从房间缩放到夸克的3D场景

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.

出处：作者给出的链接。提示词保留原文语言，未做改写。

作者提到的工具

更多3D 场景案例

• 5:06

  用共享提示词一夜生成的精致场景

  1685.1万 播放

• 0:22

  视频转4D高斯点云重建

  87.8万 播放

• 3:47

  程序化生成的海岛模拟场景

  85.2万 播放

• 2:37

  根据流传提示词制作的场景

  59.9万 播放

• 1:00

  日式风景中的可玩船只场景

  46.7万 播放

• 1:31

  Three.js骑车鹈鹕演示

  41.6万 播放