Simulating motion

Every game that moves a character, every planet in a space simulation, every cloth that drapes, is really just $a=F/m$ stepped forward a tiny slice of time at once. Get the stepping subtly wrong and orbits spiral into the void, characters phase through walls, and stacks of boxes explode. This is where physics becomes code.

We ended the force lessons with a rule: find the acceleration from the forces, then push velocity and position forward one small timestep. Doing that stepping is numerical integration. A computer cannot glide along the true smooth path; it can only take finite hops. How you take each hop is a real choice, and the choices behave startlingly differently.

Play first: one orbit, three ways to step time

The same body orbits the same central mass in all three panels. The only difference is the integration scheme. Press Run, then drag dt upward. Watch the energy trace under each: only the red one, explicit Euler, climbs away and sends its orbit spiralling out. The other two hold.

Unrolling the loop: where the energy leaks in

Start from the obvious loop. At each step, read the acceleration from the current position, then update velocity and position with the values you have. Written the most natural way, that is explicit Euler.

def explicit_euler(pos, vel, dt):
    a = accel(pos)            # acceleration from the CURRENT position
    new_pos = pos + vel * dt  # move using the OLD velocity
    new_vel = vel + a * dt    # then update the velocity
    return new_pos, new_vel

The flaw is hiding in plain sight. It moves the position using the old velocity, the velocity from before gravity had its say this step. For a curving path that old velocity points a hair too far outward, so every step nudges the body slightly farther out than it should be. Those nudges accumulate as a steady gain in total energy, and the orbit winds outward. The total energy should be constant; the method does not know that.

The one-line fix: use the velocity you just computed

Now move a single line. Update the velocity first, then move the position using that brand-new velocity. This is semi-implicit Euler, the workhorse of nearly every real-time physics engine.

def semi_implicit_euler(pos, vel, dt):
    a = accel(pos)            # acceleration from the current position
    new_vel = vel + a * dt    # update the velocity FIRST
    new_pos = pos + new_vel * dt  # move using the NEW velocity
    return new_pos, new_vel

Verlet: remember the past, run time backward

We can do better still. velocity Verlet advances the position using the current acceleration, then updates the velocity with the average of the old and new accelerations. That symmetry makes it time-reversible, which is why its energy trace is the flattest of the three.

def velocity_verlet(pos, vel, dt):
    a = accel(pos)
    new_pos = pos + vel * dt + 0.5 * a * dt * dt   # move with current accel
    a_new = accel(new_pos)                         # accel at the new spot
    new_vel = vel + 0.5 * (a + a_new) * dt         # average the two accels
    return new_pos, new_vel

This is the fusion the whole module was building toward. Motion is a = F/m; simulating it is a loop; and the character of that loop, energy that leaks, holds, or barely drifts, comes down to which line you write first. Physics and code are the same object here.

Check yourself