Realistyczny rendering dla potrzeb gier komputerowych

1. Realistyczny rendering dla potrzeb gier komputerowych Projekt i realizacja przykładowego silnika Piotr Turecki Praca magisterska pod kierunkiem dr Witolda Aldy Katedra Informatyki – AGH Kraków 2007

2. Plan prezentacji • Cel pracy • Budowa i działanie silnika • Przedstawienie możliwości renderera • Demonstracja możliwości silnika • Podsumowanie

3. Cel pracy • „Profesjonalny” silnik do gier o następujących cechach: • Budowa i działanie podobne do produktów komercyjnych • Podział na komponenty • Możliwość uruchomienia w oknie aplikacji napisanej w MFC • Łatwo „obudować” okno silnika w rozbudowany interfejs użytkownika (np. Edytor) • Łatwa modyfikacja zawartości gry • Widok w edytorze jest identyczny z widokiem z poziomu gry

4. Cel pracy • Nacisk położony na grafikę • Pozostałe podsystemy nieobecne lub mocno ograniczone • Wykorzystanie najnowszych (już nie) technologii graficznych (DX9.0) • Rozbudowany system materiałów • Możliwość zdefiniowania praktycznie dowolnego typu powierzchni

5. Cel pracy • Realistyczny rendering • Czyli poprawny fizycznie • Dla potrzeb gier • Czyli szybki • Poprawny fizycznie i szybki • Czyli praktycznie niemożliwy • Trzeba znaleźć kompromis! • Szczegóły w dalszych przykładach

6. Budowa silnika • Podział systemu na komponenty: • Silnik (GameEngine.dll) • Łatwo uaktualnić do nowszej wersji • Gra (Game.dll) • Cała logika gry – jw. łatwo uaktualnić • Potrzebne dla edytora • Moduł uruchomienia gry (Game.exe) • Korzysta z Game.dll • Edytor świata gry • Korzysta z Game.dll i GameEngine.dll

7. Game.exe Editor.exe Game.dll GameEngine.dll Budowa silnika • Schemat zależności między komponentami W rzeczywistości edytor korzysta również bezpośrednio z silnika

8. Budowa silnika • Funkcjonalność silnika udostępniona jest tylko poprzez interfejsy • Funkcjonalność podstawowa, z której korzystają wszystkie komponenty znajduje się w bibliotece statycznej

9. Działanie silnika w grze • Gra inicjalizuje silnik • Silnik tworzy okno, w którym renderuje świat gry i które pośredniczy w odbiorze wiadomości od systemu operacyjnego • Gra uruchamia blokującą metodę Run silnika • Od tej pory kod gry uruchamiany jest przez zarejestrowane wcześniej funkcje • Obsługa wejścia, obsługa logiki gry

10. Działanie silnika w edytorze • Nie można wywołać blokującej metody ani przejąć kontroli nad myszką i klawiaturą • Edytor inicjalizuje silnik (poprzez interfejs gry!) podając jako parametr już utworzone okno • Silnik będzie renderował świat w tym oknie • Edytor podczas swojego działania: • Cyklicznie wywołuje metodę silnika OnFrame • Obsługa logiki wewnątrz silnika • Wywoływanie zarejestrowanych funkcji gry • Przekazuje do silnika wiadomości od myszki i klawiatury • Logika gry jest uruchamiana również w edytorze!

11. Renderer • Najbardziej rozbudowana część silnika • Najważniejsze zagadnienia • System materiałów • Rysowanie sceny

12. Renderer – system materiałów • Jak zaprojektować system materiałów tak aby • Umożliwiał łatwe definiowanie materiałów • Miał duże możliwości • Korzystał z najnowszych technologii • Obsługiwał najnowsze efekty • Implementacja jednego efektu „nie jest trudna” • Trudnością jest obsługa wielu efektów naraz!

13. Zastosowane rozwiązanie • Własny prosty język opisu materiałów • Łatwo definiować nowe materiały • Dwuczęściowa definicja materiału • Klasa materiału - plik *.fx • Kod dla karty graficznej • Opis właściwości oraz wymagań materiału • Definicja parametrów materiału • Instancja materiału - plik *.ge_mat • Określenie używanych tekstur • Określenie wartości parametrów

