I know it can be implemented by setting Physics.autoSimulate to false and then calling Physics.Simulate manually at fixed rate per each physics “frame”.
But that breaks rigidbody interpolation (only extrapolation is left intact, but we can’t use that in our project, since we have lots of fast moving rigidbodies).
I reported it as a bug but was redirected here to ask for proper physics sub-stepping implementation on Unity side (since current behavior is said to be by design).
Physics sub-stepping is really needed in our project, we need that extra, cheap, physics joint convergence etc.
I believe many other users would benefit from it as well.
I believe developers using both 2D and 3D physics would benefit greatly from this improvement.
I’m just trying to bump this a little, because I have zero idea if this is the proper way of making improvement suggestions to Unity, simply through forums. And i’ve got no reaction. And couldn’t google anyone else making the same suggestion before.
What so you think about this?
There are no current plans for this kind of substepping. Could you elaborate why increasing the solver iteration count isn’t an option for this particular case?
After extensive experimentation with adjusting fixed timestep to increase physics update frequency, implementing my own sub-stepping by disabling AutoSimulate and calling Simulate manually and adjusting solver iteration count, higher iteration counts that gave much needed results lead to huge FPS drops under huge joint strains.
Using higher physics framerate instead also improved things (it actually improved joint behavior the most, as to be expected), but decreased framerate in general. But at least it kept the framerate much more stable.
Finally using physics sub-stepping improved things almost as much as higher physics framerate, kept performance stable, and kept performance AMAZING!!!
It also removed the need to tweak each joint like crazy for most stability and performance at the same time. Day night difference.
This feature would be a game changer for our physics heavy game. I say that as someone who has spent months tweaking physics and learning how to stabilize joints the most. I already tried all tricks I could find on various forums, after inspecting PhysX code on GitHub etc. Sub-stepping offers, by far, the best performance/tweaking difficulty/framerate stability/joint convergence and overall quality ratio.
OK I see. So are you saying that in order to make Physics.Simulate() suitable for your application it’s only needed to fix interpolation? Wondering if you’ve ever tried to code up your own interpolation solution? Unity’s interpolation just uses the last two frames of poses and assigns the Transform components accordingly, each frame.
Indeed I gave it a thought. But that is a last resort solution since making sure such custom interpolation works fast, on all rigidbodies in the scene under all circumstance, doesn’t break anything, that all timings are perfect etc. would be hard.
I also tried using rigidbody extrapolation instead - but that gave unpleasant results on fast moving rigidbodies in our scene for obvious reasons.
I have created a bug report ticket for this actually, in the past (Case 1297438). It took some effort convincing Unity QA firewall that it actually isn’t working properly. After that, I was informed this will not be fixed, since interpolation can’t possibly work in combination with sub-stepping implemented by user through manual Simulate calls. I’m not sure about that, but I’m not a full-time physics developer, so I did what QA told me - made a feature request here, in this thread, asking for a proper physics sub-stepping implementation (with bool setting to enable it and an integer setting to configure sub-step count would be more than enough I suppose).
Please @yant , you are my last chance for an amazing almost free physics quality boost <3
Hmmm this sound interesting, but I’m not sure I totally understand what the (sub)stepping does on top of regular physics stepping. The only thing I saw was, that physics callbacks are delayed until all sub-steps are completed.
From the link you posted on the other thread:
This already is the case for Unity, when you set a fixed time step smaller than the frame-rate. Can you elaborate on what would be the additional benefit of that? I’d like to understand the implications.
(Disclaimer: I mostly use 2d Physics, so things might be handled a bit differently for 3d?)
Sub-stepping doesn’t update collisions, doesn’t call FixedUpdates etc. This way it saves lots of performance. Main benefit of it is solving joints in between regular physics updates. Increasing the frequency of this particular job means amazing joint convergence at very low cost.
I’m no expert myself, just speaking from experience here. With sub-stepping I can achieve rock solid joints + high and stable FPS. Without sub-stepping, I can only increase the physics update frequency itself. This leads to horrible performance. By the time I get rock solid joints, I’m at unstable ~8 FPS in our test scene
The thing is that I don’t really need the extra work that full physics update does. I just want the joints to converge better.
I was able to do that, to some extent, by using all the joint stability hacks I could find online and/or by myself. But it’s impossible to get the level of stability that I really need in our heavily physics based game.
The difference with sub-stepping is incredible. All joint rubbery behavior and various jerking etc. disappears. Under all circumstance, when dropping heavy things on a low mass joint objects, let alone push something very hard into it, forcing it to break its constraints. Everything works.
So sub-stepping not only increases the top bar for the simulation quality you can achieve, it also does so without requiring heavy tweaking and testing per every single joint. It’s just an amazing global improvement.
OK, I see! I guess you are aware of the position/ velocity iteration settings – I always thought they might be used for stuff like this, but never really tweaked those a lot. Also it seems like 2d and 3d are different from what you can change there. For 3d it seems to mostly be for collision resolving, generally not sure if those are relevant for joints also. Thanks for laying out the details!
These are relevant to what I’m talking about, but not a silver bullet. They improve stuff, but cost a lot of performance in a very inconsistent manner. I mean - you find a value that brings solid stability, but then, when strained too much, tank performance quite a lot.
Also using the general values for these does not cut it for us. We have to fine tweak these per joint, takes time and is annoying as heck.
These also don’t work as well as upping the physics frequency or using the sub-stepping. Sub-stepping has much more stable performance, is a general setting and improves joint convergence much much more. I mean much more than even using max iteration counts for the lulz.
Hence my cry for proper sub-stepping implementation here. It just works so damn well. But I need it with working rigidbody interpolation.
Don’t get me wrong, I have no idea how PhysX integration compares across the two engines overall.
But yeah, sub-stepping has such a global effect and just is such a killer feature. I was able to see its effect on test scenario in Unreal, or in the amazing demo project from Bepu Physics.
If your making a game involving high speed physics objects, like melee combat, it’s a must have, so far I’ve got away with continuous dynamic on rigidbodies but collisions are often detected long after the sword is already stuck in an object which ruins the immersion to some degree, and turning down the physics timestep causes major lag as the game levels are pretty big.
Considering the devs comments above I think I will need to move to Unreal 5 at some point, whether Epic will help with that or not I don’t know, and then there’s converting all the C# to C++, ahh fml
I can’t speak for 3D but I’d like to clarify that I said there were no short-term plans in March but for 2022.1 there’s an opportunity to add this for 2D physics and it fits quite nicely with several of the other features that are planned for that release. That is NOT a promise for it to land in that version, just that right now there’s an opportunity.
I’ve gone ahead and implemented a version of this for 2D physics which extends the existing simulation modes we already have there. It’s actually not that clear how much of an improvement it makes overall and for how many devs it would have an impact on. I know this thread seems to be mainly 3D physics but if anyone here has an example project they think might/would benefit from such a 2D physics feature, I’d love to see it so if that’s possible, please send me; either host it yourself or DM me with your email and I can set-up somewhere for you to host it. I would prefer a smaller, easier to analyse project over a complex project with lots of other stuff going on.
Failing that I’ll spend some time looking at areas it can significantly improve. For 2D, joint stability by increasing solver iterations has always been more than enough.
A few areas I can see a potential immediate benefit over the existing 2D physics simulation modes of FixedUpdate, Update & Script are that the dev can explicitly specify a sub-step time-delta and max sub-step limit independent of the FixedUpdate in Unity which is also tied into multiple systems; increasing that frequency increases the overall CPU load in Unity because FixedUpdate isn’t just physics. Also, by performing sub-steps this way and not clearing user-forces between steps you get a full integration including those forces for each sub-step. In addition, by not performing any early stages (transform reads) and late stages (transform writes and callbacks) then you have the potential to improve performance/stability by bypassing the input/output stages whilst at the same time increasing simulation iterations that include finding new contacts, solving, integration etc.
Finally, it also looks like it might be worth considering for pure choice by the dev, whether it would be a strict fixed sub-step i.e. FixedUpdate without the input/output simulation steps where we store any unused remaining frame-time for the next frame or a semi-fixed sub-step where we simulate fixed sub-steps then finally simulate the remaining time in that frame.
Fixed Sub-Stepping doesn’t guarantee an update per-frame which makes it identical to FixedUpdate but you can change the frequency/max steps independent of the FixedUpdate and the other systems tied into it.
Semi-Fixed Sub-Stepping guarantees at least one update per-frame and will do fixed sub-steps where it can but consume the remaining time during that frame (this is the guarantee of a single simulation step). So in this mode you get the stability of fixed steps where possible but no guaranteed so improved stability over per-frame variable time-step.
Both modes reduce CPU load for multiple sub-steps though.
Why do I always have the feeling that cool stuff happens on 2D physics side of force but nothing at all happens for 3D physics? Articulation bodies, yes, but that’s hardly going to affect majority of Unity devs out there.
I vote for @MelvMay switching sides. He’s so active on the forums and always trying to help. Amazing work man, please, share your implementation and notes with someone from 3D physics department. This is lovely!
For me, as I previously stated in this thread, the biggest deal is the global, easy to achieve, low performance cost added joint stability. We have complicated joint setups, non-kinematic bodies that are either falling or being pushed into the mechanisms etc. Without sub-stepping, joints inevitably go crazy at some (not actually that hard to reach) point.
This isn’t a problem for intentionally silly games. Not so much in case of psychological horror games, where the immersion goes out the window right when that happens
You see, I keep hearing you state joint stability but saying joints inevitably go crazy without that doesn’t sound correct to me or at least I’d like to see it. I’ve not yet heard of a case, at least in 2D, where joint stability doesn’t improve with increased solver iterations and/or physics update frequency.
In the end, sub-stepping is more about when the physics simulation runs and how many times than pure stability. I believe you can “sell it” as “stability over poorer performance” by comparing it to once per-frame using a variable time-step or the classic FixedUpdate we have in Unity already. The advantage of my experiement above was that we can control the physics simulation frequency indepednent of FixedUpdate and skip some pre/post stages to save some CPU but nothing beyond that. From your initial posts you said increasing FixedUpdate caused poorer performance but without seeing some profiler info, it’s hard to say what that was. Are you sure it wasn’t other systems that are also tied into that? Worth checking out.
I am NOT stating I am correct here but rather I’m trying to invoke some proof or demonstration over a description making it sound like magic! If that’s some videos, blogs or your work then I’d loved to see it.
My work so far is to satisfy my curiosity on what I can prove would be a benefit. I don’t know Unreal that well but I keep seeing sub-stepping being compared to the variable time-step only. That’s like comparing manual Update to FixedUpdate in Unity. If you see some benefit in Unreal, are you comparing variable time-step to a fixed one only?
