Cycles: Materiały podstawowe – długi render 10

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

Do pobrania

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

10 thoughts on “Cycles: Materiały podstawowe – długi render

  1. Odpowiedz Kramon Kwi 26,2013 23:40

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

  2. Odpowiedz Seweryn Kwi 18,2013 10:56

    Racja , maszyny same nic nie zrobią. Są tylko narzędziem , inwencja twórcy i wena to podstawa w pracy grafika.
    Zawsze zastanawiało mnie dlaczego obrazy Pablo Picasso czy Van Gogh’a maja taką wartość i dochodzę do wniosku że płaci się za nazwisko twórcy.
    Analogiczna sytuacja, w każdej gałęzi sztuki płaci się za umiejętności i renomę twórcy.

    • Odpowiedz piotao Kwi 18,2013 21:44

      Płaci się też za czas, który te prace przeżyły i za to, co zmieniły na świecie i sztuce. Ci ludzie, zwłaszcza Picasso byli geniuszami i ich sztuka to nie tylko ładne obrazy, ale przekaz, który niejednemu odbiorcy dał popalić :) Dorosła sztuka, głęboka, wielowymiarowa. Dlatego te nazwiska są w cenie!

  3. Odpowiedz Seweryn Kwi 18,2013 00:07

    No ale komputery obrabiające te efekty też są , jak to się mówi kolokwialnie , wypasione.
    Wydaje mi się że sprzęt ma w efektach specjalnych drugie miejsce po doświadczeniu ludzi.
    Powiedz sam , gdybyś miał do dyspozycji Blue Gene’a można by było skrócić czas obliczeń dość spektakularnie , ale wtedy koszt usługi rośnie proporcjonalnie do czasu realizacji oraz eksploatacji maszyny.

    • Odpowiedz piotao Kwi 18,2013 08:29

      Renderfarmy nie składają się z najbardziej wypasionych komputerów. Raczej buduje się je z tanich i ‚budżetowych’ jednostek, w pewnym zakresie optymalizując stosunek kosztu do wydajności. Nie są to też jakieś złomy… ale przeciętne, stabilne maszyny, których jakość jest obliczona na długą pracę. Poza tym – nie mówimy o PCtach tylko szufladach rakowych a takie pracować mogą przez lata, bez przerwy. To innej klasy sprzęt. Drogi, ale bez przesady.
      Ludzie kosztują więcej, i czas ich pracy jest dłuższy niż czas renderfarmy.
      Gdy pytałem parę lat temu Bagińskiego na prezentacji Kinematografa jak sobie radzi z renderowaniem, powiedział, że nie jest problemem dostawić kilka jednostek. Maszyny to tylko maszyny – potrzebujesz – masz. Spróbuj znaleźć za to odpowiednich ludzi z wysokim skillem :)

  4. Odpowiedz Seweryn Kwi 17,2013 23:20

    118 dni!!!
    Zaczynam rozumieć dlaczego efekty specjalne w filmach są drogie.

    • Odpowiedz piotao Kwi 17,2013 23:42

      Drogie są głównie dlatego, że fachowcy, którzy robią efekty, sporo kosztują. Gościu, który całe życie przeznaczył nad zaleganie przed kompem, klikanie guzików i suwaków, i edycję materiałów video najczęściej życzy sobie sporo kasy. Im tacy są lepsi, tym mniej widać cyfrową obróbkę. Doskonałe efekty poznaje się po tym, że nie można ich odróżnić od prawdziwego filmu.

  5. Odpowiedz ADDJAR Kwi 17,2013 11:30

    A ja myślałem że mi długo renderują się projekty :)

  6. Odpowiedz alik Kwi 17,2013 08:10

    Czy ten komputer miał naprawdę 12MB pamięci RAM?

A Ty co o tym myślisz?