Euler integration again
Author
Explicit Euler algorithm:
x' = x + v * dt
v' = v + a * dt
Semi-Implicit Euler algorithm:
v' = v + a * dt
x' = x + v * dt
It was pointed out in an earlier thread that Explicit Euler might lead to stability problem because the x and v are stored separately this causing them to go out of sync. May I know if this problem still occur for Semi-Implicit Euler? Thanks.
Author
Any comments? Is the semi-Impicit really as good as the verlet as mentioned by one poster?
Quote:Original post by Mystery
Any comments? Is the semi-Impicit really as good as the verlet as mentioned by one poster?
Yes, it has similar behavior to Verlet. Something to play with:
struct IntegratorTest { IntegratorTest() { int count = 100; float x = 0.f; float v = 0.f; float a = 9.81f; float dt = 1.f/float(count); int i; printf("Euler:\n"); for (i=0; i < count; i++) { v += a*dt; x += v*dt; printf("V: %f X: %f\n",v,x); } // for printf("Velocity-less Verlet:\n"); float xc = 0.f; float xo = xc; for (i=0; i < count; i++) { v = xc - xo + a*dt*dt; // I compute velocity and store it. Useful in particle systems, collisions. Note no temp is required. xo = xc; xc += v; printf("V: %f X: %f\n",v/dt,xc); } // for printf("Euler - Verlet\n"); // My Euler-Verlet variant.// Optimal for simple fixed time-step simulation.// Allows excellent optimizations and improves overall code quality. x = v = 0.f; for (i=0; i < count; i++) { v += a*dt*dt; x += v; printf("V: %f X: %f\n",v/dt,x); } // for }} test;For more (stiff/spring) stability, you'll need to use a more complicated integrator (a velocity Verlet variant, RK2 (midpoint), RK4, etc.). For complete stability, an implicit integrator is required (LCP/optimizer, not trivial to implement). Implicit integrators tend to lose energy, acceleration can look strange (approximated/semi-linearized), and tend to provide damped, filtered motion (high-frequency behavior is lost, sometimes including lost precession behavior for rotational motion). However, implicit integrators can be totally stable, for just about any application, making them good for general purpose use. Additionally, there is ongoing research into improving implicit/optimization physics motion quality. If there is ever an OpenPL, it will probably be based on an implicit/optimization method. OpenGL and DirectX promoted graphics hardware. It's possible that Ageia will promote a standard "OpenPL" for physics hardware.
[Edited by - John Schultz on April 5, 2005 4:00:01 PM]
In case it was not clear why this variant is better:
It allows you to remove dt everywhere in your physics system, except when updating velocity (or momentum, depending on your implementation). Impulse calculations can be directly applied (no scaling by dt, as velocity/momentum is prescaled). Forces (and torques) are scaled by dt*dt (effectively converting them to impulses: a key feature). This is helpful when writing a physics system that treats everything as impulses (easier to debug and develop, makes friction and stable settling simpler).
// My Euler-Verlet variant.// Optimal for simple fixed time-step simulation.// Allows excellent optimizations and improves overall code quality. x = v = 0.f; for (i=0; i < count; i++) { v += a*dt*dt; x += v; printf("V: %f X: %f\n",v/dt,x); } // forIt allows you to remove dt everywhere in your physics system, except when updating velocity (or momentum, depending on your implementation). Impulse calculations can be directly applied (no scaling by dt, as velocity/momentum is prescaled). Forces (and torques) are scaled by dt*dt (effectively converting them to impulses: a key feature). This is helpful when writing a physics system that treats everything as impulses (easier to debug and develop, makes friction and stable settling simpler).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
