Zadán´ı bakalárské práce - ExtBrain

Zadání bakalářské práce

České vysoké učení technické v Praze
Fakulta elektrotechnická
Katedra počítačové grafiky a interakce
Bakalářská práce
Webová platforma pro interakci uživatelů v 3D
prostoru
Ondřej Psota
Vedoucí práce: Ing. Tomáš Novotný
Studijní program: (BN2)Softwarové technologie a management,
Bakalářský
Obor: (2612R062)Web a multimedia
28. května 2012

Poděkování
Rád bych poděkoval svému konzultantovi a vedoucímu práce panu Ing. Tomášovi Novotnému
za jeho cenné rady a vstřícný přístup při řešení problémů. Dále bych chtěl rovněž poděkovat
všem, kteří mi byli nápomocni a vytvořili podmínky pro to, abych se své práci mohl plně
věnovat.
iii

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 28. května 2012 ...............................................................................................
v

Abstract
This work deals with creating a web platform using the WebGl technology. The web platform
should be designed with regard to its future development. Objectives and requirements of
the web platform are determined. There is a description of selected technologies enabling
to display 3D graphics in a web browser and the current solution in the form of WebGl
frameworks is evaluated. The procedure is that the solution is analyzed and proposed with
regard to the requirements based on the needs of the resulting application where the user is
located in the space environment with asteroids and compete with other users.
The test did not reveal any significant shortcomings of the application. The application
mostly appeared to be stable. Problems have been resolved with the recording of objects in
the scene. Basic collisions, physics, network communication and many more features were
implemented. A good basis was created on which it could be built in the future. Some gaps
could be found in the scene lighting and some other imperfections.
Abstrakt
Tato práce se zabývá tvorbou webové platformy v technologii WebGl, která by měla být
navržena s ohledem na její budoucí vývoj. Jsou stanoveny cíle a požadavky na webovou
platformu. Dochází k popisu vybraných technologií umožňujících zobrazení 3D grafiky ve
webovém prohlížeči a hodnotí se stávající řešení v podobě WebGl frameworků. Postup je
takový, že se analyzuje a navrhuje řešení s ohledem na požadavky, které vycházejí z potřeb
výsledné aplikace, kde se uživatel nachází v prostředí vesmíru s asteroidy a závodí s jinými
uživateli.
Test neobjevil významné nedostatky aplikace, která se vesměs jevila jako stabilní. Byly
vyřešeny problémy s nahráváním objektů do scény, naimplementovány základní kolize, fyzika,
sít’ová komunikace a mnoho dalších. Podařilo se vytvořit dobrý základ, na kterém lze v
budoucnosti stavět. Určité mezery lze najít v osvětlení scény a některých nedokonalostech.
vii

viii

Obsah
1 Úvod 1
2 Popis problému 2
2.1 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Požadavky na ukázkovou aplikaci . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Požadavky na webovou platformu . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Popis vybraných technologií 4
3.1 Technologie pro zobrazení 3D grafiky ve webovém prohlížeči . . . . . . . . . . 4
3.1.1 VRML a X3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2 Flash (Stage 3D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.3 Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Technologie WebGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Specifikace API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2 Názorná ukázka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.3 Výsledek názorné ukázky . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Technologie WebSockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1 WebSocket protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2 Použití API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
ix

4 Analýza a návrh řešení 10
4.1 Stručný přehled WebGl frameworků . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Architektura platformy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1 Inspirace pro návrh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2 Privátní proměnné . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.3 Přehledový diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.4 Objekt GameObject . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.5 Komponenty objektu GameObject . . . . . . . . . . . . . . . . . . . . 13
4.2.6 Nahrání dat do scény . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.7 VirtualWorld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.8 Shadery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.9 Vstup z klávesnice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Obalová tělesa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.1 Obalová koule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2 OBB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.3 AABB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4 Testy kolizí mezi tělesy . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.5 Objekt Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Základní fyzikální systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.1 Integrační metoda rigidního tělesa . . . . . . . . . . . . . . . . . . . . 27
4.4.2 Pružina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.3 Registr působících sil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Rozdělení prostoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5.1 Mřížky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.2 Stromy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.3 Řadící mechanismy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5 Realizace 34
5.1 Herní smyčka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.1 RequestAnimationFrame API . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2 Použití RequestAnimationFrame API v aplikaci . . . . . . . . . . . . . 36
5.2 Průhlednost objektů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.1 Z-buffer a jeho nevýhody . . . . . . . . . . . . . . . . . . . . . . . . . 37
x

5.2.2 Vykreslení průhledných objektů . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Viditelnost objektů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.1 View frustum culling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.2 Backface culling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4 Multiplayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4.1 Známé architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4.2 Implementace multiplayeru v ukázkové aplikaci . . . . . . . . . . . . . 40
5.5 Generátor asteroidů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5.1 Algoritmus pro generování asteroidů . . . . . . . . . . . . . . . . . . . 42
5.5.2 Problém s generováním více asteroidů . . . . . . . . . . . . . . . . . . 43
5.6 Laser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6.1 Billboarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6.2 Nejpoužívanější typy billboardů . . . . . . . . . . . . . . . . . . . . . . 45
5.6.3 Tvorba laseru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6 Testování 47
6.1 Uživatelský test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2 Test aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7 Závěr 49
A Balíky platformy 54
B Celkový UML diagram 56
C Uživatelská příručka 58
C.0.1 Ovládání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
C.0.2 Hra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
D Obsah přiloženého CD 64
xi

xii

Seznam obrázků
3.1 Výsledný čtverec na černém pozadí . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 GameObject a možné komponenty . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Obrázek znázorňuje objekty, které mezi sebou komunikují, pokud nastane
změna v komponentě Transform a nebo v objektu GameObject. . . . . . . . 14
4.3 Komponenta NetworkView a všechny důležité třídy se kterými spolupracuje. 16
4.4 Obrázek znázorňuje načtení geometrických objektů do scény včetně materiálů
a textur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Mesh renderer, přiřazený mesh, buffery a materiály . . . . . . . . . . . . . . 19
4.6 Objekt VirtualWorld se všemi objekty, na které si drží referenci. . . . . . . . 20
4.7 Všechny objekty a konstruktory, které v platformě mají na starosti shadery. . 21
4.8 Objekt Input s přidruženými objekty . . . . . . . . . . . . . . . . . . . . . . . 22
4.9 Nejpoužívanější obalová tělesa. Převzato z [13] . . . . . . . . . . . . . . . . . 23
4.10 Nalezený OBB ve 2D. Převzato z [15] . . . . . . . . . . . . . . . . . . . . . . 25
4.11 Ukázka kolize OBB s koulí. Převzato z [12] . . . . . . . . . . . . . . . . . . . 26
4.12 (a) Buňky jsou moc malé. (b) Buňky jsou zbytečně velké. (c) Buňky jsou velké
s ohledem na velikost objektu. (d) Buňky jsou moc velké a zároveň moc malé.
Převzato z [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.13
Číslování jednotlivých potomků stromu. Převzato z [13] . . . . . . . . . . . . 31
4.14 Minimální a maximální body jednotlivých AABB v dané ose jsou seřazeny dle
velikosti. Převzato z [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.15 Na obrázku vidíme objekty, které se nacházejí kousek od sebe v jedné ose.
Pouze malý pohyb objektu může způsobit, že se hodnota uložená v seznamu
posune o mnoho pozic. Převzato z [13] . . . . . . . . . . . . . . . . . . . . . . 32
5.1 Rozdíl ve výkonu mezi setTimeout a RequestAnimationFrame API. Převzato
z [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Některé verze prohlížečů implementují API již nějakou dobu, jiné prohlížeče
naopak API zatím ignorují a nebo ho připravují v budoucích verzích. Převzato
z [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3 a) Obrázek znázorňuje chyby ve vykreslení, pokud nejsou průhledné objekty
seřazeny. b) Průhledné objekty jsou seřazeny. . . . . . . . . . . . . . . . . . . 38
5.4 a) Počáteční koule rozpůlená rovinou. b) Koule je rozpůlena jinou rovinou.
Vertexy před rovinou se posunuly směrem ke středu a vertexy za rovinou
směrem od středu. c) Výsledek po několika iteracích. . . . . . . . . . . . . . . 43
5.5 Billboardy orientované směrem k pozorovacímu bodu . . . . . . . . . . . . . 45
5.6 Laser z ukázkové aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
xiii

A.1 Balíčky, které strukturují zdrojový kód . . . . . . . . . . . . . . . . . . . . . . 54
B.1 Celkový uml diagram, který obsahuje všechny důležité třídy (konstruktory) . 56
C.1
Úvodní obrazovka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C.2 a) Okno, které se objeví po stisknutí klávesy S v úvodním okně. b) Okno
informující o stavu scény po jejím spuštění. Pomocí tlačítka Uložit scénu lze
uložit aktuální stav scény. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C.3 a) Okno, kde se uživatel může připojit jako nový hráč. b) Okno, kde si uživatel
může vybrat ze seznamu odpojených hráčů a přebrat jeho vesmírnou lod’. . . 60
C.4 Okno se scénou. Vlevo nahoře je vidět vzdálenost uživatele od středu, rychlost
a uplynulý čas od průletu první brány. Vpravo nahoře se objevují informace
o nově připojených nebo odpojených hráčích. . . . . . . . . . . . . . . . . . . 61
D.1 Výpis souboru readme.txt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
xiv

1 Úvod
Současný technologický vývoj umožňuje vytvářet aplikace spustitelné ve webovém prostředí,
které se svým vzhledem a chováním blíží desktopovým aplikacím. Přesně takovou technologii
představuje WebGl[6], pomocí které lze docílit velice zajímavých výsledků v oblasti počítačové
grafiky. Velkou výhodou technologie WebGl je možnost vytváření vlastních shaderů, s
jejichž pomocí lze docílit efektů, které jsme si dříve ve webovém prohlížeči nedokázali ani
představit. I přesto, že se objevují konkurenční technologie, které jsou schopné dosáhnout
obdobných výsledků, má WebGl tu výhodu, že případnou aplikaci lze spustit, aniž by bylo
nutné instalovat doplněk do webových prohlížečů. Jedná se o novější technologii, a proto není
podporována jejich staršími verzemi. Bohužel podpora Internetu Exploreru zatím chybí.
Cílem této bakalářské práce je navrhnout a naimplementovat webovou platformu umožňující
interakci uživatelů v 3D prostoru pomocí WebGl, které vychází z OpenGl ES 2.0[5].
Implementované vlastnosti dané platformy budou demonstrovány na ukázkové aplikaci. Koncový
uživatel bude moci ovládat vesmírné plavidlo a pohybovat se mezi asteroidy či jinými
objekty. Serverová komponenta umožní vzájemnou interakci uživatelů a sdílení jejich scény.
Aby si uživatelé mohli vyzkoušet ovládání plavidla a celkově si vychutnat možnosti vytvořeného
virtuálního prostředí, bude pro ně připraven jednoduchý závod. Kontrolní body ve
formě hvězdných bran zajistí hladký průběh závodu. Plavidla budou moci kolidovat s okolními
předměty a reagovat na kolizi. Vývoj platformy se bude odvíjet s ohledem na požadavky
ukázkové aplikace.
V kapitole 2 se definují požadavky na výslednou platformu včetně ukázkové aplikace.
Kapitola 3 se zabývá popisem technologií, které se používají k zobrazování 3D grafiky ve
webovém prohlížeči. Především jde o VRML, Stage3D a Unity. Dále se zaměřuje na základní
stavební prvky WebGl a přibližuje technologii WebSockets[8]. V kapitole 4 se provádí analýza
možností řešení a dochází k návrhu jednotlivých prvků platformy. Kapitola 5 popisuje
detailněji zajímavá či neobvyklá řešení, která se týkají vývoje ukázkové aplikace na navržené
platformě. V kapitole 6 jsou shrnuty poznatky, které vyplynuly z testování aplikace.
1

2 Popis problému
V podkapitole 2.1 je obecně popsán cíl práce a možnosti využití vytvořené platformy. V
podkapitolách 2.2 a 2.3 se kladou požadavky, které by měly výsledná platforma a ukázková
aplikace splňovat.
2.1 Cíl práce
Cílem práce je navrhnout a naimplementovat základ webové platformy pro interakci uživatelů
v 3D prostoru pomocí technologie WebGl. Očekává se, že tato platforma bude nadále
rozvíjena a postupně rozšiřována. Ve výsledku by mohla například sloužit jako součást či
doplněk výuky, jejíž pomocí by studentům byla názorně předváděna funkce určitých zařízení.
Pohyb pístů motoru by si dokázali ihned lépe představit. Samozřejmě se najde širší
oblast působnosti. Jak již bylo zmíněno v úvodu 1, vlastnosti platformy budou demonstrovány
na ukázkové aplikaci v podobě hry z prostředí vesmíru. Platforma bude založena na
rozšířené specifikaci jazyka HTML, čímž je jazyk HTML5[1]. Technologie WebGl využívá
pro vykreslování plátno canvas, které je součástí zmíněného jazyka . Z této skutečnosti vyplývá,
že zvolená technologie nebude dostupná v prohlížečích, které nepodporují HTML5.
Aktuální verze nejrozšířenějších prohlížečů již tuto specifikaci podporují. Všechny prohlížeče
jako je Firefox, Chrome, Opera, či Safari podporují ve standardním nebo editačním módu
také technologii WebGl. Bohužel jeden významný hráč na trhu v seznamu zatím chybí a tím
je Internet Explorer. Ani jeho verze číslo 9 si s touto technologií neporadí, a to v momentě,
kdy Khronos Group standardizovalo grafické rozhraní WebGl 1.0.
2.2 Požadavky na ukázkovou aplikaci
Závod bude individuální časovka, která se pro jedince spustí průletem první brány. Závodit
bude moci i více závodníků najednou, ale každému se čas měří od prvního průletu. Každý
závodník vidí zvýrazněnou příští bránu a méně zvýrazněné příští brány ostatních připojených
účastníků. Pokud nemá bránu v zorném poli, vidí po straně obrazovky šipku ukazující
nejbližší vzdálenost. Mapu bude možné stavět z lodi, čímž se otevře prostor ke stavbě zajímavých
map. Hráč bude moci po stisku klávesy nechat vygenerovat asteroid nebo bránu.
Z důvodu zpětné vazby bude vygenerovaný asteroid poloprůhledný a nebude kolidovat. Po
opuštění prostoru všemi hráči se zhmotní. Asteroidy půjde odstřelovat laserem, který když
zasáhne asteroid, tak dojde k jeho zmizení. Obdobným způsobem půjde přidávat a odebírat
brány. Laser ostatním hráčům nebude vadit. Pokud během závodu někdo zruší aktuální
bránu, najde se další brána s vyšším číslem. Vytvořený svět i s pozicemi hráčů půjde uložit
do souboru, odkud bude moci být znovu načten. Poslední pozice hráče bude uložená na
serveru. Pokud se hráč odpojí, jeho lod’ se zastaví a zůstane pro ostatní lodě viditelná ve
vesmíru. Při připojení se hráči zobrazí seznam odpojených hráčů a hráč si vybere, za koho
se připojí, nebo zadá nové jméno do editu a vytvoří se tím nový hráč.
2

2.3 Požadavky na webovou platformu
Požadavky na webovou platformu byly již částečně zmíněny v úvodu 1 práce. Ve své podstatě
se jedná o základní návrh a implementaci herního enginu. Samotné téma herních enginů je
natolik rozsáhlé a složité, že bude nutné si vymezit určitý okruh vlastností, které by výsledná
platforma nebo ukázková aplikace měli splňovat:
ˆ Platforma by měla mít určitou strukturu s důrazem na její snadnou rozšiřitelnost.
ˆ Základem každého enginu jsou 3D modely, bude tedy nutné vyřešit jejich nahrávání
do scény.
ˆ Na jednotlivé objekty by měly být aplikovatelné různé shadery podle potřeby.
ˆ Objekty ve scéně budou uspořádány ve stromové struktuře.
ˆ Na jednotlivé uzly stromu bude možné aplikovat známé transformace rotace, posunutí
a zvětšení, popřípadě jiné vlastnosti.
ˆ Jelikož by měly objekty ve scéně mezi sebou interagovat, tak je zapotřebí vytvořit
základ fyzikálního systému a s tím související detektor kolizí.
ˆ S předešlým bodem přímo souvisí různá obalová tělesa objektů ve scéně, například
koule, orientovaný kvádr atd.
ˆ Pohyb kamery by měl být dynamický, kamera by se neměla nacházet pouze na jednom
místě za objektem.
ˆ Scéna by měla být rozdělena do určitých sekcí. Objekty, které se nenachází ve viditelném
prostoru, by neměly být předány grafické kartě k renderování.
ˆ Ve scéně se budou nacházet průhledné objekty, je tedy nutné vyřešit problémy týkající
se blendingu a z - bufferu.
ˆ Pro asteroidy je třeba vytvořit generátor, aby se docílilo různého vzhledu asteroidů.
ˆ Je třeba vyřešit problémy týkající se multiplayeru a vybrat konkrétní architekturu jako
je klient - server nebo například peer - to - peer.
Serverová komponenta je tvořena javovským Jetty serverem. Bohužel to má tu nevýhodu, že
nebude moci být použit na aplikační logiku výsledného programu. Kód pro WebGl je totiž
psán v javascriptu. Jetty server byl původně vybrán, protože je malý a podporuje technologii
WebSockets, která bude použita pro vzájemnou komunikaci uživatelů. API WebGl je
oproti původnímu OpenGl hodně redukované. Základ tvoří primitiva, buffery a programovatelná
grafická část. Chybí zcela objekty Begin, End, v API se nenachází žádné metody
pro výpočet matic, kvaternionů, není zde žádná metoda lookAt. Ve WebGl není třeba hledat
žádnou podporu pro světla, materiály, žádná tam totiž není, vše je nutné udělat pomocí
shaderů. Z toho vyplývá tedy to, že určité vlastnosti musejí být doplněny různými externími
javascriptovskými knihovnami a nebo vlastní implementací.
3

