AI Models for 3D: What Actually Generates a 3D Room
"AI 3D generation" gets used as a single phrase for at least four genuinely different techniques, and they don't produce the same kind of output. If you're evaluating any tool that claims to generate 3D content, the technique behind it — not the marketing copy — determines whether what comes out the other end is something you can actually use downstream.
Text-to-3D and image-to-3D mesh generators
These models take a text prompt or a reference image and output a 3D mesh directly — vertices, faces, and usually a texture map, produced in one generation pass. The result can look striking from the angle it was optimized for. The limitation shows up the moment you need to change anything: the mesh is an opaque blob of geometry with no underlying description of "legs," "seat," or "cushion" for anything to act on. Editing means manually reworking the surface, or generating again and hoping the new result is closer to what you wanted. There's also no reliable way to ask the output "how wide is this" and get back a trustworthy number — the geometry is whatever the model happened to produce, not derived from a real-world dimension, which matters a great deal if the object needs to actually fit somewhere or be manufactured to spec.
Radiance-field reconstruction
This is the technique behind Gaussian splatting and similar methods: capture a real scene from multiple photos, and reconstruct how light behaves at every point in space well enough to render new viewpoints that weren't in the original photos. The output is genuinely photoreal from any nearby angle — because it's reconstructing something that actually existed, not inventing geometry. It's also not editable geometry in any conventional sense; there's no mesh, no material list, nothing to query for "how wide is this," because a splat field is a captured appearance, not a structured object.
Diffusion-based texture synthesis
A narrower but genuinely useful technique: given existing geometry, a diffusion model generates a plausible texture or material map for it — wood grain, fabric weave, surface wear — without touching the underlying mesh. This is a texturing step, not a generation step; it assumes the geometry already exists and focuses entirely on how the surface looks.
VLM-driven parametric authoring
The newest of the four, and the one most often missed in surveys of "AI 3D generation": a vision-language model doesn't output geometry directly. Instead, it writes a structured build recipe — dimensions, proportions, material choices, form — that a deterministic engine then executes to build the actual mesh. The model's job is description, not construction.
This is the approach behind Flur's /catalog/create: a VLM writes an
AssetRecipe, and a deterministic
Three.js pipeline builds it — no third-party mesh-generation vendor sits in that loop.
The output stays a structured object all the way through, not a rendered guess.
The practical consequence is that the same recipe that built the asset can also describe it after the fact. Ask what category a piece belongs to, what its footprint is, or which wall it's meant to face, and there's an actual field to read the answer from — because that information was part of the build instructions, not something reverse-engineered from a finished mesh after the fact.
The tradeoff that actually matters
Every one of these techniques trades against the same axis: editability. A generated mesh and a reconstructed radiance field both give you something to look at, but neither gives you something to query — you can't ask a splat field "how wide is this room" or ask a generated mesh "swap this material" and get a clean answer, because neither one kept the information a recipe keeps by construction.
A recipe-based asset is slower to produce per object than a one-shot mesh generation, because it has to be authored and then built, not generated in a single pass. What it buys back is that every asset stays inspectable and editable after the fact — you can change a dimension, swap a material, or query a piece's category, because that information was never thrown away in the first place.
Which one to reach for
None of these techniques is universally better — they solve different problems. If you need a photoreal view of a room or object that already exists, reconstruction is the right tool, and no mesh generator will get you there. If you need new, scale-accurate, editable furniture that has to drop correctly into a real room and stay adjustable afterward, a recipe-based approach is the one built for that job. And if you already have correct geometry and just need a better-looking surface on it, diffusion-based texturing solves that narrower problem without touching anything else — it isn't a competitor to the other three so much as a finishing step that assumes one of them already ran.
Getting started
For where recipe-based authoring fits into a full room build, see the 3D model creation pipeline, end to end. If you're specifically weighing radiance-field reconstruction against editable geometry for an interior walkthrough, see Gaussian splatting vs. mesh vs. panorama. And for a closer look at how Flur's recipe-based catalog tool actually works, see building a 3D furniture catalog with AI. For how a similar VLM-driven approach applies to editing an existing scene rather than generating a new asset, see editing a 3D room by chat.
See how it works or request early access to try recipe-based generation on your own furniture.