Cutting softbodies at runtime

[josemendez]

hey, thanks for the quick reply!

I should've clarified a little more I guess. I'm working with a flat '2D' mesh (currently experimenting with unity's inbuilt quads), and eventually I'm going to turn those squares into rectangles or other square-like objects.

My current in-editor blueprint settings for the quad are voxels with a generated resolution of 6. Considering I will only be generating one layer of particles for all meshes after slicing, will this dramatically lighten the load and improve performance, or would this have next to no effect? I'm guessing that I can also cover it up with some graphics shenanigans.

The costlier part of blueprint generating is graph coloring. The cost of coloring is quadratic on the number of constraints in the softbody (100 operations for 10 constraints, 10000 operations for 100 constraints, 1 million operations for 1000 constraints, etc). So as the softbody gets larger, the cost rises quite quickly. The topology of the softbody - that is, its shape, or whether it's 2D or 3D - does have an effect on the amount of constraints, and hence blueprint generation cost.

You can test this by generating your softbody in-editor: If generation is almost instant, then it will be too at runtime (the process is exactly the same). If it takes a while, it will also take a while at runtime.

I did find a topic from two years ago that touched on this, but I'm not really sure if newer Obi versions have a more optimal way of dealing with this.
--> http://obi.virtualmethodstudio.com/forum...p?tid=2269

Pretty much everything said on that thread applies to the latest version as well.

On the topic of 2D and 3D, I've found that somewhat accurately simulating around 28 (at most) 3D softbodies with my 3090 with a voxel count of 14 would be about the limit before my frames crash landed to about 2 fps. Would any performance optimizations be possible, that could perhaps break the 30+ barrier? (it was actually due to this performance limitation that I switched to a mostly 2D focus).

Regarding performance, the total amount of particles in the solver is only half of the equation: your spatial discretization resolution.
The other half is your temporal discretization resolution: that is, your timestep. Using less substeps or a larger timestep size will also improve performance, by updating the simulation less often. This will also make your softbodies softer, too. The manual explains the internal workings of the engine as well as the impact of timestep size on the results: http://obi.virtualmethodstudio.com/manua...gence.html

kind regards,