[ODE] Fixed stepping
gcarlton at iinet.net.au
Thu Aug 17 22:21:08 MST 2006
One thing to consider is whether it is at all feasible that ODE would be
made to work in future with variable time steps. This has come up
several times, but so far no real solutions have emerged. If a
hypthetical fix was created though, that would leave us with an
unnecessary logic loop inside the step function that we may no longer
want. Its hard to imagine variable stepping ever being as good as fixed
stepping, but who knows.
Another possibility is the whether different logic may want to be
applied by the application - for example, having the time delta within a
range, e.g. 0.08 to 0.12. The benefit could be that it avoids
"dropping" a step if our period is very close to exactly N step worths.
Any different logic would need direct access to the current solver
A third possibility is whether the application may wish to re-step the
collisions as well as the solver for accuracy. This implies fixed step
logic code outside the solver function.
For these reasons, I would think that the fixed step interface would be
better as a pure addition to the API.
In terms of implementation, it would also be simpler if the fixed step
loop logic was in one place, and it just called the relevant solver.
This is the reason I suggested a form of:
dWorldFixedStep(world, delta, period, steptype)
It is a nice clean new API that has the type as an enum, and leaves the
original solver code in place. Using SOLVER_LATEST means users leave it
up to ODE to worry about what solver is best, which is even simpler (is
"quick" quicker, or is "fast" the fastest..).
Lastly, regarding the API taking the number of steps as an integer
argument, that puts half the burden back on the application code - in
particular the logic of accumulating the unused delta from the last
frame and incorporating it into the new time delta.
Jon Watte (ODE) wrote:
> Geoff Carlton wrote:
>> I don't think its a good idea to fundamentally change the way all
>> existing (correct) code works, which may well be implementing fixed
>> stepping logic outside ODE. Two ideas:
> I actually think it is. This is SUCH a common problem, that we can
> break the code. It's not like it would be hard to fix in the cases
> where you actually want to compile something old.
> Btw: I think the world stepping function should take a world id, and
> an integer count of number of steps.
> / h+
More information about the ODE