Case

The hero film in C++. Zero lines written by hand.

The film that greets you on our home page is not stock footage, and it is not a WebGL demo. It is a path-traced drone flight over a landscape built from genuine aperiodic mathematics, rendered by a from-scratch C++ renderer with three GPU backends.

All of it, the mathematics, the 3D world, the renderer, the camera physics and the pipeline, was designed, written, reviewed and rendered in a single day. Every line came from Anthropic Fable 5 in Claude Code. We wrote none of it by hand. This is AI C++ programming in practice, and this is how it went.

Validated aperiodic tiles: 54,289
Light paths simulated: 663 bn
Lines of C++, zero dependencies: 1,305
Frames at 1080²: 2,220
Render time on a laptop: 4 h
Lines written by hand: 0

The brief

TokenTek's symbol is a hat. Not just any hat, but the einstein monotile: the thirteen-sided shape discovered in 2023 that tiles an infinite plane without the pattern ever repeating. One shape, infinite variation. For a company that builds custom systems instead of rolling out templates, it is not a bad metaphor to have accidentally hired as a logo.

The new website needed a hero background, and the constraints set on the morning of July 10 were short and uncompromising:

It must be the real mathematics. Not a texture, not a screenshot of someone else's demo, but the substitution system from the research paper, validated to machine precision.
It must be a rendered film, not a live canvas. Path-traced light and true depth of field from a simulated lens. The calm of a tabletop macro shot, not the plastic shimmer of realtime WebGL.
Nothing off the shelf anywhere in the chain. No engine, no renderer, no assets. If it appears on screen, code in this repository put it there.

One more thing: it was a Friday, and the site wanted its hero.

Mathematics that never repeats

The day started where the brand starts, with the hat itself. The tile is made of eight kites from the lattice you get when every hexagon in a hex grid is cut into six pieces. Thirteen vertices, all on lattice points. It can only tile the plane aperiodically, and it needs its own mirror image, sparsely scattered, to do it. That little fact became the entire art direction: in a field of identical dark tiles, the rare mirrored ones are mathematically special. So they, and only they, get to be orange.

The einstein tile, its reflection, and a small patch of the pattern. The mirrored hats are 12.7 percent of every tiling.

The generator, 373 lines of Python with no dependencies beyond shapely for validation, ports the substitution system from Craig Kaplan's hatviz. Four metatiles inflate recursively, level by level, until five substitution levels have produced 54,289 hats. 6,912 of them, 12.7 percent, are mirrored, exactly the density the theory prescribes.

Substitution levels 1 through 4: every metatile is recursively replaced by a cluster of smaller ones.

Trust the mathematics, but verify it. On every run the generator proves that all tiles have exactly equal area, that no two tiles overlap, that the surface is one connected piece without a single interior hole, and that the mirrored fraction lands on the published 12.7 percent.

One subtlety nearly slipped through: the TokenTek logo is the mirror image of the paper's canonical hat. So the entire tiling is reflected across x = 0 before use. The majority matches the brand mark, and the rare opposite-chirality tiles remain the accent candidates.

A world built from a proof

The next step turns validated 2D mathematics into a 3D world. Each tile outline is inset by 0.03 units with mitred joins, which produces the 0.06-unit hairline grooves that catch the light, then triangulated (the hat is not convex, shapely politely declines) and extruded into a prism.

The geometry around an accent tile in the shipped scene file: grooves, prisms, and one faintly emissive orange hat.

The tile heights are the day's best example of less is more. The terrain is quantized fractal noise, four octaves at a wavelength of 42 units, snapped to 50 discrete terrace levels so the landscape reads as carved strata instead of mush. The first versions shaped that noise with floor curves, sea levels and cosine easing, and every one of them flattened some band of heights. Each proposal was spotted and vetoed within minutes. The final mapping is one line:

# pure linear mapping: no shaping curve at all. Floors, sea levels and
# cosines all flatten some height band; linear keeps every point on a slope.
h = TERRAIN_AMP * n          # n = fractal noise stretched to its 1..99% range
if TERRAIN_STEP > 0:
    h = round(h / TERRAIN_STEP) * TERRAIN_STEP

The terrain as a wireframe with the flight path above: 50 terrace levels, no flattened bands.

The scene keeps only what the flight can see: a strip of 131 by 261 units, computed by sweeping the camera's exact ground footprint frame by frame. Banked turns throw the view frustum twelve units sideways, and a straight-line estimate leaves black wedges on screen. That was precisely the bug GPT 5.6 Sol caught in one of its external code reviews that evening, and the fix was upgrading the tiling from level four to level five. 10,127 tiles survive the crop, and every one gets its own material with randomized albedo and roughness so the field glitters subtly instead of reading as one molded slab.

