Will the new Unity 5 physics be deterministic?

Just bumped into this nice article on Gamasutra on building a replay system and how to get around the non-deterministic collision physics in Unity.

So that got me thinking is the new Unity 5 physics system deterministic or have the option to be deterministic and therefore recordable and replayable?

 

Could you not just store the Game Object's position and rotation in an array every frame then iterate through the array and set it's position and rotation to those values? Maybe I'm misunderstanding what you're looking for.

 

From nVidia's knowledge base

 

reminds me of playing WORMS back in the day when you'd blow someone's worm into the ocean with a grenade. Then on the "instant replay" the worm would somehow not get blown into the ocean so he would still be alive the next round. :/

 

While that would probably work, that's going to be a huge replay file. Ideally, you could just record inputs and then run the simulation with those inputs, but that's no easy task because it at least requires floating point determinism, lest your simulation diverges.

 

Thanks for the link to the article. I've been thinking about this issue recently because I've been interested in implementing a replay system.

There was a talk on PhysX 3 in Unity 5 at Unite 2014. Here's the video:

If I recall correctly from when I watched it, the engine will be MORE deterministic than before, but still not fully deterministic.

It's an hour long talk. I thought it was great. And I thought the guy giving the talk, Anthony Yakovlev, was great. I'm hoping to attend Unite next year and I'm looking forward to saying 'hi' to him if he's there.

 

But what if you could put PhysX 3 into a deterministic mode or have it and Unity record and playback your gameplay within the game?

It would also be an amazing debugging tool, although it might require a 64 bit editor for replay storage.

 

If I understand the main challenges it boils down to the fact that using managed code and the CLR you are never going to be able to get floating point determinism in C#/Unity. You have to replace any floating point operation with a fixed point math system otherwise it will diverge, with the exception being if you are a console developer(like article you linked) where you know the same processor will be used for all players of your game(although not sure maybe even that is not enough with managed code). Things that use floats in Unity would include the transform component, physics, etc.

Some people have done some cool stuff with Unity and 2D determinism by replacing everything with fixed point and their own collision systems like Clint Brennan, good read on his method: http://clintonbrennan.com/2014/01/simple-2d-deterministic-physics-simulation/

 

I think you could be incorrect here as I believe the core of Unity and PhysX 3 is written in C/C++ and only the API interface to write scripts in Unity is via managed code (depending on platform e.g. WebGL, IOS).

Note also that it sounds like Unity are planning on using the technology they have developed to port code from Unity to WebGL (C# to C++ to Javascript) to bypass the use of Mono on other platforms.

 

you could basically roll your own physics simulation thats deterministic and sell on the asset store.

 

it doesn't matter what the underlying language is. A float is a float... an approximation. using a fixed point system would have to be implemented regardless, but you'd see inconsistencies in anything that was calculated in the gpu because it would still be floating point.

 

The C# isn't just converted to C++ source code to my understanding, but if it was and you had control of the C++ compiler flags I guess you could theoretically compile a binary that was IEEE 754 compliant for floating point operations. As Dustin points out anything on GPU will not be, including physics, no matter what. Here is a good stack overflow discussion on C# and determinism and why they can't be due to the CLR: http://stackoverflow.com/questions/...s-consistent-in-c-can-they-be/6685966#6685966

 

OK let's forgo determinism then, I get it we're dealing with imprecise floating point numbers in a variable time stream trying to represent/simulate real numbers in real time.

Or the butterfly flapping it's wings causes a hurricane on the other side of the level (or in Unity once you get past 10,000 units range).

However if PhysX 3 was able to stream the physics changes to objects and Unity was to capture and time stamp this information then quite a realistic replay of events could be redone. The goal would be to capture the changes through collisions accurately and probably the best place to do that would be in PhysX code base.

 

This is what I thought, fixed point arithmetic was the basis of deterministic calculations across different platforms and architectures. Probably using 64-bit integers for todays physics in order to use 32-bit or 48-bit widths.

 

Which, for the record, isn't a problem. Deterministic systems using float's have been built and used in the past.

-----

Building deterministic physics is *hard* and the resultant code runs slower. Furthermore deterministic physics isn't a required part of making a deterministic game, nor does have deterministic physics in and of itself make a game deterministic.

As such I doubt Unity will implement it.

 

Anyone following here might also be interested in this thread I posted after watching a Unite presentation on the input recording/playback system developed for Shogun: Total Wars Battles.

 

This ....