Cycles: Materiały podstawowe – długi render

Uwaga!

Zwróć uwagę na datę.

Ten materiał (cokolwiek to jest) został stworzony w czasach gdy nie było Blendera z serii 2.8, i może być PRZESTARZAŁY! Blender rozwija się bardzo szybko.

Tym razem render trwał NAPRAWDĘ długo!
Zaczynając serię na temat materiałów w Cycles postanowiłem zrobić mały film wprowadzający w temat i pokazujący wygląd domyślnych materiałów jakie uzyskuje się w tym silniku. Było to gdzieś w listopadzie minionego roku (obecnie mamy kwiecień). Okazało się, że renderowanie trwało długo, zatem tutoriale przygotowałem bez niego, ale – dysponując niezbyt używaną maszyną, w której siedziały dwie Tesle (C1060 i 2070) – zapuściłem obliczenia, na monitorze powiesiłem kartkę „Nie wyłączać – obliczenia”, i tak zostało. Minęła już chyba zima, podczas której w tym pomieszczeniu cały czas trzymałem otwarte okno (była też kartka – nie zamykać, komputery się przegrzewają), no i w końcu nadszedł koniec obliczeń. Masakra! Dlatego opisuję wszystko w tym poście. Obliczenia wykonywane były przez Blendera w wersji  2.65, a dokładnie:  Blender 2.65 (sub 0) build date: 2012-12-10 build time: 17:19:32 build revision: 52859 build platform: Linux:64bit build type: Release build c flags: -pipe -fPIC -funsigned-char -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -fopenmp -DNDEBUG -O2 -msse -msse2 -DWITH_MOD_FLUID -DWITH_MOD_OCEANSIM -D__LITTLE_ENDIAN__ -DWITH_AUDASPACE -DWITH_AVI build c++ flags: -pipe -fPIC -funsigned-char -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -fopenmp -fpermissive -D__STDC_CONSTANT_MACROS -DNDEBUG -O2 -msse -msse2 -DWITH_MOD_FLUID -DWITH_MOD_OCEANSIM -D__LITTLE_ENDIAN__ -DWITH_AUDASPACE -DWITH_AVI build link flags: -L/home/sources/staticlibs/lib64 build system: SCons W czasie trwania tych obliczeń zmieniła się wersja blendera z 2.65.0 do 2.65.6! Trwało to ponad 4 miesiące! Oczywiście na maszynie wersja pozostała taka sama.

Przygotowanie do renderowania

