Optymalizacja dużych scen 3D: co sprawdzić, zanim viewport zwolni

Dlaczego duża scena 3D zwalnia podgląd i render

Optymalizacja dużych scen 3D wynika z prostej obserwacji. Przybywa geometrii, rosną pliki cache, kurczy się wolna pamięć RAM, a viewport - okno podglądu sceny - spada z 30 do 15, potem do 10 i do 5 klatek na sekundę. Przy większych scenach to zwykły etap pracy, nie awaria.

Pamięć nie rozwiązuje tego sama. W Wizmax pracujemy na stacjach z 192 GB RAM i przy ciężkich mapach oraz szczegółowej geometrii również taki zapas da się zużyć. Przy 128 GB margines jest mniejszy, ale zasada ta sama: RAM pozostaje ograniczeniem.

Liczy się też czas przygotowania renderu. Przykładowo: 20 testowych renderów dziennie, a każdy potrzebuje trzech dodatkowych minut na start i zakończenie. To godzina oczekiwania, która wraca przy każdej poprawce światła, materiału i kompozycji. Dlatego sposób pracy planujemy na początku projektu, a nie wtedy, gdy scena zaczyna się zacinać.

Tekstury 4K i lżejsze HDRI wystarczają częściej, niż się zakłada

Przejście z tekstur 8K na 4K oznacza cztery razy mniej pikseli. Rozmiar pliku i zużycie pamięci nie muszą spaść w tej samej proporcji, bo wpływają na nie format i kompresja, ale przy setkach map różnica bywa odczuwalna. Zwykle zaczynamy od 50-120 materiałów, a po dodaniu tekstur ludzi i roślin ich liczba rośnie. Przy podglądzie o dłuższym boku 500 px zmiany rozdzielczości mapy często nie zobaczymy. Wyjątek robimy dla jednego ważnego materiału, na przykład elewacji na pierwszym planie.

Drugie miejsce kontroli to displacement, czyli mapa, która faktycznie przesuwa geometrię powierzchni. W Coronie, programie liczącym obraz, łatwo przesadzić z parametrem Screen size: im mniejsza wartość, tym gęstsza geometria i większy koszt pamięci. Jeden materiał rzadko robi różnicę, kilkanaście podobnych powierzchni już tak. Drobne nierówności często wystarczy opracować bumpem, a Autobump pomaga zachować detal przy łagodniejszych ustawieniach. Efekt sprawdzamy w kadrze, nie w podglądzie materiału.

Podobnie jest z HDRI, mapą otoczenia, która oświetla scenę i odbija się w szkle. Mapy 16K lub 32K w wielu ujęciach nie są potrzebne, a lżejsze łatwiej zarządzać przy wielu wariantach światła. Gdy HDRI widać bezpośrednio w tle albo w dużym, ostrym odbiciu, utratę szczegółu da się zauważyć. Wtedy można rozdzielić rolę oświetlenia, tła i odbić przez environment overrides w Coronie.

Roślinność

Gęsty rozsiew roślin może liczyć się minutami

Rozsiew to automatyczne rozmieszczenie tysięcy kopii roślin lub drzew na powierzchni, u nas narzędziem Forest Pack. Kopie są instancjami, więc pamięć nie rośnie prostym mnożeniem. Rośnie jednak koszt liczenia ich materiałów, cieni i przezroczystości. Jedna roślina w ujęciu zewnętrznym potrafi mieć ponad milion trójkątów, a rzadko kończy się na jednej.

W rendach 5120 × 2880 jeden rozsiew potrzebował 85 s na start i 26 s na obliczenie obrazu. Gęsta próbka trawy z koniczynami wystartowała po 17 s, ale renderowała się 601 s i ukończyła tylko jeden przebieg, gdy pozostałe próbki po pięć. Każdy rozsiew wykadrowaliśmy osobno, na innych powierzchniach, więc to nie są równoważne warianty. Pokazują za to, że liczba obiektów nie zdradza, który rozsiew jest problemem.

