AI 3D Game Asset Generators and the Topology Problem

Text-to-3D crossed a real threshold. Ask for a wooden barrel, a market stall, a rusted radio mast, and about a minute later you have a thing that is recognisably that, in three dimensions, that you can spin around and look at from behind. Five years ago that was a day of somebody's work.

Then you open it in an editor and look at the wireframe, and the picture changes. What you have is usually a dense, unstructured surface: tens or hundreds of thousands of triangles distributed with no relationship to the form. The flat side of the barrel has as many triangles as the rim. The lid has a knot of geometry in the middle for no reason. There are no edge loops following the shape, because nothing in the process was thinking about the shape as a shape.

This is not a bug in any particular generator. Most of these systems arrive at a surface by extracting it from a volume, and an extracted surface is a dense field of triangles that happens to approximate the object. It looks correct from outside. It carries none of the structure a modeller would have put there.

That distinction between a shape and a mesh is the whole subject. Everything a 3D asset has to do beyond being looked at once depends on the mesh, and a generated mesh is the part that was not really produced.

Topology is the arrangement of the polygons, and it is not craft snobbery. It has four concrete jobs.

It controls deformation. When a character bends an elbow, the geometry around that elbow has to have loops running the right way or the joint pinches into a paper crease. There is no shader that hides it and no rig that fixes it. The loops either exist or the arm looks broken when it moves.

It controls shading. Long thin slivers and stray n-gons catch light in ways that produce visible dark streaks and shimmering edges, especially on smooth painted surfaces. You see it most in motion, as a crawling glitter along a curve that should be clean.

It controls cost. A prop that appears forty times in a level at a hundred and eighty thousand triangles each is a budget problem you will meet later as a frame rate problem, and the connection between the two is not obvious when it happens.

And it controls editability. Good topology is why an artist can select a loop, slide it, and lengthen a handle in eight seconds. On generated topology that operation does not exist; there is no loop to select. Every change becomes a sculpting operation or a rebuild.

The standard answer is retopology: build a clean low-polygon mesh that follows the form, then bake the detail of the dense original onto it as a normal map. This is a well understood pipeline that predates generated models by twenty years, and automatic tools for it are good.

For hard-surface props and static scenery, automatic retopology plus a decimation pass gets you most of the way. A generated crate at two hundred thousand triangles becomes a crate at eight hundred that looks identical in play. That is a five minute job with tools that already exist, and it is the single highest-value thing you can do to a generated model.

For anything that deforms, automatic retopology is not enough. It produces an even distribution of quads, which is fine for a rock and wrong for a shoulder. Deforming meshes need density where the bending happens and loops oriented along the direction of the bend, and that is a judgement about how the thing will move, which no automatic pass makes because nothing told it.

So the honest split is: generated static props are close to usable after a mechanical cleanup. Generated characters and creatures are concept sculpts that someone has to rebuild before they animate. Those are very different amounts of work, and the difference is not visible in the preview render, which is why people are so often surprised by it.

A model needs a UV layout: a flattening of the surface into a 2D sheet so that texture pixels land where you want them. Generated models come with something, and that something is usually machine-cut, with seams in visually terrible places and wildly uneven scaling across the surface.

The symptom is texel density. If the top of a table gets a quarter of the texture sheet and the legs share a corner of it, the top is crisp and the legs are blurry, and inside a scene where every other object has consistent density, the mismatch reads instantly as the asset not belonging.

Seams matter too. A seam is a place where the texture must break, and a well-placed one hides under an arm, along a hem, behind a bracket. An automatically placed one runs down the middle of a face. On a tiling or painted material nobody notices. On anything with a pattern, letters, or continuous grain, the break is glaring.

This one is fixable and worth fixing on the assets that matter: reproject the UVs, set a single project-wide texel density, and rebake. It is one of the few operations where the tooling is genuinely good enough to run unattended, and it removes a whole class of "why does this look wrong" that people usually blame on the model quality.

The texture that arrives with a generated model is typically a colour map with light and shadow already painted into it. There is a highlight on the upper edge and an occlusion darkening under the lip, because the model was produced from images and those images had a light in them.

That is precisely what a game material must not be. In a real-time renderer, lighting is computed at runtime. When baked lighting is also present in the base colour, you get an object that is lit twice: it has a bright edge on the left because the texture says so, and another bright edge on the right because your sun is over there. It looks flat, wrong, and slightly plastic, and it never responds correctly when the player moves a torch past it.

The other half of the problem is the missing maps. Physically based rendering wants roughness and metalness, and often normal and ambient occlusion. Generated output usually gives you colour and little else, so metal is not shiny, wet stone is not wet, and everything in the scene converges on the same dull uniform surface.

De-lighting a texture is possible and imperfect. Authoring the missing maps is real work. For distant scenery, neither is worth it. For anything the player stands next to, both are, and this is the failure that most often makes a generated asset look cheap next to a bought one even when the geometry is fine.

