3D Pipeline · Field note
Before Export: A 3D Asset Validation Pass That Survives the Engine
The useful test is not whether an asset looks correct in its authoring scene, but whether it imports predictably into the agreed engine version and target workflow.
Write the delivery contract before touching the export settings
A model is not simply “game ready.” It is ready for a particular engine version, render pipeline, platform range, camera distance, lighting approach, and use in the scene. A background prop for a desktop cinematic and an interactive object for a mobile product viewer may share a subject while requiring different topology, textures, LODs, collision, pivots, and material behavior.
I start by recording the target application and exact version, file format, unit scale, up axis, forward axis, object origin, naming rules, folder structure, and expected asset type. For skeletal assets, the contract also covers the skeleton, rest pose, root-motion policy, clip ranges, animation names, and whether accessories follow the same hierarchy. For static assets, it covers placement behavior, collision intent, mobility, and lightmap requirements.
Budgets should come from the destination rather than from a universal recipe. Triangle count, material slots, texture dimensions, bone influence, LOD thresholds, and memory limits need an owner on the engine side. If the project has not set them, I label provisional targets as assumptions and keep them visible in the delivery notes.
Inspect the mesh as data, not only as an image
A clean render can conceal geometry that becomes unstable after export. The preflight checks transforms, negative scale, unapplied modifiers, non-manifold areas, duplicate vertices, isolated elements, zero-area faces, inconsistent winding, degenerate triangles, and unexpected object history. Naming and hierarchy receive the same attention because engine tools and batch importers often depend on them.
Normals and tangents need a deliberate policy. Hard edges, smoothing groups, custom normals, UV seams, and triangulation affect baked detail and can change shading when the engine recalculates them differently from the authoring tool. Where the final triangulation matters, especially around deformation or a normal-map bake, it should be fixed before the bake and preserved through export.
UV validation depends on purpose. The texture channel needs adequate padding at the intended resolution, consistent density where consistency is expected, and overlap only where it is intentional. A separate lightmap channel may require unique, bounded shells. Mirroring, stacking, UDIMs, and multiple material sets are not defects by themselves, but they must match what the destination shader and build pipeline can actually use.
Treat materials and animation as pipeline contracts
Material names, slot order, texture paths, color space, normal orientation, alpha mode, and packed channels should be explicit. A roughness map interpreted as sRGB or a tangent-space normal imported with the wrong convention can make correct source work appear broken. I compare the neutral-lighting reference with the engine result and document any intentional difference caused by the target renderer.
Texture validation includes dimensions, bit depth where relevant, alpha usage, compression intent, mip behavior, and whether each file is actually referenced. Unused maps and duplicate material slots increase ambiguity even when their runtime cost is small. For web or constrained platforms, the exported package size and texture decode cost may matter as much as polygon count.
For skeletal delivery, I inspect bone names, parent relationships, bind pose, skin weights, excessive influences, scale, root behavior, and clip boundaries. Each requested animation is tested for looping, visible pops, foot movement, contacts, and transform drift. Constraints and control rigs generally do not travel with an exchange format, so anything the engine needs must be baked or rebuilt in the agreed destination setup.
Let a clean engine project be the final authority
The export file is an intermediate result. I import it into a clean project that matches the agreed engine and render pipeline, using recorded import settings rather than relying on whatever happened to be selected last time. The asset is viewed at realistic camera distances and under simple diagnostic lighting before it is judged inside a complex scene.
The engine pass checks scale, orientation, pivot, hierarchy, materials, texture channels, animation clips, collision, LOD transitions, bounds, lightmap warnings, and console output. Skeletal assets are exercised on the intended skeleton. Static assets are placed, duplicated, rotated, and tested against the expected collision behavior. If a project uses Nanite, Lumen, virtual textures, a Unity Scriptable Render Pipeline, or a custom shader, those choices are verified rather than inferred from the source scene.
Delivery should include the approved source, the exchange files, required textures, an engine-side test package or import record, validation captures, and a short manifest of versions and assumptions. I also include known exceptions: an intentionally overlapping UV region, a collider supplied separately, a material that needs a project shader, or an LOD that remains provisional. A precise exception is more useful than a vague claim that everything is optimized.
Related service briefs
Unity 3D Asset Preparation
Unity 3D asset preparation converts approved models into correctly scaled, organized, and tested prefabs for a specified Unity render pipeline and version.
Unreal Engine Asset Preparation
Unreal Engine asset preparation turns approved models into correctly configured assets for a specified engine version, platform target, and rendering workflow.
GLB and FBX File Conversion
GLB and FBX conversion translates a usable source asset into the requested format while checking geometry, materials, textures, scale, and animation support.