Drugi wniosek dotyczy kamery. Z lotu ptaka pojedyncze źdźbło przestaje być czytelne, ważniejsze są kolor, zróżnicowanie powierzchni i gęstość. Prostszy zestaw roślin sprawdzamy więc w docelowej kamerze i rozmiarze publikacji. Dwa rozsiewy w jednej kamerze liczyły się osobno 74,8 i 33,0 s, razem 88,3 s. Drugi dodał 13,5 s, około 18%. Zajmują jednak inne powierzchnie, więc to nie dowód, że wariant v2 zawsze szybciej zastąpi ten sam fragment zieleni.

RailClone: Embedded i instancing działają osobno

RailClone generuje powtarzalne elementy, na przykład balustrady czy oznakowanie drogi. O jego koszcie decydują dwa osobne ustawienia. Cache Embedded zapisuje przygotowaną geometrię w scenie, więc nie trzeba jej budować od nowa, ale powiększa plik MAX. Use Instancing Engine pozwala współdzielić powtarzalne segmenty podczas renderowania. Wyłączenie automatycznej przebudowy to jeszcze inna funkcja. Warto je rozróżniać, zamiast traktować jak jeden przełącznik.

Tabela poniżej zbiera dwie próby na pojedynczych obiektach. Na balustradach Embedded skrócił render o około 25% względem wariantu bez cache, a szczyt pamięci raportowany przez Coronę spadł o około 67%. Obrazy były praktycznie identyczne pikselowo. Zbudowanie cache zajęło 85,5 s, więc zwraca się po czterech renderach niezmienionego obiektu. Na fragmencie kondygnacji samo Embedded prawie nie zmniejszyło pamięci. Dopiero instancing obniżył ją z 20,78 do 4,10 GB.

W większym zakresie sceny RailClone Embedded z instancingiem zapisał obraz w 148,9 s, a budynki zamienione na Corona Proxy w 146,6 s. Szczyt pamięci fizycznej procesu wyniósł odpowiednio 27,8 i 59,8 GiB. Plik MAX zmalał z około 3,57 do 2,50 GB, ale obok powstało około 1,01 GB proxy. Ciężar w dużej mierze zmienił miejsce. Po jednej próbie na wariant nie mówimy o przewadze czasowej.

Podgląd też kosztuje. Przy 33 obiektach RailClone tryb Boxes obniżył średni koszt odświeżenia z 3,79 do 2,02 ms, o około 47%. Test obejmował kontrolowany obrót widoku i nie gwarantuje konkretnego FPS przy ręcznej pracy. Pełny podgląd zostawiamy tam, gdzie naprawdę go potrzebujemy.

Porządkowanie zaczyna się od sprawdzenia zależności

Biblioteka ustawiona obok modelu jest wygodna, ale z czasem zostają w niej elementy po usuniętych rozsiewach i starych wersjach. Nie wystarczy zaznaczyć wszystko, czego nie widać w kamerze, i usunąć. W raporcie z czyszczenia liczba węzłów sceny spadła z 4 617 do 3 493. Usunęliśmy 1 124 nieużywane elementy, około 24,3%, a kolejne 217 zostawiliśmy ze względu na zależności.

Potem uprościliśmy stosy 195 statycznych modeli i usunęliśmy 373 wpisy modyfikatorów, po sprawdzeniu geometrii i mapowania. Usunięcie UVW Map może zmienić ułożenie tekstur, a Edit Poly cofnąć edycje geometrii. Dlatego scalaliśmy wynik, a kopię modeli zapisaliśmy przed zmianą. W edytorze materiałów zostawiliśmy trzy widoki (MAT, HDRI, WNETRZA), a sześć usunęliśmy po zapisaniu kopii. Przypisania materiałów zachowano. To osobne etapy i bez pomiaru renderu nie przypisujemy im procentu przyspieszenia.

Raport narzędzia diagnostycznego to dopiero początek analizy. SiNi Forensic wskazał 69 brakujących wtyczek, ale kontrola przez API 3ds Max tego nie potwierdziła, więc nie usuwaliśmy ich zbiorczo. Pięć brakujących tekstur RailClone wymagało osobnego rozwiązania. Ustawienia konwertera dla V-Raya nie są receptą dla sceny w Coronie, a masowa zmiana UVW, displacementu czy widoczności źródeł może zepsuć potrzebny efekt.

