Asset Naming Conventions That Keep VFX & Game Studios Sane

Published June 20, 2026 • 9 min read

Every studio starts clean. Then the deadline hits, three artists name the same prop final, final_v2, and FINAL_USE_THIS, and six months later nobody can find anything. A naming convention is the cheapest insurance you'll ever buy against that chaos. Here's a convention that scales, and a few notes on actually making it stick.

Why Naming Matters More Than It Looks

Good names are not about tidiness for its own sake. They make assets searchable, make automated tooling possible, prevent accidental overwrites, and let a new hire understand the project on day one instead of week three. On a team, a consistent name is documentation that never goes stale.

The Anatomy of a Good Asset Name

A reliable pattern reads left to right from general to specific:

[Prefix]_[AssetName]_[Variant]_[Version]

SM_Crate_Large_v003
T_Crate_Large_BaseColor_v003
M_Crate_Large_v002
SK_Hero_Idle_v012

The leading type prefix is the single highest-value habit you can build. It sorts assets by type, makes search trivial, and tells anyone reading the name exactly what they're looking at.

Common Type Prefixes

• SM_ Static Mesh, SK_ Skeletal Mesh
• T_ Texture, M_ Material, MI_ Material Instance
• A_ Audio, BP_ Blueprint (Unreal)
• VFX_ or PS_ Particle System
• WID_ UI Widget, ANIM_ Animation

Rules That Save You Pain Later

1. No spaces, ever. Spaces break command-line tools, scripts, and some build systems. Use underscores or PascalCase.
2. Pick a case and hold it. Whether it's PascalCase or snake_case, consistency beats any individual choice.
3. Pad your version numbers. v003 sorts correctly; v3 ends up next to v30. Always zero-pad.
4. Ban the words "final" and "new". They are lies. Versions are for versioning.
5. No personal initials in shared assets. Crate_JS means nothing once JS leaves the studio.
6. Avoid ambiguous abbreviations. Bg could be background or big. Spell it out or document it.

Folder Structure Is Half the Battle

Names and folders work together. A common, durable layout groups by type at the top and by feature underneath, or vice versa, as long as the whole team agrees and sticks to it.

It's Different Per Tool, But the Principle Holds

Each application has its own idioms, but the discipline is the same everywhere:

• Unreal & Unity: type prefixes plus a clean Content/Assets tree; watch for duplicate materials and orphaned imports.
• Houdini: respect the $JOB structure, keep HDA versions tidy, and watch for orphaned caches.
• Nuke: because .nk scripts are plain text, your Write-node output paths, version tokens, and node naming are all auditable; absolute Read paths are a classic render-farm trap.

The Hard Part: Enforcement

Here's the truth that every pipeline TD learns: a convention nobody checks is a convention nobody follows. A wiki page does not enforce anything. Under deadline pressure, good intentions lose every time.

That's exactly why we built the Studio Hub family: Unreal, Unity, Houdini (Hive), and Nuke Studio Hub. You point them at a project folder, define your convention once, and they scan everything in the browser, flag every name that breaks the rules, find duplicates and orphans, check the project structure, and export a CSV or PDF report you can hand to the team. No installs, no uploads to a server, all local.