Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

Bug Seeking Help on Determinism in DOTS Physics

Discussion in 'Physics for ECS' started by mtka, Sep 5, 2023.

  1. mtka

    mtka

    Joined:
    Oct 1, 2019
    Posts:
    4
    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:
    upload_2023-9-6_11-36-12.png


    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:
    upload_2023-9-6_11-36-18.png


    Code Snippets
    Here's how we set up the Physics library to tick 120 times per second:
    upload_2023-9-6_11-36-23.png


    And here's the world creation code for the game level:
    upload_2023-9-6_11-36-33.png


    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
    1. Has anyone encountered this issue before?
    2. Are there any recommended settings or methods for achieving determinism across different frame rates and time scales?
    3. 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!
     
    Last edited: Sep 6, 2023
  2. rhodos

    rhodos

    Joined:
    Mar 25, 2020
    Posts:
    5
    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.
     
    mtka likes this.
  3. mtka

    mtka

    Joined:
    Oct 1, 2019
    Posts:
    4
    Hi Rhodos, thank you for letting me know. I uploaded the images again.
     
  4. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    213
    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.
     
    apkdev and Anthiese like this.
  5. gareth_untether

    gareth_untether

    Joined:
    Jan 5, 2018
    Posts:
    63
    Sounds like a good use case for Havok. Or even Photon’s Quantum.
     
  6. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    213
    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).