3 Popis vybraných technologií
V následující podkapitole 3.1 jsou stručně popsány známé technologie pro zobrazování 3D
grafiky ve webovém prohlížeči. Další podkapitola 3.2 se zaměřuje na WebGl a nastiňuje
princip tvorby pomocí této technologie. Poslední podkapitola 3.3 přibližuje technologii Web-
Sockets pro sít’ovou komunikaci.
3.1 Technologie pro zobrazení 3D grafiky ve webovém prohlížeči
WebGl není jediná technologie, která umožňuje zobrazení 3D grafiky pomocí webového prohlížeče.
Podkapitola 3.1.1 se zaměřuje spíše na starší technologii VRML. V podkapitole 3.1.2
je stručně popsána poměrné nová technologie Stage3D. Podkapitola 3.1.3 se zaměřuje na
kompletní vývojový nástroj Unity.
3.1.1 VRML a X3D
Již v roce 1997 byla publikována norma pro popis virtuálního prostředí pod jménem VRML[2].
Jedná se o jazyk, který je zaměřen na prezentaci virtuální reality ve webovém prohlížeči a
zároveň jde o formát souborů. Scéna je organizována do stromové struktury. Tělesa a další
objekty jsou popsány pomocí hraniční reprezentace. Na jejich plošky je možné mapovat textury.
Scéna v sobě zahrnuje běžně používané prvky jako jsou světelné zdroje, předdefinované
polohy, charakteristiky kamer atd. VRML není žádný programovací jazyk, neobsahuje žádné
programovací konstrukce. Funkční vlastnosti nových objektů lze popsat jazyky Java a JavaScript.
Pomocí různých prostředků lze definovat animace objektů a interakci s uživatelem.
Klíčové hodnoty založené na lineární interpolaci definují výslednou animaci. Pro interakci
slouží různé senzory, které reagují na různé aktivity avatara. Může se jednat o kliknutí myši,
o průchod určitým místem atd. Pro interakci se využívá principu událostí. VRML postupně
přestalo dostačovat současným požadavkům, což se snaží napravit formát X3D, který doplňuje
nové vlastnosti.
3.1.2 Flash (Stage 3D)
S vydáním Flashové přehrávače číslo 11 se otevřely nové možnosti použití, které dřívější
verze neposkytovaly. Nový Flash již podporuje rendering pomocí 3D hardwarové akcelerace.
Dřívější verze Flash se spoléhaly pouze CPU. Adobe s touto verzí vydalo API Stage3D[3],
které využívá všech schopností GPU přímo z Flashe, což rozšiřuje oblast působnosti tohoto
velice rozšířeného přehrávače. Již bude možné vytvářet různé efekty pomocí shaderů. Scéna
se pouze připraví(vertexy, transformační matice, atd ) a všechna potřebná data se pošlou do
GPU, které data postupně zpracuje v několika fázích. Mimo jiné se jedná o velice podobný
princip, který využívá právě WebGl.
4

3.1.3 Unity
Unity 3D[4] je herní vývojový nástroj, který poskytuje spoustu možností pro vývoj interaktivních
3D aplikací. Nejedná se pouze o grafické API, ale o kompletní vývojové prostředí.
Výsledné výtvory mohou být spuštěny na mnoha známých platformách. Od Windows, Mac,
XBox360 až po mobilní Android. Navíc existuje doplněk, pomocí kterého je možné výsledný
projekt spustit ve webovém prohlížeči. Aktuální verze 3.5 podporuje export do SWF formátu,
který je doménou Adobe Flash. Hlavním stavebním prvkem je GameObject, který se může
skládat z mnoha komponent od fyziky po různá světla a zvuky. Objektům je možné přiřadit
komponentu script pomocí, které se tvoří hlavní logika a ovládání hry. Unity podporuje tři
skriptovací jazyky. Javascript, C# a Boo, který vychází z Pythonu. Nahrávaní vytvořených
modelů ze známých modelovacích nástrojů je otázkou několika málo kliknutí. Jedná se celkově
o propracovanou platformu s vývojovým prostředím, pomocí kterého je možné vytvářet
opravdu pohledné scény a využít tím možnosti dnešních grafických karet. Unity například
podporuje Nvidia PhysX.
3.2 Technologie WebGL
Několik následujících řádků se bude týkat pouze technologie WebGl. První podkapitola 3.2.1
pouze nastiňuje konkrétní specifikaci. V podkapitolách 3.2.2 a 3.2.3 je ukázán základní princip
tvorby aplikací pomocí webGl.
3.2.1 Specifikace API
Technologie WebGl byla již částečně popsána v kapitole 1 a 2.1. Kompletní specifikace
OpenGl ES 2.0 [5] lépe popisuje všechny možnosti tohoto API, které je určeno pro vestavěné
systémy, mobilní telefony, konzole, spotřebiče či auta. Specifikace WebGl 1.0[6] vychází z
OpengGl ES 2.0, na kterou se velmi často odvolává a případně popisuje rozdíly mezi těmito
API.
3.2.2 Názorná ukázka
Na WebGl bude postavena výsledná platforma, a proto následuje velice jednoduchá ukázka,
která se snaží nastínit princip tvorby aplikací pomocí WebGl.[7]
Vertex shader a Fragment shader - Bloky vertex shaderů a pixel shaderů jsou napsány
v jazyku GLSL, který vychází ze syntaxe jazyka C. Vertex shader v tomto případě
pouze vynásobí každý vertex projekční a modelovou maticí. V ukázce jsou 2 typy proměnných.
Uniform proměnné se v průběhu provádění nemění, matice mají tedy stále stejnou
hodnotu. Naproti tomu proměnné Attribute se neustále mění. Vertex shader je totiž spuštěn
pro každý vertex zvlášt’. Fragment shader nepřijímá žádnou proměnnou z vertex shaderu a
pouze nastaví vykreslenému objektu konkrétní barvu.
var vertexSh = ” a t t r i b u t e vec3 poziceVertexu ;”+
5

