Publikacja 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.
Każdy mechanizm opisany do tej pory w tej książce wymagał, żeby ktoś go świadomie uruchomił — kliknął „Publish", otworzył loader, zmienił status w systemie śledzenia. Ostatni rozdział Części V pokazuje, co się dzieje, gdy pipeline sam zaczyna reagować na te zdarzenia, bez czekania na kolejne kliknięcie.
Hook (albo trigger) to fragment kodu zarejestrowany tak, żeby odpalić się automatycznie w reakcji na konkretne zdarzenie — publikację nowej wersji, zmianę statusu taska na approved, submit pliku do Perforce. Artysta, który wywołuje to zdarzenie, zwykle nie wie i nie musi wiedzieć, ile hooków się pod nim kryje — z jego perspektywy kliknął jeden przycisk „Publish", i tyle.
Weźmy dokładnie ten scenariusz z podtytułu rozdziału. Modelarka publikuje nową wersję hero_char. Zanim jeszcze zdąży zamknąć okno narzędzia, w tle mogą uruchomić się trzy zupełnie niezależne hooki: jeden generuje krótki playblast obrotu modelu (turntable) i dołącza go jako miniaturkę do rekordu Version z Rozdziału 8; drugi sprawdza, czy nazwa pliku i struktura sceny odpowiadają konwencji z Rozdziału 4, i oznacza publikację jako podejrzaną, jeśli nie; trzeci wysyła powiadomienie na kanał komunikatora działu riggingu, że nowa wersja czeka do podjęcia.
Hooki podpina się na dwa różne sposoby, w zależności od tego, gdzie leży odpowiedzialność. Hook wbudowany bezpośrednio w kod narzędzia publikującego (Rozdział 15) — jako kolejny krok wykonywany po głównej logice — pasuje do reakcji ściśle związanych z samym aktem publikacji, jak generowanie playblastu. Hook zarejestrowany w systemie śledzenia z Rozdziału 8, uruchamiany przez jego własny mechanizm eventów, gdy zmieni się konkretne pole rekordu, pasuje lepiej tam, gdzie reakcja nie powinna zależeć od tego, jakim dokładnie narzędziem ktoś opublikował zmianę — a jedynie od samego faktu, że w bazie coś się zmieniło. Dokładny mechanizm tych eventów pokazuje Dodatek F.
Automatyzacja jest z definicji niewidoczna — to jej cały sens. To jednak dokładnie ta sama cecha, która czyni ją ryzykowną, jeśli nikt nie prowadzi jej ewidencji. Hook napisany przez kogoś, kto dawno odszedł z zespołu, milcząco zaczyna zawodzić po aktualizacji jednej z zależności — i nikt tego nie zauważa, dopóki ktoś nie zapyta, czemu dział riggingu od tygodnia nie dostaje powiadomień. To ten sam rdzeń problemu, od którego zaczęła się ta książka w Rozdziale 1: brak jednoznacznej odpowiedzi na pytanie „co się właśnie stało i dlaczego" — tylko przeniesiony z plików artystów na kod, którego nikt świadomie nie uruchomił.
Część V pokazała, jak powstają narzędzia. Część VI pokazuje, co się dzieje, gdy tych samych narzędzi, tych samych plików i tej samej automatyzacji trzeba użyć nie na jednej maszynie, tylko na tysiącu naraz — zaczynając od farmy renderowej.