Atlas

Prompt: 海边的灯塔 (5 characters). Same prompt + same 2D code, lifted twice — once with the v1 lift prompt (no semantic types taught) and once with the v2 prompt (18 named atom + component types). v1 emit: 0 atoms (the original 3D had no moon and no stars). v2 emit: moon × 1, star × 15, plus the tower shown here. The library expansion → prompt rewrite → atom emission is a fully quantified loop — scripts/regression reproduces the result for $0.07 per demo.

→ Try the live gallery · no API key needed, click any of 8 pre-lifted scenes and fly through with WASD.

Prompt: 一座哥特式大教堂 (6 characters). 2D code: emitted but failed to render (closing-vertex bug in one polygon call). 3D scene: read by the lift LLM as semantic structure (twin towers + rose window + lancet portals + flying buttresses + crossing tower), compiled into editable SceneData, rendered via BOB GPU. Two parallel pipelines from prompt to viewer — only one needs to succeed. Diffusion has one.

Atlas — the LLM-native illustration platform. An atlas in differential geometry is a collection of charts covering a manifold. Here it's a collection of forms × renderers × patterns × scenes — composed via four orthogonal input sources (LLM prompt, generator, 2D editor, 3D editor) into a single renderer pool. Built on sdf-js — the underlying open-source SDF library. Signed distance functions are a paradigm where diffusion models structurally cannot compete.

Why this exists

The thesis (5 points)

1. AI is the 4th industrial revolution. Compute capability is reshaping how creative work happens.
2. Coding is AI's strongest commercial vertical. LLMs are far more reliable at writing code than at producing pixels.
3. SDF + LLM is the native illustration paradigm — diffusion cannot reach it. Diffusion models fail in any domain where structure must be exact (clocks, charts, maps, fonts, emoji, icons, architectural diagrams). They hallucinate visual plausibility but not geometric correctness. LLM × SDF generates provably correct structure because the LLM writes code, the code defines exact geometry, and rendering is deterministic. The Pasma / Tyler Hobbs plotter art tradition operates in exactly this space.
4. Form × Renderer × Pattern × Motif-Library: 4 independent axes, each tradable as preset IP. Same SDF rendered through different renderers (silhouette / stipple / Pasma lines / Lambert) × different pattern backgrounds (Truchet / Hilbert / Gosper / Motifs / none) × different motif libraries = combinatorial explosion of style space. Every axis is an artist-licensable asset class.
5. → A new creative-tool platform becomes possible — not Photoshop (raster), not Illustrator (manual vector), not Midjourney (diffusion). Something else, where you describe in natural language and get editable, exact, plotter-ready vector art.

The diffusion boundary (where we win)

This is a structural separation of domains, not a "diffusion is worse" claim. Diffusion owns photo-realistic / impressionistic / "vibe" generation. We own everything that needs geometric exactness:

The architecture boundary (where we differ from three.js / Unity / sampled-asset AI)

The diffusion boundary above is about input modality (pixel-sampling vs symbolic structure). This second boundary is about system architecture — what kind of 3D substrate the AI is generating into. Same active-concession pattern: each system below is excellent within its own architecture; the question is which architecture is reachable by an LLM writing code.

Two families, not two products. SDF is one point in a larger symbolic-representation family that LLMs can natively write: OpenSCAD, CadQuery / build123d, JSCAD, L-systems, CSG trees, bpy procedural scripts, parametric CAD. The opposing family is sampled-asset: meshes, NeRF, Gaussian Splat, voxel grids, point clouds. The load-bearing claim is family-to-family. SDF's specific advantages within the symbolic family — dimension-agnostic (d(p): ℝⁿ → ℝ works at any n), single-expression representation (a tree, not an API call sequence), GPU-native compile path, continuous infinite resolution — make it the optimal point for web-native simulator work; but the architectural contrast below runs at the family level, not as a product-vs-product fight.

A rung map across existing 3D systems — by state shape × loop contract × LLM writability:

three.js sits at rung 1.5 — it has mesh state (great for rendering) but no enforced loop contract (dynamics are user code). The same three.js app can be entirely static, keyframe-animated, or coupled to a physics engine — three.js doesn't pick. That's why the clean shorthand below is "graph without a loop contract."

Why sampled-asset AI (VAST Eden, Tripo, Trellis, Hunyuan3D, CSM, Sloyd, Meshy) is structurally outside the rung-2 world-model market:

1. Identity-preserving edit at object granularity is impossible. Object-level regeneration is real — these systems can swap one door without disturbing the rest of the scene. But say "make this door iron and keep the dents and the handle." What you get is a different door, roughly door-shaped and iron, not the door you had with iron and the dents preserved. Iteration is resampling at object grain, not editing. Atlas's circle(0.3) edited to circle(0.35) is the same primitive, larger — a different category of operation altogether.

2. Engines give you parameter knobs over a family of laws, not authorship of laws. setGravity(0, -12.7, 0) is one line — Bullet, PhysX, Rapier all handle 1.3× Earth's gravity trivially. Custom forces inside the Newtonian family (n-body gravity, magnetism) are doable by bypassing the built-in pipeline — Outer Wilds famously did this in Unity, reinventing a small rule runtime inside the engine to escape Unity's default gravity assumption. (That game's existence is the strongest field evidence we have: brilliant teams have to fight the engine's defaults to get behavior the engine didn't anticipate.) What no engine gives you is law-family authorship — non-Coulomb friction, modified inertia, position-varying time flow — because the shape of "what must be true" (Signorini conditions, Coulomb cones, shared global dt) is compile-time fixed in the solver's C++. Determinism on this path is an engineering achievement (Rapier supports cross-platform-determinism mode; RTS lockstep physics is a 20-year discipline). On Atlas, both law authorship and determinism are structural defaults — you have to break them (Math.random outside the rng helper, variable dt, mutable cross-tick state) to lose them.

3. State lives in three disjoint stores: mesh arrays (GPU), scene-graph transforms (CPU), physics-engine internal buffers (solver-private). Fork, time-travel, multiplayer-sync, audit are each engineering projects on this path. On Atlas they are properties of the substrate. (Determinism CI verifies bit-equal replay across 600 ticks; full-mode log is human-readable JSON.)

Atlas inverts the family on all three:

1. Output is a symbolic expression tree. The LLM is writing expressions.
2. Loop contract is step(world, actions, dt) → newWorld, a pure function. The LLM is writing functions, not configuring a solver.
3. State is one World object. Savegame is serializing it.

Where we don't try to compete. Atlas's simulator covers authorable-laws dynamics — fields, swarms, orbits, resources, rule systems, particle flow, rocket-style integration. It does NOT cover solver-grade contact physics — a 500-box pile, ragdoll, constraint-rich rigid-body chains. Bullet / PhysX / Rapier do those well; we don't try to. The trade is explicit: **give up solver-grade contact, gain savegame-native composable worlds whose laws the LLM authors