”\ } ”;
”uniform mat4 p r o j e k c n i M a t i c e ;”+
”uniform mat4 MMatice ;”+
”void main ( void ) \{”+
” g l P o s i t i o n = p r o j e k c n i M a t i c e * MMatice
* vec4 ( poziceVertexu , 1 . 0 ) ; ”+
var fragmentSh = ” p r e c i s i o n mediump f l o a t ;”+
”void main ( void ) {”+
”gl FragColor = vec4 ( 0 . 5 , 0 . 5 , 0 . 5 , 1 . 0 ) ; ”+
”} ”;
Kompilace programu - Následující kód získá WebGl kontext, pomocí kterého je možné
přistupovat k funkcím jádra WebGl. Dále se provede kompilace shaderů a vlastního programu.
var canvas = document . getElementById ( ” platno ”) ;
var g l = canvas . getContext ( ”moz−webgl ”) ;
var vertexShader = g l . createShader ( g l .VERTEX SHADER) ;
g l . shaderSource ( vertexShader , vertexSh ) ;
g l . compileShader ( vertexShader ) ;
var fragmentShader = g l . createShader ( g l .FRAGMENT SHADER) ;
g l . shaderSource ( fragmentShader , fragmentSh ) ;
g l . compileShader ( fragmentShader ) ;
var program = g l . createProgram ( ) ;
g l . attachShader ( program , vertexShader ) ;
g l . attachShader ( program , fragmentShader ) ;
g l . linkProgram ( program ) ;
g l . useProgram ( program ) ;
6

Tvorba a plnění bufferů - Proto, aby bylo možné vykreslit daný objekt, musí mít grafická
karta k dispozici potřebná data. K těmto účelům slouží buffery, které jsou po vytvoření
uloženy v paměti grafické karty. Buffery jsou pro 3D modely ideální volbou. Array buffer
slouží v tomto případě k uložení pozic vertexů a Element array buffer uchovává indexy, které
odkazují na konkrétní vertexy. Metoda gl.createBuffer() vytvoří nový buffer a gl.bindBuffer()
určuje aktuálně používaný buffer. \
v e r t e x B u f f e r = g l . c r e a t e B u f f e r ( ) ;
g l . bindBuffer ( g l .ARRAY BUFFER, v e r t e x B u f f e r ) ;
vertexy = [ 1 . 0 , 1 . 0 , 0 . 0 , −1.0 , 1 . 0 , 0 . 0 , 1 . 0 ,
−1.0 , 0 . 0 , −1.0 , −1.0 , 0 . 0 ] ;
g l . bufferData ( g l .ARRAY BUFFER,
new Float32Array ( vertexy ) , g l .STATIC DRAW) ;
v e r t e x B u f f e r . v e l i k o s t P o l o z k y = 3 ;
v e r t e x B u f f e r . pocetPolozek = 4 ;
i n d e x B u f f e r = g l . c r e a t e B u f f e r ( ) ;
g l . bindBuffer ( g l .ELEMENT ARRAY BUFFER, i n d e x B u f f e r ) ;
var indexy = [ 0 , 1 , 2 , 1 , 3 , 2 ] ;
g l . bufferData ( g l .ELEMENT ARRAY BUFFER,
new Uint16Array ( indexy ) , g l .STATIC DRAW) ;
i n d e x B u f f e r . pocetPolozek = 6 ;
program . v e r t e x A t t r i b u t e = g l . g e t A t t r i b L o c a t i o n (
program , ”poziceVertexu ”) ;
g l . enableVertexAttribArray ( program . v e r t e x A t t r i b u t e ) ;
Nastavení Uniform proměnných
- Na následujících několika řádcích se nejprve nastaví
hodnoty matic a následně se přiřadí k Uniform proměnným použitých v shaderech.
var p r o j e k c n i M a t i c e = mat4 . c r e a t e ( ) ;
var MMatice = mat4 . i d e n t i t y ( ) ;
mat4 . t r a n s l a t e ( MMatice , [ 0 , 0 . 0 , − 7 . 0 ] ) ;
g l . viewport ( 0 , 0 , 400 , 4 0 0 ) ;
mat4 . p e r s p e c t i v e (45 , 400 / 400 , 0 . 1 , 1 0 0 . 0 , p r o j e k c n i M a t i c e ) ;
program . l o k a c e P r o j e k c n i M a t i c e = g l . getUniformLocation (
program , ”p r o j e k c n i M a t i c e ”) ;
g l . uniformMatrix4fv ( program . lokaceProjekcniMatice ,
f a l s e , p r o j e k c n i M a t i c e ) ;
program . lokaceMMatice = g l . getUniformLocation (
program , ”MMatice ”) ;
g l . uniformMatrix4fv ( program . lokaceMMatice , f a l s e , MMatice ) ;
7

Vykreslení objektu
- V posledním kroku se určí buffery, se kterými má grafická karta aktuálně
pracovat. Zavoláním metody drawElements dojde k vykreslení objektu na obrazovku.
g l . c l e a r C o l o r ( 0 . 0 , 0 . 0 , 0 . 0 , 1 . 0 ) ;
g l . c l e a r ( g l .COLOR BUFFER BIT ) ;
g l . bindBuffer ( g l .ARRAY BUFFER, v e r t e x B u f f e r ) ;
g l . v e r t e x A t t r i b P o i n t e r ( program . vertexAttribute ,
v e r t e x B u f f e r . v e l i k o s t P o l o z k y , g l .FLOAT, f a l s e , 0 0 ) ;
g l . bindBuffer ( g l .ELEMENT ARRAY BUFFER, i n d e x B u f f e r ) ;
g l . drawElements ( g l .TRIANGLES, i n d e x B u f f e r . pocetPolozek ,
g l .UNSIGNED SHORT, 0 ) ;
3.2.3 Výsledek názorné ukázky
V minulé podkapitole 3.2.2 byl popsán postup, jak na obrazovku vykreslit čtverec. Zde je
výsledek snažení:
Obrázek 3.1: Výsledný čtverec na černém pozadí
3.3 Technologie WebSockets
Specifikace technologie WebSocket[8] definuje API, které dovoluje webovým stránkám používat
obousměrnou komunikaci se vzdáleným hostem. Uvádí WebSocket rozhraní a definuje
full duplexní komunikační kanál přes TCP spojení. HTML5 WebSockets výrazně redukuje
objem přenesených dat a zkracuje zpoždění až na 50ms ve srovnání s jinými technologiemi.
Existují sice technologie polling a long-polling, ale ty nemohou websockets konkurovat co
se týče rychlosti. Není již třeba se neustále dotazovat serveru, zda nejsou k dispozici nová
data k přenesení. Na technologii Websockets je unikátní, že dokáže posílat data bez větších
omezení skrz různé firewally a proxy servery.
8

Podkapitola 3.3.1 přibližuje samotný WebSocket protokol. V podkapitole 3.3.2 se rozebírá
základní API této technologie.
3.3.1 WebSocket protokol
WebSocket protokol byl navržen s ohledem na stávající webovou infrastrukturu. Specifikace
protokolu definuje, že je spojení nejprve navázáno pomocí HTTP, což garantuje zpětnou
kompatibilitu se systémy z dob, kdy WebSocket vůbec neexistovalo. Navázání spojení se
provádí v několika krocích:
ˆ Webový prohlížeč odešle na server žádost o přepnutí HTTP protokolu na protokol
WebSocket. Žádost je odeslána v podobě aktualizovací hlavičky.
ˆ Server okamžitě přepne na nový protokol, pokud podporuje technologii WebSocket.
ˆ V tomto bodě dojde k nahrazení protokolu HTTP spojením WebSocket přes vrstvu
TCP/IP. WebSocket spojení používá stejný port jako HTTP(80) a zabezpečené HTTPS(443).
ˆ Je-li spojení úspěšně navázáno, je možné přijímat a odesílat jednotlivé framy mezi
klientem a serverem ve full-duplexním módu. Jak binární, tak textové framy mohou
být přijímány a odesílány najednou v jeden okamžik.
3.3.2 Použití API
Pro navázání spojení stačí vytvořit novou instanci WebSocket a vložit do konstruktoru URL
s předponou ws nebo wss, chceme-li zabazpečené spojení:
var myWebSocket = new WebSocket ( ”ws : / /www. adresa . cz ”) ;
Rozhraní WebSocket definuje několik posluchačů, které jsou zavolány, pokud nastane konkrétní
událost :
myWebSocket . onopen = f u n c t i o n ( evt ) {
a l e r t ( ” S p o j ení navázáno ”) ;
} ;
myWebSocket . onmessage = f u n c t i o n ( evt ) {
a l e r t ( ” P ř i j a t a zpráva : ” + evt . data ) ;
} ;
myWebSocket . o n c l o s e = f u n c t i o n ( evt ) {
a l e r t ( ” S p o j ení ukončeno ”) ;
} ;
Zprávy jsou odesílány pomocí metody send :
myWebSocket . send ( ” Hello ! ”) ;
Ukončení spojení:
myWebSocket . c l o s e ( ) ;
9

4 Analýza a návrh řešení
V následující podkapitole 4.1 jsou rozebrány různé frameworky, které jsou pro WebGl k
dispozici. Podkapitola 4.2 se zaměřuje na architekturu a je zde snaha najít ideální návrh
výsledné platformy. Následující podkapitoly jsou úzce svázány s architekturou platformy.
Konkrétně se v podkapitole 4.3 rozebírají nejpoužívanější obalová tělesa a vybírají se ta,
která následně budou implementována. V podkapitole 4.4 je přiblížen základní fyzikální
systém, který bude použit. Podkapitola 4.5 je sice poslední, ale určitě není méně důležitá.
Zaměřuje se na metody rozdělující scénu a vybírá se ta ideální pro ukázkovou aplikaci.
4.1 Stručný přehled WebGl frameworků
HTML5,CSS3 a WebGl jsou technologie, které mění podobu dnešních webových stránek.[9]
Očekává se, že se tyto technologie budou navzájem doplňovat a vzniknou velice zajímavé
projekty. Takto velké rozsáhlé aplikace není možné tvořit jen pomocí API, které WebGl nabízí.
Je potřeba přidat určité vrstvy, které budou mít na starosti například světla, rendering,
nahrávání objektů, fyziku, dělení scény, stromovou strukturu, atd. Za tímto účelem vznikají
různé frameworky, které implementují tyto vlastnosti a mnoho dalších. Ačkoliv počet
WebGl frameworků neustále roste, tak některé jsou již na konci svého vývoje. V době, kdy
se začala tvořit výsledná platforma nebyly frameworky dobře zdokumentované. Například
framework Three.js vypadal jako dobrý kandidát, ve kterém by se dala platforma naimplementovat,
ale existoval pouze jednoduchý příklad, a to je velice málo. Navíc chyběla podpora
fyziky, částicového systému a pokročilejších funkcí. X3DOM framework vychází z X3D, o
kterém bylo zmíněno v kapitole (3.1.1). Podporuje stromovou strukturu, rozmanité efekty,
shadery, světla, interpolaci, atd. Obecně je nedodělaný a zatím nepoužitelný pro větší projekt,
ale určitou perspektivu před sebou má, protože vychází z X3D. GLGE jako jeden z mála
frameworků disponuje rozsáhlejší dokumentací a zajímavými příklady. Podporuje základní
vlastnosti OpenGl ES. Explicitně chybí fyzikální systém. Třídy nejsou vždy ideálně navrženy
a neuškodilo by rozdělení na více modulů. CubicVR 3D má slibné příklady, velice působivou
dokumentaci a obsahuje základní matematiku (vektory, matice). Používá OPP přístup kombinovaný
s objektovými poli, které se předávají jako parametr. Gettery a settery nejsou díky
tomu potřeba, což udělalo kód přehlednějším. Toto API plně nepodporuje animace, fyziku,
křivky, vlastní renderery. Je naimplementována většina známých světel. Obecně se jedná
o velice zdařile navrženou architekturu od matematických možností po shadery. Podporuje
formát COLADA.
Obecně mají frameworky problém s horší dokumentací, nejsou dodělané a není vždy
jisté, zda jejich vývoj bude dále pokračovat. Zatímco většina frameworků podporuje meshe,
modely, kamery, osvětlení, jeden renderer. Pokročilejší funkce jako animace, fyzika, octrees,
zvuky, video textury, sít’ování chybí. Také toto byly hlavní důvody, proč se výsledná platforma
začala tvořit od začátku, nebylo by vždy jisté, zda budou naimplementovány potřebné
vlastnosti. Kdyby existovalo opravdu dokonalé API, nebylo by celkem co řešit, ale WebGl je
tu jen krátce a frameworky mají určité porodní bolesti. Proto bylo rozhodnuto, že platforma
nebude vycházet z žádného existujícího frameworku a vytvoří se nová.
10

4.2 Architektura platformy
Návrh celé plaformy je stěžejní částí této práce. Špatný návrh by mohl způsobit velké komplikace
v průběhu budoucího vývoje.
V podkapitole 4.2.1 se hledají různé techniky, které by mohly být použity ve výsledné
platformě. V podkapitole 4.2.2 je přiblížen problém javascriptu s veřejnými a privátními proměnnými
či metodami. V podkapitole 4.2.3, respektivě v příloze B na straně 56 se nachází
přehledový diagram platformy. V podkapitolách 4.2.4 a 4.1 jsou popsány vlastnosti konstruktoru
GameObject a možné komponenty, které lze přiřadit případnému objektu. Další
podkapitola 4.2.6 popisuje, jakým způsobem jsou do scény nahrávána data ze souboru json.
Hlavní uzel scény je detailněji přiblížen v podkapitole 4.2.7. Jak jsou v platformě uspořádány
shadery, je možné nalézt v podkapitole 4.2.8. Poslední podkapitola 4.2.9 se zaměřuje na vstup
z klávesnice.
4.2.1 Inspirace pro návrh
Inspirace pro návrh byla hledána u jiných frameworků. Svým poměrně jednoduchým návrhem
zaujal framework GLGE[10]. Ten využívá při tvorbě vlastností javascriptu, který umožňuje
řetězení prototypů a také dynamicky přidávat a nebo odebírat metody či proměnné určitého
objektu. Zde je malý příklad konstruktoru Group:
GLGE. Group=f u n c t i o n ( uid ){
t h i s . c h i l d r e n = [ ] ;
var that=t h i s ;
t h i s . downloadComplete=f u n c t i o n ( ) {
i f ( that . isComplete ( ) )
that . f i r e E v e n t ( ”downloadComplete ”) ;
}
GLGE. Assets . r e g i s t e r A s s e t ( t h i s , uid ) ;
}
GLGE. augment (GLGE. Placeable ,GLGE. Group ) ;
GLGE. augment (GLGE. Animatable ,GLGE. Group ) ;
GLGE. augment (GLGE. QuickNotation ,GLGE. Group ) ;
GLGE. augment (GLGE. JSONLoader ,GLGE. Group ) ;
Z výše uvedeného kódu je možné vyčíst několik věcí :
ˆ Každá metoda, či konstruktor začíná slovem GLGE, které nejen informuje, o tom,
že se jedná o konkrétní framework, ale také omezuje kolize mezi jinými použitými
javascriptovskými aplikacemi, které by náhodou obsahovaly stejnou metodu se stejným
názvem. Pro výslednou platformu byla zvolena proměnná WGLP(WebGl Platform),
která bude v budoucnu nejspíš nahrazena jiným slovem.
ˆ Dále zaujme metoda augment. Prvním parametrem je konstruktor, jehož vlastnosti přiřazené
prototypu budou přidány do prototypu konstruktoru, který se metodě předává
11

pomocí druhého parametru. Prototyp konstruktoru Group bude ve výše uvedeném
případě rozšířen o vlastnosti prototypů konstruktorů Placeable a Animatable. Group
tím tyto vlastnosti přijme za své. Jedná se konkrétně o uzel libovolného stromu, který
bude moci být umístěn a nebo animován. Tato metoda je velice užitečná a bude zajisté
naimplementována do nové platformy. Takový postup přidávání vlastností má ale tu
nevýhodu, že by se programátor mohl za chvíli ztrácet v tom, jakou vlastnost daný
objekt má.
Trochu jinou filozofii využívá vývojová platforma Unity z kapitoly (3.1.3), která se stala
hlavním zdrojem inspirací pro výslednou platformu. Každý objekt ve scéně je typu Game-
Object, který má určité Id. Dále se podle potřeby přidávají různé komponenty, které jsou
nutné k dosažení potřebného efektu. Mezi komponenty patří například Transform, Renderer,
RigidBody, Světlo, Kamera, Animace, atd. Chceme-li například animovaný objekt, je
nezbytné vytvořit GameObject, poté přiřadit komponenty Renderer, která má na starosti
rendering, Transform, pomocí které je objekt pozicován a nakonec Animace, která zařídí
výslednou animaci. Velice zajímavá je komponenta Script, pomocí které je možné přiřadit
logiku danému objektu.
Všechny výše zmíněné vlastnosti platformy Unity přebírá výsledně vytvořená platforma.
4.2.2 Privátní proměnné
Javascript ve své implementaci nezná pojem veřejná a privátní proměnná. Pro potřeby platformy
by bylo vhodné proměnné či metody takovým způsobem odlišit. Pomocí určitých
programových struktur lze dosáhnout podobných vlastností, které privátní a veřejné metody(proměnné)
mají, ale kód by se stal složitějším a méně přehledným. Proto bylo přistoupeno
k velice jednoduchému až primitivnímu řešení. Před každou privátní metodou nebo
proměnou se bude nacházet dolní podtržítko. Takto vývojář ihned na první pohled pozná,
s jakou metodou aktuálně pracuje. Příkladem privátní proměnné může být position” z
”
komponenty Transform.
4.2.3 Přehledový diagram
Přehledový diagram se nachází v příloze B na straně 56. Vybrané části jsou popsány v
následujících podkapitolách.
4.2.4 Objekt GameObject
Každý objekt, který bude umístěn do scény by měl být vytvořen konstruktorem GameObject(id)
se zvoleným Id, které musí být unikátní. Dále do vytvořeného objektu GameObject
mohou být přidávány různé komponenty, což přibližuje následující obrázek (4.1)
12

Obrázek 4.1: GameObject a možné komponenty
Z výše uvedeného obrázku 4.1 je patrné, že objektu mohou být nastaveny proměnné,
které určují:
ˆ Zda objekt může kolidovat s ostatními objekty ve scéně.
ˆ Jestli se objekt pohybuje a nebo je statický.
ˆ Zda je objekt ve scéně viditelný.
ˆ Jestli je objekt průhledný či nikoliv.
ˆ V neposlední řadě lze objekt přiřadit ke konkrétní skupině. Například se může jednat o
asteroid, vesmírnou lod’, a podobně. Konkrétní příklad použití lze nalézt u kolizí, kdy
je někdy potřeba vyřadit jeden pár objektů, který mezi sebou nemá nikdy kolidovat.
Může se jednat například o laser, který není schopen zasáhnout vesmírnou lod’.
ˆ Poslední, ale důležitá vlastnost se týká vlastníka objektu. Vždy při zavolání konstruktoru
GameObject je této proměnné přiřazena hodnota self”, která říká, že objekt patří
”
uživateli, který sedí aktuálně u PC. Vlastníkem ale může být například server nebo jiný
vzdálený uživatel. Takto lze určit, kdo má daný objekt pod kontrolou a může s ním
popřípadě hýbat.
4.2.5 Komponenty objektu GameObject
Transform je velice důležitá komponenta, pomocí které je možné objekt pozicovat, rotovat,
a to bud’ relativně ke svému předkovi a nebo absolutně ve světových souřadnicích.
Ostatní hodnoty se vždy dopočítají automaticky. Pomocí tohoto uzlu je dále možné vytvářet
hierarchii objektů. Každý uzel Transform může mít neomezeně mnoho potomků. V
13

neposlední řadě existují možnosti zvětšování / zmenšování, přepočítání lokálního bodu do
světových souřadnic, to samé platí i v opačném směru, atd. Všechny změny provedené v uzlu
Transform jsou postupně propagovány stromovou strukturou až k listům.
Obrázek 4.2: Obrázek znázorňuje objekty, které mezi sebou komunikují, pokud nastane
změna v komponentě Transform a nebo v objektu GameObject.
Výše uvedený obrázek 4.2 znázorňuje objekty, které mezi sebou komunikují, pokud nastane
důležitá změna v komponentě Transform, a nebo v objektu GameObject. Například,
pokud dojde k pohybu objektu, tak uzel Transform neprodleně informuje všechny své zaregistrované
pozorovatele o dané změně. Při vytváření nového objektu pomocí konstruktoru
Transform se mezi pozorovatele automaticky přidá objekt Hierarchy, který má za úkol informovat
o změně všechny přímé i nepřímé potomky, které na základě nových dat změní
také svůj stav. Mezi pozorovateli se dále může nacházet například obalové těleso přiřazené
přímo objektu GameObject, a nebo jeho rendereru, pokud samozřejmě nějaký vůbec má.
Obalové těleso je automaticky přidáno mezi pozorovatele, pokud je přiřazeno objektu game-
Object, a nebo případnému rendereru. Všechna tělesa by také měla mít naimplementovanou
metodu update(), která je volána v případě , že nastane změna a je potřeba změnit pozici
či orientaci obalového tělesa. Objekt Hierarchy nemá na starosti pouze aktualizaci všech potomků,
které jsou instance Transform, ale také informuje kořenový uzel scény VirtualWorld
o požadovaných změnách. Konkrétně se jedná především o informace, zda objekt instance
GameObject přiřazený uzlu Tranform nezměnil některou ze svých proměnných. Například
jestli se z dynamického objektu nestal statický. Na základě těchto dat by následně došlo k
aktualizaci kolekcí, ve kterých si uchovává VirtualWorld ukazatele na různé typy objektů.
Více o VirtualWorld je v kapitole 4.2.7.
Pro uložení pozice v uzlu Transform je použit třísložkový vektor. Rotace jsou uloženy
ve formě matic o velikosti 4x4. Jedná se o redundanci, protože pro rotační matici dostačuje
velikost 3x3. Použitá knihovna gl-matrix[11] pro výpočet matic pracuje primárně s maticemi o
velikosti 4x4, proto byla zvolena tato velikost. Matice nejsou jedinou volbou pro uložení rotace
objektu, velice často se používají Kvaterniony. Jejich výhoda spočívá především ve snadnější
a lepší interpolaci. Další výhodou je menší pamět’ová náročnost, protože jsou uloženy ve
formě čtyř reálných čísel. Grafické karty pracují pouze s maticemi, proto je vždy potřeba
každý kvaternion převést před renderováním do maticové formy. Výhody kvaternionů nejsou
pro výslednou platformu až tak zásadní, proto jsou rotace uloženy ve formě matic, z kterých
14

je možné ihned extrahovat jednotlivé osové vektory(up, right, forward), což se v některých
případech hodí.
RigidBody je komponenta, která zaručí, že bude mít objekt určité fyzikální vlastnosti.
Více o rigidních tělesech je napsáno v podkapitole 4.4 na straně 27, kde jsou informace
týkající se použitého fyzikálního systému. K použití komponenty dojde v případě, kdy je
potřeba, aby byl objekt ovlivňován různými fyzikálními vlivy.
Camera je hluboce svázána s komponentou Transform, protože upravuje její pozici a rotaci.
Kamera se ve skutečnosti nikam nepohybuje, stále se nachází v počátku světového
souřadnicového systému a je natočena směrem k ose Z v negativním směru. Musí být tedy
hýbáno s okolním světem přesně v opačném směru. Takzavaná View matice, kterou si kamera
uchovává je vypočítána jako inverze z modelové matice, která je dodána pravě komponentou
Transform. Velice důležitou maticí pro rendering je projekční matice, která se také nachází
v již zmíněné komponentě. Kameře je možné přiřadit avatara a případně používaný skybox.
Její součástí je také takzvané ViewFrustum, které definuje viditelnou oblast pomocí šesti
rovin, které musejí být při každém pohybu kamery přepočítány.
BoundingVolume je komponenta, která zaručuje obklopení objektu obalovým tělesem.
Idea je taková, že téměř každý objekt může jím může být obklopen. Těleso by nemělo obklopovat
pouze objekt, ke kterému je přiřazeno, ale také všechny objekty, které se nacházejí v
hierarchii pod ním. Pokud dojde k posunutí nebo k rotaci objektu, je nutné také aktualizovat
polohu obalového tělesa. Více o použitých obalových tělesech je napsáno v podkapitole 4.3.
Script je komponenta, která může být přiřazena každému objektu, a pomocí které může
být objekt obohacen o určitou logiku. Například ve výsledné ukázce je takto uděláno ovládání
a chování vesmírné lodi. Každá komponenta Script musí mít povinně metodu start(),
která provádí počáteční nastavení dle potřeby uživatele. Další povinnou metodou je update(duration),
která je spuštěna v každém snímku a očekává hodnotu intervalu, o kterém
je více napsáno v kapitole 4.4.1.
NetworkView
Každý objekt, který je sdílený mezi uživateli po síti, musí mít přiřazenu
komponentu NetworkView, která obsahuje Id, které jednoznačně identifikuje objekt v síti.
15

Obrázek 4.3: Komponenta NetworkView a všechny důležité třídy se kterými spolupracuje.
Komponenta poskytuje dvě důležité metody sendMessage a onMessage, které slouží pro
příjem a odesílání dat týkajících se daného objektu. Odeslané zprávy se doručí všem uživatelům
v síti, kteří mají ve scéně objekt se stejným Id. Objektům, které jsou řízeny takto na
dálku a nejsou ovládané uživatelem, je potřeba přiřadit komponentu Script, která obstará
příjem příchozích zpráv pomocí metody onNetworkViewMessage, a která změní například
stav objektu či provede jeho odstranění ze stromu. Jedná se o upravený skript, o kterém je
více napsáno zde [25]. Skript by měl být přiřazen komponentě NetworkView, k čemuž slouží
proměnná observer. Tím je docíleno toho, že v případě příchodu nové zprávy je zavolána
výše uvedená metoda skriptu, které se neprodleně předají příchozí data. Skript by měl navíc
obsahovat proměnnou interpolationEnabled, která říká, jestli má dojí k interpolaci mezi posledními
známými stavy objektu. Z toto důvodu si skript pamatuje přibližně posledních 15
stavů objektů. Stavem se většinou myslí pozice, rotace a rychlost. V samotné metodě update
komponenty Script by mělo docházet k již zmíněné interpolaci.
Renderer je komponenta, která si uchovává data potřebná k renderování. Především by
měla obsahovat informace o geometrické reprezentaci, materiálech, texturách a bufferech.
Ve scéně jsou naimplementovány celkem tři renderery. Konkrétně se jedná o MeshRenderer,
BillboardRenderer a SkyboxRenderer. První dva zmíněné jsou detailněji popsány v kapitolách
4.2.6 a 5.6.1. Každý z nich obsahuje název shaderu, jehož pomocí má být vyrenderován
výsledný objekt. Další podmínkou pro správnou funkci komponenty je přítomnost metody
render, která má za úkol zavolat zkompilovaný program, který provede samotný rendering.
Metoda na vstupu očekává projekční a takzvanou view” matici, které jsou dostupné v kameře.
”
Light
je komponenta mající na starosti světla. Ve výsledné platformě zatím světla nejsou
naimplementována.
16

4.2.6 Nahrání dat do scény
Některé stávající frameworky podporují pro nahrávání dat do scény formát COLLADA[16]
založený na XML. Jde o velice komplexní formát, který neobsahuje pouze geometrii objektů,
ale také podporuje animace, efekty, shadery, inverzní kinematiku a podobně. Výhoda formátu
Collada spočívá, že je pod záštitou stejné společnosti, která provedla standardizaci WebGl a
také, že je podporován některými modelovacími nástroji. Z pohledu výsledné platformy jde
o zbytečně komplikovaný formát. Jedná se ale o zajímavou alternativu, která by mohla být
v budoucnu naimplementována, pokud by bylo zapotřebí nahrávat komplikovanější scény z
externího souboru.
Platforma nahrává informace o geometrických objektech z JSON souboru, který může
vypadat takto:
{
”name ”: ”Vesmír ” ,
” d e s c r i p t i o n ”: ” V i r t u a l n i r e a l i t a ve vesmiru ” ,
” e x t e r n a l o b j e c t f i l e s ”: [
{ ”id ”: ” VesmirnaLod ” , ” o b j e c t f i l e ”: ” spaceShip . obj ” ,
” m a t e r i a l f i l e ”: ” spaceShip . mtl ”} ,
{ ”id ”: ” Brana ” , ” o b j e c t f i l e ”: ” gate . obj ” ,
” m a t e r i a l f i l e ”: ” gate . mtl ”}
] ,
”meshes ”: {
”nazevMeshe ”: { ” vertexCoords ”: [ ] , ” normalCoords ”: [ ] ,
”UV”: [ ] , ” f a c e I n d i c e s ”: [ ] , ” nazevTextury : ” ”. . . ”
}
} ,
” m a t e r i a l s ”: {
nazevMaterialu : { ”AmbientColor ”: [ ] , ”specularColor ”: [ ] ,
” d i f f u s e C o l o r ”: [ ] , alpha : 1
}
} ,
” t e x t u r e s ”: {
”brana−vyrazna zare ”: { t e x t u r e S c a l e : [ 1 , 1 ] ,
fileName : ”brana−vyrazna zare . png ” } ,
”brana−zare ”: { t e x t u r e S c a l e : [ 1 , 1 ] ,
fileName : ”brana−zare . png ” }
} ,
” o b j e c t s ”: [ ]
}
JSON soubor obsahuje meshe, materiály, textury. Další důležitou položkou je external
”
object files”, která říká, z jakých externích souborů se mají načíst další data a jaký má
mít načtený objekt název.
17

Ze zmíněných souborů jsou načteny další meshe, textury, materiály a v neposlední řadě
informace o objektech, které mají být z těchto komponent vytvořeny. Informace o objektech
a jejich komponentách jsou následně uloženy do poslední položky objects”. ”
Průběh načítání dat do scény znázorňuje následující obrázek 4.4:
Obrázek 4.4: Obrázek znázorňuje načtení geometrických objektů do scény včetně materiálů
a textur
Uživatel, který si přeje vytvořit novou kopii renderovatelného objektu, zavolá metodu
objektu JsonLoader, do které vloží dvě důležité informace:
ˆ Název objektu, jehož nová kopie se má vytvořit. Ten se musí shodovat s názvem uloženým
v položce ”
objects” ve výše zmíněném JSON souboru.
ˆ Druhým parametrem je id nově vzniklého GameObjectu
Platforma zatím podporuje pouze jeden externí formát obj, což je jednoduchý datový formát,
který uchovává 3D geometrii jednoho nebo více objektů. Z tohto formátu lze vyčíst
pozici každého vertexu, UV pozici pro každý vertex, normály a jednotlivé plošky, které jsou
z vertexů vytvořeny(tzv. faces). Formát poskytuje informace, jaký materiál je přiřazen konkrétním
ploškám. V jednom obj souboru může být najednou více objektů, ale všechny sdílejí
jeden společný lokální souřadnicový systém. Pokud je v jednom souboru více objektů, tak
se v takovém případě vytvoří jeden kořenový objekt, který bude mít potomky odpovídající
objektům v souboru. S každým souborem je většinou svázán mtl formát, který si uchovává
informace o materiálech.[17] Z každého materiálu je potřeba získat vlastnosti ambient, diffuse,
specular a průhlednost. Popřípadě název textury a její velikost.
Při exportu objektů do formátu obj ze známých modelářů je nutné si dát pozor na několik
věcí:
18

ˆ Model před exportem musí být složen z trojúhelníků, čtyřhranné polygony nejsou podporovány.
ˆ Při tvorbě materiálů je nutné vybrat takový, aby obsahoval výše zmíněné složky.
ˆ Geometrická reprezentace objektu musí nést informace jak o vertexech, UV souřadnicích,
tak o normálách. Ani jedna složka nesmí chybět.
Mesh renderer má za úkol uchovávat důležitá data pro rendering objektu. Především
musejí být vytvořeny a naplněny buffery, které používá grafická karta. Bufferů, které
uchovávají indexy, může být více, protože části, které mají své vlastní materiály, musejí
být vyrenderovány odděleně. O bufferech již bylo psáno v 3.2.2 na straně 7. Mesh renderer
přibližuje následující obrázek :
Obrázek 4.5: Mesh renderer, přiřazený mesh, buffery a materiály
Struktura MeshRenderu vlastně kopíruje jeden objekt uložený v obj formátu. Jednotlivé
meshe, materiály, textury se mohou ve scéně opakovat vícekrát, proto jsou uloženy pouze
na jednom místě v objektu Components. Mesh renderery se pouze odkazují na jednotlivé
stavební komponenty, z kterých se objekt skládá.
4.2.7 VirtualWorld
Objekt VirtualWorld tvoří základní uzel celé scény. Pozor, nejedná se o konstruktor, ale již
vytvořený objekt.
19

Obrázek 4.6: Objekt VirtualWorld se všemi objekty, na které si drží referenci.
Jakmile se ve scéně vytvoří prví uzel Transform, měl by být ihned přiřazen objektu VirtualWorld,
aby došlo při následném renderování k vykreslení všech objektů ve stromu. Je
doporčeno vždy vytvořit GameObject s identifikátorem root”, jehož komponenta Transform
”
bude přiřazena objektu VirtualWorld. Tento základní uzel scény si dále drží odkazy na stavební
komponenty objektů, aktuálně používanou kameru, na všechny dynamické,statické a
renderovatelné objekty GameObject” ve stromu. Ke všem objektům GameObject”, které
” ”
se nacházejí v hierarchické struktuře je možné přistupovat pomocí speciální proměnné $”. ”
Například, pokud je potřeba pracovat s objektem GameObject” s id SpaceShip2”, tak se
” ”
použije následující zápis:
var spaceShip = VirtualWorld . $ [ ’ SpaceShip2 ’ ] ;
spaceShip . transform . rotateLocalY ( 9 0 ) ;
V případě, že je ve scéně použit strom Octree, o kterém je napsáno více v kapitole 4.5.2
na straně 30 nebo řadící algoritmus jménem Sort and sweep, měli by být jejich reference
přiřazeny k objektu VirtualWorld, který si zároveň drží ukazatel na celou scénu. Jelikož se
kolekce objektů zobrazené na obrázku 4.6 neustále mění, je potřeba informovat všechny pozorovatele,
kteří se nacházejí v poli Observers. Jako příklad může posloužit strom Octree,
který uchovává pouze statické objekty. Pokud je nějaký statický objekt odstraněn z kolekce,
je nutné také smazat referenci na obalové těleso objektu ve stromu. Octree strom je
automaticky přidán mezi pozorovatele hned v momentě, kdy se na něj VirtualWorld dozví
referenci.
4.2.8 Shadery
Ze začátku vývoje byly shadery uloženy ve zvláštním souboru, který se načítal pomocí Ajaxu.
Nevýhody zmíněného řešení spíše převažovaly nad klady. Javascript nemá právo zapisovat
do souborů na disku, takže editace souboru musela být řešena pomocí serveru. Aktuální
řešení zabudovává zdrojový kód shaderů přímo do zdrojového kódu javascriptu. Sice je psaní
kódu zdlouhavější, ale naopak může být shader dynamicky rozšířen podle potřeby o některé
funkce. Například mohou být někde připravené shaderovské funkce, které mají na starosti
jednotlivé typy světel. V případě, že by byl konkrétní typ světla použit, mohla by být funkce
20

do kódu dynamicky přidána. Pro uchovávání zkompilovaných shaderů slouží již vytvořený
objekt WGLP.ShaderPrograms.
Obrázek 4.7: Všechny objekty a konstruktory, které v platformě mají na starosti shadery.
Každý renderer musí obsahovat název shaderu, který má být použit pro renderování
konkrétního objektu. Při renderingu dojde k přepnutí na potřebný shader pomocí metody
useProgram(jmenoShaderu). V objektu ShaderPrograms může existovat libovolné množství
zkompilovaných shaderů pod různými jmény. Pro renderování normálních geometrických
objektů je připraven defaultní shader. Taktéž je k dispozici program pro renderování skyboxu.
Shadery nejsou v počátečním stavu zkompilovány, proto je potřeba vždy zavolat metodu
initDefaultShaders(). Pod pojmem shader se skrývá dvojice vertex shader, fragment shader.
Na následujících několika řádcích je část ukázky z kapitoly 3.2.2 na straně 5 přepsána do
kódu vytvořené platformy:
var sP = WGLP. ShaderPrograms ;
var vertexShader = new WGLP. Shader ( ) ;
vertexShader . setType ( ” vertex ”) ;
vertexShader . addSCLine ( ” a t t r i b u t e vec3 poziceVertexu ; ”) ;
vertexShader . addSCLine ( ”uniform mat4 p r o j e k c n i M a t i c e ; ”) ;
vertexShader . addSCLine ( ”uniform mat4 MMatice ; ”) ;
vertexShader . addSCLine ( ”{ ”) ;
vertexShader . addSCLine ( ” g l P o s i t i o n = p r o j e k c n i M a t i c e * MMatice *
vec4 ( poziceVertexu , 1 . 0 ) ; ”) ;
vertexShader . addSCLine ( ”} ”) ;
vertexShader . compileShader ( ) ;
Stejným způsobem jako výše je nutné zkompilovat fragment shader. Poté se vytvoří program
pomocí následující metody:
var program = sP . createShaderProgram ( vertexShader ,
fragmentShader , ” nazevShaderu ”) ;
V dalším kroku je zapotřebí získat lokace proměnných attribute a uniform, aby jim mohly
být přiřazeny hodnoty.
sP . assignUniformsLocation ( program , [ ” p r o j e k c n i M a t i c e ” , ”MMatice ”] ) ;
sP . a s s i g n A t t r i b u t e s L o c a t i o n ( program , [ ” poziceVertexu ”] ) ;
21

Výše vytvořená proměnná program” v tuto chvíli obsahuje proměnné uniforms a attributes,
které tvoří asociativní pole, které obsahuje lokace shaderovských proměnných. K lokacím
”
je možné přistupovat takto:
var l o k a c e = program . uniforms [ p r o j e k c n i M a t i c e ] ;
V posledním kroku musí být objektu program přiřazena metoda render, která má na starosti
naplnění shaderovských proměnných potřebnými daty pro vyrenderování konkrétního
objektu, a která nakonec zavolá funkci pro vykreslení.
program . render = f u n c t i o n ( gameObject , , p r o j e c t i o n M a t r i x ){
.
t ě l o metody
.
}
4.2.9 Vstup z klávesnice
Součástí platformy je již vytvořený objekt WGLP.Input, který usnadňuje práci se vstupem.
Pozor, nejedná se o konstruktor.
Obrázek 4.8: Objekt Input s přidruženými objekty
Na začátku je vždy nutné obsloužit události z klávesnice. K tomuto účelu slouží metody
handleKeyDown a handleKeyUp, které musí být volány, kdykoliv nastanou události ”
Key-
Down” a ”
keyUp”. Objekt Input si uchovává asociativní pole currentlyPressedKeys, kde ke
každému kódu klávesy je přiřazena hodnota true nebo false, podle toho, zda je konkrétní
klávesa zmáčknuta.
Existuje několik možností, jak lze objekt Input využít:
1. Použitím metody getKey(nazevKlavesy) lze zjistit, zda je klávesa s požadovaným názvem
aktuálně zmáčknuta. Metodu je možné použít na všechny názvy základních kláves.
Čísla se zadávají ve tvaru NUM0,NUM2,.., NUM9”.
”
22

2. Další možností je objektu Input přiřadit pozorovatele na konkrétní klávesu. Takový
pozorovatel musí mít naimplementovánu metodu update(param1, param2), kde první
parametr říká, zda došlo ke stisknutí nebo uvolnění klávesy. Druhým parametrem je
název klávesy, která vyvolala danou událost. Pozorovatele lze přidat metodou addKey-
Observer(klic, observer). Metoda, která odstraní dvojici klíč - pozorovatel” se jmenuje
”
removeKeyObserver(klic, observer).
3. Zbývá poslední metoda se jménem getAxis(jmenoOsy). V objektu Input je defaultně
uloženo několik os. Každá osa si uchovává svůj název a dva kódy požadovaných kláves.
Pokud je zmáčknuta první klávesa, metoda vrátí hodnotu -1. Pokud je zmáčknuta
druhá klávesa, metoda vrátí hodnotu 1. Pokud ani jedna z těchto kláves není zmáčknuta,
metoda vrátí hodnotu 0. Jedná se o to, že se vlastně definují klávesy pro kladný
a záporný pohyb po dané ose. V případě, že nám stávající osy nevyhovují, je možné
přidat své vlastní, a to tak, že se vytvoří nový objekt, který bude rozšiřovat ten stávající.
K tomuto slouží metoda WGLP.extend, založená na jQuery[26] knihovně, kterou
platforma využívá. Poté stačí do pole Input.Axes přidat osu s novým názvem a přiřadit
jí dva nové kódy kláves. Metody getAxis(jmenoOsy) lze například využít při ovládání
vesmírné lodi. Lze nadefinovat osu pohybu vpředVzad”, přiřadit jí potřebné klávesy
”
a pak už jen stačí sílu motoru vynásobit návratovou hodnotou funkce. Síla bude bud’
kladná nebo záporná, při nulové hodnotě nulová. Pak už stačí sílu předat objektu
RigidBody a ten už se o zbytek postará sám.
4. Objekt Input obsahuje asociativní pole Input.KeyMap, které pod každým názvem klávesy
uchovává její kód. Existuje také pole Input.rKeyMap, které si naopak uchovává
kódy a přiřazuje k nim názvy kláves.
4.3 Obalová tělesa
Ačkoliv je možné koliznímu systému předat celý objekt, tak jak byl vymodelován, je zde
několik důvodů, proč daný objekt aproximovat či obalit jiným geometrickým tělesem. [13]
Takové těleso musí kopírovat pohyb původního objektu. Obrázek 4.9 obsahuje pětici dnes
nejvíce používaných obálek.
Obrázek 4.9: Nejpoužívanější obalová tělesa. Převzato z [13]
23

Dnešní počítače nejsou dostatečně rychlé na to, aby 60x za sekundu zkontrolovaly, zda
nekoliduje mezi sebou 50 různých geometrických objektů, které se navíc skládají například
z 10000 trojúhelníků. V takovém případě by bylo nutné ověřit kolizi jednoho trojúhelníku
se všemi ostatními, a to je nemožné v reálném čase. V následujících podkapitolách se budou
rozebírat a hodnotit jednotlivé naimplementované typy obalových těles. V podkapitole 4.3.4
se přibližují všechny možné naimplementované testy kolizí. Sekci uzavírá podkapitola 4.3.5,
která popisuje případný objekt Contact, který slouží k uchovávání kolizních dat a obsahuje
metody na jejich vyhodnocení.
4.3.1 Obalová koule
Obalová koule může být přiřazena jak celému GameObjectu, tak pouze MeshRendereru,
o kterém bylo více napsáno v kapitole 4.2.6 na straně 19. Existují různé algoritmy, které
dokáží rychle a efektivně vypočítat ze sady vertexů obalovou kouli, která je jednoznačně
definována pozicí středu a poloměrem. Ve výsledné platformě je naimplementován Jackův
Ritterův algoritmus, který pracuje v lineárním čase.[14] Výsledná obalová koule je maximálně
o 5% větší než minimální možný výsledek. Algoritmus se provádí ve dvou fázích:
ˆ V první fázi se ke každé ose naleznou maximální a minimální hodnoty. Z těchto hodnot
je vypočítána prvotní koule.
ˆ Ve druhé fázi se každý bod porovná s aktuální koulí. Pokud se bod nachází mimo kouli,
tak dojde ke zvětšení poloměru a k upravení pozice středu.
4.3.2 OBB
Zkratka OBB znamená v angličtině Oriented bounding box, což je libovolně orientovaný
kvádr. Existuje mnoho reprezentací tohoto kvádru. Jako nejvýhodnější se jeví reprezentace,
kdy se uchovává polovina velikosti kvádru ve všech směrech. Rotace je uložena ve formě matice,
jako je tomu u komponenty Transform. Reprezentace v tomto tvaru umožňuje snadnější
test kolize mezi dvěma kvádry. Nalezení nejmenšího kvádru není triviální záležitost. Existuje
například metoda, kdy se kvádr natáčí postupně v různých směrech a hledá se nejmenší
kvádr. Již podle popisu jde o velice nepraktický a zdlouhavý algoritmus. Původně byl naimplementován
ve výsledné platformě, ale nakonec se od něj upustilo. Pokud se kvádr natáčel
do všech směrů a krok natočení byl 10°, tak i přes to výpočet trval neúměrně dlouho.
24

Obrázek 4.10: Nalezený OBB ve 2D. Převzato z [15]
O mnoho lepší algoritmus[15], který k výpočtu využívá kovarianční matici, dojde k požadovanému
kvádru v několika krocích:
ˆ Vstupem je pole vertexů, ze kterých se vypočítá průměrná pozice, která je použita pro
výpočet kovarianční matice spolu se vstupními vertexy.
ˆ Dalším krokem je nalezení vlastních vektorů kovarianční matice C, které definují natočení
výsledného kvádru. Pro vlastní čísla a vektory platí následující vztah : (C -
lambda*E) * v = 0, na který lze nahlížet jako na homogenní soustavu lineárních rovnic
o n neznámých. Ta má nenulové řešení, pokud je det(C - lambda*E) = 0. Vlastní čísla
jsou kořeny kubického polynomu. Vlastní vektory je možné získat vyřešením již zmíněné
soustavy rovnic. Pozici středu a velikost kvádru je již snadné dopočítat pomocí
skalárních součinů a sčítáním vektorů.
Výše zmíněný algoritmus není vhodný pro objekty, kde se vertexy vyskytují ve shlucích. Z
toho vyplývá, že je vhodný pouze na jednotlivé meshe. Pokud by se používal pro obalení
více meshů najednou, tak by výsledky nemusely být ideální. OBB nebude tedy k dispozici
jako obálka pro GameObject.
4.3.3 AABB
AABB je osově zarovnaný kvádr. Ve výsledné platformě se nejedná vlastně o kvádr, ale o
krychli, protože je vypočítána z obalové koule. Pokud by se jednalo o standardní AABB,
tak by jeho velikost musela být přepočítána vždy, když by došlo k pootočení objektu. Pozice
AABB ve scéně bude uložena ve formě minimálních a maximálních hodnot na každé ose.
Toto obalové těleso bylo do platformy přidáno pouze z důvodu, že jako kolizní algoritmus
byl vybrán Sort and sweep, který pracuje právě s AABB. Více o tomto algoritmu je napsáno
v podkapitole .
4.3.4 Testy kolizí mezi tělesy
Platforma v sobě integruje již vytvořený objekt jménem CollisionDetector, který má na
starosti provádění testů kolizí mezi obalovými tělesy. Navíc obsahuje metodu která umí
25

určit, jestli se koule nachází před rovinou nebo za rovinou. CollisionDetector dokáže také
zjistit, jestli se krychle nachází za konkrétní rovinou. V neposlední řadě detekuje kolizi mezi
jednotlivými uzly stromu Octree a takzvaným ViewFrustum kamery. Výsledná platforma
podporuje tyto typy kolizí :
ˆ Koule vs koule.
ˆ Koule vs OBB.
ˆ OBB vs OBB.
ˆ GameObject vs GameObject s automatickým rozeznáním obalového tělesa.
ˆ GameObject vs strom objektů GameObject tvořený hierarchií uzlů Transform. Opět
dojde k automatickému rozpoznání obalového tělesa.
ˆ AABB vs AABB.
ˆ Octree vs ViewFrustum kamery.
Za zmínku stojí algoritmus, pomocí kterého se testuje kolize mezi OBB a OBB. Překvapivě se
nejedná o tak jednoduchý algoritmus, jak se na první pohled zdá. Anglicky se metoda testu
nazývá jako Separating Axis Theorem. Princip je takový, že se nejprve oba OBB promítnou
na osu. Pokud jsou promítnuté intervaly disjunktní, tak tělesa mezi sebou nekolidují. Celkem
stačí otestovat 15 různých os.
4.3.5 Objekt Contact
V případě, že objekty mezi sebou nekolidují, tak testovací metody vrátí booleovskou hodnotu
false. Jiné je to však v momentě, kdy dojde k detekci kolize. Fyzikální systém si bohužel
nevystačí pouze s informací, že dva objekty do sebe narazily. Příklad kolize je na následujícím
obrázku 4.11
Obrázek 4.11: Ukázka kolize OBB s koulí. Převzato z [12]
Zde přichází na řadu objekt Contact, který v sobě zahrnuje tyto doplňující informace:
26

Kolizní normálu - Kolizní normála určuje směr, ve kterém došlo ke kolizi, a ve kterém by
měla být dvě kolidující tělesa oddělena.
Hloubku zanoření - Kolidující objekty se pouze nedotýkají. Jelikož se kolize testuje po
určitých časových intervalech, tak dojde k zanoření objektů. Hloubka zanoření určuje,
o kolik by se měla tělesa posunout ve směru/protisměru kolizní normály, aby již nedocházelo
ke kolizi.
Kolizní body - Kolizní bod může být jen jeden, například dvě kolidující koule se dotýkají
pouze v jednom bodě. Jiný případ nastane, pokud dva OBB objekty do sebe narazí
hranami, to má za následek, že vnikne více kolidujících bodů. Kontaktní body zatím
nebudou naimplementovány.
Koeficient odrazu - Tato vlastnost se nikterak nevypočítává. Je dána podle toho, jaká
dvě rigidní tělesa kolidují.
Třecí sílu - Třecí síla udává, jestli se tělesa mohou smýkat v bodě odrazu. Taktéž se nejedná
o vypočítanou hodnotu, ale je součástí vlastností rigidních těles. Protože výsledný
fyzikální systém nebude zatím podporovat rotace, nebude tato síla zatím naimplementována.
4.4 Základní fyzikální systém
Fyzikální vlastnosti objektu má ve výsledné platformě na starosti komponenta RigidBody,
o které již bylo zmíněno v podkapitole 4.2.5 na straně 15. Fyzikální simulace poskytuje realističtější
chování objektů, než kdyby docházelo k přímému ovlivňování uzlu Transform.[12]
Hned na začátku je nutné napsat, že ve výsledku bude naimplementována jen část potřebných
vlastností. Rotace budou z důvodu větší složitosti prozatím vynechány a bude je nutné
naimplementovat někdy v budoucnu. Fyzikální systém se tím pádem svým chováním bude
spíše blížit částicovému systému.
První podkapitola 4.4.1 přibližuje integrační metodu komponenty RigidBody a popisuje
samotnou komponentu. Další podkapitola 4.4.2 se zaměřuje na fyziku založenou na pružině.
Poslední podkapitola 4.4.3 se zabývá registrem působících sil.
4.4.1 Integrační metoda rigidního tělesa
V každém snímku je zapotřebí aktualizovat pozici objektu. Integrátor se skládá ze dvou částí:
ˆ První část aktualizuje pozici objektu
ˆ novaP ozice =
pozice ˆ + rychlost ˆ · interval
ˆ Druhá část aktualizuje rychlost objektu
ˆ novaRychlost =
rychlost ˆ + zrychlení ˆ · interval
27

Nová pozice objektu závisí na rychlosti a na zrychlení. Zatímco nová hodnota rychlosti
závisí pouze na zrychlení, podle druhého Newtonova zákona, který říká, jestliže na těleso
působí síla, pak se těleso pohybuje se zrychlením, které je přímo úměrné působící síle a
nepřímo úměrné hmotě tělesa, se vypočte hodnota zrychlení takto :
ˆ zrychlení =
ˆF
hmota
Rigidnímu tělesu je tedy nutné předat informaci o hmotě. Integrátor vždy jako poslední
operaci provede vynulování působící síly. Jednotlivé síly, které jsou předány rigidnímu tělesu
se sčítají a zrychlení je vypočítáno z výsledné síly.
Vstupem do integrátoru je hodnota, která udává čas, který uplynul mezi minulým a aktuálním
snímkem. Frame-rate pro fyzikální systém by měl být v budoucnu vylepšen, protože
každý počítač může mít frame-rate rozdílný. Používá se například stanovení hodnoty pro
další frame, atd. Výsledná implementace používá stejnou smyčku pro provádění fyziky a
pro rendering. Tyto smyčky se někdy oddělují a pro každou se vytvoří vlastní vlákno. V
javascriptu takovou věc bohužel nelze provést, protože neumí pracovat s vlákny. Lze použít
jen určitou techniku časování.
Rigidní těleso obsahuje ve výsledku dvě důležité proměnné:
ˆ Hmotu tělesa v kilogramech, která určuje, jak je těleso těžké a jak dobře je s ním možné
hýbat.
ˆ Výslednou sílu v newtonech, která v sobě obsahuje všechny síly aplikované na objekt.
Jiné proměnné jako je rychlost a zrychlení by neměly být ovlivňovány přímo, ale jsou vypočítány
integrační metodou.
4.4.2 Pružina
Pružina je ve fyzikálních enginech velice často používána. Pomocí pružiny lze naimplementovat
například pohyb kamery za avatarem, pohyb vlajky, vlny na moři, pohyb oblečení,
atd. Hookeův zákon matematicky popisuje chování pružiny. Hook objevil, že síla vyvinutá
pružinou závisí na délce stlačení a nebo roztažení pružiny. Tento jev je určen vzorcem:
ˆF = =tuhostP ružiny · roztažení ˆ
Další silou, která působí proti stlačení nebo roztažení je tlumící síla, která je dána vztahem:
ˆF = =tlumícíKonstanta · rychlost ˆ
Tyto síly se ve výsledku sečtou a vznikne výsledná síla.
Všechny tyto výpočty týkající se pružiny má na starosti konstruktor Spring. Po jeho
zavolání vznikne objekt, u kterého je nutné nastavit vlastnosti vyplývající z výše uvedeného
textu:
ˆ tlumící konstantu
ˆ tuhost pružiny
28

Další dvě důležité proměnné jsou pozice a požadovaná pozice. Pokud jsou tyto hodnoty
stejné, tak pružina nevyvíjí žádnou sílu. Rozdílem těchto vektorů je vektor roztažení. Z výše
napsaných vztahů již zbývá jen pokrýt rychlost a jakému rigidnímu tělesu mát být vzniklá síla
přiřazena. Pro tento účel slouží metoda updateForce(duration, gameObject), která by měla
být volána v každém snímku. GameObject je objekt, který obsahuje komponentu RigidBody
a bude mu do výsledné síly připočítána síla vzniklá pružinou. Tlumící síla se vypočte z
rychlosti daného rigidního tělesa. Duration je opět interval mezi jednotlivými snímky. V
pružině sice není potřeba, ale tato metoda by měla ve všech objektech, které vyvíjejí nějakou
sílu, vypadat stejně. Například takto může být přidán objekt, který vyvíjí gravitační sílu,
atd.
4.4.3 Registr působících sil
Sil působících na konkrétní objekt může být velice mnoho. Jedna síla může navíc ovlivňovat
více objektů, například vítr, gravitační síla, atd. Myšlenka je taková, že se vytvoří generátor
síly, jako příklad může posloužit výše zmíněná pružina. Takový generátor musí mít vždy
metodu updateForce(duration, gameObject), kde GameObject je objekt s rigidním tělesem,
na který bude působit výsledná síla.
Registr sil má tři jednoduché metody:
ˆ add(gameObject,forceGenerator), pomocí které dojde k registraci dvojice GameObject
- ForceGenerator. Síla vyvinutá tímto generátorem bude ovlivňovat rigidní těleso v
gameObjectu. Takto může být přidáno neomezené množství dvojic.
ˆ remove(gameObject,forceGenerator), pomocí které dojde k vymazání dvojice Game-
Object - ForceGenerator.
ˆ updateForces(duration), která v cyklu projde všechny zaregistrované dvojice a pokaždé
spustí metodu updateForce(duration, gameObject) příslušného generátoru síly. Za gameObject
dosadí zaregistrovaný objekt.
Výše popsaný způsob se hodí pro scény, kde se vyskytuje velké množství sil a objektů, na
které síly působí. Ve výsledné ukázce není Registr sil použit. Síla je do rigidního tělesa
přidána z komponenty Script, která je přiřazena vesmírnému plavidlu.
4.5 Rozdělení prostoru
Objektům ve scéně mohou být přiřazena obalová tělesa, která urychlují detekci kolizí mezi
objekty, ačkoliv to má tu nevýhodu, že detekce není tak přesná, jako kdyby kolidovaly přímo
samotné meshe mezi sebou. Tímto ale není vyřešeno to, jak najít dvojice objektů, které
mezi sebou mohou kolidovat. Testování typu každý z každým by bylo v tomto případě velice
neefektivní, protože se ve scéně bude nacházet velké množství objektů.
Existují techniky, které rozdělují prostor na menší části, a které testují, zda dva nebo
více objektů nesdílí stejný prostor. Jelikož objekty mohou vzájemně kolidovat pouze tehdy,
29

sdílí-li stejnou část prostoru jako druhý objekt, tak je tímto způsobem významně redukován
počet možných kolidujících dvojic.
Existují 3 hlavní typy metod pro rozdělení prostorů, které jsou rozebírány v následujících
podkapitolách.
4.5.1 Mřížky
Existují mřížky, které prostor rozdělují na stejné části. Jedná se o tzv. Uniform grids. Objekty
jsou přiřazeny oblastem, ve kterých jsou obsaženy. Jedná se o velice oblíbenou metodu.
Problém, který je s mřížkami spojen, spočívá ve stanovení velikosti buňky, což je znázorněno
na následujícím obrázku 4.12
Obrázek 4.12: (a) Buňky jsou moc malé. (b) Buňky jsou zbytečně velké. (c) Buňky jsou velké
s ohledem na velikost objektu. (d) Buňky jsou moc velké a zároveň moc malé. Převzato z
[13]
Výše zmíněný problém řeší hierarchické mřížky, kde větší objekty jsou umístěny do
mřížky, která má větší rozměr buněk. Malé objekty jsou naopak umístěny do mřížky s menšími
buňkami. Pro výslednou ukázku, která se odehrává ve vesmíru, jsou mřížky dobrou
volbou, ale přednost dostala metoda založená na řazení.
4.5.2 Stromy
Scéna je rozdělena do stromové struktury. Kořen stromu obaluje celou scénu. Potomci pokrývají
části scény, které obaluje jejich rodič. Takto může být vytvořen strom o požadované
hloubce. Na dalších několika řádcích bude popsán strom typu Octree, který byl vybrán k
implementaci do výsledné platformy.
Octree je osově zarovnaný strom, kde každý uzel má přesně osm potomků. Kořen stromu
tvoří co nejmenší krychle, která pokrývá celou scénu.
Tato krychle je rozdělena na osm podkrychlí, které tvoří potomky daného uzlu, což zobrazuje
následující obrázek 4.13. Další potomci jsou dále tvořeny rekurzivně stejným způsobem.
Typické kritérium pro zastavení rekurzivního algoritmu je maximální hloubka stromu.
30

Obrázek 4.13: Číslování jednotlivých potomků stromu. Převzato z [13]
Každý uzel stromu si uchovává tyto hodnoty:
ˆ pozici středu
ˆ poloviční velikost hrany
ˆ reference na osm potomků
ˆ pole obalových koulí, které jsou přiřazeny danému uzlu
Existují dva rozdílné přístupy při vkládání objektu do stromu. Zde bude popsán pouze ten
způsob, který je ve výsledku naimplementován. Při vkládání objektu se nejprve detekuje,
zda se obalová koule nenachází uvnitř některého z osmi potomků. Pokud se rozprostírá přes
více než jednu buňku, tak bude odkaz na obalovou kouli uložen do aktuálního uzlu. Je-li
koule obsažena pouze v jedné buňce, tak se algoritmus bude rekurzivně opakovat, dokud
koule nepřesáhne více jak jednu buňku a hloubka bude menší než maximálně povolená.
Nevýhodou tohoto postupu je, že se obalová koule někdy nebude nacházet tak hluboko, jak
by bylo ve skutečnosti možné. Pro statickou scénu by bylo lepší dělení objektu a ukládání
odkazu na kouli do všech buněk, ve kterých se vyskytuje. Pro pohyblivý objekt je naopak
vhodnější první způsob, protože se nemusí aktualizovat více ukazatelů, ale pouze jenom
jeden. Ve výsledné ukázce se ale i přesto používá tento strom pouze pro statickou scénu,
protože i přes použití první verze algoritmu, není standardní Octree strom vhodný pro mnoho
pohybujících se objektů. Pokud bude problém s výkonem, tak je možné naimplementovat
druhou verzi algoritmu. Strom nemusí být na začátku vytvořen celý. Potomci uzlů se mohou
tvořit dynamicky podle toho, zda je do nich přiřazena některá obalová koule. Za zmínku stojí
informace, že existuje Loose octree, který dovoluje dynamicky měnit velikost buněk, což řeší
některé problémy.
4.5.3 Řadící mechanismy
Jak mřížky, tak stromy řeší problémy spojené s přesahem obalových těles do více buněk.
Alternativou k těmto metodám jsou určitým způsobem seřazené objekty ve scéně. Výsledně
naimplementovaná metoda se nazývá Sweep and prune.
Sweep and prune
je metoda, která funguje na principu, že si v obousměrně zřetězeném
spojitém seznamu uchovává minimální a maximální hodnoty pro jednotlivé AABB konkrét-
31

ních těles. Celkem obsahuje 3 spojité zřetězené seznamy pro každou osu. Metodu přibližuje
následující obrázek:
Obrázek 4.14: Minimální a maximální body jednotlivých AABB v dané ose jsou seřazeny dle
velikosti. Převzato z [13]
Pokud dojde k posunutí AABB, je nutné aktualizovat pozici minimálního a maximálního
bodu ve spojitém seznamu. Metoda, která toto provádí, se nejprve podívá nalevo, zda aktuální
hodnota není menší než předchozí hodnota. Pokud zjistí, že je menší, podívá se dále,
dokud není nalezeno správné místo pro danou hodnotu. Ta je z původního místa smazána a
následně vložena mezi dvě správné hodnoty. Obdobným způsobem se porovnávají hodnoty
směrem doprava ve zřetězeném seznamu. Během hledání správného místa pro konkrétní hodnotu
se hlídá, zda nedošlo k překrytí intervalu AABB s jiným AABB. Pokud se zjistí, že ano,
tak je proveden test detekce kolize mezi těmito AABB. V případě, že je test pozitivní, je
nalezená dvojice přidána mezi kandidáty na kolizi. Dále se během hledání musí ohlídat, zda
naopak nedošlo k oddělení dvou intervalů. Pokud ano a objekty se nacházejí mezi kandidáty
na kolizi, je nutné konkrétní záznam odstranit. Ve skutečnosti nejsou v seznamu uložené
samotné hodnoty, ale reference na AABB. Navíc je součástí informace, která říká, zda se
jedná o minimální nebo maximální hodnotu. Metoda, která vkládá nové AABB do seznamu,
pracuje na podobném principu.
Obecně se očekává, že se aktualizace seznamu provede v lineárním čase. Pokud se nachází
mnoho objektů v jedné ose moc blízko u sebe, může být složitost O(n 2 ). Například se jedná
o objekty položené na podlaze, jak znázorňuje následující obrázek 4.15 :
Obrázek 4.15: Na obrázku vidíme objekty, které se nacházejí kousek od sebe v jedné ose.
Pouze malý pohyb objektu může způsobit, že se hodnota uložená v seznamu posune o mnoho
pozic. Převzato z [13]
Jelikož se jedná o poměrně efektivní metodu a zároveň nemusí být řešeny problémy s
velikostí buněk, byla použita do výsledné ukázkové aplikace. Další nespornou výhodou je, že
32

se ukázka odehrává v prostředí vesmíru. Objekty se proto většinou neshlukují podél jedné z
os, ale jsou různě rozprostřeny, což přesně vyhovuje použité metodě.
33

5 Realizace
V této kapitole se klade za cíl popsat zajímavá a neobvyklá řešení, která byla vybrána z
výsledné implementace ukázkové aplikace.
Hned první podkapitola 5.1 se zaměřuje na popis herní smyčky a možností jejího řešení.
Ve výsledné ukázce bylo nutné řešit vykreslování průhledných objektů. Na problémy s tím
spojené se snaží upozornit podkapitola 5.2. V podkapitole 5.3 je přiblížen postup, jak dochází
k redukci zpracovávaných objektů grafickou kartou. Podkapitola 5.4 detailněji rozebírá
způsob, jakým si uživatelé mezi sebou vyměňují informace po síti a upozorňuje na problémy
s tím spojené. Poslední dvě podkapitoly 5.6 a 5.5 se zaměřují na konkrétní implementace
laseru a generátoru asteroidů.
5.1 Herní smyčka
Herní smyčka určuje, kolikrát za sekundu dojde k aktualizaci scény a jak často se překreslí
plátno, DOM ve webovém prohlížeči. Frekvence by měla být co možná největší, aby nedocházelo
k zasekávání scény. Maximální hodnota opakování by neměla být vyšší než obnovovací
frekvence monitoru, protože by nemuselo dojít k vykreslení některého ze snímků na obrazovku.
První podkapitola 5.1.1 se zabývá samotným popisem RequestAnimationFrame API,
které dnešní prohlížeče nabízejí pro lepší výkonnost. Druhá podkapitola 5.1.2 přibližuje možnosti
použití tohoto API.
5.1.1 RequestAnimationFrame API
Web se v dnešní době stává stále více interaktivním. S vydáním HTML5 bylo uvedeno plátno
Canvas [1], které dovoluje vykreslování různorodé grafiky. S jeho vydáním vzrostl požadavek
na tvorbu efektivnějších animací ve webovém prohlížeči. Dříve se k modifikaci DOMu
webového prohlížeče za běhu používaly a stále se někdy používají metody setTimeout a nebo
setInterval, které dovolují překreslení stránky několikrát za sekundu. Tyto metody nejsou z
pohledu výkonnosti moc efektivní. Animace jsou stále spuštěny i přes skutečnost, že došlo
například k minimalizaci okna prohlížeče, přepnutí na jiný panel a podobně. Dokud nebylo
tvůrci webových prohlížečů poskytnuto RequestAnimationFrame API”[18], tak webová platforma
nenabízela tvůrcům aplikací jiný efektivní způsob, jak naplánovat jejich časování. V
”
dnešní době mnoho aplikací překresluje okno prohlížeče jednou za 10ms. Jde o zbytečně malou
hodnotu, protože většina dnešních monitorů nedokáže aktualizovat obraz častěji než za
16.7ms. To má za následek, že se některé snímky ztratí a vůbec se nevykreslí, což někdy vede
k trhání výsledné animace.
34

RequestAnimationFrame API”pracuje podobně jako setTimeout nebo setInterval. Hlavní
”
rozdíl spočívá v upozornění aplikace, že prohlížeč potřebuje aktualizovat obsah svého okna.
Aplikace jsou tedy více svázány s obnovovací frekvencí okna webového prohlížeče. Počet opakování
za sekundu není určen pevně, ale je dán zmíněným API. Na následujícím obrázku 5.1
je vidět rozdíl ve výkonu mezi setTimeout a RequestAnimationFrame API.
Obrázek 5.1: Rozdíl ve výkonu mezi setTimeout a RequestAnimationFrame API. Převzato
z [18]
API není zatím naimplementováno ve všech prohlížečích. Následující obrázek ukazuje
podporu API jednotlivých verzí prohlížečů.
Obrázek 5.2: Některé verze prohlížečů implementují API již nějakou dobu, jiné prohlížeče
naopak API zatím ignorují a nebo ho připravují v budoucích verzích. Převzato z [19]
35

RequestAnimationFrame API stejným způsobem jako setTimeout provádí jedno zpětné
volání libovolné funkce. Z tohoto důvodu je nutné v případě potřeby více opakování, volat
zmíněné API na konci cyklu, který má na starosti animační smyčku. Každý prohlížeč
poskytuje API pod jiným názvem, protože jeho implementaci nemají zcela ukončenou.
5.1.2 Použití RequestAnimationFrame API v aplikaci
Nejdříve je nutné zjistit, pod jakým pracovním názvem se API v nejrozšířenějších prohlížečích
nachází. Toto má na starosti níže uvedený fragment kódu, který je k dispozici ve výsledné
platformě:
window . requestAnimFrame = ( f u n c t i o n ( ) {
// RequestAnimationFrame API j e z c e l a naimplementováno
return window . requestAnimationFrame | |
// implementace v p r o h l í ž e č i Chrome
window . webkitRequestAnimationFrame | |
// F i r e f o x implementace
window . mozRequestAnimationFrame | |
// p r a c o v í verze Opera Presto
window . oRequestAnimationFrame | |
// implementace IE
window . msRequestAnimationFrame | |
// případ , kdy p r o h l í ž e č nepodporuje
RequestAnimationFrame API
f u n c t i o n ( c a l l b a c k , element ) {
return window . setTimeout ( c a l l b a c k , 1000/60);
} ;
} ) ( ) ;
Herní smyčka poté ve výsledné ukázce vypadá následovně:
f u n c t i o n loop ( ) {
var currentTime = new Date ( ) . getTime ( ) ;
i f ( t h i s . lastTime !=0){
var elapsedTime = currentTime − that . lastTime ;
/ / . . metody ř e š í c í animace , k o l i z e , r e n d e r i n g . . .
that . lastTime = currentTime ;
}
// nekonečné opakování smyčky pomocí RequestAnimationFrame API
nebo metody setTimeout
window . requestAnimFrame ( loop , $(”#webGl−canvas ”) [ 0 ] ) ;
}
36

5.2 Průhlednost objektů
Existují různé [?]způsoby, jak dosáhnout efektu průhlednosti. Z pohledu renderovacích algoritmů
jsou uplatňovány 2 typy efektů:
ˆ Takzvaný View based” efekt, kdy je poloprůhledný objekt sám vyrenderován.
”
ˆ Druhým způsobem je tzv Light-based” efekt, kdy objekt způsobí utlumení nebo odklonění
světla. Výsledkem je větší osvětlení jiných objektů, které jsou nakonec vyren-
”
derovány odlišným způsobem.
V ukázkové aplikaci je použita jednodušší varianta prvního způsobu, kde se poloprůhledný
objekt ve své podstatě chová stejně jako barevný filtr, který je aplikován na všechny objekty
za ním.
První podkapitola 5.2.1 se zaměřuje na popis Z-bufferu a jeho nevýhody. Podkapitola
5.2.2 popisuje techniku pro správné vykreslení průhledných objektů ve scéně.
5.2.1 Z-buffer a jeho nevýhody
Z-buffer v počítačové grafice řeší problém s viditelností objektů. Pokud je objekt vyrenderován,
hloubka vykresleného pixelu je zaznamenána v Z-bufferu. Tento buffer je většinou
udělán jako dvojrozměrné pole, které odpovídá jednotlivým pixelům. V případě, že musí být
na obrazovku vykreslen jiný objekt, který se překrývá s původním, tak dojde k porovnání
hloubky jednotlivých pixelů. Do Z-bufferu se zapíší pouze pixely, které se nacházejí blíže
k pozorovateli. Ostatní pixely budou ignorovány a nedojde k jejich vykreslení. Z-buffer je
součástí většiny moderních grafických akcelerátorů.
Proč jsou vlastně v tuto chvíli zmiňovány Z-buffery? Jejich nevýhoda spočívá ve faktu,
že si drží hodnotu pouze pro jeden naposledy uložený pixel. Výsledkem je, že Z-buffer sám
o sobě nemůže vyřešit efekt průhlednosti. Jestliže se více průhledných objektů nachází v
rámci jednoho pixelu, tak je nemožné vyhodnotit efekt průhlednosti pro všechny objekty.
Dalším příkladem může být těleso, které má být vidět skrze jiný průhledný objekt. Jelikož
dojde k jeho vykreslení později, jsou pixely za průhledným objektem ignorovány a nedojde
k jejich vykreslení. Zmíněný problém je možné vyřešit pomocí takzvaného A-bufferu, který
pracuje na podobném principu. Velice podstatnou nevýhodou je, že není mezi grafickými
akcelerátory tolik rozšířen, takže jeho použití nepřipadá v úvahu.
5.2.2 Vykreslení průhledných objektů
Pro vykreslování průhledných objektů se často využívá techniky nazvané Alpha blending
”
”, kdy dochází k mísení barvy průhledného tělesa s barvou objektu za ním. Průhlednost
objektu určuje hodnota alpha”. Každý pixel tedy obsahuje informaci o barvě RGB” a o
” ”
průhlednosti a”, dohromady RGBa. Hodnota 1.0 znamená, že je objekt zcela matný, naopak
”
při hodnotě alpha = 0.0 je objekt zcela průhledný.
37

Operace mísení barev je zcela závislá na pořadí. Nejprve musí dojít k vykreslení matných
objektů, aby bylo možné průhledné objekty míchat s objekty za nimi. Následně je zapotřebí
seřadit všechny poloprůhledné objekty podle vzdálenosti od pozorovatele. Samozřejmě od
nejvzdálenějšího po nejbližší. Až poté je možné poslat grafické kartě poloprůhledné objekty
k vykreslení. Z-buffer v takovém případě může zůstat povolený a vykonávat svoji funkci,
protože se vše vykresluje ve správném pořadí. Obrázek 5.3 z ukázkové aplikace znázorňuje
situaci, kdy nejsou poloprůhledné objekty seřazeny a kdy naopak mají správné pořadí.
Obrázek 5.3: a) Obrázek znázorňuje chyby ve vykreslení, pokud nejsou průhledné objekty
seřazeny. b) Průhledné objekty jsou seřazeny.
5.3 Viditelnost objektů
Grafické karty dokáží velice efektivně provádět paralelní výpočty nad geometrickými objekty.
Pokud bychom ale chtěli vyrenderovat 5000 objektů s 10000 trojúhelníky, tak bychom si moc
nezahráli. Grafické kartě není nutné posílat ke zpracování vše, co se ve scéně nachází. Proč
zpracovávat geometrická tělesa, která uživatel na obrazovce nevidí. Proto se používá metoda,
která je popsána v podkapitole 5.3.1. Další metodu optimalizace přibližuje podkapitola 5.3.2.
5.3.1 View frustum culling
Takzvané View frustum[?] ve tvaru pyramidy je definováno celkem 6 plochami, které jsou
uloženy v komponentě Camera. Těchto 6 ploch přesně určuje oblast, kterou uživatel aktuálně
vidí. Následujícím způsobem dojde k identifikaci statických objektů, které mají být
vyrenderovány:
ˆ Každý objekt je umístěn v uzlu stromu Octree, o kterém bylo psáno v kapitole 4.5.2
na straně 30.
ˆ Před renderováním každého snímku se provede test kolize mezi výše zmíněným stromem
a pyramidou, která definuje viditelnou oblast.
ˆ Kolizní algoritmus vrátí všechny objekty, které se nacházejí v uzlech kolidujících s
pyramidou.
38

Výše zmíněným postupem došlo k významné redukci objektů, které mají být poslány k
vyrenderování. Ale přesto je strom Octree naimplementován tak, že se mezi objekty dostanou
i takové, které se nenacházejí ve viditelné oblasti. Pokud by výkon grafických karet nestačil,
může dojít k testu kolize mezi pyramidou a nalezenými objekty. Jedná se konkrétně o test
View frustum - koule. Tím se dosáhne požadovaného výsledku. Bohužel strom Octree se
nehodí v aktuální implementaci k uchovávání dynamických objektů. Takový objekt by při
každém pohybu musel být ze stromu vymazán a následně do něj vložen. Z tohoto důvodu je
nutné provést test kolize mezi pyramidou pro každý objekt zvlášt’. Teoreticky by šlo použít
způsob, kterým se testují kolize mezi všemi objekty ve scéně. Pyramida by v takovém případě
musela být obalena krychlí. Poté už by se jen při každém pohybu hledali kandidáti na kolizi.
5.3.2 Backface culling
Backface culling je proces, při kterém dochází k identifikaci polygonů, které uživatel vidí.
Tentokrát není potřeba nic implementovat, jedná se o standardní výbavu grafických karet.
Pokud je Backface culling povoleno, tak dochází k ignorování polygonů, které uživatel nevidí.
Nedochází ke zbytečnému zpracování vertexů, které se nacházejí na odlehlé straně. Ve
výsledné aplikaci je Backface culling povoleno.
5.4 Multiplayer
Ukázková aplikace se odehrává v prostředí vesmíru, kde uživatelé mohou například ovládat
vesmírné plavidlo, vytvářet nové brány a asteroidy. Všechny tyto změny a mnohé další se
musejí promítnout u ostatních uživatelů, kteří se nacházejí ve stejný okamžik ve scéně. V
prostředí internetu nikdy nelze dosáhnout stavu, že by uživatelé na druhé straně viděli změny
v reálném čase. Vždy bude existovat určité zpoždění, s kterým se musí tvůrci her pro více
hráčů vypořádat.
Popisem známých architektur se zabývá podkapitola 5.4.1. Druhá podkapitola 5.4.2 popisuje
vlastní implementaci multiplayeru v ukázkové aplikaci.
5.4.1 Známé architektury
V herním průmyslu existují dvě základní metody pro synchronizaci scény mezi uživateli[21]:
Peer - too - peer - Jednotliví klienti komunikují přímo mezi sebou a vyměňují si informace
formou zpráv. Například, pohnul jsem se o tolik a tolik, postavil jsem budovu na tomto
místě, atd. Neexistuje žádný centrální server a nebo je pouze použit pro navázání
komunikace mezi jednotlivými klienty. V dnešní době se metoda peer-to-peer už tolik
nepoužívá. Můžeme ji vidět například v některých RTS hrách. Jsou s ní spojeny určité
nevýhody. Není vždy zaručeno, že hra bude vypadat u každého hráče stejně. Někdy se
mohou lišit jednotky, takže dojde k posunutí o jinou vzdálenost. Hráč se nemůže jen
tak připojit v průběhu hry. Dále bývá problém v animacích a obecně v synchronizaci
scény.
39

Klient - server - Jedná se o doménu většiny akčních her. Místo toho, aby každý klient
vykonával stejný kód a jednotliví klienti komunikovali mezi sebou, tak každý klient
komunikuje pouze se serverem. Hlavní logika hry se vykonává pouze na serveru a
jednotlivý klienti tvoří jakýsi terminál. Na server se odesílají pouze data ze vstupních
zařízení jako je myš a klávesnice. Server aktualizuje na základě těchto dat stav scény a
vrátí data s novou polohou hráče včetně informací o polohách ostatních hráčů. Aby byl
pohyb ostatních hráčů plynulý, je nutné provádět interpolaci mezi předchozími stavy.
Co se týče vlastní postavy ve hře, tak je nutné provádět predikci pohybu. Nějakou
dobu totiž trvá než server vrátí novou polohu postavy. Odezva na vstup by tedy nebyla
okamžitá a k pohybu postavy by došlo se zpožděním. Z tohoto důvodu se nečeká na
odpověd’ serveru, ale normálně dojde k pohybu postavy. Server je autoritativní, takže
pokud se pozice dodaná serverem bude lišit od té predikované, tak je nutné ji změnit.
Zde ale nastává problém, server totiž poskytne data například 200ms stará a hráč by se
posunul zpět v čase. Proto existuje buffer, který si pamatuje po určitou dobu všechny
minulé stavy postavy včetně všech zmáčknutých kláves a tlačítek. Pokud přijde korekce
od serveru, tak se zahodí všechny stavy, které jsou starší než aktuálně příchozí stav.
Postava hráče se vrátí na pozici příchozího stavu a následně se na ni aplikují všechny
vstupy uložené v bufferu. V takovou chvíli se postava nachází na správném místě a
nedojde k posunutí v čase. Tento postup se neustále opakuje.
5.4.2 Implementace multiplayeru v ukázkové aplikaci
Do této doby Jetty server splnil vše, co se od něj očekávalo. Problém nastal při implementaci
multiplayeru. Jetty server je totiž javovský a kód pro WebGl je psán v javascriptu. Z tohoto
důvodu nemohla být použita implementace typu klient - server. Zde přichází v úvahu otázka,
zda neexistuje lepší řešení, než kombinace WebGl + WebSocket + Jetty server? Odpověd’
zní ano. Jako ideální volba se jeví kombinace WebGl + WebSocket + Node.js. Node.js se
totiž chová jako standardní server, jehož kód se píše v javascriptu.
Z výše napsaného textu vyplývá, že každý klient bude muset vykonávat svůj vlastní herní
kód, což odpovídá metodě Peer-to-peer. Není to tak úplně pravda, protože jednotliví klienti
nebudou mezi sebou komunikovat přímo, ale přes prostředníka. Technologie WebSockets totiž
neumožňuje přímou komunikaci mezi webovými prohlížeči. Jednotliví klienti jsou připojeni
k Jetty serveru, který má za úkol rozesílat data všem ostatním připojeným klientům. Ve
vytvořené platformě je připraven objekt Multiplayer, pomocí kterého je možné se připojit
k serveru. Každý klient je identifikován pod svým Id. Objekt Multiplayer obsahuje metodu
pro odesílání dat ve formátu JSON ostatním klientům. Do této metody je možné vložit id,
kterému klientovi se má informace poslat. Výchozí hodnotou je all”, což znamená, že se data
”
rozešlou všem ostatním klientům.
Klienti se ve výsledné aplikaci mohou kdykoliv odpojovat a připojovat, což je pro metodu
Peer-to-peer problém. Další problém nastal, kdy do scény měly být na začátku vygenerovány
různé asteroidy. Kdyby každý klient při spuštění vygeneroval své asteroidy, tak by se vlastně
každý hráč na začátku pohyboval v jiném prostředí. Oba zmíněné problémy řeší připojení
speciálního klienta, který plní úlohu serveru a jehož Id je Server”. Takový klient musí být
”
40

vždy jen jeden.
V dalším textu je pod pojmem server myšlen připojený speciální klient, nejedná se tedy o
Jetty server. Na serveru je spuštěn stejný kód jako na jednotlivých klientech, ale nedochází k
renderování informací na obrazovku. Další důležitou vlastností serveru je, že si pamatuje stav
aktuální scény se všemi objekty a hráči. Pokud je zapotřebí na začátku vytvořit společnou
scénu, například výše zmíněné asteroidy, tak musí být vytvořena jen pomocí serveru. V
případě, že dojde k připojení nového klienta k Jetty serveru, je uplatněn následující postup:
ˆ Klient informuje server, že se připojil.
ˆ Server přidá mezi své objekty novou lod’ a přiřadí jí komponentu NetwokView, o které
bylo psáno v kapitole 4.2.5 na straně 15. Následně jí nastaví unikátní Id. V dalším
kroku přiřadí lodi komponentu Script, která má na starosti přijímání a odesílání zpráv
pro daný objekt. Navíc tato komponenta provádí interpolaci stavu daného objektu,
aby byl pohyb plynulý.
ˆ Server odešle novému klientovi všechny informace o aktuální scéně a o ostatních hráčích.
Poté všem ostatním klientům odešle všechna potřebná data o nově připojeném
klientovi.
ˆ Nově připojený klient vytvoří objekty na základě dat, které přijal ze serveru. Všechny
takto vytvořené objekty musejí mít komponentu NetworkView s Id, které přiřadil server
dané komponentě konkretního objektu. Stejně jako na serveru je novým objektům
přiřazena komponenta Script, která slouží k interpolaci stavu jednotlivých pohyblivých
objektů a k přijímání (odesílání) zpráv, které se týkají konkrétního objektu.
ˆ Všichni ostatní klienti provedou podobné úkony jako výše popsaný klient, ale pouze
pro nově přidanou lod’ připojeného klienta.
ˆ Poté již dochází ke standardní komunikaci mezi klienty. Pomocí komponenty Script a
metody sendState se posílá všem klientům a serveru informace o nové pozici hráče.
Stejná komponenta u jiných objektů slouží pro příjem nového stavu daného objektu.
U pohyblivých objektů, které neřídí sám uživatel, dochází pomocí komponenty Script
k interpolaci rotace a pozice z minulých stavů objektu, aby byl pohyb plynulý.
Server a jednotliví klienti používají dva rozdílné objekty multiplayer, které dědí vlastnosti
z objektu WGLP. Multiplayer z výsledné platformy. Rodičovský objekt obsahuje základní
metody pro připojení a komunikaci. Všechny odchozí zprávy musí obsahovat název příkazu,
který se má spustit u protějšího klienta nebo serveru. Jeden z výše uvedených multiplayer
objektů zprávu přijme a spustí metodu se stejným názvem, který byl uveden v příkazu.
Využívá se vlastnosti javascriptu, že názvy objektů či metod mohou být doplněny dynamicky.
V javascriptu jsou si totiž následující zápisy rovny:
// neměnný název metody
s e r v e r M u l t i p l a y e r . addSpaceShip ( ) ;
// název volané metody může být změněn
s e r v e r M u l t i p l a y e r [ ” addSpaceShip ”] ( ) ;
41

Skript, který provádí interpolaci, potřebuje ke své činnosti vědět, s jakým zpožděním
přicházejí nové stavy objektu. Z tohoto důvodu má objekt WGLP.Multiplayer zabudovanou
metodu checkLatency, která následujícím způsobem zjistí zpoždění mezi Jetty serverem a
připojeným klientem :
ˆ Metoda odešle na Jetty server informaci o aktuálním času.
ˆ Jetty server ihned odešle informaci klientovi zpět.
ˆ Klient zjistí zpoždění pomocí vztahu : zpoždění = (aktuálníČas - původníČasOdesláníZprávy)/2.
Každý klient musí jednou za čas aktualizovat zpoždění mezi Jetty serverem. Pokud se posílá
stav některého z objektů, tak se v rámci jedné zprávy vždy odešle informace o zpoždění
prvního klienta s Jetty serverem. Na druhém konci se k tomuto zpoždění přičte zpoždění
druhého klienta s Jetty serverem, který zprávu obdržel. Tím se získá celková hodnota, která
je potřebná k interpolaci.
Klient, který tvoří server, není autoritativní. Všichni klienti nedostávají informace o stisknutých
klávesách, tlačítkách, ale přímo obdržují nový stav objektu. Takový způsob není
ideální z pohledu bezpečnosti, protože kdykoliv někdo může ostatním klientům podstrčit
upravená data. Například se hráč může uměle teleportovat na jiné místo a ostatní klienti
tomu uvěří, což u autoritativního serveru není možné. Takový přístup by nebyl ve stávající
architektuře vhodný, protože server není ve skutečnosti server, ale speciální klient. Data by
musela cestovat přes Jetty server ke speciálnímu klientovi a zase zpět, což by akorát zvětšovalo
hodnotu zpoždění, a to není žádoucí. Navíc nemusí být řešen problém s predikcí.
Očekává se také, že případní uživatelé aplikací postavených na koncové platformě, nebudou
podvádět.
5.5 Generátor asteroidů
Ve scéně se nachází mnoho asteroidů. Z pohledu uživatele není dobrým řešením, aby každý
asteroid vypadal zcela totožně. Jejich tvar a velikost by měly být variabilní. První, ne zcela
ideální možností je vymodelovat několik asteroidů v modeláři a ty podle určitého vzorce ve
scéně střídat. Jelikož uživatelé mají možnost generovat své vlastní asteroidy, tak by došlo k
velice brzkému okoukání těch stávajících. Scéna by si zasloužila asteroidy rozmanitých velikostí,
tvarů a případně barev. Proto bylo hledáno ideální řešení, jak programově vygenerovat
tyto skalní útvary.
Prví podkapitola 5.5.1 ukazuje princip použitého algoritmu. Druhá podkapitola 5.5.2 se
zabývá popisem problému, který nastává v případě, kdy spuštěný skript trvá moc dlouhou
dobu.
5.5.1 Algoritmus pro generování asteroidů
Nakonec bylo nalezeno řešení, které vyhovuje potřebám výsledné scény. Došlo k modifikaci
algoritmu[22], pomocí kterého se dají například vytvořit různě zvrásněné kontinenty na mo-
42

delu planety země. Postupuje se v několika krocích:
1. Na začátku se nachází pravidelná koule získaná z modeláře.
2. Dojde k náhodnému zvětšení nebo zmenšení koule.
3. Koule je rozpůlena náhodně vygenerovanou rovinou.
4. Všechny vertexy, které se nachází před rovinou, jsou posunuty o náhodnou hodnotu
směrem od středu.
5. Všechny vertexy, které se nachází za rovinou, jsou posunuty o stejnou hodnotu směrem
ke středu.
6. Body 3 až 5 jsou opakovány x krát, kde x je náhodně vygenerované celé číslo.
Následující obrázek zobrazuje náhodně vygenerované plochy a výsledek po několika iteracích:
Obrázek 5.4: a) Počáteční koule rozpůlená rovinou. b) Koule je rozpůlena jinou rovinou.
Vertexy před rovinou se posunuly směrem ke středu a vertexy za rovinou směrem od středu.
c) Výsledek po několika iteracích.
5.5.2 Problém s generováním více asteroidů
Webové prohlížeče si obecně neumějí poradit se skripty, které trvají moc dlouhou dobu.[23]
V takovém případě zobrazí hlášku, která upozorňuje uživatele, že skript pracuje neúměrně
43

