How much deterministic is Physics from Unity3d In 2019?

The 3D Physics of Unity is deterministic across different platforms, like Android and IOS?
<br><br>

I saw the 2D physics is not (acros different platforms):
https://support.unity3d.com/hc/en-us/articles/360015178512-Determinism-with-2D-Physics

"However, for your application, you might want strict determinism. As
such, you would need to know whether Box2D can produce identical
results on different binaries and different platforms. Generally,
Box2D cannot do this. The reason is that different compilers and
different processors implement floating point math differently, which
affects the results of the simulation."


But I saw the 3D physics maybe is?
https://docs.unity3d.com/ScriptReference/Physics.Simulate.html
"To achieve deterministic physics results, you should pass a fixed
step value to Physics.Simulate every time you call it. Usually, step
should be a small positive number. Using step values greater than
0.03 is likely to produce inaccurate results."


https://blogs.unity3d.com/pt/2018/11/12/physics-changes-in-unity-2018-3-beta/
In the article above says:
"Enhanced determinism PhysX guarantees the same simulation result when
all the inputs are exactly the same."

So in theory it is possible, but in reality (you know dealing with physics across different platforms, like Android, IOS and others) is very complex.
I'd like to know from someone how tried to implement this in 2019, if this is possible nowadays?

 

Not sure, even most deterministic system can be 100% across different platforms.
That is why you may need sync points, to ensure, discrapiences are not wandering too much of the course.

 

@Antypodish , but ok with sync points is this physics reliable to implement a network game of Pool for example?

The behaviour of the balls will be the same on each play (in different platforms) if I:

- Recreate the scene from scratch in the same sequence (with new positions)
- Put Fixed Step
- Setup CCD

Because I implemented this stuff some years ago, the physics was not deterministic, the results are awful, I had to implement a Physics by myself.

But nowadays the PhysX of Unity 3d is really deterministic?

 

Pool type game is such slow game, that you can send plenty of sync points as you want.
Basically you send all hit vectors, and magnitude as force from current active player.
Delay of even one sec if ever would be the case, that is not an issue in such game.

 

@Antypodish thank you for your reply.

I saw on this website:

https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/BestPractices.html

Determinism:
the PhysX SDK can be described as offering limited determinism. Results can vary between platforms due to differences in hardware maths precision and differences in how the compiler reoders instructions during optimization. This means that behavior can be different between different platforms, different compilers operating on the same platform or between optimized and unoptimized builds using the same compiler on the same platform.

It also says:

However, on a given platform, given the exact same sequence of events operating on the exact scene using a consistent time-stepping scheme, PhysX is expected to produce deterministic results.

But it's not my case, my case is the one which I have many platforms many hardwares (different mobile systems).

So I must asure the determinism.

Is the PhysX of Unity deterministic or not? Because I have already had this problem, the Physics Engine was "deterministic in most cases", but in reality when you put into production there were a lot of problems once in a while (which is something I cannot accept).

 

From run to run may be, if simulation steps are forced. But that only on given device.
If you restart PC, or change device, results may be different.
Hence as I said, you need sync points. Which for your case are very trivial.

 

I suppose Unity's 2D and 3D physics engines offer the same degree of determinism.

I spent years battling with 2D Physics in order to achieve full determinism, at least when same build and architecture are involved (IE: an ARM build running on an x86 emulator will NOT achieve a consistent simulation).

And even now that I eventually obtained it, some weird Android 9 updates are screwing things up, as you can read here:
https://forum.unity.com/threads/2d-...when-updating-oneplus-3t-to-android-9.711269/

My suggestion is to avoid relying on full determinism unless you have really, really, really good points to go for it.

 

@Menion-Leah thank you for your post.
I must rely on full determinism because the gameplay needs this: pool game for example. I want the players to handle the physics.

The 2D physics of Unity is Box2D as it is on this article it is not deterministic:
https://support.unity3d.com/hc/en-us/articles/360015178512-Determinism-with-2D-Physics

So the the 2d Physics of Unity (which use Box2D) IS NOT deterministic.

The alternative would be 3D Physics.
As far as I know 3D Physics of Unity is made with PhysX.
I'm wondering if the 3D Physics is deterministic because in one place it says it is deterministic and in another it says it's not (as you can see in my posts above).

 

You don't need full determinism for such games like pool. Just read my previous posts.

 

Hello @Antypodish, I've read before for sure, maybe I didn't understand...

So you said:

Pool type game is such slow game, that you can send plenty of sync points as you want.
Basically you send all hit vectors, and magnitude as force from current active player.
Delay of even one sec if ever would be the case, that is not an issue in such game.

So for me the sync points is to send every position and vectors for each play and re-create the scene.

I understand you said the pool is a slow game, but in my previous experience with these physics engines (before 2011 when I implemented a pool game), every time there were an asynchronism between plays, even if I did what you said.

So for me this full determinism is something related to this issue, if I do a play in one machine/mobile I can rely the other side machine/mobile will do this same play in any situation. I'm a little traumatized with these determinisms of the physics engines (they always get used to fail), because of that I assume a full deterministic physics is needed.

In Java I can assume a physics can be REALLY deterministic because I can use the strictfp modifier in my classes.
strictfp is a modifier in the Java programming language that restricts floating-point calculations to ensure portability.
Programmers can use the modifier strictfp to ensure that calculations are performed as in the earlier versions; that is, only with IEEE single and double precision types used. Using strictfp guarantees that results of floating-point calculations are identical on all platforms.

