Pipeline / Spis treści

Pipeline dla Artystów Technicznych

Ta książka jest dla artystów, którzy chcą zrozumieć, jak w dużym studiu VFX i animacji tysiące osobnych plików — modeli, riggów, shotów, cache’ów symulacji — zamieniają się w jeden spójny film, bez chaosu i bez tego, żeby ktokolwiek nadpisał czyjąś pracę. To nie jest kurs programowania od zera — to wyjaśnienie mechanizmu: repozytoriów, wersjonowania, publikowania, customowych narzędzi i farmy renderowej, które razem tworzą to, co w studiach takich jak Weta Digital, ILM, Framestore, Pixar czy DNEG nazywa się po prostu „pipeline”. 22 rozdziały główne prowadzą przez ten mechanizm liniowo — od pytania, po co to w ogóle istnieje, aż po prześledzenie jednego shota przez cały pipeline na samym końcu. Dodatki A–V schodzą głębiej tam, gdzie rozdział główny musiał zatrzymać się na ogólnym mechanizmie — włącznie z serią „Studia w praktyce”, pokazującą, jak dokładnie te same problemy rozwiązały u siebie ILM, Pixar, Weta, Framestore/MPC/DNEG i inni. To żywy projekt: rozdziały i dodatki będą dopisywane i rozwijane sesja po sesji, nie powstały jednorazowo.

Zanim zaczniesz

Podstawy narzędzioweRepozytorium, terminal, zmienna środowiskowaPiętnaście minut, które wystarczą, żeby „sklonuj repo” i „zmienna środowiskowa” przestały być zaklęciami, które programiści rzucają na spotkaniach.

Część I · Dlaczego pipeline w ogóle istnieje (R.1–3)

Rozdział 1Chaos bez pipeline'uZanim 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. Rozdział 2Anatomia produkcji: show, sequence, shot, task, assetSłownik, bez którego żadne zdanie o pipeline nie ma sensu — jak film dzieli się na jednostki pracy, które da się przydzielić, śledzić i wersjonować. Rozdział 3Mapa pipeline'u: od konceptu do finalnej klatkiModeling, rigging, layout, animacja, fx, lighting, comp — jedna mapa pokazująca, co która komórka produkuje i dla kogo, zanim zejdziemy do szczegółów którejkolwiek z nich.

Część II · Dane: pliki, wersje, publikowanie (R.4–8)

Rozdział 4Struktura katalogów i konwencje nazewnictwaTysiąc artystów zapisujących pliki bez wspólnej reguły to gwarantowana katastrofa — jak nazwa pliku sama w sobie staje się metadanymi. Rozdział 5Dlaczego Git nie wystarcza do plików VFXGit świetnie radzi sobie z tekstem i różnicami linia po linii. Plik Maya na dwa gigabajty tego nie ma — i to jedna z tych rzeczy, które łamią intuicję programisty wchodzącego do VFX. Rozdział 6Perforce i wersjonowanie danych produkcyjnychSystem, o którym artysta rzadko słyszy z nazwy, a używa go codziennie — checkout, submit i blokowanie plików binarnych na poziomie całego studia. Rozdział 7Publish: praca robocza kontra wersja zatwierdzonaNajważniejsze pojęcie w tej książce — granica między plikiem, w którym pracujesz, a wersją, którą zobaczy następny dział. Rozdział 8Śledzenie produkcji: Shotgun/ShotGrid, ftrack, KitsuSkąd supervisor wie, że Twój shot czeka na review — i jak status w przeglądarce zamienia się w plik na dysku.

Część III · Wersjonowanie kodu i praca zespołu pipeline (R.9)

Rozdział 9Git w pipeline: branch, merge i code review dla narzędziTen sam Git, który nie nadaje się do pliku Maya, jest dokładnie tym, czego potrzeba do kodu narzędzi, które ten plik Maya otwierają.

Część IV · Wymiana danych między programami (R.10–13)

Rozdział 10Alembic: cache geometrii między aplikacjamiAnimacja policzona w jednym programie musi trafić bez zmian do drugiego — plik, który zamraża tylko kształt, nie recepturę na jego policzenie. Rozdział 11USD: uniwersalny opis scenyJak złożyć środowisko z tysięcy assetów bez kopiowania ich do jednego pliku — problem, który Pixar rozwiązał dla siebie, a potem oddał całej branży. Rozdział 12Kolor w pipeline: OpenColorIO i ACES od kuchniTen sam plik tekstury musi wyglądać identycznie w Mayi, Nuke i na sali projekcyjnej — to zadanie jednego configu, nie trzech osobnych ustawień. Rozdział 13OpenEXR i AOV: obraz, który niesie więcej niż pikselBeauty pass to dopiero początek — jeden plik EXR potrafi nieść dziesiątki warstw, które kompozytor złoży w cokolwiek zechce, długo po renderze.

