All articles
Tutorials · 7 min read

Taming a 100,000-asset library before it tames you

Naming conventions that sort themselves, folders versus tags, thumbnail pipelines, the duplicate policy and opportunistic migration, all part of a practical system for keeping a huge game asset library findable, and why search speed decides how varied your levels look.

Illustration of an asset thumbnail grid with a search field and tag chips

In short: Environment quality is limited by what artists can find in under a minute. Past a few thousand assets, folder discipline stops scaling, so search plus tags takes over, thumbnails decide scan speed, duplicates need a policy rather than a purge, and migration must be opportunistic rather than heroic.

Reading room of a library, shelves in warm light A library is not a pile of books: it's books plus a finding system. Your asset collection is only a library if the second part exists; otherwise it's a very expensive pile.

The real cost of a messy library

When finding the right rock takes four minutes, artists stop looking after one. Scenes converge on the same twenty remembered assets while thousands of purchased packs sit unopened.

The damage is visible on screen: repetition players can feel, money spent on packs that never ship, and a quiet tax on every set-dressing hour. There's a sharper way to state the rule: an asset that can't be found within about a minute effectively doesn't exist. You paid for it, you store it, you back it up, and it will never appear in a level. Findability is not housekeeping; it's the upper bound on your visual variety. Two studios with identical asset budgets will ship visibly different-looking games if one can find its assets and the other can't.

Naming: boring, sortable, unambiguous

A convention only works if it sorts usefully in a flat list: type prefix, category, material or species, size, index. No spaces, no "final_v2_NEW".

A proven shape:

SM_Rock_Granite_Large_01        (static mesh)
SM_Rock_Granite_Large_01_LOD1
T_Rock_Granite_D / _N / _R      (textures: diffuse, normal, roughness)
M_Rock_Granite                  (material)
MI_Rock_Granite_Mossy           (material instance)

Rules that keep it working at scale: pick one word per concept (Rock, not Rock/Stone/Boulder used interchangeably), put the most-filtered-by field early so sorting groups usefully, zero-pad indices (01, not 1) so 10 doesn't sort before 2, and write the convention on one page everyone reads on day one. The exact scheme matters far less than there being exactly one, and starting today, at whatever size you are, because retrofitting names onto 50,000 files is the project nobody ever finishes and everybody regrets postponing.

Folders say one thing; tags say the rest

A file lives in ONE folder but has many properties. Folders should encode ownership and pipeline (which pack, which project), while tags encode everything you'd search by: biome, material, mood, size, style.

Fighting multi-dimensionality with deeper folder trees produces the classic Props/Nature/Trees/Dead/Moss/ graveyard where nothing is ever found again, because a mossy dead birch belongs in five folders at once and can only live in one, so it's always in the wrong four. The working split makes search the primary way in and the folder tree mere plumbing.

A tag vocabulary that covers most environment work is smaller than teams expect: biome (forest, desert, urban…), material (wood, granite, rusted…), condition (pristine, worn, ruined), size class, and style: five axes, maybe forty terms, agreed once and enforced. The discipline is keeping the vocabulary closed: every new synonym someone invents ("weathered" alongside "worn") halves the value of both tags, because a search for one misses the other.

Thumbnails decide search quality

A list of filenames is not a library. Consistent thumbnails (same angle, neutral lighting) let the eye scan hundreds of candidates per minute, which is the actual speed set dressing needs.

Human vision evaluates a thumbnail grid far faster than it parses names; the consistency is what makes it work, because differences in the asset stay visible when the presentation is identical. A rock shot from a random angle in random lighting hides its own shape; the same rock in a standard three-quarter view under neutral light reveals it instantly. Batch-render them: a thumbnail pipeline pays for itself in the first week of any large project.

Thumbnails are also precisely where scale hurts: browsing a hundred thousand of them demands virtualization, caching, and a pipeline that renders in the background rather than stalling the editor while it catches up. That engineering problem is literally why we built a content browser into Numivo that stays smooth at a million assets, with instant thumbnails and optional AI tagging that turns "that mossy cliff piece somewhere" into a two-word search. The browser problem and the naming problem are the same problem at different layers: both are about collapsing the distance between "I need a thing" and "I'm looking at the thing."

Brick wall of thousands of near-identical units The duplicate problem, made physical: thousands of near-identical units. The skill is keeping one findable canonical version and quietly demoting the rest, not deleting anything a wall still leans on.

Duplicates: keep one, tag the rest

Don't delete near-duplicates on sight, since references break. Instead, pick a canonical version, tag the others duplicate, filter them out of default search, and retire them for real once nothing references them.

Every long-lived project accumulates overlapping packs: four granite boulders from four vendors, three barrels that differ only by a handle. The two-step policy (demote now, delete later) captures the findability win immediately at zero breakage risk: the duplicates vanish from search but stay on disk for any scene that already references them. Run the reference sweep quarterly; six months of no references usually clears the graveyard wholesale, safely.

The failure mode to avoid is deleting duplicates the day you find them: something always references the one you deleted, a level breaks, and the team learns to fear the cleanup, after which nobody cleans up anything. Demote-then-delete keeps cleanup safe, and safe cleanup is the only cleanup that keeps happening.

Migration: getting from chaos to system

Never pause production for a big-bang cleanup. Apply the convention to everything NEW from today, then migrate old content opportunistically: whatever a level pulls in gets renamed and tagged on the way through.

The opportunistic rule has a beautiful property: the assets that matter migrate first, by definition, because they're the ones being used. Anything untouched after a year belongs in cold storage, not in search results, and never needed migrating at all. Teams that instead attempt the heroic weekend cleanup tend to produce a half-renamed library, which is strictly worse than either extreme, because now the search results mix two conventions and neither can be trusted.

Field numbers worth stealing

  • Findability budget: under 1 minute, or the asset functionally doesn't exist
  • Tag vocabulary that covers environment work: ~5 axes, ~40 closed terms
  • Thumbnail scan rate with consistent rendering: hundreds per minute
  • Duplicate policy: demote immediately, delete after ~6 months unreferenced
  • Naming: zero-padded indices, one word per concept, one page of rules

Mini-FAQ

Are AI tags good enough to replace manual tagging? They're good enough to replace most of it: automated tags carry the bulk (subject, material, color) while humans add the judgment calls (style fit, project-specific terms). The combination beats either alone, which is why AI tagging works best as an opt-in assist layer rather than a full replacement.

One shared library or per-project? Shared source library, per-project imports. The library holds everything with full tags; a project pulls in only what it ships, keeping builds lean and cook times short. Mixing the two, letting a project reference the whole library, is how build sizes balloon.

What about versioning binary assets? The library is a garden, not an archive: version the source files in your DCC pipeline, keep the library as current-best-only. Historical versions living in search results are noise wearing a name badge, and they slow every search for everyone.

How do I get a team to actually follow the convention? Make the right thing the easy thing: a save/import template that pre-fills the naming pattern, a lint step that flags files off-convention, and thumbnails that make on-convention assets findable and off-convention ones invisible. Convention enforced by tooling sticks; convention enforced by nagging does not.

Start ugly, start now: a one-page naming sheet, ten core tags, and consistent thumbnails beat a beautiful taxonomy that begins next quarter. Libraries are gardens: constant small weeding, never one heroic cleanup.