dlouho a zda si přeje počkat na jeho dokončení. Nejspíše se jedná o nějakou formu bezpečnostního
opatření. Navíc v typické smyčce vytvořené pomocí cyklů for” nelze aktualizovat DOM
”
prohlížeče, protože je zablokovaný. Bohužel není zablokovaný jen pro vývojáře, ale také pro
uživatele, takže prohlížeč nereaguje na žádná kliknutí. Při generování například 1000 asteroidů
dojde k vyskočení zmíněné hlášky, uživatel nemůže být informován o průběhu generování
a navíc je blokované okno prohlížeče.
Výše uvedené problémy lze vyřešit pomocí metody setTimeout(). Při jejím vykonávání
se na chvíli uvolní DOM prohlížeče, takže může být aktualizován jeho obsah. Cyklus for” ”
lze bud’ celý nahradit metodou setTimeout(), a nebo je možné uvedenou metodu volat jen
jednou za x provedených cyklů for”. S tímto způsobem jsou spojeny určité problémy, ale
”
svůj hlavní účel plní. V ukázkové aplikaci se uživateli takto zobrazuje číslo generovaného
asteroidu.
5.6 Laser
Laser je ve výsledné aplikaci používán k sestřelování bran a asteroidů. Měl by mít hezký
vzhled a působit realisticky.
Podkapitoly 5.6.1 a 5.6.2 popisují techniku zvanou Billboarding. Podkapitola 5.6 používá
techniku popsanou v předchozích dvou podkapitolách.
5.6.1 Billboarding
Z důvody tvorby laseru byla do platformy přidána podpora billboardů [?] ve formě nového
BillboardRendereru. Jedná se o orientovaný a otexturovaný polygon, který se otáčí v závislosti
na pohybu kamery. Pomocí Billboardů s průhlednými texturami a animacemi mohou
být vytvářeny různorodé efekty, které není možné udělat efektivně pomocí geometrických
těles. Výborným příkladem je vegetace, obzvláště tráva. Dále kouř, oheň, mlha, exploze, atd.
Billboardy se někdy používají k nahrazení objektu. Především v momentě, kdy se uživatel
nachází ve větší vzdálenosti a již není schopen rozeznat detaily původního geometrického
tělesa. Tím se ušetří výpočetní výkon, protože není potřeba renderovat komplexní objekt,
ale pouze otexturovanou plochu. Dalším příkladem užití je HUD, na kterém se uživateli zobrazují
informace o hře. Při programování WebGl aplikací je snadnější HUD vytvořit pomocí
elementů jazyka HTML, protože se jedná o webovou stránku.
Rotace billboardu se většinou určuje dvěma vektory(up, forward). Problém je v tom,
že na sebe nebývají většinou kolmé, což není přípustné. Podle typu billboardu se jeden z
těchto vektorů stane fixním. Pomocí vektorového součinu se nejprve vypočte třetí vektor,
který je kolmý na oba zmíněné. Poté dojde k výpočtu vektoru, který není fixní a to tak,
že se provede vektorový součin mezi fixním a nově vypočítaným vektorem. Všechny tyto tři
vzniklé a následně normalizované vektory tvoří rotační matici billboardu.
44

