Simulátor jízdy městem

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Diplomová práce Simulátor jízdy městem David Tichý Vedoucí práce: Doc. Ing. Jiří Žára, CSc. Obor: Výpočetní technika květen 2006

2 Zadání Analyzujte volně dostupná herní jádra (game engine) z hlediska jejich schopností, výkonu a použitelnosti pro simulaci jízdy autem ve městě. Na základě této analýzy navrhněte a implementujte vlastní jádro simulátoru, odpovídající tomuto typu problému. Pro reálné zobrazení města využijte ve velké míře schopností moderních grafických karet. Součástí simulátoru bude i fyzikální model vozidla a detekce kolizí. Tyto komponenty mohou být postaveny na již existujícím řešení, např. ODE. Hustotu provozu (pohyb okolních aut) simulujte pomocí modifikovaného částicového systému. Simulátor bude také zahrnovat podporu skriptovaných událostí. Navrhněte a realizujte takovou strukturu pro rozsáhlé virtuální scény, která bude vhodná jak z hlediska efektivního vykreslování, tak pro potřeby kolizního podsystému. Pro model města využijte data z diplomové práce Martina Bašty. Porovnejte schopnosti a výkon vytvořeného simulátoru s podobnými produkty. Výsledky zhodnoťte a navrhněte případná další rozšíření. Seznam odborné literatury: David H. Eberly: 3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics. Morgan Kaufmann, 2001, ISBN: The Nebula Device 2 Engine. Open Dynamics Engine, i

3 Poděkování Rád bych poděkoval zejména vedoucímu mé diplomové práce doc. Ing. Jiřímu Žárovi, CSc., za cenné rady, Martinu Baštovi za výborně fungující spolupráci na propojení našich projektů, Dr. Ing. Tomáši Mackovi z firmy IBM za motivaci a formulaci priorit projektu, rodině a přátelům za podporu. ii

4 Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady (literaturu, projekty, SW atd.) uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č.121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). Dále povoluji volně využívat toto školní dílo firmě IBM bez omezení. V Praze dne.. David Tichý iii

5 Abstract The chalenge of this thesis is to design and implement a new game engine, suitable for a car drive simulation in a virtual environment. The main task is to achieve both realistic car motion and authenticity of graphical representation. Incoming scenes, such as models of town or its surrounding, are automatically generated (self-generated), thus their description needs to be well designed. Traffic simulator, controling motion of the other cars, is also included in the project. Abstrakt Cílem diplomové práce bylo vytvoření herního jádra vhodného pro simulaci průjezdu auta virtuálním prostředím. Důraz je kladen jak na reálnost pohybu auta, tak na vizuální věrohodnost. Vstupními scénami jsou automaticky generované modely města či jeho okolí, proto je nutné navrhnout dostatečně abstraktní způsob jejich popisu. Součástí projektu je také simulátor provozu, řídící pohyb okolních aut. iv

6 Obsah 1 Úvod Struktura textu Herní jádro (game engine) Objekt Grafická reprezentace Úroveň detailu (LOD) Ohraničující těleso (Bounding box) Fyzikální reprezentace Prostředky (Resources) Efekty Textury Geometrie (Mesh) Kolizní obálky (Ode Mesh) Obálky pro výpočet stínů (Shadow Hull) Správa prostředků Scéna Strukturalizace scény Ořezávání pohledovým jehlanem (Frustum culling) Správa poloprůhledných částí objektů Kamera Parametry prostředí (Environment) Import modelů Grafika Světlo Ambientní světlo Difusní světlo Odlesky Realizace Phongova modelu grafickými kartami Výpočet osvětlení na úrovni vrcholů (per-vertex lighting) Určení difusní složky světla Určení zrcadlové složky světla Určení výsledného osvětlení Stínování (shading) Výpočet osvětlení na úrovni pixelů (per-pixel lighting) Vytváření normálových map Formát normálových map Normály v objektovém prostoru (object space normals) Normály v tangentovém prostoru (tangent space normals) Implementace Per-vertex versus per-pixel metody Stíny Stencilové stíny Implementace Algoritmus určení obrysu tělesa Konstrukce stínového tělesa Optimalizace Implementované způsoby tvorby stínů v

7 Vykreslení stínů z-pass algoritmus Odstranění problému kamery ve stínu Shrnutí Efekty Odlesky oblohy na karoserii aut Multitexturing Fyzika Fyzikální reprezentace objektů Simulační proces Detekce kolizí Aplikace průjezdu městem (City Rider) Fyzikální model vozidla Simulace okolní dopravy Analýza chování uživatele Vstupní scény Testování Závěr Seznam literatury Přílohy Popis formátů vstupních dat D soubor Mesh soubor OdeMesh soubor Popis scény Cell soubor Graf ulic Street soubor Uživatelská příručka Popis parametrů konfiguračního souboru CityRider.ini Ovládání aplikace CityRider Obsah přiloženého CD vi

8 1 Úvod Cílem diplomové práce bylo vytvoření herního jádra vhodného pro simulaci průjezdu auta virtuálním prostředím. Pro implementaci reálného pohybu auta byla použita knihovna pro simulaci dynamiky tuhých těles. Důraz byl kladen též na vizuální věrohodnost, proto herní jádro využívá schopností moderních grafických karet, zároveň si ale zachovává dostatečnou flexibilitu v možnostech nastavení kvality grafické podoby. Vstupními scénami jsou automaticky generované modely města či jeho okolí, proto bylo nutné navrhnout dostatečně abstraktní způsob jejich popisu. Součástí projektu je také simulátor provozu, řídící pohyb okolních aut, základní podpora zvuků a možnost ovládání aplikace pomocí volantu. První základní verze aplikace byla vytvořena v enginu Nebula Device 2. Během třítýdenního pobytu na Institutu počítačové grafiky a algoritmů na Technické Universitě ve Vídni byla též vytvořena verze v grafickém enginu Ogre. Na základě zkušeností s těmito často používanými herními jádry byl implementován vlastní engine, přizpůsobený nárokům na výslednou, v něm vytvořenou, aplikaci průjezdu městem. 1.1 Struktura textu Protože se tato diplomová práce skládá z několika relativně oddělených celků, je toto respektováno i ve struktuře následujícího textu. Kapitola 2 Herní jádro obsahuje vysvětlení základů vytvořeného enginu. Kromě popisu datových struktur se zabývá také několika bězně používanými optimalizačními technikami. Kapitola 3 Grafika je zaměřena na grafickou část herního jádra. Zabývá se mimojiné metodami pro výpočet osvětlení a stínů, přičemž pozornost je soustředěna hlavně na způsob jakým tyto obecně známé techniky podporují moderní grafické karty. Kapitola 4 Fyzika je věnována popisu integrace knihovny pro simulaci dynamiky tuhých těles do vytvářeného enginu. Kapitola 5 Aplikace průjezdu městem se zabývá výslednou aplikací postavenou na vytvořeném herním jádře. 0

9 2 Herní jádro (game engine) Vytvořené herní jádro zahrnuje komplexní správu prostředků, integrovaný fyzikální engine, základní rozhraní pro použití zvuků, podporu několika vstupních zařízení. Z optimalizačních technik byla implementována podpora LOD, víceúrovňové ořezávání scény. Byly navrženy formáty jak pro popis jednotlivých objektů, tak pro definici celé scény. Engine byl naprogramován v jazyce C++, jako grafické API bylo zvoleno DirectX Graphics. Pro implementaci zvuků je využíváno rozhraní DirectSound, pro podporu vstupních zařízení DirectInput. 2.1 Objekt Je základním stavebním prvkem výsledné scény, tvořeným svou grafickou reprezentací a volitelně též fyzikální reprezentací a ohraničujícím tělesem pro ořezávání Grafická reprezentace Je dána seznamem úrovní detailu (LOD level of detail), které jsou pro daný objekt k dispozici. Tento seznam je seřazen vzestupně podle maximální vzdálenosti, do které má být daný LOD použit. Při vlastním vykreslování je pak podle aktuální vzdálenosti objektu od kamery použit první vyhovující LOD. Hodnoty maximální vzdálenosti jsou pro úrovně detailu specifikovány relativně (maximální hodnota je 1.0), vzhledem k dohledové vzdálenosti (parametr visible distance) aktuální kamery. Také u nejmenší úrovně detailu lze specifikovat dohledovou vzdálenost menší než 1.0, což znamená, že po překročení této vzdálenosti již nebude objekt vykreslován (přestože se nachází v pohledovém tělese kamery) Úroveň detailu (LOD) Obsahuje odkaz na příslušný mesh, viz. kapitola Geometrie (Mesh), definující vlastní geometrii (vrcholy a trojúhelníky) grafické reprezentace a volitelně též odkaz na zjednodušenou obálku pro výpočet stínů, viz. kapitola Obálky pro výpočet stínů (Shadow Hull). Trojúhelníky grafické reprezentace jsou roztříděny podle použitého efektu (viz. kapitoly a 3.3 Efekty) a sady textur do skupin (tzv. primitiv). Každá úroveň detailu pak obsahuje seznam svých primitiv, kde je pro každou specifikován příslušný efekt a sada textur. LOD byl tedy pojat komplexněji než v jiných enginech, kde bývá definován pouze pro úrovně detailu geometrie. Díky tomu, že jsou použité efekty specifikovány v rámci každého LOD a ne pouze na úrovni objektu, je možné používat pro vyšší úrovně detailu náročnější efekty a naopak. 1

10 Ohraničující těleso (Bounding box) Používá se pro algoritmus ořezávání scény, viz. kapitola Ořezávání pohledovým jehlanem (Frustum culling). Je zadáno osmi vrcholy představujícími vrcholy konvexního tělesa ohraničující daný objekt. Pokud objekt nemá specifikováno ohraničující těleso, nevstupuje do ořezávacího algoritmu, ale je vždy vykreslen (pokud již nebyl oříznut na vyšší úrovni) Fyzikální reprezentace Specifikuje fyzikální vlastnosti daného objektu, viz. kapitola 4 Fyzika. 2.2 Prostředky (Resources) Pojmem prostředky jsou zde myšleny samostatné entity, které mezi sebou mohou objekty sdílet. Pro jejich efektivní správu byl implementován komplexní generický objekt správce (manager), totožný pro všechny druhy prostředků, viz. kapitola 2.3 Správa prostředků. Engine implementuje tyto základní typy prostředků: efekty, textury, meshe, kolizní obálky pro fyzikální engine (ode mesh) a obálky pro výpočet stínů Efekty Definují jakým způsobem se má dané primitivum vykreslit, viz. kapitola 3.3 Efekty. Implementovaný objekt CEffect představuje nadstavbu nad vlastním efektem, která zprostředkovává předávání parametrů z enginu do daného efektu Textury DirectX podporuje velkou řadu standardních formátů (bmp, jpg, tga, ), kromě toho zavedlo svůj vlastní formát DDS (Direct Draw Surface), který umožňuje uložení mipmap a použití tzv. komprimovaných textur (rozbalovaných až při aplikaci). Vytvořený objekt CTexture obsahuje i rozhraní pro zjednodušení použití techniky rendrování do textur (v aplikaci City Rider použito pro implementaci zpětného zrcátka) Geometrie (Mesh) Popisuje vlastní geometrii grafické reprezentace, roztříděnou do skupin (primitiv). Pro každé primitivum je vytvořena vlastní paměť vrcholů (vertex buffer) a paměť indexů vrcholů (index buffer) definující jednotlivé trojúhelníky. Tento přístup není z paměťového hlediska optimální, jelikož vertex a index buffer se vytváří v paměti grafické karty a pro každý buffer je alokováno určité množství paměti navíc (nutné pro správu a přístup k bufferům). Na druhou stranu je tímto zajištěna větší flexibilita při návrhu grafické reprezentace objektů, jelikož každé primitivum daného objektu může mít jiný typ údajů uložených pro každý vrchol. 2

