Four physics gates. All pass.

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 dfd-verify binary that runs four quantitative tests against the analytic predictions of DFD. Each of the four is a specific closed-form expression the paper derives from the field equation and the two postulates; the engine should compute each one to within numerical-discretization error on a finite grid. 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 at the origin. Radius R = 40 m. Mass M = 1 (engine units). Coupling speed c_eng = 100 m/s — much smaller than the real speed of light, so that ψ is O(0.08) at the surface and stays fp32-healthy. G_eng tuned so that surface gravity is exactly 9.8 m/s², since that's the feel we want for players.

The scalar field ψ lives on a 128³ grid with 1.25 m cell spacing, covering a 160×160×160 m volume. The Jacobi solver runs 5,000 sweeps on the GPU to converge ψ to the planet's presence. Total solver time: 160 ms on an M3 Pro.

Grid: 128³  (dx = 1.25 m)
Planet: R = 40.0 m, predicted g = 9.80 m/s²
Units: c_eng = 100.0 m/s, G_eng = 15680
Predicted ψ_surface = 0.078000  (n = e^ψ = 1.0811)
GPU: Apple M3 Pro
Running 5000 Jacobi sweeps...
Solver time: 0.16 s

Gate 1: far-field ψ decay

At distances r ≫ R (outside the planet), ψ should fall off as

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

which is the analytic exterior solution of the field equation. This is the direct DFD analog of Newton's gravitational potential. Sample ψ at r = 1.3 R and compare to the analytic value.

✓  G1: Far-field ψ decay
     measured = 5.95e−2  expected = 6.03e−2  err = 1.32%  tol = 5%
     at r = 52.00 m (= 1.3 R)

The solver converges to the correct exterior field to better than 2%. This is the most basic check — if this fails, nothing downstream can work.

Gate 2: gravitational light deflection

In DFD, light propagates along null geodesics of the optical metric ds² = −c²dt²/n² + dx² with n = e^ψ (paper Eq. 6). Fermat's principle then says rays minimize optical path length, which turns into the eikonal equation d/ds(n·dir) = ∇n. For a ray passing a spherical mass with impact parameter b, the paper derives (§IV.G.1, Eq. 82) 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 the engine's eikonal marcher, stepping through ψ as produced by our Jacobi solver, actually reproduces it.

In the engine, I fire a ray from x = −14 m in the +x direction with vertical offset b = 52 m, and integrate d/ds(n·dir) = ∇n step-by-step. The ray traverses the grid and the final direction is compared against the start. I account for the finite integration range — the ideal prediction assumes integration from −∞ to +∞, but we only traverse [−L, +L]. The finite-range analytic expression (paper Appendix B, Sec. B.1.d) is

α_finite = (4GM / c²b) · L / √(L² + b²)

Result:

✓  G2: Light deflection
     measured = 1.08e−1  expected = 1.01e−1  err = 7.44%  tol = 20%
     b = 52.00 m over L = ±79.0 m, 507 steps (finite-range factor 0.835)

Light bends correctly to within 7.4%, with most of the remaining error coming from the discretization of the ray integrator on a finite-resolution grid. At 64³, this gate was 14.3%; doubling the resolution halved the error, exactly as expected from first-order eikonal integration.

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 impact parameter bends by 0.108 radians, which matches DFD's analytic prediction for that geometry."

Gate 3: Kepler's third law

DFD's second postulate (paper Eq. 15) says test bodies accelerate according to a = (c²/2) ∇ψ. For a spherically-symmetric exterior ψ = 2GM/(c²r), this reduces exactly to Newton's law of gravity in the weak field, so a test particle in a circular orbit of radius r should complete one revolution in time

T = 2π √(r³ / GM)

— Kepler's third law, which drops out of the DFD matter postulate as a consequence. If our gravity integrator is right, a circular orbit launched at the correct velocity should return to its starting angle after exactly T seconds.

Setup: place a particle at r = 1.2 R = 48 m on the +x axis with circular-orbit velocity v_circ = √(GM/r) = 18 m/s in the +y direction. Run a leapfrog integrator at 1 ms timesteps. Detect when the particle has completed one full orbit (angle wraps through 2π and returns to start).

✓  G3: Kepler orbit period
     measured = 1.72e+1  expected = 1.67e+1  err = 3.32%  tol = 15%
     r = 48.00 m, v_circ = 18.07 m/s, 17240 steps

Period matches Kepler to 3.3%. The remaining error is about half post-Newtonian (v/c ≈ 0.18 in our units — not negligible, and DFD itself predicts small corrections to the Newtonian period at this velocity ratio) and half numerical integration 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. We sample a gradient of a field that was solved by relaxing an elliptic PDE, and test particles move according to that gradient, and the resulting motion obeys DFD's prediction — which in this weak-field regime is Kepler.

Gate 4: gravitational time dilation

In DFD, the local proper-time rate at position x is set directly by the refractive index at that point (paper §II.A, Eq. 9):

dt_proper / dt_coord = 1/n(x) = e^−ψ(x)

so the ratio of clock rates at two different radii is

rate(r₁) / rate(r₂) = n(r₂)/n(r₁) = exp(ψ(r₂) − ψ(r₁))

Sample ψ at r₁ = 1.1 R and r₂ = 1.4 R. Compare the measured ratio to the analytic.

✓  G4: Clock-rate ratio
     measured = 9.850e−1  expected = 9.848e−1  err = 0.01%  tol = 5%
     r₁ = 44.00 m, r₂ = 56.00 m

0.01% error. Essentially exact. This gate is the easiest of the four because it only requires that ψ exist and that we have its exponential — no integration of any dynamic equation is involved — but getting it right means the gravitational redshift effect for rendering is automatically correct.

What this means

Four independent analytic predictions of DFD, computed from one scalar field on a 128³ grid, matched to 0.01%, 1.3%, 3.3%, and 7.4% accuracy. The whole verification takes 160 milliseconds. It runs on every commit via cargo run --release --bin dfd-verify.

╔═══════════════════════════════════════════════════════════════════════╗
║  DFD VERIFICATION GATES                                                ║
╚═══════════════════════════════════════════════════════════════════════╝
✓  G1: Far-field ψ decay     err =  1.32%   tol =  5%
✓  G2: Light deflection      err =  7.44%   tol = 20%
✓  G3: Kepler orbit period   err =  3.32%   tol = 15%
✓  G4: Clock-rate ratio      err =  0.01%   tol =  5%
ALL GATES PASSED — DFD physics verified on 128³ grid.

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.