Physics, fully deterministic?

[wickedshell]

Are physics simulations deterministic? IE assuming 3 different machines are all maintaing the same physics framerate, and given the same set of objects to work on, are the results compltely deterministic? (And assuming they are deterministic, I assume if one client drops a physics frame (or gets cut off early) the results are unspecified?)

[ulf.schroeter]

Don't expect determinism on distributed physics simulations. For some fast paced effect physics (e.g. Debris in an explosion) the differences might not be a problem, but for game objects you will run into all kinds of uncontrollable issues. That's the reason why games use server-side physics and then propagate resulting state e.g. position/rotation to all clients for a synchronized game world state

[alexander.zubov]

that's the reason why games use server-side physics and then propagate resulting state e.g. position/rotation to all clients for a synchronized game world state

 

Is it something Unigine provides or do we have to code that as part of the game logic using UnigineScript ?

[ulf.schroeter]

Unigine script code can be taken from network samples and adopted to own needs

[alexander.zubov]

what I meant was if the engine handles all that or the propagation and syncing should be coded in the script for each individual case?

[ulf.schroeter]

The latter

[wickedshell]

I know the physics for game objects has to be enforced by the server, it was more a question about the potential to reduce update frequency, and replay scenarios in a repeatable manner.

[ulf.schroeter]

I know the physics for game objects has to be enforced by the server, it was more a question about the potential to reduce update frequency

 

Have a deeper look into Unigine network scripting code. I can remember there was already some support for client-side position/rotation extrapolation based on previous position/rotation states. This might be the way to go if you want to reduce network update frequency

 

and replay scenarios in a repeatable manner.

 

Unigine physics engine supports - and I think this is quite a unique feature - physics state save/restore. There are some physics samples showing this feature. Could be used for server-side replay as shown in these videos

[manguste]

To add to Ulf's explanation, physics is Unigine is fully non-deterministic (even on one and the same machine). So basically, if physics affects the gameplay there's no other way than to calculate it on the server side.

//Our network developer is currently ill, maybe she'll provide more details later on.

[Guest anet]

If you need deterministic behavior on different computers you should not rely on physics. It is better to calculate everything in script.

 

But even this solution will not guarantee fully deterministic behavior because of floating point calculations.

 

You also might be interested in looking at this sample from our SDK: data/network/samples/replay

[dave.lannan]

Ok. I'd like some clarification here. It seems some people are talking about network distributed physic's synchronisation and some are talking about whether the physics system is deterministic from a time frame perspective. I would very much _hope_ that Unigine's physics system uses time step integrators and thus when you run the physics on one machine, the _end_ result, is identical to another machine. If this is not the case - why oh why?

 

If your integration is broken, the you are saying something like: my physics velocity calculation for time T will not remain the same depending on where I run it??

 

For distributed / shared physics, this is more of a state management issue and more about managing how you keep your objects synchronised. You should still have determinism within your physics system but it takes a little more to synchronise this across multiple clients.

 

Please tell me your physics is deterministic?

[ulf.schroeter]

http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/

[dave.lannan]

I cannot read that page (our company has it blocked), but it refers to network based physics determinism and floating points. I'll make some simple points about physics and floats. If you have a set of errors on one machine for an algorithm, as long as the errors are replicated on the other machine the same way, your physics should still remain deterministic - but with error. This is still _fine_ because its a known amount that you can take into account for. We have been putting simulators together for many years now, and to do any sort of synchronized simulated environment all calculations need to be deterministic so that they can be repeated exactly. Floating point (IEE 754) is a standard that ensures consistency across platforms, if you are seeing differences in platforms then its the implementation not the physics system that should cause problems.

 

The simple concept still holds. My physics for calculation of velocity should be consistent across all machines with the same code set. How those machines are synchronized is an utterly different problem, but the physics on each should be repeatable and consistent for any time T. Otherwise the physics has been implemented incorrectly.

Cheers,

Dave

[dave.lannan]