Część V · Budowa customowych narzędzi (R.14–18)

Rozdział 14Python jako wspólny język pipeline'uMaya, Houdini, Nuke i Katana mówią różnymi dialektami tego samego języka — dlaczego to Python, a nie C++, zszywa cały pipeline w jedną całość. Rozdział 15Anatomia narzędzia: od skryptu na biurku do przycisku w menuOdległość między „działa u mnie” a „działa u trzystu osób” to więcej niż jedna funkcja — to cała warstwa, o której artysta nigdy nie myśli. Rozdział 16Interfejsy dla artystów: PySide/Qt bez zgadywaniaNarzędzie, które trzeba tłumaczyć na Slacku, jest złym narzędziem — jak projektuje się okno, które artysta rozumie bez czytania dokumentacji. Rozdział 17Zarządzanie środowiskiem: dlaczego każdy ma dokładnie te same wersje„U mnie działa” nie może istnieć w studiu, gdzie ten sam show renderuje się na tysiącu maszyn naraz — po to istnieją menedżery pakietów pipeline'u. Rozdział 18Automatyzacja: kiedy pipeline reaguje samPublikacja modelu, która sama generuje playblast i wysyła powiadomienie do riggingu — event, na który ktoś kiedyś napisał hook, i nikt już o tym nie myśli.

Część VI · Skalowanie produkcji (R.19–20)

Rozdział 19Farma renderowa: kolejkowanie tysięcy zadańJeden shot to może być pięćset klatek na pięciuset maszynach naraz — kto decyduje, co renderuje się najpierw, gdy priorytetów jest więcej niż rdzeni CPU. Rozdział 20Storage i cache: dlaczego dysk potrafi być wolniejszy niż renderPetabajty danych i tysiąc maszyn czytających jednocześnie — architektura, w której najdroższym zasobem bywa nie moc obliczeniowa, tylko przepustowość do dysku.

Część VII · Ludzie i domknięcie (R.21–22)

Rozdział 21Pipeline TD: kto to jest i jak z nim pracować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. Rozdział 22Epilog: jeden shot, cały pipelineZaczę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.

Dodatki poniżej nie trzeba czytać w kolejności liter — każdy rozwija jeden konkretny fragment rozdziału głównego i można wchodzić do nich z dowolnego miejsca, tam gdzie akurat brakuje Ci głębi. Litera to tylko adres, nie kolejność czytania.

Dodatki A–H · Głębiej w dane i wersjonowanie

Dodatek APerforce vs Git: dwie filozofie kontroli wersjiGit zakłada, że każdy może edytować ten sam plik naraz i połączyć zmiany później. Dla trzygigabajtowej sceny w Mayi to założenie po prostu nie działa. Dodatek BUSD w głębi: warstwy, referencje, payloads, wariantyRozdział 11 pokazał USD jako czarną skrzynkę, która „jakoś” składa scenę. Ten dodatek otwiera composition arcs krok po kroku, na konkretnym przykładzie. Dodatek CAlembic kontra USD: kiedy któreOba zamrażają geometrię w czasie, ale jeden z nich potrafi więcej niż tylko cache'ować kształt — kiedy ta różnica ma znaczenie, a kiedy jest tylko teorią. Dodatek DArchitektura configu OpenColorIORozdział 12 użył configu OCIO jak gotowego narzędzia. Tu rozkładamy go na czynniki pierwsze: colorspace, role, transformy, wyszukiwanie ścieżki. Dodatek EOpenEXR od środka: kompresja, multipart, deep pixelsJeden plik, który potrafi ważyć dwa megabajty albo dwa gigabajty w zależności od jednego ustawienia kompresji — i dlaczego „deep” EXR to zupełnie inny plik niż zwykły. Dodatek FSchemat i eventy Shotgun/ShotGrid APIRozdział 8 pokazał, jak status w przeglądarce trafia na dysk. Ten dodatek pokazuje mechanizm: schemat encji i triggery reagujące na zmianę pola. Dodatek GCache'owanie i grafy zależności w pipelineKiedy zmienia się jeden asset niskiego poziomu, pipeline musi wiedzieć dokładnie, co przebudować, a czego nie ruszać — dokładnie ten sam problem, który rozwiązuje make. Dodatek HBezpieczeństwo i uprawnienia: kto może opublikować finalną wersjęNie każdy artysta powinien móc nadpisać wersję, którą ogląda klient — gate'y zatwierdzeń i uprawnienia na poziomie zadania, nie tylko pliku.