11 2.2.4 Kolizní obálky (Ode Mesh) Definují obálku objektu použitou pro detekci kolizí ve fyzikálním enginu, viz. kapitola 4 Fyzika Obálky pro výpočet stínů (Shadow Hull) Specifikují obálku (zjednodušený model grafické reprezentace) využívanou ke konstrukci stínových těles, viz kapitola 3.2 Stíny. 2.3 Správa prostředků Komplexní efektivní správa prostředků je důležitým rysem moderních enginů. Hlavním požadavkem je možnost sdílení jednotlivých prostředků více objekty. Za tímto účelem byla implementována technika počítaných referencí pro uvolňování daného prostředku až v případě uvolnění posledního objektu, který ho používal. Všechny typy prostředků mohou být též alokovány v tzv. permanentním módu, kdy po načtení zůstávají v paměti až do ukončení programu. Tento způsob je vhodný například pro často používané textury, aby se zamezilo jejich častému opakovanému načítání a uvolňování při dynamickém vytváření a rušení objektů, které je používají, během běhu programu. Všechny typy prostředků (kromě efektů) obsahují kromě metod pro načítání z externích souborů i rozhraní pro jejich dynamické vytváření, které by mělo být v budoucnu použito při dynamickém generování vstupních modelů. Jedním z problémů při implementaci sdílených prostředků je jakým způsobem definovat ekvivalenci použitých prostředků v externích souborech popisujících objekty scény (např. jak zjistit zda textura, na kterou se odkazuje právě načítaný objekt, není již v paměti). Ve vytvořeném enginu byla zvolena detekce ekvivalence na základě jména souboru, ve kterém je daný prostředek uložen. Tento způsob (použitý také v Ogre) není sice nejefektivnější, jelikož při zjišťování ekvivalence vyžaduje použití porovnávání řetězců, jeho výhodou je ovšem to, že umožňuje snadné odkazování se na prostředky v souborech popisujících objekty přímo jménem jejich souboru. Aby délka porovnávaných řetězců byla co nejmenší, není povoleno v souborech objektů odkazování na prostředky relativními cestami. Všechny prostředky daného typu proto musí být ve stejném adresáři (efekty v adresáři Effect, textury v adresáři Texture, atd.), čímž je zároveň zaručena unikátnost jejich jména souboru. 2.4 Scéna Implementovaný objekt CScene provádí správu všech objektů tvořících výslednou scénu. Stará se o všechny globální operace (operace, které není možné provádět na úrovni jednotlivých objektů, či ještě níže na úrovni aplikovaných efektů) nutné pro korektní a optimalizované vykreslení scény: víceúrovňové ořezávání scény, správa poloprůhledných objektů, konstrukce stínového tělesa. Spravuje také fyzikální engine, proto před samotným vykreslováním provádí detekci kolizí a simulační krok fyzikálního enginu. 3

12 2.4.1 Strukturalizace scény Je velice důležité z hlediska optimalizace vykreslování scény. Moderní grafické enginy proto implementují řadu pokročilých technik pro dosažení optimálního výkonu vzhledem k danému typu scény (např. BSP, quadtree, octree). Vlastní scéna se pak většinou již při samotném grafickém návrhu přizpůsobuje použitému typu strukturalizace a tím maximálně využívá jeho výhod. Vygenerované scény, jak města tak dálnic, neumožňují aplikovat nějakou z pokročilejších ořezávacích technik, protože neobsahují nějaké stálé větší celky, které by byly při používaných pohledech kamery zcela v zákrytu jiné části scény. Proto byla implementována pouze technika ořezávání scény pohledovým jehlanem (frustum culling). Protože grafická reprezentace vytvořených scén má plošně relativně rovnoměrné rozložení hustoty trojúhelníků, byla zvolena pro strukturalizaci scény pravidelná dvourozměrná mřížka. Každá buňka mřížky je popsána jedním externím souborem, definujícím prostorové rozmístění objektů v této buňce. Toto řešení není z hlediska jednoduchosti vstupních dat úplně optimální. Korektnější způsob by byl použití jednoho souboru, popisujícího celou scénu, jejíž objekty by si poté engine sám rozdělil do příslušných buněk. Tento přístup byl ale zvolen vzhledem k budoucímu dynamickému generování, kdy takový globální popis scény nebude k dispozici a kompletní specifikace jedné vygenerované buňky bude nejmenší jednotkou předávanou enginu generátorem. Přestože je mřížka pravidelná, lze v souboru buňky explicitně definovat její ohraničující těleso, což je nutné pro zamezení nekorektního ořezání, ke kterému by došlo pokud některý z objektů buňky obsahuje trojúhelníky přesahující její implicitní hranice. Vlastní určení viditelných objektů probíhá ve třech úrovních: 1) Nejprve se určí čtverec potenciálně viditelných buněk vzhledem k aktuální poloze kamery. Středem tohoto čtverce je buňka, ve které se nachází výchozí bod kamery a délka strany čtverce (v počtu buněk) je odvozena od dohledové vzdálenosti dané kamery. 2) Pro každou buňku nacházející se v tomto čtverci se na základě jejího ohraničujícího tělesa určí pomocí algoritmu frustum culling, zda je alespoň částečně viditelná. 3) V poslední fázi se prochází všechny objekty viditelných buněk a opět pomocí algoritmu frustum culling se na základě jejich ohraničujících těles určuje, zda jsou viditelné. Pokud jsou a zároveň jejich vzdálenost od výchozího bodu kamery není větší než maximální vzdálenost použití nejnižší úrovně detailu daného objektu, je tento objekt vykreslen Ořezávání pohledovým jehlanem (Frustum culling) Tento algoritmus určení viditelnosti pracuje s konvexní ohraničující obálkou daného objektu definovanou osmi vrcholy a pohledovým tělesem (frustum) kamery. Je rozdělen 4

13 na několik kroků postupně od hrubších (nejrychlejších krok 1 a 2), za účelem dosažení maximálního výkonu. 1) Pokud některý z vrcholů ohraničujícího tělesa objektu leží v pohledovém tělese, pak je objekt viditelný. 2) Při výpočtu prvního kroku se zároveň ukládá informace o tom, zda daný vrchol leží na vnější či vnitřní straně dané stěny pohledového tělesa. Pokud jsou všechny vrcholy na vnější straně nějaké stejné stěny pohledového tělesa, pak objekt není viditelný. 3) Pokud nějaká hrana pohledového tělesa protíná nějakou stěnu ohraničujícího tělesa objektu, je objekt viditelný. 4) Pokud nějaká hrana ohraničujícího tělesa objektu protíná nějakou stěnu pohledového tělesa, je objekt viditelný. 5) Jinak objekt není viditelný Správa poloprůhledných částí objektů Pro korektní vykreslení poloprůhledné části objektu je nutné, aby nejdříve byla vykreslena část scény nacházející se v daném pohledu za ní a do tohoto obrazu je poté přimíchán vykreslený poloprůhledný objekt. Obr : Ukázka prvního typu poloprůhledných částí Vytvořený engine rozlišuje dva typy poloprůhledných částí objektů: 1) Části, které leží těsně nad jiným daným objektem a je zaručené, že nenastane případ, kdy by byl nějaký další objekt vykreslován mezi těmito dvěma. V tomto případě stačí jednoduše nejdříve vykreslit objekt ležící pod a poté danou poloprůhlednou část. Tato technika byla ve vytvořených scénách použita např. na dopravní značky kreslené na silnici nebo plakáty na zdech domů, viz Obr ) Obecně umístěná část objektu není vykreslována přímo, ale pouze se na ni uloží odkaz do seznamu aktuálně viditelných poloprůhledných částí. Tyto části jsou po vykreslení celé scény seřazeny podle vzdálenosti od výchozího bodu kamery a 5

14 poté vykresleny postupně od nejvzdálenější části. Tato technika je výkonově relativně náročná, ne kvůli řazení, ale protože všechny poloprůhledné části musí být v daném objektu uloženy jako oddělená primitiva a statické poloprůhledné objekty s nízkým počtem trojúhelníků i přesto, že používající stejný efekt a stejnou sadu textur nemohou být slučovány do jednoho objektu (protože při různých úhlech pohledu se mění pořadí jejich vykreslování) čímž roste počet vykreslovaných primitiv (= počet přepínaní rendrovacích stavů) v každém snímku a tento počet je velice důležitý faktor ovlivňující výsledný výkon aplikace. Tento přístup byl použit ve výsledné scéně na vykreslení stromů, viz Obr Obr : Ukázka druhého typu poloprůhledných částí: a) Nekorektní zobrazení (neseřazené poloprůhledné části, b) Správné zobrazení. Pozn: Při vykreslování trojúhelníků ležících těsně nad sebou může kvůli omezené přesnosti paměti hloubky (z-buffer) dojít ve výsledném obraze k jejich nežádoucímu prolínání (tzv. z-fighting). Pokud bychom ale např. nápisy na silnici umístili příliš vysoko, pro odstranění tohoto problému, vzniknul by nový problém kola auta by se viditelně zabořovala do ploch těchto nápisů. Díky tomu že jsou ale tyto nápisy (stejně jako ostatní poloprůhledné části) vykresleny za použití speciálního efektu, který při vykreslování nezapisuje do paměti hloubky, budou všechny následně vykreslené objekty kresleny přes tyto nápisy, což umožňuje umístit je relativně vysoko nad silnici a tím zabránit vzniku prolínání Kamera Implementovaný objekt CCamera zapouzdřuje veškeré parametry kamery, nejen její projekční a zobrazovací matice, ale také pohledového tělesa pro ořezávání scény. Důležitým parametrem dané kamery je její dohledová vzdálenost, podle níž se řídí ořezávací algoritmus a hlavně volba použitého LOD viditelných objektů. Scéna standardně obsahuje jednu orthogonální kameru (používanou např. pro vykreslení obsahu stencilové paměti do výsledného obrazu při zobrazování stínů), ostatní klasické kamery jsou definované uživatelem až na úrovni aplikace používající tento engine. 6

15 2.4.5 Parametry prostředí (Environment) Skupina parametrů definujících globální vlastnosti prostředí. Aktuálně to jsou pouze: hustota a barva mlhy a parametry osvětlení směrový vektor světla a barvy jeho jednotlivých složek (ambientní, difusní, zrcadlové). 2.5 Import modelů Pro import modelů do enginu byl vytvořen konvertor z 3DS formátu (3D Studio file) do formátů enginu. V konvertoru byl implementován algoritmus pro výpočet normál vrcholů a některé základní optimalizační techniky, zaměřující se především na minimalizaci počtu primitiv ve výsledném objektu. Např. všechny části modelů, které nepoužívají žádnou texturu jsou sloučeny do jednoho primitivu a jejich difusní složka původních materiálů je uložena ve výsledném primitivu pro každý vrchol. V budoucnu by se měla do konvertoru integrovat některá z existujících knihoven pro generování trojúhelníkových pásů (triangle strip) ze stávajícího neefektivního seznamu trojúhelníků (triangle list) a open source Normal Mapper od firmy ATI pro automatické generování normálových map. 7

