Rendering a black hole, the Interstellar way

A geodesic is the straightest possible path through a space. On a flat sheet of paper that's an ordinary straight line. But on a curved surface, "go straight ahead and never turn" produces something that looks bent from the outside. This is why long flights take those strange-looking arcs on a flat map: the great-circle route over the globe is the actual straight line; the map is what's lying.

Here is the part that makes gravity click. Imagine two ants on a ball, starting a little apart on the equator, both walking perfectly straight "north" — neither ever steers. They start out parallel, yet they drift together and collide at the pole:

Einstein's idea was that gravity works the same way. A mass like a black hole curves the space (and time) around it, and everything — planets, spaceships, light — just keeps going "straight ahead" through that curved geometry. Nothing tugs on a photon; the photon never turns. The road itself is bent:

And "null"? In relativity, the "distance" between two events mixes space and time, and it has a quirk: along anything moving at exactly the speed of light, that spacetime distance works out to zero. Physicists call such paths null. So "null geodesic" is just compact jargon for: the straightest possible path, traveled at the speed of light — in other words, the route a ray of light takes. That's all the renderer computes, once per pixel.

Because it is one. If you have ever written an orbit toy — planets attracting each other with pos, vel, acc and a little integrator — the shader loop is exactly that program. Compare:

// Newtonian gravity (a planet in a game):
acc = -G * M * pos / pow(r, 3.0);    // pull toward center, strength ∝ 1/r²

// Schwarzschild photon (this renderer):
acc = -1.5 * h2 * pos / pow(r, 5.0); // pull toward center, strength ∝ 1/r⁴

Same loop, same integrator, same cross and dot products. The only difference is the exponent and the per-ray constant h². So where did all the geodesic machinery go? It got compiled away, in three steps:

Step 1 — geodesic equation. "Straightest path through the metric" is, concretely, a differential equation: it tells you how a path's coordinates (t, r, φ) accelerate as you move along it. Written out for Schwarzschild it's a messy coupled system — nothing you'd want in a shader.

Step 2 — conservation laws shrink it. The metric doesn't change with time or with angle, and each symmetry hands you a conserved quantity (energy, angular momentum) — the same reason cross(pos, vel) stays constant in your orbit toy: a pull pointing straight at the center has no lever arm to apply torque. Using the conserved quantities to eliminate variables, the messy system collapses to one ODE for the orbit's shape, r as a function of φ. The u = 1/r substitution is nothing deep — just a change of variables that makes the ODE almost linear, the same instinct as switching to log-space when it makes the math cleaner. That one-liner is the Binet equation above.

Step 3 — reverse-engineer a force. Now ask a programmer's question: "what acceleration field acc(pos), in ordinary flat xyz space, would make particles trace exactly these curves?" For any central pull there's a standard recipe linking the force law to the orbit ODE, and running it backwards on the Binet equation spits out the inverse-fourth-power law. For Schwarzschild photons the match is exact — not an approximation. All of the curvature survives as that one strange exponent.

The dictionary between the two worlds:

geodesic              →  the polyline your integrator traces
affine parameter λ    →  your loop's accumulated dt (a step counter, not clock time)
conserved E, L        →  the constants you'd factor out of any orbit sim
h = |x × v|           →  cross(pos, vel) — computed once, never changes
metric / curvature    →  baked into the force law's exponent
"null"                →  it's light: only vel's direction matters, |vel| is meaningless

Two honest caveats. First, the parameter you march along is not time — photons don't experience time — it's just "distance along the loop," which is why the renderer can pick whatever step size it likes. Second, this flat-space-force trick is a lucky special case, not how GR is done in general: photons around a non-rotating hole happen to admit an exact equivalent force. A spinning (Kerr) black hole — the kind Interstellar actually modeled — has no such shortcut, and you'd integrate the full geodesic equations instead.

You already know the main effect here — by ear. An ambulance siren sounds higher-pitched rushing toward you and lower-pitched driving away. The siren never changes; the waves do. A source moving toward you partly chases the waves it just emitted, so they arrive bunched together. Moving away, it leaves them stretched out. Light works exactly the same way: bunched light waves look bluer, stretched ones look redder.

Speed does a second, stranger thing. Think of running through rain that's falling straight down: to you, it seems to slant into your face. Light aims the same way — for a glowing blob moving near light speed, even the light it emits sideways gets tilted forward, concentrating its glow into a cone pointing the way it moves. Physicists call it the headlight effect. If the blob is heading toward you, far more of its light reaches your eye, so it looks dramatically brighter; receding, dimmer.

Gravity adds a third shift: light climbing out of the hole's gravity well loses energy. It can't slow down — light always travels at c — so it pays in color instead, sliding toward red. (This is real and measurable: light sent between the floors of a building on Earth shifts by a tiny, detectable amount.)

Now put all three together for the accretion disk. The gas orbits at half the speed of light, so the side swinging toward the camera is blueshifted and beamed brighter, while the receding side is reddened and dimmed — and everything pays the gravity toll on the way out. The math below bundles all of it into a single factor g, and that's the whole story of the lopsided ring in the last figure of this section.