Zanim spojrzymy na jakiekolwiek narzędzie, zobaczmy, co dzieje się w produkcji bez pipeline'u — i dlaczego ten sam problem rozwiązano w każdym dużym studiu tak samo.
Ta książka jest o pipeline — słowie, które w studiach VFX i animacji słyszysz codziennie, a które rzadko ktoś Ci precyzyjnie tłumaczy. Zanim zdefiniujemy je porządnie, zobaczmy, jak wygląda produkcja, w której go zabrakło. To najlepszy punkt startowy: każdy problem, który pipeline rozwiązuje, najpierw trzeba poczuć jako realny ból, a nie jako abstrakcyjną definicję.
Modelarka kończy postać główną i zapisuje plik jako hero_char.mb. Nazajutrz wprowadza poprawki od supervisora i zapisuje kopię jako hero_char_v2.mb — na wszelki wypadek, gdyby ktoś potrzebował starej wersji. Dzień później okazuje się, że poprawki jednak wymagały korekty, więc powstaje hero_char_v2_fix.mb, a po kolejnej naradzie — hero_char_v2_fix_FINAL.mb. Żaden z tych plików nie mówi wprost, czym różni się od poprzedniego. Nazwa to jedyna dokumentacja, jaka istnieje.
Riger, który ma podpiąć szkielet pod tę postać, otwiera folder współdzielonego dysku i widzi cztery pliki. Wybiera ten z „FINAL" w nazwie — rozsądne założenie, tyle że supervisor jeszcze tego dnia rano cofnął jedną z poprawek, a nowego zapisu nikt nie zdążył oznaczyć. Riger spędza dzień, podpinając kontrolery pod geometrię, która za chwilę i tak zostanie zastąpiona. W tym samym czasie artysta teksturujący podmienia plik tekstury skóry bezpośrednio na dysku sieciowym, pod tą samą nazwą co poprzednio — bo „to tylko drobna korekta koloru". Wieczorem lighting artist, który dzień wcześniej zaakceptował wygląd oświetlenia, odpala ten sam render i widzi zupełnie inny odcień skóry. Nie wie, czy to błąd w jego ustawieniach, czy ktoś zmienił coś, o czym nie został poinformowany. Traci godzinę na szukanie przyczyny, zanim w ogóle dotrze do tego, że problem nie leży po jego stronie.
Żadna z tych osób nie popełniła błędu w sensie, w jakim zwykle o błędach myślimy. Każda zrobiła dokładnie to, co wydawało się rozsądne w danym momencie. Problem nie leży w ludziach — leży w tym, że system, w którym pracują, nie daje jednoznacznej odpowiedzi na pytanie „która wersja tego pliku jest tą właściwą, i skąd mam to wiedzieć, nie pytając nikogo osobiście?".
Historia powyżej zdarza się w tysiącach wariantów, ale zawsze rozbija się o te same cztery pytania. Pipeline, w najprostszym ujęciu, to system zbudowany po to, żeby na każde z nich zawsze istniała jedna, sprawdzalna odpowiedź.
Zauważ, że żadne z tych pytań nie dotyczy tego, jak dobry jest model, rig czy tekstura. To pytania czysto organizacyjne — i to jest dokładnie powód, dla którego ich rozwiązanie nazywa się „pipeline", a nie „lepsze oprogramowanie do modelowania". Nawet najlepsze narzędzie DCC nie odpowie na pytanie „czy to jest aktualna wersja", bo to pytanie wykracza poza jeden plik i jedną aplikację.
Pipeline to nie pojedynczy program ani jedna baza danych — to zestaw wzajemnie powiązanych elementów, które razem zamieniają pracę osobnych artystów w skoordynowaną produkcję. W praktyce składa się zawsze z tych samych składników, które poznasz szczegółowo w kolejnych rozdziałach:
Warto zapamiętać: pipeline nie eliminuje pracy artystów ani decyzji kreatywnych. Eliminuje niejednoznaczność w tym, co dzieje się między artystami — w momencie, w którym praca jednej osoby staje się materiałem wejściowym dla drugiej.
To, co opisaliśmy powyżej, nie jest teoretyczną konstrukcją — to problem, z którym zmierzyło się dosłownie każde studio, które kiedykolwiek wyprodukowało film z użyciem komputerów. ILM budowało własne narzędzia do zarządzania plikami już w latach 90., zanim ktokolwiek używał słowa „pipeline" w dzisiejszym znaczeniu — bo skala Jurassic Park i kolejnych produkcji fizycznie wymuszała jakiś system, a żadnego gotowego nie było na rynku. Pixar poszedł krok dalej i to, co zbudował wewnętrznie dla własnej produkcji (dziś znane jako USD, Rozdział 11), oddał całej branży jako otwarty standard. Weta Digital, Framestore, MPC i DNEG — każde z tych studiów ma własny, unikalny zestaw narzędzi, ale rozwiązuje nimi dokładnie te same cztery pytania z poprzedniej sekcji. Poznasz historie kilku z nich bliżej w dodatkach O–S, w serii „Studia w praktyce".
To nie jest zbieg okoliczności. Skala produkcji — setki artystów, tysiące shotów, dziesiątki tysięcy plików — sprawia, że problem organizacyjny przestaje być kwestią dobrej woli czy dyscypliny zespołu i staje się czystą matematyką: liczba możliwych nieporozumień rośnie szybciej niż liczba osób w zespole. Pipeline to odpowiedź na tę matematykę, nie na braki charakteru poszczególnych artystów. Reszta tej książki to właśnie to — mechanizm po mechanizmie, dokładnie to, z czego taka odpowiedź się składa.
Zanim zaczniemy naprawiać którykolwiek z czterech problemów z tego rozdziału, potrzebujemy wspólnego słownika. Następny rozdział rozkłada produkcję na jednostki, którymi pipeline faktycznie operuje: show, sequence, shot, task i asset — pojęcia, które będą się przewijać przez resztę książki.