[ODE] Stability problems

Thu Feb 20 09:54: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

If you use variable framerate... if a great big explotion makes your game
slow down from 75fps to 37½ you will have a problem and all physics will run
in slowmotion - but then you could do more steps....

Tobias

----- Original Message -----
From: "Royce3" <royce3@ev1.net>
To: <ode@q12.org>
Sent: Thursday, February 20, 2003 5:29 PM
Subject: Re: [ODE] Stability problems

>
> >
> >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
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>