16 3 Grafika Tato kapitola se zabývá výhradně grafickou částí vytvořeného enginu. V podkapitole 3.1 Světlo je rozebrán Phongův osvětlovací model a hlavně způsoby jakými ho lze implementovat na dnešních grafických kartách. Podkapitola 3.2 Stíny je věnována technikám, které lze použít v aplikacích běžících v reálném čase pro tvorbu stínů. Především se zaměřuje na implementovanou techniku stencilových stínů. Podkapitola 3.3 Efekty vysvětluje výhody použití této schopnosti DirectX Graphics a demonstruje je na příkladu pokročilejšího implementovaného efektu. 3.1 Světlo Využití světla má v dnešní počítačové grafice velice důležitou roli. Osvětlení (lighting) přináší zásadní informaci o tvaru objektů, stíny (viz. kapitola 3.2 Stíny) usnadňují vnímání vzájemné polohy objektů. Hlavním cílem není vytvořit reálný osvětlovací model, ale především co nejkvalitnější vizuální výsledek. Standardně používaným lokálním osvětlovacím modelem je dnes Bui-Tuong Phong model, kde je světlo složeno ze tří základních složek odražených od povrchu tělesa: okolní světlo (ambient), difusní složka (diffuse) a takzvané odlesky (specular). Výsledná barva povrchu objektů vznikne modulací původní barvy intenzitou osvětlení (koeficientem osvětlovacího modelu), případně ještě barvou světla Ambientní světlo Obr : Model města osvětlený pouze ambientní složkou světla: a) Intenzita světla, b) Výsledná barva povrchu. Ambientní složka vzniká odrazem ambientního světla, což je světlo přicházející ze všech směrů se stejnou intenzitou. Samotné ambientní světlo vzhledem ke své povaze 8

17 nezajistí plastické zobrazení objektů ve scéně, ale je užitečné ve spojení s dalšími složkami. Protože se konstantě přičítá k výsledné intenzitě osvětlení, odstraňuje se jeho použitím vznik absolutně tmavých částí objektů Difusní světlo Obr : Model města osvětlený pouze difusní složkou světla: a) Intenzita světla, b) Výsledná barva povrchu. Difusní složka světla vytváří výsledný plastický vzhled objektů. Je nezávislá na úhlu pohledu na daný objekt. Její výpočet je založen na Lambertově zákoně: I = k d I L cos ϕ kd I L NL, kde I L je intenzita světelného zdroje, L je vektor směřující d = z bodu povrchu, pro který se intenzita počítá, ke zdroji světla a N je normálový vektor povrchu v tomto bodě. Oba vektory musí být normalizované. ϕ je úhel, který tyto dva vektory svírají. k d je koeficient difusního odrazu (vlastnost materiálu povrchu). Obr : Výsledné osvětlení složené z ambientní a difusní složky: a) Intenzita světla, b) Výsledná barva povrchu. 9

18 Obr : Vektory pro výpočet a) Difusní složky světla, b) Zrcadlové složky. Zdroj: Klaus Mueller Scientific Visualization Odlesky Odpovídají odrazům na lesklých objektech. Přidávají další stupeň realističnosti do scény. Na rozdíl od difusní složky závisí na úhlu pohledu na daný objekt. Ideálně odrazivé těleso odráží světlo pouze ve směru vektoru R, viz. Obr Ve Phongově osvětlovacím modelu se používá odraz v kuželu okolo tohoto vektoru, se šířkou danou tzv. Phongovým exponentem. Výsledná intenzita je dána vztahem: I ) ns ns S = k S I L (cos α ) = k s I L ( ER, kde S Phongův koeficient. k je koeficient zrcadlového odrazu a ns je Obr : a) Intenzita zrcadlového odrazu, b) Výsledné osvětlení (složení všech tří složek světla) Realizace Phongova modelu grafickými kartami Phongův osvětlovací model je z hlediska grafických API (DirectX, OpenGL) kompletně začleněn do standardní vykreslovací pipeline (fixed function pipeline), umožňující definovat způsob vykreslení pouze na základě nastavení sady parametrů (render state). Lze ho ale samozřejmě realizovat také s pomocí shaderů (programmable pipeline) a tím získat neomezené možnosti jeho modifikace. 10

19 Osvětlení a většina dalších výpočtů se obvykle počítá v zobrazovacím prostoru (eye-space), do kterého jsou vrcholy z lokálního souřadnicového systému transformovány maticí, vzniklou vynásobením transformační matice do světových souřadnic (world-space coordinates) s pohledovou maticí (view matrix). Použití zobrazovacího prostoru je pouze konvence, osvětlovací model lze stejně efektivně počítat již ve světovém prostoru (world-space). Důvodem je zřejmě to, že v OpenGL se standardně (na rozdíl od DirectX) world-space vůbec nepoužívá. Ve vytvořeném enginu se výpočet osvětlení provádí ve world-space, jelikož umístění objektů v tomto prostoru odpovídá jejich reálným pozicím (nezávislým na umístění kamery) a použité algoritmy jsou proto intuitivnější. Vlastní způsob výpočtu osvětlení závisí na druhu světelného zdroje. Fixed function pipeline používá tři druhy světelných zdrojů: směrové (directional light), bodové (point light) a jeho nadstavbu kuželové (spotlight) světlo. Ve vytvořeném enginu byla implementována pouze nejméně výpočetně náročná varianta směrové světlo. To je specifikováno kromě vlastností společných všem světlům (barva ambientní, difusní a zrcadlové složky) pouze směrovým vektorem. Dalším zásadním faktorem, ovlivňujícím jak způsob výpočtu, tak jeho náročnost a výslednou vizuální kvalitu, je zda se bude výpočet osvětlení provádět na úrovni zpracování vrcholů (per-vertex lighting) nebo až při zpracovávání vykreslovaných pixelů (per-pixel lighting) Výpočet osvětlení na úrovni vrcholů (per-vertex lighting) Jedná se o klasický, dnes už stále méně používaný způsob, jehož výhodou je potenciálně nižší náročnost oproti metodě per-pixel lighting. V závislosti na parametrech světla a velikosti vykreslovaných trojúhelníků objektů může ale ve výsledném obraze vzniknout řada vizuálních artefaktů. Princip spočívá ve výpočtu osvětlení pouze pro každý vrchol daného objektu ve vertex shaderu a výsledné osvětlení jednotlivých pixelů při vykreslování trojúhelníků spočítat jednoduchou interpolací hodnot osvětlení vrcholů příslušného trojúhelníku. Pro určení osvětlení vrcholů musí být pro každý vrchol definována normála povrchu Určení difusní složky světla Nejprve je nutné transformovat normálu vrcholu do world-space. Normály se transformují inversní transponovanou maticí původní matice (matice pro transformaci souřadnic vrcholů). Skalární součin transformované normály a směrového vektoru světla určuje intenzitu difusní složky (Lambertův zákon). Předpokládáme zde, že směrový vektor světla a původní normála byly normalizované, a že transformace jednotkovou velikost normály zachovala (neobsahuje změnu měřítka). 11

20 Určení zrcadlové složky světla Pro výpočet se většinou místo vektoru R (viz. Obr b) používá tzv. half vektor (viz. Obr a), který je normalizovaným součtem vektorů L a E. Obr : a) Half vector pro výpočet zrcadlové složky světla, b) Kvalita zrcadlového odrazu v závislosti na Phongově exponentu Zdroj: Klaus Mueller Scientific Visualization Pokud můžeme počítat s dostatečnou vzdáleností kamery od objektu, je možné zavést zjednodušení, kdy se vektor E (směřující z daného vrcholu objektu do výchozího bodu kamery) nahradí pro všechny vrcholy pouze obráceným vektorem směru pohledu kamery. Vektory L i E jsou potom nezávislé na daném vrcholu, a proto se nemusí výpočet half vektoru provádět přímo ve vertex shaderu. Intenzitu zrcadlové složky určíme tedy pomocí normalizovaného half vektoru, který je ve světových souřadnicích, a normály vektoru transformované do world-space podle vztahu: I ) ovlivňuje vlastnosti odrazu. ns S = ( HN. Na Obr b je vidět jak hodnota Phongova exponentu Určení výsledného osvětlení Výsledná intenzita osvětlení je součet všech tří složek vynásobených příslušnými materiálovými koeficienty daného povrchu: I = k I + k I + k I Stínování (shading) Je proces určení osvětlení pro jednotlivé pixely vykreslovaného trojúhelníku z hodnot osvětlení jeho vrcholů. Nejjednodušším způsobem je konstantní stínování (flat shading), kdy je pro všechny pixely použita hodnota osvětlení jednoho z vrcholů. Toto řešení však u křivých ploch zvýrazňuje umělé hrany, viz. Obr a. Podstatně lepší vizuální výsledky (zvláště pro difusní složku světla) dosahuje spojité stínování (Gouraud shading), kdy je osvětlení pixelu určeno lineární interpolací hodnot osvětlení vrcholů daného trojúhelníka, viz. Obr b. a a d d s s 12

21 Obr : Stínování: a) konstantní, b) interpolací odstínů vrcholů. Ani Gouraudovo stínování však není ideálním řešením. Hlavně při jeho použití pro lesklé povrchy (s výraznou zrcadlovou složkou) vznikají značně nerealistické vizuální výsledky, viz. Obr a. Obecně je kvalita per-vertex osvětlení závislá na velikosti Obr : Výpočet osvětlení: a) per-vertex, b) per-pixel Zdroj: António Ramires Fernandes Directional Light per Pixel vykreslovaných trojúhelníků ve výsledném obraze. Zmenšování jejich velikosti (použitím detailnějších modelů objektů) však může výrazně zhoršit výkon výsledné aplikace. Tuto závislost odstraňuje metoda výpočtu osvětlení pro každý vykreslovaný pixel (per-pixel lighting) Výpočet osvětlení na úrovni pixelů (per-pixel lighting) Všechny výše uvedené problémy per-vertex osvětlení lze odstranit použitím detailních modelů s vysokým počtem trojúhelníků (tzv. high resolution models), což je však z hlediska výkonu pro aplikace běžící v reálném čase neúnosné. Základní myšlenka per-pixel osvětlení proto spočívá v uložení všech detailů high resolution modelu do textur (tzv. normal map) a použití těchto textur pro výpočet osvětlení na úrovni pixelů při vykreslování klasického modelu s nízkými detaily. Výsledný obraz poté budí dojem, že použitý model je stejně detailní jako daný high resolution model (kromě jeho obrysů) Vytváření normálových map Jedním ze způsobů je použít k vytvoření normálových map klasické bump mapy nebo výškové mapy. Při konverzi bump mapy na normálovou mapu dostaneme při 13

