akalářská práce popis programových celků pro tvorbu ... · adam prchlík vedoucí práce:...

České vysoké učení technické v Praze

Fakulta elektrotechnická

Katedra počítačů

Bakalářská práce

Popis programových celků pro tvorbu počítačových her Introduction to Game Engines

Adam Prchlík

Vedoucí práce: Ing. Jaroslav Sloup

Studijní program: Elektrotechnika a informatika, bakalářský

Obor: Výpočetní technika

Leden 2008

iii

Poděkování Děkuji svému vedoucímu práce Ing. Jaroslavu Sloupovi za podnětné vedení a všechny připomínky k mé bakalářské práci. Poděkování patří také Ing. Petru Slivoňovi, hernímu vývojáři a trpělivému člověku. Děkuji i vám přátelé, kteří jste mě při psaní bakalářské práce podporovali, popoháněli a dělali můj život zajímavějším.

Poslední díky patří mojí rodině, které nevadí, že mám rád počítačové hry.

v

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady 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).

V Praze dne 20. ledna 2008

vii

Abstract

The main topic of this thesis is characterization function of the pc games and definition of their main programmatic parts. The thesis settings up the term game engine and describe this term from the view of its parts. In the text so we can find theories about making graphic and sound part of games or parts about physical simulation, scripts, Artificial Intelligence and techniques of connection the parts of game engine.

Abstrakt

Podstatou této bakalářské práce je charakteristika počítačových her po stránce jejich fungování a definice základních programových celků, ze kterých se hra skládá. Zavádí pojem herní engine, který rozebírá z pohledu několika jeho součástí. Dotýká se úvodních teorií spojených s tvorbou grafické a zvukové stránky hry, stejně tak se věnuje fyzikální simulaci, skriptu, umělé inteligenci a postupům propojení součástí herního enginu.

viii

Seznam obrázků 11

1 Úvod 1

1.1 Záměr 1

1.2 Metody 1

2 Vypracování 2

2.1 Hra 2

2.2 Herní engine 2

2.3 Grafika a grafický engine 4

2.3.1 Základní 3D grafika pro počítačové hry ............................................ 5

2.3.1.1 Jak vzniká obraz ve hře? ....................................................... 5

2.3.1.2 Index a Vertex Buffer ............................................................ 5

2.3.1.3 Vykreslený face se podílí na výkonu ..................................... 7

2.3.2 Modely ............................................................................................. 7

2.3.2.1 Mesh ..................................................................................... 7

2.3.2.2 Materiál ................................................................................ 8

Texturování, Mipmapy, Blending .................................................. 8

Bump Mapping, EMBM, Normal Mapping.................................... 9

Parallax Mapping ........................................................................ 11

Displacement ............................................................................... 11

Specular, Difuse Mapping ............................................................ 12

Materiály a Shadery .................................................................... 12

Vliv materiálů na strukturu grafického enginu............................ 13

2.3.2.3 Kompletace modelu ............................................................ 13

Kostry ........................................................................................... 13

Pohyblivé části ............................................................................. 13

Fyzikální spoje .............................................................................. 14

2.3.3 Scénový management .................................................................... 14

2.3.3.1 Objekty scénového grafu .................................................... 15

Transformace............................................................................... 15

Instance modelu .......................................................................... 15

Hraniční objekt ............................................................................ 16

Procedurální systémy .................................................................. 16

2.3.3.2 Výpočty transformací objektů ve scéně .............................. 16

ix

2.3.3.3 Příprava dat pro render ...................................................... 16

2.3.3.4 Ořezávání herní scény ........................................................ 17

View Frustum Culling .................................................................. 17

Backface Culling .......................................................................... 17

Contribution curling .................................................................... 17

Occlusion Culling ......................................................................... 17

2.3.4 Render ............................................................................................ 20

2.3.4.1 Práce renderu ..................................................................... 20

Vykreslovací pipeline ................................................................... 21

2.3.4.2 Shadery – technické pozadí ................................................ 21

2.3.5 Procedurální systémy .................................................................... 23

2.3.5.1 Particle systém ................................................................... 23

2.3.5.2 Decal systém ...................................................................... 24

2.3.5.3 Enviromentální systémy ..................................................... 24

2.4 Animační systém 25

2.4.1 Ohlédnutí ....................................................................................... 25

2.4.2 Animované sekvence ..................................................................... 26

2.4.3 Míchání animací ............................................................................. 26

2.4.4 Uložení animací .............................................................................. 26

2.4.5 Procedurální a simulační animace ................................................. 27

2.5 Fyzika a fyzikální engine 27

2.5.1 Úvod do světa herní fyziky ............................................................. 27

2.5.2 Fyzikální svět .................................................................................. 29

2.5.3 Detekce kolize ................................................................................ 31

2.5.4 Odezva kolize ................................................................................. 31

2.5.5 Fyzika netuhých těles ..................................................................... 32

Částicová fyzika ........................................................................... 32

Pružinová fyzika .......................................................................... 32

2.6 Skript 33

2.6.1 Jazyk ............................................................................................... 33

2.6.2 Funkce skriptu ................................................................................ 33

2.7 Zvuk 35

2.7.1 Úpravy zvuku ................................................................................. 35

EAX .............................................................................................. 36

x

2.7.2 Prostorový zvuk .............................................................................. 36

2.7.2.1 Vytváření prostorového zvuku ............................................ 37

Vnímání prostorového zvuku a lidský sluch ................................. 37

Šíření zvuku v prostoru ................................................................ 39

Překážky ....................................................................................... 40

Objemové zdroje zvuku ............................................................... 41

Zvuková rozhraní, knihovny a enginy .......................................... 41

2.8 Propojení částí herního enginu 42

2.8.1 Čas .................................................................................................. 43

2.8.2 Vlákna ............................................................................................. 43

2.8.3 Synchronizace scénového grafu a grafického renderu .................. 43

2.8.4 Synchronizace scénového grafu s fyzikálním enginem .................. 44

2.8.5 Animační a fyzikální simulace......................................................... 44

2.8.6 Systém událostí .............................................................................. 45

2.9 Umělá inteligence 45

2.9.1 Pathfinding ..................................................................................... 45

2.9.2 Stavové automaty .......................................................................... 46

2.9.3 Vnímání okolí .................................................................................. 46

2.9.4 Variabilita a (ne)determinismus ..................................................... 46

2.9.5 Skript a programovatelnost AI ....................................................... 47

3 Závěr 48

3.1 Zhodnocení 48

3.2 Další možné pokračování 48

4 Seznam Literatury 50

5 Bibliografie 50

Dodatek A – Herní enginy 51

Dodatek B – Programové celky pro reprodukci zvuku v počítačových

hrách. 56

Dodatek C – Ukázka užití dostupných programových celků 58

xi

Seznam obrázků

Obrázek 2.1:Technologie TruForm 1 - hrany objektů jsou zjemněny ............................... 6

