# ADR-0006: Three.js is the museum's engine

- Status: accepted 2026-08-03 (owner)
- Supersedes the open question in ADR-0003, which deferred the choice until
  a product-shaped scene existed to judge. It exists.

## Decision

Three.js renders Inception Space. The Babylon.js slice stays in the
repository as a comparison spike, reachable at `index.html?debug`, and is
not part of the product.

## Why

ADR-0003 refused to pick an engine from a synthetic bake-off, and that was
right: the Phase 1 captures had both engines failing the 60 fps gate on the
worst-case full-face artwork path, with Three.js modestly ahead
(`docs/benchmarks/ENGINE-BAKEOFF.md`). A modest lead is not a decision.

What decided it is the month since. Everything product-shaped — the
zero-gravity corridor, pocket rooms, the paint scheduler, the quality tiers,
the sky easter egg, prop labels, and now the `.lpr` warp shader — was built
on Three.js and measured there. The engine question stopped being "which is
faster in the abstract" and became "is there a reason to port a working
museum", and there is not.

The one number that mattered turned out not to be an engine number at all:
in-room frame time was dominated by canvas-to-GPU uploads, which neither
engine causes and which `.lpr` plus a GPU renderer removes
(`docs/PERFORMANCE.md`).

## Consequences

- The bake-off entry (`?engine=three|babylon`) still works, but is
  advertised only under `?debug`. The landing page is the museum.
- `@babylonjs/core` stays a dependency while the spike does. Removing it is
  a separate cleanup, worth roughly 2.6 MB of install and nothing at
  runtime — the museum never imports it.
- If a future requirement genuinely favours Babylon (WebGPU maturity, say),
  this ADR is superseded rather than argued: the world manifest, movement,
  poses and artwork model are engine-neutral by design, which is what makes
  that possible.