22 vykreslení daného objektu stejný výsledek jako s původní bump mapou. Rozdíl je ovšem v tom, že nyní nemusí být osvětlení statické, jelikož je počítáno v každém snímku v pixel shaderu, a proto je možné měnit natočení objektu, či směr světla. Obr : Vytváření normálových map z bump map. Zdroj: Ben Cloward Creating and using normal maps Pro konverzi bump map na normálové mapy existuje řada nástrojů: např. DDS plugin pro Photoshop od firmy NVIDIA. Tento přístup lze použít i v kombinaci s technikou uvedenou níže, pokud chceme vytvořit iluzi dalších detailů, které nejsou ani v high resolution modelu. Pro další způsob tvorby normálové mapy je nutné mít k dispozici kromě nízko polygonového modelu (tzv. working model), který bude používán pro vykreslování ve výsledné aplikaci, ještě jeho detailní ekvivalent (tzv. reference model). Vrcholy pracovního modelu musí mít definovány kromě souřadnic a normál též sadu texturovacích souřadnic, která se bude používat pro mapování vygenerované normálové mapy a generovací algoritmus, proto musí tyto texturovací souřadnice znát. Obr : a) Low resolution model, b) High resolution model, c) Normal map Zdroj: Dave Gosselin ATI Normal mapper tool Pro každý bod (texel) vytvářené textury namapované na pracovní model je vysílán paprsek ve směru normály povrchu pracovního modelu (přesněji interpolované normály z normál vrcholů daného trojúhelníku, viz. Obr a. Výsledná normála uložená do tohoto texelu je interpolovaná normála toho trojúhelníku referenčního modelu, jehož 14

23 průsečík s vysílaným paprskem je nejblíže od bodu povrchu pracovního modelu, ze kterého byl vysílán paprsek. Obr : a) Princip vysílání paprsků, b) Problém nesdílené normály, c) Sdílená normála Zdroj: Dave Gosselin ATI Normal mapper tool Tento průsečík samozřejmě může být nad i pod povrchem pracovního modelu. Většinou se nepoužívá jen jeden paprsek, ale více paprsků ležících v kuželu okolo interpolované normály, a výsledná normála daného texelu je potom vytvořena kombinací normál vrácených jednotlivými paprsky. Tímto přístupem se odstraňují ostré přechody normál ve výsledné normálové mapě. Pracovní model by neměl obsahovat žádné ostré hrany, jejichž vrcholy mají nesdílené normály, protože v tomto případě dochází k vynechání částí detailů z referenčního modelu, viz. Obr b. Pro generování normálových map tímto způsobem lze použít open source nástroj Normal Mapper Tool od ATI, nebo komplexnější aplikaci Melody od firmy NVIDIA s grafickým uživatelským rozhraním, umožňující také generování LOD Formát normálových map Normálová mapa je klasická textura, v RGB hodnotách jejích texelů je ale uložen směr příslušného normálového vektoru. Protože jsou normály normalizované, může se velikost jednotlivých složek vektoru pohybovat pouze v rozmezí -1.0 až 1.0. Tento interval reálných hodnot je namapován na interval diskrétních hodnot 0 až 255 (-1.0 na 0, 15

24 1.0 na 255). Důležitým faktorem z hlediska možností a způsobu použití normálových map je volba prostoru (souřadnicového systému), ve kterém jsou souřadnice normál. Nejpoužívanějšími druhy normálových map jsou mapy s normálami v objektovém prostoru (object space normals) a v tangentovém prostoru (tangent space normals) Normály v objektovém prostoru (object space normals) Výpočet osvětlení je prováděn v pixel shaderu v objektovém prostoru, do kterého je nutné transformovat směrový vektor světla. Tento transformovaný vektor je samozřejmě pro všechny vrcholy objektu stejný, proto není potřeba provádět žádné další operace ve vertex shaderu, ani pro každý vrchol specifikovat další informace (na rozdíl od normál v tangentovém prostoru). Nevýhodou tohoto přístupu je nemožnost provádět animace či deformace (obecně změnu polohy vrcholu) ve vertex shaderu při zachování korektního výpočtu osvětlení. Další nevýhodou je větší náročnost na velikost výsledné normálové mapy, jelikož pokud je model složen z ekvivalentních částí (pouze posunutých a zrotovaných, např. pokud je zrcadlově symetrický) nemohou být tyto ekvivalentní části namapovány na stejnou část textury, protože jejich výsledný obraz v normálové mapě bude kvůli rotaci odlišný. To znamená například pro zrcadlově symetrický objekt nutnost dvojnásobné plochy textury (nebo snížení detailu normálové mapy) než při použití normál v tangentovém prostoru. Tato technika byla pro svou jednoduchost a rychlost implementována do vytvářeného enginu (viz. kapitola Implementace), dnes se však kvůli nevýhodám uvedeným výše používají spíše normálové mapy v tangentovém prostoru Normály v tangentovém prostoru (tangent space normals) Tangetový prostor je lokální souřadnicový systém, definovaný pro každý vrchol. Jeho bázi tvoří tangenta ve směru první souřadnice namapované normálové mapy, binormála daného vrcholu (vektorový součin normály a tangenty) a normála. Obr : Báze tangentového prostoru (U tangenta, V binormála, W - normála) Zdroj: Chris Maughan All the polygons you can eat. 16

25 Obvykle se pro vrcholy objektů předpočítává pouze normála a tangenta. Binormála je poté počítána vektorovým součinem těchto dvou vektorů přímo ve vertex shaderu. Důvodem je ušetření paměti nutné pro uložení binormály pro každý vrchol. Vektor o souřadnicích (0, 0, 1) v tomto souřadnicovém systému odpovídá normále vrcholu a do normálové mapy je uložen jako barva (128, 128, 255), proto v normálových mapách v tangentovém prostoru převažují odstíny (mírně modifikovaná normála vrcholu) této modré barvy, viz. Obr c. Výpočet osvětlení v pixel shaderu lze provádět buď v tangentovém nebo objektovém prostoru (nutná transformace normály do tohoto prostoru). V prvním, častěji používaném případě, se musí ve vertex shaderu transformovat směrový vektor světla do tangentového prostoru pomocí matice, jejíž tři řádky jsou tvořeny tangentou, binormálou a normálou ve světovém souřadnicovém systému. Vlastní výpočet osvětlení v pixel shaderu je pak prakticky stejný jako v případě normálových map v objektovém prostoru, viz. kapitola Implementace. Výhodou normálových map v tangentovém prostoru je, že tento lokální souřadnicový systém, jehož báze se počítá ve vertex shaderu, je možné ve vertex shaderu rotovat (např. vlivem deformací) při zachování korektního výpočtu osvětlení. Další výhodou je, že stejné části modelu (pouze zrotované) mohou být namapovány na stejnou část normálové mapy, protože jejich normály v tangentovém prostoru budou totožné. Nevýhodou je nutnost mít v paměti pro každý vrchol navíc minimálně jeho tangentu (případně i binormálu) a pomalejší vertex shader, jelikož je v něm navíc nutné provést tyto operace: transformace tangenty do světového souřadného systému, výpočet binormály, transformace směrového vektoru světla do tangentového prostoru Implementace Ve vytvořeném enginu byly použity normálové mapy v objektovém prostoru, vygenerované pomocí programu Normal Mapper Tool, který je open source, takže by bylo možné začlenit ho do vytvořeného konvertoru 3ds souborů, a tím zautomatizovat celý proces jejich tvorby. Texturovací souřadnice pro normálové mapy byly vygenerovány v 3D Studiu Max pomocí unwrap modifikátoru, umožňujícího dosáhnout požadovaného neopakování se textury. Takto vygenerované souřadnice obvykle nelze použít pro mapování klasické textury (definující difusní barvu daného povrchu), proto pokud je tato textura také použita, je nutné mít pro každý vrchol dvě sady texturovacích souřadnic. Hlavním problémem normálových map je jejich velikost, aby totiž jejich použití přineslo kvalitnější vizuální výsledek než per-vertex osvětlení, je nutné aby na každý trojúhelník daného modelu bylo namapováno více texelů normálové mapy (při jednom je výsledek stejný jako při použití per-vertex osvětlení). Jejich počet nemusí být nutně odvozený pouze od velikosti plochy daného trojúhelníku, ale závisí na tom jak jemné detaily chceme pro danou plochu vytvářet. Malé detailní části (např. zrcátka u auta), které 17

26 jsou obsaženy i v pracovním modelu, je lepší vykreslovat pomocí klasického per-vertex osvětlení a ušetřit tak místo ve výsledné normálové mapě. Obr : Normálové mapy: a) kolo auta, b) karoserie auta (4x zmenšeno) Pokud je textura s normálovou mapou aplikována při vykreslování s bilineárním filtrováním, je nutné aby mezi jednotlivými spojitými částmi v normálové mapě (tzv. charts) byly mezery, které jsou vyplněny kombinací barev texelů z okraje nejbližší části. Na Obr c je normálová mapa před vyplněním těchto mezer a Obr ukazuje již vyplněné mezery. Tento přístup zajišťuje, aby výsledná normála při bilineárním filtrování nebyla určena kombinací normál (texelů v normálové mapě) z odlišných nesouvislých částí. Problém nesouvislých částí ještě zhoršuje mipmapping, který je pro normálové mapy v objektovém prostoru prakticky nepoužitelný, u normálových map v tangentovém prostoru nejsou výsledné artefakty vzniklé kvůli mipmappingu tak výrazné. Obr : a) Normálová mapa aplikovaná jako klasická textura, b) Per-pixel osvětlení na základě této normálové mapy. 18