So the full deterministic physics could be implemented in my pool game, because I did the physics and I could not handle the engine physics at that time.

For example, If I do what you say about sending hit vectors etc.., will sometime I get some asynchrony in my game? E.g. if there are 100000 plays how many of them will experience asynchonous calculations? Is it garanteed these 100000 plays will run exactly the same?

 

Why you need 10k plays?
You can easily calculate hit points ahead of time.
So if player has control, it can send all hit points for particular shot and sync at any point. So after shot is finished, every player is synced anyway.

Each watching player basically receive time, vectors and positions of each moved balls, whenever direction changes.
Watching players only calculate path between point.

In fact, you may be even better, to use own simplified physics, since you deal with balls and walls most of the time. More tricky part are pockets.

 

I said 100k plays for statistics purpose.

E.g. if I play 100k times (in different games), how many of them don't get sync and fail?

When you talk about "calculate hit points ahead of time" you are talking about the positions of the balls in the table in consecutive plays? E.g. If I play 10 times, so I can put the physics balls/table on the 10th play and begin from this play?

So in this case, if I do that, is there a minimum chance of the physics to not have the same results in two different machines and fail with Unity 3d Physics?

 

I would ask, why you worry about 100k statistical gameplays?
There is no way, that 100k plays will have same combination of shots.
Unless you have predefined configuration of balls on the table and you make somehow competitive game, across hundreds of players.

Unless I am wrong, you will have 2 players competing between each other during single session. At most some spectators. For which determinism is irrelevant for them.

See here

You know where is hit on the blue ball. Of course, each player has same configuration of balls at this point. Which is trivial to achieve. You know where white and blue will go. Next hits also can be defined etc.Now you send that over the network.

It should be irrelevant, that another online game session will result different configuration.

So what is your purpose for such mechanics?

 

I think I am talking in the wrong way.

Yes the pool game, is very simple just between two players (no spectators)

When I talk about plays, I mean the shot of the cue ball and the whole behaviour of the physics in this play (between two players).

A complete play:
- the shot (point, angle direction, force of the play on cue ball)
- the movement of the cue ball and the other balls after the shot

So If "a play", which is the behaviour of all the balls movement ends in the same position and rotation for the two players in two different machines and architechures, I can rely on this physics.
If "a play", a shot on cue ball ends in wrong positions of the balls in two different machines so I cannot rely on this physics.

When I talk about 100k plays not to fail, it means that the result of a shot is always equal for the two players in different machines/mobiles/architecures. I never want the physics to behave different in two machines. Just for statistics purposes when I say 100k plays I never excpect the result of a play (which is the bahaviour of the balls in one shot) to fail, to end in different positions.
The result of a shot between two players, the balls must always end in the same position in these two machines.

What I normally see in these physics engines, is that when I send the shot info to two different machines/architecures the physics behaves slightly different in these two machines somestimes due to difference in floating point architectures;
So The result of a shot will be different for both players if both devices.

Talking about many games being made between many players, If 100 of these 100000 plays/shot (which can be in any game) is wrong, it compromises the gameplay, because I cannot rely in the determinism, so I'll have too many complains saying the game behaves different from what is seen between two players.
Imagine if one of these failed plays (which is a whole simulations of a shot) is in the end of the championship what was televised, this could be very awfull.

I say that because I tested this with old game engines prior to 2011, they aways once in a while, give me different results of the physics simulation between two players.

 

This is where some player during session should take authority over.
Results / sync point sent to other client in the session.

Now you can switch authority, based on current player turn in the session, to another player. And so on.
Server would be more ideal, regarding authority. But can be done without server.

As the result, only one player at the time, of given session, need to worry about physics.

If you still locked on importance of determinism, in pool game, I suggest take few steps back and consider redesign.
Simply, you can not guarantee determinism across number of devices.
Best what you could do, is having fixed physics time steps, which is possible (not same as Fixed Update), using ints instead floats for maths calculations, or halve precision floats.
But that is already far more than you need for simple multiplier mechanics.

 

@Antypodish you said:

" As the result, only one player at the time, of given session, need to worry about physics"

This is true if the result of one simulation is slightly or not perceptive between players, becuase if I simulate something in one machine and the result is more or less different in another it could be terrible.

 

That why I repeatedly mentioning an importance of sync points. That will make sure, every networked devices in a session, have exactly same states. For such, is irrelevant weather physics is deterministic, or not.

Consider study FPS multiplayer games as an example. These are much more demanding, than simple pool game. Yet exist for decades.

 

I am currently working on a 3D simulation. I have tried various stuff mentioned here and there.
The simulation (as far as with unity 2019.2.5f1) is not deterministic even with:

1. the enhanced determinism, (Project Settings, enhanced PhysX simulation determinism)
2. auto simulation off and manual simulation with fixed time steps fed in (replace frame time variance with constant)
3. System.Random rather than UnityEngine.Random. (UnityEngine.Random is global RNG shared by everyone, resulting in time dependent RNG generation for multiple requests. (System.Random generates RNG as many as you want, hence can make it per-object to avoid request competition)

Floating point errors persist. More blatant form of errors however can be fixed by above.

 

Hi, by chance did you ever get an answer to this?
I was hoping that by now the Unity DOT physics or current physics would be deterministic.