Jak mogę prześledzić scenę, która nie pasuje do pamięci?

Jeśli sceny, która ma zostać poddana raytracingu, nie można zapisać w pamięci, to bez dodania większej ilości pamięci RAM do maszyny renderowanie jej w praktycznym okresie czasu wydaje się nierealistyczne, ze względu na konieczność załadowania różnych części sceny z dysku potencjalnie kilka razy na piksel .

Czy jest na to jakiś sposób? Próbuję wymyślić jakiś sposób wykonywania dużej liczby obliczeń obejmujących konkretny podzbiór sceny naraz, aby zmniejszyć liczbę razy, które trzeba załadować do pamięci. Czy istnieje inny sposób na poprawę prędkości w takim przypadku?

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ą.

Jeśli zorganizujesz scenę w strukturę przestrzenną (zwykle jest to Hierarchia ograniczającej objętości ), możesz użyć pewnego rodzaju sceny wirtualnej (tworzę ten termin w odniesieniu do wirtualnych tekstur ).

Menedżer pamięci utrzymywałby tylko ograniczoną liczbę obwiedni ładowanych jednocześnie i streścił operację polegającą na ich odzyskaniu.

W ten sposób pole zostanie załadowane tylko w razie potrzeby: gdy promień trafi w pole ograniczające, pole zostanie załadowane w celu rozwiązania kolizji. Później, gdy trzeba załadować kolejne pudełko, nieużywane jest usuwane, aby zrobić miejsce na nowe.

Po załadowaniu i usunięciu wszystkich tych skrzynek koherencja promienia byłaby głównym czynnikiem wpływającym na szybkość. Przypuszczam, że dalszą poprawą może być odroczenie załadunku, poprzez zmianę kolejności promieni, aby najpierw traktować skrzynie, które są już załadowane.

To, co robisz, to ładowanie trójkątów do pamięci z dysku na podstawie tego, co zostało wcześniej trafione. Najpierw możesz zacząć od trójkątów w bliskiej odległości. Powodem jest to, że w jednym obszarze promienie prawdopodobnie wielokrotnie uderzają w te same trójkąty. I w końcu będziesz nieco wydajny. (Z tego powodu dobrym pomysłem jest buforowanie ostatniego trafionego trójkąta w śledzeniu okluzji, który nie dba o porządek)

Po drugie, przechowujesz trójkąty w drzewie przestrzennym, które pozwala na szybkie wyszukiwanie z dysku, aby odnowić, jakie części masz w pamięci według odległości. Więc ładuj tylko gałęzie, które będą przeszkadzały w promieniowaniu. Jeśli jest to pewnego rodzaju drzewo wokselowe, takie jak oktawa, możesz nawet sortować promienie wtórne i rozwiązywać je przez spójność. Drzewo BSP jest również dość dobre w obszarach przycinania.

Są przypadki, w których to się nie udaje, ale jest dość wydajne w większości segmentów scen, jeśli nie renderujesz hałasu ...