27 3.1.7 Per-vertex versus per-pixel metody Většinu algoritmů prováděných standardně na úrovni vrcholů (ve vertex shaderu), lze implementovat na úrovni pixelů. Jediným problémem je značně omezená instrukční sada pixel shaderu (hlavně u verze) a menší maximální možný počet instrukcí tvořící pixel shader program oproti vertex shaderu. Princip převodu obecných metod z vertex shaderu do pixel shaderu je podobný jako u Phongova osvětlovacího modelu, na kterém byla v předchozí kapitole tato transformace vysvětlena. Obr : a) Exponenciální funkce pro výpočet zrcadlové složky, Stěny ve směru b) kladné, c) záporné osy X cube texture pro normalizaci vektoru. Vlastní implementace algoritmu v pixel shaderu se někdy právě kvůli omezené instrukční sadě dosti liší od původního vertex shader programu. Například při výpočtu zrcadlové složky světla v pixel shaderu verze musí být chybějící instrukce pro výpočet exponenciály nahrazena buď opakovaným násobením anebo použitím další textury, jejíž příslušné texely mají hodnoty odpovídající požadované funkci. Do textur lze ukládat funkce jedné až tří proměnných. Proměnné jsou texturovací souřadnice a funkční hodnotě odpovídá hodnota příslušného texelu. Do každého kanálu textury lze proto uložit jinou funkci. Pro tři proměnné se používají tzv. cube texture textury složené z šesti dvourozměrných textur, do kterých se přistupuje pomocí třírozměrných texturovacích souřadnic. Jejich uspořádání vzhledem k texturovacím souřadnicím si lze v prostoru představit jako krychli. V současné době vše směřuje k masivnímu využívání již relativně robustních pixel shaderů. S ohledem na tuto skutečnost jsou navrhovány i moderní grafické karty, u nichž je většinou hlavní prioritou maximální výkon vykreslovací pixel pipeline (oproti dřívějšímu zaměření na transformační vertex pipeline). S tím jak se zvyšuje náročnost pixel shaderů a tím doba vlastního vykreslení výsledných pixelů trojúhelníků, lze zároveň relativně zvyšovat počet trojúhelníků tvořících modely, jelikož toto zpomaluje pouze vertex pipeline a při vykreslování dané části modelu (tzv. primitiva, či mesh část vykreslená s jedním nastavením rendrovacích stavů, během jejíž transformace a vykreslování fungují obě pipeline paralelně) by se jinak zbytečně čekalo na provedení pixel pipeline (tzv. fill-bound mesh, opačný případ je tzv. 19

28 transform-bound mesh, kdy pixel pipeline zbytečně čeká na transformované vrcholy). Z hlediska výsledného výkonu je optimální vyvážená zátěž obou pipeline při vykreslování daného primitiva. Toho ovšem obecně nelze docílit na úrovni tvorby grafických modelů, jelikož náročnost provedení v pixel pipeline závisí na počtu vykreslovaných pixelů daného primitiva a tím tedy na jeho vzdálenosti od kamery. Používaná technika, která se vyváženému stavu přibližuje volbou verze vykreslovaného modelu podle jeho vzdálenosti od kamery je LOD (level of detail), viz. kapitola Úroveň detailu (LOD). 3.2 Stíny Stíny hrají důležitou roli při prostorovém vnímání člověka. Pomáhají pochopit vzájemné rozmístění objektů, jejich tvar a rozměry a poskytují informaci o vlastnostech a poloze zdrojů světla. V počítačové grafice se proto techniky vytvářející stíny stávají důležitým prostředkem pro zvýšení věrohodnosti a realističnosti zobrazované scény. Globální zobrazovací metody (např. metoda sledování paprsku) jsou však pro použití v aplikacích zobrazujících scénu v reálném čase stále příliš výpočetně náročné, proto se zde používají jiné techniky, které nejsou založeny na fyzikální podstatě šíření světla a v hojné míře využívají schopností moderních grafických karet. Tato kapitola se zabývá pouze technikami používanými v současnosti pro dynamické stíny, statické stíny je možné předpočítat (např. pomocí metody sledování paprsku) a uložit do světelných map (lightmap), které jsou poté při zobrazování scény kombinovány s klasickými texturami. Výhodou této techniky je výkonová nenáročnost nezávislá na počtu a typu statických světelných zdrojů ve scéně a minimální požadavky na schopnosti grafické karty (pouze podpora multitexturingu) v porovnání s jakýmikoliv technikami dynamických stínů. Světelné mapy se obvykle slučují do texturovacích atlasů. Velký počet těchto map, které je nutné mít k dispozici pro rozsáhlé scény, je kompenzován tím, že stačí mít tyto atlasy v daleko menším rozlišení oproti klasickým texturám reprezentujícím detaily povrchu. Světelné mapy mohou být buď pouze černobílé, v takovém případě lze do každého ze tří nebo čtyř kanálů textury uložit jinou mapu, nebo lze využívat více kanálů pro jednu mapu, pro dosažení pokročilejších efektů. Některé robustní nástroje pro tvorbu 3D scén (např. 3D Studio Max, Maya) obsahují komfortní rozhraní pro automatické generování těchto map. Obr. 3.2: Příklad použití světelných map. Zdroj: Kurt Miller Lightmaps (Static Shadowmaps) 20

29 Technika světelných map nebyla v aplikaci CityRider použita, jelikož se předpokládá budoucí použití generátoru Martina Bašty pro dynamické generování města a není tedy možné z výkonnostních důvodů zakomponovat do něj některou z technik pro vytváření světelných map. Nicméně vytvořený engine obsahuje všechny prvky (formáty vrcholů s více texturovacími souřadnicemi a efekty pro multitexturing) potřebné pro použití světelných map, viz. kapitola 3.4 Multitexturing. V současnosti lze pozorovat jasný trend směrem k masovému využívání dynamických stínů a to nejen již klasických technik projekčních a stencilových stínů ale i pokročilejších metod pro generování realističtějších hladkých stínů (soft shadows). Velice důležitým faktorem věrohodnosti výsledné scény je konzistence celkového osvětlovacího modelu, který většinou vzniká kombinací několika technik. Robustní moderní grafické enginy (např. Ogre, Nebula Device 2) se toho snaží dosáhnout maximální transparentností použití osvětlení vzhledem k uživateli. Proto uživatelem definovaný světelný objekt je v závislosti na dalším nastavení využíván jak pro klasické osvětlení, tak pro vrhání stínů. Ogre tímto způsobem standardně podporuje projekční texturové (SHADOWTYPE_TEXTURE_MODULATIVE) a stencilové stíny. Přičemž stencilové stíny jsou implementovány dvěma způsoby: SHADOWTYPE_STENCIL_MODULATIVE a : SHADOWTYPE_STENCIL_ADDITIVE, které se liší způsobem zpracování více světel. Při použítí druhého náročnějšího způsobu je každé světlo vykreslováno zvlášť jedním průchodem. Výsledné stíny jsou poté vytvořeny součtem stínů vržených jednotlivými světly. Do vytvářeného enginu byla implementována technika stencilových stínů, proto se jí bude podrobně zabývat následující kapitola Stencilové stíny Techniku založenou na objemových stínech poprvé představil Frank Crow v roce Tim Heidmann později ukázal jak využít stencil buffer pro implementaci objemových stínů a tím bylo poprvé možné použít tento přístup v aplikacích běžících v realném čase. Jeho metoda (dnes známa jako z-pass) ale není použitelná, pokud se kamera nachází ve stínu. První skutečně komplexní implementace stencilových stínů, řešící tento problém je z-fail metoda, kterou proslavil John Carmack (je proto někdy nazývána Carmack s Reverse). Nevýhodou tohoto algoritmu je nižší výkon (uvádí se až o 80%) ve srovnání se z-pass technikou. Proto vznikly některé modifikace z-pass algoritmu (např. ZP+: correct Z-pass stencil shadows) odstraňující problém kamery ve stínu, ale snažící se zachovat původní výkon. Základní myšlenkou algoritmu objemových stínů, je vytvoření tzv. stínového tělesa pro každý ze stínících objektů. Jak ukazuje obrázek, stínové těleso (též stínový objem) ohraničuje část prostoru ve scéně, ze kterého není přes stínící objekt světelný zdroj videt, a vymezuje tak zdrojem neosvětlený prostor. Stínové těleso je potřeba vytvořit pro každý ze stínících objektů. Pro jeho konstrukci je nejprve nutné určit 21

30 obrysové hrany (tzv. silhouette edges) vzhledem k aktuální poloze tělesa vůči zdroji světla. Vytváření stínových těles ze siluety není nutnou podmínkou, je možné vytvořit stínový objem pro každou (ke světlu přivrácenou) plochu objektu, čímž se však zvyšuje počet trojúhelníků tvořících hraniční reprezentaci výsledného stínového tělesa a v důsledku toho se zhoršuje čas potřebný pro jeho vykreslení. Obr : a) Obálky objektů použité pro konstrukci stínových těles, b) Stínová tělesa Implementace Pro každý objekt je možné v jeho příslušném 3D souboru definovat, zda daná úroveň detailu vrhá stín. Přičemž lze specifikovat tři možné varianty chování vzhledem ke konstrukci stínů: 1) standardní objekt (přesněji jeho daná úroveň detailu) vrhá stín sám na sebe a zároveň přijímá (jsou na něj vrhány) stíny od ostatních objektů. 2) nepřijímající objekt pouze vrhá stín. 3) nevrhající stín sám na sebe (not selfshadow) objekt příjímá stíny od ostatních objektů, ale sám vrhá stín jen na ně, ne sám na sebe. Stíny se nemusí vytvářet z grafické reprezentace dané úrovně detailu, ale je mozné specifikovat zjednodušenou obálku tělesa, která bude využívána pro konstrukci stínů. Použitá obálka musí být uzavřená (nesmí obsahovat díry), pro každou její hranu pak platí, že je sdílená právě dvěma trojúhelníky (nutné pro algoritmus hledání obrysu). Pokud pro nějakou úroveň detailu určíme, že má vrhat stín, je nutné aby daný objekt měl specifikované svoje ohraničující těleso (viz. kapitola Ohraničující těleso), které je využíváno pro efektivnější určení viditelnosti stínu a také v algoritmu na odstranění problému kamery ve stínu. Při vlastním vykreslování objektu se nejprve určí použítá úroveň detailu (vzhledem ke vzdálenosti od kamery), a pokud tato úroveň vrhá stín, zjistí se, zda je stín viditelný. Detekce viditelnosti stínu používá ohraničující těleso stínu, vytvořené algoritmem konstrukce stínového tělesa (viz. kapitola Konstrukce stínového tělesa) aplikovaného na ohraničující těleso objektu. Pokud je stín viditelný a nenachází se 22

31 v něm kamera (viz. kapitola Odstranění problému kamery ve stínu) vytvoří se stínové těleso Algoritmus určení obrysu tělesa Stínové těleso vznikne protažením obrysu objektu (vzhledem k jeho poloze vůči zdroji světla) ve směru světelných paprsků. Prvním krokem je tedy nalezení obrysu (siluety) daného objektu. Silueta je tvořena hranami objektu, jejichž normály přilehlých trojúhelníků mají opačný směr vzhledem ke směru světla. Seznam těchto hran vytvoříme procházením všech trojúhelníku objektu, přičemž zjišťujeme, zda daný trojúhelník leží na osvícené nebo odvrácené straně objektu. Toto určíme pomocí skalárního součinu směru světla a normály trojúhelníku. Pokud je součin kladný (odvrácený trojúhelník), přidáme všechny hrany trojúhelníku do vytvářeného seznamu hran. Při přidávání se kontroluje, zda se již daná hrana v seznamu nenachází, a pokud ano, je ze seznamu vyjmuta (oba její přilehlé trojúhelníky byly odvrácené, proto tato hrana není součástí hledaného obrysu). Ve vytvářeném seznamu hran proto po projití všech trojúhelníků objektu zůstanou jen ty hrany, které byly přidávány pouze jednou (jen jeden z jejich přilehlých trojúhelníků je odvrácený) a tyto hrany tvoří hledaný obrys. Algoritmus samozřejmě stejně tak funguje při přidávání hran osvícených trojúhelníků. Tento přístup nevyužívá žádných pomocných datových struktur, proto jeho složitost není optimální (složitost O(počet trojúhelníků * počet obrysových hran) kvůli nutnosti procházet vždy při přidávání nové hrany celý již vytvořený seznam hran). Ideální řešení (složitost O(počet hran)) je vytvořit si při načítaní daného objektu seznam všech jeho hran, obsahující pro každou hranu dva indexy jejích vrcholů a dvě normály jejích přilehlých hran, a poté při hledání obrysu pouze projít tento seznam, spočítat skalární součiny směru světla s oběmi normálami, a pokud jsou opačné, je tato hrana obrysová Konstrukce stínového tělesa Z obrysových hran vznikne stínové těleso jejich protažením ve směru paprsků světla: pro každou hranu vytvoříme jeden čtyřúhelník (přesněji dva trojúhelníky), jehož vrcholy budou dva vrcholy dané hrany a dva vrcholy vzniklé posunutím těchto vrcholů ve směru světla. Tímto postupem vznikne pouze tzv. plášť stínového tělesa, jeho uzávěry není potřeba vytvářet (při použití z-pass verze vykreslování stínů). Velikost protažení (a tím velikost vytvářených trojúhelníků) je vhodné minimalizovat, aby se zmenšila doba potřebná pro vykreslení stínového tělesa. Zároveň ale musí být tak velká, aby vytvářené stínové těleso pokrylo všechny objekty, které jsou daným objektem zastíněny. Vytvořený engine určuje velikost protažení (délku stínu) pomocí nejvyššího bodu ohraničujícího tělesa objektu (nejvyšší = bod s největší y-ovou souřadnící: předpokládá se, že y-ová souřadnice paprsků světla bude vždy záporná) tak, že nový bod vzniklý posunutím tohoto nejvyššího bodu o výsledné prodloužení, bude mít nulovou y-ovou souřadnici (předpokládá se, že minimální y-ová souřadnice vrcholů objektů, na které dopadá stín je nulová). 23

