[ODE] Stability problems

[gl]

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
>