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.
Renderowanie finalnej jakości pojedynczej klatki potrafi trwać od kilku minut do kilku godzin. Shot ma zwykle kilkadziesiąt do kilkuset klatek. Renderowanie tego lokalnie, na stacji roboczej artysty, zajęłoby dni — i zablokowałoby mu komputer do jakiejkolwiek innej pracy. Farma renderowa istnieje po to, żeby ten czas ścisnąć z dni do minut, wykorzystując setki albo tysiące maszyn naraz, zamiast jednej.
Render kolejnych klatek shotu jest z natury niezależny — klatka 47 nie potrzebuje wyniku klatki 46, żeby się policzyć. Dzięki temu artysta zgłasza jeden job („wyrenderuj shot0100, klatki 1–120"), a farma dzieli go na osobne taski, zwykle po jednej klatce (albo małej ich grupie), i wysyła każdy task na inną wolną maszynę. Sto dwadzieścia klatek na stu dwudziestu maszynach naraz kończy się w czasie jednej klatki, nie stu dwudziestu.
Gdyby zadania wykonywały się dokładnie w kolejności zgłoszenia, artysta testujący drobną poprawkę światła mógłby zablokować farmę na godziny przed supervisorem, który musi wypuścić finalny render na jutrzejszy deadline. Dlatego kolejka farmy zawsze uwzględnia priorytet — wagę uwzględniającą bliskość terminu, rangę showu (Rozdział 17 pokazał, że różne show'y bywają w bardzo różnych fazach) i typ zadania (finalny render zwykle wyprzedza test). Zadania mogą też zależeć od siebie nawzajem — job compositingu czeka, aż skończy się powiązany job lightingu — a scheduler farmy pilnuje tej kolejności automatycznie, bez ręcznej koordynacji między działami.
Zgłoszenie na farmę odbywa się przez narzędzie zbudowane dokładnie tak, jak opisano w Rozdziałach 14–16 — okno, które odczytuje kontekst, wskazuje na opublikowaną wersję sceny (Rozdział 7, nigdy plik roboczy) i wysyła job do kolejki. Kluczowy, łatwy do przeoczenia szczegół: każdy węzeł farmy, zanim zacznie liczyć klatkę, sam rozwiązuje dokładnie to samo środowisko, które miał artysta na swojej stacji — tę samą wersję DCC, wtyczek i configu OCIO, przez ten sam menedżer pakietów z Rozdziału 17. Bez tego renderowana klatka mogłaby się subtelnie różnić od tego, co artysta widział w swoim viewporcie, i to właśnie środowisko, nie sam algorytm renderujący, byłoby winne.
Trzy najpopularniejsze systemy zarządzające tą kolejką to Deadline (AWS Thinkbox), Tractor (rozwijany przez Pixara) i OpenCue (otwarte źródłowo, wywodzące się z Sony Pictures Imageworks) — różnią się szczegółami architektury, ale rozwiązują dokładnie ten sam problem. Porównanie tych trzech znajdziesz w Dodatku M.
Tysiąc maszyn liczących naraz musi też skądś czytać dane — i to szybciej, niż jedna dobra karta sieciowa mogłaby unieść. Następny rozdział pokazuje, dlaczego przy tej skali to właśnie dysk, nie moc obliczeniowa, bywa najdroższym zasobem.