32 Před samotným vytvářením trojúhelníků stínového tělesa jsou všechny vrcholy hran obrysu transformovány z lokálního souřadnicového systému daného objektu do světových souřadnic. Vzniklé trojúhelníky (ve světových souřadnicích) stínových těles všech objektů vrhajících stín jsou poté přidávány do společného zásobníku. Tato transformace se provádí kvůli efektivnějšímu vykreslování stínových těles. Ty by měly mít řádově desítky až stovky trojúhelníků a nebylo by proto vhodné vykreslovat každé stínové těleso zvlášť, pokud by totiž vytvořené trojúhelníky byly netransformované (v původních lokálních souřadnicích daného objektu), bylo by nutné před vykreslením každého stínového tělesa změnit transformační matici Optimalizace Konstrukce stínových těles, vykonávaná pouze procesorem, je úzkým hrdlem algoritmu stencilových stínů, proto je více než vhodné nevytvářet stínová tělesa z původní grafické reprezentace objektu, ale z její zjednodušené obálky. Tím ovšem vznikne řada vizualních artefaktů, především pokud daný objekt vrhá stín sám na sebe a trojúhelníky grafické reprezentace se prolínají s trojúhelníky použité zjednodušené obálky. Běžně používaným kompromisním řešením těchto artefaktů, je nepoužívat vrhání stínu sama na sebe (přesněji zavedení techniky objektů tzv. nepřijímajících stíny, které stíny pouze vrhají, ale na které nejsou vrhány). Toho lze dosáhnout jednoduše tak, že nejdříve vykreslíme všechny objekty, na které jsou stíny vrhány, poté vykreslíme vlastní stíny a nakonec všechny objekty nepřijímající stíny. V takto vykreslené scéně ovšem dané objekty sice nevrhají stíny samy na sebe, ale ani okolní objekty je nezastiňují. Proto moderní grafické enginy zavádějí rozdělení objektů vrhajících stíny do tříd, kdy objekty z dané třídy vrhají stíny pouze na objekty okolních tříd, ne na sebe navzájem, čehož je dosaženo vykreslováním stínů pro každou třídu zvášť. Stínové těleso daného objektu je nutné znovu vytvořit, pouze pokud došlo ke změně polohy (či rotace) objektu, nebo pokud došlo ke změně polohy světla (či jeho směru u směrových světel), ne tedy nutně znovu v každém snímku. Stencilové stíny se ovšem většinou používají pro pohybující se objekty (nebo pro všechny objekty ve scénách s pohyblivým světlem), v některých případech je ale i zde možné použít další optimalizační metodu a tou je aktualizace stínů jen daný početkrát za vteřinu. Tato hodnota, nemusí být konstantní a pro všechny objekty stejná, ale může se odvozovat např. z velikosti změny polohy a hlavně rotace daného objektu od jeho polohy a rotace při posledním výpočtu jeho stínového tělesa. Další nevýhodou počítání stínových těles na procesoru je nemožnost modifikovat pozice vrcholů ve vertex shaderu (např. při animacích pomocí techniky vertex skinning), jelikož algoritmus musí znát finální pozice vrcholů. Tento problém odstraňuje schopnost moderních grafických karet (nutná podpora vertex shader 2.0) vytvářet stínová tělesa přímo ve vertex shaderu (technika Shadow volume extrusion). 24

33 Implementované způsoby tvorby stínů Vytvořený engine umožňuje definovat objekty nepřijímající stíny, ale tyto objekty není možno rozdělit do více tříd. Navíc byla ale implementována modifikace konstrukce stínového tělesa určená speciálně pro objekty nevrhající stín samy na sebe. Rozdíl oproti standardnímu způsobu spočívá v tom, že stínové těleso není tvořeno pouze pláštěm, ale i tzv. horním uzávěrem, který je tvořen všemi odvrácenými trojúhelníky obálky pro konstrukci stínů (přesněji trojúhelníky vzniklými posunutím odvrácených trojúhelníků ve směru normál vrcholů o vzdálenost odvozenou od vzdálenosti objektu od kamery toto odstraňuje prolínání vykresleného stínu s původním objektem). Díky tomuto uzávěru objekt nevrhá stín sám na sebe, ale protože dále už se s ním pracuje standardně, všechny okolní objekty na něj stín vrhají. Aby ovšem tento přístup fungoval korektně, musí být obálka pro konstrukci stínů konvexní. Tato technika byla ve výsledné aplikaci použita pro konstrukci stínů všech vozidel, pro něž bylo žádoucí, aby na ně byly vrhány stíny od okolních objektů (směrové tabule atd.), ale zároveň nemohly vrhat stín samy na sebe, jelikož bylo nutné pro konstrukci stínů použít značně zjednodušenou grafickou reprezentaci. Nevýhodou nutného použití konvexních obálek pro tuto techniku je v některých případech značně nerealistický tvar stínu, na druhou stranu ale tyto obálky mohou mít daleko méně trojúhelníků než původní nekonvexní obálky. Obr : Ukázka všech typů tvorby stínů: standardní dřevěné desky, nepřijímající stín ukazatele, nevrhající stín sám na sebe vozidla Vykreslení stínů z-pass algoritmus Myšlenka, jak zobrazovat stíny ve scénách za pomoci stínových těles, je založena na vysílání testovacích paprsků ze středu promítání každým pixelem směrem k zobrazovanému povrchu ve scéně. Během cesty paprsku se počítá, kolikrát paprsek vstoupil do nějakého stínového tělesa a kolikrát jej opustil. Pokud je rozdíl těchto hodnot nenulový, znamená to, že paprsek neopustil všechna stínová tělesa, do kterých vstoupil a bod na povrchu tělesa, ke kterému dorazil, musí ležet ve stínu. Princip algoritmu si lze též představit tak, že ke kameře přivrácené plochy stínového tělesa přesouvají vše, co se nachází za nimi do stínu, zatímco odvrácené plochy jejich účinek ruší. K tomu, aby těleso 25

34 nebo jeho část ležely ve stínu, musí platit, že se nacházejí za přivrácenými a současně před odvrácenými plochami stínových těles. K rozlišení těchto situací lze využít hloubkový test. Nejprve proto vykreslíme všechny viditelné objekty (kromě poloprůhledných a stíny nepřijímajících) za pomoci paměti hloubky (z-buffer, depth-buffer). Poté jsou dvakrát vykreslena všechna stínová tělesa do stencilové paměti (stencil buffer). Poprvé jsou vykresleny pouze přivrácené plochy stínového tělesa (forward-facing polygons) přičemž jsou inkrementovány příslušné hodnoty ve stencilové paměti, poté jsou vykresleny všechny odvrácené plochy stínového tělesa (back-facing polygons) a hodnoty ve stencilové paměti jsou dekrementovány. Ve vytvořeném enginu se při vykreslování stínových těles do stencilové paměti využívá tzv. two-side stencil testu: schopnosti moderních grafických akcelerátorů provádět rozdílnou aktualizaci stencilové paměti podle toho, zda se právě zpracovává přivrácená nebo odvrácená plocha. Vykreslení stínových těles je tak realizováno pouze jedním průchodem. Normálně by se všechny inkrementované a dekrementované hodnoty vzájemně vynulovaly, ale protože byla předtím scéna vykreslena s pomocí paměti hloubky, některé pixely neprojdou hloubkovým testem. Zbylé nenulové hodnoty ve stencilové paměti odpovídají pixelům, které jsou ve stínu. Výsledný obsah stencilové paměti je proto použit jako maska pro obdélník (roztažený přes celou zobrazovací plochu), který je nakonec přímíchán (alpha-blended) k výslednému obrazu. Barva, resp. alfa složka barvy tohoto obdélníku definuje barvu resp. hustotu výsledného stínu. Obr : Problém částečně zastíněné přední ořezávací roviny pohledového tělesa a) z-pass metoda, b) z-fail, Zdroj: S. Hornus, J. Hoberock, S. Lefebvre, J. C. Hart ZP+: correct Z-pass stencil shadows Hlavní nevýhodou z-pass metody jsou nekorektní údaje ve stencilové paměti, pokud dojde k ořezání stínového tělesa přední ořezávací rovinou, viz. Obr a. 26

35 Tento problém nelze řešit např. zjištěním toho, zda se kamera nachází uvnitř stínového tělesa a následným nastavením počáteční hodnoty prvků stencilové paměti na počet takto detekovaných těles, protože kamera (přesněji její přední ořezávací rovina) se může nacházet ve stínu jen částečně, viz. Obr a a Obr b. Jelikož neexistuje komplexní řešení tohoto problému, zachovávající původní výkon z-pass algoritmu, používá se už dnes tento přístup spíše jen v aplikacích, kde k tomuto problému nedochází (např. při isometrickém pohledu na scénu). I přesto byla tato metoda použita ve vytvořeném enginu a to za účelem dosažení maximálního výkonu. Obr : a) Celá přední ořezávací rovina uvnitř stínu, b) Přední ořezávací rovina částečně ve stínu Odstranění problému kamery ve stínu Vzhledem k tomu, že scéna výsledné aplikace obsahuje relativně rozměrově malé stíny, byl problém zastínění přední ořezávací plochy vyřešen detekcí toho, zda se tato plocha nachází alespoň částečně v nějakém stínovém tělese, a pokud ano, dané stínové těleso není vykresleno do stencilové paměti. Toto je jediná část celé implementace dynamických stínů, jejíž korektnost závisí na typu výsledné scény. V zatím testovaných scénách, díky daným umístěním kamery a směru světla, nastávaly jen ojediněle situace, kdy bylo postřehnutelné náhlé zmizení stínu (jeho oříznutí). Zjištění toho, zda daným stínovým tělesem prochází přední ořezávací plocha se děje ve dvou krocích. V prvním rychlém hrubším testu je využíváno ohraničující těleso stínového tělesa. Pokud je z-ová souřadnice nějakého jeho vrcholu (transformovaného do zobrazovacího prostoru) záporná, může daným stínovým tělesem potenciálně procházet přední ořezávací plocha, a je proto nutné provést druhý přesný test (takové stínové těleso nemůže zároveň být zcela mimo pohledové těleso, jelikož by jinak bylo oříznuto již algoritmem zjištění viditelnosti). Druhý test využívá transformace odvrácených trojúhelníků stínového tělesa (odvrácených vzhledem ke směru světelných paprsků) a přední ořezávací plochy do roviny kolmé na směr světelných paprsků, čímž se daný problém převede na dvourozměrný test toho, zda vzniklý čtyřúhelník transformované přední ořezávací plochy neobsahuje (alespoň částečně) některý z transformovaných odvrácených trojúhelníků 27