The orange accents are chosen against the actually flown route: the scene builder contains a line-for-line port of the C++ flight camera, verified against the original to under a hundredth of a unit, and picks mirrored hats within seven units of the ground track, greedily, closest first, with a minimum spacing of eight units. 19 accents made the final scene. The drone flies over its orange marks instead of dragging them along one edge of frame, and each accent glows faintly into a separate radiance buffer that becomes the lava-glow bloom in post.

The choreography from above: the flight path, the camera's ground footprint, and the 19 orange accents along the track.

Everything packs into one flat 15.3 MB binary the renderer reads in a single pass: 10,128 materials, 374,701 triangles, nothing else.

A renderer from an empty file

No ready-made engine survives the zero-dependency constraint, so the renderer was written from scratch in C++17. The film's entire optical personality lives in a single 425-line header that compiles unchanged as plain C++, CUDA and Metal Shading Language.

It is a textbook-honest path tracer, tuned for exactly one scene:

A thin lens. Every sample picks a random point on an aperture disk of radius 0.42. Depth of field is therefore geometry, not a post filter: bokeh grows physically with distance from the focal plane.
GGX plus Lambert. Satin dark plastic, which is what makes the groove edges glint.
Next event estimation with multiple importance sampling toward one big rectangular key light, so the soft highlights converge clean at 256 samples per pixel instead of 2,000.
A BVH with median splits and at most four triangles per leaf: 374,701 triangles trace comfortably on anything.
Five bounces, Russian roulette after two, and a firefly clamp that deliberately spares primary rays, because the bright bokeh disks are the shot and should not be dulled.

The anatomy of one light path: lens sample, bounces, shadow rays toward the key light, and firefly clamping.

Determinism is a design principle, not an accident. The random number generator is seeded per frame, pixel and chunk: the same frame and the same pixel produce the same photons, on any machine and any backend. Any frame can be re-rendered in isolation and land within sampling noise of the original, which is what later makes segmented, resumable rendering across machines trivially safe.

A drone flying over ten-unit mountains with an extreme aperture has a problem: a fixed focus distance is wrong almost everywhere. The fix is ten lines and a statistics joke, a median filter in disguise:

// autofocus: put the focal plane at the median scene depth of a small
// patch around the frame center. Fixed ray grid, no RNG: deterministic
// per frame, and the median doesn't pump when an edge crosses the center.
for (int j = 0; j < 5; ++j)
    for (int i = 0; i < 5; ++i)
        if (intersectBVH(S, cam.pos, rayThroughGrid(i, j), &hit))
            depths.push_back(hit.t * dot(d, cam.fwd));
std::nth_element(depths.begin(), depths.begin() + n/2, depths.end());
cam.focusP = cam.pos + cam.fwd * depths[n/2];

Twenty-five rays, no randomness, take the median. A mean would drift whenever half the patch hangs over a valley, and a random pattern would make focus breathe between frames. The median over a fixed grid does neither: the frame center is simply always sharp, and the mountains slide through the focal plane like a tilt-shift diorama.

The thin lens and the autofocus: aperture disk, focal plane, and the median of 25 depth probes at the frame center.

Frames leave the tracer as raw linear radiance, get their lava glow from a separate emission buffer, are tonemapped with ACES and dithered by half a bit so the near-black gradients survive H.264 without banding. The stream is piped straight into ffmpeg: 7.8 GB of raw frames that never touch the disk.

The camera that had to learn to fly

The hardest piece of the day, and the most rewritten, was not the light transport. It was the camera. The plan document preserves the fossil record: a straight dolly, then a perfectly looping orbit, then a spline follower, each approved and each overturned within hours as the same truth surfaced every time. Rails feel like rails, no matter how smooth.

The final camera, revision eight, is not a path at all. It is a simulated FPV drone with an action camera hard-mounted 45 degrees down, flown by a causal control chain:

// FPV pilot model. Guidance suggests the acceleration that would follow
// the route; the body must first yaw its nose toward the required thrust
// vector, and only then can forward thrust bend the velocity. Momentum
// carries through the turn: yaw first, push second.
V3 requiredThrust = guideAccel + vel * (1.0f / dragTau);
float targetYaw   = atan2(requiredThrust.x, requiredThrust.y);
yawV += (wrapPi(targetYaw - yawS) * wY * wY - 2*zY*wY*yawV) * dt;
V3 bodyF{sin(yawS), cos(yawS), 0};        // the nose, not the route
V3 desiredAccel = clampLen(bodyF * thrust - vel * (1/dragTau), accelMax);
accel += clampLen(desiredAccel - accel, jerkMax * dt);   // jerk cap

Guidance chases a carrot fifteen units ahead on a spline through thirteen waypoints, but guidance only gets to suggest. The craft must first yaw its nose toward the required thrust vector, and only thrust along wherever the nose actually points can bend the velocity. Momentum does the rest.