5.6.2 Nejpoužívanější typy billboardů
Existují tři základní druhy billboardů, které se nejčastěji používají. Všechny tři jsou naimplementovány
ve výsledné platformě. Při tvorbě komponenty BillboardRenderer je nutné si
zvolit požadovaný typ billboardu. Samozřejmě je potřeba poskytnout rendereru všechny důležité
informace o požadovaném billboardu. Především jde o rozměry, kameru a směr fixního
vektoru.
Billboard zarovnaný s obrazovkou již svým názvem napovídá, že jde o billboard rovnoběžný
s obrazovkou a jehož vektor směřující vzhůru (up vector) je konstantní. Up ”
vektor” je totožný s up vektorem” kamery. Jde o typ billboardu, který se v různých
”
aplikacích používá například jako HUD.
Billboard orientovaný směrem k pozorovacímu bodu je vždy natočený směrem ke
kameře (fixní vektor) a jehož vektor směřující vzhůru je pevně daný a nezávislý na
rotaci kamery.
Obrázek 5.5: Billboardy orientované směrem k pozorovacímu bodu
Osově zarovnaný billboard není primárně natočen směrem ke kameře a navíc může rotovat
kolem libovolné osy. Jednoduše řečeno má fixní ”
up vector” a jeho ”
forward vektor”,
který ukazuje směrem ke kameře, je až podružný.
5.6.3 Tvorba laseru
Laser je vytvořen pomocí osově zarovnaného billboardu pokrytého průhlednou texturou červeného
laseru. Orientace vesmírné lodi určuje směr up vektoru”. Pokud uživatel stiskne
”
klávesu, která obsluhuje laser, dojde k jeho roztažení ve směru up vektoru”. S roztažením je
”
nutné posunout laser tak, aby vždy začínal na špičce vesmírné lodi. MeshRendreru laseru je
přiřazen obalový OBB, který nejlépe odpovídá tvaru billboardů. Reakce laseru na stisknutou
klávesu zařizuje komponenta Script, která je přiřazena konkrétnímu objektu GameObject.
Podle polohy objektu se obalová tělesa sice posouvají a rotují, ale nedochází k jejich zvětšení.
Proto je nutné s roztahováním laseru také zvětšovat OBB ve stejném směru. Výsledný laser
je zobrazen na následujícím obrázku 5.6 na následující straně:
45

