Physx determinism

Physx is not deterministic when it runs with the same input on different architectures, it makes sense.
But does it make sense that Physx is not deterministic when it runs the same input on the same machine?! It does not sound right!

 

I'm not quite sure what you're trying to say but are your saying that you get a different physic result (different behavior of the rigid body ) every time you run your game?

 

indeed. I am saying exactly that.

 

As far as I know the problem isn't with PhysX as such but rather with the wrapper Unity puts around it which breaks determinism. In order for the physics to be completely deterministic then absolutely everything has to happen in the same manor, including the order of collision detection and resolution etc which will require everything to be added or arranged in memory in the same order. As far as I know, Unity's wrapper around the PhysX system makes it impossible for you to garauntee this.

 

I believe the physx engine itself is not deterministic. I remember reading something on a nvidia forum about it, and the engine isn't even intended to be deterministic... I don't think there is a way around it either.

Do you need to change anything in the scene that would affect the simulation? If not and you need the same simulation 100% of the time you could bake the animation externally and bring it in as an animated objected instead of giving it real time physics

 

I think the main problem it is practically impossible to make it completely deterministic.
The more the simulation runs, the more "errors" are introduced in it and each time, even on the same exact machine, cpu cycles may be distributed differently and so run the simulation in a slightly different way.
And more, if you run a complex simulation, there is the "butterfly effect"...

 

Deterministic physics require that you don't use fast linear equation systems on float base running on CPUs.
Thats practially impossible if you want to run larger scale systems performantly and don't want to go to the GPU to do it.

There are deterministic physics system but they are significantly slower, a price that needs to be payed for not being hit by float accuracy problems that get scaled up massively in linear equation systems due to the high number of multiplications and the often 'suboptimal' values pushed in

 

on the same machine a simulation should give the same result. The simulation cannot be cpu time dependent, the number of iterations should be identical for each simulation. So I believe it is due to the unity wrapper implementation than the physx implementation. Obviously float number errors are produced in the same identical way on the same machine with the same number of iterations.

 

I'm pretty sure it worked for me when I tried it before, but it was only in a prototype - there were no constraints and no collisions, for example. Still, I recorded user inputs and played them back, and my helicopter flew around exactly as it should have done.

Is it not working for you at all, or is there some specific event that's causing it to diverge?

Maybe this is obvious, but my only tip would be to make sure all your code which could modify physics state is in FixedUpdate, not Update.

 

yes we use fixedupate. Although I wonder if the deltatime between the fixedupdates is REALLY constant. The behaviour between our simulations is completely and totally different, although what we do is relatively crazy