Building a 3D Furniture Catalog with AI: From Recipe to Asset
Most "AI-generated furniture" means a model producing a mesh directly — and inheriting
every limitation that comes with an opaque, uneditable blob of geometry. Flur's
/catalog/create takes a different approach: the model describes the piece, and a
deterministic engine builds it — then checks its own work, and tells you honestly when
it can't get closer on its own.
From photo to AssetRecipe
The process starts with a photo of a piece of furniture. First, the model looks at the photo — a distinct perception step before anything gets written down. Then a vision-language model writes a structured AssetRecipe from what it saw — a description covering dimensions, proportions, material choices, and form, not pixels or a mesh. The model's entire job is description: turning a photo into a specification precise enough that something else can build it correctly.
That's a narrower job than it might sound, and the narrowness is deliberate. The model isn't asked to imagine what a plausible piece of furniture looks like from a prompt — it's asked to describe a specific, existing object precisely enough that a separate, deterministic step can reproduce it. Constraining the model's role to description is what keeps the output tied to something real rather than a generative guess.
From recipe to asset
A deterministic Three.js pipeline takes that recipe and builds the actual mesh from it — geometry constructed according to the recipe's dimensions and proportions, materials applied according to its material choices. Nothing about this step is generative or probabilistic; the same recipe builds the same asset every time, which is exactly what makes the output predictable and inspectable rather than a one-off result you either accept or regenerate and hope for something different.
That determinism also makes debugging possible in a way generation doesn't. If an asset comes out wrong, the recipe is right there to inspect — a wrong dimension or a mislabeled material is visible and fixable directly, rather than being an opaque property of a black-box output with no intermediate step to point to.
Critique, redraft, and honest failure
Building the mesh isn't the last step — the agent then compares its own build against the source photo and, when they don't match closely enough, redrafts the recipe and tries again. This is a loop, not a single shot: the same "does this match" question gets asked again after every redraft, up to a small number of attempts.
What happens when it still doesn't match matters as much as the loop itself. Rather than silently shipping a wrong asset or hiding the mismatch, the tool says so directly — "the basic shape and proportions didn't match closely enough after 2 attempts" — and hands the recipe over with every dimension, material, and part still editable, ready for someone to adjust it by hand or start over from another photo. An honest failure with an inspectable recipe beats a confident-looking wrong answer with nothing to correct it against.
Why this keeps assets editable, scale-accurate, and orderable
A directly generated mesh is an opaque blob — there's no "legs," "seat," or "cushion" in it for anything to act on, and no reliable dimension to query. A recipe-built asset is the opposite by construction: the dimensions that built it are still attached to it afterward, so asking "how wide is this" gets a real answer instead of a guess, and changing a material or a proportion means editing the recipe and rebuilding, not manually reworking a finished surface.
That same structure is what makes an asset scale-accurate and orderable rather than approximately-furniture-shaped. Because the recipe specifies real dimensions, not a generative model's best guess at what furniture usually looks like, what shows up in a scene is dimensionally trustworthy — which matters directly the moment a visualization becomes the basis for actually purchasing the piece.
The facing/rotation taxonomy
Correct dimensions and correct placement still aren't enough on their own — an asset also has to face the right way to read as correct in a room. A bed's headboard belongs against a solid wall, not floating mid-room; a desk should face into usable floor space, not into a corner; a wardrobe needs clearance in front of its doors, which means its orientation has to account for which side actually opens. None of this is a single rule that applies universally — it's a per-category taxonomy, where each type of furniture carries its own facing logic tied to how it's actually used in that position.
This is also where recipe-based construction pays off a second time. Because the recipe describes what the object is — a bed, a desk, a wardrobe — rather than being a category-blind mesh, that category can drive an orientation rule automatically. A generated mesh with no category attached has nothing for a facing rule to key off of — the taxonomy isn't an extra step bolted onto the recipe approach, it's a direct consequence of the recipe already knowing what kind of object it's building before geometry even exists.
How this differs from other AI 3D generation
Text-to-3D and image-to-3D mesh generators output geometry directly, in one pass, with no intermediate structured description — fast, but the result is opaque afterward. Radiance-field reconstruction captures how an existing real scene looks, which solves a completely different problem: viewing something that already exists, not creating something new that has to be editable and placeable. The recipe-based approach used here sits apart from both: slower per asset than a one-shot mesh generation, because authoring and building are separate steps, but every asset stays inspectable, editable, and correctly oriented long after it's built — which is the property that actually matters once a piece has to drop into a real room, survive an edit, and get ordered for real rather than just look convincing in a single rendered frame.
From asset to catalog
A built asset isn't useful until it's registered — added to the catalog with its category, dimensions, and facing metadata attached, the same fields visible on its detail page. From that point it's just another catalog piece: searchable, placeable in the 3D editor, and orderable, exactly like the furniture that shipped with Flur from the start.
Getting started
For how this recipe-based approach compares to the other AI 3D generation techniques in use today, see AI models for 3D: what actually generates a 3D room. For how the facing taxonomy connects to broader placement logic once an asset is in a scene, see how AI places furniture in a 3D room. And for where catalog furniture fits into a full room build, see the 3D model creation pipeline, floor plan to walkable tour.
See how it works or request early access to build a 3D asset from your own furniture photo.