[ODE] Stability problems
Royce3
royce3 at ev1.net
Thu Feb 20 09:37:02 2003
Just trying to understand something:
Is there a problem with setting a fixed timestep at program startup based
on the detected CPU speed?
Royce3
>
>Subject: Re: [ODE] Stability problems
> From: "gl" <gl@ntlworld.com>
> Date: Thu, 20 Feb 2003 15:55:47 -0000
> To: <ode@q12.org>
>
>
>The problem is that, as is outlined in the docs, two steps @ (say) 0.01 is
>_not_ the same as one step @ 0.02 - you will get different results.
>
>This affects you in two ways - if you want the simulation to stay completely
>consistent (particularly in a multiplayer game), you will have to run with a
>fixed stepsize and use the scheme suggested.
>
>Even if you don't have that requirement, it's likely that changing the
>stepsize frequently leaves thing less stable. I haven't tested myself how
>significant this is, but it will make some difference at least.
>
>Try running at the fixed size, and see if you can't find a value that works
>for your situation without eating too much CPU - at least see if it fixes
>the problems.
>--
>gl
>
>----- Original Message -----
>From: "Tobias Thorsen" <tobias@chaseace.com>
>To: "Jeroen Schmitz" <ode@q12.org>
>Sent: Thursday, February 20, 2003 3:29 PM
>Subject: Re: [ODE] Stability problems
>
>
>> Sounds pretty much like what i am doing now..
>> I dont like the idea of having to do many simulation steps for each
>frame -
>> it really slows things down. On my p3 800 mhz ODE uses between 3 and 7 ms
>> for a simulation step. I believe to have observed that it uses less time
>> when doing smaller steps, but it still adds up to a lot of time when doing
>> more than 2 steps pr. frame.
>> What i really dont understand is how i can get stability problems when my
>> game is running constant 75 fps, and the step size never exceeds 0.025 of
>a
>> second - also when nothing really crazy is happening with lots of
>difficult
>> collisions. Is the fact that the step size varies a bit from frame to
>frame
>> enough to make ODE unstable?
>> I dont want to do a step size of 0.0001 - that would mean i would have to
>do
>> 10000 steps pr second - more than 100 steps pr frame... would be very
>> slow....
>>
>> Tobias
>>
>>
>>
>> ----- Original Message -----
>> From: "Jeroen Schmitz" <ode@engine-software.nl>
>> To: <ode@q12.org>
>> Sent: Thursday, February 20, 2003 1:43 PM
>> Subject: Re: [ODE] Stability problems
>>
>>
>> > Matthews, Steve USA wrote:
>> > > Try making your world step time consistent and much smaller,
>> > > regardless of visual FPS, by using code like:
>> > >
>> > > ***********
>> > > int i;
>> > >
>> > > const static double WORLD_STEP_TIME = 0.0001;
>> > > int numWorldSteps =
>> > > (int)(systemTimeSinceLastFrame/WORLD_STEP_TIME);
>> > >
>> > >
>> > > for (i=0; i < numWorldSteps; i++)
>> > > {
>> > > collide();
>> > > worldStep(WORLD_STEP_TIME);
>> > > emptyContactGroup();
>> > > }
>> > >
>> > > double leftoverWorldStepTime =
>> > > systemTimeSinceLastFrame - numWorldSteps * WORLD_STEP_TIME;
>> > >
>> > > collide();
>> > > worldStep(leftoverWorldStepTime);
>> > >
>> > > emptyContactGroup();
>> > > **********
>> > > (Sorry the code is not ODE syntax, but this is what I'm using, and
>> > > it's pretty close)
>> > >
>> > > This will ensure that the step time in your world is consistent and
>> > > SMALL. There are numerous posts in the archives that cover these
>> > > stability (of the physics world) issues.
>> >
>> > Altough this method would indeed ensure a consistent step time, the
>> > disadvantage of this would be that on slower computer you would get a
>> > considerable extra amount of calculations. The problem I see with the
>> > solution above is that the lower your fps gets, the bigger the
>> > systemTimeSinceLastFrame value would be, which would result in an
>> > increasing numWorldSteps, which would in turn result in even poorer
>> > performance on such a slow system. I tried the solution above compared
>> > to a more frame-rate dependant step time and the result on slower
>> > computers wasn't good.
>> > The method I use comes from one of the ODE examples and uses half the
>> > frame time for the time steps (with a certain minimum value to prevent
>> > the time step from becoming too large, if the framerate would become
>> > really slow), taking two world steps per frame. This looks like this:
>> >
>> > dSpaceCollide (m_odeSpace,(void*)this,&nearCallback);
>> > dWorldStep(m_odeWorld, MIN(systemTimeSinceLastFrame/2.0, 1.0/15.0));
>> > dJointGroupEmpty(m_contactgroup);
>> > dSpaceCollide (m_odeSpace,(void*)this,&nearCallback);
>> > dWorldStep(m_odeWorld, MIN(systemTimeSinceLastFrame/2.0, 1.0/15.0));
>> > dJointGroupEmpty(m_contactgroup);
>> >
>> > Although this indeed has the disadvantage that on slower computers your
>> > step time increases, it gives you a lower performance impact if the
>> > framerate goes down.
>> >
>> > Jeroen
>> >
>> > _______________________________________________
>> > ODE mailing list
>> > ODE@q12.org
>> > http://q12.org/mailman/listinfo/ode
>> >
>>
>> _______________________________________________
>> ODE mailing list
>> ODE@q12.org
>> http://q12.org/mailman/listinfo/ode
>>
>
>_______________________________________________
>ODE mailing list
>ODE@q12.org
>http://q12.org/mailman/listinfo/ode