Another note about "games using server-side phsyics". This is very rarely the case that a complete physics state machine is propogated to a client state machine. The most common (modern) methodology is to have a server 'master' physics system that has historical buffered state snapshots (usually high level controller states) that sync regularly with the client side physics system and keep game elements in check. This is to ensure that the client side always feels 'smooth'. If the client had to propagate its local physics states up to the server, wait for the server to collate the physics states of all other clients, and then propogate that all back down, your physics feedback would be horrible (massive latent loop) - classic case, is driving a vehicle. Nearly all of this is done client side, and only a basic sync is done with the server. Other methods use peer-2-peer syncing like we did in our rts 10 yrs ago, where you propogate high level state information like "Move units along this ai path to time T", which would crunch down into a couple of paramters to move a group of units and each client would share this with each other. Every now and then (usually around a second) a sync check is sent around where the clients in the the peer-2-peer validate state updates and do a check that they match their counterparts, and then continue onwards processing local physics operations. When you have 16 players, and 100 units each then you cannot afford to send the physics of every ojbect around every frame.

 

Hope that helps out.

Cheers,

Dave

[dave.lannan]

Im bumping this again. There are two comments from Unigine developers that claim the physics is inconsistent across machines? If this is the case, then we cannot use any of the velocity/acceleration mathematics in the physics system?

Please clarify this. This concerns me the most "To add to Ulf's explanation, physics is Unigine is fully non-deterministic (even on one and the same machine)."

 

I would like a definite - is this correct or incorrect? If it is correct then physics just should not be used. Because you are effectively saying the physics is random, which is simply not useful for games or sims.

Cheers,

Dave

[manguste]

Yes, physics is non-deterministic in Unigine. The result of floating point calculations will vary to some extend on different machines due to different CPU architectures, compilers, and optimization settings. Not only that, each time the world is loaded bodies are sorted in a different order, hence the different results.

 

What this does mean is that you will get APPROXIMATELY the same result, within some tolerance. So if you set velocity for a moving unit (with body and shape), it will get to the destination point on different machines, but a bit earlier on one and a bit later on another.

 

This is a common practice for physics - for example, PhysX and AFAIK Havok are non-deterministic as well. IEEE standard results in significantly lower floating point performance. You can script your app logic and use only integer math, or only doubles if you want ironclad guarantee of reproducibility.

Edited February 29, 2012 by manguste

[dave.lannan]

Ok. I think I can guess what Unigine is doing. What you are effectively saying is that you are not using a constant time-step integrator in your physics? This is again nothing related to floating point or architectures etc. You are doing what most game systems and sim systems DONT do. Having used a very many game systems (from PowerSlide Engine, to Dark Reign 2 Engine, to UDK to Vega Prime and many others) over the last 20 yrs most use a fixed timestep integrator so that when the timestep for the physics (regardless of frame rate or CPU speed) changes by a fixed amount on _any_ machine it is an identical result (regardless of how long it _actually_ takes in realtime - because the realtime as far as a sim or game is concerned is the correctly _calculated_ one). When you try to use a floating timestep integration you change the outcome of the physics functions (because fine delays can result in differing output) and this results in non-consistent physics. Based on my game and sim experience - this is a bad thing to do and is generally not ever recommended for a stable physics system - this is why you use fixed timesteps in PhysX. If you use floating timesteps expect problems.

 

This is nothing to do with floating point, compilers etc. This is a limited implementation of physics. That simple. I would warn people who are doing sims, to simply not use this physics system because it will cause you sync-hell when you try to validate your sim units.

 

On the matter of floats - "IEEE standard results in significantly lower floating point performance." I really dont understand this. You do realise that nearly every piece of CPU hardware these days (with the exception of NDS - idiots! and a handfull of phones) has IEEE 754 hardware in it. It covers 8, 16, 32, 64 and other implementations of floating point. 32 bit float has been around since 8087 days. And most modern ARM chips have it as well. This standard is in hardware, so compared to what other floating point format in hardware is it slower than?

http://en.wikipedia.org/wiki/IEEE_754-1985

 

