Symulacja zjawisk naturalnych przy wykorzystaniu silnika graficznego CryEngine

Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki Rok akademicki 2013/2014 PRACA DYPLOMOWA INŻYNIERSKA Mateusz Andrzej Zawiślak Symulacja zjawisk naturalnych przy wykorzystaniu silnika graficznego CryEngine Opiekun pracy mgr Krzysztof Chabko Ocena:...... Podpis Przewodniczącego Komisji Egzaminu Dyplomowego

Kierunek: Informatyka Specjalność: Inżynieria Systemów Informatycznych Data urodzenia: 08.08.1991 Data rozpoczęcia studiów: 01.10.2010 Życiorys Urodziłem się 8 sierpnia 1991 roku w Janowie Lubelskim, lecz moim miastem rodzinnym jest Biłgoraj. W roku 2004 ukończyłem Szkołę Podstawową nr 3 w Biłgoraju. W latach 2004 2010 kontynuowałem naukę w Zespole Szkół Ogólnokształcących w Biłgoraju, najpierw w Powiatowym Gimnazjum nr 2, a następnie Liceum Ogólnokształcącym im. ONZ w klasie o profilu matematyczno-informatyczno-fizycznym. Egzamin maturalny zdałem w 2010 roku i zostałem przyjęty na studia dzienne na Wydziale Informatyki i Technik Informacyjnych Politechniki Warszawskiej. W trakcie piątego semestru wybrałem specjalizację Inżynieria Systemów Informatycznych.. podpis studenta Egzamin dyplomowy Złożył egzamin dyplomowy w dn... z wynikiem. Ogólny wynik studiów... Dodatkowe uwagi i wnioski Komisji....

Streszczenie Przedmiotem niniejszej pracy jest symulacja zjawiska burzy jako ilustracji rozbudowy silnika gry CryEngine. Pierwsza część pracy jest wprowadzeniem w tematykę tworzenia wirtualnych rzeczywistości z wykorzystaniem dostępnych na rynku silników gier i grafiki oraz przedstawieniem problemu wizualizacji zjawisk naturalnych. Kolejne rozdziały dokładnie opisują proces tworzenia nowych elementów omawianego silnika wraz z opisem wykonanej symulacji burzy. Ostatnia część to załączniki. Znajdują się w nich propozycje zajęć laboratoryjnych prezentujących możliwości rozbudowy silnika CryEngine wersji 3.4.5. Słowa kluczowe: CryEngine, burza, rozbudowa, zjawisko naturalne Abstract The simulation of natural phenomena using graphics engine CryEngine The object of this thesis is simulation of the phenomena of the storm as an example of an CryEngine s game engine expansion. The first part of the thesis preludes to the subject of creating virtual realities using a commercially available game and graphics engines. It also contains a representation of the problem of visualization of natural phenomena. Next chapters thoroughly describe the process of creating new elements of this engine with the description of the created storm simulation. In the last part, there are attachments. They present the proposals of the laboratory using CryEngine version 3.4.5. Key words: CryEngine, storm, extension, natural phenomenon

1. WSTĘP... 5 1.1. WPROWADZENIE... 5 1.2. CEL PRACY... 5 1.3. PLAN PRACY... 6 2. PRZEGLĄD DOSTĘPNYCH ŚRODOWISK DO PROJEKTOWANIA WIRTUALNYCH RZECZYWISTOŚCI... 7 2.1. PROJEKTOWANIE WIRTUALNE... 7 2.2. DEFINICJA SILNIKA GRY... 7 2.3. SILNIK CRYENGINE 3... 8 2.4. ALTERNATYWNE ROZWIĄZANIA... 11 2.5. SPOJRZENIE W PRZYSZŁOŚĆ... 12 3. WIZUALIZACJA BURZY... 14 3.1. CHARAKTERYSTYKA PROBLEMU... 14 3.2. ZAŁOŻENIA... 16 3.3. WYMAGANIA... 17 4. PROJEKT ROZWIĄZANIA I OPIS WYBRANYCH ELEMENTÓW IMPLEMENTACJI... 18 4.1. PROJEKT INTERFEJSU... 18 4.2. ZARYS ARCHITEKTURY ROZWIĄZANIA... 19 4.3. MODELOWANIE DESZCZU... 22 4.4. BŁYSKI WRAZ Z PIORUNAMI... 28 4.5. WIATR JAKO POPRAWA FUNKCJONALNOŚCI SILNIKA... 33 4.6. PROBLEMY NIEROZWIĄZANE... 34 5. OCENA ROZWIĄZANIA... 37 5.1. JAKOŚĆ SYMULACJI... 37 5.2. OCENA ZŁOŻONOŚCI PROCESU ROZBUDOWY SILNIKA... 39 6. PODSUMOWANIE... 40 7. BIBLIOGRAFIA... 41 8. ZAWARTOŚĆ PŁYTY CD... 42 9. ZAŁĄCZNIKI... 43 ZAŁĄCZNIK A. ZAPOZNANIE ZE ŚRODOWISKIEM CRYENGINE 3 FREE SDK... 43 ZAŁĄCZNIK B. WPROWADZENIE DO TWORZENIA WŁASNYCH OBIEKTÓW DLA SILNIKA CRYENGINE 3... 48 ZAŁĄCZNIK C. SYMULACJA PROSTYCH ZJAWISK NATURALNYCH W CRYENGINE 3... 56 4

Wstęp 1. Wstęp 1.1. Wprowadzenie Grafika komputerowa to dziedzina informatyki zajmująca się tworzeniem szeroko pojętej grafiki przy pomocy komputera. Obecnie jest powszechnie stosowana w rozrywce, nauce oraz technice [3]. Od lat artyści starają się przedstawić przy jej pomocy swoje wizje, a naukowcy prowadzić symulacje różnego rodzaju sytuacji. Podstawowym kryterium podziału zastosowania grafiki może być typ danych. Na tej podstawie wyróżniamy grafikę dwuwymiarową i trójwymiarową. Pojęcie trójwymiarowości należy rozumieć jako przedstawianie obiektów umieszczonych w przestrzeni trójwymiarowej na dwuwymiarowym obrazie. Za kolejne kryterium należy uznać cykl generacji obrazu. Na jego podstawie należy wyróżnić grafikę czasu rzeczywistego, w której program musi bardzo szybko odświeżać obraz [3]. Trójwymiarowa grafika czasu rzeczywistego odgrywa kluczowe znaczenie w różnego rodzaju symulacjach i grach komputerowych oraz wszędzie tam, gdzie wymagana jest interakcja z użytkownikiem. Najpotężniejszą dziedziną jej zastosowań pozostają jednak gry komputerowe. Dążenie do fotorealizmu istotnie wpływa na szybkość rozwoju tej gałęzi grafiki komputerowej. Najpopularniejsze gry komputerowe tworzone są dzięki silnikom gier, które oferują na dzień dzisiejszy szeroki zestaw rozwiązań posiadających zróżnicowane funkcjonalności. Najnowsze trendy ukierunkowują jej rozwój w stronę odwzorowywania natury w środowisku wirtualnym. Wraz z rozwojem silników efekty staja się coraz ładniejsze i bardziej dopracowane. 1.2. Cel pracy Jednym z najpopularniejszych silników koncentrujących się na, jak najdokładniejszym odwzorowania natury w wirtualnym środowisku jest produkt firmy Crytek CryEngine. Celem pracy inżynierskiej było stworzenie symulacji zjawiska naturalnego, jakim jest burza, przy wykorzystaniu wspomnianego silnika. Animacja powinna wyglądać realistycznie i wykorzystać możliwości oferowane przez CryEngine. Wszystkie działania związane z animacją muszą być prowadzone w czasie rzeczywistym. Stworzony obiekt musi bowiem móc stanowić fragment większej sceny interaktywnie odwzorowującej działanie natury. Opis wykonanego rozwiązania powinien ponadto stanowić swoisty szablon tworzenia nowych elementów, zrozumiały dla programistów rozpoczynających pracę z tym silnikiem. 5

Wstęp 1.3. Plan pracy Niniejsza praca podzielona została na cztery zasadnicze części. Pierwsza część to rozdział drugi dokonujący przeglądu dziedziny i dostępnych na rynku gotowych rozwiązań. Wyjaśnione zostały w nim podstawowe definicje w celu wprowadzenia czytelnika w tematykę pracy. Drugą, główną część pracy stanowią rozdziały 3 6. Rozdział 3 zawiera szczegółowe sformułowanie problemu pracy. Wymienione zostały założenia i wymagania stawiane omawianemu w dalszej części rozwiązaniu. Rozdział 4 przedstawia krok po kroku proces rozbudowy silnika CryEngine na przykładzie obiektu symulującego zachowanie burzy. Dodatkowo opisane zostały nierozwiązane problemy, wraz z ich przyczynami. Rozdziały 5 oraz 6 to omówienie sposobu oceny rozwiązania, wnioski oraz podsumowanie całości symulacji burzy, jako ilustracji definiowania nowych elementów silnika CryEngine. Organizacyjna część trzecia to rozdziały 7 i 8. Bibliografia z rozdziału 7 zawiera spis książek, stron WWW oraz artykułów wykorzystanych jako źródła informacji, niezbędne podczas tworzenia pracy inżynierskiej. Rozdział 8 opisuje zawartość dołączonej płyty CD. Ostatnią czwartą, a zarazem niezwykle istotną część pracy stanowią załączniki zawierające propozycje tematyki laboratoriów przedstawiających możliwości rozwoju silnika CryEngine. Każdy z nich kończy się zestawem poleceń dla uczestników danych zajęć. Do każdego z zadań laboratoryjnych zostało dołączone przykładowe rozwiązanie. Wszystkie rysunki znajdujące się w pracy zostały oznaczone dodatkowym, krótkim opisem. Jeżeli obrazek nie został wykonany przez autora pacy, informacja o jego pochodzeniu została umieszczona na końcu tego opisu. 6

