Optimizing Performance With Multiple Softbodies

[relevantname]

Hi,

I want to have min. 60-70 softbodies in my scene(Little softbody cubes), bu performance issues arise when there are more than 20 softbodies in the scene(FPS dropping to 2-4). Each softbody has 8 particles and ObiSolver's substep amount is 2. 
I tried to solve this problem with these solutions;

- I created an Obi Solver for each of my objects. And I unchecked the box 'Simulate When Invisible', but no luck, fps still drops.
- I attached a script that checks the distance between player and softbody to enable(when the player is in range) or disable(when the player outside of the range) the ObiSoftbody component. 
This approach worked very well but most of the times softbodies didn't behave correctly to player's actions or there are lots of position mistakes(weird teleportations) happened.
- I attached a script that checks if the softbody is visible to camera or not, and enable or disable the ObiSoftbody component. (Not surprisingly, I got the same result as solution above)

Are there any solid solution for this kind of case, or am I doing something wrong with applying these solutions? 

P.S: In solutions 2 and 3, I also tried to AddActor and RemoveActor methods, not only enabling or disabling the ObiSoftbody component.
P.S 2: I'm using Burst mode. (I also tried to switch Obi mode)
P.S 3: I'm not checking collisions on particles. 

Thank you.

[josemendez]

The amount of softbodies and/or solvers in the scene has zero impact on performance.

When you add an actor (soft body, rope, cloth, whatever) to a solver, all of its particles and constraints are "thrown in a bag" together with all particles and constraints of other actors. Then, all particles from all solvers in the updater are updated in parallel. The engine does not care where these particles came from, in fact it does not know what a "softbody" is: all it cares about are how many particles and constraints are there to process.

Roughly 500 particles (70 softbodies x 8 particles each) should be no issue. No need to enable/disable solvers, softbodies, etc.

- What are your solver/updater settings? how many shape matching constraint iterations, how many substeps, etc?
- You mention you're using Burst: make sure to disable the jobs debugger and safety checks, as these have a huge negative impact on performance. See:
http://obi.virtualmethodstudio.com/manua...kends.html

[josemendez]

On a side note:

Code:

FPS dropping to 2-4

This is a clear symptom of death spiraling: If your physics simulation takes more than X real-world milliseconds to simulate X milliseconds worth of game time, Unity will be forced to perform more than 1 physics update per frame. This negatively affects performance, and forces it to update physics more and more times each frame, entering a downwards performance spiral that stops when it hits your max fixed timestep setting. Its default value is 0.333 seconds, or 3 FPS.

If you're unsure what death spiraling is or how max fixed timestep / fixed timestep affect your physics, there's many online resources that explain it:
https://forum.unity.com/threads/what-is-...ep.330116/
https://docs.unity3d.com/Manual/class-TimeManager.html
https://gafferongames.com/post/fix_your_timestep/