W skrócie: jakość środowiska jest ograniczona tym, co artyści potrafią znaleźć w niecałą minutę. Powyżej kilku tysięcy assetów dyscyplina folderów przestaje się skalować, wyszukiwanie plus tagi przejmują pałeczkę, miniatury decydują o szybkości skanowania, duplikaty potrzebują polityki, a nie czystki, a migracja musi być oportunistyczna, nie bohaterska. Oto system, który przeżywa wzrost, z konkretnymi konwencjami wartymi skopiowania i powodami, dla których każda liczy się w skali.
Biblioteka to nie stos książek, to książki plus system znajdywania. Twoja kolekcja assetów jest biblioteką tylko, jeśli istnieje druga część; inaczej to bardzo drogi stos.
Prawdziwy koszt bałaganiarskiej biblioteki
Gdy znalezienie właściwej skały zajmuje cztery minuty, artyści przestają szukać po jednej, sceny zbiegają się do tych samych dwudziestu zapamiętanych assetów, podczas gdy tysiące kupionych packów leżą nieotwarte.
Szkoda jest widoczna na ekranie: powtórzenie, które gracze czują, pieniądze wydane na packi, które nigdy nie trafiają do gry, i cichy podatek od każdej godziny aranżacji. Jest ostrzejszy sposób ujęcia reguły: asset, którego nie da się znaleźć w około minutę, w praktyce nie istnieje. Zapłaciłeś za niego, przechowujesz, robisz kopię, a nigdy nie pojawi się w poziomie. Znajdywalność to nie sprzątanie; to górna granica twojej różnorodności wizualnej. Dwa studia o identycznych budżetach assetów wydadzą widocznie inaczej wyglądające gry, jeśli jedno potrafi znaleźć swoje assety, a drugie nie.
Nazewnictwo: nudne, sortowalne, jednoznaczne
Konwencja działa tylko, jeśli sortuje się użytecznie na płaskiej liście, prefiks typu, kategoria, materiał lub gatunek, rozmiar, indeks. Bez spacji, bez „final_v2_NEW".
Sprawdzona forma:
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)Reguły utrzymujące to w skali: jedno słowo na koncept (Rock, nie Rock/Stone/Boulder używane wymiennie), umieść pole najczęściej filtrowane wcześnie, by sortowanie grupowało użytecznie, dopełnij indeksy zerami (01, nie 1), by 10 nie sortowało się przed 2, i zapisz konwencję na jednej stronie, którą każdy czyta pierwszego dnia. Dokładny schemat liczy się o wiele mniej niż to, że jest dokładnie jeden, i by zacząć dziś, przy jakimkolwiek rozmiarze, ponieważ dopasowanie nazw wstecz do 50 000 plików to projekt, którego nikt nigdy nie kończy i którego odkładania wszyscy żałują.
Foldery mówią jedną rzecz; tagi mówią resztę
Plik żyje w JEDNYM folderze, ale ma wiele właściwości, foldery powinny kodować własność i pipeline (który pack, który projekt), tagi kodują wszystko, po czym byś szukał: biom, materiał, nastrój, rozmiar, styl.
Zwalczanie wielowymiarowości głębszymi drzewami folderów produkuje klasyczny cmentarz Props/Nature/Trees/Dead/Moss/, gdzie nic już nigdy się nie znajduje, bo omszała martwa brzoza należy do pięciu folderów naraz i może żyć tylko w jednym, więc zawsze jest w czterech złych. Działający podział czyni wyszukiwanie główną drogą wejścia, a drzewo folderów zwykłą instalacją hydrauliczną.
Słownik tagów pokrywający większość pracy nad środowiskiem jest mniejszy, niż zespoły oczekują: biom (las, pustynia, miejski…), materiał (drewno, granit, zardzewiały…), stan (nieskazitelny, zużyty, zrujnowany), klasa rozmiaru i styl, pięć osi, może czterdzieści terminów, uzgodnionych raz i egzekwowanych. Dyscyplina polega na trzymaniu słownika zamkniętego: każdy nowy synonim, który ktoś wymyśli („zwietrzały" obok „zużyty"), zmniejsza o połowę wartość obu tagów, bo wyszukiwanie jednego mija drugi.
Miniatury decydują o jakości wyszukiwania
Lista nazw plików to nie biblioteka, spójne miniatury (ten sam kąt, neutralne oświetlenie) pozwalają oku skanować setki kandydatów na minutę, co jest rzeczywistą szybkością potrzebną aranżacji.
Wzrok człowieka ocenia siatkę miniatur znacznie szybciej, niż parsuje nazwy; to spójność sprawia, że działa, bo różnice w asście pozostają widoczne, gdy prezentacja jest identyczna. Skała sfotografowana pod losowym kątem w losowym oświetleniu ukrywa własny kształt; ta sama skała w standardowym ujęciu trzech czwartych pod neutralnym światłem ujawnia go natychmiast. Renderuj je wsadowo, pipeline miniatur zwraca się w pierwszym tygodniu każdego dużego projektu.
Miniatury to też dokładnie miejsce, gdzie skala boli: przeglądanie stu tysięcy z nich wymaga wirtualizacji, buforowania i pipeline'u renderującego w tle, zamiast zamrażać edytor, gdy nadrabia. Ten problem inżynierski jest dosłownie powodem, dla którego zbudowaliśmy przeglądarkę treści w Numivo, która pozostaje płynna przy milionie assetów, z natychmiastowymi miniaturami i opcjonalnym tagowaniem AI, które zamienia „ten omszały kawałek klifu gdzieś" w dwuwyrazowe wyszukiwanie. Problem przeglądarki i problem nazewnictwa to ten sam problem na różnych warstwach: oba dotyczą zwinięcia odległości między „potrzebuję rzeczy" a „patrzę na rzecz".
Problem duplikatów, uczyniony fizycznym: tysiące niemal identycznych jednostek. Umiejętnością jest zachowanie jednej znajdywalnej wersji kanonicznej i ciche zdegradowanie reszty, a nie usuwanie czegokolwiek, na czym mur wciąż się opiera.
Duplikaty: zachowaj jeden, otaguj resztę
Nie usuwaj niemal-duplikatów na widok (referencje pękają), wybierz wersję kanoniczną, otaguj pozostałe duplicate, odfiltruj je z domyślnego wyszukiwania i wycofaj naprawdę, gdy nic ich nie referuje.
Każdy długowieczny projekt gromadzi nakładające się packi: cztery granitowe głazy od czterech dostawców, trzy beczki różniące się tylko uchwytem. Dwuetapowa polityka (zdegraduj teraz, usuń później) chwyta zysk znajdywalności natychmiast przy zerowym ryzyku pęknięcia, duplikaty znikają z wyszukiwania, ale zostają na dysku dla każdej sceny, która już je referuje. Uruchamiaj skan referencji kwartalnie; sześć miesięcy bez referencji zwykle bezpiecznie opróżnia cmentarz hurtowo.
Tryb awarii do uniknięcia to usuwanie duplikatów w dniu, w którym je znajdziesz: coś zawsze referuje ten, który usunąłeś, poziom pęka, a zespół uczy się bać sprzątania, po czym nikt niczego nie sprząta. Zdegraduj-potem-usuń utrzymuje sprzątanie bezpiecznym, a bezpieczne sprzątanie to jedyne, które nadal się zdarza.
Migracja: od chaosu do systemu
Nigdy nie wstrzymuj produkcji dla wielkiego wybuchowego sprzątania, zastosuj konwencję do wszystkiego NOWEGO od dziś, potem migruj stare treści oportunistycznie: cokolwiek poziom wciąga, jest po drodze przemianowane i otagowane.
Reguła oportunistyczna ma piękną właściwość: assety, które się liczą, migrują pierwsze, z definicji, bo to one są używane. Cokolwiek nietknięte po roku należy do zimnego magazynu, nie do wyników wyszukiwania, i nigdy nie musiało migrować. Zespoły, które zamiast tego próbują bohaterskiego weekendowego sprzątania, zwykle produkują w połowie przemianowaną bibliotekę, ściśle gorszą niż którakolwiek skrajność, bo teraz wyniki wyszukiwania mieszają dwie konwencje i żadnej nie można ufać.
Liczby z pola warte podkradzenia
- Budżet znajdywalności: poniżej 1 minuty, inaczej asset funkcjonalnie nie istnieje
- Słownik tagów pokrywający pracę nad środowiskiem: ~5 osi, ~40 zamkniętych terminów
- Tempo skanowania miniatur przy spójnym renderowaniu: setki na minutę
- Polityka duplikatów: zdegraduj natychmiast, usuń po ~6 miesiącach bez referencji
- Nazewnictwo: indeksy dopełnione zerami, jedno słowo na koncept, jedna strona reguł
Mini-FAQ
Czy tagi AI są wystarczająco dobre, by zastąpić ręczne tagowanie? Wystarczająco, by zastąpić większość, zautomatyzowane tagi niosą trzon (temat, materiał, kolor), a ludzie dodają oceny (dopasowanie stylu, terminy specyficzne dla projektu). Kombinacja bije każdą samą, dlatego tagowanie AI działa najlepiej jako opcjonalna warstwa wspomagająca, nie pełne zastępstwo.
Jedna wspólna biblioteka czy per projekt? Wspólna biblioteka źródłowa, importy per projekt. Biblioteka trzyma wszystko z pełnymi tagami; projekt wciąga tylko to, co wydaje, trzymając buildy szczupłe, a czasy cook krótkie. Mieszanie obu (projekt referujący całą bibliotekę) to sposób, w jaki rozmiary buildów pęcznieją.
A wersjonowanie binarnych assetów? Biblioteka to ogród, nie archiwum: wersjonuj pliki źródłowe w swoim pipeline DCC, trzymaj bibliotekę jako tylko-najlepszy-obecny. Historyczne wersje żyjące w wynikach wyszukiwania to szum z identyfikatorem, i spowalniają każde wyszukiwanie dla wszystkich.
Jak sprawić, by zespół naprawdę przestrzegał konwencji? Uczyń właściwe łatwym: szablon zapisu/importu wstępnie wypełniający wzór nazwy, krok lintu oznaczający pliki poza konwencją i miniatury czyniące assety zgodne z konwencją znajdywalnymi, a niezgodne niewidocznymi. Konwencja egzekwowana narzędziowo trzyma się; konwencja egzekwowana marudzeniem nie.
Zacznij brzydko, zacznij teraz: jednostronicowy arkusz nazw, dziesięć tagów rdzeniowych i spójne miniatury biją piękną taksonomię, która zaczyna się w przyszłym kwartale. Biblioteki to ogrody, ciągłe małe pielenie, nigdy jedno bohaterskie sprzątanie.