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, unedittable blob of geometry. Flur's
/catalog/create takes a different approach: the model describes the piece, and a
deterministic engine builds it.
From photo to AssetRecipe
The process starts with a photo of a piece of furniture. A vision-language model reads it and writes a structured AssetRecipe — 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.
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.
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, end to end.
See how it works or request early access to build a 3D asset from your own furniture photo.