Excessive physics overhead while moving of model with big amount of beams/nodes

Yes, I've reduced quality of graphics for these tests.
And I expect that red portion of graph should only correspond to actual physics calculation, while video encoding overhead should be not counted as and marked as "physics".

 

No, it works so that any CPU load can make red part to appear if that CPU load causes physics code to get more delayed as CPU processing power runs out.

Also if physics have to wait something else which gets affected by increased CPU load, red bars start to appear.

So it is bit hard to know sometimes why physics appear to get lot of delay, what can be known is that CPU can't keep up, reason why can be almost anything and that is why it is needed to eliminate other possibilities.

For example when I did close OBS studio red bars did go completely away, when I had it on, red bars appeared, however with OBS closed when driving trough narrow gap, added CPU load by collision system did show up and it was known that there could not be graphical workload increase or any other workload increase, so it was clear what caused the situation.

With complex maps there are often too many variables, that is why such simple test object on quite empty map is good test as it removes other variables from play, test becomes more controlled that is always helpful for finding out what is really happening.

 

There are there new videos with some updates on that topic:


Retest of HWInfo+threads scenario, but now with 8700K@5GHz. "Red peaks" are there, but got quickly absorbed by more powerfull CPU and generally this setup is playable.
Okay, finally I was forced to upgrade from 3770K by something. However,


Six tri-articulated buses on simple map. Stable Red peaks overhead. But only on realtime. Even 2x slowdown removes "solid red overhead" completely. Not gradually, but completely.


Much clearly pronounced physics overhead with complex 8*8 Crash Hard's truck. Nicely detected single-thread overload. Moving to 2x slowdown shows how the previoulsy ovelloaded thread becomes free and that leads to normal processing.

From "white box" perspective of testing, it seems like the way to resolve this issue is to distribute complex models calculations between several threads.

 

It seems to be fixed in 0.19