Skąd supervisor wie, że Twój shot czeka na review — i jak status w przeglądarce zamienia się w plik na dysku.
Rozdział 7 wspomniał, że publikacja „rejestruje nową wersję w systemie śledzenia" — to właśnie ten system jest tematem tego rozdziału. Dla artysty bywa on najbardziej widocznym elementem całego pipeline'u: to strona w przeglądarce, którą otwiera każdego ranka, żeby zobaczyć listę swoich tasków na dziś. Pod spodem to jednak coś znacznie prostszego niż wygląda — baza danych, zbudowana wokół tej samej hierarchii, którą poznałeś w Rozdziale 2.
Show, sequence, shot, asset i task z Rozdziału 2 nie są w systemie śledzenia metaforą — są dosłownymi tabelami w bazie danych, połączonymi relacjami. Rekord Shot ma pole wskazujące na rekord Sequence, do którego należy; rekord Task ma pole wskazujące, do jakiego Shot albo Asset należy, kto jest jego właścicielem (assignee) i jaki ma obecnie status: not started, in progress, pending review, needs work, approved. Kiedy supervisor otwiera dashboard swojego shotu, widzi po prostu zapytanie do tej bazy — wszystkie taski powiązane z tym jednym rekordem Shot, posortowane po dziale i statusie.
Najważniejsza encja w tym modelu, z punktu widzenia całej reszty tej książki, to Version. Powstaje dokładnie w momencie publikacji: niesie odnośnik do rzeczywistego pliku w depocie Perforce (Rozdział 6), miniaturkę albo playblast do szybkiego podglądu bez otwierania ciężkiego pliku źródłowego, oraz własny status, niezależny od statusu całego taska. Jeden task może mieć dziesiątki Version — kolejne próby, poprawki, iteracje — a status taska jako całości zwykle po prostu odzwierciedla status jego najnowszej Version.
To właśnie Version jest tym, co odpowiada na pytanie z podtytułu tego rozdziału: status w przeglądarce nie jest oderwaną etykietą — to pole rekordu, który wskazuje na konkretny plik na dysku. Zmiana statusu tego rekordu (np. z pending review na approved) jest tym, co loader z Rozdziału 7 sprawdza, zanim zaproponuje komuś tę wersję jako „najnowszą zatwierdzoną".
Codzienny (albo kilkurazowy w tygodniu) przegląd nowych wersji, zwany dailies, to rytuał, wokół którego system śledzenia jest w praktyce zbudowany. Supervisor grupuje kilkanaście czy kilkadziesiąt Version od różnych artystów w jedną playlistę, ogląda je po kolei, i przy każdej zostawia notatkę — czasem tekstową, czasem narysowaną wprost na klatce obrazu — razem ze zmianą statusu.
Ten cykl powtarza się tyle razy, ile potrzeba, aż Version dostanie status approved — dopiero wtedy staje się tą wersją, którą inne działy zobaczą jako domyślną, zgodnie z mechanizmem z Rozdziału 7.
Różnice między nimi dotyczą głównie API, kosztu licencji i tego, jak głęboko integrują się z konkretnymi DCC — model danych z tej sekcji, encje Project/Shot/Task/Version i cykl dailies, jest w praktyce niemal identyczny we wszystkich trzech. Dokładniejsze porównanie schematu i mechanizmu eventów znajdziesz w Dodatku F.
Część II domyka temat danych produkcyjnych. Część III wraca do Gita — tym razem nie jako (nieudanego) rozwiązania dla plików artystów, tylko jako właściwego narzędzia do wersjonowania kodu narzędzi, które ten cały system spinają.