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

Plan prezentacji

• Cel pracy

• Budowa i działanie silnika

• Przedstawienie możliwości renderera

• Demonstracja możliwości silnika

• Podsumowanie

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

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

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

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

Budowa silnika

• Schemat zależności między komponentami

Game.exe

Game.dll

GameEngine.dll

Editor.exe

W rzeczywistości edytor korzysta również bezpośrednio z silnika

Budowa silnika

• Funkcjonalność silnika udostępniona jest tylko poprzez interfejsy

• Funkcjonalność podstawowa, z której korzystają wszystkie komponenty znajduje się w bibliotece statycznej

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

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!

Renderer

• Najbardziej rozbudowana część silnika

• Najważniejsze zagadnienia– System materiałów– Rysowanie sceny

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!

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

Renderer – system materiałów

Plik *.fx

param: vertex = Normal;param: ViewPos;

bool Specular = true;float Shininess = 50;

… kod dla karty graficznej

WłaściwośćTyp wierzchołków

WymaganiePołożenie kamery

definicja parametrów

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ściparametrów

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?

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

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

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

Wyspa

C – zmiana oświetlenia

Duża wyspa – wersja 1

Duża wyspa – wersja 2

Symulacja wody na karcie graficznej

Teren

Edycja:

S – znak modyfikacji +/-

A – zmiany: alpha / vertex

1-4 – aktywna warstwa

Obsługa:- Wyłącz kamerę – F2- Przywłaszcz myszkę - Enter

Załamanie światła

Parallax mapping

Podsumowanie

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

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

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

Dziękuję za uwagę