Using a fixed physics timestep in Unreal Engine, free the physics approach

[anonymous_user_58aef3f9]

@0lento;581806

Basically what could happen is that you start doing more physics steps because your total frametime starts lagging but when you add more work to it, it’ll lag even more and at some point it just can’t keep up, starving the CPU (at least in theory).

I’d still keep the “Max Substeps” parameter around and use it to limit max steps you can calculate between frames. If you can’t do the work within max substep amount using fixed timesteps, you could then just split the frametime with your max substeps and use it like substeps work by default (only as failsafe). You could also change the Max Substeps to have little more headroom, especially if you want to run your physics at slightly higher framerates.

To keep fixed timesteps, delay the simulation time until the rendering catches up (ie less time will have passed in the game than real time). If it is a multiplayer game, you will also need to freeze the server and wait, or else disconnect clients that can’t keep up.

As far as determinism, it can be done in a floating point physics engine but not in PhysX currently. Contrary to what some have suggested, floating point is atomically deterministic on a single client. The result of a sin operation will always be the same in a single thread unless you do some funny things. The problem is that different chipsets and floating point modes of operations have slightly different results for the same operations. In theory you can force a specific IEEE standard but it can be expensive if a chipset doesn’t support it natively and you have to emulate. I think some runtime operations in Java can enforce certain floating point standards, for example. The second problem is that the physics engine itself might have race conditions, especially if it is using parallelization.