NewtonUpdate timestep value

[misho]

Hello all,

I am using Newton Dynamics (ver. 2.24) with the existing Flight Simulator engine to model spaceflight dynamics. Everything is going reasonably well, and I have a few quick questions:

I can query my FS engine and obtain instant FPS value fFrameRate. Is it then sufficient to specify my timestep as such:

Code: Select all

NewtonUpdate (g_world, 1.0f/fFrameRate);

Furthermore, my FS engine also allows for time compression and expansion, from 0.25x to 128x time factor value fSimSpeed. I would expect that I would be able to use it as such:

Code: Select all

NewtonUpdate (g_world, 1.0f/fFrameRate*fSimSpeed);

but I am not getting results I'd expect. Is it possible to do this? (the documentation says that large time steps result in instability).

thanks,
Misho

[Windrider]

I think Newton works best with a fixed timestep for its update.

There is an example of this in the tutorial, I pretty much copy pasted the demo technique in my application and the physics result were way improved.

I suggest you give it a look!

[misho]

Thanks, but that won't work in my case (I use the tutorial code extensively as well and have a pretty good grasp of it). My FPS value varies depending on the amount of graphics in the scene. I can get anything between 5 FPS to 60 FPS, which is anything between 0.2 and 0.0167 seconds timestep value. BIG difference. I cannot use the constant timestep value because if I do, the simulation will appear to speed up or slow down along with changing FPS and that's not what you want in a simulator.

