Choose the Right AI 3D Workflow

Four routes, four different jobs

The four approaches are not competitors at different quality levels. They solve different problems, and choosing between them is mostly a question of what you are willing to fix afterwards.

Text-to-3D is a concept tool. It is genuinely fast at answering "what could this look like," and it is rarely close to production geometry. Treat its output as a blockout — a volume to model against — rather than as an asset.

Image-to-3D starts from an approved view, which makes it useful when the look is already agreed. Its structural weakness is specific and worth naming: it is inferring everything you cannot see. The back of the object is a plausible guess, and for anything that will be seen from behind, that guess is usually wrong in a way that requires modelling rather than tweaking.

Scanning or photogrammetry gives you a real object accurately. It also gives you a dense, messy mesh with baked-in lighting, and retopology is not optional if the asset needs to deform or fit a budget.

Manual modelling remains the answer whenever the constraints are strict: a polygon budget, clean edge loops for animation, precise real-world dimensions, or geometry that must be watertight.

The honest framing is that the first three approaches move work rather than remove it. That can still be a large win — a blockout that saves two days of concept iteration is valuable even if the final mesh is modelled by hand.

Let the destination set the criteria

The same mesh can be finished work or unusable depending entirely on where it is going, so the destination is the first thing to write down.

The spread is wide. A still render cares only about the silhouette and the surfaces the camera sees; topology is irrelevant and hidden faces can be a disaster with no consequence. A 3D print cares about none of that and requires watertight manifold geometry with real wall thickness. Between them, a game asset cares about polygon budget and UV layout, and an animation asset cares about edge loops in exactly the places that deform.

This is why "we already have the 3D model" is such an unreliable statement in a production conversation. It is true for the still and false for the game, and the gap between them can be several days of work.

Write the destination row first, and derive the acceptance criteria from it before generating. That inverts the common workflow, where a promising mesh is generated and then someone works out whether it can be used.

Know what is missing

The gap between the two columns is where estimates go wrong, because the left column is what everyone sees in the review and the right column is what determines the schedule.

A generated asset arrives with a convincing silhouette, plausible detail on the camera-facing side, and a baked texture that reads well at review distance. Everyone in the meeting concludes the asset is done.

What is typically absent: topology you could animate, correct real-world scale, a UV layout that a texture artist can work with, interior and hidden surfaces, and separable material slots. None of these is visible in the render.

Scale deserves specific attention because it causes the most confusing downstream bugs. Generated meshes frequently arrive in arbitrary units. Import one into a scene with physics or with other assets and it will be dramatically the wrong size, and the symptoms — objects falling through floors, lighting that behaves strangely, cameras with the wrong depth of field — rarely point back at scale as the cause.

So before anything else, place the asset next to a one-metre reference cube. It takes fifteen seconds and prevents an afternoon.

Practice: the asset handoff brief

Pick one object you need and write the brief before generating anything:

ASSET       Ceramic pour-over dripper
DESTINATION Real-time web viewer (three.js), desktop and mobile
VIEWS       Full 360 orbit, user-controlled. All sides visible.
SCALE       Real-world. Height 105 mm. Metres, Y-up, pivot at base centre.
BUDGET      Under 15k triangles. Single 2k texture set.
MATERIALS   One material. Base colour, roughness, normal.
FORMAT      glTF 2.0 binary, Draco compressed, under 3 MB.
BLOCKERS    Interior of the cone is visible when tilted -- must be
            real geometry, not a guess.

Now choose the approach. The "all sides visible" line rules out image-to-3D on its own; the polygon budget rules out raw photogrammetry without retopology. The brief made the decision, which is the point.

Generate a draft with whichever approach survived, then list every piece of cleanup work between the draft and the brief, with a time estimate. That list — not the render — is the honest measure of whether the AI workflow saved anything.

Common mistake

Do not judge a 3D asset from one attractive render.

The render is generated from the angle that flatters the mesh, with lighting chosen to hide its problems, at a distance that conceals its density. This is not deception; it is just what a default preview does.

Rotate a full revolution. Look at the silhouette from at least four angles, since silhouette is what reads at distance and what generation most often gets subtly wrong. Check where surfaces intersect. Then open it in the actual target environment, at the actual camera distance, with the actual lighting.

The three-quarter hero render is the least informative view of a 3D asset, and it is the one every generator gives you by default.