Review Generated 3D Assets Before Handoff

Three passes, three classes of defect

Preview quality and production quality are different properties, and the preview is specifically designed to show the first one.

Each of the three passes finds defects the others structurally cannot, which is why running only the first is the common failure.

Turntable. Rotate a full revolution, slowly, on a plain background. This catches holes, collapsed or hollow backs, asymmetry that should not be there, and silhouette problems. Silhouette matters more than surface detail for anything seen at distance, and it is what generation most often gets subtly wrong — an object that reads correctly from the front and is slightly the wrong shape from the side.

Wireframe and normals. Switch to wireframe, then to a normals or face-orientation view. This catches density spikes where thousands of triangles are spent on nothing, flipped faces that will render as holes, non-manifold edges that will break a boolean or a print, and n-gons that will break a subdivision. None of these is visible in a shaded render.

In the target engine. At real camera distance, under real lighting, at the real budget. This catches everything the first two cannot: how the material behaves under your lighting rather than the preview's, whether the texture resolution holds at your closest camera, and whether the asset actually fits the frame budget alongside everything else in the scene.

Teams that stop after the first pass ship assets that fail in the third, and they fail after the deadline, because the third pass happens during integration.

Tailor the checklist

A generic asset checklist copied from a marketplace listing will check things your pipeline does not care about and miss the two things that will actually cause a rejection.

Build the checklist from the destination brief instead. The four groups above are the frame; the specific items come from your pipeline's conventions.

Orientation and pivot deserve a specific call-out because they are pure convention and therefore invisible until they are wrong. Y-up versus Z-up, centimetres versus metres, pivot at the base versus the centroid — each is arbitrary, each is a hard requirement in some engine, and each produces a bug that looks like something else entirely.

For anything animated or interactive, add the pipeline-specific rows: LOD set, collision mesh, rigging, deformation edge loops, material slot naming, and whether the mesh is a single object or a hierarchy.

Then write the estimate. For a generated asset, the useful number is not "is this good" but "how long from here to compliant." That figure is what tells you whether the AI step saved anything, and tracking it over several assets is the only honest way to evaluate a workflow.

Record provenance while you still can

Every input to a 3D workflow carries its own terms, and they stack. The reference photograph, the scanned object and the location it was scanned in, the model weights, and the provider's output terms are four separate questions with four separate answers.

The reason to record this at build time rather than on request is simple: it is close to impossible to reconstruct later. Six months on, nobody remembers which of forty reference images produced which asset, which generator version was used, or what the terms said at the time — and terms change, so "we checked" is not the same as "we recorded what it said."

Keep it with the asset, not in a separate spreadsheet:

{
  "asset": "pour-over-dripper-v4.glb",
  "created": "2026-07-30",
  "pipeline": [
    { "step": "reference",  "source": "studio-shoot-2026-06-11/IMG_2214.dng",
      "rights": "work for hire, full transfer, contract SC-118" },
    { "step": "image-to-3d","tool": "example-gen 2.3",
      "terms": "commercial use permitted on Studio plan, checked 2026-07-30" },
    { "step": "retopology", "tool": "Blender 4.5", "by": "a.novak" },
    { "step": "texture",    "source": "in-house scan library / ceramic-matte-07" }
  ],
  "distribution": "client deliverable, unrestricted"
}

The checked date on the terms line is the field that matters most, because it converts "we believe this is fine" into "this is what the terms said on this date," which is a defensible position.

Practice: annotate one asset

Take one generated asset and run all three passes. Capture one image from each pass and annotate every finding with pass, fix, or verify.

Then estimate the cleanup time for everything marked fix, and compare it against what modelling the asset from scratch would have cost. Record both numbers.

Do this for three or four assets before drawing a conclusion about the workflow. The variance is high — some objects come out of generation nearly usable and some are worse than starting over — and the shape of that distribution, rather than the best case, is what tells you where the approach belongs in your pipeline.

Common mistake

The most common mistake is treating provenance as a legal formality rather than as production metadata.

Every image, scan, and set of model weights that entered the workflow can carry its own restrictions, and those restrictions travel into everything derived from them. A reference photograph you did not license does not become licensed by being converted to a mesh. A generator whose terms restrict commercial output does not stop restricting it because you retopologised the result.

The practical consequence is that an unrecorded input is an unusable asset. When a client, a platform, or a marketplace asks what went into it — and eventually one of them will — an asset whose history cannot be described has to be rebuilt, and it has to be rebuilt at exactly the moment when there is no time to do it.