[ODE] Stability problems

[Tobias Thorsen]

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
>