in·side the rig

Real millimetres, generic parts. Every part is built in code from boxes, cylinders, fin stacks and swept tubes at the published dimensions of a real 2026 flagship build: the full-tower case, an E-ATX board, a nearly four-slot graphics card, a 360 mm liquid cooler, a 1600 W supply. One frame for everything (millimetres, +Y up, +Z to the case front, +X to the glass), scaled by a thousand into metres for the camera. The names were never needed: a cooler reads as a cooler because of its shape.

One part tree, one explode engine. Each piece is a node with a stable id, and 104 ids live in one registry. The copy file must describe every id and the builders must emit every id, so a typo on either side is a type error rather than a hole in the atlas. The explode is data: each node carries a stage from one to four, a direction, a distance and a lag, and the slider's four quarters are the stages. Children ride on their parents, so a graphics-card fan gets the card's travel plus its own.

Two abstract worlds at remote origins. The processor city and the graphics lanes are built in the same scene, far below the machine, and the camera jumps between worlds inside short black dips placed exactly on chapter boundaries. The camera flies four segments of keys stamped with scroll progress, sampled by a Catmull-Rom on those stamps so unevenly spaced keys keep an even pace.

Flows as particles. Memory requests, storage blocks, power, coolant and air are point clouds riding curves through the real geometry, each with its own style, switched on and off by chapter. Heat is a sprite field that swells over the chip and the card's power stages.

Blender for the hero parts. The fan rotors at five sizes, the graphics-card shroud, the pump block and the heat spreader come from a scripted Blender parts library, one small GLB of 16 meshes named <part>__<material>. At load the page swaps them into the tree by id before anything is indexed; if the file is slow or missing, the procedural parts stand. ?lib=0 forces that.

Accessibility and mobile. Focus rings, accessible names, a live caption region, a slider that speaks its stage, focus moved into the panel when a control opens it, Escape unwinding credits, then selection, then deep dive, and a plain list of every product for screen readers. Reduced motion stops the drift, the auto-rotate and the eased camera. On a phone the atlas panels fold into bands above and below the machine.

No brands, enforced. The first version named its parts. This one does not: parts are named for what they are, specs are given as classes rather than one product's numbers, the accent that used to be red on black is now amber, and tools/brand-scrub.mjs fails CI if a maker's or product's name appears in the piece's source, its page, its frames' manifest or the strings inside its GLB. The replayed frames below were rebuilt from sources run through the same scrub first.

Built with Claude Code from Jack's master brief and storyboard. The three small helpers the lab version borrowed from a private kit (a device-tier guess, a soft sprite texture and the camera-key sampler) were rewritten here from how they behave; the sampler was checked against the original's output on random keys until they agreed to rounding error.

1. Start with a registry of ids. Every inspectable piece gets a stable id in one list. Make the content and the builders both typed against it, so the compiler tells you when a part has no words or the words have no part.
2. Build in real units, in one frame. Pick millimetres and one axis convention, write the layout constants down once, and make every builder a pure function that returns a node. Scale the whole machine once, at the root.
3. Make the explode data, not animation. Give each node a stage, a direction, a distance and a lag. The slider's stops are the stages, so "case open" and "every piece" are positions, not timelines. Parent children under their node and the travel adds up for free.
4. Stamp camera keys with scroll progress. A list of [p, x, y, z] rows per segment, sampled with tangents from the neighbouring keys over their time span. Put a ?p= pin in from day one; software GL never settles otherwise.
5. Hide world changes in the dark. Micro worlds can sit far from the machine in the same scene. Dip to black for a few per cent of scroll on the boundary and move the camera while nobody can see it.
6. Swap geometry in by id. Author better meshes in a script, name them after the node ids, keep them in the primitive's own local frame, and drop them in before you index the tree. Keep the primitives as the fallback.
7. Probe instead of guessing. Expose the scene and a raycast helper on window. The two worst frames here were the camera sitting inside a part, found in one probe after two wrong theories.
8. Scrub what you do not own. If the piece depicts real products, keep a denylist of names in CI and run it over text, textures and model files alike. A model file's node names are as public as the page.

The explode engine, whole (the full piece is in src/rig/ on GitHub):

// each node moves within its own quarter of the slider; children ride along
const ease = (t) => t * t * (3 - 2 * t);

function stageProgress(amount, stage, lag = 0) {
  const w0 = (stage - 1) / 4, w1 = stage / 4;
  let t = (amount - w0) / (w1 - w0);
  if (lag > 0) t = (t - lag) / (1 - lag);   // siblings leave in waves
  return ease(Math.min(1, Math.max(0, t)));
}

function applyExplode(nodes, amount) {
  for (const n of nodes) {
    n.object.position.copy(n.home);
    if (n.explode) {
      const { stage, dir, dist, lag } = n.explode;
      const d = new THREE.Vector3(...dir).normalize();
      n.object.position.addScaledVector(d, dist * stageProgress(amount, stage, lag));
    }
    applyExplode(n.children, amount);
  }
}

Directions are in the machine's frame and distances in millimetres; the node's home is captured once at build time, so the engine can never lose the assembled position.