"You can script your app logic and use only integer math, or only doubles if you want ironclad guarantee of reproducibility." So you are saying you can make your physics deterministic? Or not. I have written deterministic physics systems in fixed point int for pinball games on GBA up to 128bit double physics for PS2 and MIPS on SGI boxes and the representation of the data has no bearing on whether an algorithm is deterministic or not. It generally determines the error level of the integration step.

 

V = Vo + a * T

 

This algorithm should hold _regardless_ of platform, compiler, etc etc. This is a physics algorithm for calculating the new velocity. None of what you have said, leads me to believe this can possibly be different across hardware without some incorrect implementation. So. We will agree that the Unigine physics system is not stable and unable to provide consistent results.

 

Btw. this comment: "Not only that, each time the world is loaded bodies are sorted in a different order, hence the different results.". Has helped us solve another issue - we cannot exactly repeat the AI path finding along NavMeshes and so we cannot implement our replay system with this setup. So it looks like a number of features for Unigine are going to need to be disabled for our sim.

 

I do hope that your physics isn't like I described, but it seems otherwise.

 

Cheers,

Dave

[ulf.schroeter]

The discussion is getting more and more useless

 

- read the documenation, Unigine is using fixed timestep integration decoupled from rendering frame rate https://developer.unigine.com/en/docs/1.0/principles/physics/

 

- read the provided link, read other articles on the internet, read about optional IEEE float format handling of hardware and learn that most physics engine, dx9/10/11 optimizing compilers etc deactivate it due to significant performance degradations, that used SSE vector instruction sets are not IEEE conformal, ..., ...

 

- read about Vortex physics engine, which claims to provide "lifelike, repeatable behaviour for accurate real-time applications such as operator training and virtual testing" and be prepared to spend all your money on licencing

 

- try writing your own "fully-deterministic" physics engine and learn the difference between theory and practice

 

- ....

[dave.lannan]

Thanks for the update. Having written a number of verlet physics systems, and other types, for multiple platforms as well as dealing with numerous physics systems on platforms from SGI, PS2, PS3, XBox, Win, Linux and others. Im talking from having experience in the simulation business and the game business.

 

I really dont care what you are trying to claim. But ANY algorithm that when run on THE SAME MACHINE twice, should OPERATE THE SAME. This is utterly regardless of what the math is doing unless you are using a random input. My simple statement still holds: We need to apply a velocity - Vn = Vo + a * T should be consistent on THAT machine everytime we run it.

 

We were TOLD. by Denis, and others in a conference call last year that your physics was deterministic. We needed this, because we have training simulation requirements that mean we need to be able to _exactly_ replay our scenarios. And, according to YOUR documents it states in the "SIMULATION OF PHYSICS" content section that:

 

"Unigine physics is deteministic. Bodies, shapes and joints are sorted inside islands. By that, we ensure that contacts will always be solved in the predefined order and visualization of physics in the world is fully repetitive (one one computer)."

 

This is why we are needing clarification. Because it seems even you are not certain on whether the engine is or not. If it isnt, then we will use our physics systems that ARE deterministic. In the simulation business (and games) it is extremely important to have deterministic systems in use so that state management is properly defined. Otherwise problems with game state saving, replay, and AI control become extremely difficult to solve with proper consistency. I'm disappointed that what we have been promised earlier last year has been delivered with this many issues.

 

We will move forward using our external systems. Thanks.

Dave.

[ken.mayfield]

We needed this, because we have training simulation requirements that mean we need to be able to _exactly_ replay our scenarios. .

 

We do exactly this in our iOS game Demolicious. Every time the cannon shoots, we record the entire scene, so if the player wins with that shot... we can play back the scene EXACTLY as it happened from many different camera angles to show them what destruction they have caused. Look at their time reverse demos, that is the feature you're looking for.

 

In the case that you're looking for physics to play exactly the same during every playthrough, you are probably out of luck. I have not seen this on a single physics engine to date.

[ulf.schroeter]

The time reverse functionality will not solve continuous multi-machine synchronous calculations without server-side state management. Nevertheless perfect for your short-term replay.