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!

Hey guys! 
Im working on a construction sim which uses Digger pro for voxel terrain and it uses terrain holes when digging downwards and puts a mesh in the place of the hole. Now the problem is fluids does not seem to recognise that there are holes and flows as if there is no hole. 
I tested this with a plain scene with a new terrain and painted a hole and added an emitter on top, but it thinks there is no hole there.

Am I missing a setting somewhere or is there a workaround for this? Any leads will be appreciated.

Regards,
Abhishek Jathan

Hi, sorry to bother you again, I'm encountering a rather unreliable skinning behaviour.

   

Steps to reproduce:
When modifying the RubberDragon demo, if you increase the Surface and Volume Sampling to a 100, to increase the particle count. And re-binding it in the skinner with the default parameters. Removing custom skinmap doesn't help.
Increasing Radius in the Bind parameters helps the issue somewhat, but it "inflates" the skinned mesh, and is a workaround I'd like to avoid.

Thank you very much for your continuing support and development of this amazing plugin!

Hi there!

I didn't found a topic but maybe I didn't search correctly!
I thought it will be fun to share our games that use Obi Rope!


Here is our game release last January 29th : 

CAIRN



Available on Steam but also on various PC Stores and PS5



We use Obi rope for the lifeline of Aava (the main character) with a good old line renderer and for the quickdraw (not visual, only the simulation rebinded on a skined mesh).
We split the rope into several ropes (one rope between each quickdraw)
We use distance field for collision (no mesh collider since it was easy to penetrate and impossible to move out)

Cheers!

Guillaume