14. Renderer – system materiałów Właściwość Typ wierzchołków Plik *.fx param: vertex = Normal; param: ViewPos; bool Specular = true; float Shininess = 50; … kod dla karty graficznej Wymaganie Położenie kamery definicja parametrów

15. Renderer – system materiałów Plik *.ge_mat material "stone01" { tex[DiffuseMap] = "stone/stucco8.jpg"; tex[BumpMap] = "up.tga"; fx = "Solid.fx" { Specular = false; Parallax = false; } } Używane tekstury Używany plik *.fx Nadpisanie wartości parametrów

16. Renderer – Rysowanie sceny • Typowa scena składa się z setek obiektów pokrytych różnymi materiałami • Trzeba ją narysować szybko • Dlaczego to jest takie trudne?

17. Renderer – Rysowanie sceny • Jeden obiekt może być pokryty wieloma materiałami • Nie da się rysować obiektu jako całości • Kolejność rysowania materiałów ma znaczenie • Materiały przezroczyste, załamanie światła • Lustra wymagają dwukrotnego rysowania całej sceny • Woda, zwykłe lustro • Dynamiczne cienie • Dodatkowy przebieg głębi dla każdego światła • Dla punktowych nawet 6 przebiegów • Nowoczesne efekty – zajmują więcej czasu • Mapowanie nierówności, cienie, woda, rozbudowane oświetlenie • Dodanie nowego efektu często wymaga zmiany w obecnej implementacji • W kodzie dla karty graficznej i w C++ • Np. dynamiczne cienie – Dużo zmian w przebiegu oświetlenia w C++ i w shaderach • A to tylko aspekt graficzny • Co z fizyką, logiką, zarządzaniem widocznością, całym procesem rysowania sceny, itp.?

18. Rozwiązanie • Podział sceny na atomowe fragmenty • Łatwo posortować i wyświetlić tak aby było najmniej zmian stanu karty graficznej • Proces renderowania rozbity na osobne przebiegi • Przebieg koloru • Przebieg oświetlenia • Przebieg rysowania głębi • Upraszcza obliczenia w każdym przebiegu i umożliwia zastosowanie bardziej rozbudowanych efektów • Np. obsługa wielu świateł z dynamicznymi cieniami

19. Demonstracja możliwości silnika • We wszystkich demach: • F1 – zrzut ekranu • F2 – automatyczna kamera • F3 / F4 – następna / poprzednia kamera • F5 x2 – zapis danych kamery • Enter – przejęcie kontroli nad myszką • Esc – zwolnienie myszki • Esc x2 – wyjście • Sterowanie kamerą – strzałki + myszka

20. Wyspa C – zmiana oświetlenia

21. Duża wyspa – wersja 1

22. Duża wyspa – wersja 2

23. Symulacja wody na karcie graficznej

24. Teren Edycja: S – znak modyfikacji +/- A – zmiany: alpha / vertex 1-4 – aktywna warstwa Obsługa: • Wyłącz kamerę – F2 • Przywłaszcz myszkę - Enter

25. Załamanie światła

26. Parallax mapping

27. Podsumowanie

28. Realizacja celu • Wszystkie główne założenia zostały zrealizowane • Budowa i działanie silnika podobne do produktów komercyjnych • Zaawansowana grafika • Duże możliwości systemu materiałów • Zdobyte doświadczenie oraz wiedza • Jednak nie wszystko udało się zrealizować • Perspektywiczne mapy cienia • Efekty wolumetryczne • „Porządny” edytor

29. Wykorzystanie • Dla innych programistów • Wiele problemów jest rozwiązanych, zerknięcie do kodu może oszczędzić wiele czasu • Pomoc w wykładach / ćwiczeniach • Dobry punkt wyjścia (dokumentacja) • Demonstracja różnych efektów

30. Rozbudowa • Autor od początku prac nie planował rozbudowy projektu • Projekt służył zapoznaniu się z tego typu zadaniem (jak bardzo to jest trudne?) • Zmierzenie się z napotkanymi problemami • Zebranie doświadczenia • Wszystko po to aby napisać następny – dużo lepszy silnik • Nie wyklucza to możliwości rozbudowy lub wykorzystania przez innych

31. Dziękuję za uwagę