Szybki test i finalny render odpowiadają na różne pytania

Przy ustawianiu kamery sprawdzamy kompozycję, przy odbiorze detalu - konkretną fakturę, balustradę albo odbicie. Uruchamianie za każdym razem tego samego długiego profilu spowalnia kolejne decyzje. W Camera 02 porównaliśmy trzy profile przy tej samej kamerze, geometrii, materiałach i oświetleniu, w natywnych 3072 × 1728 px i z wyłączonym displacementem.

Profil A (limit renderowania 10 min) skończył po 11 min 52 s z końcowym surowym szumem 8,05%. Profil B (5 min) po 6 min 19 s z 11,04%, a profil C (3 min) po 4 min 26 s z 14,41%. C był więc o około 63% krótszy od A. Zmieniliśmy jednak także limit, sposób odszumiania i próbkowanie, a wszystkie trzy próby zatrzymał limit czasu. To porównanie użyteczności profili, nie dowód, że tę samą jakość policzymy trzy razy szybciej. Również A pozostał zaszumiony.

Dlatego wolimy szybki profil roboczy i osobną ocenę wymagań finalnego materiału. Zbliżenia, trudne odbicia i druk mogą wymagać dokładniejszej kontroli. Wyników z nieruchomego kadru nie przenosimy na animację, gdzie trzeba sprawdzić stabilność detalu i odszumiania między klatkami.

Rzadko we wszystkich materiałach. Przejście z 8K na 4K to cztery razy mniej pikseli, a przy podglądzie o dłuższym boku 500 px różnicy często nie widać. Wyjątek robimy dla powierzchni na pierwszym planie, na przykład elewacji.

Edytor materiałów też zbiera zbędne gałęzie

W Slate Material Editor, edytorze łączącym materiały i mapy w graf, z czasem przybywa widoków, kopii materiałów i elementów po wcześniejszych wariantach. Samo znalezienie właściwej gałęzi zajmuje wtedy więcej uwagi, niż powinno.

W naszej scenie zostawiliśmy trzy widoki (MAT, HDRI, WNETRZA), a sześć usunęliśmy po zapisaniu kopii ich materiałów i map. Usunięcie widoku nie usuwa materiału przypisanego do obiektu, więc przypisania i środowisko zostały. Zysk jest organizacyjny: mniej zakładek, prostsze szukanie. Nie mamy pomiaru, który przypisałby tej zmianie oszczędność czasu otwierania sceny lub renderu.

Proxy odciąża plik, a czas renderu zostaje podobny

Większy zakres sceny pokazał, że ciężar potrafi zmienić miejsce. RailClone Embedded z instancingiem zapisał obraz w 148,9 s, a budynki zamienione na Corona Proxy w 146,6 s. Szczyt pamięci fizycznej procesu wyniósł odpowiednio 27,8 i 59,8 GiB.

Plik MAX zmalał po konwersji z około 3,57 do 2,50 GB, ale obok powstało około 1,01 GB plików proxy. Proxy to obiekt wczytywany z osobnego pliku, więc odciąża plik sceny i viewport. Chaos opisuje je właśnie w tej roli, a nie jako automatyczny sposób na szybszy rendering. Przy wyborze porównujemy więc czas renderu, szczyt pamięci i miejsce na dysku, każde osobno.

Detal

Wycinki 100% pokazują, co wygładza krótszy profil

Wycinki w skali 100% pokazują różnicę, której nie widać z daleka. Profile B i C mocniej wygładzają roślinność i zaszumione odbicia. Również A pozostaje zaszumiony i nie jest bezszumowym wzorcem. Podane czasy obejmują przygotowanie, rendering, odszumianie i zapis.

Dlatego wolimy szybki profil roboczy i osobną ocenę wymagań finalnego materiału. Oszczędzony czas ma sens wtedy, gdy obraz nadal pozwala podjąć właściwą decyzję. Zbliżenia, wymagające odbicia lub druk mogą potrzebować dokładniejszej kontroli. Wyników z nieruchomego kadru nie przenosimy automatycznie na animację, gdzie trzeba sprawdzić stabilność detalu i odszumiania między klatkami.