There is a setting called Physics Update Cap. This setting specifies the maximum number of Physics Updates that can run per rendered frame. If your FPS is low enough that this cap gets hit, you could experience time slowing down, which will make everything look slo-mo. This is just an unfortunate side effect of physics running at a fixed frame rate and being independent of the rendered frames. Try setting to 3 to minimize that possibility, but note that it could lower your FPS because each physics update takes a lot of time and up to 3 could happen per rendered frame. This could happen if you have physics rate set very high and/or your rendered FPS is very low.
I appreciate everything you are doing here, and I'm glad to see you discovered the Physx single thread bottleneck (which is a bit better in newer Unity versions but it still sucks - I'll be doing custom skin physics in VaM2 for this reason). I also glad you posted those charts of how the character threads timing works. The goal for VaM1 was to hit 90FPS for VR usage. I realize with heavy physics it often does not hit that unless you have a very good CPU/GPU and are not running a scene with lots of models all with soft-body physics on. It was a challenge. The character threads code was optimized just enough to try to hit this 90FPS so as not to be the bottleneck. The skinning system is very inefficient as is the morph code. It is great you addressed both of those. When I developed this I didn't see much of a point trying to hit a max FPS above 90 since I was targeting VR and that was the sweet spot. The ultimate bottleneck is Physx on physics heavy scenes and there isn't any way around that. That all said, I am still very glad you looked into this and found some amazing fixes just sitting there for many/most users. I would love to roll this back into official release at some point if you are willing and I can find some time in between VaM2 work. That might be tough. I would definitely compensate you if we manage go this route. If you are interested in making some $$$, I could even give you access to the VaM github repos so we can add this in an easier-to-review manner. I would want to review everything just to make sure nothing is getting broken. DM me if you want to go this route.
Thank you!
I agree with almost everything you said, except my multithreading of GPUCollidersManager::ComputeColliders(), I realized while multithreaded
writing to physx is a no-go, you can multithread
reading access to the physx engine without problems. In my patch I fill the GPSphere[] and the GPLineSphere[] that goes to the shaderkernel multithreaded. This call happens in
FixedUpdate() and it cut the physics time a little, what we yearn for most.
All other optimizations are purely for dick measuring in benchmarks lol.
The other thread schedueling workarounds apply to pretty much every game and there was nothing wrong with VaM in that regard.
You are also correct about the physics thing. Here is a simpler explaination as far as I understood:
If you your physics rate is 90hz and the physics update cap is 3, the optimal boobs update is 270 times per second, so if you manage to hit 270 physics updates per second the boobs get updated correctly and there is no flopping around. If you lower the physics update cap to 1 there is more flopping because the velocity kept constant for a longer time. Same happens if your CPU is too slow, because you also skipped physics updates.
What many however dont realize is that the
average FPS you see is not the
physics updates per seconds! Your PhysicsRate*PhysicsUpdateCap needs not only match your FPS, but your
min FPS, the points where physics happens! My patch makes this actually harder to realize because it boosts the "physics free" frames while not really touching the
min FPS.
Users install my patch, see their avg FPS go from 180 to 270, update their physics rate from 60*3 to 90*3 and wonder why boobs start flopping around, not realizing that their min FPS mostly stayed the same.
"Physics Time" also isnt really physics time because the
Performance Monitor in VaM also counts physics free frames into the average as "0.00ms", that took me a while to realize and I added a "Physics Time (only fixedUpdate frames)" metric for myself for testing. Maybe add a "physics fps" metric in the perfmon? Showing how many FixedUpdate() were ran per seconds, so users can adjust their settings to perfectly match that.
I also contemplated if its even worth doing improvements to the physics free frames, but I guess for scenes where there isnt that much physics or when its mostly morphs doing the content, it still counts as an improvement if the the physics rate is dialed down.
TLDR: boob physics didnt improve that much, keep the physics rate and soft body setting you had before or they start flopping around.
