DCC Naming Rules for Production Guide

1. Define what each name identifies

Separate asset identity, scene node, geometry variant, material, texture, joint, animation clip, and delivery package. A single name should not carry every fact about the object. Decide which identifiers must remain stable across DCC files and engines. Stable names matter for reimport, overrides, bake matching, and references; descriptive labels that change every review should live in metadata or task notes instead.

2. Choose a token grammar

Write the grammar before examples: prefix, asset identifier, component, variant, level of detail, side, and optional state. Use one separator and a controlled case style. Ban spaces, ambiguous punctuation, and tokens whose meaning changes by department. Specify allowed character sets and maximum length for the strictest destination. Reserve words such as TEMP, TEST, and FINAL only if their lifecycle is enforceable.

3. Name meshes, materials, and textures

Keep render mesh, collision mesh, socket, and proxy roles explicit. Material names should express material identity or slot purpose, while texture names should include the material or asset identifier plus map type and, where needed, tile or color-space role. Do not encode resolution if delivery tooling can read it from the file. For baked pairs, use matching high and low identifiers that the baker can parse without manual selection.

4. Name rigs and animation data

Use deterministic joint names with side tokens in one position, such as L and R, and reserve a center token if required. Controls may use a separate prefix but should preserve semantic correspondence to driven joints. Blend-shape targets need stable expression and side tokens. Animation clips should identify action and variant without embedding frame ranges that change. Test retarget and export mappings after any rename.

5. Handle versions and variants

Distinguish a product variant from a work revision. Variants such as damaged, winter, or colorway may belong in the asset identifier; iterative versions usually belong in source control, file history, or publish metadata. If filenames require a revision, use fixed-width numeric tokens and increment only on publish. Never use final_final2. LOD tokens should map to documented screen or quality targets rather than artist preference.

6. Decision example: modular sci-fi door

A modular door includes frame, moving panel, collision, two material slots, three LODs, and open and close clips. Assign one asset identifier, then add role tokens for frame and panel, collision prefixes for runtime discovery, material-purpose tokens for metal and emissive slots, and LOD suffixes in the approved position. Keep red and blue product variants explicit, while review revisions remain in publish metadata.

7. Diagnose naming failures

Broken reimport after rename means a downstream system treats the name as identity. Duplicate short names can collide when namespaces are removed. Bake mismatch usually indicates inconsistent high/low tokens or separators. A validator rejecting international characters signals an undocumented destination constraint. When artists invent abbreviations, the vocabulary is probably hard to find or missing a needed role; update governance rather than accepting silent divergence.

8. Evidence checklist and multilingual workflow table

Publish the grammar, token dictionary, valid and invalid examples, migration mapping, and validator output. Test round trips through each DCC, exporter, engine importer, and build step. Confirm duplicate detection, case sensitivity, namespace removal, side-token parsing, LOD discovery, and bake matching. Record an owner for vocabulary changes. The multilingual row below identifies the production rule consistently across review and handoff documents.

Related production references