36 stínového tělesa. Pokud ano, dané stínové těleso tedy není vykresleno do stencilové paměti Shrnutí Vytvořená implementace dynamických stínů je maximálně efektivní díky použití z-pass algoritmu vykreslování stencilových stínů a rychlému způsobu odstranění problému s přední ořezávací rovinou. Pro objekty nepřijímající stíny a objekty nevrhající stín samy na sebe je navíc možné počítat stínové těleso ze značně zjednodušené obálky původního objektu a tím zmenšit zátěž procesoru. Druhou stranou mince je ovšem vizuální korektnost a konzistence stínového modelu výsledné scény, která je značně problematická. Z hlediska korektnosti vytvořených stínů je jedním z problémů tvar stínů, viditelně neodpovídající skutečnosti, při použití konvexních obálek pro vytváření stínů (nutné u implementované metody pro objekty nevrhající stín samy na sebe) a také samotný způsob vykreslení masky ze stencilové paměti do scény. Ta je nyní přimíchávána (blendována) k výslednému obrazu, s váhou odpovídající alfa složce barvy stínu. To ovšem způsobí ztmavení všech částí původního obrazu, které jsou ve stínu, nezávisle na klasickém osvětlovacím modelu, se kterým byla původní scéna vykreslena. Tím dochází například k přílišnému ztmavení některých částí scény. Řešením je vykreslit všechny objekty, na které jsou vrhány stíny dvakrát, poprvé pouze s ambientní složkou osvětlení, podruhé naopak pouze s difusní a spekulární složkou. Výsledný obraz je poté složen z těchto dvou na základě stencilové masky. Části ve stínu budou vykresleny s větší váhou z prvního ambientního obrazu a nezastíněné části naopak z druhého. Nepříjemnou daní za realističtější visuální výsledek je samozřejmě téměř dvojnásobná náročnost vykreslovací části (z důvodů dvou průchodového vykreslování). Obr : Příklady nekorektnosti stínového modelu: a) difusní a spekulární osvětlení i v částech ve stínu (vozidlo), příliš tmavé části ve stínu (krabice), b) nereálný tvar stínu kvůli jeho výpočtu z konvexní obálky Konzistence výsledného osvětlovacího modelu je asi nejslabší částí vytvořených scén. Přestože je teoreticky možné, aby stíny vrhaly všechny objekty (kromě 28

37 poloprůhledných), byla tato technika použita pouze pro dynamické objekty (vozidla, krabice ) a některé menší statické (značky, ukazatele ). U statických objektů vytvářených generátorem Martina Bašty (terén, domy ) by použití dynamických stínů nebylo vhodné (nejen z výkonových důvodů), zároveň ale tuto techniku není možné nahradit jinou např. statickými světelnými mapami (kvůli potenciálnímu budoucímu dynamickému generování objektů). Přes konečné, relativně skromné použití stínů ve vytvořených scénách, je jimi hlavně u dynamických objektů zdůrazňována jejich velikost, poloha a orientace ve scéně, za cenu minimálního snížení celkového výkonu aplikace. Obr : a) Výsledná scéna bez použítí dynamických stínů, b) s dynamickými stíny 3.3 Efekty Jednou z velkých předností současné verze DirectX oproti OpenGL je podpora tzv. efektů, což je vysokoúrovňová abstrakce umožňující popsat všechny grafické efekty podporované DirectX rozhraním a to jak pomocí nastavení rendrovacích stavů (render state), tak pomocí vertex a pixel shaderů. Hlavní výhoda spočívá v tom, že je tak veškeré nastavení nutné pro vykreslení daného objektu specifikováno pouze jedním efektem, který lze navíc popsat pomocí externího textového souboru. Tento přístup maximálně odděluje specifikaci způsobu jakým se má daný objekt vykreslit (popsáno efektem) od vlastního rendrovacího procesu, kde už jen stačí zavolat příslušný efekt. Použití efektů proto snadno umožňuje přizpůsobit výslednou aplikaci schopnostem různých grafických karet, jelikož stačí vytvořit různé verze efektů pro různé grafické karty (např. verzi pro karty bez podpory shaderů, s podporou shaderů verze 1.0 atd.) a aplikaci potom poskytnout sadu efektů podporovanou na cílové stanici, bez nutnosti výslednou aplikaci jakkoliv měnit a znovu překládat. Shadery v efektech mohou být psány buď v tzv. shader assembleru, nebo pomocí vyššího programovacího jazyka HLSL (high level shader language) se syntaxí podobnou 29

38 jazyku C. HLSL byl odvozen z Cg - prvního vyššího programovacího jazyka pro shadery vytvořeného firmou NVIDIA. Efekty také umožňují definovat více průchodů (pass), pokud je nutné vykreslovat objekt víckrát pro dosažení požadovaného výsledku (např. při použití multitexturingu na grafických kartách, které nemají požadovaný počet texturovacích jednotek). Protože efekty zapouzdřují pouze nastavení prováděné před vykreslením daného objektu, je samozřejmě potřeba komplexní operace, nutné pro korektní zobrazení, prováděné s objekty na úrovní celé scény (např. setřídění všech poloprůhledných objektů podle vzdálenosti od kamery) implementovat přímo v programu. Vytvořený engine provádí nastavování stavů před vykreslením všech objektů jen s použitím příslušných efektů definovaných v externích souborech, žádné nastavení není specifikováno přímo uvnitř programu. Tento přístup poskytuje uživateli maximální volnost jak ve volbě použitého efektu pro daný objekt, tak v modifikaci již vytvořených efektů a tvorbě nových. Engine implementuje sadu proměnných, které je možné v každém efektu použít a před vlastní aplikací daného efektu nastaví aktuální hodnoty všech proměnných použitých v tomto efektu. Tyto proměnné lze rozdělit do tří skupin: 1) parametry prostředí vlastnosti světla (směrový vektor, ambientní, difusní, zrcadlová složka), vlastnosti mlhy (barva, intenzita). 2) parametry kamery projekční a zobrazovací matice, souřadnice výchozího bodu a směr pohledu kamery ve světových souřadnicích. 3) lokální parametry vykreslovaného objektu transformační matice z lokálního souřadnicového systému do světových souřadnic, sada použitých textur. Přesný seznam všech parametrů a způsob jejich použití v efektech je popsán v příloze Vytváření vlastních efektů. Příkladem pokročilejšího implementovaného efektu je efekt odlesků oblohy (skybox) na karoserii aut, kterým se zabývá následující kapitola Odlesky oblohy na karoserii aut Tento efekt byl implementován pro atraktivnější vzhled modelů aut. Vzhledem k jeho náročnosti je používán pouze u vyšších LOD aut. Základem algoritmu je výpočet reflexního vektoru, který je poté použit pro texturování modelu cube texturou oblohy (skyboxu) a Fresnelův zákon, kterým je určena intenzita odlesků oblohy. Nejprve je nutné definovat pro každý vrchol vektor povrchu P, okolo kterého se bude odrážet pohledový paprsek (vektor E normalizovaný vektor z daného vrcholu do výchozího bodu kamery). Obvykle se používá přímo normála daného vrcholu. Tento přístup ovšem pro modely aut neposkytuje kvalitní výsledky, jelikož tyto modely obsahují velké, relativně rovné plochy, které mají velmi podobné normály, a na tyto plochy je proto namapovaná jen velmi malá část cube textury, viz. Obr a. Daleko rovnoměrnější rozložení textury poskytuje mapování pomocí vektoru směřujícího ze 30

39 středu modelu k danému vrcholu, viz. Obr b. Toto mapování ale zase neodpovídá reálnému odrazu. Relativně ideálního mapování bylo dosaženo kombinací obou těchto přístupů, viz. Obr Obr : Namapování oblohy pomocí: a) Normály vrcholu, b) Vektoru směřujícího ze středu modelu k danému vrcholu. Obr : Kombinace obou metod. Tento způsob určení vektoru P je již poměrně náročný, proto by místo jeho výpočtu ve vertex shaderu bylo vhodnější ho předpočítat a uložit pro každý vrchol modelu. Tím by také bylo umožněno počítat tento vektor pro každý model jiným způsobem v závislosti na tvaru daného modelu. Výsledné reflexní mapování cube textury je prováděno pomocí vektoru R vzniklého odrazem pohledového paprsku E okolo vektoru povrchu P. Vektor R je vypočten tímto vztahem: R = E + 2P( PE), kde E i P jsou normalizované vektory ve světovém souřadném systému. Odrážet by se neměl celý skybox, ale pouze obloha. Do alfa kanálu všech textur skyboxu byla proto uložena informace o intenzitě s jakou se má daný texel přimíchávat do výsledného obrazu, viz. Obr b. Reálnějšího zobrazení lze dosáhnout tím, že celá obloha nebude mít v alfa kanálu konstantní hodnotu, ale část odpovídající obrazu slunce bude mít maximální intenzitu a zbytek oblohy hodnotu podle své světlosti. 31

40 Obr : Výsledná reflexe a) celého skyboxu, b) pouze oblohy. Obr : Jedna z textur skyboxu: a) RGB, b) alfa kanál. Posledním krokem je výpočet dalšího faktoru ovlivňujícího intenzitu přimíchávání odrazu oblohy. Obr : Intenzita odrazu pro hodnotu konstanty materiálu c a) 4.0, b)

41 Tento faktor je vypočítán pomocí Fresnelova zákona: I ) c = ( 1+ NE, kde N je normálový vektor daného vrcholu a c je konstanta materiálu povrchu (pro karoserie aut použita hodnota 4.0). Pro vrcholy daným pohledem viditelných trojúhelníků by hodnota skalárního součinu vektorů N a E měla být vždy záporná, a proto vypočtená intenzita je vždy menší než 1.0. Aplikace tohoto faktoru způsobí maximální intenzitu odrazu na vrcholech, jejichž normála je kolmá na pohledový vektor E. Obr : Výsledný efekt pro hodnotu konstanty materiálu c a) 4.0, b) Multitexturing Je v nejobecnějším smyslu proces aplikace více textur současně při vykreslování daného objektu. Díky rozšiřující se instrukční sadě nových verzí pixel shaderů se výrazně zvětšuje obor možností použití textur, a proto se také zvětšuje počet současně aplikovaných textur. Pokud daná grafická karta nepodporuje požadovaný počet textur vykreslovaných najednou (single-pass multitexturing), lze tento problém vyřešit vykreslením daného objektu víckrát a smícháním výsledných obrazů (multi-pass multitexturing), ovšem za cenu odpovídajícího výrazného snížení výkonu. Tato kapitola se dále bude zabývat pouze klasickým použitím textur pro přímou modifikaci barvy výsledného vykreslovaného pixelu (např. textury představující detaily povrchu, světelné mapy). Do těchto textur je obvykle přistupováno pomocí texturovacích souřadnic uložených pro každý vrchol modelu. Přestože je možné přistupovat k více texturám pomocí stejné sady texturovacích souřadnic, používá se spíše pro každou texturu zvláštní sada, čímž přestává být ve výsledném obraze tak nápadné opakování textur, protože může být každá z nich na objektu jinak umístěná a roztažená. Nevýhodou je ovšem větší velikost dat uložených pro každý vrchol. Ve vytvořených scénách byl zatím multitexturing použit pouze u města z generátoru Martina Bašty. Části modelu města využívají pouze jeden typ multitexturingu, kdy jsou dvě textury definující detaily povrchu vzájemně smíchány na 33

