Hi all!

I'm making a game where you try to throw lassos at other players. This requires a lot of spawning a rope, despawning it, then respawning it again.

Currently I do this by disabling the ObiRope and ObiRopeExtrudedRenderer components. When I need it again I reenable it by waiting until the rope is loaded then manually adjust the positions, prevPositions, and Velocities of all particles. Then I wait one frame to let things settle before reenabling the Renderer.

This almost works, except for a single frame where the Renderer shows its previous position. I cannot for the life of me figure out how to make the Renderer only show the new position of the rope rather than starting at its previous position. This also happens when I just leave the Renderer on the entire time.

Is there a better way to go about disabling/enabling rope or some kind of RendererRefresh I can call? I was considering teleporting the rope somewhere far away while disabled rather than disabling the component but wanted to see if there was a better way first.

Thanks!

Pic of the one frame issue:

Hi, in the softbody documentation it is written that at max resolution (128, as I understand), one vertex would correspond one particle, but it doesn't seem to be the case? It seems to be governed by Shape Analysis Resolution value as well, and I cannot enter the value higher than 128 manually.

Is it possible to override the limit if I want to have actual one particle per vertex?

In a similar manner, I understand that having a lot of particles would make the simulation unstable, and what values can I tweak to achieve better shape matching? So far what I've gathered - low Mass Scale, Sequential Shape Matching, and Constraint Orientation (I use particle attachments and simulate parts of a mesh) works best.

In this model nose should be much more dense than the rest of the model, for example.

  suzanne_dense_nose.zip (Size: 155.2 KB / Downloads: 1)

Hello,

I recently learned from Unity's official announcement that, by the end of this month, all overseas resources will no longer be accessible to developers in mainland China.

I truly enjoy using your assets and have greatly benefited from them in my projects. However, I’m concerned about how I can continue to receive updates or access your resources after this change takes effect. Could you kindly advise on how to proceed? For instance, will there be alternative platforms or methods to obtain updates for your assets moving forward?

Thank you for your time and support. I really appreciate your work and hope to continue using your resources in the future.

Looking forward to your reply.

Hi, this thread mentioned destructive nature of blueprint generation, I noticed too that iteration based on mesh changes is really slow because of this, adding one vertex to softbody or cloth requires regeneration.

My proposition is to add feature to map existing data to newly generated particles.
To be precise, there would be checkbox next to "Generate" button (or button dropdown similar to lightmap bake) and this mode would keep old blueprint data cached, then after generation it mapsnew particles to old one by finding the closest particle. So things like weight, radius, groups would be copied from previous setup. Also groups - it would keep groups, but replace indices with new one that fit previous positions. In this case adding single vertex to mesh would require minimal changes, if any. In case of meshes with similar surface (but different density of particles) the same would apply, because 99% of data would fit previous setup.

This is not critical feature, but I think it would sagnificantly help many users and make iterations way shorter.

I'd like to put together something similar, can you give me a high level explanation on how they achieved this please:
https://www.youtube.com/watch?v=mpKB8z-lT8k

Thanks.

Hi!

Could you please advise me on what would be the best solution to have a blueprint optimized for a full soft body character, because isotropic particle density is an inefficient approach IMO.
Ideally - Blueprint window could support a "density" map, akin to skin weights map, because it doesn't make sense to have the same particle density for a thigh, or a spine, as for example for fingers, or face, or other fine-detailed extremities.
Splitting the character into different meshes with their own different blueprints is a workaround I have found working sort of well, but you can't reliably "stitch" the mesh to be visibly watertight, and have it have continuous simulation, so there are gaps (for example on a wrist where more high-particle hand meets low-particle arm) in the mesh.

Could please advise if there already is a way to solve this issue?

Thank you very much!

Hello,

I'm making a pet simulator game where you use a rigidbody hand object to pet/poke/punch/etc. a little softbody slime guy.

I need the slime's bottom half to stay locked into one place, and it seems like the default way in Obi Softbody v7.1 is to use particle attachment and paint some particles to be used as anchors. But I am still in the process of trying to figure out what the best settings for the softbody are, and every time I go to make an edit to the blueprint, I must then re-generate and repaint the anchor particles which is extremely tedious. Is there a better way to anchor a softbody without having to repaint them every time it gets regenerated?

There does seem to be one other solution to this, which is shown in the FullBodyVolumetricSoftbody demo using the skeleton sampling feature to keep much of the softbody locked in place exactly how I'd want it to be. However when I import some bones and weight painting for my model, it seems to only anchor one small specific point on my softbody model to the skeleton for some reason. I have even gone so far as to use the exact same skeleton that the big_guy demo mesh uses and data-transferred the weight paint and vertex groups from that armature to my model, but this same effect still happens. I'm not able to find much documentation on how the skeleton sampling works outside of what's on the softbody setup documentation page; am I missing some info about what determines how much influence a skeleton has on the softbody volume and surface particles? Would this pipeline of creating a few simple bones to use as anchor points for my softbody be a viable solution in the first place?

Thanks in advance!

Hi, I noticed huge overhead coming from scheduling jobs and I have got several questions.
First of all I am aware that pushing many large job structs is slow and waking up threads is not free, however I did not expect such a big performance difference.
You can see profiler snapshot of obi simulation scheduling, single frame has 20 substeps and for testing purposes I added callback with job handle to schedule custom job (small blue bottom column).

Observations:
1. Each following substep is longer. For example the first call takes ~0.01ms, while the last one is ~0.1ms. This is huge difference, especially for jobs like particle collision where most of update is taken by them (0.4ms single substep!).
2. Using ScheduleByRef helps a bit, but I think for my custom jobs it's maybe 20% and what is more important I can't see wh huge job structs like friction can take small fraction of frame, while scheduling my job takes several times more time even if it's smaller.
3. I expected that changing Parallel to IJobFor would give me huge boost because it does not need to wake up everything, but it's not true.
4. Calling JobHandle.ScheduleBatchedJobs(); does not change anything, or I can't see visible difference.

   

In short I fail to see what exactly is causing that and on top of that Iam worried about obi8 - if I write custom constraint I guess it will be the same, so writing like 2-3 custom scripts going to kill the frame rate.

Hi all, just wanted to post an update on the VR, physics-driven fishing game I've been working on (previous update).

• The entire ecosystem is simulated using a complex AI system
  
• The player uses different watercraft to navigate large non-linear environments
  
• All the angling interactions are phyiscs-driven, thanks to Obi  
  The fish actually fight against your rod and line. 
  
• I hope to have a large array of fishing gear, including different lines and rods. Maybe even fly fishing!
  

I have a function that alters skin constraints on a procedurally generated cloth mesh at runtime.  The code currently applies the same constraints to the entire cloth, but I’ve realised I need to be able to separate them. Some parts need to be quite tight to prevent creases and crinkles, but tightening everything up prevents other parts of the cloth from moving freely, so it barely looks simulated at all.

I’m looking at the code in ObiSkinnedClothBlueprint for creating constraints, and it’s my understanding that the number of active constraints lines up with the number of clusters in the cloth mesh topology. So I would use each cluster’s vertices to calculate data about the surrounding mesh, and use that to calculate the mesh values.

Is this correct? My code isn’t giving the results I want, but before I redo my own functions to try and fix it, I want to make sure I’m actually applying the values in a way that’s intended. The Obi Cloth code is complicated stuff, and my solution feels suspiciously easy.

Thanks!