Obrázek 5.6: Laser z ukázkové aplikace
46

6 Testování
Aplikace byla otestována nejen z uživatelského hlediska, ale také s důrazem na nalezení
implementačních chyb. V první podkapitole 6.1 se rozebírají nalezená zjištění od uživatelů
především co se týče ovládání ukázkové aplikace. Druhá podkapitola 6.2 se zaměřuje na
implementační chyby aplikace.
6.1 Uživatelský test
Výsledná aplikace je zaměřena spíše na mladší generaci, ale nic nebrání starším lidem, aby
si ji vyzkoušeli. Pokud má uživatel základní znalosti počítačů, je schopen ovládat myš a
klávesnici, může se ponořit do vytvořené virtuální reality.
Uživatelé obecně neměli problém s pochopením uživatelského rozhraní. Spuštění scény
se obešlo většinou bez větších komplikací. Lod’ se ovládá jen pomocí klávesnice, což byl asi
největší kámen úrazu. Lidé jsou z dnešních her spíše zvyklí na ovládání pomocí myši. Velice
často se stávalo, že si uživatelé pletli klávesy. Chtěli se například otočit kolem osy x a místo
toho zrychlili pohyb lodě. V několika případech se stalo, že uživatel místo brány vygeneroval
nový asteroid. Pro nové hráče by asi byla každá brána malá, protože se častěji stávalo, že
došlo k nárazu. Velikost zůstane ale nezměněna, protože jde spíše o již zmíněný problém s
ovládáním.
Z provedeného testu lze usuzovat, že by uživatelé uvítali alespoň částečné ovládání pomocí
myši. Dále z testování vyplynulo, že trvá delší dobu, než si uživatelé zapamatují funkcionalitu
jednotlivých kláves. Přeci jenom možností, kam se může lod’ pohybovat, je trochu více.
6.2 Test aplikace
Aplikace byla otestována takovým způsobem, že se spustila hlavní scéna a připojilo se několik
uživatelů. Problémů nebylo nalezeno mnoho, ale přeci jenom se určité nedokonalosti aplikace
projevily. Při masivnějším přístupu uživatelů došlo k pádu aplikace. V konzoli se následně
začaly objevovat samé hodnoty null, popřípadě jiné výjimky týkající se kolekce, ve které
jsou na serveru uloženi všichni připojení uživatelé. Problém aktuálně není vyřešen, ale text
výjimek naznačuje, že by se mohlo jednat o chybu způsobenou vlákny, které se snaží najednou
přistupovat v jeden okamžik k výše zmíněné kolekci. Jedno vlákno například čte z kolekce
data a druhé se snaží vymazat záznam, což u kolekce HashMap najednou nelze. Jak již bylo
napsáno, aplikace zcela spadla, takže správně nepracovalo ani počítadlo aktuálně připojených
uživatelů. Scénu bylo sice možné uložit, ale následné spuštění se nezdařilo, protože soubor
obsahoval chybná data.
Dalším zjištěným problémem bylo, že scéna nevydržela připojená přes noc. Technologie
WebSockets totiž automaticky po nějaké době odpojuje klienta, který dlouho nevykazoval
žádnou činnost a ani nedocházelo z jeho strany k příjmu dat od jiných uživatelů. Z tohoto
důvodu se řídící scéna nejspíše odpojila, protože neměla s kým komunikovat. Řešením by
bylo pravidelné informování serveru, že klient zůstává aktivní.
47

