Unreal got real

W zasadzie była tylko jedna rzecz, na którą rzeczywiście czekałem przed E3. Byłyby dwie, gdybym choć jedną komórką nerwową wierzył, że Valve pokaże tam Steam i Source na Linuksa, ale mniejsza z tym. Na co czekałem? Oczywiście na prezentację nowego silnika Epic, Unreal Engine 4. Ogłaszam wszem i wobec, że się doczekałem i czuję się sponiewierany. Ale po kolei. Na wstępie muszę zaznaczyć, że będę pisał niekoniecznie tłumacząc to, co piszę. Mam nadzieję, że jest na Grastro kilka osób, które mimo wszystko zrozumieją ten tekst, a pozostałych i tak zachęcam do przeczytania i zapoznania się z prezentacją Epic.

Zacznijmy od filmiku, bo naprawdę nie ma na co czekać, po prostu trzeba oglądać. Tylko nie zapomnijcie później wrócić do czytania, bo mam tu kilka słów do dodania ;).

Poza, dla odmiany wyglądającym na zdatny do użytku (oraz ewidentnie inspirowany Unity i CryEngine’em), edytorem największą zmianą w UE4 w stosunku do jego poprzednika jest „opóźniony wyświetlacz”, czyli deferred renderer. Pierwsze komary zwiastujące jego nadejście pojawiły się w ostatniej aktualizacji do UE3 (i do UDK chyba też), kiedy to dodany został DX11, a wraz z nim cała menażeria efektów zaprezentowanych z przytupem (zwłaszcza jak skakał z dachu to był przytup jak ta lala) w Samarytaninie. Nawiasem mówiąc, zdarzało mi się chwalić Epic za cierpliwość w oczekiwaniu na API, w którym deferred shading stanie się obywatelem pierwszej, zamiast czwartej kategorii i nadal uważam, że była to bardzo dobra decyzja z ich strony, podobnie jak np. decyzja DICE o niewłączaniu do Frostbite 2 renderera DX9, co byłoby zwyczajną stratą czasu i wysiłku.

Global Illuminati…. um, illumination

Sam deferred shading nie jest więc nowością w UE, a już na pewno nie jest nowością ogólnie, bo przecież napędzał oświetlenie w Stalkerze, CryEngine i wszystkich grach Rockstar od czasu GTA4. Nie oznacza to jednak, że wszystko już widzieliśmy, oj nie. Podczas gdy w demie „UE3.9” sprzed roku (jak ten czas leci, matko…) widzieliśmy m.in. nowe odbicia, bokeh DOF czy sub-surface scattering, a na opisywanej prezentacji pokazano również nowy system decali, palmę pierwszeństwa wśród nowości w UE4 bezsprzecznie dzierży global illumination.

Muszę uczciwie powiedzieć, że cała rzecz robi dość spore wrażenie. Kiedy pierwszy raz o tym przeczytałem, od razu przyszło mi na myśl, że Epic zwyczajnie zintegrował w UE4 tą samą technologię, która stała się znakiem firmowym Frostbite 2 od DICE, czyli Geomeric Enlighten. To wydawało się tym bardziej logiczne, że całkiem niedawno Enlighten trafił do UE3, choć nie jako zintegrowana technologia, a jedynie jako wtyczka dla zainteresowanych. Okazuje się jednak, że UE4 działa na zupełnie innych algorytmach, dzięki którym odsadza konkurencję tak samo, jak Frostbite wyprzedził ją integrując middleware od Geomeric.

Odbicie lustrzane od dynamicznego obiektu w stronę podłogi zmienia się wraz z materiałem

