Float calculations

[trying]

Quick Summary: I'm simulating a "throw" using a projectile equation to calculate an initial velocity for a 3d object (which is simluated in the bepu world as a cylinder). I then take this initial velocity and pass it another CPU in order to simluate the same throw on the opponents screen. The end point of the "throw" is off on the second CPU relative to the results on the first. Is this due to the different ways that different architures calculate floats? Any thoughts on how this can be corrected? Thanks in advance...

[Norbo]

Is this due to the different ways that different architures calculate floats? Any thoughts on how this can be corrected?

If the engine is running with multiple threads, then the broad phase, narrow phase, and solver need to have their AllowMultithreading properties set to false. For performance reasons, these three stages are nondeterministic when multithreaded.

If the engine is running sufficiently singlethreadedly and the starting configuration is exactly the same, then yes, it is probably architectural differences. A little extra information can be found here, if you haven't already seen it: http://stackoverflow.com/questions/6683 ... an-they-be

Solving this problem directly is a pretty huge pain. Fixed point math could be used to replace all the floating point math, but that would involve creating a new math library and replacing all the math used by the engine. Doable, but tedious and time consuming. The final result would be quite a bit slower too.

My usual recommendation is to implement a sort of replay-playback system. One system computes the simulation and records its state at a bunch of keyframes and then sends that replay data to another computer, which then plays it back. The replay fully defines the motion, so you don't have to worry about floating point nondeterministic butterfly effects. The keyframes can be compressed quite a bit to save bandwidth. This also gives you an easy framework for doing replays in general if your game/simulation needs them.

The replay-playback assumes something like a turn-based approach, of course- if it needs to be continuous real time feedback, then incremental corrections will be needed. Glenn Fiedler has a bunch of great resources about this sort of thing: http://gafferongames.com/