Dodatki I–N · Głębiej w narzędzia i skalowanie

Dodatek IRez i menedżery pakietówTrzysta stacji roboczych, ten sam show, dokładnie ta sama wersja Houdiniego i tego samego pluginu na każdej z nich — bez tego żaden render nie jest powtarzalny. Dodatek JMaya API: MFnPlugin, callbacki, customowe node'yRozdział 15 pokazał tool jako menu w Mayi. Ten dodatek schodzi niżej — do node'ów i callbacków, z których taki tool jest w środku zbudowany. Dodatek KHoudini i HDA: pipeline dla FX i geometrii proceduralnejDigital Asset to węzeł, który artysta może opublikować i przekazać dalej jak każdy inny plik — most między proceduralną siecią a resztą pipeline'u. Dodatek LNuke: gizmos, szablony i grupy w kompozytinguSetka nodów kompozytingowych powtarzana w każdym shocie to błąd, nie praktyka — gizmo zamyka je w jednym, wersjonowanym bloku. Dodatek MDeadline, Tractor, OpenCue: trzy podejścia do kolejki renderuTen sam problem — tysiąc zadań, ograniczona liczba maszyn — rozwiązany trzy razy inaczej przez trzy różne studia. Dodatek NContinuous Integration dla pipeline'uNarzędzie używane przez cały show nie może zepsuć się w środku dnia — jak pipeline testuje sam siebie, zanim zmiana trafi do artystów.

Wykład: Studia w praktyce (O–S)

Pięć części, jedno pytanie: jak ten sam mechanizm z rozdziałów głównych wygląda naprawdę, gdy zbudować go musi konkretne studio, pod konkretny film, z konkretnym budżetem czasu. Nie trzeba czytać po kolei — każda część stoi osobno.

Dodatek OStudia w praktyce, część 1: ILM — narodziny przemysłuZanim pipeline miał nazwę, ktoś musiał wynaleźć format pliku na obraz z ruchomym przecinkiem — historia studia, które budowało infrastrukturę, bo nie było jej skąd wziąć. Dodatek PStudia w praktyce, część 2: Pixar — pipeline jako produktJedyne studio na tej liście, które swój wewnętrzny pipeline (USD) oddało całej branży za darmo — i dlaczego to się im opłacało. Dodatek QStudia w praktyce, część 3: Weta Digital — skala AvataraSetki tysięcy assetów lasu, każdy inny, żaden ręcznie nieumieszczony — pipeline zaprojektowany pod produkcję, w której ręczna praca fizycznie się nie mieści w budżecie czasu. Dodatek RStudia w praktyce, część 4: Framestore, MPC, DNEG — pipeline wielu show'ów narazDuże studio rzadko robi jeden film na raz — jak jeden dział pipeline'u obsługuje dziesięć produkcji i cztery kontynenty jednocześnie, bez dziesięciu różnych systemów. Dodatek SStudia w praktyce, część 5: poza Pixarem — Animal Logic i konsorcjum USDUSD wygrało nie dlatego, że Pixar tak kazał, tylko dlatego, że reszta branży dobrowolnie dołączyła do wspólnego standardu — pipeline studia, które nie napisało USD, ale w pełni na nim stoi.

Dodatki T–V · Przyszłość i praktyka zawodowa

Dodatek TCloud rendering: farma, która nie stoi w budynku studiaRozdział 19 zakładał farmę pod tym samym dachem co artyści. Co się zmienia, kiedy te maszyny stoją w cudzym centrum danych tysiące kilometrów dalej. Dodatek UMotion capture pipeline: od volumu do rigaAktor w garniturze z markerami to dopiero początek — dane z volumu przechodzą przez własny, osobny łańcuch czyszczenia i retargetingu, zanim trafią do riga postaci. Dodatek VStudia przypadków: co się psuje, gdy pipeline zawodziNajwięcej o architekturze systemu mówią jego realne awarie — kilka anonimowych historii typu „publish nadpisał cudzą wersję” i co z nich wynika na przyszłość.

Dodatek W · Wzorce Pythona w kodzie narzędzi

Dodatek WWzorce Pythona w kodzie narzędziRozdział 14 wyjaśnił, po co w pipeline jest Python. Ten dodatek pokazuje, jak wygląda kod, który się z niego naprawdę pisze — pathlib, subprocess, dataclasses, logging i reszta zestawu, który wraca w prawie każdym narzędziu.

Pomocnik praktyczny

Tom 1Zbuduj mini-pipeline od zeraTe same tematy co w rozdziałach 4, 7, 16 i 18, ale tym razem piszesz kod: prosty publish script, hook do niego i okienko PySide, które to wszystko spina — krok po kroku.