Why
The interesting word is procedural, and it is not a synonym for generated. A generated model is a mesh: a bag of vertices that arrived somehow and can now only be edited by hand. A procedural model is code that produces geometry when run, so its subject is an argument, its proportions are variables, and changing it means changing a line rather than re-sculpting a surface. That is why the post can say the tank can be swapped out for anything else — if the tank is a function, the tank is a parameter.
This repository already made the same move, one domain over. Nothing in docs/topics/ is written by hand; every page is produced from lib/poc-cards.ts by a generator. The consequence showed up concretely this week: when two workspaces both regenerated those pages, the fifty resulting conflicts were not resolved by merging HTML — they were resolved by merging the source and re-running the generator, because a conflict in a derived file is never fixed in the derived file. An LLM that emits the generator instead of the artifact inherits exactly that property, and it is worth more than the visual: code can be diffed, reviewed and parameterized; a mesh can only be looked at.
And the claim has a direction problem worth catching. 2D schematics into 3D models says the drawing is the input. But the demo's own buttons — FRONT, PLAN, ISO — are the standard orthographic projections that CAD software produces from a 3D model, and the blueprint aesthetic is the cheapest of those views to render. So the arrow may point the other way: one parametric model, six camera angles, one of which looks like a schematic. That is not an accusation; it is the first thing to check, and it is checkable in a single attempt.
How it works
Three things that get called the same thing
| What the output is | Editing it means | Can it be reviewed? | |
|---|---|---|---|
| Generated mesh | Vertices | Sculpting by hand | No — you can only look at it |
| Parameterized model | Fixed code, exposed knobs | Turning a knob the author anticipated | Partly — the knobs, not the shape |
| Procedural, as claimed here | Code written per subject | Editing a line | Yes — it is a diff |
The post claims the third. The demo is consistent with the second. The difference is invisible in a video and obvious in one experiment.
The experiment, in full
One attempt, one input: a schematic of something from a domain it has never rendered — not a vehicle, not military, ideally something with an irregular shape rather than boxes and cylinders. Then read the result against three outcomes:
- A model appears and is roughly right — the claim holds, and the interesting question moves to how the code represents shape.
- A model appears but is a tank with different proportions — it is a parameterized generator. Still useful, differently framed.
- Nothing usable appears — the schematic was never the input; the blueprint was an output view all along.
Why it belongs in this catalogue at all
Not for the tank. For the shape of the output. The recurring difficulty with model-produced artifacts is that they cannot be checked — a paragraph, an image, a mesh all arrive as finished surfaces with no seam to inspect. A model that emits a program instead moves the artifact into a form that already has review tooling around it: version control, diffs, tests, parameters with names. That is the same reason this repo keeps card data as the source of truth and treats every page under docs/topics/ as disposable output, and it generalizes far past 3D.
Honesty about the source
This is a social post with no repository, no paper and no primary link, forty-two minutes old at capture, carrying 19 likes against 16,000 views — engagement that says seen rather than verified. Nothing here should be repeated as fact. The card exists because the distinction is worth holding, not because the demo is established.