The Pipeline

What actually happens between the artist and the player

A 3D model leaves a DCC tool — Maya, Blender, ZBrush, whichever — and it is not yet close to being in the game. Before it reaches a player it will be exported, reimported, retopologised if it started in high-poly, UV-unwrapped, baked, textured, rigged if it moves, weighted, imported into the engine, assigned materials, given LODs, collision geometry and occlusion data, organised into the right folder structure, referenced by a scene, included in a build, and tested in-engine at target hardware settings. Any one of those steps can introduce something wrong. Most of the time, nobody will see it until far down the line, when fixing it costs ten times what it would have cost at source.

This is the asset pipeline: the sequence of transforms that converts source files into runtime-ready content. It is not glamorous infrastructure, but it is where a surprising proportion of a project's unplanned work originates.

Where things go wrong, and why

The first class of problem is silent corruption — a value that is technically legal but semantically wrong. A mesh exported with the wrong axis convention looks fine in isolation; in-engine it is ninety degrees off or mirrored, and if no one checks immediately, it is checked in, propagated to every scene that references it, and then discovered during a lighting pass two months later. Scale is the same: a prop modelled at ten times the intended size will not error; it will simply make every environment that contains it look wrong in ways that are hard to diagnose.

The second class is missing data. Collision hulls that were not generated, LODs that were never authored, a material slot left unassigned — these will not necessarily break a build. They may silently degrade performance or produce visual artefacts that only show at distance, or on a hardware tier the development machine does not represent. This is why budgets per asset need to be agreed before production, not discovered during optimisation.

The third class is version drift. The source file, the exported intermediate, and the engine asset can fall out of sync whenever anyone edits one without propagating the change. Naming and versioning discipline is what prevents this, and the discipline fails most often under pressure — exactly when the pipeline needs to be most reliable.

It is not glamorous infrastructure, but it is where a surprising proportion of a project's unplanned work originates.

The value of automation and the cost of its absence

A well-constructed pipeline automates as many of the transform steps as possible. Export scripts enforce axis conventions and scale. Baking is parameterised and reproducible. LOD generation follows rules set at the start of production, not left to individual artists to interpret differently. Importers validate against a schema — triangle count, texture resolution, material slot count — and reject assets that breach their budget before they reach the engine. When something is rejected, it is rejected at the source, by the person who made it, while the context is fresh.

The cost of not building this infrastructure is paid continuously. Manual steps are repeated inconsistently. Problems compound. An artist who has to hand-configure an export every time will eventually configure it wrong, especially on the twentieth asset of a long day. The pipeline should make the correct path the only path, or at least the easiest one.

None of this infrastructure builds itself, and someone has to own it. That person is typically a technical artist — close enough to the DCC tools to understand what artists need, and close enough to the engine to understand what the runtime will accept. When studios underfund that role, they find out later, in bug counts.

The pipeline is not finished when it first works. It is a living system that needs to accommodate new asset types, new platforms, new quality tiers, and the edge cases that production always surfaces. A pipeline that was fit for purpose at the vertical slice may be creaking by content complete — and patching it at that point, under certification pressure, is one of the more unpleasant things a team can be asked to do.

The examples in this entry are illustrative, not a measurement of any particular production.