Przegląd dostępnych środowisk do projektowania wirtualnych rzeczywistości 2. Przegląd dostępnych środowisk do projektowania wirtualnych rzeczywistości 2.1. Projektowanie wirtualne Dzisiejsze środowisko ekonomiczne zarówno w Polsce jak i pozostałej części świata stawia stale wzrastające wymagania w stosunku do kolejnych inwestycji wszystkich sektorów gospodarczych. Projekty realizowane są z zachowaniem coraz krótszych terminów wykonania, maksymalnego poziomu elastyczności oraz szybkości dostosowywania się do zmieniających się realiów i wymagań. W przypadku zdecydowanej większości z nich komunikacja pomiędzy wykonawcą a zleceniodawcą w głównej mierze odbywa się za pośrednictwem sieci. Dotyczy to przede wszystkim sektora informatycznego, ale pozostałe również nie pozostają w tyle. Zarządzanie projektami większości dziedzin gospodarki staje dzisiaj przed dodatkowymi wymaganiami, ale co warte podkreślenia, również i dodatkowymi możliwościami 1. Projekty wirtualne stwarzają realną szansę sprostania tym wszystkim wymaganiom. Tworzenie nowego oprogramowania, gry komputerowej, projektowanie nowego budynku architektonicznego bądź ogrodu wymaga od wykonawcy korzystania z wirtualnego projektowania. Wraz z rozwojem tej dziedziny informatyki architekci zyskali możliwość zweryfikowania z klientem pierwszych szkiców bez konieczności ciągłego przerysowywania nowych koncepcji. Co więcej zleceniodawca ma możliwość dostrzeżenia większej ilości szczegółów w stosunku do tradycyjnego rysunku technicznego. Wirtualny obraz otaczającej nas rzeczywistości można dziś dostrzec również w sferze rozrywki. Zrodziła się możliwość odbywania wirtualnych spacerów w miejscach, do których dotarcie byłoby po prostu niemożliwe, a interaktywne prezentacje zjawisk naturalnych mogą być doskonałą formą przekazania wiedzy. Dodatkowo symulacja zjawisk niebezpiecznych dla życia człowieka umożliwia wcześniejsze zaplanowanie niezbędnych przeciwdziałań i zweryfikowanie ich skuteczności w wirtualnej rzeczywistości. 2.2. Definicja silnika gry Sprawne przygotowanie wirtualnej rzeczywistości nie byłoby możliwe bez specjalistycznego silnika. W tym momencie należy zaznaczyć wyraźną różnicę pomiędzy silnikami graficznym oraz silnikami gier. Silnik graficzny jest to część kodu odpowiadająca za przetwarzanie grafiki trójwymiarowej, a więc przygotowanie 1 Źródło: http://www.computerworld.pl/artykuly/295026_1/projekt.wirtualny.html 7

Przegląd dostępnych środowisk do projektowania wirtualnych rzeczywistości i renderowanie sceny [5]. Zawiera elementy zaawansowanej matematyki, wymagające złożonych obliczeń i przekształceń poszczególnych elementów modelowanej rzeczywistości. Silnik graficzny działa w czasie rzeczywistym, a zatem kolejne klatki obrazu muszą być generowane z prędkością pozwalającą na swobodny ruch symulowanej rzeczywistości [5]. W odróżnieniu od silnika graficznego silnik gry odpowiedzialny jest za interakcję elementów gry. W wielu przypadkach silniki gier zapewniają szeroki zestaw narzędzi programistycznych wraz z komponentami umożliwiającymi ich wielokrotne użycie. Większość dostępnych na rynku silników dostarczanych jest wraz ze zintegrowanymi środowiskami umożliwiającymi szybkie tworzenie pełnych produktów, bez ingerencji w kod, a co za tym idzie znajomości języków programowania. Czasami nazywane są one oprogramowaniem pośredniczącym (ang. middleware) [7]. Silniki gier zazwyczaj bazują na silnikach graficznych, których realizacja opiera się na interfejsie programowania aplikacji graficznych (ang. API), takich jak OpenGL bądź DirectX. Jak większość oprogramowania pośredniczącego silniki gier zapewniają niezależność od karty graficznej oraz wideo tak bardzo pożądaną w czasach istnienia ogromnej różnorodności sprzętu komputerowego. Początkowo budowane były na podstawie języków programowania niskiego poziomu m.in. C (np. Sge2d). Obecnie coraz więcej silników gier implementowanych jest w językach wysokiego poziomu, takich jak Java, C++ (np. CryEngine 3) czy Python (np. Panda3D). Wydajność najnowocześniejszych gier 3D jest dzisiaj ograniczana przez moc kart graficznych, a zatem potencjalne zagrożenie spowolnienia wynikające z tłumaczenia języków wysokiego poziomu ma pomijalne znaczenie. Natomiast wzrost wydajności realizowania projektów z ich wykorzystaniem stwarza ogromne korzyści dla producentów. Wbrew powszechnej opinii silniki gier nie służą jedynie do tworzenia gier. Stanowią doskonałą podstawę do tworzenia oprogramowania wykorzystywanego w procesie realizacji projektów, o których jest mowa w podrozdziale 2.1 niniejszej pracy [7]. 2.3. Silnik CryEngine 3 2.3.1. Ogólny zarys W niniejszej pracy do realizacji wizualizacji zjawisk naturalnych wykorzystano silnik CryEngine 3. Wersja oznaczona numerem 3 niemieckiego producenta gier komputerowych Crytek wydana została w sierpniu 2011 roku i została zaimplementowana z wykorzystaniem języka C++. 8

Przegląd dostępnych środowisk do projektowania wirtualnych rzeczywistości Całość pakietu dostarczanego wraz z silnikiem CryEngine 3 zawiera również zestaw narzędzi deweloperskich CryEngine 3 SDK do tworzenia własnych modyfikacji, map oraz kompletu logiki gry. Ogół tworzonego świata może być budowany na zasadzie przeciągnij i upuść. Ze względu na ogromne podobieństwo jego wyglądu do jednego z najpopularniejszych programów do generowania grafiki trójwymiarowej 3ds Max silnik CryEngine 3 zyskał ogromną popularność zarówno wśród wielkich producentów gier jak i zwykłych pasjonatów tworzenia wirtualnej rzeczywistości. Tablica 1.1 przedstawia liczbę projektów programistycznych posiadających wykupioną licencję na wykorzystanie CryEngine w zależności od jego kolejnych wersji. Stały wzrost zainteresowania deweloperów omawianym silnikiem stanowi doskonałe potwierdzenie realizacji założeń firmy Crytek o chęci tworzenia uniwersalnej technologii umożliwiającej opracowywanie szerokiego zakresu produkcji komputerowych. Tablica 1.1 Liczba sprzedanych licencji silnika CryEngine (stan z dnia 11.10.2013) 2.3.2. Licencjonowanie Wersja silnika Liczba sprzedanych licencji CryEngine 1 6 CryEngine 2 7 CryEngine 3 32 Produkt firmy Crytek dostępny jest w kilku rodzajach licencji. Darmowa wersja pozwala na jej niekomercyjne użytkownie bez żadnych dodatkowych ograniczeń. Możliwe jest oczywiście wykupienie licencji, jednak cena takiej operacji nie jest publicznie znana. Co ciekawe konieczność dokonania takiego zakupu pojawia się dopiero w momencie odnoszenia korzyści finansowych dzięki silnikowi CryEngine [8]. Niezależność licencyjną posiada CryENGINE Cinebox. Produkt ten jest platformą do tworzenia szerokiej gamy wizualizacji, którego podstawę stanowi silnik CryEngine. Przeznaczony jest głównie dla dużych producentów, ze względu na koszt wspomnianej licencji. Stwarza możliwości nagrywania sekwencji filmowych w wysokiej rozdzielczości. Być może dzięki zaawansowanemu poziomowi zaimplementowanej fizyki i jakości renderowanego obrazu w niedalekiej przyszłości powstaną przy jego pomocy seriale lub pełnometrażowe filmy [8]. 2.3.3. Wersja 3.4.5 Projekt wizualizacji zjawisk naturalnych realizowany w niniejszej pracy wykonany został dzięki silnikowi CryEngine wersji 3.4.5 na podstawie darmowej licencji. Podobnie jak w poprzednich wydaniach tak i teraz zapewniona jest kompatybilność z wieloma 9

Przegląd dostępnych środowisk do projektowania wirtualnych rzeczywistości programami do grafiki komputerowej. Dzięki łatwemu w instalacji dodatkowi CryTIF dostępne jest tworzenie własnych tekstur oraz modyfikacja już istniejących w programie Photoshop (wersji 6. lub wyższej). Poza wyglądem i numerem wersji kolejną rzeczą łączącą CryEngine 3 SDK z 3ds Max em jest zestaw dodatków CryExport[nrWersji].dlu pozwalających grafikom na importowanie do edytora wymodelowanych obiektów bądź animacji. Rysunek 2.1 przedstawia pełny diagram przepływu tworzenia zasobów różnych części oprogramowania [2, 13]. Rys. 2.1 Diagram przepływu tworzenia zasobów [2 s.125] Dla wygody użytkownika CryEngine wspiera pisanie skryptów w języku LUA. Daje to możliwość implementacji ważnych funkcjonalności tworzonej rzeczywistości bez konieczności rekompilacji kodu źródłowego całego silnika. Oznacza to, że rezultaty wszystkich wprowadzonych zmian widoczne są od razu w oknie edytora. Przyjazny interfejs modelowania obiektów dostępny jest bezpośrednio w edytorze SDK. Natomiast dalsza chęć zamodelowania złożonych logicznie wirtualnych rzeczywistości, dostępna jest dzięki otwartości produktu CryEngine na modyfikację. Łatwość integracji kodu 10

