Publish: praca robocza kontra wersja zatwierdzona

Wracamy teraz do granicy, którą Rozdział 4 zarysował fizycznie jako dwa foldery, work/ i publish/. Ten rozdział wyjaśnia, co dokładnie tę granicę przekracza i dlaczego — bo publish to prawdopodobnie najważniejsze pojedyncze pojęcie w całym pipeline. Jeśli zrozumiesz tylko jeden mechanizm z tej książki, niech to będzie ten.

To nie jest „Zapisz jako"

Intuicyjnie „opublikować" brzmi jak „zapisać w innym miejscu". W praktyce publish to zwykle znacznie więcej niż kopiowanie pliku — to konkretna sekwencja kroków, wykonywana przez narzędzie pipeline'u, nie ręcznie przez artystę:

• Eksport czystego wyniku — plik roboczy modelarki może zawierać dziesiątki tymczasowych obiektów, historii konstrukcyjnej, notatek. Publikacja rzadko kopiuje cały ten plik bezpośrednio — zamiast tego eksportuje z niego wyłącznie to, czego potrzebuje odbiorca, samą finalną geometrię, bez balastu.
• Nadanie numeru wersji — narzędzie samo odczytuje najwyższą istniejącą wersję w folderze publish/ (Rozdział 4) i nadaje kolejną, bez udziału artysty w liczeniu.
• Zapis przez Perforce — sam plik trafia do depota jako nowy submit (Rozdział 6), więc dostaje pełną historię i jest odzyskiwalny.
• Rejestracja w systemie śledzenia — nowa wersja pojawia się w bazie produkcyjnej (Rozdział 8) jako fakt widoczny dla całego zespołu, nie tylko jako plik na dysku, o którego istnieniu trzeba komuś powiedzieć osobno.

Dopiero wszystkie te kroki razem — nie sam zapis pliku — nazywają się publikacją.

Dwa osobne progi, nie jeden

Łatwo założyć, że skoro coś zostało opublikowane, jest automatycznie gotowe do użycia. W wielu pipeline'ach to prawda dla wczesnych etapów produkcji — szybkość iteracji jest ważniejsza niż formalna kontrola. Ale przy elementach o dużym wpływie na resztę produkcji (hero asset, którego dotyczy setki shotów) dochodzi zwykle drugi próg: zatwierdzenie (approval) przez supervisora, osobne od samego publikowania. Artysta może publikować wersje robocze do przeglądu tyle razy, ile potrzebuje; dopiero jedna z nich, oznaczona jako zatwierdzona, staje się tą, którą inne działy pobierają domyślnie. Do tego mechanizmu — kto może zatwierdzać i jak wygląda taka bramka — wrócimy głębiej w Dodatku H.

Nikt nie przegląda cudzych folderów

Druga połowa tego mechanizmu dotyczy tego, jak opublikowana wersja trafia do kogoś innego. Artysta w dziale animacji, który chce wczytać rig postaci, nigdy nie otwiera ręcznie ścieżki na dysku i nie szuka najnowszego pliku po dacie modyfikacji. Używa narzędzia — loadera albo referencera — które zna konwencję z Rozdziału 4, odpytuje system śledzenia z Rozdziału 8 i automatycznie proponuje najnowszą zatwierdzoną wersję. To domyka pętlę z Rozdziału 3: shot referuje asset przez tę samą, przewidywalną ścieżkę, nigdy przez ręczne kopiowanie pliku ani zgadywanie, który plik jest aktualny.

Wracamy do chaosu z Rozdziału 1

Warto na chwilę wrócić do sceny z pierwszego rozdziału i przepuścić ją przez ten mechanizm. Riger, zamiast szukać pliku z „FINAL" w nazwie na dysku sieciowym, otwiera loader, który pokazuje mu jedną, jednoznaczną, najnowszą zatwierdzoną wersję modelu — nie cztery kandydatki do zgadywania. Artysta teksturujący nie podmienia pliku pod tą samą nazwą — publikuje nową wersję, która dostaje własny numer i nie nadpisuje niczego, z czego ktoś już korzysta. Lighting artysta, który następnego dnia odpala ten sam render, wciąż widzi dokładnie tę wersję tekstury, którą zaakceptował dzień wcześniej — dopóki sam świadomie nie zaktualizuje swojej referencji do nowszej. Cały chaos z Rozdziału 1 rozbijał się o brak dokładnie tego mechanizmu.