[ODE] Infinite sliding... ?

[David Walters]

> Jon Watte wrote:

> I agree on the global function, although I think it should set a "time
> step" property on the world, not globally for ODE. Just like gravity is
> a property of the world.

Yes, that makes more sense!

---

> Jason wrote:

> This subject comes up a LOT. Would it be worth implementing a
> fixed-update loop within ODE itself? Something like
> dWorldStep(new_world_time, step_size) - which will step multiple times
> under the hood until it catches up with the world time?


Are you suggesting a helper function that works like this?:


dWorldStep(new_world_time, step_size)
{
     static old_world_time = 0;

     while ( new_world_time > old_world_time )
     {
         old_world_time += step_size;

        //  <== DO PHYSICS STUFF HERE

     };
}

If so, I think there's a danger here of creating an inflexible system
where you're forced into a way of working that is unhelpful. I might
just want ODE to step once and isn't having to work to defeat this
sort of timing system going to be messy? Timing code for a game loop
is quite complex and I think it's something that an advanced user
would want full control over.

The global world property approach isn't perfect, but I think it's a
helpful change because it sends a clear message to users that step
size isn't something you want to change often - at the moment it's
easily implied that you pass in delta-time and then your trouble
starts without a clear indication of that being the culprit.

We should definitly discuss this a bit more, but if everyone is in
agreement with changing to use "dWorldSetTimeStep"  I'll make this
alteration to the code, test programs and to the wiki.

I'd use a default of 60Hz which I think is appropriate as it's a very
common refresh rate for computer displays - thereby allowing you to
rely on v-sync for timing in the very early stages.

Regards,
Dave.


ps. Don't try and type formatted psudo-code directly into g-mail, it's
a pain :-)