Seeking Help on Determinism in DOTS Physics

Hello, Unity community!

I’m working on an ambitious project that involves marble racing with a strong requirement for deterministic physics simulations. For this reason, I’ve opted to work with Unity’s DOTS and the new Physics library. We’re making good progress but have hit a roadblock that I’m hoping someone here can help with.

The Setup
We’ve created a demo scene with some basic platforms for testing the roll of the marbles. In these tests, the marbles are not manipulated in any way and just roll due to gravity.

Platform Setup:


The entire level resides in a sub-scene that loads into its own custom world. Implementing this separation allowed the simulation to work deterministically, but only when the frame rate and time scale settings are consistent.

Output from Windows Build:


Code Snippets
Here’s how we set up the Physics library to tick 120 times per second:


And here’s the world creation code for the game level:


The Problem
The simulation works deterministically only when running at the same frame rate and time scale settings. However, we need it to be deterministic across different settings for frame rate and time scale.

Questions

  • Has anyone encountered this issue before?
  • Are there any recommended settings or methods for achieving determinism across different frame rates and time scales?
  • Any other insights or tips on working with deterministic physics in DOTS?

Conclusion
Any help or guidance would be greatly appreciated. Thank you in advance for your time and expertise!

Hey there, apparently there is an issue with the images you uploaded. If you fix them you are more likely to get the help you seek.

Hi Rhodos, thank you for letting me know. I uploaded the images again.

With a standard game physics engine you can not expect the behaviour to be identical when using different timesteps. The timestep defines the accuracy in the time discretization of the method and for most simulation cases different timesteps will lead to different object trajectories.
The time stepper discretizes otherwise smooth differential equations and has an error term in the order of the timestep. Depending on the integrator used this could be O(dt^2) (for the semi-implicit Euler integrator we use in Unity physics) or different orders.
In other words, using a smaller timestep leads to a smaller error in the time integration and thus different outcomes.

Sounds like a good use case for Havok. Or even Photon’s Quantum.

The described limitation also applies here, assuming discrete time integration is used. Changes in the timestep change the engine’s produced trajectory except for special cases, such as specific steady state situations (object at rest, object traveling at constant speed without angular motion in zero gravity to name a few).