When Async Physics is enabled, if the game-thread delta time dips below AsyncPhysics/MaxPhysics delta time, rigid bodies will slow down despite reporting the same velocity as a higher framerate. This causes the result of the simulation to appear ‘slowed down’.
This is unexpected since we expect Async Physics to produce deterministic results regardless of game thread tick time, so long as p.AsyncPhysicsBlockMode is not setup to drop simulation frames. This is problematic for games with smaller physics timesteps becase you are unlikely to be able to maintain consistent game thread performance, and physics results will diverge as a result. This is compounded in network games where physics replication is used as results diverge far more than usual.
This is easy to reproduce in one of the starter projects with either Chaos Vehicles or Modular Vehicles. Enable Async Physics and drive forward, making note of the reported velocity and distance travelled. Now limit the game thread to a low framerate such as 15/20 FPS, and perform the same test - the reported velocity of the body and all calculated forces will be consistent, but the distance travelled in the same amount of time will be far less.
Raising MaxPhysicsDeltaTime to something unreasonable like 1.f, removes the issue (unless you suffer a hitch or otherwise dip below 1 FPS) - without deeper investigation it would seem that the position solver uses a different delta time to the physics simulation step, which seems like an oversight.
The main concern is that some projects require higher physics timesteps (like 60/120Hz) for stability or accuracy, and if the game cannot maintain a framerate higher than this, the results will diverge dramatically.
[Attachment Removed]
Steps to Reproduce
Using the ‘Chaos Vehicle’ or ‘Chaos Modular Vehicle’ templates:
- Setup Async Physics in project settings with a 30Hz tick rate and a 30Hz MaxPhysicsDeltaTime.
- Drive one of the vehicles, drive forward a fixed amount of time and make a note of the distance travelled.
- Clamp maximum delta time with t.maxfps 20
- Drive again for the same amount of time, but notice the distance travelled is much shorter.
Notice also that the reported velocity of the physics object is the same, but the actual distance travelled is much lower.
[Attachment Removed]
I should add that this does NOT occur when Async Physics is disabled, and Substepping is enabled instead. So long as you have enough substeps to cover the game threads delta time, simulation results will remain stable and consistent at low FPS.
It’s expected that Async Physics would act like substeps, accumulating delta time and simulation multiple frames in a singlel game tick should the GT fall behind.
In addition to the above, if you enable substepping AND Async Physics, the effect compounds even more - and physics will slow down further but still report the same velocities.
[Attachment Removed]
Hi James,
I think this may be a slightly non intuitive setup on our variables - can you set the MaxPhysicsDeltaTime to 1 and see if this then goes away?
Best
Geoff
[Attachment Removed]
Ah, sorry James - missed that part.
Looking at the code - if you set the MaxSubstepDeltaTime to be 0, it will avoid clamping at the ChaosScene level, but will still limit the step to the AsyncDt further down. That seems to be the sensible setting for the async side.
I’ll raise this with the dev team because throwing away time is a surprise, and we limit this anyway further down (ie we do the canonical 'limit how many steps we can do - which slows time down in overloaded scenarios where there just isn’t a good answer).
Best
Geoff
[Attachment Removed]
Hi Geoff,
Yeah I mentioned this above, if you set MaxPhysicsDeltaTime to something impossibly high (clamped to 1.f by project settings) the slowdown issue goes away, but of course if you suffer a spike or hitch that takes the delta time beyond that, you will still desync/diverge so somewhere the determinism is lost.
Even when the simulation “slows down” however, the reported velocities/accelerations/forces applied to objects are the same, it’s the resulting transform that does not accumulate correctly from those internal accelerations. It seems that the final position solve is using a different delta time to the sim itself.
[Attachment Removed]