Przegląd dostępnych środowisk do projektowania wirtualnych rzeczywistości źródłowego ze środowiskiem MS Visual Studio zachęca kolejnych programistów do stawienia czoła próbie rozbudowy oraz personalizacji jego szerokich możliwości [10]. Wersja 3.4.5 w stosunku do poprzednich przynosi szereg poprawek wykrytych błędów oraz dokłada nowe funkcjonalności jak i narzędzia developerskie. Szczególnie warte uwagi jest odświeżenie teselacji DirectX11 oraz jego kompatybilność z urządzeniami mobilnymi i konsolami (Xbox, PlayStation 3, PlayStation 4 i Wii U). Charakteryzuje się ona dodatkowymi efektami wody i większym poziomem szczegółowości w stosunku do poprzednich wersji. Od początku rozwój silnika CryEngine nastawiony był na wizualizację otwartych przestrzeni, dzięki czemu obecny stopień ich odwzorowania względem rzeczywistości jest imponująco wysoki 2. 2.4. Alternatywne rozwiązania Dzisiejszy rynek programistyczny silników gier liczy sobie tysiące alternatywnych rozwiązań począwszy od tych najbardziej znanych jak Queke bądź Unreal, a kończąc na jeszcze niedocenianych produkcjach zdecydowanie mniejszych korporacji. Jednym z podstawowych kryteriów podziału tak licznej grupy oprogramowania jest ich publiczna dostępność. Znakomita większość silników umożliwia wypróbowanie przeważającej części ich możliwości dzięki źródłom umieszczanym w sieci na zasadzie darmowych licencji (ang. open source). W opozycji do takiej postawy stoją deweloperzy, których autorskie silniki gier objęte są ścisłą klauzulą poufności. Przykładem są znane większości graczy komputerowych wszystkie części serii FIFA oraz bestsellerowe gry akcji God of War III i Metal Gear Solid 4. Unreal Engine jest silnikiem, którego korzenie sięgają roku 1998, a jego najnowsza wersja zaprezentowana została przez firmę Epic Games w roku 2006. Mimo tak długiego jak na realia szybko rozwijającego się rynku oprogramowania okresu czasu Unreal nadal pozostaje jednym z najchętniej wybieranych silników gier. Charakteryzuje się on wieloplatformowością dzięki temu, że jego jądro zostało zaimplementowane w języku C++. Zasadnicza część kodu opiera się na języku UnrealScript, lecz dzięki licznym narzędziom modyfikacja go oraz budowa na jego podstawie zindywidualizowanych produkcji nie stwarza większych problemów. Zachęca on kolejnych deweloperów relatywnie niską ceną wywoławczą i mocno rozwiniętym wideo krajobrazem [9]. Wyróżniającą się pozycją jest Unity 4 posiadający ponad 1.5 miliona zarejestrowanych użytkowników. Unity 4 to zintegrowany system tworzenia gier 2 Źródło: http://www.crydev.net/viewtopic.php?f=355&t=105888 11

Przegląd dostępnych środowisk do projektowania wirtualnych rzeczywistości komputerowych opierający się na potężnym silniku, posiadający szeroką gamę narzędzi deweloperskich do tworzenia trójwymiarowej rzeczywistości. Poza grami producenci zapewniają możliwość tworzenia wysokiej jakości wizualizacji oraz wirtualnych animacji. Samo środowisko przystosowane jest do działania na trzech największych platformach: Microsoft Windows, Os X oraz co warte szczególnej uwagi Linux. Jednak uruchamianie jego produktów końcowych możliwe jest na pozostałych platformach: Mac OS, Wii, PlayStation 3, Xbox 360, Windows Phone 8 i Android. Unity dzięki wtyczce Unity Web Player zapewnia możliwość działania gier w przeglądarce internetowej. Stanowi to bardzo atrakcyjną alternatywę dla wdrażania interaktywnych treści internetowych i stanowi potwierdzenie innowacyjności jej producenta Unity Technologies 3. Akcja większości gier komputerowych wyprodukowanych w przeciągu ostatniej dekady rozgrywana jest w zamkniętych przestrzeniach i z tego względu producenci silników gier skupiali na nich większość swojej uwagi. Crytek starając się myśleć przyszłościowo i być o jeden krok przed konkurencją stale analizował rynek i od samego początku produkcji CryEngine a rozwijał elementy świata zewnętrznego. Stąd CryEngine obrazuje swoje największe możliwości w przypadku otwartych powierzchni. Szeroki zestaw elementów przyrody, imponujących efektów renderowanych w czasie rzeczywistym, a co za tym idzie wspieranie wizualizacji zjawisk naturalnych był przeważającym kryterium wyboru silnika CryEngine do realizacji projektu w ramach niniejszej pracy dyplomowej. Intuicyjny edytor, łatwość modyfikacji kodu źródłowego oraz darmowa licencja oferowana przez firmę Crytek czyni jej produkt wyśmienitym narzędziem wizualizacji skomplikowanej działalności przyrody. 2.5. Spojrzenie w przyszłość Wraz z pojawieniem się ósmej generacji konsol wideo przed silnikami gier powstały nowe wyzwania i konieczność sprostania jeszcze większym wymaganiom rynku. Ten etap rozwoju gier komputerowych przyniósł konieczność implementacji wielu innowacyjnych rozwiązań (m.in. rozszerzonej rzeczywistości) nad którymi obecnie pracują najwięksi producenci. Dodatkowo razem ze stale wzrastającą liczbą elementów nowoczesnego silnika gier konieczne jest podnoszenie prędkości jego działania. Coraz większym zainteresowaniem cieszą się systemy z rodziny Linux. Co oczywiste wraz z nadchodzącymi zmianami ewoluować musi także rynek gier komputerowych. Producenci rozrywek komputerowych starając się dotrzeć do jak 3 Źródło: http://unity3d.com/ 12

Przegląd dostępnych środowisk do projektowania wirtualnych rzeczywistości największego grona odbiorców poszukują rozwiązań wspierających możliwie maksymalną liczbę platform. Firma Leadwerks Software jako jedna z pierwszych rozpoczęła realizację projektu, którego celem jest kolejna wersja silnika gier Leadwerks Engine, którego realizacja opiera się na znanej multiplatformowej bibliotece do trójwymiarowej grafiki komputerowej OpenGL. Co ciekawe w założeniach projektu nowe narzędzie nie będzie jedynie pozwalało na produkcję gier dla omawianego systemu, ale umożliwiało także tworzenie nowych bezpośrednio na nim 4. Najbliższe lata mogą więc być przełomowe dla rozwoju silników gier, a co za tym idzie możliwości tworzenia wirtualnych rzeczywistości wraz z wizualizacją zjawisk naturalnych. Z tego względu warto bliżej przyjrzeć się procesowi ich tworzenia od samego początku aż do finalnego efektu. 4 http://www.benchmark.pl/aktualnosci/cryengine-leadwerks-silniki-gier-dla-systemulinux.html Żródło: 13

Wizualizacja burzy 3. Wizualizacja burzy Niniejszy rozdział zawiera sprecyzowanie celu pracy. Poza przedstawieniem charakterystyki problemu kolejne podrozdziały zawierają wymagania funkcjonalne i niefunkcjonalne stawiane realizowanemu projektowi. 3.1. Charakterystyka problemu Symulacja zjawisk obserwowanych w przyrodzie to bardzo złożony problem znajdujący się na pograniczu matematyki, informatyki oraz nauk przyrodniczych. Niejednokrotnie samo zdefiniowanie matematycznego modelu opisującego zachowanie wybranego efektu wymaga długotrwałych badań połączonych z próbą formułowania tez i ich udowadniania. Ograniczenia wynikające ze stosowanych języków programowania mogą wymusić na programiście zastosowanie przybliżeń, które często w znaczący sposób wpływają na końcowy rezultat prac. Dodatkowa, jak dotąd nieodgadniona, losowość charakterystyki oddziaływania świata stanowi kolejną przeszkodzę w idealnym odzwierciedleniu zjawisk naturalnych w ramach wirtualnej rzeczywistości. Niezwykle często obserwowanym działaniem przyrody jest burza. Jej definicja mówi o zjawisku zaburzenia równowagi atmosferycznej, przejawiającym się opadami deszczu wraz z silnym wiatrem. Często połączone są one z wyładowaniami atmosferycznymi obserwowanymi jako pioruny, którym towarzyszy grom dźwiękowy, a także zjawisko świetlne błyskawica. Burza to bardzo złożone zjawisko pogodowe, którego postać jak i intensywność działania uzależniona jest od miejsca, czasu trwania i wielu innych czynników, które mają zdolność dynamicznej zmiany w czasie. Matematyczny model opisujący całość omawianego elementu działania natury musi uwzględniać liczne zjawiska naturalne, o których mowa powyżej. Konieczność uwzględnienia ich wzajemnych interakcji uniemożliwia opracowanie jego idealnej postaci opisującej wszystkie czynniki wchodzące w skład burzy. Stąd grafika komputerowa stosuje liczne uproszczenia, pomimo których można uzyskać efekty bardzo przypominające prawdziwe zjawisko. 14

Wizualizacja burzy Rys. 3.1 Składowe elementy burzy Rysunki 3.1 przedstawiają składowe elementy stanowiące całość zjawiska burzy: wiatr oddziałowujący na obiekty znajdujące się w obrębie burzy (Rys. 3.1.A), kałuże tworzące się wskutek opadów deszczu (Rys. 3.1.B), krople deszczu stanowiące deszcz, wraz z ich odbiciem od obiektów stałych (Rys. 3.1.C), wyładowania atmosferyczne (Rys. 3.1.D). Celem pracy jest przedstawienie możliwości rozbudowy silnika CryEngine na przykładzie symulacji zachowania burzy. Naturalnym wymaganiem stawianym przed finalnym efektem symulacji jest uwzględnienie podstawowych elementów składających się na całość analizowanego zjawiska. Szczegółowe założenia zostały wymienione w następnym podrozdziale. Wyładowania atmosferyczne, a dokładniej rzecz ujmując wyładowania elektryczne w atmosferze powstają: w chmurach, pomiędzy chmurami oraz między chmurą a powierzchnią ziemi. W pracy przyjęto, że miejsce ich wystąpienia będzie niezależne od położenia chmur, gdyż ich symulacja a dalej interakcja z piorunami stanowi wysoce złożony problem, który mógłby stanowić temat odrębnej pracy dyplomowej. 15

