Maya, 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ść.
Część IV pokazała formaty, którymi dane wędrują między programami. Ta część pokazuje, jak w ogóle powstają narzędzia, które te formaty czytają, piszą i spinają w jeden proces. Zaczyna się od pytania, które prędzej czy później zadaje sobie każdy początkujący pipeline TD: skoro Maya, Houdini i Nuke są napisane w C++, dlaczego niemal cały kod pipeline'u, który je łączy, jest w Pythonie?
Każdy z głównych DCC embeduje interpreter Pythona i wystawia swój wewnętrzny model sceny jako zestaw funkcji i klas tego języka. Składnia jest zawsze ta sama — pętle, funkcje, importy — ale nazwy i kształt API różnią się między aplikacjami, bo każda odzwierciedla swój własny model danych:
# Maya import maya.cmds as cmds selected = cmds.ls(selection=True) # Houdini import hou selected = hou.selectedNodes() # Nuke import nuke selected = nuke.selectedNodes()
Trzy różne API, to samo pytanie: „co jest zaznaczone". Riger, który zna Pythona, nie musi uczyć się nowego języka programowania, żeby zacząć skryptować w Houdinim — musi tylko poznać nowy słownik. To jedna z głównych przyczyn, dla których artysta techniczny, przechodząc między działami i programami, wciąż może korzystać z tej samej, raz zdobytej umiejętności.
Same silniki tych programów — rasteryzacja viewportu, symulacje fizyczne, kompresja obrazu — pozostają napisane w C++ (albo podobnie szybkim języku) właśnie dlatego, że liczą się tam mikrosekundy. Python w tej architekturze pełni rolę kleju: warstwy, w której nie liczy się surowa wydajność, tylko szybkość pisania, czytelność i łatwość zmiany. Skrypt publikujący z Rozdziału 7 nie musi renderować klatki w mikrosekundę — musi być łatwy do napisania, przeczytania przez kolegę podczas code review (Rozdział 9) i zmiany, kiedy konwencja się zmieni. Dokładnie w tym miejscu Python wygrywa z C++: brak kroku kompilacji oznacza, że poprawka trafia do artystów w kilka minut, nie po przebudowaniu i przetestowaniu binarki.
Python w pipeline nie żyje wyłącznie wewnątrz okien Mayi czy Nuke. Skrypty wysyłające zadania na farmę renderową (Rozdział 19), demony nasłuchujące zmian statusu w systemie śledzenia i automatycznie reagujące (Rozdział 18), narzędzia wiersza poleceń do zarządzania środowiskiem (Rozdział 17) — wszystkie one też są zwykle napisane w Pythonie, uruchamiane niezależnie od jakiegokolwiek DCC. To sprawia, że wiedza pipeline TD nie jest rozdrobniona między dziesiątkami niekompatybilnych technologii — jeden język obsługuje całą infrastrukturę, od przycisku w menu Mayi po skrypt uruchamiany co noc na serwerze.
Znamy już język. Następny rozdział pokazuje, jak z pojedynczego skryptu Pythona powstaje coś, co artysta faktycznie klika — cała droga od kodu na biurku programisty do przycisku w menu Mayi.