Struktura katalogów i konwencje nazewnictwa

Rozdział 3 pokazał mapę działów. Ten rozdział schodzi na poziom tego, co faktycznie leży na dysku — bo to właśnie tam, w strukturze katalogów i nazwach plików, mapa z poprzedniego rozdziału zamienia się w coś, czego dotyka artysta i czego używają narzędzia. Dobra struktura wygląda z zewnątrz nudno: zero kreatywności, wszystko sztywno ustalone z góry. To zamierzone — im mniej miejsca na indywidualną interpretację, tym mniej okazji do nieporozumienia z Rozdziału 1.

Struktura odzwierciedla podział z Rozdziału 2

Skoro produkcja dzieli się na potok assetów i potok shotów, struktura katalogów robi dokładnie to samo — na najwyższym poziomie każdego showu stoją zwykle dwa foldery, assets/ i shots/, a każda ścieżka w dalszej części drzewa jednoznacznie mówi, w której gałęzi się znajdujesz.

show/DEMO/
├── assets/
│   └── character/
│       └── hero_char/
│           ├── model/{work,publish}/
│           ├── rig/{work,publish}/
│           └── surfacing/{work,publish}/
└── shots/
    └── seq010/
        └── shot0100/
            ├── layout/{work,publish}/
            ├── anim/{work,publish}/
            ├── fx/{work,publish}/
            ├── lighting/{work,publish}/
            └── comp/{work,publish}/

Zauważ dwa powtarzające się wzorce. Po pierwsze, każdy task (Rozdział 2) — model, rig, lighting i tak dalej — dostaje własny podfolder, niezależnie od tego, czy siedzi pod assetem, czy pod shotem. Po drugie, każdy z tych folderów dzieli się dalej na work/ i publish/ — dokładnie granicę z Rozdziału 1, tylko zapisaną fizycznie jako dwa różne miejsca na dysku, a nie jako coś, co trzeba pamiętać. Plik w work/ może wyglądać jak popadnie — to prywatny warsztat artysty. Plik w publish/ podlega już sztywnym regułom, które zaraz opiszemy.

Nazwa pliku jako zapis kontekstu

Sama struktura katalogów mówi, w jakim jesteś miejscu, ale plik zwykle wędruje dalej — trafia do renderu, do innego programu, czasem kopiowany jest poza swój folder macierzysty. Dlatego nazwa samego pliku musi nieść te same informacje, co ścieżka, w skróconej, ale wciąż jednoznacznej formie:

DEMO_seq010_shot0100_lighting_beauty_v012.exr
DEMO_hero_char_rig_v034.mb

Każdy fragment nazwy, oddzielony podkreślnikiem, odpowiada jednemu, konkretnemu polu kontekstu — showowi, shotowi lub assetowi, taskowi, opcjonalnie opisowi (beauty jako nazwa passu renderu) i na końcu zawsze numerowi wersji. Trzy zasady sprawiają, że to działa niezawodnie w praktyce:

• Wersja jest zawsze liczbą, zawsze z zerami wiodącymi (v001, nie v1) — dzięki temu sortowanie alfabetyczne w dowolnym systemie plików pokrywa się z kolejnością chronologiczną, nawet przy stu wersjach.
• Żadnego wolnego tekstu w miejscu, gdzie powinno być pole — _fix, _FINAL czy _poprawiony_naprawde to dokładnie ten sam błąd co w Rozdziale 1, tylko schowany w środku „porządnej" konwencji.
• Zawsze małe litery, zawsze podkreślniki zamiast spacji — nie dlatego, że wielkie litery wyglądają gorzej, tylko dlatego, że render farma (Rozdział 19) często łączy stacje robocze z Windows, gdzie system plików nie rozróżnia wielkości liter, z maszynami linuksowymi, gdzie rozróżnia. Plik zapisany jako Hero_Char.mb i odczytywany jako hero_char.mb na dwóch różnych maszynach to prawdziwa, udokumentowana kategoria awarii w tej branży.

Konwencja jest dla skryptu, nie tylko dla oka

Tu dochodzimy do sedna, dlaczego ten rozdział w ogóle zasługuje na tyle uwagi. Gdyby chodziło tylko o czytelność dla człowieka, luźniejsza konwencja by wystarczyła — ludzie radzą sobie z niejednoznacznością. Narzędzia pipeline'u, które poznasz w Części V tej książki, nie radzą sobie z nią wcale. Skrypt publikujący nową wersję pliku musi automatycznie odczytać z bieżącej ścieżki, jaki to show, jaki shot i jaki task, żeby wiedzieć, gdzie zapisać wynik i pod jaką nazwą — a potem znaleźć najwyższy istniejący numer wersji w folderze publish/, żeby nadać kolejny. Jeśli choć jeden plik w tym folderze łamie konwencję, taki skrypt albo się wywali, albo — gorzej — cicho przypisze złą wersję.

W większych studiach ta konwencja bywa zapisana nie jako dokument czy nawyk zespołu, tylko jako dosłowny szablon w konfiguracji pipeline'u — coś w rodzaju wzorca {show}/shots/{sequence}/{shot}/{task}/{version}/{filename}, z którego narzędzia generują ścieżki automatycznie, zamiast polegać na tym, że ktoś je poprawnie wpisze ręcznie. Dzięki temu zmiana konwencji w połowie produkcji — rzadka, ale zdarza się — oznacza edycję jednego pliku konfiguracyjnego, a nie ręczne poprawianie tysięcy już zapisanych ścieżek.