Wizualizacja burzy Dla uniwersalności rozwiązania oraz jego pełnej kompatybilności z silnikiem CryEngine powinno być ono niezależne od architektury komputera testowego. Całość obliczeń będzie prowadzona poza procesorem karty graficznej (GPU). Wymusza to zastosowanie licznych uproszczeń modelu dla przyśpieszenia obliczeń, które nie powinny jednak wpłynąć na realizm wyglądu końcowej symulacji. Uwzględniając wygodę docelowych użytkowników obiekt burzy powinien być dostępny w ramach edytora CryEngine Sandbox SDK. Dodatkowym wymaganiem jest możliwość parametryzacji wszystkich wymienionych elementów. Dzięki temu wizualizacja burzy może być dostosowana do indywidualnych potrzeb użytkownika. Stanowi to jednoczesne utrudnienie uwzględnienia dowolności pory dnia lub nocy w jakiej może nastąpić symulacja zjawiska burzy. Podsumowując, celem niniejszej pracy jest przedstawienie możliwości symulacji zjawisk naturalnych przy wykorzystaniu silnika graficznego CryEngine. Przykładową realizację stanowić będzie burza, której symulacja powinna być prowadzona w czasie rzeczywistym. 3.2. Założenia Poniższa lista stanowi spis założeń dotyczących nowego obiektu burzy, stanowiącego rozbudowę funkcjonalności silnika CryEngine: możliwość animowania deszczu, możliwość zmiany rozmiaru oraz prędkości spadania kropli deszczu, tworzenie kałuż na płaskich powierzchniach ziemi, długość promienia burzy powinna być skalowalna, animacja rozbicia kropli deszczu w konfigurowalnej odległości maksymalnej od gracza, rozwiązanie musi zawierać symulację wiatru, którego działanie zanika poza obszarem objętym zjawiskiem, realizacja wiatru musi uwzględnić losowość tego zjawiska objawiającą się podmuchami, burza musi zawierać błyski oraz towarzyszące im pioruny, burza musi być podzielona na strefy definiujące prawdopodobieństwo wystąpienia w nich piorunów, w miejscu uderzenia pioruna powinien pozostać znak wypalenia na powierzchni ziemi (o ile uderzenie nastąpiło wystarczająco blisko terenu), 16

Wizualizacja burzy wypalenie powinno następować wraz z pojawieniem się pobliskiej smugi dymu, pojawieniu się pioruna musi towarzyszyć eksplozja, kolizja pioruna z obiektem powinna skutkować zapaleniem tegoż obiektu, styczność pioruna z metalowym obiektem powinna być obarczona dodatkowym efektem poświaty, zarówno wielkość jak i kształt pioruna powinny być losowe, symulowanym wyładowaniom atmosferycznym towarzyszy dźwięk słyszalny z bliskich odległości, algorytm nie uwzględnia skłonności uderzania piorunów w metalowe elementy, program powinien umożliwiać zmianę wartości parametrów wpływających na zachowanie poszczególnych elementów burzy, użytkownik powinien mieć dostęp do obiektu burzy z poziomu Panelu Poleceń edytora CryEngine 3 Sandbox SDK. 3.3. Wymagania Dla poprawnego działania programu, konieczne jest spełnienie wymagań definiowanych przez producentów środowiska CryEngine 3 Sandbox SDK. Element obiektu burzy rozbudowujący silnik CryEngine wersji 3.4.5 tak samo jak całość silnika napisany został w językach C++ oraz skryptowym LUA, w środowisku Visual Studio 2010. Ze względu na rozmiar całości kodu silnika na płycie CD, dołączonej do niniejszej pracy, umieszczone zostały jedynie wszystkie nowo stworzone oraz zmodyfikowane pliki silnika. Chęć zbudowania całości wraz z nowymi elementami, wymaga otworzenia projektu CryEngine_GameCodeOnly.sln w środowisku Visual Studio, dołączenia nowych plików oraz podmiany zmodyfikowanych i zbudowaniu całego projektu. Uruchomienie gotowych scen wymaga wcześniejszego wyeksportowania ich do tzn. plików poziomu. Operacja ta dostępna jest poprzez wybór opcji Export to engine z menu File. Tak przygotowane pliki będą dostępne jako plansze rozgrywki, widoczne po uruchomieniu środowiska gry Launcher.exe. 17

Projekt rozwiązania i opis wybranych elementów implementacji 4. Projekt rozwiązania i opis wybranych elementów implementacji Rozdział ten przedstawia ogólny zarys implementacji zjawiska burzy w ramach silnika CryEngine. Na przykładzie omawianego projektu omówione zostaną możliwości rozbudowy silnika o kolejne obiekty symulujące działanie zjawisk naturalnych. Stopniowe budowanie finalnego obiektu rozpoczyna się od Rozdziału 4.1, który pokazuje, jak szybko można tworzyć interfejs graficzny dostępny dla użytkownika końcowego zestawu narzędzi SDK (ang. source development kit). Rozdział 4.2 omawia działanie symulacji zachowania burzy ilustrując schematycznie jego główne elementy, których opisy znajdują się w kolejnych częściach tego fragmentu pracy. W rozdziale 4.6 przedstawione zostały problemy napotkane przez autora podczas pracy z silnikiem CryEngine. 4.1. Projekt interfejsu Rysunek 4.1.1 przedstawia projekt interfejsu graficznego odpowiadającego za interakcję między zachowaniem symulacji burzy a użytkownikiem. Analiza wymagań stawianych projektowanemu obiektowi umożliwiła wyróżnienie podstawowych parametrów charakteryzujących jego zachowanie. Rys. 4.1.1 Interfejs użytkownika definiujący parametry burzy 18

Projekt rozwiązania i opis wybranych elementów implementacji Całość interfejsu zaimplementowana została wewnątrz skryptu Storm.lua. Silnik CryEngine analizujący poszczególne skrypty automatycznie buduje menu dostępne dla użytkownika w panelu Roll Bar. Podstawę tej analizy stanowi zawartość tablicy Properties, wymaganej dla każdego skryptu opisującego dany obiekt [2 s.93]. Dzięki wprowadzonej przez producentów silnika konwencji przyrostków interpretacja graficzna parametru zależna jest od jego typu i umożliwia wygodną zmianę jego wartości [12]. Właściwości burzy podzielone zostały na 5 podstawowych części: podstawowe, błyski, rozbicie kropli deszczu, pioruny oraz wiatr. Każda z nich charakteryzuje zachowanie symulacji burzy w ramach danego elementu burzy. Tak jak w rzeczywistym środowisku tak i tutaj cześć z nich jest od siebie zależna a końcowy efekt jest wypadkową wartości wszystkich parametrów i ich współpracy. 4.2. Zarys architektury rozwiązania Jak wspomniano w rozdziale 3.1 problem opisu modelu burzy charakteryzuje się wysoką złożonością, a liczba parametrów opisujących całość zjawiska jest bardzo duża. Jednak, aby końcowa wizualizacja wyglądała realistycznie, zagadnienie to zostało zawężone do wymagań opisanych w rozdziale 3.2. Do reprezentacji obiektu burzy wykorzystano klasę CStorm, której abstrakcyjną klasę bazową stanowi CGameObjectExtensionHelper, rozszerzoną o następujące metody i zmienne: class CStorm : public CGameObjectExtensionHelper<CStorm, IGameObjectExtension> { public: enum StormTimer { ethunder_timer_lifetime = 0x1110, ethunder_timer_soundtime = 0x1111, eraindropanim_timer_lifetime = 0x1112 }; protected: /* */ zbiór zmiennych odpowiadającym parametrom zdefiniowanym w skrypcie Storm.lua Vec3* currwinddirection; } std::vector<string> lightnings; 19

GameFactory Rejestracja Projekt rozwiązania i opis wybranych elementów implementacji Wspomniana klasa CGameObjectExtensionHelper musi stanowić klasę bazową dla wszystkich nowo tworzonych obiektów. Zapewnia ona kompatybilność nowego elementu z pozostałą częścią silnika. Ponadto konieczne jest zarejestrowanie jej w globalnej przestrzeni nazw, tak aby była ona dostępna dla użytkowników edytora. Procedura ta odbywa się w ramach metody InitGameFactory klasy GameFactory. Macro REGISTER_GAME_OBJECT wymaga podania nazwy klasy bez obowiązkowego przyrostka C. Przykład takiej operacji został przedstawiony poniżej: REGISTER_GAME_OBJECT(pFramework, Storm, "Scripts/Entities/Environment/Storm.lua"); Rysunek 4.2.1 schematycznie przedstawia umiejscowienie klas nowo definiowanych elementów w kontekście całego silnika: CryEngine CGameObjectExtensionHelper NowaKlasa1 NowaKlasa2 Rys. 4.2.1 Nowe klasy w ramach silnika CryEngine 20

Projekt rozwiązania i opis wybranych elementów implementacji Pośród licznego zbioru metod czysto wirtualnych, które musi implementować klasa CStorm należy wyróżnić metodę Update. Odpowiada ona za aktualizację obiektu i jest uruchamiana przez silnik CryEngine wraz z każdym odświeżaniem wirtualnego środowiska. Metoda ta stanowi więc miejsce w którym umieszczony został główny algorytm wizualizacji zjawiska burzy. deszcz błyski burza wiatr pioruny Rys. 4.2.2 Schemat symulacji burzy Rysunek 4.2.2 stanowi poglądowy schemat budowy modelu burzy aktualizowany w każdym wywołaniu głównego algorytm, którego kroki wymieniono poniżej w postaci pseudo-kodu: Pętla wykonywania programu Aktualizacja wartości parametrów podanych przez użytkownika Aktualizacja deszczu Symulacja rozbicia kropli deszczu Symulacja wiatru Błyski wraz z piorunami Na początku należy zaktualizować wartości zmiennych prywatnych odpowiadających parametrom podanym przez użytkownika. Bezpośrednia interakcja z eksploatatorem niesie za sobą niebezpieczeństwo niepoprawności podanych danych. Dlatego też muszą być one zweryfikowane przed rozpoczęciem aktualizacji modelu. W omawianym rozwiązaniu zostało to wykonane wewnątrz metody Reset() znajdującej się z skrypcie Storm.lua. Jest to pierwszy krok algorytmu i jego ewentualne niepowodzenie powinno blokować dalsze działania, których efekty byłby niemożliwe do przewidzenia. 21

