One field to render them all
Why a single field can replace the triangle mesh, the physics engine, the lightmap, and the voxel grid of a classical game engine — and what makes it simultaneously simpler and more correct.
The classical engine, drawn honestly
A modern game engine carries five independent representations of the world:
| Subsystem | Data structure | Queried by |
|---|---|---|
| Renderer | Triangle mesh + BVH + textures + lightmaps | Every pixel shader |
| Physics | Rigid bodies + collision shapes + broadphase | Every simulation step |
| Lighting | Irradiance probes + reflection captures | Every shaded surface |
| Destruction | Voxel grid + chunk tree | Every edit |
| AI navigation | NavMesh + flow fields | Every NPC step |
These are five approximations of the same thing: what exists, where, and how it behaves. Each was designed by a specialist team to be good at one kind of query. None of them agree with each other exactly. Enormous engineering effort goes into keeping them in sync as the world changes.
When you dig a hole in Minecraft, the chunk voxels update, the meshing remakes a triangle mesh, the lighting recomputes, the physics rebuilds its collision shape, and the server replicates the edit. Five updates for one logical event. The better engines hide this under good tooling. The worst engines show it to you as a visible stutter.
Density Field Dynamics
DFD is the physics theory behind this engine. It says: space is flat. A single scalar field ψ permeates it. Gravity, optics, and the passage of time all emerge from that one field.
Two postulates:
P1 (light): light travels through space as if through a medium with refractive index
n = e^ψwhich means light curves wherever ψ changes.
P2 (matter): test bodies move under the acceleration
a = (c²/2) ∇ψwhich reproduces Newton's law in the weak field.
The field itself is set by where the mass is. The theory has zero free parameters once H₀ is measured. Every observation that has ever been made of gravity — from solar-system precision tests to binary pulsars to LIGO gravitational waves to Event Horizon Telescope black-hole shadows — is consistent with what DFD predicts in those regimes. The paper is public if you want the full derivation.
What this means for an engine
Every physical question a game engine ever asks is a question about the field:
- Render a pixel? Ask the field. Light bends where the field is strong. No meshes, no BVH.
- Apply gravity? Ask the field. No collision solver, no constraint LCP.
- Is this point solid? Ask the field. No collision mesh.
- How fast do clocks tick here? Ask the field. Gravitational redshift is free.
- How does light bend around a mass? The same physics that renders the frame bends it, and it's the same physics that produces the gravity you fall in. They can't disagree.
The payoff is that all five data structures above collapse into one. You only ever change the stuff in the world. Everything else follows from it. There's no synchronization problem, because there is no second thing to stay in sync with the first.
The consistency you get for free
In a classical engine it is genuinely possible for a light to shine through a wall the physics treats as solid. The rendering lightmap was baked from one version of the scene; the physics collision mesh was exported from another; they drift. This is a famous class of bug in every engine.
In Ractr, the renderer reads the same field that the physics reads. If light bends around an object, matter falls toward that object, because both behaviors come from the same field. They cannot disagree. The consistency is enforced by the math, not by a careful build pipeline.
The theory backs this up. Given the matter in the world, the field exists and is unique, so there's never ambiguity about which world you're looking at. Changes travel no faster than light, which shows up in the engine as a visible ripple — correct physics and a free aesthetic effect. And the field always settles. Classical rigid-body solvers can explode. This can't.
The scaling property
Classical engines have to stream chunks, swap LODs, rebuild BVHs, reproject lightmaps. All of that exists because the representation only knows about the chunks you've loaded.
A world built on the field is different. Gravity and light reach as far as the physics says they do, which is everywhere. The same engine that works for a 40-meter planet works for a 6,000-kilometer planet, and in principle for a solar system or an open MMO world. The size of the world is not what decides the cost of a frame.
The smallest possible world
I'll close with the thing that makes this project feel right to me. Every game engine is, at some level, trying to simulate a universe. The question every engine architect answers is what is the smallest representation I can get away with? Triangle meshes are small — but you pay with collision-mesh drift, lightmap drift, BVH rebuild cost. Voxels are small — but you pay with seams, aliasing, and memory. SDFs are smaller — but you still pay, and they have no physics in them.
The actual smallest representation, the one that has been running the universe for 13.8 billion years, is one field. You can't go below one field without losing information. And when you're simulating on top of that field, everything the field already does becomes a feature of your engine for free. Gravity, time, light, inertia, matter interaction — all emergent, all consistent, all available everywhere.
The next post is about what happens when you actually build it and check if the physics works. Spoiler: four tests, all pass.