Osoba, do której piszesz, gdy narzędzie się wywala — czym różni się jej praca od pracy artysty i programisty, i dlaczego jest trochę jednym i drugim.
Cała ta książka opisywała mechanizmy — pliki, wersje, narzędzia, farmę. Za każdym z nich stoją jednak ludzie, którzy je budują i utrzymują. Ten przedostatni rozdział poświęcamy właśnie im: osobom, które w studiu noszą tytuł Pipeline TD (albo Pipeline Engineer, Pipeline Developer — nazwa różni się między studiami, rola jest zaskakująco spójna).
Pipeline TD rzadko jest wyłącznie jednym albo drugim. Część z nich zaczynała jako artyści — modelarze, riggerzy, kompozytorzy — którzy z czasem zainteresowali się automatyzacją własnej pracy i naturalnie przesunęli się w stronę kodu. Część to programiści, którzy trafili do VFX z zewnątrz i musieli nauczyć się, jak faktycznie wygląda dzień pracy osoby, dla której piszą narzędzia. Obie drogi prowadzą do tego samego miejsca: umiejętności pisania solidnego kodu (Część V tej książki) połączonej ze zrozumieniem, jak wygląda praca po drugiej stronie ekranu — czego artysta oczekuje po kliknięciu „Publish" i dlaczego zawieszone okno z Rozdziału 16 wygląda dla niego jak awaria, nie jak długa operacja w tle.
Rozdział 15 wyjaśnił, dlaczego traceback Pythona jest nieczytelny dla artysty — ale to nie znaczy, że jest bezużyteczny. Dla Pipeline TD to najważniejsza pojedyncza informacja w całym zgłoszeniu.
„Publish się wywala, pomocy"
„Publish rigu hero_char, shot0100, task rigging, ok. 14:20 — okno pokazało czerwony komunikat, zrzut ekranu w załączniku"
Kontekst (show, shot czy asset, task), moment wystąpienia i dokładna treść komunikatu — nawet niezrozumiałego dla zgłaszającego — pozwalają Pipeline TD odtworzyć sytuację bez dopytywania w tę i z powrotem, co przy piętnastu zgłoszeniach dziennie robi ogromną różnicę w czasie reakcji.
Artysta, który zgłasza problem, zwykle chce jednego: żeby zniknął, najlepiej natychmiast. Pipeline TD musi jednak pamiętać, że każda zmiana w kodzie narzędzia (Rozdział 9) trafia — po code review — na branch, z którego korzystają wszyscy pozostali artyści, a show w krytycznej fazie może być świadomie przypięty do starszej, przetestowanej wersji (Rozdział 17). Poprawka, która wygląda na jednolinijkową, często i tak przechodzi przez te same bramki co każda inna zmiana — nie z biurokracji, tylko dlatego, że błąd wprowadzony pospiesznie do wspólnego narzędzia potrafi kosztować więcej czasu całej produkcji, niż zaoszczędziła jedna szybka łatka.
Ostatni rozdział tej książki nie wprowadza nic nowego — łączy wszystkie mechanizmy poznane po drodze, śledząc jeden shot od pierwszego szkicu aż po klatkę, która trafia na ekran.