Projekt rozwiązania i opis wybranych elementów implementacji Dalsze kroki dotyczą poszczególnych elementów burzy umieszczonych na schemacie Rys. 4.2.2. Zdecydowana większość z nich zrealizowana została poprzez wywołania odpowiednich funkcji wewnątrz wspomnianej metody Update. Natomiast pozostałe stanowią połączenie możliwości jakie oferują mechanizmy programowania funkcjonalności silnika CryEngine zarówno w języku skryptowym LUA jak i wysokopoziomowym języku C++. Kolejne podrozdziały przedstawiają implementacje poszczególnych części całości rozwiązania wraz z opisem wybranych mechanizmów oferowanych przez silnik CryEngine wersji 3.4.5. 4.3. Modelowanie deszczu Większość definicji burzy jakie można odnaleźć w literaturze wskazuje deszcz jako jej centralny element. Obiekt imitujący spadanie kropli deszczu stanowi element standardu silnika CryEngine. Realizacja tego punktu założeń projektu nie stanowiła więc dużego problemu. Jedyną czynnością jaką należało wykonać było umożliwienie zdefiniowania przez użytkownika wartości argumentów funkcji obsługi deszczu, których definicje wyglądają następująco: // podstawowe cechy deszczu virtual void SetRainParams( const Vec3 & vcenter, float fradius, float famount, const Vec3 & vcolor); //zaawansowane właściwości virtual void SetRainParams( float freflamount, float ffakeglossiness, float fpuddlesamount, bool braindrops, float fraindropsspeed, float fumbrellaradius); Na Rysunku 4.3.1 można zobaczyć, jak wygląda deszcz dla różnych wartości intensywności amount. Dla zwiększenia realizmu końcowego efektu wizualizacji deszczu wykonany został dodatkowy efekt imitujący rozbicie spadającej kropli deszczu, którego realizacja omówiona została w dalszych podrozdziałach. 22

Projekt rozwiązania i opis wybranych elementów implementacji Rys. 4.3.1 Wygląd deszczu w zależności od poziomu intensywności amount 4.3.1. Animacje Bardzo ciekawą i przydatną funkcjonalnością silnika CryEngine jest możliwość umieszczania animacji wewnątrz wizualizowanej rzeczywistości. Specjalny obiekt AnimObject, który można odnaleźć w kategorii Physics, wymagania podania pliku opisującego sekwencję przekształceń oraz drugiego zawierającego obiekty biorące udział w animacji. Dzięki dostarczanej przez producentów silnika wtyczce o której mowa w rozdziale 2.3.3 dla popularnego programu 3ds Max, możliwe jest eksportowanie animacji przygotowanych w tymże programie do formatu akceptowanego przez CryEngine. Istnieje jednak pewien problem znacząco ograniczający możliwości tworzenia złożonych animacji. Jedynymi przekształceniami wspieranymi przez wspomnianą wtyczkę są rotacje oraz zmiana położenia. Ograniczając się jedynie do tych dwóch przekształceń, w ramach projektu stworzona została animacja rozbicia kropli wody. Jej realizację w ogromnym stopniu ułatwiła procedura reactor umożliwiająca definiowanie właściwości fizycznych i sił zgodnie z obowiązującymi prawami fizyki [11 s.1116]. Należało jednak 23

Projekt rozwiązania i opis wybranych elementów implementacji pamiętać o takim doborze obiektów i przekształceń, aby całość animacji była zrozumiała dla silnika CryEngine. Rysunki 4.3.2 przedstawiają kluczowe klatki stworzonej animacji rozbicia kropli wody w dużym powiększeniu. Rys. 4.3.2 Efekt rozbicia kropli wody Mając gotowe pliki animacji konieczne jest dynamiczne umieszczanie jej w ramach symulacji burzy. Dla uniknięcia nadmiernego obciążenia procesora zbędnymi operacjami, które nie wpływają na realizm końcowej symulacji, efekt ten widoczny jest jedynie w ustalonej odległości od gracza. Założenie takie wydaje się być zdroworozsądkowym, gdyż analogicznie do sytuacji obserwowanej w świecie rzeczywistym, dostrzeżenie przebiegu rozbicia kropli możliwe jest jedynie z bardzo małych odległości. 24

Projekt rozwiązania i opis wybranych elementów implementacji Metoda SimulateRainDropSplashEffect odpowiedzialna za ten fragment symulacji burzy składa się z czterech podstawowych kroków: 1. sprawdzenie czy gracz znajduję się w obrębie działania burzy, 2. wybór losowego punktu odległego od gracza nie dalej niż zadana odległość, 3. dynamiczne umieszczenie animacji w wybranym punkcie, 4. usunięcie animacji po upłynięciu określonego przedziału czasowego. Warto przyjrzeć się bliżej dwóm ostatnim etapom tego algorytmu. Umieszczenie dowolnej animacji wewnątrz metody napisanej w języku C++ zmusza program do wypełnienia specjalnej struktury SEntitySpawnParams, która jednoznacznie definiuje nowy obiekt lokowany w planszy. Tak jak wspomniano wcześniej obiektem dedykowanym animacjom jest AnimObject, którego wartości parametrów dostępne z poziomu interfejsu graficznego, wypełniane są za pośrednictwem struktury SmartScriptTable. Aby symulacja wyglądała naturalnie konieczne jest zdefiniowanie czasu życia animacji. Gdy czas życia minie konieczne jest usunięcie obiektu z planszy. Z racji powtarzania się tego zagadnienia w wielu miejscach implementowanego projektu jego sposobom rozwiązania poświęcony został następny podrozdział. 4.3.2. Mechanizm regulatora czasowego Bardzo często spotykanym zdarzeniem obserwowanym w wirtualnych środowiskach jest znikanie przedmiotów. Przykładem takiej sytuacji może być śmierć jednego z bohaterów gry komputerowej, którego ponowne odrodzenie wymaga usunięcia z planszy pozostawionego ciała. Wracając do omawianego rozwiązania symulacji burzy, konieczność eliminacji uprzednio stworzonych obiektów (symulujących animacje rozbicia kropli wody, pioruny itp.) wymagała opracowania uniwersalnego rozwiązania dla wszystkich tego typu sytuacji. Na to zagadnienie można spojrzeć z dwóch istotnie różniących się perspektyw. Jedna z nich zakłada przekazanie odpowiedzialności za usunięcie danego obiektu na niego samego. Musiałby on zostać poinformowany kiedy musi zniknąć, bądź otrzymać w odpowiednim momencie wiadomość o natychmiastowej konieczności zaistnienia takiego zdarzenia. Innym z możliwych podejść jest delegowanie obserwatora, który przejmie omówioną odpowiedzialność nadzorując obiekty mu podległe. Ze względu na dostarczany przez silnik CryEngine mechanizm regulatora czasowego autor niniejszego projektu zdecydował się na pierwszy z omówionych 25

