Jeśli scena nie mieści się całkowicie w pamięci, wkraczasz w obszar renderowania poza rdzeniem. Istnieją tutaj zasadniczo dwa podejścia: a) Wygeneruj scenę na żądanie b) Załaduj scenę na żądanie
Pierwsze podejście dobrze współgra z większością przepływów pracy z animacjami, w których modele są silnie podzielone za pomocą np. Catmull-Clark i mogą stać się bardzo wymagające pamięci, ale same siatki podstawowe łatwo pasują do pamięci. Pixar ma na ten temat kilka artykułów (np. Różnicowanie promieni i buforowanie geometrii multiresolution w celu śledzenia śledzenia rozkładu w złożonych scenach ), ale jego sedno polega na tym, że modele są dzielone tylko wtedy, gdy są uderzone przez promień, i dzielą tylko tyle, ile jest uzasadnione dla takiego promienia (np. rozproszone wzajemne odbicie wymaga mniejszej dokładności niż odbicie lustrzane). Reszta jest obsługiwana przez pamięć podręczną geometrii, która przechowuje podzielone modele w pamięci i, mam nadzieję, czyni ten proces wydajnym dzięki dobrej strategii eksmisji.
Tak długo, jak wszystkie podstawowe siatki wygodnie mieszczą się w pamięci, możesz łatwo wyjść poza rdzeń i renderować siatki na poziomach podziału, które nigdy nie zmieściłyby się w pamięci. Pamięć podręczna geometrii skaluje się również ładnie z ilością posiadanej pamięci, umożliwiając ważenie pamięci RAM i czasów renderowania. To również zostało wykorzystane w Cars, jak sądzę.
Drugie podejście jest bardziej ogólne i nie polega na intensywnym stosowaniu podziału. Zamiast tego opiera się na fakcie, że twoja scena została najprawdopodobniej wykonana przez artystę i jest już podzielona na stosunkowo małe obiekty, które indywidualnie pasują do pamięci. Ideą jest zatem utrzymanie dwóch hierarchii (drzewa kD lub hierarchii woluminów ograniczających): hierarchii najwyższego poziomu, która przechowuje tylko ramki ograniczające obiektów w scenie, oraz hierarchii niskiego poziomu, która przechowuje rzeczywistą geometrię. Dla każdego obiektu istnieje jedna taka hierarchia niskiego poziomu.
W tym podejściu idealnie już przechowujesz obwiednię wraz z każdym obiektem na dysku. Gdy scena jest ładowana, początkowo budujesz hierarchię najwyższego poziomu, co oznacza, że musisz tylko patrzeć na obwiednie, a nie na geometrię. Następnie zaczynasz śledzić promienie i przechodzić je przez hierarchię. Ilekroć promień uderza w węzeł liścia w hierarchii najwyższego poziomu (tj. Uderza w obwiednię obiektu), obiekt ten jest ładowany do pamięci i tworzona jest jego hierarchia niskiego poziomu. Promień kontynuuje śledzenie tego obiektu. W połączeniu z pamięcią podręczną obiektów, która zachowuje jak najwięcej hierarchii niskiego poziomu w pamięci, może to działać dość dobrze.
Pierwszą korzyścią takiego podejścia jest to, że obiekty, które nigdy nie zostaną trafione, nigdy nie są ładowane, co oznacza, że automatycznie dostosowuje się do widoczności na scenie. Drugą korzyścią jest to, że jeśli śledzisz wiele promieni, nie musisz od razu ładować obiektu, ponieważ zostanie on trafiony przez promień; zamiast tego możesz przytrzymać ten promień i poczekać, aż dostatecznie dużo promieni trafi w ten obiekt, amortyzując obciążenie po kilku trafieniach promieniem.
Możesz także połączyć to podejście z algorytmem sortowania promieni, takim jak Posortowane odroczone cieniowanie do śledzenia ścieżki produkcyjnej, aby uniknąć przeładowania z powodu niespójnych promieni. Wspomniany artykuł opisuje architekturę renderera Hyperion Disneya, używanego w Big Hero 6, wierzę, więc najprawdopodobniej może obsługiwać sceny na skalę produkcyjną.