Text-to-3D and AI Modelling

"Text-to-3D" is a loose umbrella over three quite different pipelines, and knowing which one you are using explains what you will get. The first is genuine text-to-3D: a diffusion-style model, descended from the DreamFusion line of research, hallucinates a 3D form from a text prompt. It is the most magical and the least reliable - fine for a stylised prop, hopeless for anything precise. The second, and by 2026 the more practical, is image-to-3D: you give a model one or several images and it reconstructs a mesh. Meshy, Tripo, Rodin and Kaedim live mostly here, and because they are anchored to a real picture the results are far more controllable. The third is not generative at all but AI-assisted capture: photogrammetry and, increasingly, Gaussian splatting (via apps like Luma or Polycam) turn a phone video of a real object or space into a 3D representation.

These roads produce very different artefacts. Capture gives you a faithful record of something that exists - a heritage cornice, a site, a chair you love. Image-to-3D gives you a plausible object shaped like your reference. Pure text-to-3D gives you an invented blob with the right vibe and no guarantee of correctness. All three share one trait that governs everything downstream: they output meshes, not the parametric, data-rich objects a BIM tool wants. That single fact is why the rest of this lesson is about fit, not magic.

It is also worth being honest about the rate of progress, because the demos move faster than the useful reality. Each year the meshes get denser, the textures sharper, and the generation quicker - Meshy, Tripo and Rodin in 2026 produce genuinely attractive objects in under a minute. What has not changed is the fundamental output: a shaded surface with no engineering meaning. Better-looking triangle soup is still triangle soup. So when you watch a launch reel, the right question is never 'how good does it look?' but 'what could I actually do with the file?' - and the answer, in 2026, keeps landing on the same short list of props, massing and capture.

Open a fresh text-to-3D output and three problems greet you. Topology is the first: the surface is usually a dense, irregular triangle soup, not the clean quad mesh a modeller edits or the tidy solids a BIM tool expects. It may be non-manifold, have holes, or bury detail in noise. To make it editable you often need retopology - rebuilding a sensible surface over the generated one - which for anything but a simple prop can cost more time than modelling from scratch. Scale is the second: these models rarely know real-world units. A generated sofa might import at the size of a house; you set the scale, and you had better measure something real to set it against. Data is the third and deepest: a mesh is just a shell. It has no walls that know they are walls, no rooms, no materials-with-properties, no IFC classification - none of the semantics that make a model a building information model rather than a picture of one.

This is not a temporary bug that the next release fixes; it is what these systems are for. They are trained to make something that looks right from the outside, which is a completely different objective from making something that is correct, buildable and documented. Understanding that keeps your expectations - and your workflow - honest.

There is a subtler problem too: plausibility without truth. A generated staircase will have treads because staircases have treads, but the model has no idea whether those treads meet a code riser height, whether the structure could stand, or whether the dimensions are consistent from one view to another. It produces the appearance of correctness, which is exactly the trap - a confident-looking object that no engineer, no code, and no measurement stands behind. This is the same lesson as hallucination in language models, wearing a 3D coat: the output is fluent, and fluency is not accuracy. For a background prop that does not matter at all; for anything structural or dimensioned it matters enormously, and it is why the buildable, documented layer of a project stays firmly hand-authored.

Cleared of the fantasy, the real value is easy to place. Early massing is the sweetest spot: generate three or four rough volumetric ideas for a form in minutes, drop them onto your site model, and use them as something concrete to react to before you commit to authoring. They are disposable by design, so their loose geometry does not matter. Props and set dressing are the second: furniture, planters, sculptures, clutter, vehicles and vegetation that populate a render or a walkthrough. Nobody dimensions the background sofa, so a generated one is pure time saved - and image-to-3D from a product photo gets you a specific piece fast. Placeholder geometry is a quieter third use: a stand-in object that holds a space in the scene until the real component arrives.

Capture deserves its own line because it is arguably the most professionally solid use today. A Gaussian-splat or photogrammetry scan of existing conditions - a facade you are renovating, a room, an artefact - gives you accurate context to design against, and the accuracy comes from the real world, not from a model guessing. As a working rule: use AI 3D freely for anything nobody will measure or build, and author by hand anything that carries dimensions, data, or your professional signature.

There is one more honest limit to name here: intellectual property and provenance. The generative pipelines were trained on large corpora of 3D and image data whose licensing is, in 2026, still a contested and evolving area - a theme we return to in Module 9. For a disposable massing study this rarely matters, but if a generated asset becomes a visible, distinctive feature of published work, it is worth treating with the same caution you would any found asset: prefer capture of things you have rights to, or your own reference images, over relying on the model to have invented something clean. Combined with the technical limits, this reinforces the same boundary from a different direction: generated 3D belongs to the fast, low-stakes, disposable edge of the process, where its speed is a gift and its uncertainties cost nothing.

The safe pattern mirrors the human-in-the-loop from Module 0: you direct (write a tight prompt or supply clean reference images), the tool generates a mesh, and then you judge and repair before anything enters your real model. Judging means checking scale against a known dimension, inspecting the topology, and deciding honestly whether cleanup is cheaper than remodelling. Often, for a hero object, it is not - and the right call is to bin the output and model it yourself. That is a successful use of the tool, not a failure: it gave you a reference and a decision.

The reason this discipline matters is that generated geometry is seductive. A shaded, spinning object feels finished in a way a blank viewport never does, and there is a real temptation to keep it simply because deleting work is uncomfortable. Resist that. The value the tool delivered was the thinking it accelerated - a form to react to, a reference to model against - not the file itself. Judge every asset on one question: would I be comfortable if this ended up in the final work with my name on it? For a background prop, yes; for anything measured or built, almost never. Holding that line is what separates a designer who is genuinely faster with AI from one who is quietly shipping un-owned geometry.

A concrete prop workflow looks like this:

1. Reference: 2-3 clean photos of the object (or a tight text prompt)
2. Generate:  image-to-3D (e.g. Meshy / Tripo) -> download mesh
3. Scale:     set against a known dimension in your scene
4. Judge:     background prop? keep. Hero / measured? remodel.
5. Place:     drop into the render scene, never into the BIM model

And a blunt weak-vs-strong prompt for pure text-to-3D:

Weak:  "a modern chair"
Strong: "a single mid-century lounge chair, oak frame, tan
         leather, three-quarter view, plain background, one
         object only, no room"

Isolating one object on a plain background gives image-to-3D reconstruction a far cleaner target. Keep every generated asset in a clearly labelled "AI / placeholder" layer so it can never quietly migrate into documentation - that separation is the discipline that lets you use these tools without ever compromising the work you sign.