The timestep parameter in the NewtonUpdate (I assume, and according to the documentation http://newtondynamics.com/wiki/index.php5?title=NewtonUpdate) was intended just for that purpose - to calculate the state of physics in the given time interval.

The documentation states that the timestep value is "clamped" between 20 and 600 FPS (0.05 and 0.00167 seconds). Looks like I'll need this "clamp" disabled, if possible, if I am going to be able to use the time speed up / slow down feature I mentioned in my original post.

Any thoughts, anyone?

[Windrider]

Well, the method I was talking about was actually to calculated the update value according to the FPS fluctuation. But maybe I am misunderstanding the issue then....

[Windrider]

Just in case:

Code: Select all

UpdatePhysics(float timestep)
{

   dFloat timestepInSecunds = 1.0f / MAX_PHYSICS_FPS;
   unsigned64 timestepMicrosecunds = unsigned64(timestepInSecunds * 1000000.0f);

   unsigned64 currentTime = dGetTimeInMicroseconds();
   unsigned64 nextTime = currentTime - m_microsecunds;
   int loops = 0;

   while ((nextTime >= timestepMicrosecunds) && (loops < MAX_PHYSICS_LOOPS)) {
      loops++;

      // run the newton update function
      if (!m_reEntrantUpdate) {
         m_reEntrantUpdate = true;
         if (m_physicsUpdate) {
            // update the physics world
            NewtonUpdate(World, timestepInSecunds);
         }
         m_reEntrantUpdate = false;
      }

      nextTime -= timestepMicrosecunds;
      m_microsecunds += timestepMicrosecunds;
   }

   if (loops) {
      m_physicsTime = dFloat(dGetTimeInMicroseconds() - currentTime) / 1000000.0f;

      if (m_physicsTime >= MAX_PHYSICS_LOOPS * (1.0f / MAX_PHYSICS_FPS)) {
         m_microsecunds = currentTime;
      }
   }
}


[misho]

Thanks again!

This cannot be code that calculates the timestep due to fluctuating FPS, because NewtonUpdate takes a timestep value of timestepInSecunds, which in turn is calculated based on a constant value.

The problem is, if you look at the code you posted, the passed variable "timestep" is never used. The timestep in this case is calculated internally for the purpose (I assume) of the demo. I, on the other hand, have a FS system that renders the scene and it tells me exactly how long it took to render it, and based on that time value, what the timestep should be.

I have to admit I am not sure what the code you posted is used for . There are a few defines that are set in the demos, for instance, MAX_PHYSICS_LOOPS set to 1, which makes the while loop run only once (again, not sure of the purpose of that).

[Windrider]

Due... what a dumb I can be sometimes! thanks to you as I have not remarked that yet! (beer coding )

Anyhow, the "timestep" should be exactly what you are saying, being the elapsedtime between 2 render. This piece of code is to be used with dHighResolutionTimer.h and uses the internal clock to insure that an exact amount of time passed by before it calls the NewtonUpdate.

It seems that this would work to insure NewtonUpdate is not called to often, at a fixed timing, but would not adapt if the FPS is lower then the preset update rate.

I indeed did not complete my work on this!

[misho]

No worries and thanks for your help. Perhaps Julio will be able to shed some light on the questions I have

Misho

[misho]

Further to my progress, I noticed that passing values of .25 or .50 for fSimSpeed (corresponding to 1/4 and 1/2 speed of simulation) DOES work:

Code: Select all

NewtonUpdate (g_world, 1.0f/fFrameRate*fSimSpeed);

... the sim slows down as it should. However, anything above 1 does NOT speed up the sim.

Speeding up (compressing) time is very useful in a flight simulator - it is used on long flights on autopilot, to compress long boring times, and, more importantly for me, it would be very useful in my spaceflight simulator, to compress time spent in orbit, when spacecraft is not manoeuvred, but only orbiting.

[Windrider]

One last comment before I give up!

I cleared away some stuff from that copy-pasted code a bit and:

Code: Select all

void CLScene::UpdatePhysics()// float timestep)
{
   
   dFloat timestepInSecunds = 1.0f / MAX_PHYSICS_FPS;
   unsigned64 timestepMicrosecunds = unsigned64(timestepInSecunds * 1000000.0f);

   unsigned64 currentTime = dGetTimeInMicroseconds();
   unsigned64 nextTime = currentTime - m_microsecunds;
   bool loop = false;

   while (nextTime >= timestepMicrosecunds)
   {
      loop = true;
      NewtonUpdate(World, timestepInSecunds);
      nextTime -= timestepMicrosecunds;
      m_microsecunds += timestepMicrosecunds;
   }

   if (loop) {
      m_physicsTime = dFloat(dGetTimeInMicroseconds() - currentTime) / 1000000.0f;

      if (m_physicsTime >= (1.0f / MAX_PHYSICS_FPS)) {
         m_microsecunds = currentTime;
      }
   }
}


where MAX_PHYSICS_FPS = 120 and m_microsecunds = 0 at startup, this definitely insure a fixed resolution for the NewtonUpdate. I insure that the time between both loop was at least timestepInSecunds, and if more than that, it will repeat the NewtonUpdate call to catch up which would occurs if the FPS is lower that MAX_PHYSICS_FPS.

[Windrider]

Your technique will indeed work but, any more experienced Newton user could confirm, this would not give a fixed FPS in the newton update which is less optimal.

Should you not multiply this with your timeElapsed of your render loop at least to have the result you'd expect?

[misho]

Yep - I'm doing that already :

1.0/fFrameRate is one frame render time, in seconds.

Unless I am doing something very, very wrong...

As far as optimal... if my FPS varies, I have no choice... and this would be the case for almost any visual engine where Newton is used for Physics.

[Windrider]

Oh indeed, your fFrameRate varies upon application FPS.

That should work then, cant see why it does not accelerate since simSpeed being over 1 should not work less then under 1, it is basically just giving Newton the elasped time value between both call.

And yes, Graphical app tends to have variable FPS, but a fixed time step is a concept encouraged by many.

Interesting subject! Can wait to see others answer on this.

[Windrider]

http://gamedev.stackexchange.com/questi ... -time-step

[misho]

It (probably) doesn't work because the documentation says that the timestep value is "clamped" (limited) to values between 20 and 600 FPS, or 0.05 to 0.00167 seconds. It seems that the physics engine becomes unstable at large timestep values. In my case, if I need to compress the time, then I need to calculate long durations between physics updates (up to 128x).

If I have a FPS of 60 (which is where my sim is at most of the time), that corresponds to 0.0167 seconds interval. With doubling the sim speed, I need to pass 0.0167*2, or 0.0333s, which is coming close to the 0.05 "clamp" limit (although, I am NOT seeing doubling of the sim speed, and I don't understand why... except if the clamp limit was changed or something)