Organising a 3D pipeline for a team

Conventions, handoffs and validation. What stops a project becoming unnavigable at scale.

A pipeline is the set of agreements that let several people produce assets that work together.

The agreements worth making early

  • Units and axes. One convention, configured in every tool.
  • [Naming](/kb/game-development/naming-conventions/). Prefixes, casing, indices.
  • Folder structure. By type or by feature — either works, mixing them does not.
  • Texel density. A single project figure.
  • Polygon tiers by asset role.
  • Formats. Which for what, at each handoff.
  • Where source files live versus exported assets.

None of these are interesting. All of them are expensive to change once there are a thousand assets.

Source versus derived

Keep authoring files — the .blend, the .ma, the layered textures — separate from exported game assets. Exports are derived and regenerable; sources are not. Conflating them means a project where nobody knows which file is authoritative.

Validation

Automated checks at import catch what review misses: wrong scale, missing UVs, exceeded budgets, incorrect naming, missing LODs. A validation script that rejects non-conforming assets is worth more than a document nobody reads.

Handoffs

Every handoff is a place where information is lost. Minimise their number, and make what crosses each one explicit — a checklist per handoff beats an assumption.

Where generation changes the pipeline

It adds a stage and a decision. The stage is generation; the decision is which assets go through it. Both benefit from being explicit: an agreed list of what gets generated, and a defined cleanup standard that generated assets must meet before entering the library.

Without that, generated assets arrive at inconsistent quality and the library becomes unpredictable — which costs more than the generation saved.