Is Burst going to provide a fully deterministic physics engine using fixed point or something that is just as solid?
Burst is a compiler. It translates C# ILM code to optimized machine code (assembly).
The Entities package allows you to use the new DOTS-enabled physics engine which is deterministic. To use it, you must subscribe to the Entities programming paradigm however.
To be clear, the existing internal 2D/3D physics engines are deterministic. The only indeterminism is floating-point handling which the DOTS physics engine suffers from too.
So deterministic yes but not fully determinisic. 
But it wasnât always fully deterministic, right?
Or maybe that Project Settings flag continuous to mislead devs since it implies that even with the flag checked, it wonât be 100% deterministic:
âEnhancedâ means âbetter but not perfectâ. 
The main problem is that determism is discussed without qualfying it. The physics engine doesnât add random elements so if you do the exact same thing on the device then it will always be the same next time.
The problem here is that devs might do things like destroy an object then create it and move it and expect it to react the same. Itâll react the same as you did during the last time you started the game but it wonât necessarily react the same as the previous object you destroyed. All this is because of state. Different order in the broadphase, order of contact processing etc. You can improve determinism to handle these kinds of cases.
Itâs not misleading, itâs using the word determinism without context. In most cases, when itâs discussed, itâs referring to deterministic across devices.
To clarify something. One thing that the internal 2D/3D physics engines do are fully destroy the physics worlds when a new scene is loaded, if there are no objects left (DontDestroyOnLoad). This means that the new scene will get loaded the same (order-wise) and everything will always be the same with no side-effects of an existing broadphase or any other dynamic state.
You could say this improves determinsim.
Personally when I discuss determinism Iâm ususally referring to float point arithmetic. Which can be different across devices.
This difference (in evaluating calculations with floating point values) can often be found across the range of devices, which is why we would then refer to something being ânot deterministicâ.
Thatâs what I was referring to.
So how would you interpret this when weâre talking about multiple different sets of hardware?
I donât understand what youâre asking me, Iâm not interpreting anything. I was merely stating that you can improve local determinism. Itâs not all or nothing was my point.
I stated above that often, when devs say âdeterminismâ, they are referring to the same results on multiple devices. Right now, the biggest issue is FP handling.
That has not been solved yet via Burst for HPC# so all existing physics engines from Unity are not 100% deterministic across devices. That is not to say they are not deterministic on the same device given the same set of inputs.
This was what I was looking for⌠I think that that was what @CodeSmile was also referring to with âfully deterministicâ.
Yes, fully deterministic. The thing is, even that has interpretations as I alluded to above regarding game-play changes.
You can write a (say) fixed-point physics engine and still not get determinism as you interpret it because things behave differently during the gameplay because of order of operation changes. Theyâll always react like that from session to session but during gameplay, two things might act differently. You can improve/solve this to stop order of operations being able to cause changes. Often this is at cost, mostly sorting etc. You can get this too with multithreading but again, there are ways to mitigate this, hopefully at a zero/low cost.
100% fully deterministic that can have improved determinism added to it. Sounds crazy!
I had to read your post more than once to understand what you wanted to sayâŚ
So not deterministic.
Are you saying here that it is literally impossible with the unity game engine to develop a fully deterministic game due to the unity engine itself introducing random order of processing? (I mean even if we turn off the physics engine and use fixed point math ourselves?)
No, I didnât say that. I also donât want this thread to become asking me about all the ins and outs of software determinism because thereâs plenty of great material online about it including lots and lots of posts about Unity doing a better descriptive job than I ever could! I think this one is a great article because itâs concise and clear but obviously there are lots of others.
But ⌠given a fixed set of inputs, Unity (not simply physics) should produce the same results on the same device. There are obvious exceptions such as multithreading which requires you to be careful about handling data order to give consistent results.The Job system can help with this if youâre simply dishing out segments of an array to be handled on different threads as the data order isnât changed but other ways of handling data where itâs collated at the end of the job requires specific steps such as sorting.
Itâs been said before but anything that doesnât adhere to this should be considered a tentative bug, for instance, objects being activated in a different order when loading a scene can have consequences to determinism and other stuff. Unity should not do that kind of thing!
Itâs a complex subject that is hillariously condensed down to a single word âdeterminismâ.
Hi, sorry to wake up an old topic. But can I just check:
Given that the biggest issue is FP handling, if the PhysicsEngine adds/multiples lots of FPs together (which I assume it does) isnât that inherently undeterministic even on the same machine, even with the same inputs?
For example, just adding 0.000001 to itself one million times is not guaranteed to equal 1 every time.
Floating point yes
Fixed point no
He specifically brought up fixed point to make his case that other factors were in play that could thwart the benefits of using fixed point to ensure full deterministic.
Thereâs plenty of material online to understand what you mean by âFP handlingâ. It certainly doesnât mean that a piece of hardware is somehow random in how it handles floating-point, itâll always give you identical results.
If you want to know about 2D physics and determinism, Erin Catto recently posted a great article on his blog: Determinism :: Box2D
FYI: Integrating Box2D v3.x into is currently WIP: https://youtu.be/ksKVvwvpXX4?si=GHhck53lSNhIIarv
Curious example. I think this is not true if the number you start with is always the same. Count up from 0 and youâll reach 1 every time. But you may not get there from other numbers, say 12345 + 1 million times 0.000001 may read out as 12345.9999998 but it will always be the same result when starting to count from 12345 (but not necessarily on every platform).
Well, this most likely would not count up at all as the relative exponent differences are too great. C# Fiddle example. A float has only a fix number of significant digits. The more digits are needed before the decimal point, the less are available behind the decimal point since itâs a âfloating pointâ. A 32 bit float only has about 7 significant decimal digits (24 binary digits). I once created this table to show how the minimum representable number changes as the numbers get larger.
In your example 12345 would be in the range 8k-16k, so the smallest possible change would be about 0.001. Anything smaller is most likely rounded to 0. Though thatâs all just normal FP mechanics and is still consistent on the same device. This change in behaviour due to the size of FP numbers is also the reason why you can never get consistent results when you use Time.deltaTime. On a machine that runs at 1000fps you would hit certain limits earlier than on a crappy device that runs at 30fps.