42 základě hodnot z třetí textury. I když je z této kombinující textury prakticky využíván pouze jeden kanál, nešlo tuto informaci uložit do alfa kanálu některé z textur detailu, jelikož ty mají jiné mapování. Obr Ukázka použití multitexturingu: a) Výsledný obraz, b) Použité textury (tmavá textura byla použita pro definici kombinace ostatních). Protože jsem podporu této techniky do generátoru implementoval pouze na úrovni výstupního exportu vygenerovaných objektů, kde už není k dispozici žádná globální znalost o jejich vzájemné poloze, není aktuální použití multitexturingu příliš koncepční. Přesto je výsledný vzhled scény znatelně kvalitnější než bez multitexturingu, jelikož s jeho nasazením je možné použít lepší, kontrastnější textury bez toho aby bylo viditelné jejich opakování. Další výhodou je, že při výsledném průjezdu modelem města s výraznými texturami a multitexturingem se značně zvyšuje vnímání rychlosti pohybu auta díky výrazným detailům ubíhajícího povrchu pod autem, než při použití jedné monotónní textury. Obr : Scéna otexturovaná pouze a) první, b) druhou příslušnou texturou definující detaily povrchu. 34

43 Obr : a) Scéna otexturovaná kombinující texturou, b) Výsledná scéna. 35

44 4 Fyzika Pro simulaci dynamiky tuhých těles byla do vytvořeného enginu integrována open source knihovna ODE (Open Dynamics Engine). 4.1 Fyzikální reprezentace objektů Pro objekty, které se účastní fyzikální simulace je nutné definovat jejich fyzikální reprezentaci. Z hlediska jejich chování ve fyzikálním enginu je lze rozdělit do dvou skupin: Statické objekty jsou použity pouze pro kolize s dynamickými objekty, proto je u nich definována jen kolizní obálka. Dynamické objekty kromě kolizní obálky je pro ně nutné specifikovat také rozložení jejich hmoty. Kolizní obálku statických objektů lze definovat buď pomocí geometrických primitiv koule, kvádru a válce s polokoulemi na svých podstavách (capped cylinder), nebo pomocí obecné triangulované geometrie. Triangulovaná geometrie (v enginu pojmenovaná Ode Mesh) byla implementovaná jako další prostředek (resource) vytvořeného enginu a jednotlivé objekty ji tedy mohou mezi sebou sdílet. Byl také specifikován formát souborů pro její uložení. Rozložení hmoty dynamických objektů lze definovat pouze pomocí výše uvedených geometrických primitiv (nelze použít triangulovanou geometrii). Výše popsaná implementovaná jednoduchá fyzikální reprezentace objektů zdaleka nevyužívá všech možností knihovny ODE, jako jsou např. klouby (joints) a další entity, pro které ještě ve vytvořeném enginu nebylo napsáno obecné rozhraní pro jejich komplexní začlenění. Ve výsledné aplikaci proto bylo toto implementované obecné rozhraní použito jen pro statické objekty a pro jednoduché dynamické objekty (krabice, míče). Pro implementaci fyzikálního modelu auta byla napsána nadstavba nad tímto rozhraním. 4.2 Simulační proces Na úrovni scény je potřeba vytvořit instanci dynamics world prostředí, ve kterém bude prováděna vlastní simulace, instanci collision world (též space) prostor, ve kterém probíhá detekce kolizí a zásobník pro tzv. kontaktní klouby (contact joints) klouby vzniklé při kolizích. Při vlastní simulaci se v každém kroku nejdříve provede detekce kolizí. Pro každou detekovanou kolizi lze vytvořit kontaktní kloub se specifikovanými parametry a nakonec se provede vlastní krok fyzikální simulace. 36

45 4.3 Detekce kolizí Protože vozidla a dynamické objekty v aplikaci průjezdu městem mají jednoduché rozložení hmoty, je vlastní krok fyzikální simulace výkonově zanedbatelně složitý oproti detekci kolizí, která představuje výraznou zátěž procesoru. Proto byly implementovány některé techniky snižující její náročnost. První z nich je optimalizace na úrovni generovaných dat (modelu města), kde je jako kolizní obálka generován značně zjednodušený model města. Některé části byly úplně vynechány pro potřeby aplikace průjezdu městem není například nutné, aby kolizní obálka obsahovala střechy domů. Protože se detekce kolizí provádí na úrovni kolizního prostoru (space), spočívala idea další optimalizace v nepoužívání jednoho globálního kolizního prostoru, ale více lokálních kolizních prostorů např. na úrovni každé buňky scény. Detekce kolizí by se pak prováděla jen pro buňky ležící do určité vzdálenosti od kamery. ODE ale bohužel neumožňuje, aby daný objekt byl součástí více kolizních prostorů najednou, proto docházelo k problémům při přechodech vozidel a dynamických objektů přes hranice buněk, jelikož v daném čase byly detekovány kolize dynamického objektu vždy jen s kolizními obálkami jedné buňky Stejného zamýšleného efektu bylo ale nakonec dosaženo jiným způsobem. Tento přístup používá opět pouze jeden kolizní prostor, ale využívá schopnosti ODE zpřístupnit/znepřístupnit danou kolizní obálku pro detekci kolizí, bez toho aby musela být rušena a poté opět vytvářena. Pro detekci kolizí jsou proto zpřístupňovány pouze obálky buněk, ležících do daného poloměru (parametr OdeRadius) od buňky, ve které se nachází výchozí bod kamery. Protože je zatím přesný pohyb všech vozidel (nezávisle na vzdálenosti od kamery) vypočítáván pomocí fyzikálního enginu, byla do kolizního prostoru umístěna rovina, po které jezdí okolní auta, pokud se nachází v buňce jejíž kolizní obálky aktuálně nejsou zpřístupněny pro detekci kolizí. Toto řešení samozřejmě pro okolní auta funguje korektně jen ve městě se silnicemi v této rovině. Obecně fungujícím řešením by bylo počítat přesný pohyb vozidel s pomocí fyzikálního enginu jen do určité vzdálenosti od kamery a poté už je jen posouvat nějakým jednoduchým algoritmem. Podpora tohoto přístupu nebyla dokončena, jelikož vznikla řada problémů při implementaci plynulého přechodu vozidla mezi těmito dvěma modely chování. 37

46 5 Aplikace průjezdu městem (City Rider) Aplikace využívající vytvořený engine pro implementaci simulace průjezdu městem, včetně simulátoru okolní dopravy. 5.1 Fyzikální model vozidla Nad implementovaným jednoduchým rozhraním pro definici fyzikální reprezentace byla vytvořena nadstavba pro vytvoření fyzikálního modelu vozidla. Rozložení hmoty (body) auta je popsáno pomocí čtyř koulí představujících kola vozidla a tenkého kvádru reprezentujícího podvozek. Hmota karosérie je zanedbána, čímž je docíleno nízkého umístění těžiště auta a tím větší stability vozidla. Kola jsou spojeny s podvozkem pomocí kloubů, viz. Obr Obr. 5.1: Typ kloubu použitý pro spojení kol s podvozkem, Zdroj: Russell Smith Open Dynamics Engine User Guide Kolizní obálka auta je vytvořena stejným způsobem, jen výška daného kvádru odpovídá výšce auta. Pro přesnější výpočet kolizí by samozřejmě bylo možné definovat obálku karosérie namísto kvádru odpovídající triangulovanou geometrií, ale již tento jednoduchý způsob vytvářel dojem relativně reálných kolizí. Ve vlastním simulačním kroku, byl implementován algoritmus určující zrychlení (zpomalení) auta v závislosti na uživatelských vstupech. Natáčení kol nebylo dosaženo standardní aplikací sil, ale přímo explicitním určením požadovaného úhlu natočení. Jelikož při aplikaci sil docházelo často k nežádoucímu chování (natočení kol proti sobě) z důvodů omezené přesnosti výpočtu, která je v tomto případě kritická, protože kolo se otáčí okolo jedné osy mnohonásobně rychleji než okolo druhé. 38

47 Na této úrovni se také značně liší zpracování vstupů od volantu, poskytujícího spojité hodnoty požadované akcelerace a natočení kol, od zpracování vstupů z klávesnice. Modifikací parametrů vytvářených kontaktních kloubů při detekci kolize pneumatiky s okolím byl vytvořen model smyku. Hlavním problémem zde byla stabilita výsledného modelu, který byl kvůli absenci jakýchkoli deformací při kolizích velice nestabilní. Za účelem maximální stability byl vyvinut systém sil, které jsou aplikovány k utlumení nežádoucího chování. Všechny typy aut používají stejný model chování, liší se od sebe pouze jinými hodnotami sady vstupních parametrů (maximální rychlost, síla motoru, umístění kol..). 5.2 Simulace okolní dopravy Auta se po městě pohybují pomocí grafu ulic, vytvářeném generátorem města Martina Bašty. Analyzují tento graf do určité vzdálenosti (podle své aktuální rychlosti) a na základě toho před zatáčkami zpomalují, na rovině opět zrychlují. Jejich přesný pohyb je řízen stejným fyzikálním modelem, jako auto uživatele. Pro udržení na silnici se auta vždy snaží minimalizovat svou vzdálenost od vektoru ulice a zároveň srovnat směr své jízdy se směrem tohoto vektoru. Toto chování je dosaženo pomocí komplexního algoritmu, který zajišťuje plynulý návrat vozidla na silnici v případě, že je z ní vytlačeno (pokud ovšem ve zvolené cestě nenarazí na nějakou bariéru). Auta nerespektují dopravní předpisy, ani nezpomalují, pokud je před nimi pomalejší vozidlo, protože nemají k dispozici žádné údaje o poloze okolních aut. Tento problém by šel v budoucnu vyřešit s použitím grafu ulic, který by obsahoval pro každou ulici seznam vozidel, které po ní v daném pruhu právě jedou. Auta by se poté vyhýbala kolizím díky analýze tohoto seznamu pro ulici, na které se nachazí (případně i okolní, pokud je blízko křižovatky). 5.3 Analýza chování uživatele Pro testovací účely byla vyvinuta jednoduchá aplikace, propojená s aplikací průjezdu městem pomocí knihovny Chillix od firmy IBM, která zobrazuje některé základní údaje o chování uživatele, viz. Obr. 5.4a. 5.4 Vstupní scény Aplikace průjezdu městem byla implementována za použití modelu města vytvářeného generátorem Martina Bašty, viz Obr. 5.4b. Později vzniknul další projekt 39

48 Jaroslava Nosála a Radka Tykala generující pro tuto aplikaci scény okolí města s dálnicemi, viz Obr. 5.4c. Obr. 5.4: a) Aplikace pro analýzu chování uživatele, b) Město vytvořené generátorem Martina Bašty, c) Dálnice z projektu Jaroslava Nosála a Radka Tykala. 40

49 6 Testování Pro testování byl použit počítač s procesorem AMD Athlon XP 2000, 256MB RAM a grafickou kartou ATI Radeon 9600 s 256MB paměti. Vytvořený engine byl testován za použití modelu města o rozměrech 800 x 800m. Obr. 6.1: Měření náročnosti fyzikální simulace. První test byl zaměřen na určení náročnosti fyzikální simulace, která je kvůli zatím neoptimalizovanému návrhu výkonově kritickou částí výsledné aplikace. Pro odstranění vlivu náročnosti vykreslování byla nastavena dohledová vzdálenost na minimum. Z grafu je vidět, že i přestože engine vykonává prakticky pouze fyzikální simulaci (nic se nevykresluje) nedokáže zvládnout více než čtyřicet okolních aut. 41

50 Druhý test se zabývá výkonem grafické části, konkrétně náročností implementované techniky dynamických stínů, proto byl počet okolních aut nastaven na nulu.. 6.1: Měření náročnosti dynamických stínů. 42