Generate one medieval chair and it is convincing. Generate the table, the bench, the cupboard and the door in four more calls, and put them in one room, and the room falls apart.

The wood is a different wood in each. The wear is heavy on two and absent on two. One is stylised with soft chamfered edges and one is nearly photoreal. The scale of the plank widths does not agree, so the cupboard reads as either enormous or doll-sized depending on which neighbour you look at it beside. Each object passes on its own and the set fails, because a set is a claim that all these things came from the same world.

Style coherence is not a slider. It is a bundle of decisions: how sharp edges are, how much surface noise there is, how saturated the palette runs, how much detail per square metre, whether damage is told through geometry or through texture. A human artist carries all of that between assets without thinking about it. A generator holds none of it between calls.

Two things help, and neither is a prompt trick. Lock a reference and generate variations of an accepted asset rather than new objects from scratch. And run a shared material and palette pass over the whole set at the end, which will not fix silhouette language but does an enormous amount for the feeling that these things belong together.

Generated models arrive at arbitrary scale, arbitrary orientation and with the origin wherever the exporter felt like putting it, often at the centre of the bounding box. A chair whose origin is at its middle sinks halfway into the floor when you place it, and rotates around its own waist.

Set the rules once. Real-world metres, upright on a defined axis, origin at the base for anything that sits on ground, at the hinge for anything that swings, at the geometric centre for anything that spins. Apply it as an import step and you never think about it again. Skip it and you spend the rest of the project nudging things by hand and wondering why the door frame does not line up with the wall.

Collision is the other one nobody mentions. Using a dense generated mesh as its own collider is the single most reliable way to make a small scene run badly, because collision cost scales with triangles the same way rendering does, and physics queries do it every frame. Every prop needs a simple hull, and simple means a box, a capsule, or a handful of convex pieces. Automatic hull generation handles most of it; the exceptions are things the player walks through, like doorways and arches, where a convex hull cheerfully seals the hole.

None of this is interesting work, and all of it is the difference between a folder of models and a level you can walk around in.

A character has to have a skeleton, and every vertex has to be weighted to the bones that move it. Automatic rigging exists and works reasonably on a clean humanoid mesh in a neutral pose.

Generated characters are frequently neither. They come in whatever pose the model imagined, often with arms partly down and hands fused to the body. They come with anatomy that reads correctly from the front and is a mess underneath, because nothing enforced that the inside of the arm has to exist. And they come with the dense unstructured topology described earlier, which weights unpredictably, so the elbow collapses and the shoulder tears.

The consequence is not that generated characters cannot be animated. It is that getting one animated is a rebuild: retopologise for deformation, pose to a neutral T or A, redo the UVs, rebake, then rig. That is a substantial amount of specialist work, and it is why generated 3D has landed so much more usefully on environment art than on characters.

The workaround most people converge on is to keep the character count tiny and treat those few as the assets you actually invest in, while letting generation fill the world around them. That is a sensible allocation, and it happens to match where the value is anyway.

The honest summary is the same as for 2D: a strong placeholder and a weak final asset. The strength is real and worth taking seriously.

Blockouts stop being grey. A level you are testing with cubes tells you about distances and sightlines and nothing else. A level filled with roughly correct generated objects tells you whether the space reads, whether the player can tell a door from a wall, whether the market feels like a market. You can make design decisions against it that you cannot make against cubes.

Background and mid-distance filling is the sweet spot. Objects the player never approaches do not need clean topology, correct texel density or authored roughness. They need a silhouette and a colour, which is exactly what generation delivers.

Kitbashing is underrated. Generate twenty variations of a bracket, a crate, a pipe junction, then build real objects by assembling pieces you have already cleaned up. You get variety from combination rather than from generation, and combination preserves consistency because every part came from the same accepted set.

And it is a good way to answer a question quickly. Should this ruin be stone or timber? Twenty minutes and two versions in the scene beats a week of arguing, and the answer transfers even though neither model ships.

Decide the constants first: units, up axis, texel density, triangle budgets by object class, the origin rules. Write them down. They cost nothing before there are assets and they are painful to retrofit afterwards.

Generate into a slot rather than into a folder. You are making the cupboard for the room you already have, at the size it must be, next to the things that are already there. Judge it there, not in a turntable render with studio lighting, because a turntable render is the environment where every generated asset looks its best and every problem in this article is invisible.

Run the mechanical passes as a pipeline, not per-asset by hand: decimate, retopologise, reproject UVs, rebake, generate the collision hull, set the origin. Once that pipeline exists, the marginal cost of another asset is minutes.

Then decide, deliberately, which small number of assets carry the game. The player character, the two or three things they interact with constantly, the view in the screenshot. Those get real work, whether you commission it, buy it, or build it yourself. Everything else stays as it is, and nobody will ever look closely enough to care.

The failure mode is not using generated art. It is expecting a generated asset to be finished because it looked finished in the preview, and discovering the missing half of the object three months later when the animation pinches and the frame rate drops.