Problémy se týkaly především sít’ové komunikace. Co se týče samotné hry a prostředí,
významné chyby nebyly zatím objeveny.
48

7 Závěr
Cílem práce bylo navrhnout a naimplementovat webovou platformu pro interakci uživatelů v
3D prostoru. Vlastnosti platformy měly být demonstrovány na ukázkové aplikaci. V kapitole
2 byly stanoveny cíle práce, které se vesměs podařilo splnit, a to bud’ s menšími nebo většími
obtížemi. WebGl není jedinou technologií, pomocí které je možné prezentovat 3D objekty
ve webovém prohlížeči. Vývojová platforma Unity se zdá být výborná a také posloužila
jako hlavní inspirace pro návrh struktury platformy. Co se týče Stage3D, tak i zde je velký
potenciál k masivnějšímu rozšíření, protože téměř není člověka, který by neměl nainstalovaný
Flash přehrávač na svém PC. Bude velice zajímavé sledovat, jaká z těchto technologií se více
prosadí, a která spíše zapadne do stavu zapomnění.
Co se týče architektury, tak se podařilo najít celkem použitelnou strukturu, která dává
určitý smysl. Každý objekt ve scéně je vytvořen konstruktorem GameObject s jedinečným
Id, na který jsou následně nabalovány komponenty podle potřeby. Komponenty objektu
přidají fyzikální vlastnosti, obalí ho tělesem, obohatí ho o určitou logiku, umožní jeho vykreslení
a obecně doplní různou funkcionalitu. Není problém vytvořit si vlastní konstruktor
objektu s požadovanými proměnnými, metodami a následně zdědit všechny vlastnosti objektu
GameObject. Platforma totiž neobsahuje jen objekty, metody,třídy, které jsou potřeba
k vykreslování či fyzice. Ale musely být naimplementovány takové struktury jako je oboustranně
zřetězený seznam, dále metoda umožňující dědění vlastností jiného objektu , metoda
umožňující rozšíření stávajícího objektu a podobně.
Analýza dále ukázala, že existuje velké množství obalových těles, která se hodí jen na
určité typy objektů. To samé platí v případě stromů, mřížek, řadících algoritmů, pro které
platí, že ne vždy se hodí do každé situace. Proto je třeba vždy velice zvážit jaké obalové těleso
se přiřadí objektu, a nebo jaká se použije metoda na dělení prostoru. Fyzikální systém je
určitě velice užitečný, protože dokáže simulovat chování reálného světa. Pomocí pružiny lze
dosáhnou takových efektů, jako je houpání hladiny moře, pohyb oblečení a podobně. Pružina
je také ideální volbou pro to, aby byl pohyb kamery za avatarem dynamický a nestála stále na
jednom místě. Škoda jen, že se nestihl naimplementovat částicový systém, pomocí kterého je
možné vytvářet efekty jako je kouř, oheň, mlha, exploze a podobně. Implementaci takového
systému lze budoucímu vývojáři jen doporučit.
V kapitole 5 bylo ukázáno, že není dobré pro různé animace v prohlížeči používat metodu
setTimeout, protože je neefektivní s ohledem na výpočetní výkon. Je lepší využívat prohlížečem
nabízené API, které šetří čas i peníze. Dále bylo ukázáno, jak tvořit zajímavé tvary
asteroidů pomocí náhodně vygenerovaných rovin a posouváním vertexů. Musel být také vyřešen
problém se sdílením scény mezi uživateli, kdy nakonec byla použita taková podivná
kombinace metod klient - server a peer - to - peer. Rozhodně by bylo lepší v budoucnosti
vyměnit Jetty server za Node.js, protože je možné jeho kód psát v javascriptu.
Testování v kapitole 6 ukázalo, že ukázková aplikace netrpí zásadními nedostatky. Většinou
se jednalo o problémy spojené se sít’ovou komunikací, které zatím nebyly vyřešeny.
Nejspíše to bylo způsobeno tím, že se dvě vlákna snažila najednou měnit či číst jednu a tu
samou kolekci. Tímto směrem by se měl budoucí vývojář vydat při hledání chyby.
49

