Question is there a way to throttle physics update when the framerate tanks?

i'm polishing this bit script that handles performance and after all the tricks all I left is naughty physics that's tanking my framerate when too many creatures are in the world.
Time.fixedTime is read only for good reasons I'm sure so what's left as a quick way to throttle down physics' cpu usage?

this works but seems dangerous

Code (CSharp):

1. Physics.defaultSolverIterations = Mathf.FloorToInt(Mathf.Lerp(6, 3, (float)(cpuTime / (HZ60GPUTIME * 2))));
2.  

 

You can write to Time.fixedDeltaTime. This modifies the frequency of calls to FixedUpdate() and the physics update rate.

Note that changing Time.fixedDeltaTime in runtime may have unexpected secondary effects, as described in this thread:
https://forum.unity.com/threads/adjusting-time-fixeddeltatime-by-time-timescale.869491/#post-6796637

 

Cool didn't know this was the entry point.
Have you tried changing the fixeddeltatime at runtime? Any way to avoid objects suddenly exploding?
I will test today if dropping the solver iteration count even drops physics cpu noticeably, it might be too small a change and cause too many glitches as well.

 

Yes, but I do it only once after loading the scene. My case usage is simulating complex vehicles with extensive use of joints (i.e. cranes) that require a larger physics rate to retain stability.

That's why modifying Time.fixedDeltaTime in runtime is a bad practice. PhysX does some state caching along time. Applying some delta time to states that were cached with a different delta time results in those unwanted effects.

I can't figure out a proper solution for this. Maybe a possible workaround would be 1) store velocities of all dynamic rigidbodies, 2) make all those rigidbodies kinematic, 3) modify Time.deltaTime, 4) wait one physics frame, 5) make the rigidbodies dynamic again and 6) restore the velocities of these rigidbodies.

Cool, please share your results. I don't think this would cause significant issues. Solver iterations occur within a single physics step. It's like repeating the calculations a number of times so they become more accurate each repetition. Each new physics step the engine just takes the actual iteration count for the iteration loop.

 

I tested both iteration and fixeddeltatime lerping at runtime.
All objects except a few are kinematic driven by navmeshagent. By the time framerate triggers the lerp there are enough objects onscreen to hide glitches I think.
It all works fine.

 

Weird effects may happen rarely in non-kinematic objects. The condition is that the lerp is triggered while a collision is being resolved. It might be a rare effect, but it definitely can happen.

 

How to prevent that?