The FPV model's anatomy: guidance, yaw dynamics, physics, and a hard-mounted camera. The spline follows the craft, not the clock.

The result measures like drone footage because it is generated by the same physics that shapes drone footage. The body slips up to 30.4 degrees away from the velocity vector in the hardest turn while speed stays pinned around two units per second. The camera leads the turn optically by up to 19.9 degrees: the gaze arrives before the trajectory, exactly the tell that separates FPV footage from camera-on-rails renders. And the horizon banks up to 10.6 degrees because lateral acceleration tilts the craft, never because anyone rolled the image in post.

74 seconds of flight telemetry: slip, gaze lead, bank and speed. The curves look like real FPV data because the physics is the same.

Critically for the pipeline: the whole simulation is re-integrated from zero for every frame. That sounds wasteful and costs nothing, microseconds against seconds of ray tracing. But it means frame 1,890 rendered on a CUDA box is bit-identical in pose to frame 1,890 on an M4 Max. The camera has no state files, no baked path, and no way to drift.

A studio that travels along

The lighting is one warm-white rectangular light, 60 by 54 units, and a faint sky gradient. Nothing else. The trick is that the light is bolted to the camera's heading: always 24 units to the right, 36 ahead, 39 up. Every frame of the 72-second flight is lit like the same photograph, same key direction, same soft rolloff. That is what makes the loop's crossfade invisible and gives the film its calm studio quality while an entire mountain range slides past underneath.

The scene setup: camera, traveling key light and focal plane. The whole film is lit like a single photograph.

One core, three kinds of silicon

At 17:59 the film had a problem money could not solve but portability could: the CPU renderer needed a day that did not exist. The answer became the repository's most satisfying engineering. The core header compiles unchanged as C++17, CUDA and Metal Shading Language, so the film's entire look, BSDF, lens, BVH, RNG and integrator, exists exactly once.

#if defined(__METAL_VERSION__)
  #define HD inline          // function qualifier
  #define DEV device         // device-memory address space
  #define THR thread         // thread-local address space for refs
  typedef uint u32; typedef ulong u64;
  HD float xsqrt(float v) { return metal::sqrt(v); }
#else                        // C++ host / CUDA
  #define HD __host__ __device__ inline
  #define DEV
  #define THR
  HD float xsqrt(float v) { return sqrtf(v); }
#endif

Three shims, one function qualifier and two address-space keywords, plus safe math wrappers and a single ABI rule. That is the entire cost of portability. The backend drivers are almost embarrassingly thin:

Backend	File	Lines	The interesting part
CPU	main.cpp	44	a row queue across 16 cores with std::thread
CUDA	cuda_main.cu	90	samples split into 16-spp launches so no kernel wakes the Windows display watchdog
Metal	metal_main.mm	136	the GPU kernel is compiled at runtime by concatenating the core header with a 23-line MSL wrapper

One core, three backends: the same integrator on CPU threads, CUDA kernels, and a Metal kernel compiled at runtime.

The backends were cross-checked to visually identical frames. Metal rendered a final-quality frame in about 6.5 seconds against the CPU's 38.6, and turned "start the render before bed" from a plan into a luxury.

A pipeline that survives Ctrl-C

A single script runs the whole delivery: tracer, 60-frame segments, a lossless intermediate, the loop edit, and finally H.264, VP9 and the poster. Two design decisions carry it.

Segments are cache entries, not just progress. Every segment is encoded and kept as a finished file. Abort at any time, and a rerun continues after the last complete segment. At most 60 frames are ever at risk, about six GPU minutes.

The cache key is the content of everything that could change a pixel. Not timestamps, not filenames. The scene file, the configuration, resolution and samples, and the exact bytes of the renderer binary itself are fingerprinted together:

# Fingerprint the executable bytes, not just the filename. Metal also
# compiles the core header at runtime, so it is renderer input even
# when the binary itself did not need relinking.
FP=$({ cat scene.bin config.txt
       print -r -- "$S $SPP $FRAMES $SEG ${TRACER:t}"
       cat -- "$TRACER" } | cksum | tr ' ' '_')

Touch the scene, the look, or the renderer itself and the fingerprint changes: the pipeline cannot resume stale frames into a new film. That is the unglamorous reason the day could rewrite the camera physics at 20:36 and still trust a render started at 23:32.

The data funnel: from 663 billion light paths through 7.8 GB of raw frames, which never touch the disk, to a 24 MB web film.

The film loops every 72 seconds, and the edit is deliberately cheeky. Instead of a motion-matched cut (the earlier orbit camera had one for free, and was cut for feeling lifeless), the source renders two extra seconds past the loop point, still mid-turn, and the delivery dissolves that tail into the head over two seconds of active motion. Movement hides the seam, and the eye never finds a freeze to latch onto. Page load always starts on the clean, sharp poster frame.