Celkově se nejednalo o snadnou práci, protože se týkala najednou více témat, která spolu
více či méně souvisela, ale za to těch zkušeností bylo získáno opravdu velké množství, které
budou určitě někdy zužitkovány. Pro budoucího vývojáře je připraven základ platformy, která
se nadále může vesele rozvíjet a nadále rozšiřovat.
50

Reference
[1] LAWSON, Bruce ; SHARP, Remy . Introducing HTML5. Berkeley : New Riders, 2011.
223 s.
[2]
JIŘÍ, Žára, Bedřich BENEŠ, Jiří SOCHOR a Petr FELKEL. Moderní počítačová grafika.
Vyd 1. Brno: Computer Press, 2004, 609 s. ISBN 80-251-0454-0
[3] SCABIA, Marco. How Stage3D works. Adobe [online]. 3.10.2011 [cit. 2012-05-
18]. Dostupné z: http://www.adobe.com/devnet//flashplayer/articles/how- stage3dworks.html
[4] UNITY: Game Development Tool [online]. San Francisco, © 2012 [cit. 2012-05-17].
Dostupné z: http://unity3d.com
[5] MUNSHI, Aaftab a Jon LEECH. OpenGL ES Common Profile Specification [online].
Verze 2.0.25. The Khronos Group Inc., 2.11.2010 [cit. 2012-05-18]. Dostupné z:
http://www.khronos.org/registry/gles/specs/2.0/es full spec 2.0.25.pdf
[6] MARRIN, Chris. WebGL Specification. The Khronos Group Inc.
[online]. Version 1.0. 10.2.2011 [cit. 2012-05-18]. Dostupné z:
https://www.khronos.org/registry/webgl/specs/1.0/
[7] THOMAS, Giles. Learning WebGL [online]. 13.10.2009 [cit. 2012-05-18]. Dostupné z:
http://learningwebgl.com/blog/?p=28
[8] WebSocket.org – A WebSocket Community [online]. Kaazing Corporation, © 2012 [cit.
2012-05-19]. Dostupné z: http://www.websocket.org/index.html
[9] SOMMER, Benjamin. Benjamin Sommer Weblog [online]. 13.5.2012 [cit. 2012-05-
19]. Dostupné z: http://weblog.benjaminsommer.com/blog/2012/05/13/comparison-ofwebgl-framework-apis/
[10] GLGE WebGL Library/Framework [online]. GLGE, 12.2.2012 [cit. 2012-05-20]. Dostupné
z: http://www.glge.org/api-docs/
[11] JONES, Brandon. High performance matrix and vector operations for WebGL
[online]. GitHub · Social Coding, ©2011 [cit. 2012-05-20]. Dostupné z:
https://github.com/toji/gl-matrix
[12] MILLINGTON, Ian. Game physics engine development: how to build a robust
commercial-grade physics engine for your game. 2nd ed. Boston: Morgan Kaufmann
Publishers, c2010, xxix, 522 p. ISBN 01-238-1976-8.
[13] ERICSON, Christer. Real-time collision detection. Vyd. 1. Boston: Morgan Kaufmann,
2005, 591 s. ISBN 15-586-0732-3.
[14] GLASSNER, A. Graphics gems I. San Diego: Academic Press, 1998, 301 - 303. ISBN
0-12-286166-3.
51

[15] LENGYEL, Eric. Mathematics for 3D game programming and computer graphics, third
edition. 3rd Ed. Boston, MA: Cengage Learning, 2011, 212 - 216. ISBN 1435458869.
[16] COLLADA - 3D Asset Exchange Schema. The Khronos Group Inc. [online]. ©2012 [cit.
2012-05-22]. Dostupné z: http://www.khronos.org/collada/
[17] Wavefront .obj file. In: Wikipedia: the free encyclopedia [online]. San Francisco
(CA): Wikimedia Foundation, 2.5.2012 [cit. 2012-05-22]. Dostupné z:
http://en.wikipedia.org/wiki/Wavefront .obj file
[18] Using PC Hardware more efficiently in HTML5: New Web Performance APIs,
Part 1. MANN, Jatinder. MSDN Blogs [online]. 6.7.2011 [cit. 2012-05-22]. Dostupné
z: http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-moreefficiently-in-html5-new-web-performance-apis-part-1.aspx
[19] When can I use requestAnimationFrame?. When can I use...: Compatibility tables for
support of HTML5, CSS3, SVG and more in desktop and mobile browsers. [online]. 2012
[cit. 2012-05-23]. Dostupné z: http://caniuse.com/requestanimationframe
[24] MÖLLER, Tomas Akenine. Real-time rendering. 3rd ed. Wellesley, Mass.: A.K. Peters,
c2008, xviii, 1027 s. ISBN 978-1-56881-424-7.
[21] FIEDLER, GLENN. What every programmer needs to know about game networking.
Glenn Fiedler’s Game Development Articles and Tutorials [online].
24.1.2010 [cit. 2012-05-23]. Dostupné z: http://gafferongames.com/networking-forgame-programmers/what-every-programmer-
needs-to-know-about-game -networking/
[22] Spherical Landscapes. The good-looking textured light-sourced bouncy fun
smart and stretchy page [online]. 22.11.2003 [cit. 2012-05-24]. Dostupné z:
http://freespace.virgin.net/hugo.elias/models/m landsp.htm
[23] The Secret of Keeping Web Apps Responsive. Windy Road [online]. 30.3.2007 [cit.
2012-05-25]. Dostupné z: http://windyroad.org/2007/03/30/web -apps-the-new-singlethreaded-gui/
[25] FALCONER, Aubrey. NetworkView Position Sync. Unify Community
[online]. 10.1.2012 [cit. 2012-05-27]. Dostupné z:
http://www.unifycommunity.com/wiki/index.php?title=NetworkView Position Sync
[26] JQuery: The Write Less, Do More, JavaScript Library [online]. © 2012 [cit. 2012-05-27].
Dostupné z: http://jquery.com/
52

A
Balíky platformy
Obrázek A.1: Balíčky, které strukturují zdrojový kód
54

B
Celkový UML diagram
Obrázek B.1: Celkový uml diagram, který obsahuje všechny důležité třídy (konstruktory)
56

C
Uživatelská příručka
Instalace
Není nutné nic instalovat. Aplikace pouze vyžaduje javu minimálně ve verzi 1.7. Ke spuštění
stačí webový prohlížeč s podporou WebGl a WebSockets. Chrome a Firefox již minimálně
rok obě technologie podporují. Internet Explorer bohužel technologii WebGl nepodporuje a
zatím to ani nemá v plánu.
Nastavení
Před spuštěním je potřeba nastavit v souboru websockets settings.js ip adresu a port. Soubor
se nachází v adresáři ./webapp/scenes/space/app/.
Spuštění Jetty serveru
Zkompilovaný server se nachází v kořenovém adresáři projektu. Server se spouští přes konzoli
pomocí následujícího přikazu:
java − j a r s e r v e r . j a r parametr1 parametr2 parametr3
kde
parametr1 je ip adresa, na které se má spustit server. Nastavena defaultně na ”
localhost”.
parametr2 je port. Defaultně nastaven na 8080.
parametr3 je webový adresář s aplikací. Defaultně nastaven na ”
./webapp”.
Spuštění
Po zadání ip adresy do prohlížeče se objeví následující úvodní okno:
58

Obrázek C.1: Úvodní obrazovka
Vždy při prvním načtení úvodního okna je třeba spustit hlavní řídící scénu. Ta se spouští
stisknutím klávesy S a následným kliknutím na tlačítko Spustit novou scénu. Pozor, neklikat
v tomto případě na tlačítko Spustit v úvodním okně . Řídící scéna musí být spuštěna vždy
jen jedna.
Obrázek C.2: a) Okno, které se objeví po stisknutí klávesy S v úvodním okně. b) Okno
informující o stavu scény po jejím spuštění. Pomocí tlačítka Uložit scénu lze uložit aktuální
stav scény.
59

Řídící scéna nejprve vygenerovala několik asteroidů a poté došlo k jejímu spuštění. Objevilo
se informační okno, které ukazuje aktuální počet připojených uživatelů. Scénu je možné
kdykoliv uložit. V průběhu hraní nesmí dojít k zavření okna webového prohlížeče, ve kterém
je spuštěna řídící scéna.
V tuto chvíli je potřeba otevřít nové okno prohlížeče a zadat opět ip adresu serveru.
Otevřelo se Úvodní okno, stejné jako na obrázku C.1 na předchozí straně. Po kliknutí na
tlačítko Spustit se objeví nová zatím neznámá obrazovka. Viz další obrázek C.3:
Obrázek C.3: a) Okno, kde se uživatel může připojit jako nový hráč. b) Okno, kde si uživatel
může vybrat ze seznamu odpojených hráčů a přebrat jeho vesmírnou lod’.
Na první pohled zaujme přepínač, který nabízí 2 možnosti:
Nový hráč - V případě zvolení této možnosti musí uživatel vyplnit přezdívku pod jakou si
přeje ve scéně vystupovat. Poté stačí kliknout na tlačítko Spustit scénu.
Vybrat hráče - Zde se uživatel nepřipojuje jako nový hráč, ale může si vybrat ze seznamu
odpojených hráčů. Po spuštění scény je mu přiřazena lod’ bývalého hráče na poslední
známé pozici. Nový hráč přebírá původní přezdívku odpojeného hráče.
Nyní je spuštěna scéna.
60

Obrázek C.4: Okno se scénou. Vlevo nahoře je vidět vzdálenost uživatele od středu, rychlost a
uplynulý čas od průletu první brány. Vpravo nahoře se objevují informace o nově připojených
nebo odpojených hráčích.
Kdykoliv je potřeba uložit stávající scénu, tak je nutné otevřít okno webového prohlížeče,
kde se nachází spuštěná řídící scéna. Jde o stejné okno jako na obrázku C.2 na straně 59,
konkrétně jde o obrázek b).
Co se týče načtení uložené scény, tak se postupuje zcela stejně jako když se spouští nová
řídící scéna, akorát s tím rozdílem, že se neklikne na tlačítko Spustit novou scénu, ale na
tlačítko Nahrát uloženou scénu. Tím dojde ke spuštění uložené scény.
C.0.1
Ovládání
Vpřed / vzad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .W/S
Zastavení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C
Vlevo / vpravo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Q/E
Nahoru / dolu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .R/F
Rotace kolem osy x (pitch) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . U/J
Rotace kolem osy y (yaw) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A/D
Rotace kolem osy z (roll) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . H/K
Vytvoření brány . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B
Vygenerování asteroidu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V
Laser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Mezerník
Kamera nahoru / dolu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 / 1
Kamera vpřed / vzad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 / 4
61

Označení první brány (restart závodu) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0
C.0.2
Hra
Závod se spustí průletem první brány. Závodit může i více závodníků najednou, ale každému
se čas měří od prvního průletu. Každý závodník vidí zvýrazněnou příští bránu (pro sebe) a
méně zvýrazněné příští brány ostatních připojených účastníků. Pokud nemá bránu v zorném
poli, vidí po straně obrazovky šipku ukazující nejbližší vzdálenost. Hráč může po stisku
klávesy nechat vygenerovat asteroid nebo bránu. Asteroidy a brány je možné sestřelovat
laserem. Závod lze pro sebe restartovat stisknutím klávesy 0.
62

D
Obsah přiloženého CD
Obrázek D.1: Výpis souboru readme.txt
64