INFINIZOOM
Build infinizoom: a procedural infinite-zoom world. The deliverable is a
self-contained BunJS project. Running `bun run server` must build and serve it
(wire up the corresponding "server" script in package.json). Three local assets
exist in this directory and must be used: ./macbook_interior.png (a real MacBook
Pro teardown photo), ./apple_m4_scheme.png (Apple's M4 die floorplan diagram),
and ./wallpaper.jpg (a 1920×1200 desktop wallpaper photo). Load the wallpaper
from this local file — never fetch content from external servers (the sole
exception: three.js itself may be imported from a CDN by URL).
The world
A single 3D world is traveled indefinitely along a fixed camera track that zooms
through these levels:
Main route: a room → a desk → a MacBook Pro → inside the chassis → the logic
board → the Apple M4 package → the M4 die → a performance core → an integer ALU
block → a standard logic cell → a FinFET transistor → a material cross-section
inside the fin → the silicon crystal lattice → one unit cell → an atom → its
nucleus → a nucleon → a quark. Logic gates and circuits (AND, OR, etc.) should
be animated as it computes.
Screen branch: exactly one bifurcation, hovering above the MacBook. Choosing the
other side dives into the display instead: the screen → the display panel →
pixel tiles → a pixel block → one pixel → its R/G/B sub-pixel LEDs → the
emissive layer → an emitter molecule → and converges to the same atom → nucleus
→ nucleon → quark tail. The leds must be accurate: 1-to-1 mapping from screen
pixels to leds, and their colors must match the color of that pixel. The screen
is animated and the LEDs are updated to match the animation in real time.
Riding the track forward IS zooming in; riding backward is zooming out. The
design must extend additively: adding a new structure = one render function +
one call in its parent; adding a bifurcation = one more route; a future backward
extension (t < 0: out the window → city → planet → universe) must require only
prepending track levels. A time parameter must be threaded through everything so
all animation stays possible at any depth.
Architecture (hard constraints)
- Mutable state is EXACTLY: one float t (position along the track), one branch
bitstring (0 = left/A, 1 = right/D; a bit is pushed when passing a fork and
popped when backing out below it), and raw input (keys held, mouse position).
Every frame is a pure function of (t, branches, raw input, wall-clock time).
No other state — no scene graph, no node objects, no stored world data, no
caches of world structure.
- Renderers are pure functions that call their children directly: render_room()
calls render_desk() calls render_macbook() … down to render_quark(). No
dispatch layer, no classes. The call stack is the scene traversal.
- Scale-space warping via local unit frames: floats cannot hold meters and
femtometers at once, so every renderer works in its own ~unit-sized local
frame, and the camera is re-expressed into each child frame. Geometry math is
done camera-relative in doubles, cast to float only at the very end, so the
picture is artifact-free across all ~17 decades of scale. The exact same
layout constants must place structures for rendering AND author the track —
one source of truth, or the camera drifts visibly off the line.
- Immediate-mode rendering over three.js: every frame, the recursion emits
primitives into instanced pools; three.js is only a rasterizer. Nothing
off-screen or sub-pixel is emitted or recursed into.
The track and the camera
- Speed: fast. The whole main ride should take roughly 20 seconds, with a
comfortable, constant-feeling time per level (exponential zoom feel) and
gentle easing near the fork and the track ends.
- Shape: gently curved arcs. Not wandering, roundabout, or random-direction —
but also NOT dead-straight rays. Soft, purposeful curves.
- The green line: the track is always visible in-scene as a translucent green
line. It must be an infinitesimal line: ~2 pixels wide on screen at EVERY
distance, implemented as a true GL line primitive (not tubes, not rods, not
meshes of any kind), transparent (never rock-solid), and it must NEVER grow
wider as it approaches or passes the camera — it is literally a path line,
visible both near and far.
- The camera must never look at nothing. At every instant of the ride the view
must be filled with structure. Concretely: every level approach is a diagonal
glide (roughly 45°) over the parent surface — never a low horizontal skim
(which puts empty void in the upper half of the screen) and never a
straight-down drop (which degenerates the camera roll). Every level must
render rich, non-uniform content at the distance where the camera arrives —
never a flat gray plate.
- Dive points land dead-center inside meaningful sub-structures. The line must
enter the CENTER of one of the small colored squares (a specific core on the
die, a specific block in the core, a specific pixel on the screen) — never a
border, edge, gap, seam, or gray filler zone. The boundary transitions between
levels (e.g. performance core → integer ALU block, "100 µm across") must be
scrutinized: the camera must be looking at detailed structure the whole way
through.
- Occlusion never pops: every shell the camera is about to pierce (the keyboard
deck, the transistor's gate, the LED's cathode, the screen's cover glass…)
fades away smoothly as a pure function of t shortly before the camera reaches
it, and fades back identically when riding out.
Controls and HUD
- W rides deeper, S rides back.
- At the bifurcation: a big translucent ‹ on the left edge and › on the right
edge of the screen, each labeled with its key (A / D), with the currently
selected side highlighted/glowing. No sentence-style instruction text.
- Mouse moves the glance direction with a full 360° range — the rider can look
all the way around, including behind.
- A title at the top-left always names where we are right now (e.g. "performance
core") together with the current physical scale ("3.2 mm across").
Content — fidelity and density
Everything must be densely detailed — think "10× more detail than feels
sufficient" — and hiding must be un-aggressive: distant and peripheral objects
stay visible; more detail is always preferred over less. Everything plausible
must be animated and alive.
- The room and desk: a believable day-lit room (window, curtains, floor, walls,
shelf, chair, door, rug, a wall clock whose hands actually run, lamps, cables)
and a believable desk (the MacBook, a potted plant, paper, a mug, books,
phone, pens…).
- The MacBook exterior: correct proportions, full keyboard with per-key legends,
trackpad, ports, hinge, screen bezel with notch and camera.
- The MacBook interior: there are many components inside a MacBook — reproduce
them in pixel-perfect locations matching ./macbook_interior.png: the two fans
(with visibly SPINNING, clearly readable impeller blades — use few chunky
blades, not a dense blur), the S-curved heat pipe and heat spreader, the black
logic board carpeted in passives with EMI shields and chips, the antenna bar
along the hinge, side port boards, the 4-corner + 2-tall-center battery cell
layout with printed labels, aluminum struts, the trackpad flex cable running
down the middle to its gold connector, the flanking speakers, tape, thermal
pads, screws — all of it.
- The M4 die: block placement faithful to ./apple_m4_scheme.png (4 P-cores +
shared L2, 6 E-cores + L2, 10 GPU cores, 16 Neural Engine cores, SLC,
media/display engines, ISP, Secure Enclave, memory PHYs on the edges), with no
bare/gray substrate anywhere — every area is a labeled block, and blocks show
interior sub-structure at every intermediate zoom. The CPU interior (core
floorplan: caches, decoders, schedulers, ALUs, FP units, register files…) must
be greatly detailed, not a few flat rectangles.
- Digital circuits doing operations — explicitly a top-priority feature: the
zoom must pass through logic that is visibly COMPUTING. Standard cells are
real gates (AND/OR/NAND/NOR/XOR/NOT): their input nets carry live 0/1 signals
(bright = 1, dark = 0), their output is the actual boolean function of the
inputs, pulses race along wires when gates switch, and whole logic blocks
twinkle with switching activity at every zoom level.
- Animated electronic simulation: the FinFET's gate runs a live drive waveform,
and while it is open, charge carriers visibly flow from source to drain.
Continue through real materials: gate oxide, dopants, the diamond-cubic
silicon lattice at its true 0.543 nm pitch, into atoms with orbiting
electrons, a nucleus with protons/neutrons and an animated gluon field, down
to quarks.
- The screen must be REAL: a real image at real MacBook-panel fidelity — the
bundled ./wallpaper.jpg photo as the desktop background, with a procedurally
drawn OS on top (menu bar, dock with recognizable icons, overlapping
application windows: a code editor with syntax-colored lines, a file browser,
a terminal with a blinking cursor, and a video window that visibly plays,
animating at full frame rate). Never a mosaic of colored squares. All levels
of the screen (full panel → tiles → pixels → sub-pixel brightness) must sample
the SAME image function so content never changes across zoom, and detail must
increase strictly monotonically as the camera approaches — at no zoom distance
may the screen become LESS detailed than it was a moment before.
- The sub-pixel LEDs: each LED is lit by the ACTUAL channel value of the
on-screen image at that exact pixel — realistic and accurate, not default
colors. Because the screen animates, the LEDs visibly CHANGE color over time.
The dive targets a pixel inside the playing video, where R, G and B clearly
differ from each other and keep changing. Inside, an LED is not a solid: model
the full OLED stack — the TFT drive circuit with its data/scan lines and
storage capacitor, the reflective anode, transport layers, the emission layer,
the semi-transparent cathode, auxiliary wiring, spacers, encapsulation — with
a live simulation: holes drift up, electrons drift down, they recombine in the
emission layer with a flash, and photons fly up and out. Below that, the
emissive layer resolves into a molecular film, then a single emitter molecule
built of real atoms, joining the shared atomic tail.
Visual-quality laws
- Nothing ever pops, flickers, or z-fights — anywhere, at any scale, moving in
either direction. In particular: never emit overlapping coplanar surfaces or
nested coincident translucent volumes; and any material exempted from fog
(emissive screens, glass, glow) must still be manually distance-faded and
culled, or shells belonging to enclosing structures will haunt the camera at
deep zooms as giant flickering planes.
- All LOD transitions are smooth morphs or strictly-finer refinements of
identical content — never a swap to something coarser, blurrier, or
differently colored.
- Spinning/periodic animations must be tuned to be perceptible (no temporal
aliasing that freezes or scrambles them).
- Runs at 60 fps.
Code Quality
Ensure your implementation is concise, minimal, elegant. Use pure functions as
much as possible. Keep it very Haskell-like, even though it is TypeScript. Most
of the complexity of the function comes from the different objects that are
rendered, and each object is a render function. Each renderable object must live
in its own file at src/render/<name>.ts — that directory is the one that scales
as we add more renderables. Organize the project such that it can scale by just
adding more render functions/files under src/render/. Avoid unnecessary
complexity.