Mimo, że scena mogła być renderowana jako całość, postanowiłem podzielić renderowanie na fragmenty. Zatem po przygotowaniu całościowego, gotowego pliku ze sceną, zapisałem go w kilku wersjach. W każdej z wersji kamera była ustawiona tak, aby pokazywać inny obiekt. Otrzymałem zatem pliki cycles-diffuse.blend, cycles-emission.blend, itp, które prawie niczym się nie różniły. Kamera jednak renderowała w tych plikach za każdym razem inny obiekt. Dodatkowo, wyrenderowane obrazki zapisywały się do różnych katalogów. Renderowałem etapami, za pomocą kolejnych uruchomień blendera dla wybranego fragmentu sceny, i dla wybranych zakresów klatek. Pomógł z tym prosty skrypt, który pozwalał restartować obliczenia:
#blender -b cycles-diffuse.blend -a
#blender -b cycles-emission.blend -s 404 -a
#blender -b cycles-glass.blend -s 473 -a
#sleep 1
#blender -b cycles-glossy.blend -a
#sleep 1
#blender -b cycles-velvet.blend -s 359 -a
#sleep 1
#blender -b cycles-translucent.blend -s 343 -a
#sleep 1
blender -b cycles-transparent.blend -s 369 -a
#
#sleep 1
#blender -b cycles-holdout.blend -a
Powyżej jest ostatnia wersja tego skryptu, w takiej postaci, jakiej używałem w obliczeniach. Wiersze ze znakiem # są wyłączone i nic nie robią. Po zakończeniu pracy danego blendera w ten sposób wykluczałem go z dalszych obliczeń przy kolejnym restarcie. Gdy musiałem przerwać renderowanie (bo np. trzeba było coś innego na maszynie zrobić), po prostu przerywałem pracę blendera za pomocą Ctrl+C i już. Potem trzeba było zobaczyć, jakie klatki animacji się wyrenderowały, i odpowiednio zmienić numer od którego blender zaczynał. I ponownie uruchomić skrypt. Daty utworzenia klatek wskazywały na długość renderowania. Listing wyrenderowanych klatek wyglądał podobnie do listy:
-rw-r--r-- 1 piotao users 290453 gru 19 22:20 0464.png
-rw-r--r-- 1 piotao users 290329 gru 19 23:38 0465.png
-rw-r--r-- 1 piotao users 290636 gru 20 00:56 0466.png
-rw-r--r-- 1 piotao users 290564 gru 20 02:14 0467.png
Pliki te pochodziły z fragmentu sceny na którym małpka była cała ze szkła w domyślnych ustawieniach. Jak widać, czas renderowania można odczytać z dat modyfikacji. Zatem plik o nazwie 0465.png renderował się 78 minut! Aby dokładnie podliczyć czasy renderowania zrobiłem ze wszystkich katalogów, czyli diffuse, emission, anizotropic, velvet, glass, glossy, transparent, translucent dokładne listy plików z innym formatem czasu, co wyglądało tak:
-rw-r--r-- 1 piotao users 279664 2013-01-13 01:40:10.000000000 +0100 0006.png
-rw-r--r-- 1 piotao users 279728 2013-01-13 02:46:20.000000000 +0100 0007.png
-rw-r--r-- 1 piotao users 279670 2013-01-13 03:52:30.000000000 +0100 0008.png
-rw-r--r-- 1 piotao users 279316 2013-01-13 04:58:40.000000000 +0100 0009.png
Tak zapisane czasy można uzyskać pod linuxem wpisując polecenie ls -l --time-style=full-iso. Są oczywiście inne sposoby, ale zrobiłem to po prostu tak jak było mi wygodnie. Mając takie listy, napisałem mały programik w perlu, który przeanalizował kolejne wiersze i obliczył różnicę czasów pomiędzy kolejnymi plikami. Było to bardzo proste zadanie – wystarczyło z wiersza wyjąć datę, oraz czas, a potem przerobić te dane na daty, i zapamiętać. Podczas wczytywania kolejnego wiersza – czynności powtórzyć i odjąć od poprzednich dat.
Obliczanie czasu obliczeń dla każdej serii plików zapisanych na listach.
Obliczanie czasu obliczeń dla każdej serii plików zapisanych na listach.
Zainteresowanym tematem proponuję napisanie samemu arytmetyki na datach, ja użyłem modułu Date::Calc, który wyliczał ładnie różnicę między dwiema datami, podając ją w dniach, godzinach, minutach i sekundach. Potem wystarczyło jedynie przerobić te dane na sekundy, zsumować i skonwertować na godziny. W wyniku przetworzenia całej listy takich plików otrzymałem zatem od razu liczbę godzin, które zajęły obliczenia. A mając takich katalogów kilka – po prostu zsumowałem ten czas, i dlatego, teraz, po paru miesiącach, mogę z dumą pokazać film, na którym widać materiały podstawowe.

 Statystyka obliczeń

Czas całkowity w godzinach: 2845.26 Czas całkowity w dniach: 118 i pół dnia! Specyfikacja: Intel Core i7 920 @2.67GHz, 12MBGiB ram, Tesla C2070 (5375MB) + Tesla C1060 (4095MB), Maszyna SMP, Linux Debian 7.0 kernel 3.2.39-2 x86_64, NVIDIA GLX Module  310.44 Ustawienia plików podczas renderowania: rozmiar 512×512, samples 2000, 50fps, clamp 0, filter glossy: 0.03, Długość filmu: 500 klatek, 50FPS, film połączyłem cztery razy w VSE aby był dłuższy. Małpka z jednej strony jest wygładzona, z drugiej nie. Wszystkie klatki oryginalnie miały wielkość 512×512 pikseli, dla potrzeb filmu w FullHD zostały umieszczone w siatce 4×2 i odpowiednio pomniejszone. Nie zrobiłem idealnych proporcji, więc teraz ich rozmiar jest inny i dlatego wydają się odrobinę pionowe.

Zmontowany film

Polski Kurs Blendera: Cycles – materiały podstawowe

Do pobrania

Możesz pobrać plik z którego zaczynałem pracę i wypróbować go na swoim komputerze.

Wasze przemyślenia

Sory że to mówię ale zdekka straszne marnotractwo energi z 2 powodów. Po 1 po co taka duża ilość sampli po 2 renderowałeś w 512z512 po czym jak sam mówiłeś przpyadkiem zniszczyłeś proporcje więc nawet mogłeś renderować i miliard sampli ale pikseloza będzie bo zniszczyłeś proporcje.
Wszystko fajnie ale w tym czasie można było wyrenderować coś nie wiem komuś pomóc? zrobić kontekst na rendering jakiejś fajnej animacji dla kogoś kto nie ma komputera czy coś.

A co Ty o tym myślisz?

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *