Dev.to WebDev 🛠 Dev 👁 0 📖 5 min read

One prompt, 18 files, one NaN: what 'one-shot' 3D scene generation actually looks like

"One-shot" 3D generation gets read as: type a sentence, get a picture. Here is the actual log from a single prompt given to Claude Fable 5.2 on the day it launched (November 9): 18 files written, 12 shell commands run,

"One-shot" 3D generation gets read as: type a sentence, get a picture.

Here is the actual log from a single prompt given to Claude Fable 5.2 on the day it launched (November 9): 18 files written, 12 shell commands run, 17 files read back, a browser opened for visual acceptance, and one NaN found by reading pixel values out of the render buffer — and fixed — before the picture was considered done.

The author's own definition of "one-shot" is narrow and useful: one prompt, no second conversation, no manual post-processing. No retouching. Which is not the same as no tools.

The two 3D outputs were a 360° "early morning seaside lighthouse fishing harbour" and a 3D web page of the Apple Jing'an store in Shanghai.

The output is 18 files, not one HTML blob

From the model's own progress report inside the log:

"All 18 files are written (the page, the local Three.js library, and 17 modules). Now moving into browser acceptance: syntax check first, then actually open it and look."

That single line rules out the "it spits out an HTML file" picture. It split the scene into modules, vendored Three.js locally — because the prompt demanded the thing run offline — and then went into the browser to check the result.

And that browser step was real: "12 commands run, 17 files read."

The prompt is a checklist, not a mood board

The most transferable page of the whole experiment is the requirement block. Roughly:

Build a 360° immersive scene of a seaside lighthouse harbour at dawn with Three.js, openable by double-clicking index.html (offline, classic script tags, no ES modules).

All assets must be generated procedurally in code — no external images or models. Low-poly for distant objects, detail preserved up close; seeded randomness so every run is identical; keep the polygon count and post-processing cost in budget so it stays smooth; zero console errors. Write the code module by module, and report progress after each file.

Two things follow.

"All code, no assets" is a prompt constraint, not a model capability. Skip that sentence and the model will happily reach for textures and GLBs.

The other bullets are acceptance criteria wearing aesthetic clothes. "Offline, no ES modules" pins the delivery format. "Seeded randomness" pins reproducibility. "Module per file, report progress" pins maintainability. "Zero console errors" pins verifiability. None of them say "make it atmospheric" — that is the part you cannot check.

How it found its own bug

The log entry that matters most:

"The frame is broadly fine — composition and silhouettes are OK, and the console is clean. But lit objects render black, the sea is blown out, and the lighthouse beam has a bright artifact at the tip. Let's find the cause first."

"Read the pixel values of the render buffers at each stage to locate where the black and the blown-out areas come from."

"Root cause found: in the sky shader, the back-to-sun azimuth combined with the pow/normalize terms at zenith produces NaN, which is baked into the environment map and breaks every lit material and reflection. I'll add guards everywhere a shader can hit a negative base or a zero vector."

"With the NaN gone the frame is correct: sunrise, reflection band, lighthouse, water reflections all present. Now checking south and west faces."

That is four steps: render a frame → read pixels → localise to a shader → guard and re-render.

That is not generation. That is debugging — of shaders the model had written minutes earlier.

What the pretty frame costs

The lighthouse scene ran for tens of minutes. The second one is the honest number: about 2.5 hours for the Apple store page, split roughly into ~1 hour spent searching for press coverage and zooming through close to a hundred reference photos, and ~1 more hour modelling.

Budget-wise: 10 tasks in 4 hours burned about 24% of the quota. The author's conclusion was blunt — expensive enough that he would keep daily work on a cheaper mix of models.

One detail worth keeping: he noticed image previews appearing inside the model's thinking summaries. It was looking at what it drew — not writing blind.

What to copy

  1. Write the prompt as acceptance criteria, not as a brief. "Offline-runnable / seeded randomness / zero console errors / one module per file" beats any amount of "make it feel calming".
  2. Tell it to render a frame and inspect it. Explicitly: check for black lit surfaces, blown highlights, missing faces in the distance. Reading the buffer is what made the NaN findable at all.
  3. Ask for source, not artifacts. You want index.html plus modules — diffable, parameterisable, committable. A baked GLB can only be regenerated.

What this doesn't prove

  • It is one person's test, not a reproduction. Timings, quota burn and model behaviour are all self-reported.
  • "One-shot" does not mean "no tools". It used a browser, a local Three.js copy, web search, and roughly a hundred reference photos. The claim is only: no second prompt, no hand retouching.
  • The video pipeline is unstated. A 40-second tribute clip is mentioned; how the frames were produced and encoded is not described, so don't infer it.
  • The scale is one small scene and one building. No production line, no city, no engineering-grade tolerance — that is the industrial path (C# / parametric scene code), which this experiment never touches.

Why this is the interesting half of the 3D story

Most of the discourse is about can it generate. The useful question, once code is the output format, is can you accept it. Here the answer was mechanical: the model could read its own pixels, so a wrong blank could be turned into a located bug, then into a guard clause, then into a correct frame.

The next time someone says "one prompt, one 3D scene", ask what was in the log.

Sources

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.