[ODE] Fixed stepping

[Geoff Carlton]

Hi,
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 
functions.

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.

Geoff


Jon Watte (ODE) wrote:
>
>
> Geoff Carlton wrote:
>> Hi,
>> 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.
>
> Cheers,
>
>          / h+
>
>