Game 3D Asset Pipeline
Move verified visual research through concept, modelling, UVs, PBR texturing, rigging, animation, export, import, optimisation and acceptance without losing provenance or device fitness.
Prerequisites
Load the approved art direction, cultural/reference ledger, mobile-game-performance, and the selected engine's import requirements.
Use When
- Creating art direction, asset briefs, Maya/Blender models, Substance-style textures, rigs, clips, LODs, collisions or engine import presets.
Do Not Use When
- Designing UI appearance without the design-system engine, or inventing cultural references without research and consultation.
Required Inputs
Art pillars, reference/rights ledger, target camera and devices, engine/renderer, real-world scale, asset inventory, simultaneous counts, material/texture contract, animation needs and measured budgets.
Workflow
- Approve reference provenance, gameplay purpose, silhouette, scale, value hierarchy and cultural review.
- Produce production-facing turnarounds, scale/material/animation callouts and a technical asset brief.
- Block out in engine before detail; validate camera, traversal, touch readability and modular dimensions.
- Model for silhouette and deformation; validate topology, normals, pivots, hierarchy and transforms.
- Unwrap to the project seam, padding and texel-density policy; bake and texture non-destructively under neutral and final lighting.
- Rig, skin and test extreme poses; author named clips, root-motion policy, sockets, events and transition poses.
- Export through a versioned contract; rebuild materials in engine; create simple colliders, LODs and import presets.
- Test stress scenes on the minimum device and feed defects back to source assets.
Quality Standards
- Count runtime triangles, material slots, texture memory, bones, overdraw, lights, particles and animation memory in context.
- Derive numeric budgets from representative scenes and target-device profiling, not book examples.
- Keep source files, licences, contributor rights, references and derived assets traceable.
- Require visible state variants for interactable, damaged, harvested, inactive or completed objects where gameplay needs them.
Anti-Patterns
- Detailed model before engine blockout. Fix: validate scale and silhouette first.
- Generic “African” visual borrowing. Fix: source-specific research, consultation and provenance.
- Render mesh as collider. Fix: deliberate simplified collision.
- Huge textures justified by hero status. Fix: screen-coverage and memory evidence.
- DCC viewport treated as engine parity. Fix: material and lighting acceptance in target renderer.
Outputs
Art bible; reference/rights ledger; asset inventory and briefs; budget profile; DCC/export/import contracts; accepted source and runtime assets; QA reports; stress-scene/device evidence.
References
- Concept-to-engine 3D pipeline
- Asset acceptance and mobile budgets
- Practical 3D scene evidence
Decision Rules
| Condition |
Choice |
| Detail does not affect silhouette or survive gameplay distance |
Put it in texture or remove it |
| Asset repeats often |
Prioritise instancing, shared materials and lower-cost variants |
| Deformation is visible |
Topology and skin tests dominate static beauty |
| Budget is not measured on device |
Mark provisional; do not scale content |
Read Next
Use real-time-game-graphics for material/lighting/render integration, mobile-game-performance for budgets, and game-testing-polish for visual regression and acceptance.
1---2name: game-3d-asset-pipeline3description: Use when directing or producing game-ready 3D environments, characters, props, materials, rigs, animations, LODs, collisions, lighting assets, or DCC-to-engine imports; mobile budgets must come from target-device measurement.4---5# Game 3D Asset Pipeline6Move verified visual research through concept, modelling, UVs, PBR texturing, rigging, animation, export, import, optimisation and acceptance without losing provenance or device fitness.78## Prerequisites910Load the approved art direction, cultural/reference ledger, `mobile-game-performance`, and the selected engine's import requirements.11<!-- dual-compat-start -->12## Use When13- Creating art direction, asset briefs, Maya/Blender models, Substance-style textures, rigs, clips, LODs, collisions or engine import presets.14## Do Not Use When15- Designing UI appearance without the design-system engine, or inventing cultural references without research and consultation.16## Required Inputs17Art pillars, reference/rights ledger, target camera and devices, engine/renderer, real-world scale, asset inventory, simultaneous counts, material/texture contract, animation needs and measured budgets.18## Workflow191. Approve reference provenance, gameplay purpose, silhouette, scale, value hierarchy and cultural review.202. Produce production-facing turnarounds, scale/material/animation callouts and a technical asset brief.213. Block out in engine before detail; validate camera, traversal, touch readability and modular dimensions.224. Model for silhouette and deformation; validate topology, normals, pivots, hierarchy and transforms.235. Unwrap to the project seam, padding and texel-density policy; bake and texture non-destructively under neutral and final lighting.246. Rig, skin and test extreme poses; author named clips, root-motion policy, sockets, events and transition poses.257. Export through a versioned contract; rebuild materials in engine; create simple colliders, LODs and import presets.268. Test stress scenes on the minimum device and feed defects back to source assets.27## Quality Standards28- Count runtime triangles, material slots, texture memory, bones, overdraw, lights, particles and animation memory in context.29- Derive numeric budgets from representative scenes and target-device profiling, not book examples.30- Keep source files, licences, contributor rights, references and derived assets traceable.31- Require visible state variants for interactable, damaged, harvested, inactive or completed objects where gameplay needs them.32## Anti-Patterns33- Detailed model before engine blockout. Fix: validate scale and silhouette first.34- Generic “African” visual borrowing. Fix: source-specific research, consultation and provenance.35- Render mesh as collider. Fix: deliberate simplified collision.36- Huge textures justified by hero status. Fix: screen-coverage and memory evidence.37- DCC viewport treated as engine parity. Fix: material and lighting acceptance in target renderer.38## Outputs39Art bible; reference/rights ledger; asset inventory and briefs; budget profile; DCC/export/import contracts; accepted source and runtime assets; QA reports; stress-scene/device evidence.40## References41- [Concept-to-engine 3D pipeline](references/concept-to-engine-pipeline.md)42- [Asset acceptance and mobile budgets](references/asset-acceptance-mobile-budgets.md)43- [Practical 3D scene evidence](references/practical-3d-scene-evidence.md)44<!-- dual-compat-end -->45## Decision Rules46| Condition | Choice |47|---|---|48| Detail does not affect silhouette or survive gameplay distance | Put it in texture or remove it |49| Asset repeats often | Prioritise instancing, shared materials and lower-cost variants |50| Deformation is visible | Topology and skin tests dominate static beauty |51| Budget is not measured on device | Mark provisional; do not scale content |52## Read Next53Use `real-time-game-graphics` for material/lighting/render integration, `mobile-game-performance` for budgets, and `game-testing-polish` for visual regression and acceptance.
peterbamuhigire