The loop edit: two extra seconds of mid-turn footage dissolve into the film's beginning. Motion hides the seam.

The render night

The final commit landed at 23:32. The render script picked the Metal tracer, and the M4 Max laptop spent the night pushing 663 billion camera paths: 2,220 frames times 1080² pixels times 256 lens samples, each path up to five bounces deep with a shadow ray at every vertex.

Per-frame render times through the night, and the backend comparison that made the night possible.

The per-frame curve is its own little story. The cheap frames cruise over distant terrain, and the expensive stretch is the long banked combination turn where near-field mountains fill the frame with wide bokeh: more BVH work per ray, and more rays surviving to full depth. On average 6.49 seconds per frame, four hours in total, and the poster frame hit the disk at 03:41.

Every look decision of the day, meanwhile, was made at 500 times that speed: the tracer's preview mode swaps in a pinhole camera, 1 sample per pixel and headlight shading. That is the mode the whole flight was choreographed in.

The preview mode every decision of the day was made in, against the same frame at final quality.

The convergence ladder: the same crop at 4, 16, 64 and 256 samples per pixel.

Fresh out of the tracer at print resolution, rendered for this article by the same binary and the same scene that shipped the film:

The head of the loop, the poster moment.

The S-turn at 17 seconds. Bokeh does the heavy lifting.

Cruising over the terraces at 48 seconds.

The hardest turn at 63 seconds: 30 degrees of slip, 10 degrees of bank.

The day in the git log

All times July 10, 2026. The repository is the diary:

Time	Event
11:42	First version: tiling generator, scene builder, CPU tracer, first frames
12:01	The orbit camera era begins, and quietly ends
12:01 to 16:21	Look development: graphite and orange locked, aperture 0.42, dolly and orbit tried and discarded
16:21	Spline flight camera, preview mode, wallpaper generator
17:34	Ready to render: flight v1 approved on preview films
17:59	CUDA tracer, so an RTX 5090 across the office could help
18:33	Shared render core plus Metal backend: one integrator, three machines
18:49	The render script: live progress, abort and resume, automatic backend choice
19:24	GPT 5.6 Sol's review addressed: level-5 tiling, scene built from the truly flown route
19:43	Autofocus: the focal plane follows the median scene depth at frame center
20:36	Gaze leads into the turns: the FPV model in its final form
23:32	Final version for web. The render starts
03:41	The poster frame is written. Four hours of GPU time, 663 billion light paths

And here is the result, the film that now sits behind the headline on our home page:

72 seconds, 24 MB of VP9. Loops without a visible seam.

Why one day was enough

We understand if it sounds improbable: an AI model that in one day designs, writes and documents validated research mathematics, a C++ path tracer with three GPU backends, and a physics model that fools the eye. But it was not magic. It was three ingredients.

A decisive art director. Every look decision in the log was made in minutes, on evidence, preview films and stills, and never reopened. The terrain saga, six shaping curves proposed and six flattened height bands detected, is the pattern in miniature: fast vetoes beat slow consensus.

An agentic way of working. The build was one continuous human-AI pair session. Art direction, taste and veto power on one side; design, implementation, review response and documentation through Anthropic Fable 5 in Claude Code on the other. The plan document was the shared contract, and every revision of the design survives in it: that is why this article could be written from the repository after the fact. The code was also reviewed externally twice during the day, by GPT 5.6 Sol. Having AI review AI is a standing part of our method, always with a different model than the one that wrote the code. When the evening review found two real bugs, both were fixed and verified within the hour, because the fingerprinted pipeline made re-validation cheap.

Determinism as policy. Seeded randomness everywhere, configuration as text, content-hashed caches, and a camera that re-integrates from zero. Nothing in the pipeline depends on what happened yesterday, which is exactly why the pipeline could be rebuilt four times today.

The repository, 373 lines of tiling mathematics, 551 lines of scene building and 1,305 lines of renderer, replaces what would conventionally be a Blender project, a render farm and a motion-graphics subscription. The site got its hero. The hero happens to be a proof.

The method is the same one we use in client work: clear direction, fast decisions on evidence, and AI agents writing every line. That is how we build production systems, and that is how we built our own home page.

The substitution rules are ported from Craig S. Kaplan's hatviz (BSD-3-Clause). The tile is from "An aperiodic monotile", Smith, Myers, Kaplan and Goodman-Strauss, 2023. Everything else, generator, renderer, camera and pipeline, was written from scratch in the repository on July 10, 2026.

Want to see what one day can do?

The method that built the film is the method that builds production systems for our clients: clear goals, fast decisions, and AI agents writing the code. Get in touch and we will show you what it looks like on your systems.

Get in touch Read the case: Notebook Navigator