Sunday, January 3, 2010

Integrator blues

So, here I am working on the Drive train for Rigs of rods and I've got a conundrum. My typical approach to forces and integrators is that when you add a force to an object you expect it to last for the size of the time step, any longer and what ever added the force needs to keep adding it. Perhaps I should still keep to that principle.

Here is my problem, I want to hide the integration stops from anything interacting with the integrator. This comes to be a problem (for me anyways) when getting into higher order integrators such as the Runga-Kutta K4 (4th order). It seams that any integrator higher than 1st order requires steps smaller than the given time step, for example, RK4 takes 3 extra euler steps for every integrator step, it takes two steps at half the time step, and one at the full time step.

lets setup an example:
class object {
    float force;
    float x;
    float v;
public: 
    //! apply constant force for the next integration step
    object() : force(0.0f), x(0.0f), v(0.0f) {}
    void applyForce(force(float force) { this->force += force; }
    void integrate(float dt) {
        x += v*dt;
        v += force*dt;
        force =0.0f;
    }
};
so say you have two of these objects coupled together by a spring (f = -kx) now RK4 is basically
  1. Get derivative @ t=0, k1
  2. Advance dt/2s using k1, get derivative k2
  3. Advance dt/2s using k2, get derivative k3
  4. Advance dts using k3
  5. Advance dts using a weighted average of the difference derivatives (k1 + 2*k2 + 2*k3 + k4)/6
Notice 2 half steps and 1 full step. When dealing with multiple bodies you can't run through steps 1-5 for each object, you need to do step 1 for all objects, steps 2 for all objects, etc.

Lets say you have a sim of with a time step of 0.001s, you have an external system that adds 100N to the object. the 100N is to be applied for 0.001s while the force from the spring needs to last for 0.0005s, then is recalculated again.

Perhaps, forces need to be distinguished between static forces and dynamic forces. Static forces are forces that depend on user input, for example a car engine, mouse movement, etc. Dynamic forces are the internal forces generated by the physics simulation. In other words Static forces are applied and last an entire time step, dynamic forces are calculated on the fly when requested.


Hmm, while typing thing I wonder an approach similiar to Ogre frame listener would be appropriate. calsses that effect an object can be registered as a "FrameListener" of sorts, there are calls to each listener that signal the start of the tiem step calculation, and one at the end of the calculations, and perhaps each intermediate time step when using higher order integrators.

Food for thought, but perhaps at a later time.

No comments:

Post a Comment