La qualité d'environnement est limitée par ce que les artistes peuvent trouver en moins d'une minute. Passé quelques milliers d'assets, la discipline des dossiers cesse de passer à l'échelle : recherche plus tags prennent le relais, les miniatures décident de la vitesse de balayage, les doublons demandent une politique plutôt qu'une purge, et la migration doit être opportuniste plutôt qu'héroïque. Voici un système qui survit à la croissance, avec les conventions concrètes à copier et les raisons pour lesquelles chacune compte à l'échelle.
Une bibliothèque n'est pas un tas de livres : ce sont des livres plus un système de recherche. Votre collection d'assets n'est une bibliothèque que si la seconde partie existe ; sinon c'est un tas très coûteux.
Le vrai coût d'une bibliothèque en désordre
Quand trouver le bon rocher prend quatre minutes, les artistes cessent de chercher après une : les scènes convergent vers les mêmes vingt assets mémorisés tandis que des milliers de packs achetés restent fermés.
Les dégâts sont visibles à l'écran : une répétition que les joueurs ressentent, de l'argent dépensé pour des packs jamais livrés, et une taxe silencieuse sur chaque heure d'habillage. Il y a une façon plus tranchante d'énoncer la règle : un asset introuvable en environ une minute n'existe effectivement pas. Vous l'avez payé, vous le stockez, vous le sauvegardez, et il n'apparaîtra jamais dans un niveau. La trouvabilité n'est pas du ménage ; c'est la borne supérieure de votre variété visuelle. Deux studios aux budgets d'assets identiques livreront des jeux à l'aspect visiblement différent si l'un trouve ses assets et l'autre non.
Nommage : ennuyeux, triable, sans ambiguïté
Une convention ne marche que si elle se trie utilement en liste plate : préfixe de type, catégorie, matériau ou espèce, taille, index. Pas d'espaces, pas de « final_v2_NEW ».
Une forme éprouvée :
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)Des règles qui la font tenir à l'échelle : un mot par concept (Rock, pas Rock/Stone/Boulder utilisés indifféremment), placez le champ le plus filtré tôt pour que le tri regroupe utilement, remplissez les index de zéros (01, pas 1) pour que 10 ne se trie pas avant 2, et écrivez la convention sur une page que tout le monde lit le premier jour. Le schéma exact compte bien moins qu'il n'y en ait exactement un, et de commencer aujourd'hui, à la taille que vous avez, car rétro-appliquer des noms à 50 000 fichiers est le projet que personne ne termine jamais et dont tout le monde regrette le report.
Les dossiers disent une chose ; les tags disent le reste
Un fichier vit dans UN dossier mais a de nombreuses propriétés : les dossiers devraient encoder la propriété et le pipeline (quel pack, quel projet), les tags encodent tout ce par quoi vous chercheriez : biome, matériau, ambiance, taille, style.
Combattre la multidimensionnalité par des arbres de dossiers plus profonds produit le classique cimetière Props/Nature/Trees/Dead/Moss/ où rien n'est jamais retrouvé, car un bouleau mort et moussu appartient à cinq dossiers à la fois et ne peut vivre que dans un, donc il est toujours dans les quatre mauvais. Le découpage qui marche fait de la recherche la voie d'entrée principale et de l'arbre de dossiers une simple tuyauterie.
Un vocabulaire de tags qui couvre l'essentiel du travail d'environnement est plus petit que les équipes ne le pensent : biome (forêt, désert, urbain…), matériau (bois, granite, rouillé…), état (immaculé, usé, en ruine), classe de taille et style : cinq axes, peut-être quarante termes, convenus une fois et appliqués. La discipline consiste à garder le vocabulaire fermé : chaque nouveau synonyme que quelqu'un invente (« altéré » à côté d'« usé ») divise par deux la valeur des deux tags, car une recherche de l'un rate l'autre.
Les miniatures décident de la qualité de recherche
Une liste de noms de fichiers n'est pas une bibliothèque : des miniatures cohérentes (même angle, éclairage neutre) laissent l'œil balayer des centaines de candidats par minute, ce qui est la vitesse réelle dont l'habillage a besoin.
La vision humaine évalue une grille de miniatures bien plus vite qu'elle n'analyse des noms ; c'est la cohérence qui la fait marcher, car les différences dans l'asset restent visibles quand la présentation est identique. Un rocher pris sous un angle aléatoire dans un éclairage aléatoire cache sa propre forme ; le même rocher en vue trois-quarts standard sous lumière neutre la révèle instantanément. Rendez-les en batch : un pipeline de miniatures se rentabilise dès la première semaine de tout grand projet.
Les miniatures sont aussi précisément là où l'échelle fait mal : en parcourir cent mille exige virtualisation, mise en cache, et un pipeline qui rend en arrière-plan plutôt que de figer l'éditeur pendant qu'il rattrape son retard. Ce problème d'ingénierie est littéralement pourquoi nous avons intégré un navigateur de contenu dans Numivo qui reste fluide à un million d'assets, avec miniatures instantanées et tagging IA optionnel qui transforme « ce morceau de falaise moussu quelque part » en une recherche de deux mots. Le problème du navigateur et celui du nommage sont le même problème à des couches différentes : les deux consistent à réduire la distance entre « il me faut une chose » et « je regarde la chose ».
Le problème des doublons, rendu physique : des milliers d'unités quasi identiques. Le savoir-faire est de garder une version canonique trouvable et de rétrograder discrètement le reste, non de supprimer quoi que ce soit sur quoi un mur s'appuie encore.
Doublons : en garder un, taguer le reste
Ne supprimez pas les quasi-doublons à vue (les références cassent), choisissez une version canonique, taguez les autres duplicate, filtrez-les hors de la recherche par défaut, et retirez-les pour de bon une fois que rien ne les référence.
Tout projet de longue durée accumule des packs qui se recouvrent : quatre blocs de granite de quatre fournisseurs, trois tonneaux ne différant que par une anse. La politique en deux temps (rétrograder maintenant, supprimer plus tard) capture le gain de trouvabilité immédiatement à zéro risque de casse : les doublons disparaissent de la recherche mais restent sur le disque pour toute scène qui les référence déjà. Lancez le balayage des références chaque trimestre ; six mois sans référence vident généralement le cimetière en bloc, en toute sécurité.
Le mode d'échec à éviter est de supprimer les doublons le jour où vous les trouvez : quelque chose référence toujours celui que vous avez supprimé, un niveau casse, et l'équipe apprend à craindre le nettoyage, après quoi personne ne nettoie plus rien. Rétrograder-puis-supprimer garde le nettoyage sûr, et le nettoyage sûr est le seul qui continue d'avoir lieu.
Migration : passer du chaos au système
Ne mettez jamais la production en pause pour un nettoyage big-bang : appliquez la convention à tout ce qui est NOUVEAU dès aujourd'hui, puis migrez l'ancien contenu de façon opportuniste : ce qu'un niveau tire à lui est renommé et tagué au passage.
La règle opportuniste a une belle propriété : les assets qui comptent migrent en premier, par définition, car ce sont ceux utilisés. Tout ce qui reste intact après un an appartient au stockage froid, pas aux résultats de recherche, et n'a jamais eu besoin de migrer. Les équipes qui tentent plutôt le nettoyage héroïque du week-end tendent à produire une bibliothèque à moitié renommée : strictement pire que l'un ou l'autre extrême, car désormais les résultats de recherche mélangent deux conventions et aucune n'est fiable.
Chiffres de terrain à voler
- Budget de trouvabilité : moins d'1 minute, sinon l'asset n'existe fonctionnellement pas
- Vocabulaire de tags couvrant le travail d'environnement : ~5 axes, ~40 termes fermés
- Vitesse de balayage des miniatures avec rendu cohérent : des centaines par minute
- Politique des doublons : rétrograder immédiatement, supprimer après ~6 mois sans référence
- Nommage : index remplis de zéros, un mot par concept, une page de règles
Mini-FAQ
Les tags IA sont-ils assez bons pour remplacer le tagging manuel ? Assez pour en remplacer la plupart : les tags automatisés portent le gros (sujet, matériau, couleur) tandis que les humains ajoutent les jugements (adéquation de style, termes propres au projet). La combinaison bat chacun seul, d'où le fait que le tagging IA fonctionne mieux comme couche d'assistance opt-in que comme remplacement total.
Une bibliothèque partagée ou par projet ? Bibliothèque source partagée, imports par projet. La bibliothèque tient tout avec des tags complets ; un projet ne tire que ce qu'il livre, gardant les builds légers et les temps de cuisson courts. Mélanger les deux (un projet qui référence toute la bibliothèque), c'est comme les tailles de build enflent.
Et le versionnement des assets binaires ? La bibliothèque est un jardin, pas une archive : versionnez les fichiers source dans votre pipeline DCC, gardez la bibliothèque en meilleur-actuel-seulement. Des versions historiques vivant dans les résultats de recherche sont du bruit avec un badge nominatif, et elles ralentissent chaque recherche pour tout le monde.
Comment amener une équipe à vraiment suivre la convention ? Rendez la bonne chose facile : un modèle d'enregistrement/import qui pré-remplit le motif de nommage, une étape de lint qui signale les fichiers hors convention, et des miniatures qui rendent les assets conformes trouvables et les non-conformes invisibles. Une convention appliquée par l'outillage tient ; une convention appliquée par le rappel à l'ordre, non.
Commencez moche, commencez maintenant : une feuille de nommage d'une page, dix tags cœur et des miniatures cohérentes battent une belle taxonomie qui commence le trimestre prochain. Les bibliothèques sont des jardins : un constant petit désherbage, jamais un nettoyage héroïque.