Obrázek 2.2: Plastický povrch koule (převzato z http://www.vray.us) ............................ 9

Obrázek 2.3: 3D modelář Modo a hrbolatá kůže plaza ..................................................... 9

Obrázek 2.4: Užití environment bump mappingu (převzato z http://www.zanir.szm.sk)................................................................................................ 10

Obrázek 2.5: Použití displacement mappingu. ................................................................ 12

Obrázek 2.6: Hierarchické uspořádání solárního systému .............................................. 15

Obrázek 2.7: Dělení prostoru pomocí BSP ...................................................................... 18

Obrázek 2.8: Portálovýc systém ...................................................................................... 19

Obrázek 2.9: Použití shaderů pro ztvárnění kůže - technologie ze hry Crysis ................ 22

Obrázek 2.10: Částicový efekt – výbuch automobilu. Ze hry Crysis (Crytek, 2008) ................................................................................................................................ 24

Obrázek 2.11: Drátěný model s kostrou v Bind Pose ...................................................... 25

Obrázek 2.12: Procedurální systémy ve hřa Alan Wake – generování mraků, volumetrická mlha, simulace počasí ............................................................................... 27

Obrázek 2.13: Druhy obalů pro detekci kolizí ................................................................. 30

Obrázek 2.14: Použití vícečetných bounding volumes k obklopení částí modelu ............................................................................................................................. 31

Obrázek 2.15 a 6.3: Vizuální skriptovacího systému UnrealKismet (Převzato z http://www.unrealtechnology.com/) ........................................................................... 34

Obrázek 2.16: Vícekanálová reproduktorová soustava .................................................. 39

Obrázek 2.17: Síť waypointů ........................................................................................... 46

Obrázek 2.18: Ohraničená plocha – soustava konvexních polygonů .............................. 46

1

1 Úvod

1.1 Záměr Záměrem této práce je vytvořit základní popis herního enginu a jeho částí. Jednotlivé části rozebrat a poskytnout představu o jejich účelu a škále funkcí, jež zastává. Rozbor jednotlivých částí pak doplnit o teoretické základy, které mohou posloužit čtenářům a začínajícím herním vývojářům, jako úvod a vodítko k dané problematice. Současně se práce má pokusit poskytnout základní představu o existujících řešením a spojit teoretické poznatky s konkrétními řešeními.

1.2 Metody Tuto práci jsem vzhledem k záměru práce vytvořil formou deskriptivního textu. Při popisu jednotlivých částí herního enginu spojuji poznatky o jejich fungování s teoretickým základem pro dané odvětví. Používal jsem informační zdroje internetových komunit herních vývojářů, odborné články a výzkumné práce pro hlubší proniknuti do některých témat. Další informace jsem získal přímo od českých profesionálních herních vývojářů, s nimiž jsem také konzultoval vlastní závěry a interpretace shromážděných poznatků.

2

2 Vypracování

2.1 Hra Počítačová hra od svých historických počátků v osmdesátých a devadesátých letech minulého století v mnohém pokročila. Evolucí designu, grafického zpracování a programátorského umění se počítačová hra dneška stává mnohem atraktivnější pro široké publikum hráčů a z vývoje počítačové hry vzniklo náročné a velmi konkurenční průmyslové odvětví. Hry starého typu mnohdy stavěly pouze na svém designu, herní myšlence a hratelnosti. Postupem času se však začalo zdokonalovat technické zpracování a hry se stávaly otázkou týmové práce mnoha nadšenců i profesionálů. Počítačová hra na sebe začala nabalovat další odvětví od grafiky přes zvuk až k profesionální scénografii.

Co je limitujícím faktorem pro evoluci počítačové hry? Jedním takovým faktorem by dozajista byl vývoj počítačového hardwaru, ať už mluvíme o osobních počítačích architektury x86 či o novějším fenoménu herních konzol, které z hardwaru osobních počítačů vycházejí. Určitě nebude nadsázkou, prohlásím-li, že v mnohých případech je vývoj počítačového hardwaru úzce spojen s vývojem her samotných a naopak. Vývojáři počítačových her jsou mnohdy o malý krok napřed před vývojem hardwaru a nově vyvíjené hry vždy vyžadují o kousek více výkonu než jejich předchůdci. To vytváří neustálý tlak na výrobce hardwaru, aby překonávali své a konkurenční výrobky a uspokojili tak hráčskou komunitu dychtící po kvalitnějším běhu jejích oblíbených her. S příchodem nové generace hardwaru se pak opět otevírají nové možnosti pro vývojáře jak v oblasti výkonu, tak i nových technologických postupech. Tato spirála udržuje celé odvětví velice živé a není divu, že se v dnešní době vývoji herního hardwaru i her samotných věnuje nemalé množství lidí. Ovšem z historické zkušenosti vyplývá, že tato rovnováha je víceméně konstantní. Tedy že výrobci hardwaru se snaží o co nejvýkonnější hardware (alespoň v rámci ekonomické „slušnosti“) a programátoři se stále snaží z dostupného hardwaru „vymáčknout“ něco navíc.

Co dnes vývojáře brzdí při vývoji? Pokud tvrdíme, že je zde nastolena jistá rovnováha, musí se přeci roky vývoje v odvětví nějak projevit. A skutečně je tomu tak, nejvíce je tento vývoj vidět v komplexitě obou výrobků. Počítačové procesory či grafické akcelerátory dnes obsahují komplexní funkce pro multimedia a matematiku, naproti tomu počítačové hry se dnes skládají z tisíců řádků počítačového kódu a mnohdy i několika gigabytů počítačových dat. Komplexita počítačové hry dneška v porovnání s komplexitou hry z doby přelomu osmdesátých a devadesátých let je obrovská. Vývoj takové hry si žádá v mnohém zásadně odlišný přístup, a není tedy divu, že se dnes klade velký důraz na technologie, které by mohly poskytnout vývojářům co nejvíce svobody při tvorbě obsahu a naopak co nejvíce omezily tvorbu programové části hry. Cestou dneška je modulární pojetí vývoje jádra počítačové hry a tímto tématem se budeme nadále zabývat.

2.2 Herní engine Herní engine je pojem převzatý z anglického Game Engine, což by v doslovném překladu do českého jazyka znamenalo „herní motor“ či „pohon hry“. Jde o takový kus

3

počítačového programu, který zajistí programový běh hry. Definice tohoto pojmu není vždy jednoznačná a může být profilována herními principy té které hry, avšak existuje ustálená představa o herním enginu jako o programu zajišťujícím ve hře následující prvky:

grafiku animaci zvuk herní fyziku možnosti skriptování umělou inteligenci logiku a herní principy UI/GUI síťovou komunikaci

Můžeme pak rozlišit hned několik přístupů ke konstrukci herního enginu. Jeden používaný přístup spoléhá na vývoj celého enginu v rámci jedné společnosti či dokonce pouze pro jeden konkrétní projekt. Další významný přístup pak využívá již hotových kusů kódů, ať už vlastních, či licencovaných od jiné vývojářské skupiny, k vytvoření části či celého herního enginu. Jako konkrétnější příklad můžeme uvést grafické a fyzikální systémy, na které je dnes kladen při vývoji velký důraz. Právě tyto dvě části jsou totiž hlavním lákadlem nové generace her a herních enginů, obvykle označovaných jako Next Gen (datuje se přibližně od doby uvedení herní konzole Xbox360), a zároveň jsou obě tyto části kritické v nárocích na výkonnost hardwaru, a tedy i výsledně na plynulost běhu hry.

Pokud budeme brát v úvahu dva již uvedené předpoklady, že jednotlivé komponenty herního enginu mohou být velice komplexní a jejich odladění může způsobit nechtěné zpomalení hry, zjišťujeme, že je mnohdy vítaným řešením vyvíjet jednotlivé části herního enginu samostatně. Takové části pak mnohdy dokážou pracovat autonomně a jsou označovány jako subsystémy či enginy. Mluvíme pak o herním enginu, jako o součtu programových celků zajišťujících funkčnost hry. Tyto programové celky se pak mohou označovat jako grafický engine či fyzikální engine. Opět platí, že tato označení nejsou striktní, ale spíše zvyková.

Dalším hlediskem, ze kterého se vývoj komponentního enginu1 jeví jako výhodný, je hledisko ekonomické. Tak jako jiná programátorská odvětví, těží vývoj počítačových her z možností opětovného užití již hotových celků. Od svých historických počátků až téměř do konce osmdesátých let minulého století byly hry vyvíjeny „pro jedno použití“. Tím je míněno, že většina programového kódu byla použitelná jen jednou a jeho značnou částí byla konkrétní herní logika. S příchodem jednotné platformy, jakou je PC, a dostatečné hardwarové abstrakce v podobě operačních systémů a různých API, bylo možné vytvářet znovu použitelné celky a herní logika se oddělila od samotného herního enginu. Opětovná použitelnost v dnešní době hraje naprosto nepostradatelnou roli. Některé úspěšné části či celé herní enginy jsou často použity při

1 Komponentní engine – jinými slovy engine skládající se z nezávislých komponentů

4

tvorbě někdy až desítek různých herních titulů. Příkladem takového úspěšného enginu pak není nic menšího než legenda Unreal Engine.

Dalším pojmem, se kterým se můžeme setkat ve spojení s vývojem počítačových herních enginů, je takzvaný Middleware. Takto označovaný programový celek je často vyvíjen za účelem doplnění her o neesenciální technologie a bývá často vyvíjen mimo samotné herní enginy jako nezávislý nástroj. V kontextu s herním vývojem Next Gen dostávají middleware technologie na významu a opět lákají zvýšenou pozornost na straně vývojářů. V herním průmyslu tak dnes vznikají celé společnosti zabývající se vývojem middleware pro hry a bratrská odvětví (například 3D grafika). Příkladem takového middleware může být některý z fyzikálních enginů (u her, kde je fyzika spíše doplňkovým „zbožím“), či technologie pro tvorbu prostředí, například rostlin a stromů.

O konkrétních herních enginech současnosti se lze dočíst v dodatku A. Dále se budeme zabývat herním enginem z pohledu jeho jednotlivých komponent a subsystémů.

2.3 Grafika a grafický engine Z pohledu hry je grafický engine programový celek, který zajišťuje vizualizaci abstraktního modelu hry. Tedy řečeno poněkud příměji, zobrazuje dění ve hře. Název grafický engine pak napovídá, že tento programový celek může být ve své podstatě autonomní a jeho původ je v celé škále grafických aplikací (například aplikace konstrukční a modelační, vizualizace, herní, 3D ale i 2D), kde zajišťuje určitou míru abstrakce pro snazší práci s grafikou.

Tím přichází v potaz i nahraditelnost grafického enginu. Pro vývoj počítačové hry tato abstrakce může hrát velkou roli, protože vhodně napsaný grafický engine lze nahradit za jiný, aniž by nutně museli programátoři zasáhnout do zbývajících části hry. Touto abstrakcí pak můžeme řešit i záležitosti portace2 hry pro jinou platformu, ať už v rámci jednoho herního systému či při přechodu z jednoho herního systému na druhý. Příkladem nechť je převod úspěšné počítačové hry na herní konzole, nebo přechod mezi jednotlivými grafickými API (u osobních počítačů běžně Direct 3D či OpenGL).

Grafický engine je natolik objemný softwarový celek, že jej lze dále dělit na několik odlišných bloků. Z určitého odstupu bychom mohli rozeznat tři základní funkce: správu dat, podpůrnou logiku a vykreslování. Toto obecné dělení pak můžeme konkretizovat a jmenovat několik nejběžnějších prvků grafického enginu. Jsou to tyto:

Render správa geometrie, materiálů a textur scénový graf animační systém3 procedurální systémy

2 Portace, Port – převod kódu hry do podoby spustitelné na jiné hardwarové architektuře či operačním

systému. 3 Konstrukce animačního systému může být rozdílní, je časté jeho spojování s grafickým enginem, ale

není výjimkou, kdy je animační část součástí například fyzikálního enginu – například u systému Havok.

5

Dříve, než jednotlivé části grafického enginu blíže popíšeme, seznámíme se s grafikou, která je hrami produkována.

2.3.1 Základní 3D grafika pro počítačové hry

2.3.1.1 Jak vzniká obraz ve hře? Všechno začíná u možné reprezentace prostorové grafiky, tedy takzvané 3D grafiky. Existuje mnoho teoretických i praktických způsobů jak prezentovat prostorovou grafiku pomocí počítače. Počítačové hry jsou ovšem specifickou kategorií aplikací, která krom samotného vykreslení klade požadavky i na rychlost, s jakou je vše provedeno. To abychom mohli vytvářet pohyb pro lidské vnímání zdánlivě plynulý. Celé toto odvětví se zaměřuje na práci s povrchovou reprezentací, která je dobrým kompromisem mezi náročností na matematické výpočty a nároky na paměť počítače. Hlavním cílem je tedy popsat a zpracovat povrchy vykreslovaných objektů.

Ačkoliv jsme schopni grafický engine jako celek dále dělit a tím i izolovat část zodpovídající za samotné vykreslování (render), jejíž případnou změnou bychom mohli teoreticky využít i jiných reprezentací, budeme se dále zabývat jen povrchovou reprezentací. Pro pochopení a utvoření si představy o 3D grafice počítačových her popíšeme několik základních pojmů.

Vzato od počátku, pro povrchovou reprezentaci rozeznáváme dva základní typy elementů, jsou jimi vrcholy a hrany. Vrcholy jsou body, dle anglického názvosloví vertexy, jež leží na povrchu modelovaného tělesa. Jeden vrchol je často reprezentován strukturou tří čísel v plovoucí desetinné čárce. Hrany jsou spojnice mezi těmito body. Hrana vždy spojuje právě dva body a jeden takový může být hranou spojen s více než jedním dalším bodem. Abychom mohli vyjádřit hrany mezi vrcholy, využíváme takzvaných indexů, anglicky Indices. Index pak říká, které vrcholy jsou spojeny do většího celku, primitivy. Index je celé číslo.

Propojení několika vrcholů vede ke vzniku grafické primitivy. Grafická primitiva je geometrický útvar s minimální složitostí, tudíž lehce zobrazitelný grafickou kartou. Nejčastěji se jedná o trojúhelníky, čtyřúhelníky, mnohoúhelníky či polygony, v závislosti na grafickém API, které používáme. Právě grafické API vytváří vrstvu abstrakce, což umožňuje programátorům pracovat s primitivami, které grafický hardware neumí zpracovat přímo. V praxi se tedy pro grafický hardware složitější primitivy rozkládají na nejjednodušší plošný útvar, kterým je v drtivé většině případů trojúhelník definovaný třemi vrcholy.

Primitiva nám přináší také jisté výhody pramenící z její pevné podoby. Můžeme využít třeba znalosti počtu vrcholů tvořících danou primitivu nebo toho, že primitiva je uzavřená – poslední definovaný vrchol bude hranou spojen s prvním. Pokud chceme primitivu vytvořit, stačí nám udat, které vrcholy ji budou tvořit. Pro tento účel jsou použity indexy. Abychom blíže pochopili jejich princip, řekneme si něco o způsobu ukládání vertexu a indexů.

2.3.1.2 Index a Vertex Buffer Pro uložení vrcholů a indexů používáme takzvané vertex a index buffery. Jedná se o jakási jednorozměrná pole, v nichž jsou prvky udržovány právě v tom pořadí, v jakém

6

byly zadány. V případě vertex bufferu jsou pak položkami struktury obsahující informace o jednotlivých vrcholech, kde mimo samotné pozice figurují i další informace, jako je barva, materiál či odpovídající texturové koordináty. Index buffer pak obsahuje pozice, tedy indexy, jednotlivých vrcholů z vertex bufferu.

Skupina v řadě po sobě jdoucích indexů pak označuje skupinu vrcholů, jež budou tvořit primitivu. Každá skupina indexů má tedy vždy takový počet členů, jaký je počet vrcholů potřebný k sestavení primitivy. Skupiny jsou v index bufferu řazeny jedna za druhou. Toto uspořádání pak umožňuje nad množinou vrcholů z vertex bufferu vytvořit velké množství primitiv pomocí indexů, aniž by bylo zapotřebí některý z vrcholů znovu definovat.

Existuje několik možných způsobů, jak indexy seřadit a jak jejich řazení chápat. Jelikož povrchová reprezentace u každé vzniklé primitivy rozeznává její přední a zadní stranu, využívá se právě pořadí indexů. Dva takové způsoby jsou clockwise a counterclockwise, tedy po směru hodinových ručiček a proti směru hodinových ručiček. V takovém případě povrchová reprezentace u každé vzniklé primitivy rozeznává její přední a zadní stranu dle toho, zda se vrcholy uzavírají podle nebo proti směru hodinových ručiček. Přední straně primitivy se pak říká Face. Strana odvrácená se pak nazývá Backface. Rozlišení stran se používá zejména při takzvaném cullingu, tedy „oříznutí“ nepotřebných elementů při vykreslování – o této metodě bude řeč později.

Face tedy vyjadřuje zobrazovanou, čelní, plochu primitivy, respektive trojúhelníku. Pro zpracování je důležitá takzvaná normála, neboli normálový vektor roviny určené face. Normálový vektor je orientován kolmo na face, směrem od jeho povrchu na stranu, ze které je čelní strana viditelná. Pomocí normálových vektorů je možné třeba vypočítat úhel, pod kterým dopadá světlo a tak i přizpůsobit barvu celého trojúhelníku. V základu je normála neměnná po celé ploše trojúhelníku, nicméně později si povíme o technikách, které umí využít změn normály k vytvoření různých dodatečných efektů na povrchu trojúhelníku. Jmenujme například Bump Maping, neboli vytvoření dojmu hrbolatosti povrchu, nebo technologii TruForm spojenou s grafickými akcelerátory někdejší společnosti ATI, kde dochází k hardwarovému dělení faces na menší plochy a úpravám jejich normál pro dosažení oblejších povrchů.

Obrázek 2.1:Technologie TruForm 1 - hrany objektů jsou zjemněny

7

2.3.1.3 Vykreslený face se podílí na výkonu Mimochodem, tyto prvky jsou velice důležité hned ze dvou výkonnostních hledisek. První hledisko je samotné vykreslování. Render se pro co nejefektivnější práci snaží omezit zbytečné zpracování nadbytečných elementů, ať už jsou to objekty mimo „záběr“ kamery, nebo právě trojúhelníky - faces, které jsou ke kameře zády. Na rozdíl od ostatních 3D aplikací, hry jsou v tomto ohledu specifické, a nesetkáte se tedy téměř vůbec s tím, že by bylo třeba nechat v obraze vykreslený backface trojúhelníku. Dejme si příklad na nějakém uzavřeném objektu, nejlepší bude obyčejná kostka. Pokud bychom se chtěli dívat na kostku zepředu, kolmo na její přední stěnu, render by postupoval od nejvzdálenější stěny, vykreslil ji a přes ni následně vykreslil stěnu přední, na kterou se díváme. Pro nás by kostka vypadala v pořádku, ale z hlediska výkonu bychom promrhali čas vykreslováním vnitřní strany zadní stěny kostky. Vynecháním této stěny výkon ušetříme, aniž bychom změnili výsledný obraz. Výjimku z pravidla tvoří některé speciální techniky, které mají spíše umělecký význam, kdy se může vykreslený backface používat třeba pro tvorbu obrysů (backface se vykreslí s větší šířkou čáry, takže po překreslení zůstává na okraji objektu zřetelná linka).

Ve spojení s vykreslováním komplexnějších objektů pak mají faces další roli a tou je jejich počet při vykreslování objektů. Pro testování a sledování výkonu hry se často sleduje právě počet „vnějších stran trojúhelníků“, tedy těch, které jsou vykreslovány. Tento údaj je pro vývojáře o něco přesnější, protože lépe vypovídá o množství vykreslovaných trojúhelníků, nežli absolutní počet trojúhelníků obsažených ve scéně či pohledu kamery.

Spojením vrcholů a odpovídajících hran vzniká geometrie různých tvarů, ať už plochých či uzavírajících nějaký objem. Takto můžeme vytvořit takzvanou drátěnou kostru (drátěná z anglického Wireframe).

2.3.2 Modely

2.3.2.1 Mesh Nyní známe základ pro popis geometrie nějakého objektu. Objekty myslíme takové předměty, vozidla, budovy, postavy a jiné útvary, které se mohou v herním světě objevit, a mají tedy svou geometrickou reprezentaci. Obyčejně takovým objektům říkáme modely4. Takový model se z pohledu tvůrců počítačové hry stává daleko komplikovanějším, než jak jej ve výsledku vidí hráč. Dříve, než se podrobněji pustíme do rozboru vztahu modelů a grafického enginu, povězme si, co vše je spojováno s modely v moderní počítačové hře.

Model je dnes v mnohých příkladech alfou i omegou pro počítačovou hru, protože v sobě nese všechny možné informace, které mají hráči navodit co nejintenzivnější pocity z prostředí, v kterém se díky hře mohou pohybovat. A nejde zde jen o dokonalou grafickou podobu, ale i o připodobnění fyzikálních či akustických vlastností. Abychom model mohli lépe zpracovat, rozdělíme jej na menší části, kdy jedna taková se nazývá Mesh. Mesh je taková geometrie, která představuje ucelenou část

4 Je míněná grafická podoba objektu. Obecné označení objektu ve hře je entita (Viz.

8

modelovaného objektu. V praxi to pak znamená nejenom geometrii, ale i materiály, ze kterých je daný mesh vytvořen.

2.3.2.2 Materiál Právě materiály jsou dnes jedním z hlavních míst zájmu vývojářů. Materiál totiž může říct grafickému enginu, jak bude povrch vypadat při použití světel, jak bude světlo odrážet, jaké světlo bude vyzařovat, jakou bude mít strukturu, jak bude průhledný či jaké efekty se mají na povrchu objevit. Fyzikální engine bude zajímat, jak je na tom model s třením, s hmotností či hutností. Pro ozvučení hry pak bude zajímavé, jaký zvuk bude materiál vydávat při kolizi s jiným objektem. Dalo by se tedy říci, že práce s materiály je pro objekty v počítačové hře téměř esenciální. Ale vždy záleží na potřebách té které hry a komplexnost materiálů se může velice lišit.

Z pohledu grafického enginu se můžeme setkat s mnoha vlastnostmi materiálu. Mezi ty základní a dnes již téměř neměnné patří odrazivost, tedy jakési pomyslné světlo odražené od povrchu, vyjádřené barvami ambientní, difúzní a spekulární složky. Několik dalších parametrů může určovat, jak jsou tyto reflexe na objekt nanášeny, tedy intenzitu, pokud není již určena v alfa kanálu jednotlivých barev, a zářivost vyjadřující jak kontrastní má být spekulární odlesk. Pro větší variabilitu se přidává ještě další pomyslné světlo, tentokrát emitované objektem a opět se jedná o barvu, která je nanášena na povrch objektu. Takovéto emitované světlo však nemá vliv na osvětlení dalších objektů ve scéně. Moderní render grafického enginu pak může na tyto základní vlastnosti materiálu nanést další efekty, třeba vytvoření slabé záře kolem světlo emitujícího povrchu.

Zpracování materiálu se v dnešní době posunulo ke zpracování na úrovni jednotlivých pixelů, takzvané „per pixel“. Existuje mnoho technik, které mohou ovlivnit výsledný dojem z vykreslovaného materiálu ať už pomocí ovlivňování barvy, nasvětlení, či posunu vykreslovaného pixelu. Všechny tyto techniky mají však společného jmenovatele v podobě map, či textur chcete-li, které se na materiál nanášejí často i v několika vrstvách.

Mapu či texturu je možné si představit jako rastr nebo dvojrozměrné pole, kde každý prvek je složen z jednoho či více čísel, obvykle trojice či čtveřice (počet barevných kanálů). Pokud vám to evokuje představu rastrového obrázku, není to náhodné. Pro mapy a textury se v praxi opravdu používají obrázky a barevné složky RGB pixelů se používají pro definici vektoru se složkami XYZ. Pro upřesnění je vhodné si říct, že termíny mapa a textura de facto vyjadřují totéž a v mnoha případech je lze bez problému zaměnit.

Texturování, Mipmapy, Blending Nanášení obrázku na povrchy objektů je nejzákladnější způsob použití textur. K tomu je potřeba definovat takzvané texturovací koordináty, které říkají, jaké body textury se mají „přichytit“ na vrcholy vykreslovaného meshe. Vývojáři pak mohou využít hned několik způsobů jak texturu „napnout“ na povrch meshe tak, aby nevznikaly rušivé chyby při nanášení dvojrozměrného obrázku na trojrozměrnou plochu.

Další možnost, jak zjednodušit nanášení textur, je použití mipmap, předem připravených zmenšenin původní textury. Při použití mipmap se na polygony nanášejí

9

tyto zmenšené textury v závislosti na velikosti vykreslovaného polygonu na obrazovce. Proto také šetří výkon při vykreslení, kdy není potřeba vypočítávat zmenšení textury pokaždé, stačí jen zvolit již zhotovenou mipmapu podle požadované velikosti. Mipmapa pak vzniká opakovaným dělením původní textury na polovinu a tím vznikají i různé úrovně detailů. Mipmapy se pak vytváří někdy až do velikosti pouhých pár pixelů.

Textury se dají v mnoha případech i kombinovat a vrstvit. Existuje mnoho způsobů jak dva obrázky zkombinovat, a proto musí být v rámci materiálu myšleno na určení pořadí a zejména způsobu kombinování vrstev textur. Anglicky se tomuto říká Blending. V praxi se pak jedná o mnoho možných způsobů, jak zkombinovat barvu dvou pixelů, zdali se barvy sečtou, odečtou, zprůměrují, zdali se bude uvažovat alfa kanál, tedy průhlednost. Dokonce se při blendingu mnohdy používají i další textury, jako masky, například právě pro zmíněný alfa kanál. Variant existuje mnoho a záleží právě na grafickém enginu, jakou škálu má vývojář k dispozici (v jiném případě by totiž toto míchání muselo být vytvořeno explicitně mimo grafický engine nebo dokonce už jako předpřipravené namíchané textury, což je velice nepružné řešení).

Využitím různých map můžeme vytvořit několik dalších efektů materiálů. Zkusíme jmenovat některé důležité a ve hrách používané.

Bump Mapping, EMBM, Normal Mapping Jedním z nejznámějších efektů je takzvaný Bump Mapping. Jde o techniku, která umožňuje změnit způsob/směr odražení světla či mapování textury v určitém bodě, s cílem vytvořit dojem plastického povrchu. Existuje hned několik metod, s jejichž pomocí lze docílit bump mappingu. Zmíníme jen ty nejznámější.

Ukázky použití Bump-Mappingu

Obrázek 2.2: Plastický povrch koule (převzato z

http://www.vray.us)

Obrázek 2.3: 3D modelář Modo a hrbolatá kůže plaza

První je využití monochromatické bump mapy, monochromatické textury jako výškové mapy5. Efekt pak stojí na výpočtu gradientu v daném bodě a modulace normály. Tato

5 Výška je odvozena z barvy pixelu. Používané například i pro modelování terénů.

10

metoda se označuje jako Emboss Bump Mapping, je považována za nejjednodušší a její výsledky jsou velice hrubé.

Další a pokročilejší metodu představuje Environment Bump Mapping, zkráceně EMBM. Ve své době inovativní technologie, kterou do svých grafických 3D akcelerátorů implementovala společnost Matrox, využívá hned tři mapy. První je klasická textura, tedy obrázek, který bude patrný na povrchu, dále bump mapa (někdy označovaná také jako gradient mapa) a nově i enviroment mapa, jakýsi odraz okolního prostředí. Bump mapa slouží k výpočtu gradientu, jenž se následně použije pro úpravu normálových vektorů jednotlivých pixelů a dále i pro úpravu mapování environment textury pomocí posunutí texturovacích koordinát.

Výsledný efekt je dobrou aproximací reality odrazu okolí na nerovných površích. EMBM bohužel produkuje jisté chyby, které se projeví při nevhodné kombinaci světelných zdrojů a při kterých dochází ke špatnému odlesku, a postupem času byl nahrazen novějšími postupy. Hardwarová podpora EMBM již není součástí moderních grafických akcelerátorů a k jeho produkci jsou používány shader programy (viz Materiály a Shadery).

Nejpoužívanější metodou bump mapingu dneška je tedy Normal Bump Mapping nebo též DOT3 Bump Mapping, Per-pixel lightining. Jak už název napovídá, je to technika manipulující s normálovým vektorem v jednotlivých pixelech. Využíváme všech tří barevných kanálů pixelů normálové mapy pro vytvoření správného normálového vektoru. Výsledkem je korektně vypadající nasvícení povrchu, a to i s více světelnými zdroji. Herní vývojáři takto mohou značně ulehčit grafickému enginu práci, jelikož stejného dojmu by dosáhli pouze použitím modelů s vysokým počtem polygonů, jichž zvládne grafický engine vykreslit jen omezený počet v potřebném čase.

Obrázek 2.4: Užití environment bump mappingu (převzato z http://www.zanir.szm.sk)

11

Parallax Mapping Paralaxní mapování v roce 2001 představil Tomomichi Kaneko se svými kolegy v práci nazvané Detailed Shape Representation with Parallax Mapping (1). Funguje na principu posouvání částí textury tak, že vznikne dojem členitého povrchu s viditelnými prohlubněmi. Někdy se o tomto efektu mluví jako o variantě Offset Mappingu6, právě kvůli zmíněnému posuvu. Využívá při tom optického jevu zvaného paralaxa, který popisuje, jak je ovlivněn pohled na různě vzdálené předměty při změně úhlu pohledu. Tato metoda je velice jednoduchá, ale dost efektní, a je k ní zapotřebí výšková mapa, podle které je možné vypočítat zmíněnou paralaxu. Aby byl dojem opravdu věrný, používá se krom vychýlení textury i úprava normál, pomocí již zmíněného Normal Mappingu. Původní algoritmy nepočítaly s takzvaným Self Occlusion, tedy s detaily jako je překryv a vrhání stínů. Později, v roce 2004, byly tyto algoritmy vylepšeny, a nově se označují jako Parallax Occlusion Mapping. Mnoho moderních herních enginů se honosí možností použít Paralax Mapping právě se Self Occlusion a Soft Shading, jenž vytváří jemné stíny. Jako příklad můžeme jmenovat například Unreal Engine 3, či enginy pro hry The Eldred Scrolls: Oblivion, GTA 4, Age of Conan se svým Dreamworld Enginem, nebo open source projekt Irllicht.

Displacement Dalším z efektů je takzvaný Displacement (také Displacement Mapping, respektive Offset Mapping), do češtiny přeloženo jako „posunutí“. Opět se zde setkáváme s úpravami řízenými texturou či mapou. Zatímco bump mapping či paralax mapping tvořil pouhé zdání, že materiál je zvlněný, displacement mapping dokáže vykreslovaný povrch opravdu zvlnit. Oficiální texty společnosti nVidia tento rys popisují následovně:

„Oproti Bump Mappingu, který ovlivňuje jen stínování povrchu, Displacement Mapping mění pozici elementů na povrchu.“ (2)

Změnou v přístupu oproti předešlým, na optickém klamu založeným efektům, je, že displacemenet přímo počítá se změnou geometrie a s „rozbitím“ povrchu na menší části. Proto je také tento efekt označován jako Per-vertex efekt a jeho zpracování je prací pro geometry a vertex shadery. Do nedávné doby nebyl tento efekt dostupný pro real time využití, ale v dnešní době už nachází své uplatnění, díky hardwarové implementaci mnoha potřebných funkcí.

Pro tvůrce počítačové hry pak přináší možnost, jak změnit předpřipravený mesh do různých podob pouze na základě změny displacement mapy. Jako příklad si vezměme například tvorbu terénních nerovností nebo povrchové deformace na pokožce monstra, kterému můžeme dodat třeba ostny.

6 Offset Mapping – obecné pojmenování techniky, jež vytváří posunutí na úrovni pixelů (vzniká Parallax

Mapping) nebo na úrovni vrcholů (vzniká Displacement Mapping).

12

Obrázek 2.5: Použití displacement mappingu.

Specular, Difuse Mapping Pokud zmiňujeme operace prováděné na úrovni pixelů za pomoci speciálních textur, nezapomeňme také na možnost ovlivňování reflexe světla na téže úrovni. Doposud zmiňované metody, jako je například normálové mapování, používají k výpočtu nasvícení (Difuse lightning) a odlesků (Specular lightning) konstanty platné pro celý materiál (homogení po celém povrchu). Pomocí Specular a Diffuse Mappingu jsme schopni tyto konstanty upravit na úrovni jednotlivých pixelů a vytvořit povrch s nestejnými odrazivými vlastnostmi. Princip je tedy v základní myšlence stejný jako předešlé „mapping“ techniky a umožňuje vytvořit na materiálech specifické světlo odrazivé vlastnosti. Techniky ovlivňující osvětlování na úrovni pixelů nazýváme také Per-pixel lightning.

Materiály a Shadery Ve výčtu těchto několika nejzajímavějších materiálových efektů jsme si ukázali, jak různorodé možnosti herní design má. Společným jmenovatelem jsou pak mnohdy speciální výpočty prováděné programovatelnými sub-procesorovými jednotkami pro zpracování pixelů a geometrie. Můžeme je znát pod názvy Pixel, Geometry a Vertex Shader Units. Tyto jednotky se starají o výpočet barvy pixelu, výpočty pozic vertexů a přidávání nebo odebírání vertexů dle předloženého programu. Doslova lze pomocí shader jednotek upravit, jakým způsobem bude probíhat výpočet barvy pixelu, jakým způsobem se má vypočítat pozice vrcholů nebo jakým způsobem se mají z geometrie odstraňovat nebo do ní přidávat vrcholy.

Shader je program, jenž dokáže upravit způsob, jakým je standardně nakládáno s texturováním a stínováním. Případně může zasáhnout i do geometrie povrchu, na který je aplikován materiál. Záleží na grafickém enginu, jaké všechny možnosti a jejich kombinace vývojářům umožní. Z pohledu práce s materiály nás pak zajímá sada konstant, jimiž se shader řídí a kterou je potřeba asociovat s materiálem, stejně jako kód samotného shaderu (zkompilované instrukce pro GPU).

13

Jelikož jsou shadery zejména záležitostí renderu grafického enginu, budeme se jim podrobněji zabývat v části věnované právě renderu.

Vliv materiálů na strukturu grafického enginu Grafický engine se z větší části zabývá správou dat a způsobem, jak s nimi zacházíme. Tato data jsou z velké části definice materiálů. Je důležité, aby grafický engine dokázal vývojářům poskytnout dostatečné zázemí pro sestavení a správu materiálů. V ideálním případě pak vývojář nemusí řešit, kde a jak jsou uložené mapy a textury materiálu, kde a jak se vytvoří mipmapy, či zdali render při vykreslování dostane správný shader. Správa materiálu by měla umět všechna data shromáždit tak, aby bylo snadné se k nim dostat jak ze strany herního enginu, tak i ze strany renderu, který má své specifické požadavky. Je například důležité určit vrstvení jednotlivých textur a efektů, dodržet pořadí, informovat render o tom, zdali je potřeba udělat rasterizaci ve více krocích, nebo o tom, že daný materiál vyžaduje vyrenderování jiné části scény (to v případě zrcadel). To samé platí pro blending a pořadí a způsob míchání textur.

2.3.2.3 Kompletace modelu Utvořili jsme si představu o geometrické i materiálové podstatě meshů, je načase zkompletovat model. Modelem je myšlen kompletní objekt, se všemi svými částmi, s definovanými animačními i fyzikálními vlastnostmi. Začneme ale s konstrukcí od začátku, tedy od meshů. Každý model se skládá z jednoho i více meshů. Základním způsobem, jak takové meshe spojit, představuje jejich uchycení do relativních souřadnic modelu. Mesh je při modelování umístěn grafikem do té polohy, v jaké bude později součástí celého modelu. Pro tyto potřeby má model určeno těžiště, takzvaný pivot, vůči němuž jsou udávány všechny pozice vrcholů. Tento princip má i širšího využití na úrovni scénového grafu a spojování modelů do hierarchického stromu, o čemž bude řeč později.

Kostry Po vymodelování základního tvaru modelu může být tento umístěn na kostru. Tomuto procesu se říká Skining, tedy volně přeloženo „navlékání kůže“. Kostra je pohyblivá struktura kostí a kloubů, jež má za cíl vytvořit dojem pohybu (zejména) organických částí. Každá z kostí ovládá část vrcholů modelu, pohneme-li s kostí, pozice vrcholů se změní v závislosti na nové poloze kosti. Každý kloub vytváří pohybový rozsah dvou jím vzájemně spojených kostí. Koster se využívá v animačním systému grafického enginu, kde se jim budeme dále věnovat.

Pohyblivé části Protiváhou „organickým“ modelům jsou modely s pohyblivými částmi. Pohyblivé části mohou být například dveře automobilu, kormidlo a výškovky letadla, pohyblivá ramena robotického bojového stroje. Pohyblivé části jsou často řešeny samostatnými modely, které jsou hierarchicky začleněny do modelu využívajíce možností scénového grafu. S takovýmto uspořádáním není problém danou součást v příhodný okamžik uvolnit, umístit do jiného místa scénového grafu a zapracovat fyziku. S trochou štěstí lze vytvořit například simulaci poškození vozidel a trousit ve scéně jednu součástku vozidla za druhou.

Uvedu stručný příklad, dveře automobilu, které je možné otevřít. Po vytvoření modelu auta bez dveří a dveří samotných, je třeba umístit těžiště modelu dveří do budoucí osy

14

otáčení, tedy do pozice pantů dveří. Model dveří vložíme jako model podřízený modelu auta ve scénovém grafu. Aktuální umístění dveří je v počátečních souřadnicích prostoru modelu auta, je tedy potřeba pomocí transformace dveře ještě posunout do odpovídající pozice pantů na straně modelu auta.

Fyzikální spoje Třetím případem jsou spoje fyzikální, též nazývané jointy. Napomáhají při fyzikálních simulaci a slouží k omezení pohybu dvou těles (tělesa se nemohou od sebe vzdálit, čímž vzniká onen spoj). Mohou se zdát podobné kloubům kostry, ale jsou plně nezávislé na grafických reprezentacích modelu a jsou zpracovávány nezávisle na kostře či hierarchických spojích scénového grafu. Více se budeme o této problematice zmiňovat v části věnované fyzikálnímu enginu.

2.3.3 Scénový management Management scény je téměř nejdůležitější součást grafického enginu7. Je to nástroj, který vytváří a udržuje kompletní podobu herní scény. Řečeno poněkud zjednodušeně, management scény říká, kde co je. Využívá při tom hierarchického modelu, který velice usnadňuje kontrolu nad celou scénou. Mezi jednotlivými modely ve scéně existují relace na bázi rodič – potomek, nebo chcete-li nadřízený a podřízený model. Často je možné narazit na přirovnání k solárním systémům, kde je každý solární systém nezávislý, planety podléhají vlivu jen své vlastní hvězdy, stejně jako měsíce rotují jen kolem své vlastní planety. Pohne-li se planeta, vleče si sebou svůj měsíc, rotuje-li celý solární systém kolem středu galaxie, jsou v pohybu i planety a jejich měsíce. Z pohledu solárního systému však tento pohyb nevnímáme. Existují i další relevantní příklady, třeba jízda vlakem. Z pohledu vlaku setrvávají cestující na svých sedadlech klidně a bez pohybu, ačkoliv se pro zbytek světa celá vlaková souprava a s ní i lidé pohybují. Jde tedy o princip podobný principu izolovaných (inerciálních) soustav.

To, jak jsou planety umístěny v rámci solárního systému, je ekvivalentně vyjádřeno takzvanou transformací v kontextu 3D grafiky. Jedná se o udání relativní pozice a rotace objektu. Pokud říkám relativní, myslím tím pozici a rotaci udanou vůči počátku prostoru, ve kterém se model nachází, jako v našem příkladu solární systém. Představme si tedy, že herní engine právě nahrál geometrii modelu, jenž má být umístěn do scény. Jednotlivé meshe a jejich vrcholy jsou, jak jsme již říkali, umístěny v konkrétních vzdálenostech od těžiště celého modelu. Tento pivot, toto těžiště modelu, nám poslouží jako počátek prostoru modelu, jakési izolované soustavy, která podléhá vnějším vlivům jako celek právě skrze své těžiště. Pokud umístíme model do většího prostoru, můžeme s ním v rámci tohoto prostoru pohybovat jednoduchým udáním transformace, tedy posuvu od počátku tohoto prostoru.

V praxi se pro toto uspořádání používá stromová, nebo stromu podobná struktura. Každý z uzlů takového stromu ovlivňuje všechny uzly a listy nacházející se v hierarchii pod ním. Dle principu, který jsem demonstroval, je každý objekt podřízen objektu výše v hierarchii, jež je završena kořenem celé scény.

7 Scénový management, potažmo scénový graf, spravuje hierarchii

15

Obrázek 2.6: Hierarchické uspořádání solárního systému

Scénový graf poskytuje tři důležité prvky: počítá transformace objektů ve scéně, připravuje data pro vykreslení renderem a zajišťuje rozhraní pro práci se strukturou objektů ze strany logiky hry.

2.3.3.1 Objekty scénového grafu Pokud mluvíme o objektech scénového grafu, částečně otevíráme dveře do neznáma, jelikož u mnoha herních enginů „vlastní výroby“ může scénový graf obsahovat téměř cokoliv, co uznají vývojáři za vhodné. Scénový graf je často povyšován nad celý grafický engine. Speciálně u her, jež nepoužívají ke své prezentaci pouze grafiku, můžeme očekávat, že scénový graf bude sloužit pro tvorbu hierarchie i nad jinými prvky herní scény. Na mysli teď mám například zvukové emitory, různé virtuální objekty a další prvky. Pro účely grafiky to budou zejména následující typy objektů: transformace, instance modelu, hraniční objekt a procedurální systém.

Transformace Implementace transformací opět podléhá fantazii a vynalézavosti autorů. Zmíním dvě možné varianty. Transformace je součástí každého objektu scénového grafu, nebo druhá možnost, transformace je samostatný „rodičovský“ uzel, jenž určuje transformaci všem podřízeným objektům.

Instance modelu Jedná se o grafické modely. Úmyslně však mluvím o instanci, jelikož chci upozornit na možnost, že daný objekt bude jednou z mnoha instancí stejného modelu. Takzvaný Instancing, je totiž jednou z mnoha moderních a žádaných schopností grafického

16

enginu. Scénový graf tedy obsahuje několik objektů, jež odkazují na stejná grafická data. Ulehčují se tím jednak hromadné úpravy stejných modelů a zároveň jde o značnou úsporu paměti.

Hraniční objekt Hraniční objekt je objekt vymezující svým tvarem určitý prostor. Může být užit jak pro dělení prostoru scény, tak pro vymezení prostoru, v němž je umístěn některý z modelů. Hraničních objekt se užívá například při ořezu herní scény nebo při detekci kolizí. Podrobnější popis následuje v sekci Ořezávání herní scény.

Procedurální systémy V tomto případě jde o objekty scénového grafu zastupující některý z procedurálních systémů grafického enginu. Tyto systémy generují normální geometrii, se kterou je dále nakládáno jako s ostatními modely.

2.3.3.2 Výpočty transformací objektů ve scéně Každý z objektů je umístěn a rotován ve scéně pomocí své transformace. Ta je vyjádřena transformační maticí, jež uchovává jak posun, tak i rotaci. Pokud je potřeba zjistit absolutní pozici a rotaci objektu vůči takzvaným „světovým souřadnicím“, souřadnice celého světa scény, využívá engine násobení matic. Názorně bychom to mohli popsat asi takto: Monstrum stojí metr od středu místnosti, místnost je sto metrů od středu budovy, budova je kilometr od centra města. Domyslíme-li si směrové informace v 3D prostoru, dokážeme pomocí transformačních matic určit absolutní pozice všech objektů ve scéně. Díky nastolené hierarchii lze i snadno sledovat změny pozic objektů a omezit výpočty transformací jen na větve a objekty, kterých se změna týká.

2.3.3.3 Příprava dat pro render Jelikož scénový graf samozřejmě neoperuje se samotnými geometrickými nebo texturovými daty, musí existovat ke každému objektu ve scénovém grafu objekt s daty pro render. Aby byla úspora výkonu v této kritické části grafického enginu co největší, samotné datové objekty jsou připraveny ve formátu, jemuž grafické API nativně rozumí. Úkolem scénového grafu je pak vybrat data, jež budou zobrazena, a synchronizovat je s renderem. Děje se tak pomocí průběžné aktualizace, či aktualizace v nějaké formě synchronizačních bodů, a to v závislosti na architektuře celého grafického enginu.

Příprava a výběr dat je závislý na několika úkonech: „ořezání“ scény, příprava datových objektů, seřazení objektů. Ořezávání scény je optimalizační krok, jenž má snížit počet zpracovávaných objektů. Příprava datových objektů zahrnuje případné úpravy dat, aplikace transformací a jiné operace s geometrií objektů a texturami, opět v závislosti na implementaci konkrétního enginu. Seřazení je pak optimalizací, jež napomáhá ke snížení potřebných změn stavů redneru, a tedy i urychlením jeho práce. Cílem je seřadit objekty podle vzdálenosti od kamery a umožnit tak lepší vyhodnocení dalšího ořezu. Následně také seskupit objekty používající stejný materiál, což vede k tomu, že render pak není nucen často měnit používané textury a jiné zdroje.

17

2.3.3.4 Ořezávání herní scény Při přípravě pak dochází i k několika optimalizačním krokům, aby se ušetřil výkon i objem přenášených a zpracovávaných dat. Zejména se jedná o úkony, jež omezí počty zpracovávaných objektů na nezbytné minimum. Relevantními pojmy jsou zde Visibility Culling a Cliping, jež oba vyjadřují jakousi formu ořezávání. Jelikož se jedná o jednu z kritických optimalizací, existuje mnoho způsobů, jak docílit omezení vykreslovaných polygonů. Obecně jde o determinaci viditelných povrchů (Visible Set Determination) nebo o determinaci povrchů, jež naopak vidět nebudou (Hiden Surface Determination/Removal). Část optimalizačních procedur se vykonává ve scénovém grafu - ty často pracují na úrovni celých modelů, či jejich součástí, a část vykonává render, většinou na úrovni samotných polygonů.

Bohužel toto dělení je jen jakousi teorií a doporučením, reálné implementace mohou být od této teorie odlišné.

View Frustum Culling Frustum je objem ve scéně zabíraný kamerou, jedná se o vyjádření zorného pole kamery. Cokoliv mimo frustum je tedy nadbytečné a není třeba vykreslovat. View Frustum je tedy technika vybírající ze scény jen objekty, jež jsou v pohledu kamery.

Backface Culling Pojem backface jsem již zmiňoval v úvodu povídání o grafickém enginu a jedná se o zadní strany trojúhelníků (primitiv), jež není třeba vykreslovat. Render proto tyto trojúhelníky vyřadí z vykreslování.

Contribution curling V případech, kdy je vykreslovaný objekt tak vzdálený kameře, že by nebyl ve výsledném obrázku patrný a doslova by se na něm nepodílel, je vyjmut ze zpracování.

Occlusion Culling Je technika, snažící se eliminovat ty modely či polygony, jež jsou zakryty nějakým jiným modelem blíže ke kameře. Opět se zde setkáváme se slovem Occlusion – okluze, jež je možné chápat jako překrývání. Occlusion Culling je pak pojmenováním základní myšlenky a společného cíle mnoha různých přístupů a konkrétních algoritmů. Některé z těchto algoritmů mohou pracovat s celými modely v rámci scénového grafu, jiné pracují se samotnými polygony v součinnosti renderu a grafického hardwaru. Jediným relevantním kritériem pro použití některého z algoritmů je dosažený výkon. Proto je dnes většina pokročilých enginů vybavena kombinací těchto algoritmů. V základu lze říci, že každá z používaných metod ořezávání scény do jisté míry využívá detekce střetu či protnutí objektů ve scéně s pomocnými paprsky či rovinami. Mluvíme o Intersection Detection, tedy o hledání střetů. Výsledky takového hledání nám pomáhají různým způsobem vymezit určité prostory scény, určit, zda jsou objekty v určitém prostoru, případně jaké je jich pořadí vzdáleností od kamery.

Jedním z prvních a historicky úspěšných přístupů je dělení prostoru na menší celky. V anglickém názvosloví se mluví o použití „buněk“, technice se říká Cell-based

18

Occlusion Culling. Prostor je dělen do buněk, pro něž je vyjadřována vzájemná viditelnost. Dva velice známé systémy využívají BSP8 a princip portálů.

BSP využívá pravidelné a systematické dělení prostoru v několika úrovních, jež jsou často uspořádány do vyvážené stromové struktury, nejčastěji Octree9. Při samotném ořezávání je pak sestaven PVS (Potentially Visible Set), jež je produktem analytického zkoumání, které buňky zasahují a nezasahují do pohledu kamery. Součástí implementace pak může být rozhodnutí, zdali některá z buněk plně nebrání výhledu na další buňky. Hierarchie vlastní stromové struktuře umožňuje netestovat jednotlivé buňky nižších úrovní, pokud je zjištěno, že pohled kamery nezasahuje do obklopující buňky vyšší úrovně. V takovém případě se celá větev stromu může při dalším zpracování vynechat. Nevýhoda spočívá jednak v časové náročnosti, jež je ale řešena větší měrou předzpracování, tak i v jisté nepřesnosti. Tento způsob ořezávání se pak z principu hodí spíše pro statické objekty a scény.

Obrázek 2.7: Dělení prostoru pomocí BSP

Portálové zpracování pak spoléhá na jistou předvídatelnost viditelnosti sousedních buněk. Každá z buněk totiž reprezentuje povětšinou uzavřený prostor, jenž je se svým okolím spojen pouze portálem. Je tedy daleko snazší předvídat, které části celé herní mapy bude potřeba zobrazit a její zbytek je automaticky označit jako neviditelný. Průhledy jsou generovány na základě informací o kameře i portálech a dochází

8 BSP - Binary Space Partitioning, binární rozdělování prostoru.

9 Octree – Stromová struktura, ve které má uzel právě osm potomků.

1 – Kamera2 – Objekty potenciálně viditelné3 – Objekt mimo záběr kamery

Dělení prostoru pomocí BSP

Buňky 3. úrovně v pohledu kamery

Buňky 2. úrovně v pohledu kamery

1

2

3

2

2

2

19

k vytvoření vymezeného prostoru, podle něhož se ořízne obsah sousedních prostorů, podobně jako tomu bylo u metody Frustum Culling. Náročnost na čas je zde daleko menší a není třeba předzpracování. Tato metoda se ovšem omezuje na použití především v uzavřených prostorech, což ostatně logicky plyne z principu jejího fungování.

Obrázek 2.8: Portálovýc systém

Ani jeden z těchto postupů bohužel není příliš vhodný pro zpracování rozlehlých a otevřených prostranství a jakkoliv vynikající výsledky mohou podávat v interiérech, ve volném prostoru hrubě selhávají. Takovéto rozdíly mohou pak velkou měrou ovlivnit i obsahové možnosti hry samotné a design herních prostředí může být velice ovlivněn. V seznamu požadavků na vývoj nových grafických enginů pak může být i možnost změnit, doplnit či zvolit jedno z již hotových řešení pro Occlusion Culling.

Další obvyklou optimalizací je užití zjednodušených reprezentací modelů, jejichž viditelnost lze daleko snáze a rychleji testovat než v případě složité geometrie původního modelu. Metoda, které se pro tento test běžně používá, se nazývá trasování (Tracing)10. Model můžeme vyjádřit využitím konvexních obálek (Convex Hull) nebo takzvaných hraničních objemů (Bounding Volumes, Bounding Boxes). Konvexní obálka je jednoduchým „trupem“ generovaným podle geometrie modelu. Bounding volumes jsou jednoduchá tělesa, jimiž lze co nejlépe obklopit daný model, například koule, válce, nebo kvádry (jednoduše tělesa, s nimiž je snadné vypočítat protnutí). Pro větší přesnost lze použít více hraničních objemů obklopujících jednotlivé meshe modelu, například bounding box paže či hlavy postavy. Ověřit viditelnost pomocí hraničního objemu lze velice rychle, ale může být nepřesné. Trasování konvexní obálky může být přesnější, ale náročnější. Některé hry používají pro velkou přesnost přímo geometrii modelu, nebo její zjednodušenou verzi (Low polygon model), za cenu výrazně zvýšených nároků na výkon. V praxi je možné použití jednotlivých reprezentací

10 Trasování – metoda sledování trasy, obvykle přímky - paprsky, v určitém směru a detekující protnutí

trasy s určitým objemem.

1 2

2

2

1 – Kamera2 – Objekty potenciálně viditelné3 – Portály do sousedních místností

Pohled kamery

Portálový systém

3 3

20

kombinovat a trasování urychlit, například pokud vybereme podle hraničních objemů jen ty objekty, které budou pravděpodobně vidět, a teprve u těchto budeme testovat pomocí konvexní obálky.

Konvexní obálky je také možno použít při druhém hlavním přístupu k ořezávání herní scény. Jedná se myšlenku dvou prvků, Occluders and Occludee11, tedy objektu clonících a objektu cloněných. Prvním krokem je vyhledání pravděpodobných occluderů pomocí některého z možných algoritmů. Paprsky vedené od kamery skrze okrajové body konvexní obálky mohou snadno určit prostor, který bude zastíněn. Některé algoritmy dokonce pracují s několika objekty najednou a kombinují zacloněné prostory do jednoho. Následně opět dochází k detekci, zda se objekty v pohledu kamery nachází uvnitř, vně, či na rozhraní tohoto prostoru.

Podobný tomuto konceptu může být využití Occlusion Mapy. Opět dochází k vyhledání objektů, jež pravděpodobně cloní jiným částem scény. V součinnosti s renderem a grafickým hardwarem dojde k rasterizaci těchto objektů do mapy, která je vodítkem při vykreslování finálního obrazu. Grafický hardware pak testuje, kolika pixely objekty přesahují masku, a render rozhodne, zda má být objekt dále zpracován. Okluzní mapy se pak většinou sestavují do hierarchického setu.

Podrobnější informace o Occlusion Culling a jeho metodách můžeme najít v dizertační práci Hansonga Zhanga nazvané Effective Occlusion Culling for the Interactive Display of Arbitrary Models (3).

2.3.4 Render Render je část grafického enginu odpovědná za vykreslování. Dnes ideálně běží ve vlastním vlákně, drží vlastní sadu dat, která se snaží v co nejkratším čase zpracovat a předat grafickému API a potažmo grafickému hardwaru k zpracování a vykreslení. Bohužel se hardware i rozhraní mezi jednotlivými platformami liší. Rendery tudíž vznikají jednotlivým platformám upravené „na míru“ a jejich odladění je opravdovou výzvou pro vývojáře.

Pro ilustraci jmenujme jen několik platforem, jichž se moderní a Next Gen hry týkají. Z pohledu hardwaru je dnešní trh bojištěm několika různých herních platforem, jejichž zástupci jsou: PC, Microsoft Xbox360, Sony Playstation 3 a Nintendo Wii. Poslední tři platformy jsou koncipovány primárně jako herní, tudíž jsou softwarově vybaveny vlastními specifickými rozhraními. Softwarové vybavení PC je pak dominantou dvou grafických API. Prvním je otevřené a standardizované rozhraní OpenGL, jehož implementace nalezneme pro téměř všechny hlavní operační systémy. Druhým API a dominantou operačních systémů Microsoft Windows, je rozhraní Direct X, rozhraní s asi největším vlivem na vývoj her pro platformu PC.

2.3.4.1 Práce renderu Render přijímá data z nadřazeného systému (obvykle scénový graf) ve formátu, jemuž rozumí. Tedy v podobě popisů materiálů a geometrických dat. Dále se snaží jednotlivá data rozlišit podle toho, zda se jedná o průhledné objekty, objekty s odrazivostí, zdali

11 Occluders and Occludee – Stínící a stíněný/Clonící a cloněný – jde o princip určení objektů zakrývaných

bližším objektem.

21

jsou zdroji světla a podobně. Podle těchto informací pak zařazuje objekty k vykreslení v takovém pořadí, v jakém bude zajištěno, že skrze průhledné objekty bude vidět pozadí, nebo že stíny objektů dopadají na správná místa a obdobně ve stejném duchu. Pokud bychom uvažovali dostatečně jednoduchou scénu obsahující pouze materiály s primitivním stínováním, podařilo by se nám celou scénu vykreslit jedním průchodem. Ve scénách se složitějšími efekty dochází například k vykreslení části scény, jež je použita jako textura pro efekty zrcadlení, a render musí umět na tuto potřebu reagovat. Render je tedy jakýmsi převodním blokem mezi objekty scénového grafu a grafickým API a zodpovídá za správné vykreslení obrazu. Proto jsou rendery vždy specifické pro dané grafické API a danou platformu, ale mohou spolupracovat se stále stejným systémem scénového grafu.

Vykreslovací pipeline Vykreslovací pipeline (též Render Pipeline) je sled bloků softwaru a hardwaru produkujících obraz. Na jeho počátku je render, který nakonfiguruje grafickou kartu (tedy způsob průchodu dat grafickou pipeline na kartě), a následně do ní odešle data. Různou konfigurací a změnami v pořadí, v jakém jsou jednotlivé elementy zapisovány, je pak možné dosáhnout rozličných efektů od stínů přes průhlednost, až po zrcadlení na rovných i zakřivených plochách.

2.3.4.2 Shadery – technické pozadí Prvotní shader jednotky byly fyzicky specifické pro zpracování pixelů nebo vertexů a nebylo možné je zaměnit. Vývoj v čase a jistý evoluční proces zapříčinil sloučení možností těchto jednotek a v dnešní době se ujal koncept Unified Shader Units, tedy fyzicky unifikovaných jednotek, které oproti svým předchůdcům již umí zpracovat oba typy elementů univerzálně. Což umožňuje efektivně rozdělovat výkon mezi zpracování pixelů a geometrie.

V čem jsou tedy shader jednotky inovativní a jak se podílí na vykreslení obrazu? Odpověď nalezneme, pokud se vrátíme k myšlence pipeline, tedy konkrétně její hardwarové části, někdy označované jako „grafická pipeline“ (Graphic Pipeline). Odhlédneme-li od části, která je prováděna grafickým API a 3D aplikací samotnou, máme řetězec pro zpracování, jež je plně hardwarově implementován a tím pádem i neměnný. Bohužel to vede k jistému druhu sterility při vytváření různých efektů a některých nelze ani docílit. Mluvíme o takzvané Fixed Function Pipeline (FFP), předchůdci dnešní Dynamic Function Pipeline (DFP). DFP pak umožňuje nahrát program, který změní způsob zpracování dat v některých svých stupních. Takovýto program se nazývá Shader a o jeho vykonání se starají právě shader jednotky.

Z jiného úhlu pohledu můžeme mluvit o akceleraci pomocí v grafickém čipu integrované T&L(Transform and Lightning), jednotce starající se o transformace a osvětlovací operace. Shader jednotky jsou pak jakousi druhou architektonickou generací této T&L jednotky. Pevná implementace funkcí je tedy nahrazena programovatelnou a zpětná kompatibilita je zajištěna defaultním Shaderem.

22

Tímto způsobem fungovala pipeline u grafických karet s grafickými kartami s Shader Modelem12 verze 3 a nižší. S příchodem nové generace hardwaru se Shader Modelem verze 4 a nového rozhraní DirectX 10 se začíná mluvit o plně programovatelné pipeline. Lépe řečeno pipeline podle modelu DirectX 10 již neumožňuje využívat takzvaných fixed functions. Implementace tohoto modelu má tedy mnohdy značný dopad na podobu renderu grafického enginu.

Obrázek 2.9: Použití shaderů pro ztvárnění kůže - technologie ze hry Crysis

Shader má svá omezení, ať už jsou to samotné schopnosti nebo maximální délka programu, což ovlivňuje i možnosti využití shader jednotek ve hře a potažmo i možnosti aplikovat efekty materiálů. Jelikož skoro žádný z používaných efektů již nemá pevnou implementaci v GPU, tak jak tomu bylo třeba u napevno implementovaného Enviroment Bump Mappingu v GPU grafických karet Matrox, jsou vývojáři odkázáni na výkon shader jednotek při zpracování jednotlivých shaderů.

Optimalizace efektů prováděných shadery je v principu stejná jako u jakéhokoliv jiného programového algoritmu. Čím delší a složitější je prováděný shader, tím déle se aktuální snímek připravuje. Pokud vezmeme v úvahu, že shadery mají omezenou délku, může příprava složitého efektu vyžadovat dekompozici na více částí. To samé se stane, pokud chceme aplikovat více než jeden efekt stejného druhu. V takovýchto případech je potřeba vykonat další průběhy, které se mohou neblaze projevit na běhu grafiky hry.

12 Shader Model – technická specifikace pro Shadery a Shader jednotky.

23

Z těchto důvodů je cílem herních vývojářů připravit dostatečně krátké shadery, které budou vytvářet efekty v co nejlepší kvalitě. V druhém případě se pak snaží o vytvoření algoritmů spojující dva různé efekty do jednoho shaderu tak, aby nebylo nutno provádět nadbytečné průběhy při zpracování. Příkladem zde může být Parallax Occlusion Mapping, jakožto kombinace self occluding stínování, normálového mapování a úprav texturových koordinát.

2.3.5 Procedurální systémy Procedurální systémy jsou programové celky, jež mají na starost parametrizované generování obsahu herní scény. Takto vzniklé objekty jsou převážně krátkodobého charakteru a mají roli doplňkových efektů. Některé základní procedurální systémy se staly nedílnou součástí vyspělých herních enginů a jsou implementovány na úrovni grafického enginu, ostatní jsou pak implementovány v úrovni nad grafickým enginem. Zmiňme některé základní.

2.3.5.1 Particle systém Particle Systém, je jeden z nejpoužívanějších procedurálních systémů vůbec. Díky němu je možné do herního světa umístit různorodé částicové efekty. Pro představu si jich pár jmenujme, mohou to být jiskry, efekty detonací, plameny, unikající pára, kouř, roztříštění munice o překážku, částice prachu poletující vzduchem nebo detaily sněhových vloček a další. Díky své velké univerzálnosti je particle systém neocenitelným pomocníkem. Kvalita a užitnost particle systému pak stojí a padá na jeho komplexnosti. Tedy jde o možnost tvorby různorodých efektů. Účelem většiny particle systémů je generovat a emitovat texturovanou geometrii. Vývojáři se pak snaží umožnit změnu chování při generování i emisi částic dle požadavků designérů. Z pohledu herní scény je pak particle systém reprezentován vlastním objektem ve scénovém grafu, jenž poskytuje geometrii k renderování. Každý takový objekt udržuje sadu dat, dle kterých je generován vzhled efektu na jednotlivých snímcích. V závislosti na designu hry pak můžeme narážet na různou životnost i výskyt takovýchto efektů.

24

Obrázek 2.10: Částicový efekt – výbuch automobilu. Ze hry Crysis (Crytek, 2008)

2.3.5.2 Decal systém Decal systém je dalším prvkem, který je hojně využíván. Princip je velice podobný particle systému. Opět dochází k programovému generování geometrie, tentokrát přichycené na povrchu jiných modelů ve scéně. Pokud particle systém vytvořil efekt broků tříštících se o zeď, decal systém této události dodá na věrohodnosti v podobě děr a jiných stop na povrchu stěny. Taktéž zastoupení ve scénovém grafu je obdobné jako u particle systému.

Pozn: například decal s využitím paralaxního mapování dokáže udělat věrohodné a plastické prohlubně na povrchu stěny, nebo stopy vtisknuté do čerstvého sněhu.

2.3.5.3 Enviromentální systémy Pod názvem environmentální systémy se skrývá dnes nastupující skupina procedurálních systémů, jež autonomně vytvářejí některou ze součástí okolního světa. Tyto systémy jsou pak opět do jisté míry univerzální a nejsou tedy tolik spjaté s konkrétním herním kódem. Jako příklad může posloužit generování oblohy s oblaky, jež jsou vytvářeny sadou algoritmů dle přání designérů pro danou hru či lokaci a časové období ve hře. Podobné systémy jsou pak na pomezí implementace v rámci grafického enginu či doplněného middleware.

25

2.4 Animační systém Už jsme se dozvěděli, jak je možné modely umístit do herního světa, máme představu o tom, jak s modely posouvat pomocí transformací. Zatím ovšem ještě neumíme modely opravdu animovat.

2.4.1 Ohlédnutí Animace v real-time počítačové grafice má překotnou historii, opět spojenou se zvyšujícími se možnostmi a výkonem počítačového hardwaru. Animace u starších her dvojrozměrných her (i těch s pseudo třetím rozměrem) byla tvořena klasickou okénkovou metodou, podobně jako animace kinematografická. Jednotlivá okénka (snímky) byla klíčována do obrazu. S příchodem reálného objemového 3D byly animované modely složeny z nezávislých objektů, jež se spojovaly na úrovni scénového grafu. Doslova se mluví o Jointed Rigid Objects. Tento přístup nedovoloval upravovat vertexy objektů v okolí těchto spojů a výsledky byly velice hrubé. Adoptovány byly dva postupy, jež situaci značně zlepšily. Mluvíme o využití kostry modelu a technice skinning.

Kostra je soustava pevných kostí a ohebných spojů, kloubů. Ke kostře je připevněna „kůže“, která ji následuje a přizpůsobuje se jejímu pohybu. Kůže je nám již dobře známá síť vrcholu, kdy pozice každého jednoho vrcholu je ovlivněna jednou či více kostmi, čímž mohou vznikat i pružné ohyby a deformace v okolí kloubů. Pokud by každý z vrcholů byl ovlivněn pouze jednou kostí, mluvili bychom o Rigid Bones (Tuhé kosti). Model tedy již od „výroby“ nese informace o vlivu kostí na jednotlivé vrcholy. Bohužel v tomto bodě musí být věnována zvýšená pozornost při vytváření modelu, protože animační systém není schopen „domyslet“, zda bude daný ohyb vypadat reálně a mohou vznikat nepříjemné chyby. Zde se matematická přesnost nahrazuje ruční prací a zkušeností grafiků. Úkolem animačního systému je v tomto ohledu především spravovat pohyby kostí a interpretovat tento pohyb pro jednotlivé vertexy.

Obrázek 2.11: Drátěný model s kostrou v Bind Pose

26

Stejně jako jsme definovali spojení meshů modelu vůči těžišti modelu, je i spojení kostry a „skinu“ potřeba udělat za určitých „referenčních“ podmínek. Pro tyto účely se používá takzvaná Bind Pose. Model je v této pozici svázán s kostrou, a je tedy bez deformací. Kostra modelu je uspořádaná v posloupnosti, jež funguje na stejném principu jako hierarchie scénového grafu. Příklad: Pohyb stehenní kostí postavy pak musí zapříčinit pohyb kostí holení nártu atd.

2.4.2 Animované sekvence Samotné animace jsou výsledkem animačního předpisu, který říká, jak se mají kostry modelů měnit v čase. Vzniká sekvence bodů umístěných na časové ose, jež obsahují informace o „natvarování“ kostry. Těmto bodům se pak po vzoru digitálního videa říká klíčový snímek a dle toho užíváme pro tento druh animací anglický pojem Keyframe Animation (Animace s použitím klíčových snímků). Série klíčových snímků pak utváří soubor význačných okamžiků v animaci, jež je třeba doplnit o ty nevýznačné. Dochází tedy k doplnění „bílých míst“, k interpolaci pohybu kostry mezi jednotlivými klíčovými snímky, anglicky Keyframe Interpolation. Interpolace také značnou měrou zmenšuje množství dat, jež je potřeba zpracovat. Algoritmů pro interpolaci existuje více, jmenujme dva nejvíce používané: LERP (Linear Interpolation) a SLERP (Spherical Linear Interpolation), tedy interpolace po přímce a po křivce.

2.4.3 Míchání animací Moderní animační systémy jsou ceněny pro svou schopnost míchat animace. Jednotlivé animace mohou na sebe navazovat, na různé části kostry modelu mohou být aplikovány různé animace nebo může být dokonce dopočítán jakýsi mezistav dvou současně probíhajících animací nad stejnými částmi kostry. Animační systém pomocí míchání animací pak může pomoci tam, kde nejsou animace dokonale navázané, nebo kdy je animace přerušena ještě před koncem a je na ní navázaná jiná.

Přístupu k realizaci míchání animací je opět mnoho. Běžné jsou animace zabývající se nějakou menší částí kostry. Například postava hýbá hlavou či rameny, zatímco nohy jsou animovány při chůzi nebo jen přešlapují na místě. Výsledný efekt není vždy dokonalý, ale dříve hojně používaný, a i pro některé dnešní hry plně dostatečný. Další technikou je zprůměrování animací, kdy pozice jednotlivých kostí je kompromisem mezi polohami dílčích animací. Do třetice zmiňme příspěvkové zpracovaní, jež rozlišuje míru, jakou daná animace přispívá do výsledné podoby kostry.

Pro hlubší poznatky o animaci pomocí kostry a skinningu, doporučuji práci autorské dvojice Doug L. James a Christopher D. Twigg z Carnegie Mellon University nazvané Skinning Mesh Animations (4).

2.4.4 Uložení animací Uložení animace je jen částečně záležitostí grafického enginu a animačního enginu samotného, nicméně grafické enginy velmi často preferují některý z grafických formátů pro modely, či dokonce zavádějí formáty vlastní. Pokročilé formáty pak obsahují informace o modelu, materiálech, kostře modelu a k ní odpovídajících animacích. Mnoho enginů také podporuje tvorbu vlastních zásuvných modulů pro import modelů i ve formátech, jejichž podpora není autory enginu implementována.

27

2.4.5 Procedurální a simulační animace Trochu odlišný přístup k animaci bychom mohli vidět v procedurální a simulační animaci. Zatímco běžné animace jsou předem definované sekvence pohybů kostry, procedurální animace jsou založené na programovém generování těchto pohybů. V takovém případě je nutné nezaměňovat animační systém s některým z celků zabývající se tímto druhem animace. V případě těchto animací je kostra ovládána jiným modulem, animační systém se stará jen o správné umístění vertexů vůči novým pozicím kostí. Příklad takovýchto animací může být simulace dynamiky rigidních těles či simulace svalstva. Budeme se jimi zabývat později.

Obrázek 2.12: Procedurální systémy ve hřa Alan Wake – generování mraků, volumetrická mlha, simulace počasí

2.5 Fyzika a fyzikální engine

2.5.1 Úvod do světa herní fyziky Zápolení s fyzikou ve světě her má již delší historii, ačkoliv teprve nyní se stává opravdovým kolbištěm a středem zájmu výrobců hardwaru a herních vývojářů. Fyzika měla v hrách vždy poněkud minoritní úlohu, můžeme se dohadovat, že snad vinou méně výkonného hardwaru. Její výskyty byly velice pozvolné a opatrné a byl kladen důraz na to, aby fyzika neovlivňovala plynulý běh hry. V mnohých případech byla jen jakýmsi volitelným doplňkem tam, kde byl dostatečný přebytek výkonu, ale jen málokdy měla jinou než estetickou funkci. V malých krocích se pak z fyziky coby zábavné vizuální hříčky stal zajímavý element, plnohodnotná součást světa

28

počítačových her. Fyzika reálně ovlivňuje prostředí a naopak prostředí je v mnoha hrách již plně fyzikální.

Podíváme-li se retrospektivně na počítačové hry, vždy zde byl nějaký náznak aplikace základních fyzikálních zákonů. Postavičky již na osmibitových počítačích padaly z plošinky směrem k povrchu zemskému, projektily katapultů zdánlivě opisovaly balistickou křivku a právě zastřelené postavy v 3D her padaly bezvládně k zemi. Bohužel, málokdy se tyto efekty děly za přispění nějakého komplexnějšího fyzikálního modelu. To, o čem budeme mluvit v souvislosti s herní fyzikou a fyzikálními enginy, je totiž komplexní a univerzální systém pro práci se základní Newtonovskou fyzikou v reálném čase. Tedy jde zejména o vliv gravitačních a jiných sil na tuhá tělesa. Musíme uvažovat dvě propojená hlediska, ze kterých lze pohlížet na fyzikální engine pro počítačové hry.

Prvním hlediskem je již zmiňovaná komplexnost. K simulaci fyziky můžeme přistupovat různými způsoby. Buď použijeme přesný popis jednotlivých fyzikálních veličin a objekty pro fyzikální účely nadefinujeme s hmotností, objemem, odporem vzduchu, třením. Změna fyzikálního chování hry pak bude na základě rovnic odpovídajících jednotlivým fyzikálním zákonům. Nebo budeme postupovat univerzálněji a vše vyjádříme soustavou sil, které na těleso působí. Vlastně můžeme mluvit o silách nebo impulzech, tedy rozdíl je jen v působení času, nicméně základní myšlenka je stejná a fyzikální engine pak řeší vždy jen jeden typ problému. Třetím používaným přístupem bychom už zabrousili do vod fyzikálních enginů, jež nejsou primárně určeny ani pro hry, ani přímo pro vědecké simulace. Jedná se o fyziku „netuhých“ těles využívajících teorie pružin a je využívaná spíše pro tvorbu videa (a tedy potažmo i obsahu do her). Ani jeden z přístupů se nedá označit za jednoznačně lepší pro hry, můžeme se tedy setkat s hybridy prvních dvou přístupů. Běžnější je pak použití systému založeného na soustavě sil či impulsů, jež případně umožňují některé ze sil generovat pomocí fyzikálních veličin a tím i ušetřit práci vývojářům. V následujícím textu se budeme zabývat zejména fyzikou na bázi impulzů či sil. V tomto hledisku se mohou jednotlivé enginy lišit.

Druhé hledisko je přesnost výpočtu. Přesnost počítané fyziky pro účely her se s postupem doby zvyšuje, ale stále se jedná o přesnost, jež je hrubě nedostačující například pro vědecké simulace. Ovšem nižší přesnost přináší značně vyšší výkon, který dovoluje přepočítat celou fyzikální scénu i několikrát během vykreslování jediného grafického snímku. Tím i narážíme na složitost samotného fyzikálního světa, o němž bude řeč záhy. Nejprve ale uvedeme druhou úlohu fyzikálních enginů, a to detekci kolizí.

Detekce kolizí je jednou z klíčových částí herní fyziky vůbec. Dokonce i hry, které nevyužívají komplexní fyziky, mívají systém pro detekci kolizí. Z názvu již částečně vyplývá, co je účelem, tedy detekovat kolizi dvou objektů. Z obecného pohledu na věc hledáme situaci, kdy se objekty dotýkají nebo protínají a dokonce i situace, kdy již kolize pominula. Aniž bychom zatím specifikovali reprezentaci objektů pro fyzikální účely, pojďme se věnovat požadavkům, které detekce kolizí má. Číselná přesnost pro detekci kolizí již není tak kritická, jak vyplyne záhy, naproti tomu časové rozlišení je naprosto stěžejní. Čím větší je toto rozlišení, tím přesnější je pak samotná detekce, čím menší, tím se zvyšuje riziko, že kolize nebude detekována. Představme si to na rychle

29

se pohybujícím projektilu, jež má zasáhnout papírový terč. Pokud bude detekce probíhat s velkým časovým odstupem, může se stát, že projektil bude v jednom kroku před rovinou terče a v druhém již notný kus za ní. Z našeho pohledu se projektil pohyboval skokově a ani v jednom kroku nezaznamenáme, jak projektil prostupuje papírem a tedy nedojde ani k detekci kolize. Tedy jde tytéž principy, jež ovlivňují například vzorkování signálů. Logický důsledek je tedy mít co nejvyšší časové rozlišení, v reálné hře pak mluvíme o intervalech v řádu milisekund a méně (uvažujeme-li simulaci odpovídající reálnému času). Jinou možností jak detekci kolize zpřesnit je zavést predikci kolize či její zpětnou kontrolu. Tak například je možné testovaný objekt pomyslně prodloužit na trajektorii, kterou opisuje, nebo je možné využit „ray casting“, tedy testy paprskem vedeným ve směru pohybu objektu, a mnoho dalších technik.

Další ze stěžejních otázek je způsob reprezentace kolizního modelu. Pro lepší pochopení si pojďme říct, jak herní svět vypadá z pohledu fyziky.

2.5.2 Fyzikální svět Když se podíváme na některou z moderních her, jež využívá fyziku, je velice lákavé si myslet, že fyzika je počítána nad modely tak, jak je vidíme. Takový postup bohužel není zatím reálný a výkony současného počítačového hardwaru na něj nestačí. Pro fyziku se tedy zavádí vlastní sada objektů reprezentujících objekty herní scény. V anglické terminologii lze pak najít rozlišení termínů Geoms (zkrácenina pro Geometrie), pro geometrii modelů tak, jak jej vidí například grafický engine, a Bodies (těla), definici objektu pro fyzikální svět. Jde o zjednodušené reprezentace stejné jako ty, o kterých jsme mluvili v souvislosti s ořezáváním obrazových elementů v grafickém enginu. Bounding volumes (již zmiňované hraniční objemy), konvexní obálky,„low polygonal“ modely a modely složené z jednoduchých objektů, jako jsou válce, koule, krychle a kvádry. Scéna krom těchto objektů může obsahovat další jednoduché geometrické prvky, například různé pomocné roviny.

Pro výpočty samotného fyzikálního chování, takzvané fyzikální dynamiky těles, se reprezentace omezuje na definici těžiště, na nějž se aplikují všechny impulsy a síly, tedy v důsledku posuny a rotace. Popis objektu tak není moc složitý, doplníme-li další informace jako je váha, tření a jiné fyzikální vlastnosti objektu (jsou-li podporovány a potřebné), případně jejich silové či impulsové ekvivalenty, nadefinujeme-li spoje („joint“) a dodáme počáteční stav objektu, získáme objekt plně řiditelný fyzikou.

30

Obrázek 2.13: Druhy obalů pro detekci kolizí

Pro detekci kolizí se používá takzvaný kolizní model a jeho podoba se může lišit podle potřeby konkrétní hry. Pro každý model je obvykle vygenerován hraniční objem (dynamicky hrou, statické části scény pak i explicitně vývojáři), ve kterém se nachází, a je pravděpodobné, že v rámci optimalizace je vygenerována i konvexní obálka13. Přesněji pak může být kolizní model vytvořen jako soustava hraničních objemů, které tentokrát obklopují jednotlivé části objektu. V obou případech použití hraničních objemů uvažujeme tyto objemy jako skupinu jednoduše matematicky vyjádřitelných objektů, například kvádru, koule, kapsle, válce. Výpočet kolize s těmito objekty je matematicky snadný. Jako nejpřesnější, ale nejnáročnější považujeme použití polygonálního modelu, tedy zjednodušení původního modelu s co nejnižším nutným počtem polygonů.

13 Při použití konvexní obálky využíváme faktu, že lze velice snadno zjistit, zdali je testovaný bod uvnitř či

vně obálky.

31

Obrázek 2.14: Použití vícečetných bounding volumes k obklopení částí modelu

Pozn.: Mnohé fyzikální enginy podporují sdružování objektu do skupin. V rámci těchto skupin nejsou uvažovány kolize mezi objekty.

2.5.3 Detekce kolize Kolize začíná protnutím dvou hraničních prostorů obklopující modely. Detekční systém se pak snaží detekci zpřesnit na základě dostupných kolizních modelů, ať už zadaných či dopočítaných. Cílem celé detekce je pak zjistit dvě věci, zdali došlo ke kolizi a pokud ano, určit v jakém bodě a s jakými „následky“ (myšleny účinky kolize na objekty). Každý druh kolizního modelu pak využívá jiného algoritmu pro detekci kolize. V zásadě se mnohé z nich zakládají na testu, zdali je bod uvnitř prostoru vymezeného kolizním modelem, jiné z nich sledují vzájemnou vzdálenost důležitých bodů.

Optimalizací pro systém detekce kolize je opět mnoho, zmiňme například užití techniky binárního dělení prostoru (BSP). Další informace k této a jiným technikám lze najít například v článku Stana Melaxe pro server Gamasutra14 nazvaném BSP Collision Detection As Used In MDK2 and NeverWinter Nights (5).

Pozn.: Běžně je udáván jen jeden kolizní model pro každý model, v rámci optimalizace jsou generovány pomocné modely. Některé hry ovšem vyžadují, aby všechny objekty ve scéně měly velmi přesné kolizní modely, aniž by bylo nutné je modelovat společně s modelovým objektem. Dobrou ukázkou jsou populární multiplayerové FPS (First Person Shoter), například série Unreal Tournament, které potřebují kolizní systém umožňující přesnou střelbu bez chybných detekcí. Tyto nároky může splnit systém, který z geometrie každého modelu vygeneruje také kolizní model. Uvažujme i potřebu přesný kolizní model upravovat společně s úpravami vlastního modelu (animované postavy, modely jejichž části se pohybují a podobně).

2.5.4 Odezva kolize Odezvou kolize bychom mohli nazvat děje, jež kolize zapříčiní. Tyto děje nejsou automatické, protože fyzikální systém nezná záměry vývojářů. Proto jsou detekované kolize předávány nadřazenému systému, například jako jejich seznam. Většina systémů pak umožňuje registraci handleru, obslužného programu, pro zpracování nastalé

14 Gamasutra – vývojářský portál – www.gamasutra.com

32

kolize. Odezva kolize pak obsahuje informace o kolizi, tedy bod jejího vzniku o hloubce vzájemného průniku obou objektů a normál pro daný kontakt.

Je plně v rukou programátora, zda kolize vyvolá událost a zda se zpracuje jako kolize dvou fyzikálních těles (například dojde k odrazu).

Pokud budeme požadovat reálné chování fyziky ve světě tuhých či polotuhých těles, bude nejobvyklejší reakcí na kolizi vytvoření dočasného kolizního jointu. Tedy spoje, jež omezí tělesa v jejich pohybu, tedy například v jejich vzájemném prostupování, a současně umožní převést energii pohybu změnou směru pohybu a vzniku rotací. Spoj vzniká v bodě kolize, tedy v bodě dotyku kolizních modelů, či ve středu oblasti, jíž se modely protínají. Takovýto dočasný spoj je přerušen enginem ve chvíli, kdy je přerušena interakce (dotyk, protnutí) obou těles.

Vícenásobná kolize tělesa má za následek vytvoření většího množství kolizních spojů. Princip věci pak nedovoluje řešit nastalé kolize tělesa nezávisle a musí všechny participovat na jediném výpočtu. S tím přichází i problém různé složitosti výpočtů, který podobně jako výskyt kolizních extrémů může vést k chybám ve fyzikálním chování těles. Příkladem extrému může být situace, kdy těleso „uletí“ poté, co bylo sevřeno mezi dvě pevné stěny a stlačováno (například v scéně neúplně ovládané fyzikou, kde fyzikou ovládané těleso stojí v cestě tělesům právě ovládaných animačním systémem). Fyzikální enginy dnešní doby tyto situace běžně neumí řešit, zatímco reálný výsledek tohoto druhu extrémů je ve většině případů deformace či destrukce objektu, fyzikální engine by musel znát způsoby, jakými se předmět láme a trhá, z jakých dílů je složen, což je pro současné hry trochu velké sousto. Deformace se tedy řeší jako konkrétní odezva kolize naprogramovaná vývojáři tak, aby vytvořila dojem deformace toho konkrétního modelu, nebo kusu materiálu.

2.5.5 Fyzika netuhých těles S nárůstem výkonu pro výpočet fyziky ve hrách se zvětšil zájem o využití fyzikálních enginů pro netuhá tělesa, plyny, kapaliny a podobně. Těmto simulacím se ve hrách zatím vývojáři převážně vyhýbali využitím předpřipravených animací či jednoúčelovým kódem pro deformace. Principů zpracování těchto elementů je opět vícero, uvedu dva základní.

Částicová fyzika Částicová fyzika je často používaná pro nesoudržné materiály, jakými jsou kapaliny, plyny, plazmaty. Tento způsob velice připomíná částicové systémy grafického enginu s tím rozdílem, že jednotlivé částice se nepohybují na základě předpisu, ale dle fyzikálního modelu. Grafická reprezentace takovéhoto souboru částic pak může zajistit věrohodný vzhled, například slévání masy částic.

Pružinová fyzika Fyzika využívající pružin se používá k simulaci stlačení, napínání a zkrutů těles (kus gumy, želatina), tedy reversibilní deformace. Do tělesa jsou umístěny pomyslné pružiny, jež omezují těleso v deformacích a vytváří tendenci tělesa vrátit se do původního stavu.

33

2.6 Skript To, co dělá hru zajímavou, je z velké části její obsah. Stran grafiky a zvuku může být hra dokonalá, ale bez způsobu, jak vyprávět příběh nebo zajistit interaktivitu hry, bychom asi moc úspěšní nebyli. Filozofie vývoje her a herní technologie pak vyžaduje, aby obsah hry byl co nejvyšší možnou měrou oddělen od herní technologie, potažmo herního enginu. Vychází to z potřeby udržet herní engine a technologii s ním spojenou univerzální, snadno modifikovatelnou a rozšiřitelnou. Skriptovací systém nám umožní úkolovat herní engine bez potřeby později do enginu samotného zasahovat.

2.6.1 Jazyk Skripty jsou myšleny jednoduché programové sekvence psané v autory zvoleném skriptovacím jazyce, který bývá obvykle zjednodušením či derivátem některého ze známějších programovacích jazyků (často zvykově jazyk C/C++). Skriptovací systém poskytuje designérům přístup k těm nejvyšším úrovním herního enginu. Pomocí skriptů lze herní engine úkolovat skrze funkce, jež autoři enginu do skriptovacího systému importovali (rozuměj - zpřístupnili k použití). Tyto jazyky mají mnohdy velmi jednoduchou syntax a mohou se omezovat jen na základní programovací prvky, jakými jsou rozhodování a cykly. Je v zájmu autorů herního enginu poskytnou na jednu stranu dostatečně inteligentní jazyk, ale také co nejsnazší a dobře použitelný. Cílovou skupinou uživatelů jsou totiž designéři, tvůrci obsahu hry, nebo dokonce v několika málo případech i samotní hráči, již mají s programováním minimální nebo nulové zkušenosti. Z tohoto faktu vyplývá i umístění skriptovacího systému daleko od spodních vrstev herního enginu, čímž se silně omezí možnost ohrozit stabilitu celé herní aplikace.

Obecně se skripty nejenom ve hrách, ale i v jiných aplikacích, dají zpracovávat různými způsoby. Zejména otázka kompilace může jednotlivé systémy odlišovat. Vyjdeme-li ze základního přesvědčení, že pro počítačové hry není nikdy výpočetního výkonu nazbyt, budeme raději, když se kompilace skriptů provedou již během produkce hry a nikoliv během hraní samotného. Ovšem druhá strana mince, tedy samotná tvorba skriptů, vyžaduje značné množství zkoušení, testování a co nejpohodlnější a nejrychlejší práci se skriptovacím systémem. Tedy je vítána i možnost nechat skripty přeložit i za běhu hry, a proto se mnohdy nedílnou součástí skriptovacího systému stává i překladač (či parser) skriptovacího jazyka15.

2.6.2 Funkce skriptu Důležitým bodem při návrhu a integraci skriptovacího systému je nalezení rovnováhy mezi jednoduchostí skriptů a množstvím specifických funkcí implementovaných přímo do kódu herního systému. V základě jde o to, aby funkce, importované z herního enginu, byly co nejméně závislé na herním obsahu, ale současně aby se omezila velikost a složitost samotných skriptů. Ona rovnováha ovlivňuje hned několik faktorů. Prvním je množství napevno naprogramovaných funkcí a tedy i času stráveného programátory herního enginu nad jejich vytvářením, druhý je otázka výkonu, jelikož zpracování složitých skriptů trvá znatelně déle, než vykonání funkcí zkompilovaných

15 Překladače a parsery skriptovacích jazyků mohou být použity i nezávisle na skriptovacím systému,

například pro načítání nastavení. Některé hry dokonce samy skripty generují – viz hra Homeworld 2 a použitý skriptovací systém s jazykem LUA.

34

přímo v herním enginu. Dalším by mohla být míra svobody a kreativní možnosti, jež mají designéři skrze skriptovací systém dostupné. Čím komplexnější jsou funkce herního engine, tím jednoduší skriptování je, ale omezenější možnosti designérů. Tento bod je označován jako jeden z kritických při návrhu a realizaci, jelikož práce programátorů na herním enginu je znatelně složitější a finančně i časově náročnější, ale může ušetřit mnoho práce při následné tvorbě skriptů. Příkladem může být přemístění postavy z bodu A do bodu B. Skript nebude obsahovat sekvenci povelů, jež hernímu enginu řekne, kudy má postava jít a kde zahnout, ale bude obsahovat pouze volání funkce, jež najde optimální trasu a postavu po ní provede (využívá funkcí systému umělé inteligence, viz kapitola Umělá inteligence). Takto jsme převedli náročný úkol do rukou herního enginu a dokonce nám odpadá řešení problému s vadným skriptem, pokud by se časem trasa na mapě poněkud změnila. Obecně se traduje, že tyto netechnologické části her mohou být stejně obsáhlé co do množství kódu, jako ty technologické (render, scénový graf, fyzika).

Jak jsou skripty ve hrách používány? Řekli jsme si, že skript může použít soubor funkcí, jež skriptovacímu systému uvolní vývojáři, ale samotné skripty je potřeba vykonat. Nejčastější způsobem používání skriptů je jakýsi pomyslný systém „obsluhy události“. Nejde o žádný sofistikovaný systém událostí, jak ho můžeme znát u operačních systémů nebo některých programovacích jazyků. Jde o princip věci – při určité události je vykonán příslušný skript. Uveďme si příklad nějaké události. Postava vstoupila do na mapě vytyčeného prostoru, čímž vytvořila událost, nebo se také říká, že spustila spoušť (trigger). Jiný druh události může nastat během některé důležité fyzikální kolize. Postava dopadla z výšky na zem. V takovém případě bude objekt reprezentující postavu uvědomen o takové kolizi, vyhodnotí ji a spustí skript, jež má nastaven pro tento druh události.

Obrázek 2.15 a 6.3: Vizuální skriptovacího systému UnrealKismet (Převzato z http://www.unrealtechnology.com/)

Jelikož již byly zmíněny potřeby při vytváření skriptů, uzavřeme tedy téma skriptování právě jimi. Skriptovací systém jako takový není jen interpretem a překladačem skriptů, během tvorby hry se stává i důležitým vývojovým nástrojem. Stejně jako programátoři samotného herního enginu používají moderní vývojová prostředí s mnoha nástroji pro testování a ladění kódu, tak i designéři při skriptování vyžadují jisté množství komfortu v podobě testovacích a ladících nástrojů. Pro tyto účely se kombinuje nezbytný editor a ladící schopnosti skriptovacího systému. Opět záleží na úrovni skriptovacího systému,

http://www.unrealtechnology.com/

35

který je použit, jaké funkce mají tvůrci obsahu k dispozici. Trasování a krokování, sledování obsahu proměnných, výpis ladících informací – tyto funkce dnes už patří k určitému standardu programování a skriptování, ani u herního skriptu tomu není jinak.

2.7 Zvuk Jen málokterá hra opravdu zaujme hráče pouze svou vizuální stránkou, a je tedy načase se zabývat zvukem. Snad se nedopustím velké polemiky nad tématem, pokud vzpomenu výzkum pro americká filmová studia, který měl ukázat, jakou měrou se zvuk podílí na prožitcích vizuálního obsahu. Výsledky hovořily o znatelně lepších reakcích účastníků výzkumu při použití kvalitního a přirozenějšího ozvučení. Co platí pro zážitky filmové, to platí i pro zážitky z počítačových her.

Základním kamenem při ozvučování her jsou samotné zvukové nahrávky. Podle terminologie převzaté z kinematografie můžeme takové nahrávky rozdělit na hlas, ruchy a hudbu. Zvukový doprovod hry je doslova poskládán z takových nahrávek, přehrávaných simultánně dle potřeby. To je i základním účelem zvukového systému herního enginu. Podobně jako grafický subsystém, i ten zvukový odstiňuje práci s konkrétním hardwarem, respektive s obslužnými rozhraními.

2.7.1 Úpravy zvuku Krom samotného přehrávání umožňují zvukové systémy i aplikaci různých efektů a úprav zvuku, které mohou zpestřit dojem z poslechu. Mluvíme samozřejmě o efektech aplikovaných v reálném čase (na rozdíl od předpřipravené zvukové nahrávky třeba u filmu). V první řadě se věnujme otázce aplikace holých efektů, jako jsou ozvěna (Echo), zpoždění (Delay), efekty odrazů od překážek (Reverb), efekty při úpravě fáze (Phaser, Phase Shift), různé zvukové modulace, vibráto a tremolo (Vibrato, Tremolo, Flanger), zkreslení (Distortion) a jiné. Jsou to efekty, jež lze samostatně aplikovat na přehrávaný zvuk. Děje se tak za pomocizvukového subsystému počítače, tedy zvukové karty (integrované digitální signálové procesory pro zpracování efektů) a jejího ovladače, pokud jsou efekty podporovány. Tyto efekty byly původně určené k vylepšení a „osvěžení“ syntetizovaného zvuku (MIDI), který byl dříve velmi oblíben ve hrách pro jeho jednoduché zpracování a minimální datový objem (můžeme najít podobnost v porovnání rastrové a vektorové grafiky). Časem se syntetizovaný zvuk stal nedostačující kvalitou a variabilitou a byl nahrazen klasickými nahrávkami (záznam zvukových vln).

Vývoj zvukového hardwaru a herního ozvučení posunul pozornost od pouhých jednotlivých efektů k jejich kombinování, a tím i k vytváření environmentálního audia, napodobování zvukových prostředí. Ve hrách slouží pro navození pocitu pohybu v různých prostorách, např. jeskyně, les, hala. Efekty prostředí se zpočátku tvořily na základě pevných předvoleb (Presets) obsahujících informace o počtu a pořadí aplikovaných efektů, stejně jako o jejich nastavení. Postupem času bylo ovládání mnoha parametrů těchto efektů zpřístupněno vývojářům a bylo tak umožněno vytvářet bohaté efekty napodobující různá prostředí. Bohužel je tento postup stále jen statickým napodobením a nevzniká automaticky na základě analýzy okolního prostoru – obvykle jsou napevno přiřazeny k určitým částem mapy.

36

EAX Průkopníkem a propagátorem této technologie, zaměřené zejména na použití v herním průmyslu, je společnost Creative Labs. Její implementaci známe pod zkratkou EAX (Enviromental Audio Extension). Jedná se o rozšíření pro rozhraní Direct Sound 3D (součást Direct X společnosti microsoft) a v dnešní době je možné ji použít i pomocí jiných 3D zvukových rozhraní, jako je například OpenAL16. Tato rozhraní sama zpracovávají zvukovou scénu (viz Prostorový zvuk) a EAX jen aplikuje efekty pro jednotlivé reprodukované zvuky, které označujeme některým z pojmů zvukový kanál (Sound Channel), zvukový tok (Sound Stream) nebo hlas (Voice). Vývojáři mají tedy možnost přistupovat i k nastavení EAX (a jiným podobným rozšířením) pomocí „sad vlastností“ (Property Sets) nebo mohou přistupovat k samotnému rozhraní EAX. V současnosti pátá generace technologie EAX umožňuje za přispění hardwaru (zvukové karty Sound Blaster X-Fi a lepší) zpracovat až 128 zvukových kanálů a na každý aplikovat až čtyři různé efekty. Podpora pro zpracování EAX je dnes implementovaná v drtivé většině počítačového zvukového hardwaru, a to minimálně ve verzi 2.0, která se stala zvukovým standardem (IASIG).

Dalším z nástrojů, který dostávají vývojáři do rukou, je možnost prolnout dvě prostředí (dvě předvolby) tak, aby vznikl plynulý přechod. Tento postup označujeme jako Enviroment Morphing a byl implementován v třetí generaci EAX. Děje se tak na základě přechodů, jež jsou rozmístěny ve zvukové scéně. Enviroment Morphing byl velice důležitým mezníkem, protože sebou přinesl možnost měnit parametry předvoleb, a tím také možnost vytvářet nové efekty prostředí (kombinováním již existujících).

Čtvrtá generace EAX nabízí použití více efektů prostředí současně. Pro různé zdroje zvuku je možné nastavit několik odlišných efektů prostředí, které budou zpracovány nehledě na pozici posluchače. Je tak umožněna větší bohatost a přirozenost zvukového projevu.

Velice silnou konkurenci pro technologii EAX tvořila technologie Sensuaura od stejnojmenné společnosti. Tak jako technologie EAX 2.0 byla coby zvukový standard implementovaná do mnoha zvukových čipů, tak i Sensuara byla licencována a její podpora byla implementována do mnoha zařízení, v neposlední řadě i do herních konzolí Xbox, Playstation2 a GameCube. Přestože jde o velice rozšířenou alternativu, byla celá společnost Sensuara odkoupena (v roce 2008) společností Creative Technology a její technologie začleněna do portfolia produktů Creative Technology. Z tohoto důvodu se domnívám, že pro budoucí vývoj herního audia nebude hrát již důležitou roli.

2.7.2 Prostorový zvuk Jedním z milníků herního zvuku byl příchod prostorového zvuku, tedy zvuku zpracovávaného s ohledem na pozici zdroje zvuku a pozici posluchače a zároveň s ohledem na okolní prostor. Aby bylo možné prostorový zvuk vytvářet, je potřeba nejdříve popsat „zvukovou“ scénu. Jde opět o nějakou interpretaci scény, tak jak jsme ji definovali pro grafiku a pro fyziku. V principu obsahuje zdroje zvuku (zvukové

16 OpenAL původně vyvinuté společností Loki Software, později převzato Open Source komunitou,

v dnešní době vyvíjeno a udržováno společností Creative Technology/Creative Labs.

37

emitory) a posluchače. Pokročilejší podoba zvukové scény pak může obsahovat geometrii pro simulaci šíření zvuku nebo nastavení pro environmentální efekty a přechody mezi nimi.

Zvukový engine počítačové hry povětšinou spolupracuje se zprostředkujícím rozhraním, podobně jako je tomu u grafiky. Tato rozhraní pak dostávají od zvukového enginu informaci o pozici posluchače a zvukových emitorů, jejich vlastnostech (natočení, rychlost pohybu, hlasitost a podobně), informace o efektech, které se mají použít, či geometrické podobě scény. Úkolují různé softwarové součásti, zvukové efekty a podpůrné algoritmy, tak i samotné ovladače zvukového hardwaru. Povětšinou jsou tato rozhraní u NextGen her používána v kombinaci s nějakou nadstavbou, poskytující vyšší funkce hernímu enginu, ale o tom více později.

2.7.2.1 Vytváření prostorového zvuku Správná simulace zvuku by obsahovala mnoho výpočtů sledujících šíření zvuku skrze scénu, počítala by odrazy a pohlcování různých frekvencí materiály okolí, rezonance materiálů, zahrnuly by se interference a pracovalo by se s neomezeným počtem zvukových zdrojů. Bohužel k takto komplexní simulaci zatím současné hry technologicky a počítače výkonově nedospěly. Dříve, nežli se budeme zabývat šířením zvuku prostorem, vraťme se ještě k možnostem, jak upravit samotné zvuky tak, aby budily dojem, že opravdu pochází z prostoru, jež je znázorňován graficky.

Při vytváření prostorového zvuku můžeme uvažovat několik způsobů, jak zvuk ovlivnit. Prvním je změna hlasitosti. Zvuk bude ztrácet na své intenzitě dle vzdálenosti zdroje od posluchače. Současné zvukové systémy pak umožňují upravit charakteristiku pro úbytek hlasitosti zvuku, aby bylo možné simulovat změny ve schopnosti prostředí šířit zvuk, například rozdíl mezi šířením zvuku v mlze, pod vodou, nebo v normální atmosféře. Úprava hlasitosti dle vzdálenosti je nazývaná Rolloff efekt a jeho charakteristika Rolloff Model. Druhým takovým způsobem, jak ovlivnit zvuk, je opět aplikace různých efektů, tentokrát ale parametrizovaných v závislosti na již zmiňovaném umístění ve scéně. Třetím způsobem je využití techniky Audio Panningu, metody pracující s reprodukcí zvuku pomocí dvou a více reproduktorů. Zvuk je přehráván ve více reproduktorech najednou a rozdílnou hlasitostí je zvuku udělována domnělá pozice v prostoru. Tuto techniku známe dobře z ovládání stereofonních hudebních systémů, kde můžeme ovládat takzvaný Stereo Balance (jedná se o Stereo Panning).

Vnímání prostorového zvuku a lidský sluch Na rozdíl od obrazového vjemu a zraku je pochopení lidského sluchu důležitější pro tvorbu věrohodného ozvučení a v mnohém ovlivňuje konstrukci zvukových enginů pro počítačové hry. Vnímání prostoru pomocí našeho sluchu je založenu na skladu mnoha různých informací, jež mozek přijímá a dekóduje do naší představy o okolí. Pomáhá nám naše fyzická stavba (například tvar učních boltců) i naše schopnosti zvuk analyzovat (funkce spánkového laloku v mozku). Vnímáme drobné odchylky, ty mohou

38

být sekvenčního charakteru (projevují se v čase) a simultánního charakteru (struktura zvuku a sklad kmitočtů)17.

Orientaci v prostoru pomocí zvuku nám umožňuje naše stereofonní sluchové ústrojí. Zvuk doléhá do pravého i levého ucha rozdílně, odchylky mohou být v hlasitosti (Interaural intensity difference) nebo v čase (Interaural time difference). Zpoždění samo o sobě nám teoreticky dává informaci o jednorozměrném umístění předmětu, zdali je od nás více vpravo či vlevo. Další analýzou zvuku nám náš sluch poskytne informaci o umístění v dalších směrech. Pokud zvuk přichází ze zdroje, který je před námi, vnímáme daleko lépe vyšší kmitočty18, než pokud je zdroj umístěn za námi. Podobně pak vnímáme, zda je zdroj nad námi či pod námi. Pomáhá nám pohyb zdroje (nebo pohyb hlavy, jež je automatický, stejně jako pohyb očí při prohlížení objektů), protože náš sluch nám umožní zpracovat rozdíly a pomůže nám rozhodnout se o umístění zdroje zvuku. Zaprvé vděčíme našemu stereofonnímu sluchu, zadruhé pak konstrukci našich uší. Struktura ušních boltců napomáhá vytvářet odchylky ve zvucích přicházejících z různých směrů. Využitím těchto znalosti vzniká soubor funkcí, jež umí zvuk modifikovat tak, aby zmátl náš sluch a byl interpretován jako zvuk pocházející z jiného zdroje v prostoru (tedy ne z reproduktoru či sluchátek). Tyto funkce označujeme zkratkou HRTF, z anglického Head Related Transfer. V tomto bodě začíná být rozhodující i způsob reprodukce zvuku. Pojďme si krátce říct o několika problémech s reprodukcí zvuku spojených.

17 Zvuková analýza prostředí – ASA (Auditory Scene Analysis) je metoda popsaná Albertem Bergmanem

(7) 18

Zvuk v o nižších kmitočtech nemá takovou směrovost a nedokážeme ji ani vnímat. Proto je obvyklé, že se pozici basových reproduktorů, či subwooferů, nevěnuje takový pozornost, jako prostorovým reproduktorům určeným pro vyšší kmitočty.

39

Obrázek 2.16: Vícekanálová reproduktorová soustava

Při použití vícekanálových reproduktorových sestav se můžeme setkat s problémy, které je třeba, aby zvukový systém řešil. Takovým problémem se může stát tvorba přeslechů. Přeslech, jinak také Cross Talk Effect, vzniká ve chvíli, kdy nejsme schopni reprodukovat zvuk pouze pro jedno ucho, pokud je to potřeba. Zvukový engine musí na jednotlivé kanály aplikovat další techniky pro potlačení těchto nežádoucích přeslechů. Jmenujme dvě, Cross Talk Cancellation, používá zvuku s opačnou fází pro vyrušení efektu na jedné straně poslechového prostoru, a Direction Enhancement, která posiluje směrovost reprodukovaného zvuku.

Účinnost algoritmů HRTF je velice nízká, pokud se pokusíme vyvolat dojem velmi blízkého zdroje zvuku. Řešení je v rozdělení nejbližšího prostoru kolem posluchače na několik zón a zvuk upravovat přímo podle toho, ve které se má nacházet zdroj zvuku. Tato technologie se nazývá MacroFX.

Šíření zvuku v prostoru Zatím jsme mluvili o zvuku, který k nám doléhá přímo. Ovšem vnímáme i zvuk odražený, a ten nám umožňuje dále zpřesnit představu o prostoru, ve kterém se nacházíme. Pro účely zvukové simulace prostoru v počítačových hrách uvažujeme čtyři způsoby, kterými se zvuk může šířit k posluchači:

přímý šířený zvuk (direct path)

jednoduchý odraz (first order reflection)

vícenásobný odraz (second order or late reflection)

zvuk šířený přes překážku (occluded path)

Druhý a třetí bod z tohoto seznamu, tedy odrazy a ozvěny vzniklé v prostoru, označujeme anglickým termínem Reverbation. Ze zpoždění odrazů, ze směru, z jejich četnosti a délky trvání, mohutnosti, struktury, ze všech těchto vlastností získáváme

40

informace o dotčeném prostoru. Aby zvukový systém mohl tyto dozvuky vytvořit, je třeba již podrobnějších informací o konkrétním prostoru. Interpretace scény tedy musí obsahovat i geometrii, podle níž je možné vytvořit potřebný dozvuk. Zvukové systémy tuto úlohu řeší několika způsoby. Jmenujme si dva, Enviromental Reverb a Wavetracing.

Enviromental Reverb je znám zejména jako řešení firmy Creative Labs a jako součást technologie EAX. Jak jsme si již řekli, EAX se stará zejména o efekty prostředí, jež jsou vesměs statické a nehledí na podobu scény. Ovšem s postupem času bylo umožněno vývojářům parametrizovat jednotlivé efekty a zejména efekt Reverb natolik, že lze velice efektně napodobit šíření zvuku v konkrétním prostoru. Tento přístup je dost výhodný, protože vývojář může přizpůsobovat všechny parametry efektu Reverb dle geometrie konkrétního prostoru (EAX 3.0 a novější), nebo může zvolit konzervativnější způsob a potřebné informace a nastavení může zanést přímo do mapy a využít tak již zmiňovaného statického efektu prostředí. Technologie EAX je ale závislá na zvukovém hardwaru, který musí být schopný zmíněné efekty reprodukovat (obdoba několika generací Shaderů u grafických karet).

Jako konkurenta můžeme jmenovat techniku nazvanou Wavetracing19. Ta se snaží napodobit způsob, jakým se vlny šíří od zdroje k posluchači. Zvukové vlny se odráží podle geometrie prostoru a jednotlivé odrazy se k posluchači dostávají v různém čase, přesně dle fyzikální představy o rychlosti šíření zvuku. To je rozdíl oproti pouhému Reverbu, jež sice může vycházet z předpokladů prostoru, ale šíření zvuku se uvažuje jen velmi omezeně. Důsledkem toho k nám mohou odrazy zvuku přicházet z různých směrů. Materiály, od kterých se zvuk odráží zpět, mohou ovlivnit, jak se zvuk odrazí a jak se při odrazu změní. Z teorie vyplývá možnost generovat geometrii pro zpracování audia pomocí Wavetracingu z geometrie určené pro grafiku, ovšem v současné praxi je takový postup stále dosti náročný. Opět je tedy tendence omezovat složitost zvukové scény20. Omezení z důvodu výkonové náročnosti se týká také množství zpracovávaných kanálů (myšlen počet šířených zvuků), stejně tak i množství odrazů, jež je možné zpracovat současně. Wavetracing je implementován například v starším zvukovém systému A3D (Aureal)21, dřívějším konkurentovi systému EAX.

Překážky Zmiňoval jsem částečné pohlcování zvuků. To se děje při odrazu zvuku a zejména při průchodu zvuku překážkou. Každá překážka deformuje zvuk jiným způsobem, pro počítačové hry rozeznáváme povětšinou tři druhy, a to okluze, obstrukce a exkluze. Nachází-li se mezi posluchačem a zdrojem zvuku souvislá překážka, zcela zabraňující přímému kontaktu, například stěna, jedná se o okluzi (uzavřená překážka). Překážka, kolem níž se může zvuk stále šířit směrem k posluchači, třeba i nepřímo, například sloup, se nazývá obstrukce. Pokud se zvuk šíří skrze překážku, jež objemově omezuje prostor, jímž zvuk prochází k posluchači, říkáme takové překážce exkluze (například

19 Wavetracing nejen názvem ale i základní myšlenkou připomíná techniku z oblasti referování obrazu,

takzvaný Raytracing – sledování paprsků. 20

I některé 3D hry uvažují šíření zvuku pouze ve dvou rozměrech. 21

Aureal vycházel ze svého výzkumu simulace prostorového zvuku pro NASA. Pro zábavní průmysl byl uvolněn systém A3D, používaný například v 3DMarku. V roce 2000 odkoupen konkurenční Creative Labs.

41

otvor v souvislé stěně). V prvním případě bude zvuk zastřený, v druhém bude posluchač vnímat spíše odraz zvuku v prostoru a v třetím bude vnímat zvuk přímo, ale už ne jeho ozvěny.

Ať už použijeme pro detekci Wavetracing nebo jinou techniku, která umožní překážky najít a rozlišit, jsme téměř vždy v situaci, kdy používáme k detekci geometrii scény. To opět přináší zmiňované nároky na výkon. Zvuková scéna se proto velice zjednodušuje a některé předem známé překážky se mohou ve scéně označit, čímž se ulehčí jejich rozpoznání a určování typu překážky. Touto cestou se vydává i jedna z pozdějších verzí EAX, implementující překážky jako další zvukový efekt.

Objemové zdroje zvuku Objemové zdroje zvuku (Volumetric Sound Sources) jsou takové zdroje, jež nejsou soustředěny do jednoho bodu. V případech, kde je zapotřebí, aby zdroj zvuku nepocházel z jednoho konkrétního bodu, je vytvořen objem, jehož všechny části mohou být zdrojem zvuku. Zvuk je pro posluchače soustředěn do nejbližšího bodu objemu a má v každém bodě stejnou intenzitu. Použití je možné například u ozvučení projíždějícího vlaku, jehož hřmot na kolejnicích chceme slyšet po celé délce soupravy. S touto technikou se můžeme setkat pod názvem ZoomFX.

Zvuková rozhraní, knihovny a enginy Orientace v softwaru, zaměřeného na produkci zvuku pro počítačové hry, je poněkud nepřehledná. Máme zde rozhraní zajišťující funkčnost na nižších i vyšších úrovních, zvukové knihovny mohou poskytnout různé efekty, ať už počítané softwarově nebo pomocí zvukového hardwaru. První skupina zajišťuje vlastní reprodukci zvuku, tyto můžeme nazývat jako zvukové rendery, pracují se zvukovým hardwarem a mohou umožnit přístup k hardwarové akceleraci při zpracování efektů. Druhá skupina pak zvuk vytváří, upravuje, ale sama nereprodukuje a využívá jiná rozhraní k jeho reprodukci či k hardwarové akceleraci zpracování efektů. V mnoha případech se pak dají označit jako Wrapper API (zkráceně Wrapper), obalové rozhraní. To vše může být zapouzdřeno do podoby kompletního zvukového enginu nebo může být takový engine zcela proprietární a všechny jeho součásti mohou být psány jen pro tento engine. Některé systémy reagovaly na změny a umožňují emulovat jiná rozhraní tak, aby byla zajištěna kompatibilita s hardwarem i novým softwarem (například emulace EAX pomocí ALchemy a OpenAL).

Navzdory různorodosti zvukových enginů si můžeme zformulovat základní množinu funkcí, jež můžeme očekávat:

Simultánní přehrávání více zvuků Zvukové buffery a správa uložení zvuku v paměti Přehrávání vícekanálového audia Prostorový zvuk

o Umístění zdrojů zvuku a posluchače v prostoru o Rolloff modely o Dopplerův efekt o Audio panning o Head Related Transfer Function o Práce s geometrií scény

42

o Práce s překážkami o Efekty prostředí – Enviromental Reverb

Vícekanálová reprodukce Efekty

o Zpracování v reálném čase o Parametrizace efektů o Řetěz zpracování – aplikace více efektů na kanál o Hardwarová akcelerace

Podpora různých audio formátů Zvukový záznam

Krátkému popisu a shrnutí dostupných rozhraní a zvukových enginů je věnována Dodatek B - Programové celky pro reprodukci zvuku v počítačových hrách.

2.8 Propojení částí herního enginu Herní engine není jen součtem jednotlivých subsystémů, ale jde o jejich funkční spojení a přenosu informací mezi nimi. V mnoha případech tvůrci herních enginů (potažmo her) řeší stále stejné zadání, jak interpretovat vznikající data do podoby, v které je lze reprodukovat jako obraz a zvuk, nebo jako soubor dat pro synchronizaci při síťovém hraní. Přesto s každým novým enginem, novou kombinací subsystémů, nebo i novou hrou, vzniká další řešení tohoto úkolu. Pokusím se tedy zformulovat vlastní představu o možných postupech při spojování různých částí enginu. V první řadě je dobré zopakovat si a pochopit, co herní engine vlastně vytváří.

Každá hra se skládá ze dvou částí, softwarové technologie a herního obsahu. Herní engine je hlavním zástupcem technologie hry. Herní obsah je pak sadou informací tvořících herní svět, nebo herní prostředí, chcete-li. Je vyjádřen graficky a zvukově, objekty se v něm pohybují, je interaktivní, má svá pravidla, je v něm vyprávěn příběh, alespoň tak to vnímá hráč. Pro vývojáře je toto prostředí herní scénou a objekty herní scény nazýváme entity.

Správu scény a jejích entit má na starosti Entity Manager, správce entit22. Entita sdružuje různé datové struktury popisující objekt stran grafiky, fyziky, zvuku, skriptů a dalších. Tyto datové struktury jsou pak rozmístěny v jednotlivých subsystémech. Je běžné, že si každý ze subsystémů udržuje vlastní sadu dat (vlastní představu o scéně), která je odlišná než u ostatních subsystémů. Vytváří si vlastní scénu (například grafická scéna, fyzikální scéna a další) a tu si udržuje, pomocí interního správce. Jedním velice důležitým správcem je scénový graf, o kterém jsem psal v kapitole Grafika a grafický engine v sekci scénový management. Scénový graf grafického enginu, si udržuje hierarchicky uložená grafická data patřící k jednotlivým herním entitám.

22 Zvyková terminologie, není pevně zakotvena a může se měnit.

43

2.8.1 Čas Dříve nebylo zvykem ve hrách sledovat čas jako jeden z parametrů ovlivňující hru23. Hry pracovali tak rychle jak jim bylo umožněno a pokud byl počítač rychlejší, bylo rychlejší i tempo hry. S příchodem nové generace her, her závislých na výkonu grafických akcelerátorů, her využívajících různých druhů simulace, se stalo nezbytným sledovat čas. Běh hry v čase můžeme rozdělit na malé časové úseky, takzvané tiky (Tick). Běh hry sestává ze stále stejných úkonů opakujících se v cyklu, jeden průchod cyklem nazýváme jeden krok (Step). Během jednoho tiku je vykonán jeden krok.

Pokud nebudeme brát v úvahu délky jednotlivých tiků, každý step posune herní čas o konstantní. Pokud by byla zátěž nerovnoměrná, například by se objevoval nějaký náročnější grafický efekt, tempo hry by se stále měnilo. Viděli bychom sice výsledek každého stepu, a tudíž i všechny snímky onoho efektu, ale tempo hry by bylo roztříštěné a pocit ze hry taktéž. Stejně tak byla zasažena i hratelnost a obtížnost hry. Proto hra měří čas mezi jednotlivými tiky a každá změna scény vzniklá během jednoho kroku je úměrná jeho délce. Vozidlo urazí v každém tiku vzdálenost přímo úměrnou rychlosti a délce tiku. Pokud se zpracování některého tiku zpozdí, změní se plynulost vykreslovaného obrazu, ale tempo hry zůstane zachované.

2.8.2 Vlákna Současný trend v konstrukci herních enginů káže použití vláken (Threads). Ty umožňují určitým částem hry pracovat nezávisle na ostatních a tedy i různě rychle („tikají“ v jiném rytmu). To by samo o sobě mohlo vést k jisté nekonzistenci a i sledování práce herního enginu by bylo pro vývojáře dosti obtížné. Zavádí se tedy synchronizace. Počet a účel vláken může být u herních enginů rozdíný. Jejich množina by mohla být asi takováto:

Hlavní vlákno – v každém tiku dle následujícího pořadí zpracovává herní vstupy od uživatele, herní logiku, síťové vstupy, skript, AI, management scénového grafu

Vlákno grafického renderu – v každém tiku vykreslí jeden snímek

Fyzikální engine – v každém tiku pohne fyzikálním světem o Pro své výpočty, může fyzikální engine používat několik dalších

vnořených vláken

Zvukový engine – pro zpracování některých softwarových řešených efektů, může obsahovat interní vlákna

Síťový kód – pro udržování a zpracování komunikace na nižších vrstvách využívá vlastní vlákno

Další vlákna – některé úkony, jež na sobě nejsou závislé, lze provádět paralelně. Používá se jako optimalizační prostředek.

2.8.3 Synchronizace scénového grafu a grafického renderu Hlavní vlákno a vlákno využívané renderem grafického enginu obvykle tikají v poměru 1:1. Pro synchronizaci obou vláken je použito synchronizační bariéry – čeká se, až obě vlákna dokončí svůj step. Změny vzniklé v hlavním vlákně se interpretují jako změny

23 Nebylo ani potřeba čas uvažovat, rozdíly v rychlosti zpracování nebyly tak markantní jako dnes, také

nároky her na výkon, byly v každém okamžiku téměř konstantní.

44

transformačních matic ve scénovém grafu, případně přidáním nebo odebráním jeho uzlů. Následuje příprava dat pro render, prohledáním scénového grafu a seřazením vybraných modelů ve vyhovujícím pořadí (viz kapitola Grafika a grafický engine, sekce Příprava dat pro render). Management scénového grafu (hlavní vlákno) pak předává data renderu. Po dokončení synchronizace dat uvolní hlavní jádro bariéru a obě vlákna vykonají další step.

2.8.4 Synchronizace scénového grafu s fyzikálním enginem Při popisu fyzikálního enginu a principu jeho fungování jsem uvedl důvody, proč fyzikální engine potřebuje vyšší časové rozlišení (kapitola Fyzika a fyzikální engine). Abychom ve hře byli schopni dodržet požadavky fyziky na časové rozlišení a současně vytvořit ve hře normální plynutí času, musíme zajistit, aby jednotlivé tiky herní fyziky byly co nejkratší24. Vlákno herní fyziky tiká několikanásobně rychleji v poměru k rychlosti hlavního vlákna. Tento poměr je odhadován na pět až deset tiků herní fyziky během jednoho snímku (tiku hlavního vlákna a renderu)25. Při každém tiku hlavního vlákna je zapotřebí aktualizovat scénový graf. Staré transformační matice modelů jsou nahrazeny nově vypočtenými transformačními maticemi těles reprezentujících tyto modely uvnitř fyzikálního enginu. Vlákna jsou synchronizována opět za pomocí bariéry či příznaku. V době mezi dvěma snímky pak fyzikální engine pracuje nad vlastní sadou dat, která nejsou do scénového grafu propagována, dokud to není zapotřebí (omezení nadbytečných paměťových operací).

2.8.5 Animační a fyzikální simulace Animační systém a fyzikální engine mají společnou základní myšlenku, oba mohou ovlivňovat objekty ve scéně (měnit transformační matice scénového grafu). Nezřídka pak může být jeden objekt ovlivněn jak fyzikou, tak animačním systémem. Existují dva případy, kdy se oba systémy setkávají. V prvním případě je na konkrétní entitu v herním světě aplikována fyzika a její grafický model je zároveň ovlivňován animačním systémem (postavička ve hře padá z výšky a mává u toho rukama). V druhém případě je současné ovlivňování objektů nepřípustné (animační systém pohybuje postavou jedním směrem, ale fyzikální simulace druhým) a často vzniká v takzvaných Cutscénách (Cutscene26), krátkých animovaných sekvencích produkovaných v herním enginu. Hra musí mít tedy zabudován mechanismus rozhodující o tom, který ze systémů může s objektem pohybovat.

Druhým případem, kdy se oba systémy setkávají, je fyzikální simulace s využitím kostry. Již jsem naznačil, že oba umí pracovat s kostrou, a upozorňoval jsem, že se nejedná o jednu a tu samou kostru (opět dle pravidla, že každý systém si udržuje svou reprezentaci objektu/entity). Existuje ale několik situací, kdy vývojáři záměrně tyto kostry ztotožňují. Příkladem nechť je oblíbený fyzikální Ragdoll efekt, tedy simulace „hadrové panenky“. Podstatou je, pohybovat kostrou na základě působení fyzikálních sil. Pohyb fyzikální kostry se pak může projevit na kostře, která je použita k animacím,

24 Pokud by tomu tak nebylo, fyzikální simulace by nebyla plynulá, ale skoková.

25 Tento poměr nemusí být konstantní po dobu běhu hry, v závislosti na návrhu synchronizačního

mechanismu. Udávaná hodnota se zakládá na reálných pozorováních a teoretickému výpočtu potřebného časového rozlišení. 26

Cutscene – doslova „střihová scéna“.

45

ale může to fungovat i naopak. Jeden z přístupů, jak toho docílit, využívá scénového grafu (kostra je tvořena podstromem), nebo jiné hierarchické struktury, k níž mají fyzikální i animační systém přístup. Další z přístupů integruje část animačního systému s fyzikálním systémem do jednoho celku. Příkladem spojení fyziky, animace a jednoduché umělé inteligence je systém Euphoria.

2.8.6 Systém událostí Doposud jsem mluvil o propojení jednotlivých systémů na úrovni dat, některé systémy ale potřebují spojení pomocí událostí. Události vznikají na mnoha místech na základě dění v herním světě. Některé systémy události vytvářejí, například herní logika a detekce kolizí fyzikálního enginu, jiné systémy pak mohou na události reagovat, například skript nebo zvukový engine. Každou událost lze spojit s některou entitou v herním světě a pomocí této entity lze definovat jakým způsobem se má vzniklá událost zpracovat. Obvyklými zdroji událostí jsou fyzikální engine s detekcí kolizí, systém vstupů uživatele a logika hry. Naproti tomu jsou obvyklými konzumenty (příjemci) událostí skriptovací engine a zvukový engine.

2.9 Umělá inteligence Většina her krom základní herní logiky obsahuje i systém autonomně reagující na dění v herním světe. Říkáme, že hra obsahuje umělou inteligenci, v angličtině ji pak často označujeme zkratkou AI (Artificial Inteligence). Systém umělé inteligence nebývá běžnou součástí herního enginu a jedná se o celek tvořící, podobně jako skriptovací engine, vyšší úroveň herního kódu. Samotný pojem umělá inteligence zahrnuje celý vědní obor a některé definice značně převyšují a liší se od toho, co je používáno pro počítačové hry. Umělá inteligence v počítačových hrách je jen jakési napodobení hry lidského hráče. Pojmout všechny principy fungování herní AI by bylo nad rámec této práce a tak jen některé nastíním.

Systém umělé inteligence má dvě úlohy. První úlohou je poskytnutí podpůrných funkcí, které jednorázově řeší základní úkoly pomocí relativně jednoduchých algoritmů. Asi nejvíce zmiňovaným úkolem je takzvaný Pathfinding, hledání cesty. Druhou úlohou je simulace komplexnější inteligence, která dokáže reagovat na různé podněty. Příkladem může být inteligence takzvaných agentů nebo NPC (Non-Player Charakter, postava neovládaná hráčem), nebo inteligence pro strategické hry.

2.9.1 Pathfinding Pathfinding je souborné označení algoritmů, jež řeší problém nalezení cesty z bodu A do bodu B skrze prostor obsahující překážky. Jedná se o typickou úlohu, kterou potřebuje řešit většina 3D her napříč všemi žánry. Lidé řeší tuto úlohu pomocí paměti, zkušenosti a úsudku, čímž herní AI nedisponuje a je zapotřebí jí vypomoci. Pro všechna obvyklá řešení je zapotřebí, abychom AI umožnili alespoň základní orientaci v prostoru. Prostor, ve kterém se AI může pohybovat, lze vyjádřit například jako ohraničenou plochu složenou z konvexních polygonů, nebo jako neorientovaný graf (Waypoint Graph27). Pathfinding je často řešen variacemi algoritmů Dijkstra, A*, Bellman-Ford a dalších.

27 Waypoint – navigační bod na vytýčené trase.

46

Obrázek 2.17: Síť waypointů

Obrázek 2.18: Ohraničená plocha – soustava konvexních

polygonů (Převzato z blogu Game/AI - http://www.ai-blog.net/)

Pro další informace o technice využívající plochy z konvexních polygonů doporučuji práci Automatically-generated Convex Region Decomposition for Real-time Spatial Agent Navigation in VirtualWorlds (6), od kolektivu autorů z

2.9.2 Stavové automaty V mnoha případech je AI založena na konečných stavových automatech. Každý ze stavů takového automatu představuje nějakou aktivitu a v tomto stavu AI setrvává, dokud nejsou splněny podmínky pro přechod do stavu jiného. V rámci jedné aktivity AI vykonává stále se opakující sekvenci úkonů. Tento koncept byl poprvé použit pro strategické hry, kde byla jednotkám propůjčena jednoduchá třístavová logika (čekej, pohybuj se, bojuj). Čím více stavů a přechodů mezi nimi použijeme, tím rozmanitější AI získáme. Užití stavového automatu vytváří z části deterministickou AI. Hodí se jak pro již zmíněné strategické hry, tak i pro složitější NPC pro hry žánru RPG28 či FPS.

2.9.3 Vnímání okolí U starších (a některých současných) her jsme se mohli setkat s tím, že počítačový protihráč využíval informace, jež hráč neměl k dispozici, a tím získával nad živým hráčem. Současným trendem je vytvořit pro AI „spravedlivé“ vnímání světa. Negativem je o něco větší náročnost (například při použití trasování okolí).

2.9.4 Variabilita a (ne)determinismus Tlak na vývoj uvěřitelnějších AI se stále zvětšuje, zejména v žánrech Real-Time strategií

a FPS vyžadují hráči větší variabilitu a nepředvídatelnost. Jedním způsobem, jak toho

dosáhnout, je rozvinutí stávajících postupů – komplexnější stavové automaty a větší

množina podnětů. AI nové generace se učí vnímat nejen své okolí, ale také

spolupracovat v týmu a sledovat postup ostatních hráčů. Druhým způsobem je rozšířit

stávající postupy o další. Můžeme uvažovat o použití náhodných faktorů nebo předešlé

28 RPG – Role Playing Game, často překládané jako hra na hrdiny. Role Playing – hraní v roli.

http://www.ai-blog.net/

47

zkušenosti při procesu rozhodování. Některé hry používá genetické algoritmy nebo

neuronové sítě pro vytvoření AI, která se je schopná učit a měnit své „návyky“.

2.9.5 Skript a programovatelnost AI Některé herní enginy umožňují rozšířit schopnosti AI o akce definované pomocí skriptů. Herní skript pak může ovlivnit rozhodován, upravit aktivity nebo změnit strukturu stavového automatu. V tomto ohledu opět záleží na tom, co herní vývojáři umožní. Alternativou k použití skriptů je podpora pro vlastní naprogramované AI. Enginy, které tuto funkčnost obsahují, poskytují herním vývojářům přístup k aplikačnímu rozhraní a umožní vložit vlastní program AI, který bude skrze toto rozhraní komunikovat a interagovat v herním světě. Příkladem enginu s podporou skriptovatelné AI je CryENGINE, programovatelnou AI podporuje konkurenční Unreal Engine.

48

3 Závěr

3.1 Zhodnocení Tuto práci jsem věnoval tématu počítačových her a popisu hlavních celků, ze kterých se skládají. Rozhodl jsem se strukturovat text jako úvod do problematiky tvorby počítačové hry a zaměřil jsem se na teorii a principy fungování herního enginu. Jednotlivým částem herního enginu jsem přiřadil priority dle vlivu na celkové vyznění hry. Takto stanoveným prioritám jsem podřídil délku a podobu jednotlivých kapitol.

V každé tematické části textu jsem poskytl úvod do dané problematiky a teoretický základ popisující funkčnost konkrétní části herního enginu. Nebylo mým cílem a ani mi to rozsah práce neumožňoval, abych se věnoval všem relevantním technikám či postupům. Proto je třeba v některých ohledech četbu kombinovat s úžeji profilovanou literaturou k daným tématům (grafika, fyzika, zvuk atd.).

Nejvíce prostoru jsem věnoval grafice a grafickému systému. Abych zpřístupnil text i těm čtenářům, kteří nejsou s problematikou obeznámeni, vytvořil jsem stručný teoretický úvod k tématu herní 3D grafiky. Důraz je kladen na techniky spjaté s texturováním a materiály, které jsou jedním z témat současného trendu zvyšování vizuální kvality směrem k fotorealistickému ztvárnění počítačových her.

Zkoumáním zadaného oboru a postupným shromažďováním poznatků o herních enginech jsem zkonstatoval, že v zadání položená otázka vlivu herních žánrů na technologický základ počítačové hry je irelevantní a nelze na ni v kontextu práce odpovědět. V souvislosti s postupným posunem záměru práce se i zpracování posunulo směrem k deskriptivnímu textu a změnilo se jeho vyznění. Současná podoba bude doufám bližší pro ty čtenáře, kteří se zajímají o vývoj počítačových her.

Obor počítačových her je v současné době velice konkurenční a mnohé informace o konstrukci počítačových her současnosti jsou přísně utajovány a je velice složité je získat. Proto je důležité mít na paměti, že informace uvedené v této práci mohou být velice obecné a některé reálné herní enginy se mohou velice lišit od konstrukcí, které jsem popsal. Snaha o získání výhody v konkurenčním prostředí zapříčiňuje velkou rozmanitost řešení, které nelze všechny obsáhnout v jednom textu, a dá se s větší davkou nadsázky říci, že většina myslitelných postupů již byla někým vyzkoušena a použita.

3.2 Další možné pokračování Vzhledem k šíři tématu, jakým jsou počítačové hry a herní enginy, lze jen podpořit myšlenku dalšího rozšiřování tohoto textu. Pro část Grafika a grafické enginy by bylo možné zpracovat téma volumetrických efektů, HDR a popis stínovacích technik. Dále by pak bylo možno rozebrat možnosti dynamické Sekci Fyzika a fyzikální engine dále rozšířit o téma deformací a deformačních modelů nebo fyzikou řízené animace. Umělé inteligenci bylo v této práci úmyslně věnováno méně prostoru, a tudíž by bylo možné rozšířit i toto téma. Další části by se mohly věnovat podpoře síťové hry či podpůrným nástrojům pro herní enginy. Tento záměr však přesahuje formát této bakalářské práce.

50

4 Seznam Literatury

5 Bibliografie 1. Kaneko, Tomomichi, a další. Detailed Shape Representation with Parallax Mapping. místo neznámé : Sborník International Conference Artificial Real Existence .

2. Donnely, William. GPU Gems 2. s.l. : University of Waterloo.

3. Zhang, Hansong. Effective Occlusion Culling for the Interactiove Display of Arbitrary Models. s.l. : The University of North Carolina at Chapel Hill, 1998.

4. James, Doug L. a Twigg, Christopher D. Skinning Mesh Animations. místo neznámé : Carnegie Mellon University.

5. Melax, Stan. BSP Collision Detection As Used In MDK2 and NeverWinter Nights. místo neznámé : Gamasutra, 2001.

6. Hale, D. Hunter, Youngblood, G. Michael a Dixit, Priyesh N. Automatically-generated Convex Region Decomposition for Real-time. Charlotte, NC : The University of North Carolina at Charlotte - .

7. Bergman, Albert S. Auditory scene analysis. Cambridge, MA : MIT Press , 1990.

8. Boer, James. Game Audio Programing.

9. Slivoň, Ing. Petr. Zobrazovací jádro pro vizualizaci třírozměrných dat v reálném čase. Praha : České vysoké učení technické, 2008.

10. Wikipedia. www.wikipeda.org.

11. Devmasters. www.devmasters.com.

12. Gamasutra. www.Gamasutra.com.

13. GameDev. www.GameDev.net.

51

Dodatek A – Herní enginy

Vývoj počítačových her a videoher je dnes velkým odvětvím zábavního průmyslu a jeho růst vede k produkci velkého množství herních enginů. Obvykle je na ně pohlíženo dle určení jako na herní enginy pro vývoj velkých herních projektů a na enginy určené pro vývoj casual her29 a hobby komunitu.

Seznam několika současných významných herních enginů:

Aurora Engine / Odyssey Engine (BioWare)

CryENGINE 1 a 2 (Crytek)

C4 Engine (Terathon Software)

DreamWorld Engine (Funcome)

Gembryo (Emergent Game Technologies)

Id Tech 4 a 5 (id Software)

Illusion Engine (Illusion Softworks / 2KCzech)

Infinity Engine (BioWare)

JupiterEX (Touchdown Entertainment)

Offset Engine (Intel)

RAGE (Rockstar Games)

Serious Engine 1 a 2 (Croteam)

Shark3D (Spinor)

Source Engine (Valve)

Tourque Game Engine (Garage Games)

Unreal Engine 1, 2 a 3 (Epic Games)

V následující tabulce si porovnáme několik vybraných enginů.

29 Casual Games - hdy určené příležitostným hráčům, nekomplikované, jednoduché strukturou.

52

Následuje krátký popis dvou současných nejvyspělejších herních enginů. Uváděné informace jsou výtahem z informací udávaných přímo výrobcem daného enginu doplněné o informace z dalších veřejných zdrojů a mají především ilustrativní účel.

Unreal Engie 3.0

Výrobce: Epic

Popis: Jeden z technologicky nejpokročilejších a nejvýznamnějších herních enginů dnešní doby. Navazuje na úspěchy svých předchůdců a je jedním z nejpoužívanějších herních enginů vůbec.

Dostupnost: UE3 je komerční produkt, jež si lze zakoupit ve formě licence k vývoji hry. Cena je utajována (odhaduje se na více než 700000 USD).

Grafický engine:

Gemini Pod tímto názvem se skrývá velice mocný grafický engine s pokročilým vícevláknový rednerem. Mezi zvláštní vlastnosti patří

- Bezkonkurenční škála efektů

- Pokročílé techniky stínování

- Volumetrické efekty

- Dynamické určování viditelnosti

- Plná integrace technologie SpeedTree (IDV)

- Obsahuje velmi pokročilý particle systém Cascade

Fyzika:

nVidia PhysX Poskytuje:

- Fyzikální simulaci tuhých těles (Rigid Body)

- Simulaci oděvů a látek (Cloth Simulation)

- Simulaci netuhých těles (Soft Body simulation)

- Systém pokročilých definic materiálů – fyzikální tření,

přiřazení zvuku a effectů

- Na fyzice založené animace

Skrze rozhraní PhysX dostává většina her postavená na UE3 možnost hardwarové akcelerace fyziky30.

Zvuk

Vvyužívá vlastní 3D zvukový engine a vlastní sadu softwarových DSP efektů. Poskytuje pokročilé možnosti práce s komprimovaným zvukem.

Animace

Unreal Animation Poskytuje:

- Skeletární animace s podporou vlivu až čtyř kostí na jeden

vrchol

- Plná podpora LOD (Level of Detail) pro mesh i kostru

30 Více informací k technologii PhysX lze nalézt na http://www.nvidia.com/object/nvidia_physx.html

http://www.nvidia.com/object/nvidia_physx.html

53

- Blending animací – využívá hierarchického stromu k definici

prolínání animací

V souvislosti s animacemi obsahuje UE3 systém Matinee – poskytující lepší vládu nad animacemi na úrovni klíčových snímků

Skript UnrealScript - Syntaxe založená na jazyku C++

- Silný objektový návrh

- Managed code a Garbage Collection

- Vestavěný překladač

Kromě již jmenovaných PhysX (nVidia) a SpeedTree (IDV) obsahuje technologie Bink Video (RAD Game Tools) nebo FaceFX (OC3 Entertainment). Mnohé další jsou pak součástí partnerského programu Unreal Engine 3 IPP31.

Informace o enginu byly převzaty ze serveru Unreal Technology32.

Ukázka schopností grafické technologie Unreal Enginu 3 – oficiální obrázek společnosti Epic Games.

31 Aktuální seznam participujících společností naleznete na http://www.unrealtechnology.com/partner-

program.php 32

Unreal Technology - http://www.unrealtechnology.com

http://www.unrealtechnology.com/partner-program.php

http://www.unrealtechnology.com/partner-program.php

http://www.unrealtechnology.com/

54

CryENGINE 2

Výrobce: Crytek

Popis: Komplexní herní engine zaměřený na fotorealistický obraz a simulaci okolního prostředí. Je zaměřen především na hry žánru FPS. Návrh je zaměřen na podporu vývoje her za použití minima progamování – mnoho věcí je přístupno desingerům pomocí skriptu či podpůrných vizuálních nástrojů.

Dostupnost: Jedná se o komerční produkt, jež si lze zakoupit ve formě licence k vývoji hry. Cena je utajována

Grafický engine: Tento grafický engine nebosahuje tolik funkcí jako konkurenční Unreal Engine, zato je znám pro vysokou technologickou úroveň a schopnostmi velmi realistického vykreslování. Další zatím nejmenované chopnosti:

- Light Beams and Shafts – tvorba světelných paprsků a

„sloupců stínu“

- Pokročilá technologie shaderů – využívá v plné míře

možností DirectX 10, skriptovatelné shader efekty

- Technologie 3D oceánů – velice pokročilá simulace vody a

vodních ploch, včetně mnoha fyzikálně věrných efektů

- 2.5D okluzní mapy

- Volumetrické efekty

Fyzika: proprietární fyzikální engine umožňující: - Simulaci chování vozidel

- Fyziku tuhých těles

- Simulaci tekutin

- Ragdoll efekty

- Simuluje pohyb oděvů a netuhých těles

Zvuk: Proprietární zvukový systém. Umožňuje vytvářet velice přesné přechody mezi různými prostředími. Interaktivní hudební systém reagující na herní události.

Animace: K běžným schopnostem animačního systému přidává například animace tváří a upravuje animace postav s ohledem na přirozenost pohybů. Na fyzice založené animace.

Umělá inteligence: Obsahuje velice zdařilou týmovou AI. Logiku a chování AI lze měnit na základě skriptů

Skript: Založen na oblíbeném jazyce LUA.

55

Podrobnější informace o CryENGINU 2 i jeho předchůdci můžeme nalézt na webových stránkách společnosti Crytek33. Další informace lze získat z komunitního webu InCrysis34 zaměřené na počítačovou hru Crysis (Crytek), která jako první používala CryENGINE 2.

Schopnosti CryENGINE - Simulace lomu světla v příbojových vlnách

Ukázka ze hry Crysis – CryEngine

33 CryENGINE - http://www.crytek.com/technology/cryengine-2/specifications/

34 InCrysis - http://www.incrysis.com

http://www.crytek.com/technology/cryengine-2/specifications/

http://www.incrysis.com/

56

Dodatek B – Programové celky pro reprodukci zvuku v počítačových hrách.

DirectSound Jsou součástí DirectX společnosti Microsoft. Jeho součástí jsou i funkce pro práci se zvukem v 3D prostoru (DirectSound3D). Zajišťuje abstrakci nad zvukovým hardwarem a umožňuje využít akceleraci zvukových efektů třetích stran, pomocí rozšíření dostupných pomocí sad vlastností. Pro prostorový zvuk již implementuje základní algoritmy jako je Audio Panning, Rollof efekt, Dopplerův efekt, HRTF a MacroFX. Podporuje vícekanálový zvuk i reprodukci pro vícekanálové reproduktorové soustavy. Vytváří podobu zvukové scény, nepracuje však z geometrií scény a nezpracovává překážky. V současné době je jeho vývoj označen za zastavený a společnost Microsoft ho nahrazuje systémem XAudio.

XAudio 2 a XACT XAudio 2 vychází z původního zvukového systému XAudio pro herní konzoli Xbox společnosti Microsoft. Jeho druhá generace je multiplatformní a je implementován pro Xbox360 a Windows XP/Vista. XACT je pak aplikačním rozhraním a zvukovým enginem, jež využívá služeb XAudio 2 a X3DAudio. Součástí technologie XACT jsou pak i nástroje určené pro designéry (XACT Authoring tool).

OpenAL Projekt společnosti Loki Software, později uvolněn pro Open Source komunitu, v současné době spravován a propagován společností Creative Technology. Vytváří plnohodnotnou alternativu k DirectSound a DirectSound3D. Je multiplatformní a rozšiřitelný o extense. Je velice oblíbené a bylo například použito jako základ pro zvukový engin v Unreal Engine 2 a 3 a tedy i všechny hry na těchto enginech založené. OpenAL je vyvíjeno s podobnou strukturou jakou má grafické rozhraní OpenGL.

FMOD Je vyvíjen společností Firelight Technologies jako komerční projekt. FMOD je komplexní, multiplatformí zvukový systém. Využívá vlastního softwarového DSP pro aplikování efektů, tak i vlastního zvukového renderu. Přesto umožňuje zařadit do řetězce zpracujícího zvuk i hardwarově akcelerované efekty pomocí rozhraní OpenAL (dříve DirectSound3D). Podporuje vícekanálový zvuk i reprodukci pro vícekanálové reproduktorové soustavy, využívá dvourozměrné mřížky (2D Matrix) pro umístění zvukového vstupu (zpracovaný zvuk vstupující do renderu) v prostoru. Je rozšiřitelný pomocí systému zásuvných modulů. Poskytuje událostmi řízené prostředí umožňující designérům snadněji pracovat se zvukovou scénou. Interactive Music pak poskytuje možnost plynule přecházet od jedné hudební nahrávky k jiné, pracuje s rytmikou skladeb (možné použít třeba při přechodu od klidné hudby k akčnímu podkreslení bojové scény). Zpracovává geometrii scény a umožňuje zpracovat překážky. Je velmi oblíbený a byl použit v několika zásadních herních titulech poslední doby, jako jsou Crysis, BioShock, Age of Conan, Little Big Planet a další. Společnost Firelight Technologies je pak technologickým partnerem tří současných hlavních výrobců herních enginů, Unreal, GarageGames, Crytek.

57

Miles Sound System Patří do skupiny nástrojů RAD Game Tools stejnojmenné společnosti. Podobně jako FMOD jde o komplexní řešení pro 2D a 3D ozvučení s dlouholetou tradicí. Je multiplatformní a podporuje všechny hlavní herní systémy současnosti. K reprodukci (renderování) používá vlastní softwarový směšovač (Miles Mixer), ale může použít i DirectSound3D a akcelerovat audio na DS3D kompatibilním hardwaru. To poskytuje vývojářům výhodu, jelikož se nemusí starat o to, zdali jsou hráči vybaveni správným zvukovým hardwarem, a umožňuje jim poskytovat prostorový zvuk oběma způsoby. O zpracování prostorového zvuku se pak stará technologie Intel RSX, kterou RAD Game Tools odkopila a integrovala do MSS. Implementuje zpracování Dopplerova efekt, Cross Talk Cancellation, True 3D Sound (variace technologie HRTF) a jiné. Zvuk reprodukuje pro většinu běžných reproduktorových konfigurací (včetně Dolby Surround, DTS, SRS Circle Surround® a další). Implementuje podporu technologie EAX a je rozšiřitelný o efekty pomocí systému zásuvných modulů (zde označovaných jako Filter Processors). Součástí Miles Sound Systém je sada nástrojů pro vývojáře i designéry. Obsahuje softwarový syntetizátor. Je často používaný, zejména i z historických důvodů, a můžeme ho najít ve hrách, jako jsou Warcraft III, The Elder Scrolls IV Oblivion, RPG hry od Bioware jako NeverWinter Nights a Star Wars: Knight of The Old Republic a v neposlední řadě i série Call of Duty.

IrrKlang Ukázkou středu mezi nízkoúrovňovými rozhraními a komplexními zvukovými enginy je projekt IrrKlang rakouské společnosti Ambiera Software Development. Je multiplaformní a poskytuje rozhraní pro tradiční jazyky jako C++, tak i pro jazyky .Net (takzvaný Managed Code). Pro platformu Windows využívá služeb DirectSound a má vlastní systém pro tvorbu prostorového zvuku. V současnosti neumožňuje hardwarovou akceleraci efektů a přístup k technologii EAX. Je používán zejména nezávislými vývojáři a nadšenci (pro které je zdarma k použití).

58

Dodatek C – Ukázka užití dostupných programových celků

Doprovodná aplikace má za úkol demonstrovat možnosti využití dostupných programových celků, jako je grafický, fyzikální, nebo zvukový engine. Po úvaze byla zvolena kombinace grafického a fyzikálního enginu pro svou atraktivitu a dobrou názornost.

Výběr technologie Výběr možných systémů jsem omezil na volně dostupné pro soukromé a akademické využití. Převážnou jejich část tvoří systémy s volně šiřitelnými zdrojovými kódy. Jako podmínku jsem si dal dostupnost (i za použití wrapperů) pro programovací jazyky .Net (C# a Visual Basic.Net), jelikož je považuji za přehlednější a přívětivější než nativní jazyky (C++, VB, Delphi). Cílovou platformou jsou pak osobní počítače s operačním systémem Microsoft Windows za použití grafického API OpenGL nebo DirectX. Objektový model přínosem.

Při sestavování možných kandidátů jsem použil internetové zdroje DevMasters, Wikipedia a diskusní fóra věnující se problematice vývoje počítačových her. Mezi vhodné grafické enginy jsem zařadil tyto tři:

- Axiom - Horde3D - IrrLicht - OGRE / MOGRE

Pro fyzikální simulace jsou to tyto:

- Bullet - Newton Game Dynamics - Open Dynamics Engine (ODE)

V případě grafických enginů IrrLicht a OGRE pak existuje řada rozšiřujících rozhraní umožňujících využití různých fyzikálních systémů. Zvolil jsem jedno z těchto řešení založené na kombinaci OGRE a Newton Game Dynamics, konkrétně pak MOGRE a MogreNewt.

Aplikace Aplikace je psaná v jazyce VisualBasic.Net. Zdrojové kódy a soubor projektu je určen pro Microsoft Visual Studio 2008.

Instalace Aplikace je dodána v nezabalené podobě bez potřeby instalace a stačí ji jen pustit pomocí souboru „CVUTBoulder.exe“. Pro běh aplikace je potřeba .Net Framework 3.5 a DirectX 9 a instalační balíčky jsou přiloženy k aplikaci.

Záměr Cílem aplikace je vytvořit jednoduchou fyzikální simulaci a zobrazit ji. Ve scéně je umístěn zvrásněný povrch (plastické logo ČVUT) a na něj dopadá svítící koule. Uživatel

59

může na scénu přidávat další objekty, které mají různé tvary a textury a fyzikálně reagují na povrch i na ostatní objekty.

Nastavení Aplikace využívá standardního dialogu OGRE enginu k nastavení renderu. Na výběr je ze dvou rendrovacích systémů Direct3D Rendering Subsystem a OpenGL Rendering Subsystem. Po zvolení se zpřístupní doplňující nastavení pro daný renderovací systém.

Ovládání simulace Ovládat lze ukázku pomocí klávesnice a myši. Můžeme ovládat pohyb kamery kolem scény a pohyb svítící koule uvnitř scény.

W, A, S, D – Posun kamery

Šipky – Natáčení kamery

Num8, Num4, Num6, Num2 – Pohyb koule dopředu, dozadu a do stran

Num5 – Pohyb koule vzhůru

Mezerník – Přidání nových objektů

Escape – Ukončení aplikace

60

PrintScreen – Vytvoří snímek

R – Změna způsobu vykreslování (body, drátěný model, celistvé)

T – Změna způsobu filtrování (billinearní, trilineární, anizotropní)

B – Vykreslení hraničních boxů

F3 – Vykreslení pomocných čar pro fyziku

akalářská práce popis programových celků pro tvorbu ... · adam prchlík vedoucí práce:...

Documents