Epic twierdzi, że ich GI działa w stu procentach w czasie rzeczywistym. Podobne twierdzenia padały w materii Enlighten, z tym że tam występowały z pewnym zastrzeżeniem — podczas budowania mapy trzeba było zbudować również jej uproszczoną wersję, która służyła do zapisania informacji o odbiciach od statycznej geometrii w lightmapach i próbnikach (te zapisywane były chyba przy pomocy spherical harmonics, chociaż głowy sobie za to uciąć nie dam). Później można już sobie przestawiać światła i pobierać odbicia dla dynamicznych obiektów z ambient probe’ów, ale wprowadza to pewne istotne ograniczenia. Po pierwsze, co prawda liczenie tej kosmicznie małej lightmapy zabiera tylko kilka minut, ale jednak zabiera. Te kilka minut to postęp w stosunku do generowania lightmap normalnej wielkości, ale nadal potrafi się złożyć na sporo czasu w przypadku wielu iteracji mapy. Drugi problem jest taki, że podczas gdy dynamiczne obiekty mogły odbierać światło od obiektów statycznych, to same go nie odbijały. Jeśli nie mylą mnie oczy i uszy, to w przypadku UE4 jest inaczej. Jest lepiej.

Na filmie widać dynamiczne, jaskrawe obiekty, takie jak statuy czy zielona planeta, odbijające światło, które następnie przenosi się na inne dynamiczne obiekty, a także na statyczne ściany i statyw tellurium. Co więcej, w pewnym momencie widać nawet bug powodujący gigantyczne zwiększenie (i za razem lepsze zademonstrowanie, hahaha) tego efektu. Chodzi o okolicę 1 min. 50 sekund na nagraniu, gdzie widać mocno przejaskrawiony efekt odbicia światła przez zieloną planetę (screen poniżej). Kolor „krwawi” naprawdę solidnie, odbijając się w ścianach i w tej planeto-latarce. Dodatkowo, kiedy już prezentacja przenosi się do edytora, widać że odbicia lustrzane na statuach (które są dynamiczne, jak widać na samym początku nagrania) są faktycznie oparte o światło odbite, a więc o GI, a nie o klasyczne metody symulowania tego rodzaju efektów. Dalej ponownie bardzo ładnie widać światło odbijające się od zielonej planety w stronę statywu oraz w stronę srebrnej planety z pierścieniami.

This scene is bugging me

To wszystko oznacza, że Epic całkowicie wyeliminował konieczność jakiejkolwiek wstępnej kalkulacji oświetlenia i wbudował w swój kombajn prawdziwe global illumination w czasie rzeczywistym, a więc wprowadził prawdziwą rewolucję. Nie tylko w materii samego wyglądu gier, który nauczyliśmy się poprawiać przy pomocy całej masy hacków, ale przede wszystkim od strony szybkości developmentu. Jeśli level designer będzie mógł wstawić sobie do sceny jedno światło, ustawić parametry materiałów, kliknąć „Play” i natychmiast zobaczyć scenę taką, jaką powinna być zgodnie z podstawowymi prawami rzeczywistej fizyki, to jest to naprawdę przełom. Koniec fill lights, koniec lightmap, koniec czekania.

Puszczając wodze googla…

Oczywiście kiedy tylko to wszystko zobaczyłem, natychmiast zacząłem szukać wskazówek mogących mnie naprowadzić na wykorzystywane algorytmy. Jedyną, która pojawia się w prezentacji jest termin „voxel lighting”. Algorytm na który natrafiłem po krótkich poszukiwaniach został opisany w dokumencie z SIGGRAPH 2011 zatytułowanym „Interactive Indirect Illumination Using Voxel-Based Cone Tracing” (pełna wersja). Oczywiście twierdzenie, że to właśnie z takiej techniki korzysta UE4 jest niczym więcej jak spekulacją, ale pozwalam sobie na nią, bo global illumination samo w sobie cholernie mnie interesuje, zwłaszcza w wydaniu real time. Jeszcze ciekawsze jest to, że rzeczona technika wykorzystuje do przybliżenia sceny i przeliczenia odbić aktualizowane w czasie rzeczywistym sparse voxel octree, czyli strukturę, którą powinien kojarzyć każdy, kto widział demka Unlimited Detail. Całe budowanie drzewka opiera się zaś na GPU, dzięki czemu może być ono aktualizowane na bieżąco, a co za tym idzie obsługiwać dynamiczne, animowane obiekty nie tylko od strony pobierania przez nie światła, ale też jego odbijania.

