Video summary

I'm making a game engine based on dynamic signed distance fields (SDFs)

Main summary

Key takeaways

Technology

Overview

Mike describes an in-progress game engine built around dynamic signed distance fields (SDFs) to support high-fidelity, real-time modification of world geometry.

What the engine enables (product/gameplay goals)

  • Detailed dynamic geometry edits during gameplay:

    • Additive and subtractive changes (e.g., smooth blends or sharp-edge cutouts).
    • Non-destructive edits, such as:
      • moving a hole around,
      • creating a tunnel,
      • walking through it and having it disappear behind you.

  • Motivation: most games use static worlds or low-fidelity / hard-to-edit geometry (even Minecraft / No Man’s Sky). This engine aims for much higher geometric fidelity.

Core tech: SDF boolean operations

The engine uses SDFs to perform simple geometric boolean operations:

  • union
  • subtraction
  • intersection

It also supports smoothed blending to avoid hard edges.

External references mentioned

  • Sebastian Llog: a short math/rendering intro linked in the description, covering SDF definitions and typical rendering via ray marching.
  • ShaderToy and Inigo Killes: general SDF techniques.

Rendering approach (performance problem + solution)

Problem

  • Standard SDF rendering via ray marching is expensive because it evaluates complex distance functions many times per pixel—and dynamic scenes make this worse.
  • Even with culling, complex scenes can involve dozens+ of SDF edits influencing a point.

Solution: cached distance grids + interpolation

  • The scene is represented as an ordered list of SDF edits (borrowed terminology from Dreams).
    • Each edit has position/rotation/scale and applies via boolean ops (union/subtraction/etc.).
  • To avoid recomputing the full SDF repeatedly:
    • Evaluate and cache SDF distance values on a grid, then reuse them during rendering.
  • To reconstruct approximate distance at arbitrary points:
    • Find the grid cell containing the point.
    • Gather the cell corner distances and use:
      • bilinear interpolation (2D) or
      • trilinear interpolation (3D).
    • The implementation is described as conceptually equivalent to a single GPU texture fetch.

Accuracy tradeoff (grid resolution)

  • Coarser grid spacing causes artifacts like wobbling near corners due to interpolation error.
  • Higher grid resolution improves accuracy but increases cost.

Memory optimization: sparse caching

  • Full dense 3D distance grids are too memory-heavy:
    • Even 1024³ samples at 1 byte each becomes ~1 GB.
  • Optimization: cache only where the surface might exist:
    • Only cells where cached distances cross positive to negative (i.e., contain the SDF zero-crossing surface).

Sparse storage method: brick map

  • Uses a brick map:
    • A dense grid of pointers to small bricks stored in a texture atlas.
    • Bricks are 8×8×8 (inspired by Dreams).
  • This reduces memory by not storing irrelevant empty space.

Open-world optimization: SDF “geometry clip maps” (LOD for evaluation)

For large worlds, it’s still too costly to evaluate everywhere, so it uses nested multiresolution grids:

  • Inspired by geometry clip maps.
  • Multiple clip levels are centered on the player:
    • each level covers a larger area at coarser resolution.
  • This keeps the on-screen size of cached regions relatively constant while reducing evaluation cost with distance.

Quantified example

For ~2.5 km draw distance:

  • >200 trillion cells without clip maps
  • ~20 million cells with clip maps → about a 10 million× reduction

Dynamic updates: regenerate only changed regions

To support fast runtime geometry changes:

  • Edits are tracked spatially with a BVH (AABB tree shared CPU/GPU).
  • BVH is used to:
    • accelerate queries / raycasts,
    • determine which edits affect a region,
    • decide which distance bricks must be re-evaluated after edits change.

Debugging support

  • A visualization shows which bricks get regenerated per frame.
  • Most of the world is reused across frames.

Physics integration (what’s done vs not done)

  • Rendering uses GPU SDF evaluation, but physics needs collision support.
  • Chosen physics engine: Jolt (mentioned as used in Horizon Forbidden West and Death Stranding 2).

  • Since Jolt doesn’t directly support SDF collision:

    • The engine generates a triangle mesh from the SDF (in chunks) using marching cubes.
    • Mesh generation:
      • done on the CPU across multiple threads for lower-latency updates,
      • used for physics collisions (rendering does not use meshes).

  • Dynamic SDF edits can become dynamic physics bodies, enabling realistic collisions as the scene changes.

Terrain generation

  • Terrain is not a simple height field; it’s fully 3D and generated progressively:
    • via octaves of noise
    • heavily inspired by work by Inigo Killes
  • SDF edits interact properly with the terrain.

Gameplay demos / features enabled by this system

  • Kilometer-scale digging
    • “effectively unbounded” number of edits via incremental recomputation + LOD
    • demonstrates digging deep below the surface
  • Tunnel gun
    • capsule subtraction locked to the player viewpoint
    • physics collision mesh updates dynamically
    • tunnel can be removed after passing through
  • Moving hole to affect objects/enemies (physics reacts as the hole shifts)
  • Material stamping / ore digging
    • edits can volumetrically stamp materials underground
  • Visual “grossness” noted when digging certain materials
  • Supported operations include:
    • subtractive digging
    • additive construction (e.g., building walls from cubes)
    • drawing on surfaces
  • SDF fidelity enables semi-modeling workflows (demo: “Sir Potato Face”)
  • Extensive debug visualizations are emphasized as critical for intuition and debugging

Main speakers / sources

  • Speaker: Mike (creator of the engine)

  • Referenced sources/tools:

    • Sebastian Llog (SDF math/rendering video)
    • ShaderToy (SDF technique references)
    • Inigo Killes (SDF techniques/articles)
    • Dreams (inspired edit/caching terminology and brick sizing ideas)
    • NVIDIA (cited grid reconstruction concept)
    • Valve 2007 paper (font SDF caching technique)
    • Geometry clip maps (paper referenced)
    • Jolt physics engine
    • Donut County (gameplay inspiration)

Original video