Projekt rozwiązania i opis wybranych elementów implementacji sposobów rozwiązania. W dalszej części niniejszego podrozdziału zostanie krótko omówiony ten mechanizm, który wraz z detektorem zdarzeń stanowi bardzo dobre miejsce obsługi analizowanych zdarzeń usunięcia obiektów z planszy. Integralną częścią każdej gry jest obsługa zaistniałych w niej zdarzeń. Dzięki detektorom można uniknąć żmudnego zadania utrzymania stanu obiektu, aktualizowanego w każdym obiegu pętli uruchamiającym funkcję Update. W rzeczywistości takie podejście wprowadzałoby bardzo dużo konsekwencji i prowadziło do tworzenia monstrualnych wielkości diagramów stanów poszczególnych obiektów. Autorzy silnika CryEngine zobligowali programistów tworzących nowe obiekty do obsługi zdarzeń poprzez stworzenie wirtualnej metody ProcessEvent, której implementacja w każdej klasie pochodnej zostanie wymuszona przez kompilator C++. Argumentem tej metody jest struktura SEntityEvent zawierająca wszelkie potrzebne informacje do zidentyfikowania przychodzących zdarzeń. Poniższy fragment kodu prezentuje przykładową implementację metody ProcessEvent: void CThunder::ProcessEvent( SEntityEvent& event ) { } switch(event.event) { case ENTITY_EVENT_RESET: { Reset(); } break; case ENTITY_EVENT_TIMER: { switch(event.nparam[0]) { case CStorm::eTHUNDER_TIMER_LIFETIME: { // wykonaj odpowiednie akcje... } break; } } break; } Jak widać jednym z możliwych rodzajów zdarzeń jest ENTITY_EVENT_TIMER, wchodzący w skład mechanizmu regulatora czasowego. Zdarzenie to generowane jest po upłynięciu czasu, którego długość podana została jako jeden z parametrów funkcji SetTimer dostępnej dla każdego obiektu typu IEntity. Analogiczna metoda istnieje również na poziomie języka skryptowego LUA, tak że zdarzenia mogą być obsługiwane także tutaj. Podsumowując możliwe jest ustawienie regulatora czasowego (ang. timer) dla obiektu i obsługę tego zdarzenia w przytoczonej funkcji. Jest to najwygodniejsze 26

Projekt rozwiązania i opis wybranych elementów implementacji rozwiązanie dla klas, które tworzone są przez programistę od samego początku. Niestety podejście to wymagałoby ingerencji w implementację klasy AnimObject zdefiniowanej już w silniku CryEngine i wymuszenie obsługi dodatkowego zdarzenia, czego konsekwencją byłoby zniszczenie tego obiektu. Tak nieeleganckie podejście wymaga znalezienia dla tego typu przypadków innego rozwiązania. Z pomocą przychodzi możliwość definiowana własnych słuchaczy zdarzeń. W przypadku sytuacji związanych z obiektami należy zwrócić uwagę na klasę abstrakcyjną IEntityEventListener, której klasy pochodne zdolne są do nasłuchiwania przychodzących zdarzeń. Poniższy fragment kodu przedstawia szkielet klasy zaimplementowanej na potrzeby niniejszej pracy: class IEntityTimer : public IEntityEventListener { public: enum IEntityTimerEnum { eentity_timer_lifetime }; = 0x1113 IEntityTimer(IEntity *pent, int time) { genv->pentitysystem->addentityeventlistener( pent->getid(), ENTITY_EVENT_TIMER, this); pent->settimer(ientitytimerenum::eentity_timer_lifetime, time); } ~IEntityTimer(void) { genv->pentitysystem->removeentityeventlistener( pent->getid(), ENTITY_EVENT_TIMER, this); } private: void OnEntityEvent( IEntity *pentity, SEntityEvent &event ); }; IEntity * pent; Jak widać konstruktor obiektu rejestruje samego siebie jako nowego słuchacza zdarzeń dla obiektu pent i wymusza wystąpienie zdarzenia po upływie czasu, który również jest jednym z argumentów tego konstruktora. Definicja metody OnEntityEvent rejestrując moment zakończenia pracy regulatora czasowego usuwa obiekt pent z systemu obiektów, jednocześnie wywołując destruktor słuchacza. W ramach destruktora zapewnione jest usunięcie słuchacza z grona odbiorców zdarzeń. Kolejny przykład 27

Projekt rozwiązania i opis wybranych elementów implementacji prezentuje prostotę obsługi omówionej metody rozwiązania problemu dynamicznego usuwania obiektów z planszy: IEntity* explosionfire; //... new IEntityTimer(someObj,500); 4.4. Błyski wraz z piorunami Następnym elementem projektu symulacji burzy, jako ilustracji możliwości rozbudowy silnika CryEngine, są błyski towarzyszące temu zjawisku. Realizacja tego punktu wymagań projektu obrazuje możliwości programowania hybrydowego w ramach tegoż silnika. W pierwszej części tego rozdziału omówione zostały sposoby integracji pomiędzy językami LUA oraz C++. Praktyczne wykorzystanie nowo poznanej wiedzy prezentują dalsze podrozdziały na przykładzie implementacji wyładowań atmosferycznych, złożonych z błysków oraz towarzyszących im piorunów. 4.4.1. Integracja pomiędzy LUA oraz C++ Niezwykle istotne dla wykorzystania pełni potencjału silnika CryEngine jest poznanie możliwości współpracy fragmentów kodu napisanych w językach C++ oraz LUA. Praktyczne wykorzystanie programowania mieszanego może istotnie wpływać na wydajność wybranych, newralgicznych części działania algorytmu. Poza tym łączenie istniejących funkcjonalności przyśpiesza budowanie aplikacji bez konieczności powielania implementacji jednego algorytmu w wielu językach programowania. CryScriptSystem to abstrakcyjna, wirtualna maszyna LUA dostępna w ramach silnika CryEngine. Jej implementacja wspiera programowanie w języku LUA wersji 5 i zapewnia następujące funkcjonalności [4]: wywoływanie funkcji skryptowych, wystawianie zmiennych i funkcji zaimplementowanych w języku C++ na potrzeby skryptów LUA, tworzenie tablic skryptów zapisanych w pamięci maszyny wirtualnej. W celu udostępnienia zmiennych oraz funkcji zaimplementowanych w języku C++ konieczne jest stworzenie nowej klasy pochodnej, dziedziczącej po klasie bazowej CScriptableBase, która zapewnia większość funkcjonalności. Przykładowa deklaracja klasy może wyglądać następująco: 28

Projekt rozwiązania i opis wybranych elementów implementacji class CScriptExtension_Game : public CScriptableBase { public: CScriptExtension_Game( ISystem* psystem ); virtual ~CScriptExtension_Game() {} }; int SomeFunc(IFunctionHandler* fh, char* ptext); Wewnątrz konstruktora tej klasy musi być zawarty kod rejestrujący poszczególne metody w danej przestrzeni nazw. Dzięki akcjom zaprezentowanym wewnątrz poniższego kodu możliwe jest wywołanie nowej metody SomeFunc wewnątrz skryptu LUA z przestrzeni nazw Game (Przykładowo: Game.GameLog("message to transfer"); ). Init(pSystem->GetIScriptSystem(), psystem); SetGlobalName("Game"); #undef SCRIPT_REG_CLASSNAME #define SCRIPT_REG_CLASSNAME &CScriptBind_Game:: SCRIPT_REG_TEMPLFUNC(SomeFunc, "text"); Udostępnianie wartości stałych zdefiniowanych na poziomie języka C++ umożliwia metoda IScriptSystem::SetGlobalValue(), której przykład użycia zaprezentowano poniżej: genv->pscriptsystem->setglobalvalue("some_const", SOME_CONST); Komunikacja w stronę przeciwną prowadzona jest za pośrednictwem specjalnej struktury IScriptTable reprezentującej wszystkie tablice i zmienne wykorzystywane w danym skrypcie LUA. Dostęp do niej możliwy jest dzięki analogicznej metodzie IScriptSystem::GetGlobalValue(). Poza tym zdefiniowany został dla programistów zbiór specjalistycznych funkcji dedykowanych konkretnym zastosowaniom. Przykładem jest rozgłaszanie zdarzeń zarejestrowanych przez algorytm zaimplementowany w języku skryptowym dzięki funkcji BroadcastEvent. 4.4.2. Błyski Przykład realizacji błysków towarzyszących burzy doskonale obrazuje otwartość silnika na różnorodność języków programowania i szeroką gamę funkcjonalności dostępnej dla programistów LUA. Symulacja błysków spełniających założenia stawiane projektowanemu zjawisku przebiega według następującego algorytmu: 29

Projekt rozwiązania i opis wybranych elementów implementacji 1. Wylosuj strefę wystąpienia błysku z zadanymi prawdopodobieństwami. 2. Uaktualnij parametry nieba. 3. Określ opóźnienie pojawienia się pioruna towarzyszącego błyskowi oraz długość trwania błysku. 4. Ustaw regulator czasowy na wystąpienie pioruna i przywrócenia początkowych parametrów nieba. 5. Zasymuluj piorun. Kroki 1 4 zaimplementowane zostały wewnątrz pliku Storm.lua, który następnie przekazuje odpowiedzialność obsługi obiektów pioruna metodom klasy Storm języka C++. Zaletą takiego podziału jest dostępność specjalistycznych funkcji w konkretnych przestrzeniach nazw. Metoda implementująca powyższy algorytm uruchamiana jest wewnątrz funkcji Update z prawdopodobieństwem odpowiadającym zadanej przez użytkownika częstotliwości wystąpienia błysków. Drugi krok algorytmu wykorzystuje wbudowaną w silnik metodę System.SetSkyHighlight uaktualniającą podstawowe parametry wyglądu nieba. Jak widać mimo bardzo konkretnie sprecyzowanych oczekiwań istnieje odpowiednia funkcja dostępna dla programistów LUA. Pełny spis wyspecjalizowanych funkcji LUA silnika CryEngine dostępny jest na stronie producenta i stanowi obowiązkową lekturę dla osób implementujących kolejne fragmentu funkcjonalności w tymże języku. Dla potwierdzenia powyższej opinii kolejny przykład, wykorzystany wewnątrz omawianej symulacji burzy, prezentuje łatwość z jaką możliwe jest odtwarzanie towarzyszących jej dźwięków: function Thunder:initSounds() end self.sounds[0] = "Game/Sounds/SomeThunderSound.mp2"; self.sounds[1] = "Game/Sounds/AnotherThunderSound.mp2"; function Thunder:OnReset() end if( self.bsound == 1 ) then local thundersound = self.sounds[random(0,1)]; self:playsoundevent(thundersound, {x=0,y=0,z=0}, {x=0,y=0,z=0}, SOUND_3D, 0, SOUND_SEMANTIC_EXPLOSION); end 30

Projekt rozwiązania i opis wybranych elementów implementacji Płynne przejście wykonywania algorytmu z poziomu skryptów LUA do implementacji ostatniego kroku omawianego algorytmu, napisanej w języku C++, odbywa się za pośrednictwem mechanizmu rozgłaszania zdarzeń, przedstawionego w poprzednim podrozdziale. Metoda obsługi regulatora czasowego OnTimer rozgłasza trzy rodzaje polecenia symulacji pioruna w zależności od strefy jego wystąpienia. Z drugiej strony nasłuchująca funkcja obsługi zdarzeń omówiona wcześniej ProcessEvent wykrywając takie polecenie rozpoczyna procedurę symulacji piorunów. Wadą tego mechanizmu jest to, że identyfikatorem zdarzenia jest łańcuch znaków alfanumerycznych generujący potencjalne problemy wynikające z różnych sposobów kodowania znaków. 4.4.3. Pioruny Symulacja pioruna zaimplementowana w języku C++ rozpoczyna się od losowego wybrania miejsca uderzenia wewnątrz strefy, jednoznacznie określonej przez przechwycone zdarzenie rozgłaszane z poziomu języka LUA. Dalsze czynności polegają na umieszczeniu obiektu symulującego piorun w tym miejscu wraz z uzupełnieniem odpowiadającej mu tablicy stanu. Zadanie dynamicznego wstawiania obiektu do wirtualnego środowiska jest na tyle istotną i niezwykle często powtarzającą się czynnością, że zostanie ono szczegółowo zaprezentowane na przykładzie omawianych piorunów. Do reprezentacji pojedynczego pioruna wykorzystano klasę CThunder, której bazę stanowi wielokrotnie przytaczana CGameObjectExtensionHelper. Analogicznie do klasy CStorm posiada ona odpowiadający jej skrypt Thunder.lua stanowiący zbiór parametrów pioruna. Metoda SpawnEntity umożliwiająca dynamiczne umieszczanie obiektów w mapie wymaga podania uzupełnionej struktury typu SEntitySpawnParams. Polami na które należy zwrócić szczególną uwagę są: vposition miejsce umiejscowienia obiektu, pclass klasa wstawianego obiektu. W przypadku piorunów poszukiwaną klasą jest oczywiście wspomniana CThunder. Następnie uzupełniana jest kolejna struktura, która odpowiada tablicy parametrów tworzonego obiektu, a mianowicie SmartScriptTable. Poprawne stworzenie obiektu pioruna wymaga wskazania w niej modelu obrazującego piorun (zamodelowane przykłady przedstawia Rysunek 4.3.3), wraz z pozostałymi parametrami takimi jak np. wymuszenie destrukcji kolizyjnych obiektów. Dla zwiększenia odczucia realizmu symulowanych 31

Projekt rozwiązania i opis wybranych elementów implementacji piorunów są one losowo skalowane oraz rotowane wokół pionowej osi Z. Całość zaś pokrywana jest samoświecącym białą barwą materiałem thunder_light. Dodatkowe sprawdzenie typu materiału obiektu kolizyjnego pozwala na symulację czerwonej poświaty podczas uderzenia w metalowy przedmiot. Rys. 4.3.3 Modele piorunów Fragmentu kodu odpowiedzialny za dynamiczne umiejscawianie obiektu pioruna prezentuje się następująco: void CStorm::simulateThunder(int zonenumber) { SEntitySpawnParams params; params.vposition= RandPlace(); params.pclass = genv->pentitysystem-> GetClassRegistry()->FindClass("Thunder"); IEntity* propeentity = genv->pentitysystem->spawnentity(params, false); if (propeentity) { // ustaw paramtery obiektu SmartScriptTable tableentityproperties; propeentity->getscripttable()->getvalue( "Properties", tableentityproperties); params.ppropertiestable = tableentityproperties; if (tableentityproperties->havevalue("object_model")) tableentityproperties->setvalueany("object_model", "Game/Objects/thunderbolts/lightning2.cgf"); } if (tableentityproperties->havevalue("bdestroy")) tableentityproperties->setvalueany("bdestroy", 1); genv->pentitysystem->initentity(propeentity, params); } else { GameWarning("Blad tworzenia pioruna"); } 32

Projekt rozwiązania i opis wybranych elementów implementacji W momencie inicjalizacji obiektu dalsza obsługa jego zachowania kontrolowana jest przez odpowiadający mu skrypt LUA. Zatem możliwe są płynne przejścia pomiędzy LUA oraz C++ w obu kierunkach. 4.5. Wiatr jako poprawa funkcjonalności silnika Pomimo wielu zalet silnik CryEngine, będący przedmiotem zainteresowania niniejszej pracy, posiada również szereg niedopracowanych zagadnień. Dla produktu firmy Crytek, jak i innych dynamicznie rozwijanych projektów, zgłoszenia błędów oraz towarzyszące im liczne poprawki to rzecz w zupełności naturalna. Część błędów implementacji jest stale wykrywana podczas testów funkcjonalnych nowych części silnika oraz regresji wskazujących utratę poprawności działania wybranych fragmentów funkcjonalności. Zatem kolejne wersje silnika CryEngine oprócz jego rozbudowy przynoszą także eliminacje błędów zgłaszanych przez samych użytkowników. W zależności od typu projektu, którego realizacja opiera się na CryEngine ie dokładnie testowane są jego poszczególne fragmenty. Przykładowa rozbudowa o zjawisko naturalne jakim jest burza wykazała brak poprawności działania funkcji SetWind odpowiedzialnej za imitację wiatru. Czas trwania procesu zgłoszenia problemu i oczekiwania na kolejną wersję z nadzieją na jego naprawę był nieakceptowalny dla zachowania terminów realizacji omawianego projektu. Szczęśliwie implementacja własnej wersji wiatru nie nastręczała istotnych problemów. Wśród licznego zbioru funkcji oferowanych przez silnik znajdują się bowiem dwie bardzo przydatne w tym przypadku: GetEntitiesInBox oraz Action. Funkcja GetEntitiesInBox, której argumenty definiują prostokątny obszar przeszukiwań, rodzaj oraz maksymalną ilość elementów uzupełnia dodatkowo przekazaną listę obiektami spełniającymi zadane warunki, jednocześnie znajdujące się wewnątrz tegoż obszaru. Kolejnym krokiem algorytmu pozorowania wiatru musi być symulacja oddziaływania jego siły na poszczególne obiekty wyłonionego zbioru. Metoda Action dostępna dla każdego obiektu typu IEntity wymaga przekazania struktury jednoznacznie identyfikującej wykonanie zamierzonej akcji. Jedną z akceptowalnych jest struktura pe_action_impulse, której pole impulse typu Vec3 określa kierunek oraz długość wektora impulsu jaki zostanie przyłożonym do danego obiektu. Poznanie metody Action wraz z zestawem akceptowalnych struktur akcji otwiera przed projektantami gier szerokie możliwości oddziaływania na obiekty znajdujące się wewnątrz planszy. Dla utrwalenia istoty tego tematu przedstawiono poniżej fragment 33

Projekt rozwiązania i opis wybranych elementów implementacji krótko omówionej metody symulującej działanie wiatru, wraz z dodatkowymi komentarzami: void CStorm::SimulateWind() { //... IPhysicalEntity *plistbuf[32], **pplist = plistbuf; // wyłonienie elementów objętych działaniem wiatru int numentities = genv->pphysicalworld->getentitiesinbox( wpos-checkoffset,wpos+checkoffset,pplist,ent_all,1024); for (int i=0; i<numentities; ++i) { EntityId id = ppworld->getphysicalentityid(pplist[i]); planszy // sprawdzenie czy obiekt ma fizyczną reprezentację na IPhysicalEntity *ppent = genv->pphysicalworld-> GetPhysicalEntityById(id); if (NULL!= ppent) { // akcja symulujaca impuls pe_action_impulse imp; imp.impulse = *currwinddirection; } } } // wymuszenie wykonania akcji ppent->action(&imp); Efektem działania takiego podejścia jest realistycznie wyglądające oddziaływanie na obiekty znajdujące się w obszarze działania burzy wraz z płynną zmianą jego kierunku. Dodatkowym efektem zwiększającym naturalność odbioru symulacji są losowe podmuchy, których prawdopodobieństwo wystąpienia jest wartością jednego z parametrów określanych przez użytkownika. 4.6. Problemy nierozwiązane W tym rozdziale opisane zostały problemy, których niestety nie udało się rozwiązać. Większość zaistniałych kłopotów wynika z ograniczeń dostępności wybranych części kodu silnika CryEngine. Próba uzyskania efektu spływania kropli wody po przezroczystych okularach, obserwowanych z pierwszoosobowej perspektywy gracza, omówiona została w punkcie 4.6.1. Punkt 4.6.2. opisuje zaistniały problem wydajnościowy występujący podczas złożonej animacji rozbicia spadającej kropli deszczu. 34

Projekt rozwiązania i opis wybranych elementów implementacji 4.6.1. Problem spływania kropli wody po twarzy gracza Ciekawym efektem towarzyszącym symulacji burzy byłaby dodatkowa interakcja z postacią znajdującą się w obrębie jej oddziaływania. Wszyscy gracze oglądający świat przedstawiony oczami bohatera (z perspektywy pierwszej osoby) mieliby wrażenie spływania wody po okularach zaraz po wejściu w obszar burzy. Podobny efekt widoczny jest już w silniku CryEngine w chwili opuszczania przez gracza zbiornika z wodą (np. rzeki). Analogiczne odtworzenie podobnego odczucia okazało się jednak niemożliwym. Producenci silnika zastrzegli sobie prawa do tej części kodu implementacji, która jest odpowiedzialna za rysowanie widoku pierwszoosobowej perspektywy. Próba ominięcia tego fragmentu znacząco komplikowałaby algorytm i z tego powodu została pominięta. 4.6.2. Napotkane problemy wydajnościowe Innym problemem, jaki stawia przed projektantami silnik CryEngine jest ograniczenie akceptowanych transformacji animacji do rotacji i przesunięcia. Niestety z tego powodu duże kłopoty przysparzało zasymulowanie animacji rozbicia kropli deszczu połączonej z efektem rozchodzenia się kręgów wody w kałużach. Zaproponowane przez autora niniejszej pracy rozwiązanie polegające na połączeniu standardowej animacji rozbicia kropli wody z pojawieniem się animowanej tekstury imitującej rozchodzące się kręgi wody znacząco wpłynęło na wydajność całej symulacji. Z tego powodu konieczne było zrezygnowanie z tej dodatkowej animacji. Należy jednak pamiętać o istnieniu łatwych w tworzeniu animowanych tekstur, których przykład zaprezentowany został na Rysunku 4.6.2. 35

Projekt rozwiązania i opis wybranych elementów implementacji Rys. 4.6.2 Animowana tekstura kręgów wody 36

Ocena rozwiązania 5. Ocena rozwiązania Weryfikacja jakości rozwiązania symulacji burzy, jako ilustracji możliwości rozbudowy silnika CryEngine, może być wyrażona jedynie poprzez subiektywne oceny użytkowników. Podrozdział 5.1 stanowi zbiór zebranych opinii i odczuć osób, którym została przestawiona końcowa wersja burzy. Kolejny podrozdział stanowi ocenę złożoności procesu rozbudowy silnika CryEngine przedstawioną przez autora niniejszej pracy. 5.1. Jakość symulacji Efekty uzyskane w końcowych symulacjach wyglądają naturalnie, jeżeli burza obserwowana jest z dużej odległości. Niestety bliższe spojrzenie na poszczególne elementy symulacji odkrywa istotne niedoskonałości. Zasadniczą jest ograniczony zbiór animacji rozbicia kropli wody. Animacje te powinny być generowane na nowo dla każdego przypadku. Niestety jest to niezwykle złożony problem, który mógłby stanowić odrębny temat pracy dyplomowej. Ponadto ograniczenia wynikające z założeń wbudowanego mechanizmu obsługi animacji prawdopodobnie wymagałyby jego nowej, autorskiej implementacji. Istotną sprawą dotyczącą spadających kropli deszczu jest również brak ich odzwierciedlenia na powierzchni generowanych kałuż. Te dwa oddzielne byty musiałyby być ze sobą ściśle powiązane. Brak dostępności fragmentu kodu źródłowego silnika odpowiedzialnego za efekt kałuż stanowi poważny kłopot naprawy tego artefaktu. 37

Ocena rozwiązania Rys. 5.1 Porównanie błysku z zewnątrz (A) i wnętrza burzy (B) Na rysunku 5.1 przedstawione zostały dwa obrazki przedstawiające błysk towarzyszący piorunom widziany spoza obszaru burzy (A) oraz w jej wnętrzu (B). Jasność efektu obserwowana wewnątrz burzy jest zbyt intensywna. Na górnym rysunku łatwo jest dostrzec przybliżoną lokalizację wyładowania atmosferycznego. Na dolnym rysunku efekt jest na tyle rozmyty, że trudno wyróżnić jakiekolwiek kształty, a całość wygląda sztucznie. Przyczyną powstawania tego artefaktu jest zbyt wysoki współczynnik załamania światła przez krople deszczu, który został ustalony na stałe przez producentów silnika. W rozdziale 4.5 omówiona została implementacja wiatru. Wykonane testy symulacji burzy w zróżnicowanych środowiskach wykazały brak wpływu wiatru na część roślinności. Dokładna analiza problemu wykazała uproszczony sposób implementacji obiektów typu Vegetation. Założenie jakie towarzyszyło ich powstawaniu redukowało ich interakcję z innymi obiektami jedynie do wykrywania kolizji. Niemożliwe okazało się więc wykonywanie na nich jakichkolwiek złożonych akcji, w tym wymuszenia impulsu. 38

Ocena rozwiązania 5.2. Ocena złożoności procesu rozbudowy silnika Przedstawiony proces rozbudowy silnika CryEngine o nowy obiekt rozpoczął się od opracowania koncepcji wyglądu całego zjawiska. Zdefiniowane założenia były stopniowo weryfikowane w czasie trwania implementacji. Poziom skomplikowania silnika umożliwia jego swobodną analizę. Natomiast czas tworzenia nowych obiektów jest ściśle uzależniony od stopnia znajomości silnika i procesu jego rozbudowy. Patrząc na symulację jako złożenie poszczególnych elementów można powiedzieć, że zabrakło w niej kilku szczegółów. Całość jednak prezentuje się realistycznie i stanowi dobrą podstawę do dalszego rozwoju. 39

Podsumowanie 6. Podsumowanie W ramach niniejszej pracy przedstawiona została możliwość rozbudowy silnika CryEngine. Jako przykładową symulację zjawiska naturalnego wykorzystującą omawiany silnik wybrano burzę. Zaprezentowana technika jej realizacji była celowo dobrana tak, aby obejmowała najważniejsze fragmenty dostępnej części kodu, możliwe do szeroko pojętej rozbudowy. Przedstawiony został schemat budowy silnika wraz z wybranymi mechanizmami. Ponadto przybliżone zostały podstawowe aspekty programowania hybrydowego oraz współpracy silnika z popularnym oprogramowaniem Autodesk 3ds Max. Niestety przy dynamicznym rozwoju silnika, jest on obecnie słabo udokumentowany z punktu widzenia programistów. Dokumentacja dostępna na oficjalnej stronie producenta opisuje tylko podstawowe informacje dotyczące możliwości jego rozbudowy, które ponadto zostały wielokrotnie modyfikowane. Głównym źródłem wiedzy pozostaje więc prężnie rozwijane forum poświęcone silnikowi oraz przede wszystkim umiejętność analizowania jego kodu. W dalszej części pracy zaprezentowaną symulację burzy można rozbudować na wiele sposobów. Poza dodatkowymi efektami wizualnymi, mechanizm aktualizacji stanu obiektu może być rozszerzony w taki sposób, aby uwzględniał złożoną interakcję z innymi zjawiskami naturalnymi. Umieszczona w ramach większego programu mogłaby znaleźć szerokie zastosowania badań zachowania ludzi w razie nagłych zmian pogodowych. Stworzenie autorskiego mechanizmu destrukcji obiektów mogłoby stanowić kolejne udoskonalenie dla silnika CryEngine 3 oraz być tematem pracy magisterskiej. Kontynuacja analizy tego bogatego silnika może odkryć kolejne możliwości poprawy efektów jego działania. Projektowanie wirtualnych rzeczywistości będących odzwierciedleniem naturalnego środowiska stało się ostatnio bardzo popularne. Coraz częściej producenci analizując oczekiwania graczy odchodzą od surrealistycznych przestrzeni starając się możliwie dokładnie odwzorować zachowanie natury. Silnik CryEngine z całą pewnością na długo pozostanie trafnym wyborem zarówno dla złożonych projektów, jak również jako doskonałe narzędzie szkolenia młodych adeptów programowania wirtualnych środowisk. 40

7. Bibliografia 1. D. Tracy, S. Tracy. CryENGINE 3 Cookbook. Pack Publishing, 2011. 2. S. Tracy, P. Reindell. CryENGINE 3 Game Development Beginner's Guide. Pack Publishing, 2012. 3. Grafika komputerowa http://pl.wikipedia.org/wiki/grafika_komputerowa 4. CryEngine 3 dokumentacja, Integracja pomiędzy LUA oraz C++ http://freesdk.crydev.net/pages/viewpage.action?pageid=1 31661 5. Artykuł prezentujący silniki gier http://www.benchmark.pl/testy_i_recenzje/najwazniejsze_s ilniki_gier_cz._1-2798.html 6. Oficjalna dokumentacja CryEngine 3 http://freesdk.crydev.net/dashboard.action 7. Definicja silnika gier http://en.wikipedia.org/wiki/game_engine 8. CryEngine - licencje http://mycryengine.com/?conid=70 9. Porównanie silników gier http://www.develop-online.net/news/the-top-14-gameengines-the-list-in-full/0114330 10. CryEngine 3 dokumentacja, Instalacja wtyczek http://freesdk.crydev.net/display/sdkdoc3/installing+exp orter+plugins 11. Kelly L. Murdock. 3ds Max 8. Biblia. Helion, 2007. 12. CryEngine 3 dokumentacja, Struktura skryptów http://freesdk.crydev.net/display/sdkdoc5/structure+of+a +Script+Entity 41

Zawartość płyty CD 8. Zawartość płyty CD Na załączonej płycie CD znajdują się: tekst pracy w pliku Symulacja zjawiska naturalnych CryEngine.pdf, kod źródłowy nowo dodanych oraz zmodyfikowanych klas silnika CryEngine 3.4.5 (w katalogu GameDll), skrypty LUA stworzone w ramach realizowanego projektu (w katalogu Skrypty), obiekty i animacje projektu stworzone w programie 3ds Max 2010 (w katalogu Obiekty i animacje), pozostałe obiekty dodane do silnika CryEngine (w katalogu Pozostałe obiekty), filmy prezentujące projektowane zjawisko naturalne przy zróżnicowanych wartościach parametrów (w katalogu Filmy), przykładowe rozwiązania zadań laboratoryjnych (w katalogu Laboratoria). 42

Załączniki 9. Załączniki Załącznik A. Zapoznanie ze środowiskiem CryEngine 3 Free SDK 1. Wstęp CryEngine 3 to silnik do gier umożliwiający projektantowi bardzo dużą swobodę w budowaniu własnych przestrzeni, w których toczona będzie rozgrywka. Studio developerskie Crytek odpowiedzialne za rozwój silnika dostarcza edytor graficzny CryENGINE 3 Sandbox Editor pozwalający na projektowanie wspomnianych plansz w sposób wysoce przyjazny użytkownikowi. Dzięki niemu stworzenie własnej gry jest możliwe bez znajomości języków programowania. Znając najbardziej efektowne gry stworzone dzięki silnikowi CryEngine można wysnuwać marzenia o stworzeniu własnej gry, która mogłaby podbić serca wszystkich graczy. Należy mieć świadomość, że zostały one stworzone przez liczne zespoły programistów i grafików pracujących nad jednym projektem przez wiele miesięcy. Dzięki edytorowi Sandbox wchodzącego w skład większego pakietu CryEngine 3 Free SDK możliwe jest wykonanie autorskiego projektu w domowych warunkach. Skrypt ten stanowi wprowadzenie w temat tworzenia scen w programie CryEngine 3 Sandbox i podzielony został na dwie części. Pierwsza z nich omawia wygląd i organizację interfejsu użytkownika. Druga jest przeglądem dostępnych w programie obiektów oraz instrukcją tworzenia prostej mapy, która jest celem laboratorium. 2. CryEngine 3 Sandbox podstawy Rysunek A.1 prezentuje interfejs użytkownika dostępny w głównym oknie programu. Został on podzielony na pięć zasadniczych części: główny pasek menu, panel poleceń (ang. RollupBar), pasek stanu, konsolę oraz widok tworzonej sceny (ang. Viewport). 43

Załączniki Rys. A.1 Interfejs użytkownika 2.1 Główny pasek menu Rysunek A.2 przedstawia organizację głównego paska menu (ang. menu bar). Pozwala on na szybki dostęp użytkownika do licznych funkcji edytora Sandbox. Znajdują się tutaj: obsługa podstawowych operacji wejścia-wyjścia, modyfikacji obiektów znajdujących się w tworzonej scenie (m.in. przesuwanie, skalowanie, łączenie elementów) oraz złożonych modyfikacji terenu i zarządzania materiałami. Całość jest intuicyjna i nie stanowi problemu nawet dla początkujących użytkowników. Rys. A.2 Menu główne 2.2 Widok główny Widok główny stanowi centralną część edytora, która umożliwia podgląd i nawigację tworzonego projektu. Wszystkie nowo dodane obiekty, modyfikacja terenu oraz zmiana nałożonych materiałów renderowanie są w czasie rzeczywistym. Poruszanie się wewnątrz sceny odbywa się za pomocą przycisków W,A,S,D oraz myszy. Przytrzymanie prawego przycisku myszy umożliwia obrót bieżącej kamery, a kombinacja klawiszy CTRL+G pozwala na natychmiastowe przejście do trybu gry. Wyjście ze wspomnianego trybu wymaga naciśnięcia klawisza Escape [1 rozdz. 1]. 44

Załączniki 2.3 Panel poleceń Rysunek A.3 pokazuje panel poleceń dostępny z prawej strony ekranu głównego, który został zorganizowany w strukturę drzewiastą rozdzielającą kolejne poziomy poleceń. Rys. A.3 Panel poleceń Pierwsza zakładka zawiera narzędzia tworzenia obiektów, jak również stanowi miejsce wyświetlania i modyfikacji ich właściwości. Wszystkie elementy dostępne w edytorze podzielone są tutaj na grupy, a umieszczanie ich w modelowanej scenie odbywa się na zasadzie przeciągnij i upuść. W wielu przypadkach warto dodatkowo skorzystać z opcji śledzenia terenu przycisk Follow Terrain. Dzięki temu nowo dodawane obiekty automatycznie będą przylegały do terenu mapy. 3. Edycja terenu Teren nowo utworzonej sceny domyślnie jest płaską powierzchnią wody. Niniejszy rozdział przedstawia proceduralne generowanie terenu. Mimo iż nie jest to zawsze właściwe podejście w perspektywie finalnego produktu to stanowi bardzo dobry przykład dla początkujących użytkowników i umożliwia szybką generację prototypu tworzonej mapy [1]. Wybierając ikonę edycji terenu bądź pozycję Edit Terrain z menu Terrain użytkownik może przejść do okna edycji terenu (Rys. A.4). 45