Solver is too performance heavy

[quent_1982]

I have a single medium length ObiRope with ~35 attachments, that costs around 22 FPS, but hole pure rope somehow costs around ~38 FPS, so the hole solver with single rope uses ~60 FPS, that is too much.
TimeStep in project is 0.015f, I've played a bit with ObiSolver values but it didn't help at all. If I set all solver's constraints to 1 and parallel it gives only ~12 fps.

[josemendez]

I have a single medium length ObiRope with ~35 attachments, that costs around 22 FPS, but hole pure rope somehow costs around ~38 FPS, so the hole solver with single rope uses ~60 FPS, that is too much.
TimeStep in project is 0.015f, I've played a bit with ObiSolver values but it didn't help at all. If I set all solver's constraints to 1 and parallel it gives only ~12 fps.

These FPS numbers are not normal. They suggest that either the Burst compiler is disabled, or the jobs debugger is enabled. You must enable Burst and disable the debugger for normal performance inside the editor, as explained in the manual:

https://obi.virtualmethodstudio.com/manu...kends.html

Also keep in mind that Synchronous Fixed mode is very costly, and it may trigger death spiralling if combined with a small timestep. Try switching to Synchronous, if performance suddenly improves then consider adjusting your project’s max allowed timestep.

Kind regards

[quent_1982]

These FPS numbers are not normal. They suggest that either the Burst compiler is disabled, or the jobs debugger is enabled. You must enable Burst and disable the debugger for normal performance inside the editor, as explained in the manual:

https://obi.virtualmethodstudio.com/manu...kends.html

Also keep in mind that Synchronous Fixed mode is very costly, and it may trigger death spiralling if combined with a small timestep. Try switching to Synchronous, if performance suddenly improves then consider adjusting your project’s max allowed timestep.

Kind regards

Hello, thanks for reply!

I've noticed that Unity enable Burst's Safety Checks, Jobs Debugger and Leak Detection every time I want to relaunch Unity Editor, so disable it all back gives much better result.
But still in async. mode 1 solver (I've changed it a bit so I've attached several screenshots) with same rope costs ~40 FPS, inside of Profiler FixedUpdate not call more than once per frame so Time settings is set good and I really do not want to change Time because of project size.

[josemendez]

Hello, thanks for reply!

I've noticed that Unity enable Burst's Safety Checks, Jobs Debugger and Leak Detection every time I want to relaunch Unity Editor, so disable it all back gives much better result.
But still in async. mode 1 solver (I've changed it a bit so I've attached several screenshots) with same rope costs ~40 FPS, inside of Profiler FixedUpdate not call more than once per frame so Time settings is set good and I really do not want to change Time because of project size.

Still not normal to get 40 FPS. Most cases with a single rope would yield +200 FPS on a regular computer. Would it be possible for you to use the profiler to export a profiling session that we can take a look at?

kind regards,

[quent_1982]

Still not normal to get 40 FPS. Most cases with a single rope would yield +200 FPS on a regular computer. Would it be possible for you to use the profiler to export a profiling session that we can take a look at?

kind regards,

Hello, just wanted to check if you've had a chance to take a look at the performance test project I sent over yesterday.

Let me know if you have any feedback or need anything else from me, kind regards.

[josemendez]

Hi,

Received your project and tested it.

You have 20+ attachment components per rope which is overkill, the cost of having so many components per object which is not negligible. You also have 20 rigidbodies with 20 colliders, 20 joints, etc - per solver which is a lot of objects. A sizable part of the cost comes from these.

Note that if you simply want objects evenly spaced along the rope, there's a much simpler and cheaper way to do it: set the position of the object to a point along the rope. See ObiRopeAttach sample component for an example.

If you really need that many attachments, create pin constraints at runtime. This will circumvent the need to have so many components per object.

Still, in your project a single solver+rope runs at about 200 fps (5 ms/frame). Copying the entire solver once (2 solvers, 40 rigidbodies, etc) runs at 170 FPS (6 ms/frame): That's *only* 1 ms more. Having 5 copies of the solver runs at 95 FPS (10.5 ms/frame). Having 12, it runs at 40 FPS (24.8 ms/frame). It's not a performance issue, it's working as intended given how heavy the simulation is.

These measurements are without the 20+ attachments, rigidbodies, joints, etc per solver:
1 solver: 220 FPS
2 solvers:204 FPS
5 solvers: 165 FPS
12 solvers: 100 FPS

So the objects under each solver make a large difference: from 100 FPS without them, to 40 FPS with them.

Also note that relative performance must never be measured using FPS, since FPS don't scale linearly with performance.
Milliseconds/frame is the usual way to measure performance, as it's linear. For instance if your game is running at 200 FPS (5 ms/frame) and you add 2 ms/frame, that's 1/0.007 = 142 FPS. It would seem like a huge performance drop, but consider what happens when you add the same hit of 2 ms/frame to a game running at 60 FPS (16 ms/frame): 1/0.018 = 55 FPS. It's only 5 FPS less.

So the same performance hit that takes you from 200 FPS to 142 FPS, would take you from 60 FPS to 55 FPS.

kind regards,