Fixed timestep but Different results.

[Crashy]

Hi,
I'm experiencing a strange problem, having different results when the framerate change, although I do fixed time step updates of newton.

Basically, having an object of 3000 units of mass, dropping it from an altitude of 1382 and waiting 60 seconds, with a gravity acceleration of 9.81 m/s², I have these results:

At 120 fps, the object falls to -3301 units.
At 71 fps, the object falls to -8872 units
At 20 fps, the object falls to -13015 units.

The physic step is set to 100 updates / second, and for all tests, at 60 seconds, ~6000 updates have been made (+/- 2 updates).

So I don't understand where the problem comes from, as the same count of fixed time steps have been made, my object should reach the same position, whatever the framerate is. And the difference is really huge.

Note that the linear and angular frictions are both set to 0.

I've tried with 1 or two thread, same result. Would disabling sse or anything like that change something?

Thank you very much.

[Sweenie]

Can you post the code that handles the fixed update?

[Edit]
Just tried it myself and regardless of frame rate and fixed timestep(tried with both 60 steps/sec and 100 steps/sec) the body always falls a bit over 17000 meters(with linear damping set to 0) which should
be close to the distance a body would fall (in perfect vacuum) in real life.

What version of Newton are you using and are you absolutely sure you set the Linear Damping to 0?

[Crashy]

I'm using a revision of Newton 3 dating of 03/15/2013, cannot tell the exact revision as the repository was reset a few weeks ago.

The code doing the timestep is this one, it's the one from ogrenewt

Code: Select all

//t_step is the delta time between current and previous frame
//m_timestep is the fixed time step == 1/100
// clamp the step if necessary = fps < 10
   if( t_step > 0.1f)
   {
      if (t_step > (m_timestep * m_maxTicksPerFrames))
      {
         t_step = m_timestep * m_maxTicksPerFrames;
      }
   }

   // advance the accumulator;
   m_timeAcumulator += t_step;

   while (m_timeAcumulator >= m_timestep)
   {
      NewtonUpdate(m_world, m_timestep);
      m_timeAcumulator -= m_timestep;
      realUpdates++;
   }

You recognize a code strongly inspired by the gaffer's post on his blog.
And yes, I'm sure at 100% the linear damping is set to 0.

[Julio Jerez]

a simple In free falling body should have the same behavior regardless of threads count or simd.

The one thing that I made starting with core 306 is that newton now uses SIMD unconditionally. I fused the simd class with the dgMath, therefore everything is either simd or not.
The problem with having two separate classes that do the same thing, is that it force you to keep two code bases, and as the engine get more features or gets older this is much harder to maintain.
All code in the engine now is SSE but you can still use scalar x87 arithmetic by defining DG_SCALAR_VECTOR_CLASS as a compiler command line preprocessor.

we do have to face reality and accept that SSE, multicores and high performance computing are here to state, and none of those thing are friendly to deterministic physics updates.
If we keep guaranteeing determinism, then we are condemned to always run one a single thread with scalar arithmetic and no chances to ever use GPU computing.

[Crashy]

Yes I'm aware of all these problems
I was just asking if multithreading or sse could have an impact on the results because I'm out of ideas to solve this problem, but as you say, it may not have any influence for a simple falling body.

[Crashy]

Okay, I've found the bug. This was completely my fault, due to a bad recursive call.

To be clear, at each each frame end, I update the position on my visual object with a little interpolation. But this update, due to a small reentrant call, also reset the position of the newton rigid body. This was a major flaw in my game, I even don't know why I haven't seen it before.

Sorry for the trouble.