[ODE] continuous forces w/ constant step size

[Jon Watte]

In my simile to your ODESystem, I also hook in all the 
user customization of the system. Parts of user customization 
is to add custom forces, setting joint limit targets, etc. 
This gets called for each time step, just like dWorldStep().

If you wire your ODESystem components to the UI such that 
they receive continuous signals (pressing key down will keep 
sending the signal until the key up event arrives) then you 
have a system that should behave "the same" with different 
frame rates -- with the one variation being that input lag is 
higher on slower frame rates.

Then you can capture and RLE compress the input with frame 
time stamps, and later play back the same input by keeping an 
eye on the time steps inside the stepping loop, and you have 
your recording system all done!

Cheers,

			/ h+


-----Original Message-----
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of Tyler
Streeter
Sent: Thursday, September 16, 2004 2:19 PM
To: ode at q12.org
Subject: [ODE] continuous forces w/ constant step size


So far I have been using the following type of loop in
my simulation:

while(1)
{
   getUserInput();
   addForcesToObjects();
   dt = getElapsedTime();
   physics.step(dt);
   redraw();
}
...
void PhysicsEngine::step(dReal dt)
{
   timeAccumulation += dt;

   while (dt >= STEP_SIZE)
   {
      //step ODE ahead by a constant value
      ODESystem.step(STEP_SIZE);
   }
}

This works well to make things move the same on
different machines (no slow motion on slower machines)
and to yield repeatable results (due to the constant
step size).  Additionally, it's nice to have this
iterative stepping loop hidden within the above "step"
function so the application can just pass in some
arbitrary dt.

Here's the problem with it: The continuously-applied
forces and the input only get updated once per frame,
not once per time step, which yields different results
depending on the frame rate.  These things need to get
applied per time step to get consistent results.

Assuming I want to keep the iterative stepping
function, here's a possible solution: calculate the dt
since the last frame, call some addForce wrapper
function that takes a force vector and a dt value,
update physics, redraw..  This addForce function
creates a "force event" that gets added to a queue,
storing the force vector and the amount of time it
should be applied.  Whenever physics gets stepped
ahead, each force event's time left gets decremented
until eventually they stop getting applied.  This
allows forces to be applied for some time into the
future which is helpful since you don't know exactly
how long it'll be until the next frame comes around.

Any comments?

Tyler


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 
_______________________________________________
ODE mailing list
ODE at q12.org
http://q12.org/mailman/listinfo/ode