Opis algorytmu wspomina również, że wydajność całego procesu jest praktycznie niezależna od geometrycznej złożoności sceny, zaś demonstracje algorytmu śmigały na jednym GTX480 z prędkością od 20 do nawet 70 klatek na sekundę. Oczywiście były one prostsze niż demo UE4, gdyż w głównym przedmiocie niniejszego tekstu do głosu dochodzi jeszcze SSS, cząsteczki itd., niemniej ta wydajność pokrywałaby się więc z tym, co twierdzi Epic — że cała prezentacja UE4 działała na jednej karcie GTX680.

Dla porządku napiszę jeszcze raz — cały ten paragraf traktujcie z rezerwą. Czas i, mam szczerą nadzieję, przyszłe publikacje być może go zweryfikują. Zanim to jednak nastąpi, zobaczcie sobie prezentację opisywanej techniki, która może nie mieć nic wspólnego z UE4, ale i tak jest zajebista:

Unreal KisEd

Co jeszcze zmieniło się w UE4? Wspomniany edytor. Teraz wygląda na mocno inspirowany edytorem Unity, z domieszką tego z CryEngine i bynajmniej nie jest to wada — w porównaniu z Unreal Editor z UE3, w którym połapanie się było niemal nierealne, ten ma ręce i nogi. Wygląda czytelnie i z całą pewnością jest bardziej elastyczny. Oczywiście jego faktyczna jakość zostanie zweryfikowana w użytkowaniu, dlatego mam nadzieję, że prędzej czy później UE4 pojawi się w formie UDK. Największa zmiana w materii devu to jednak z całą pewnością Kismet.

O tym, że Kismet ma zastąpić, a nie jak dotąd uzupełniać, UnrealScript było wiadomo od bodaj kilku tygodni. Mnie się ten pomysł średnio podobał, bo jako programista lubię się babrać w kodzie, ale niekoniecznie w kodzie C++, gdzie za każdym rogiem czai się seryjny memory leak; a to właśnie C++ ma być jedyną opcją dla „nieklikających” programistów w UD4. Kismet zresztą też ma wypluwać z siebie kod we wspomnianym języku. Po obejrzeniu tej prezentacji jestem jednak znacznie przychylniej nastawiony do całej koncepcji.

Co prawda w pewnym momencie widać kod odpowiedzialny za napędzanie tellurium, który wygląda jak talerz spaghetti albo futurystyczny karabin z masą luf, ale wizualizacja przepływu mnie kupiła. I na dodatek, cholera, ładnie to wygląda — mało istotna własność kiedy mowa o programowaniu, ale skoro jest to wypada wspomnieć. Kupiło mnie również całkowicie „bezszwowe” kompilowanie skryptów w tle, dzięki czemu w oczekiwaniu na efekt można zająć się innymi rzeczami, a kiedy efekt już się zbuduje — natychmiast trafia do gry. Oczywiście język skryptowy w rodzaju Pythona czy JavaScriptu czas oczekiwania na zbudowanie kodu zmniejszyłby do zera, ale jednak takie rozwiązanie sprawia, że skryptowanie jest ładnie wbudowane w edytor i nie powinno wywoływać zbytniej irytacji, nawet pomimo biegającego za kulisami C++.

Podsumowanie, aka „doczytał tu ktoś?”

Unreal Engine 4 to rewolucja. Jeśli mnie wzrok nie myli i faktycznie widzę dynamiczne obiekty uczestniczące w RTGI na równych ze statycznymi prawach, to jest to rewolucja bez dwóch zdań. Tak w tym, jak gry będą wyglądać jak i w tym jak szybko będą tworzone, a to z każdą generacją, każdym wzrostem rozdzielczości i mocy obliczeniowej, ma coraz większe znaczenie. Czekam z niecierpliwością na efekty wykorzystania tej technologii w praktyce.