Building 3D Rooms With AI: a Spec, Not Pixels

Ask any capable model to build a 3D room in HTML and CSS and, after enough iterations — costly in both tokens and time — you will get one. It works. It is also a one-off: unrepeatable, unverifiable, and no cheaper the second time. Getting valid, richly-detailed rooms reliably, in a single shot, a hundred times over is a different problem entirely — and it is not solved by a better prompt or a bigger model. It is solved by never asking the model for pixels at all.

Why hand-crafting pixels doesn't scale

Look at what one room actually demands. The model has to lay out the room. Then build each fixture. Then hold real-world proportion between every fixture and the room — a table that reads as a table beside a door that reads as a door. Then place each fixture with physical sense: tucked in a corner, flush to a wall, never floating, never overlapping another, never buried where no one can see it. Ask a model to satisfy all of that by emitting raw CSS transforms — pixel positions and 3D rotations, by hand — and it becomes a genuinely hard, expensive job even for a frontier model. And every room is a fresh gamble: the next one might seat the desk halfway inside the wall, and nothing in the system would know.

The instinct is to iterate — prompt, look, correct, repeat — until one room comes out right. That produces exactly one room. It does not produce a pipeline.

The reframe: a contract the model can't get wrong

So the model never emits the room. It emits a small spec — a layout.json — and deterministic code resolves that spec into the CSS 3D scene. The whole trick is in what the spec is made of, because the spec is where the hard constraints move from "hope the model got it right" to "true by construction."

It begins with one file that defines the world in real-world units:

js// engine/core/metric.js — the single source of truth
export const ROOM_M      = 4;     // floor edge, in METRES (width = depth)
export const ROOM_H_M    = 2.6;   // ceiling height, in metres
export const PX_PER_M    = 225;   // the only pixel number in the building
export const KEEPOUT_R_M = 1.5;   // the standing circle you can't put furniture in
export const EYE_Y_M     = 1.6;   // where the player's eyes are

A four-metre room, a 2.6-metre ceiling, and a rule that everything else derives from these numbers. Pixels appear exactly once, as a conversion factor. Everything the model reasons about is in metres — the units it already knows from the real world.

That single choice is what makes the model's job easy. A piece of furniture becomes just a box with a size and a place, in metres:

json{ "id": "credenza",
  "wall": "back", "along": 0, "out": 0.22,
  "parts": [
    { "id": "body", "size": [1.0, 0.8, 0.4], "pos": [0, 0.40, 0] } ] }

A one-metre-wide body, forty centimetres deep, seated on the back wall, pulled twenty-two centimetres into the room. A model writing that doesn't imagine pixels or perspective — it reasons the way a person does, because a table is about a metre wide whether you're a human or a machine. Proportion, the thing that was so expensive to get right in pixels, now comes almost for free. Placement — "in the corner, against the wall" — is a couple of fields, not a matrix of transforms. And the model isn't inventing geometry from nothing: it composes from a fixed catalog of validated primitives, arranging known-good pieces rather than drawing shapes.

And here is what a roomful of those numbers builds:

Because it's a spec, code can prove it

A blob of hand-authored pixels can only be eyeballed. A layout.json can be checked — walk the boxes, do the arithmetic, before a single frame renders:

textengine/layout/validate.js — geometry proven in milliseconds, pre-render

  bounds          a part pokes through a wall, floor, or ceiling
  collide         two pieces occupy the same space
  keep-out        furniture intrudes on the 1.5 m standing circle
  door-clearance  something blocks the doorway
  sight-line      a clue is hidden from every place the player can stand

That last check is the whole idea in miniature: for anything a player must read, code fires sixteen rays from the standing circle at eye height and proves the clue is visible from somewhere a player can actually stand. Before the spec, none of this was checkable — a model placed things by eye and a human hoped. After it, a room's physical logic is guaranteed before it exists, and the generator can place a hundred rooms without anyone squinting at one. (This is the same principle as drawing the answer in code — the whole scene is now data a program can read back — one level up: applied to space, not a single puzzle.)

The structure is a guardrail, not a cage

It's tempting to read all this as limiting the model — boxing a creative tool into a rigid schema. It is the opposite. A model handed a blank canvas and "build a room" is powerful but unpredictable; the same model handed the spec is powerful and production-grade. The schema doesn't shrink what the model can make — it defines a playground the model composes inside, freely, without being able to hand back something broken. Add one new primitive to the catalog and the model can combine it with every fixture and every room that already exists. That isn't shipping a feature; it is widening the space of valid rooms the model can build.

One artifact, two authors

The quietest win is the largest. Because the contract is plain JSON, a small drag-and-drop editor sits over the very same spec: a person can nudge a fixture a few centimetres and watch the same validator pass or fail in real time — a room's geometry argued about in millimetres, before it renders. The model generates the spec; a human tweaks it; the model regenerates; nothing is lost in translation, because there is one artifact and both of them speak it. The machine and the person are, finally, editing the same thing.

What to take from this

When a generative task is too hard or too costly to do reliably — and "hand-craft the pixels" almost always is — stop asking the model for the finished artifact. Put a spec between the model and the output: a small, declarative description in units the model already understands, assembled from validated primitives, that code can verify and a human can edit, and let deterministic code resolve it into the real thing. The structure is not a constraint on the model's power. It is the guardrail that turns a brilliant one-off into a pipeline — cheap, verifiable, and correct by construction, one room at a time.