# DOTS Physics and determinism

Hello all,
I’ve been looking into the new Unity Physics documentation and one thing stood out to me:

Now I’ve researched cross platform/architecture physics determinism in the past and came to the conclusion, that it’s not possible using floats in Unity, which is why I decided to create my own fixed point physics system.

Question: How can we understand that determinism claim? Is the DOTS Physics system supposed to be deterministic on one machine or do you take any steps in the burst compiler to ensure cross processor and architecture float operation determinism?

Same question.
We use simple self 2d AABB+ physics based on fixed point math.
We need determenism between divecies and patform (ios\android)
May we switch to DOTS Physics engine?

By the way, for now the system seems to actually run in the frame rate dependent update loop, so it is by design anything but deterministic. I am pretty sure that is subject to change, but for now it makes little sense to evaluate it in this regard.

Unity will use the Burst Compiler to enable cross platform deterministic float operations, at least they’re mentioning it here: https://github.com/Unity-Technologies/EntityComponentSystemSamples/blob/master/Documentation~/ecs_principles_and_vision.md#determinism

We use “ticks”
I think manulay run physic step with custom “delta time” enough to solve this problem (if math itself determ)

Yes, I remember reading that a few months ago and I guess it can work as long as the floats are never assigned by regular floats from non-burst compiled code.
I hope they pull it off, but this comes with many, many question marks attached. Would be nice to hear about the progress on this.

I guess you are talking about your own in house solution? Yes, that is the standard procedure if you want to achieve any kind of reliable physics.

1 Like

Unity Physics is not deterministic, yet, at least not 100%.

Here is a sample where I created 6 columns of 5 spheres. Each column should bounce exactly the same. In the example gif we can see this is not the case.

However, if I repeat the process, we can compare the two and see if it its consistent across runs.
(Test #2)

To be 100% deterministic the results should be the same no matter the coordinates.

It’s hard for me to tell with this example. Perhaps we need something more dramatic. But this example, does show differences between the columns that are identical. This may have major effects in something like racing games, where user on left side might experience slightly different physics than the user on right side.

EDIT: I can’t seem to embed the gfycat gifs, sorry!

I think determenism is:
Same Input → simulation → Same output.
If you change coordinates its not same input

6 Likes

Necroing to correct the misunderstanding.

Yes, the input is different, but in the case of balls bouncing on one axis (y in this case), only the y input matters, which is the same between balls (I assume). A deterministic physics system should be able to produce balls in a line that bounce in sequence on the y axis, given there is no force acting on the ball on the x or z axes, such as in the example provided. So, the only culprit for the balls not bouncing in sequence is that the Physics is not deterministic.

In any case, what is the current status of this now?

To get exactly same result in case like yours, floating point math based physics would need to simulate the rigidbodies in same location for this type of operation to be possible. This would need to be either same location or always done in local space (but once transformed to world space, floating point math could alter the results due to the floating point accuracy anyway, breaking this type of determinism). Basically as soon as you move the body to different location, floating point math may give you slightly different result. Only way this type of operation could stay deterministic is to use physics solver that doesn’t use floats, otherwise it’s virtually impossible due to floating point accuracy playing a role here.

I stress that you will never get this type of behavior out of Unity Physics, you’d need fixed point math based physics solvers instead.

What Unity Physics does give determinism for is that for same input (including body transform), you get same results (and determinism like this is really helpful for networked physics).

1 Like

Good to know. It still doesn’t make sense to me . . . I mean, if you have the same y value for different objects even if they have different x and z positions, and the only force acting on those objects is gravity (and they all start with the same acceleration/speed on the y axis, and zero acceleration/speed on the x and z axes), then it seems like the math should work out the same for each object.

You can probably read somewhere about floating point accuracy and errors. Basically you could do same axis physics integration in local space and you’d get exactly same result. But then when you’d move this object to different location, you’d have to use potentially lossy floating point math to do this. You’ll face the floating point math inaccuracy as well if you integrate in world space with different input values (different position).

Even if you could do the integration in local space, you can’t guarantee that once you move between local and world space and back to local space, the result would be exactly same as there’s bunch of math operations on these transformations that can alter the last digits of the values. Even one digit diff can make your physics work differently. For example on like on collisions things can bounce into different directions etc with minor diff like that.

3 Likes

someone have tried it?

Here a video:

Interesting.

That’s what Unity should be doing IMO.
Use this with a prediction/rollback netcode strategy and you get cross platform multiplayer without having to worry much about netcode synchronization and stuff.
Really fast to iterate when developing and suitable for multiple game designs and genres.