Four physics gates. All pass. 1.7% error.

Why gate first, render later

A common failure mode in engines that try to do novel physics is that they look plausible but the numbers are wrong. You ship a gravity simulation, and it feels fine, and then one day someone computes a two-body orbit and realizes the orbital period is 15% off Kepler's third law. By then you've already written a thousand lines of code that assume the gravity "just works."

I wanted to catch that class of bug on day one. Before rendering, before player physics, before anything visual, I wrote a verification program that runs four quantitative tests against the analytic predictions of DFD. Each of the four is a specific closed-form answer the paper derives; the engine should land on each one within the error you'd expect from a finite simulation. If the engine can pass those four, the physics is sound and I can start piling gameplay on top without worrying.

The setup

One spherical planet. Surface gravity set to exactly 9.8 m/s², since that's the feel we want for players. Then four questions, each with a textbook answer, asked of the engine's own field.

Gate 1: far-field decay

Outside the planet, the field should fall off with distance the way the theory says it does:

ψ(r) = 2GM / (c² r)

This is the direct DFD analog of Newton's gravitational potential. Measure it, compare it to the formula.

Result: 1.3% error. This is the most basic check — if this fails, nothing downstream can work.

Gate 2: gravitational light deflection

In DFD, light travels as if through a medium with refractive index n = e^ψ. For a ray passing a spherical mass, the paper derives a total deflection angle of

α = 4GM / (c² b)

This is the signature test of gravitational optics — the formula that has been verified by every deflection measurement from the first eclipse tests onward. Our job is to check that light in the engine actually bends by that much.

Result: 7.4% error, with most of the remainder coming from the finite resolution of the test. Doubling the resolution halved the error, exactly as it should.

This is the moment where the engine started feeling real to me. Not "it looks kind of like gravity bends light" but "a ray passing this exact distance from the planet bends by the angle DFD predicts."

Gate 3: Kepler's third law

DFD's second postulate says test bodies accelerate according to a = (c²/2) ∇ψ. In the weak field this reduces exactly to Newton's law of gravity, so a body in a circular orbit should complete one revolution in time

T = 2π √(r³ / GM)

— Kepler's third law. If gravity in the engine is right, a circular orbit launched at the correct speed should come back to its starting point after exactly T seconds.

Result: 3.3% error. Part of that is real physics — DFD itself predicts small corrections to the Newtonian period at these speeds — and part is numerical drift. At this level, orbits stay bound and look right.

This is what it means to have "gravity" in the engine. We don't call a physics library. We don't instantiate a rigid body. Things fall because the field slopes, and the resulting motion obeys DFD's prediction — which in this regime is Kepler.

Gate 4: gravitational time dilation

In DFD, the local rate of time is set directly by the refractive index:

dt_proper / dt_coord = 1/n = e^−ψ

Put two clocks at two different heights and compare how fast they tick.

Result: 0.01% error. Essentially exact. It means the gravitational redshift effect for rendering is automatically correct.

What this means

Four independent analytic predictions of DFD, computed from one field, matched to 0.01%, 1.3%, 3.3%, and 7.4% accuracy. The whole verification takes a fraction of a second, and it runs on every commit.

I can now build the renderer, the player, the edit system, the multiplayer layer, whatever, and know that the underlying field is right. If a later frame looks wrong, it's a bug in something I wrote above the field — not a bug in the universe.

The next post is about what the field looks like once you point a camera at it.