Cleaning up AI-generated 3D models for commerce

What generators actually emit

Image-to-3D and text-to-3D systems — TRELLIS, Hunyuan3D, TripoSR, InstantMesh, SF3D, SPAR3D and their commercial cousins — mostly reconstruct a surface from a volumetric or implicit representation, then bake an appearance onto it. The output is characteristically structurally simple: metallic-roughness materials with no exotic extensions, one texture set, no skinning, no morph targets.

That simplicity is why the "AI slop needs rescuing" narrative overstates the case. When we ran a provenance-tracked corpus of open-generator outputs through a commerce-readiness gate, the dominant outcome was *warnings*, not hard blockers — and after automated repair, 64/64 AI-generated models were AR-ready. Human-authored showcase assets, with their transmission and volume and clearcoat, fail readiness gates far more often than generator output does.

Problem 1 — scale and origin are meaningless

This is the one that actually breaks commerce, and almost nobody lists it. Generators output geometry in a normalized space — typically fitted to a unit cube — because they have no idea whether you asked for a coffee cup or a shipping container. glTF is defined in metres, and AR places objects at real-world scale.

So your beautifully reconstructed sneaker arrives in a customer's living room as a one-metre monolith. Fix it before anything else: scale the geometry to the product's true dimensions, and move the origin to the base of the object so AR floor placement works. Everything downstream — triangle budgets, texel density, bounds-based camera framing — depends on the model being the right size.

Problem 2 — triangle counts sized for a viewer, not a page

Marching-cubes-style extraction produces dense, fairly uniform meshes. Uniform is the operative word: a generated mesh spends as many triangles on a flat panel as on a detailed edge, which is exactly what a good decimator is for. Reducing a generated mesh by an order of magnitude while preserving silhouette is routine, because the original topology was never optimised for anything.

Problem 3 — automatic UV atlases with no padding

Generated models get an automatically-unwrapped texture atlas, and automatic unwrappers optimise for packing efficiency, which means islands sit as close together as possible. Then you compress the texture — and block-compressed formats work on 4 × 4 texel tiles, so neighbouring islands bleed into each other and you get coloured fringes along seams.

In our own corpus work this was consistently the most common warning on generator output. It is invisible in an uncompressed preview and obvious once KTX2 or a GPU format enters the picture. The fix is padding: re-pack the atlas with at least four texels of gutter, or avoid block compression on that texture.

Problem 4 — disconnected islands and floaters

Reconstruction from images produces stray fragments: a shard of geometry where the background leaked in, an interior shell that will never be seen, a speck a metre from the product. They inflate the bounding box — which makes viewers frame the product badly — inflate triangle counts, and occasionally appear as visible debris in AR.

Removing disconnected components below a size threshold is safe and mechanical. Do it after scaling, so "small" means something.

Problem 5 — normals, tangents and vertex colours

• Missing normals. glTF permits their absence, and viewers then compute flat per-face normals, which makes a smooth product look faceted. Generating smooth normals fixes the look — but be aware it adds a vertex attribute, and on an untextured vertex-coloured mesh that can make the file *larger*. A repair pipeline should keep whichever result is smaller when the quality verdict is unchanged.
• Missing tangents. If a generated material carries a normal map with no TANGENT attribute, the glTF validator raises MESH_PRIMITIVE_GENERATED_TANGENT_SPACE: runtime-generated tangent space "may be non-portable across implementations". Different viewers, different surface detail.
• Vertex colours instead of textures. Common in scan-derived and some generated output. They render fine in three.js — and are a hard error in Android's Scene Viewer, which does not support vertex colours. Bake them to a base-colour texture if Android AR matters.

Problem 6 — texture resolution chosen by the generator

Generated assets frequently ship a single large baked map, often 2048 or 4096 px, sized by the model rather than by how big the product renders. Since textures are usually 70–90% of a GLB, this is where the size wins are. Resizing to the resolution the product actually needs, then re-encoding, does far more than any geometry codec — see reducing GLB file size.

A repair order that works

1. Validate first, so you know whether you are fixing a broken file or a suboptimal one.
2. Set real-world scale and move the origin to the product base.
3. Remove disconnected components and interior shells.
4. Decimate to a sane triangle budget — for AR, Scene Viewer's recommended 100,000 is the binding constraint.
5. Re-pack UVs with adequate island padding.
6. Generate smooth normals where missing; generate or export tangents if any normal map is used.
7. Bake vertex colours to a texture if you need Android AR.
8. Resize and re-encode textures.
9. Deduplicate and prune, then compress geometry.
10. Check AR readiness for both platforms and look at the result on a device.

Steps 2 through 9 are all automatable, and automating them is the only way this scales past a handful of SKUs — the whole reason to generate models is volume. What is not automatable is the final look: Apple ships no headless Quick Look renderer, so no tool can reproduce its output offline, and a device check on your best sellers stays part of the process.

One licensing note: generator terms differ sharply on commercial use and redistribution, so check them before a generated model goes on a product page. Related: the pre-publish checklist and decoding validator output.