Zaczęliśmy od pojedynczego pliku bez żadnej struktury. Kończymy, śledząc jeden shot przez każdy system z tej książki — od pierwszego szkicu do klatki w kinie.
Rozdział 1 zaczął się od chaosu: pliku z „FINAL" w nazwie, nadpisanej pracy, straconego dnia. Dwadzieścia rozdziałów później masz już wszystkie elementy, które ten chaos zamieniają w przewidywalny proces. Zanim zamkniemy tę książkę, prześledźmy jeden, konkretny shot — seq030_shot0250 — od pierwszego szkicu do klatki, którą zobaczy widz, wskazując po drodze na każdy mechanizm, który już znasz.
Postać główna, hero_char, powstaje w potoku assetów z Rozdziału 3: modeling buduje geometrię i publikuje ją (Rozdział 7) przez narzędzie, które sam kontekst odczytuje automatycznie (Rozdział 15), zapisując wynik przez Perforce (Rozdział 6) w strukturze katalogów z Rozdziału 4. Rigging i surfacing robią to samo, każdy w swoim tasku, każdy pilnując configu OpenColorIO z Rozdziału 12, żeby tekstury wyglądały identycznie wszędzie, gdzie ktoś je otworzy. Cały ten postęp widać w systemie śledzenia z Rozdziału 8 — supervisor ogląda kolejne wersje na dailies i zatwierdza tę jedną, którą zobaczą inne działy.
Layout ustawia kamerę w scenie złożonej z warstw USD (Rozdział 11) — asset hero_char jest tylko referencją, nie kopią. Animacja ożywia rig i zapieka wynik do cache'u Alembic (Rozdział 10), który trafia do FX bez potrzeby otwierania Mayi. FX symuluje włosy i ubranie na tym cache'u, zapisując własną warstwę. Lighting składa wszystko razem i wysyła zadanie na farmę renderową (Rozdział 19) — setki klatek na setkach maszyn naraz, z których każda odczytuje dokładnie to samo środowisko (Rozdział 17) i te same dane ze współdzielonego storage'u (Rozdział 20). Wynik to nie jeden obrazek, tylko wielokanałowy OpenEXR z dziesiątkami passów (Rozdział 13).
Po drodze, bez udziału żadnego artysty, odpalają się hooki z Rozdziału 18 — playblast do przeglądu, powiadomienie do kolejnego działu. Compositing składa finalny obraz z passów, kierując się tym samym configiem koloru co wszyscy wcześniej. Cały ten łańcuch narzędzi — od publish scriptu po submitter farmy — jest kodem wersjonowanym w Gicie (Rozdział 9), utrzymywanym przez Pipeline TD (Rozdział 21), który dba, żeby żadna zmiana nie zepsuła tego, co akurat renderuje się dla innego shotu.
Żaden z mechanizmów w tej książce nie jest tam dlatego, że komuś się spodobał estetycznie. Każdy z nich to odpowiedź na konkretny, nieunikniony problem skali: kiedy artystów jest dwustu, a shotów tysiące, chaos z Rozdziału 1 nie jest ryzykiem — jest gwarancją, jeśli nic mu się nie przeciwstawi. To dlatego niemal identyczny zestaw rozwiązań powstał niezależnie w ILM, Pixarze, Weta Digital, Framestore, MPC i DNEG — różne narzędzia, różne nazwy, ten sam kształt problemu i ten sam kształt odpowiedzi. Przyjrzysz się temu bliżej w serii „Studia w praktyce" w dodatkach O–S.
Jeśli pracujesz jako artysta w studiu, które ma dobry pipeline, prawdopodobnie nigdy nie zobaczysz większości mechanizmów opisanych w tej książce z nazwy — zobaczysz tylko przycisk „Publish", który działa, i loader, który zawsze pokazuje właściwą wersję. To jest dokładnie znak, że ktoś zrobił swoją pracę dobrze.