AI stopped generating meshes and started writing code: four paths to 3D, and the missing acceptance test

Here is the number that made me look twice: a 4B model that outputs a single HTML file — three.js included, geometry and lights written as code — has 319,000 downloads and 967 likes on Hugging Face. It runs on a laptop in Q4.

Not a frontier model. Not a mesh generator. Four billion parameters writing JavaScript.

Within about two weeks, three more efforts landed on the same shape: Google treating a declarative subset of three.js as a compiler input, a Blender-side framework that edits scenes through bpy code, and an AR system that generates a pixel shader per frame from a sentence.

What they share is the output format. Code, not mesh files. No external assets, no textures baked to disk — the scene is a program.

That changes what you can do with the result, and it changes what "correct" means.

Why code is the right output

Generative mesh pipelines (Trellis, Meshy and friends) produce one file. It looks good, and if you want it different you regenerate and hope.

A code pipeline produces a program: parameterised, readable, diffable, version-controlled. "Make the lamp warmer and move the desk 20 cm left" becomes a few changed parameters instead of another sampling run.

The cost is equally clear: the code running is not the same as the picture being right. That is a software problem, not a rendering problem — which is why this round of work keeps circling back to verification.

Path A — three.js becomes the scene language

This is the mainstream path, because models are already good at front-end code.

Qwen3.5-4B-3D-Coder (CCORE, a fine-tune on Qwen3.5-4B, Apache 2.0) is the flag-bearer: the output is an HTML file that pulls in three.js and builds the scene procedurally. 319k downloads, 967 likes, and the companion ThreeJS-3D-Scenes dataset is public.

The interesting part is the size. 4B means the pipeline doesn't need a frontier model — GGUF Q4/Q8 runs locally. The model card also ships an optional vision projector (644 MiB) that lets it build a voxel scene from a reference image.

There is a GLB variant with 43k downloads that exports the three.js scene for Godot — worth noting because it folds code back into an asset format, giving up the editability that made it interesting.

Google went the other way. Three-Live doesn't trust model-written code inside a webview; it takes a declarative subset of three.js as a DSL, executes it in a sandbox, and serialises the result to GLB / USDZ in 2–5 milliseconds. Their thesis: code is untrusted input, so treat it as compiler input.

Path B — bpy, where "correct" is a state you can check

three.js answers "viewable in a browser". Blender answers "deliverable, renderable, inside a pipeline".

BlenderFORGE (arXiv 2611.10768) is the most complete attempt so far: open-weight multimodal models edit explicit scenes by writing bpy, and the tasks are shaped so state is verifiable — object placement, shape-key editing, lighting adjustment, material modification.

Their starting point is blunt: most existing systems lean on closed model APIs and lack a deterministic, state-verifiable execution environment, so you can neither train nor evaluate properly.

The architecture gives the trick away. In the middle of the pipeline sits a Blender Sandbox with two tools — a code executor and a preview renderer. The model changes something, runs it, looks at it, decides again. That is not one-shot generation; it is iterative editing with feedback.

Path C — don't generate geometry, generate the shader

If all you need is to change how something looks, the cheapest move is to skip geometry entirely.

ShadAR (arXiv 2610.19998) does exactly that: you say "blur all the people", it parses intent with GPT-5.2, locates the targets with YOLOv26, generates a pixel shader, and injects it into the AR passthrough — live. Not an offline render of one frame; every frame.

It's proof that lighting and post-processing are already inside the real-time pipeline for generated code. The engineering-side equivalent is a coding agent writing GLSL demos, or two models racing to write a Minecraft shader pack from scratch.

Path D — industrial scenes want dimensions, not atmosphere

Industry flips the problem: the requirement is exact size and placement.

SceneGenAgent (ACL 2025) generates industrial scenes in C#, and puts the difficulty where it belongs — spatial layout planning. Not "does it look like a factory", but are the positions, spacings and orientations right. The loop is structural planning → code generation → verification.

For anyone building line/plant tooling, this is the most useful of the four: in industrial scenes, "right" can be written down as a constraint.

The gap all four share

Every path above solves generation. What blocks deployment is acceptance.

EMNLP 2026 has a paper that names it: Apples on the Table? points out that text-to-3D-scene evaluation either compares "does it look like the prompt overall" or skips spatial reasoning altogether — nobody checks "X must appear to the left of Y". Their LEGO benchmark does fine-grained constraint checking.

BlenderFORGE's failure analysis is what that gap looks like in practice. Two trajectories: a model decides the nightstand is "to the left of the bed" and moves it left — further from the target; another misreads 90° as 180° and spins the armchair too far.

Red text in the figure marks the reasoning that failed. The code executed. The picture was wrong.

That is the sentence to remember from this whole wave: the distance between "it generates" and "it generated the right thing" is not model capability. It's verification.

Four paths, side by side

Three questions to ask any 3D pipeline

1. Is the output code or a file? A file means every change is a regeneration. Code means a one-line diff — and whether it can live in your VCS.
2. Can acceptance be automated? If "correct" can be written as constraints (position, size, material, light parameters), it can go into CI. If it's "looks about right", it's an inspiration tool.
3. Does it know what it is changing? Iterative editing with a run-look-decide loop was an order of magnitude more reliable than one-shot generation in everything above — because every edit gets feedback.

What we didn't do

• We ran none of this locally. Download counts, parameter sizes and task definitions come from the model cards, papers and Google's blog post. Nobody in this article has published a benchmark of the GGUF build on real hardware yet.
• The four paths are not exclusive. Three-Live is path A plus a compiler; BlenderFORGE is path B plus reinforcement learning; ShadAR is path C plus object detection. Real products will be combinations.
• The scale is small. A 4B model, four edit categories, single-scene demos. None of them has been tested at the scale of a building or a production line.

Sources

• Qwen3.5-4B-3D-Coder (CCORE, Apache 2.0): https://huggingface.co/ccore/Qwen3.5-4B-3D-Coder — GLB variant: https://huggingface.co/ccore/Qwen3.5-4B-GLB-3D-Coder
• Google Open Source Blog, Three-Live: https://opensource.googleblog.com/2026/11/introducing-three-live-ai-generated-3d-ar-webxr.html
• BlenderFORGE (arXiv 2611.10768): https://arxiv.org/abs/2611.10768
• ShadAR (arXiv 2610.19998): https://arxiv.org/abs/2610.19998
• SceneGenAgent (ACL 2025): https://aclanthology.org/2025.acl-long.873/
• Apples on the Table? / LEGO benchmark (EMNLP 2026): https://aclanthology.org/2026.emnlp-main.2310/