[ODE] dWorldStep() on non constant frame rate

[Thomas Harte]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--=_NextPart_Lycos_0151391040223648_ID
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>I use your great physics engine for a little game I made. I have a
>really strange problem, my loop is like that:
...
>   dt = lasttime-newtime;
>   dWorldStep(dt);
...
>
>But the server, sometime slowdown a lot and the dt can be 100ms and some
>time, it near 300ms for one or 2 loops. So we call dWorldStep with 0.3.

What I do is decide exactly how many physics updates I want in a second, and 
effectively work out how many whole ones of them have occurred during the last frame. 
So, e.g.

const int MsPerPhysicsUpdate = 5; //200 physics updates per second
int NextUpdate = 0;
...
dt = lasttime-newtime;
NextUpdate += dt;

while(NextUpdate > MsPerPhysicsUpdate)
{
   /* generate time dependant constraints here */
   dWorldStep( (dReal)MsPerPhysicsUpdate / 1000.0);
   NextUpdate -= MsPerPhysicsUpdate;
}
...

This works quite well - it means I can be sure my physics act exactly the same 
independant of the frame rate, although it does lead to some odd distortions of time if 
you have MsPerPhysicsUpdate set quite high.

An alternate method I have also used involved pretty much the same thing, but 
MsPerPhysicsUpdate was taken as a maximum, and NextUpdate was not accumulated 
from one frame to the next. So, instead I had something like :

const int MsPerPhysicsUpdate = 5; //200 physics updates per second
...
int ThisUpdate = 0;
ThisUpdate = lasttime-newtime;

while(ThisUpdate > MsPerPhysicsUpdate)
{
   /* generate time dependant constraints here */
   dWorldStep( (dReal)MsPerPhysicsUpdate / 1000.0 );
   NextUpdate -= MsPerPhysicsUpdate;
}
/* generate time dependant constraints here also */
dWorldStep( (dReal)ThisUpdate / 1000.0);
...

This prevents any 'distortion of time' at high values of MsPerPhysicsUpdate, and means 
you can ensure the integration is _at least_ as accurate as a certain minimum, but then 
creates some issues through not being sure exactly what the physics update is.

By the way, if you are running the same simulation on multiple boxes and expecting to 
get the same results, you might be surprised since different brands of CPU (particularly 
in terms of intel vs Motorola, but also intel vs AMD, etc) can result in different levels of 
floating point accuracy, even for the same size of dReal, and in fact I believe that intel 
type CPUs have a particular flag which may be set depending on how accurate you want 
your floating point results which different versions of Windows make different decisions 
about setting.

Obviously these differences in result are tiny, but they can accumulate, so you at least 
want to be running an explicit state synchronisation scheme of some sort, e.g. every 
frame having one machine explicitly dictate the state of a particular body or island to all 
the others.

-Thomas

When words aren't enough - Vodafone live! A new world of colour, sounds, picture messages and information on your mobile. <a href="http://ad.doubleclick.net/clk;4909903;7724245;q?http://www.vodafone.co.uk/live">
Click here</a> to find out more.


--=_NextPart_Lycos_0151391040223648_ID--