VYSOKÉ UČENÍ TECHNICKÉ V BRNĚBRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMAČNÍCH TECHNOLOGIÍÚSTAV POČÍTAČOVÉ GRAFIKY A MULTIMÉDIÍ

FACULTY OF INFORMATION TECHNOLOGYDEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA

3D HRA S TECHNOLOGIÍ LEAP MOTION

BAKALÁŘSKÁ PRÁCEBACHELOR’S THESIS

AUTOR PRÁCE MATĚJ MAINUŠAUTHOR

BRNO 2014

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚBRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMAČNÍCH TECHNOLOGIÍÚSTAV POČÍTAČOVÉ GRAFIKY A MULTIMÉDIÍ

FACULTY OF INFORMATION TECHNOLOGYDEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA

3D HRA S TECHNOLOGIÍ LEAP MOTION3D GAME WITH LEAP MOTION CONTROLLER

BAKALÁŘSKÁ PRÁCEBACHELOR’S THESIS

AUTOR PRÁCE MATĚJ MAINUŠAUTHOR

VEDOUCÍ PRÁCE Ing. MICHAL ŠPANĚL, Ph.D.SUPERVISOR

BRNO 2014

AbstraktCílem této bakalářské práce bylo navrhnout a implementovat 3D hru labyrint ovládanoupomocí gest rukou. Pro rozpoznávání pohybu a gest hra využívá technologii Leap Motion,aplikace samotná je vytvořena v herním enginu Unity. Výsledkem práce je multiplatformní3D hra s vlastní knihovnou, která integruje Leap Motion SDK do Unity a eliminuje chybyv detekci rukou.

AbstractThe goal of this bachelor’s thesis is to design and create a 3D labyrinth game controlled byhand gestures. This is achieved by using the Leap Motion sensor. Results of this thesis arethe cross-platform 3D game based on Unity engine and a custom library that integratesLeap Motion SDK to the Unity engine. The developed library is able to suppresses detectionerrors introduced by the common LeapMotion SDK.

Klíčová slovaLeap Motion, ovládání pohybem rukou, ovládání gesty, Unity, C#, hra

KeywordsLeap Motion, hands motion control, gestures control, Unity, C#, game

CitaceMatěj Mainuš: 3D hra s technologií Leap Motion, bakalářská práce, Brno, FIT VUT v Brně,2014

3D hra s technologií Leap Motion

ProhlášeníProhlašuji, že jsem tuto bakalářskou práci vypracoval samostatně pod vedením pana Ing.Michala Španěla, Ph.D.

. . . . . . . . . . . . . . . . . . . . . . .Matěj Mainuš

19. května 2014

PoděkováníRád bych poděkoval Ing. Michalu Španělovi, Ph.D. za věcné připomínky a vedení práce.

c© Matěj Mainuš, 2014.Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informa-čních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávněníautorem je nezákonné, s výjimkou zákonem definovaných případů.

Obsah

1 Úvod 3

2 Možnosti detekce gest rukou 42.1 Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Wiimote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 Leap Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Leap Motion SDK 73.1 Struktura API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Detekce a klasifikace objektů . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Reprezentace rukou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.4 Reprezentace prstů a nástrojů . . . . . . . . . . . . . . . . . . . . . . . . . . 83.5 Gesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.6 Problémy a nedostatky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Tvorba 3D her v Unity 114.1 Scéna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Zdroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 Skripty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4 Fyzika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.5 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.6 Optimalizace scén . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Návrh 3D hry labyrint ovládané pohybem rukou 155.1 Herní princip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Ovládání hry pohybem rukou . . . . . . . . . . . . . . . . . . . . . . . . . . 165.3 Rozšíření Leap Motion API . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.4 Menu, scény a labyrinty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.5 Herní engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.6 Fyzika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Implementace hry 226.1 Struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.2 Ovládání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.3 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.4 Modely, textury, materiály, shadery, světla a animace . . . . . . . . . . . . . 246.5 Knihovna rozšiřující Leap Motion SDK . . . . . . . . . . . . . . . . . . . . . 26

1

7 Testování a hodnocení 27

8 Závěr 29

A Obsah CD 32

B Manual 33

2

Kapitola 1

Úvod

Tématem mé bakalářské práce je návrh a realizace 3D hry s technologií Leap Motion. Totozadání jsem si vybral, protože Leap Motion je nové zařízení o kterém dosud není napsánomnoho prací a jedná se o velmi zajímavý senzor využitelný právě ve hrách. Cílem mé práceje vytvořit 3D hru labyrint ovládanou pohybem rukou s využitím zařízení Leap Motiona za pomoci herního enginu Unity. V aplikaci je kladen důraz na jednoduchost a přesnostovládání, na grafické zpracování a přenositelnost mezi platformami. Součástí práce je vlastníknihovna, která integruje Leap Motion SDK do Unity, přidává podporu v ovládání GUI,eliminuje falešné objekty a odchytává stav kdy zařízení nekorektně rozpoznává orientaciobjektů.

V úvodní kapitole jsou popsány dostupné možnosti detekce rukou a jejich gest. V ná-sledující kapitole je podrobněji popsáno zařízení Leap Motion, dále pak práce pokračujekapitolou o herním enginu Unity. Kapitola o návrhu aplikace popisuje také herní principy,ovládání, fyziku ve hře a návrh vlastní knihovny rozšiřující Leap Motion API. Následujekapitola o implementačních detailech skriptů, postupu tvorby scén, modelů a textur. Nakonci práce jsem popsal testování aplikace a nastínil možnosti další vývoje.

3

Kapitola 2

Možnosti detekce gest rukou

Smyslem této kapitoly je popsat, jakými dostupnými způsoby lze detekovat pohyb rukou ajejich gesta. Tato kapitola popisuje speciální zařízení pro detekci gest, jako jsou Kinect 2.3,Wiimote 2.2 nebo Leap Motion 2.4, jejich přednosti, výhody a nevýhody.

Cílem této bakalářské práce, bylo vytvořit 3D hru, která je ovládána pohybem rukou agesty. Ty lze snímat pomocí kamery, nebo nějakým speciálním zařízením jako je napříkladKinect nebo Leap Motion. Tyto zařízení kombinují více kamer snímajících prostor v různémspektru, proto je snímání objektů těmito zařízeními přesnější, než obyčejnou kamerou.K těmto zařízením je k dispozici sada nástrojů, které urychlují vývoj aplikace, protožeautor nemusí řešit detekci, klasifikaci, a sledování objektů. Existují i zařízení, které pracujína jiném principu než je rozpoznávání obrazu, jako je tomu například u ovladače Wiimotenebo u teprve vyvíjeného ovladače Myo 1.

2.1 Kamera

Snímání obrazu kamerou, detekce rukou v obraze, a následné rozpoznávání a klasifikacegest je základní způsob, jaký použít k řešení problému ovládání aplikace gesty. Výhodoutohoto řešení je, že k němu není potřeba žádný speciální a drahý hardware. U tohoto řešeníje ale nezbytné použít algoritmy pro detekci rukou v obraze a klasifikaci gest, které popisujínapříklad práce[7][13][1]. Detekce a klasifikace pak probíhá z důvodu složitých algoritmůna velmi malém počtu snímků za sekundu, což může mít vliv na latenci ovládání ve hrách.Při snímání kamerou s nízkým rozlišením, může být detekce nepřesná a při použití pouzejedné kamery nelze přesně určit pozici objektu v prostoru. Z tohoto řešení však vycházejíspeciální zařízení jako je například Kinect.

2.2 Wiimote

Wiimote je skupina ovladačů ke konzolím Wii od společnosti Nintendo. Tyto zařízení máuživatel v ruce, vypadají dálkový ovladač a obsahují tří směrový akcelerometr a kameru.Akcelerometrem lze detekovat velmi výrazné pohyby rukou, kamera pak slouží pro určenípozice vůči konzoli[14]. Ovladač se však nikdy oficiálně nepoužíval jinak, než s konzolemiNintendo.

1https://www.thalmic.com/en/myo/

4

Obrázek 2.1: Hra ovládána senzorem Wii[2].

2.3 Kinect

Kinect je senzor pro snímání pohybu lidí od společnosti Microsoft, původně navržený jakoovladač ke konzoli Xbox, později však bylo vydáno SDK i pro platformu Windows. Tatotechnologie je založena na kameře, hloubkovém infračerveném senzoru a speciálním čipupro urychlení výpočtů. Výstupem ze zařízení jsou informace o kloubech kostry až dvoulidi[3]. Pro jeho původní zaměření je Kinect využíván často ve ve hrách, kde jako ovladač,slouží hráčovo tělo. Povětšinou se pro ovládání používají velmi výrazné pohyby a gesta,jako například mávnutí rukou, výskok, kopnutí, . . . Oproti zařízení Leap Motion nedokážesledovat pohyby dlaní a prstů, z důvodu nízkého rozlišení hloubkové kamery[12].

Obrázek 2.2: Ovládání hry senzorem Kinect[4].

5

2.4 Leap Motion

Leap Motion je speciální snímač uvedený na trh v roce 2013, který je navržený pro snímánírukou, prstů nebo také různých předmětů, jako jsou například tužky nebo pera. Snímačse skládá ze dvou infračervených kamer a tří diod. Jeho výhodou je přesné prostorovésnímání[17] dvou rukou s rychlostí až dvě stě snímků za sekundu[6]. Pro vývojáře je k dis-pozici multiplatformní SDK které podrobněji popisuje kapitola 3. Vývojáři mohou své apli-kace s navrženým nebo upraveným ovládáním pro Leap Motion umisťovat do aplikačníhoobchodu Airspace2.

Obrázek 2.3: Součásti zařízení Leap Motion.

2.4.1 Ovládání aplikací pomocí snímače Leap Motion

Na vývojářských webových stránkách3 jsou zveřejněny směrnice pro ovládání menu, tudížvšechny aplikace by se měly těmito pokyny řídit. Ovšem existují i výjimky, jako jsou aplikaceurčené k ovládání desktopového uživatelského rozhraní. Na ovládání hry nejsou kladenyžádné nároky, ale existují dva hlavní způsoby ovládání. Jsou ovšem k vidění i aplikace,které lze ovládat i pomocí nástrojů, jako jsou pera nebo tužky.

• První skupinou jsou aplikace ovládané pouze gesty. U těch nezávisí na poloze ruky, alena provedeném gestu. Pro ovládání se používají velmi výrazná, dobře detekovatelnágesta, jako například švihnutí rukou, nebo virtuální dotek obrazovky

• Do druhé skupiny spadají aplikace ovládané polohou nebo náklonem ruky. U nichse používají spíše mírnější gesta jako například uchopení předmětu, kliknutí prstem,sevření ruky v pěst. . . Existují i aplikace využívající kombinace ovládání senzoremLeap Motion a klávesnice.

2https://airspace.leapmotion.com/3https://developer.leapmotion.com/documentation/csharp/index.html

6

Kapitola 3

Leap Motion SDK

Tato kapitola popisuje základní aspekty práce s Leap Motion SDK, Jejím cílem je popsathlavní a důležité části API, naznačit jakým způsobem s ním pracovat a ukázat jaké in-formace lze ze zařízení získat a k čemu je využít. Není cílem této kapitoly popsat všechnyčásti, spíše jeho vlastnosti, výhody a nevýhody které se odráží v návrhu ovládání aplikace.Kapitola čerpá z oficiální dokumentace[5].

Sekce 3.1 popisuje strukturu API. V Části 3.2 jsem naznačil jakým způsobem se zpra-covávají snímky. Sekce 3.3 a 3.4 se zaměřují na práci s detekovanými objekty, 3.5 na prácise základními gesty a v poslední části 3.6 jsou popsány problémy a nedostatky SDK.

Leap Motion SDK je oficiální programovací rozhraní pro Leap Motion. Lze ho stáh-nout jako registrovaný vývojář z vývojářských stránek1. SDK je dostupné pro operačnísystémy Windows, Linux a OSX, platformy x86 a x86 64. Jeho součástí je dokumentace,sada příkladů a knihoven pro jazyky C/C++, C#, Java a Python. Pro další jazyky lzepoužít komunitní knihovny které lze najít také na vývojářských stránkách. Zařízení kesvému chodu vyžaduje speciální software, který je dostupný na stránkách projektu. Jehosoučástí jsou ovladače pro senzor, vizuální debugger, aplikace obchodu Airspace a softwarepro nastavení a kalibraci senzoru.

3.1 Struktura API

API Leap Motionu lze rozdělit do čtyř celků.

1. Práce se zařízením

2. Modely detekovaných objektů

3. Gesta

4. Ostatní (vektory, matice, posluchače, utility)

Jednotlivé části API budou popsány v následujících kapitolách.

3.2 Detekce a klasifikace objektů

Detekce a klasifikace objektů se provádí neustále a na pozadí, takže do ní programátorpřes svou aplikaci nemůže zasahovat. K zaznamenaným snímkům lze přistoupit přes třídu

1https://developer.leapmotion.com/

7

Controller , která obsahuje seznam šedesátí posledních snímků. Každý snímek je nezávislýna ostatních a obsahuje seznamy detekovaných rukou, prstů a předmětů. Do této třídy jemožné zaregistrovat posluchače, který je informován o dokončení zpracování dalšího snímkua o odpojení nebo připojení snímače k počítači.

3.3 Reprezentace rukou

Detekovaná ruka je reprezentovaná třídou Hand . Ta obsahuje unikátní číselný identifikátor,kterým je možné provázat ruku mezi snímky, seznam detekovaných prstu a nástrojů, kteréjsou s rukou spojeny. Také je možné získat vektor vzdáleností dlaně od kontroléru, jejíjednotkový normálový i směrový vektor, vektor zrychlení a také dobu po jakou je rukadetekovaná. Vektory jsou reprezentovány v milimetrech a pravorukém kartézkém souřadnémsystému, který je zobrazen na obrázku 3.1

Obrázek 3.1: Souřadnicový systém v Leap Motion API[5].

3.4 Reprezentace prstů a nástrojů

Třídy Finger , Tool reprezentující prst a nástroj, jsou si velice podobné. Obě jsou potomkytřídy Pointable a ta obsahuje prakticky všechny zásadní vlastnosti jako vektor pozic vescéně, jednotkový vektor orientace, vzdálenost od ruky ke které patří, zrychlení oprotipředchozímu snímku a obdobně jako v případě ruky také číselný identifikátor, který jeunikátní pro každý prst nebo nástroj v rámci scény. Pokud uživatel sevře ruku v pěst, dojdek zmizení všech prstů. Když ji poté rozevře, Leap Motion se pokusí přidělit prstům stejnéidentifikační čísla, jako měly předtím. Grafickou reprezentaci dat ze snímače znázorňujeobrázek 3.2.

(a) Vizualizér dodávaný s Leap Motion SDK. (b) Vizuální debugger pro Leap Motion.

Obrázek 3.2: Vizuální reprezentace dat ze senzoru Leap Motion

8

3.5 Gesta

Leap Motion API obsahuje základní sadu tříd pro rozpoznávání gest, jako je švihnutí rukounad senzorem, dotyk virtuální plochy, nebo gesto kruhového pohybu prstu. Jednotlivá gestaa jejich třídy zobrazuje skupina obrázků 3.3. Všechny tyto třídy jsou potomky třídy Gesture.Ta obsahuje vlastnosti jako dobu trvání gesta, seznam rukou, prstů případně nástrojů kterédané gesto provedly, typ gesta a jeho stav. Rozpoznávání těchto základních gest se musíaktivovat v třídě Controller .

(a) SwipeGesture (b) CircleGesture (c) KeyTapGesture

(d) ScreenTapGesture

Obrázek 3.3: Obrázky a třídy reprezentující gesta v Leap Motion API[5].

3.6 Problémy a nedostatky

Tato část se bude zabývat nedostatky a problémy Leap Motion SDK. Tyto problémy anedostatky většinou pramení z problémů při detekci a klasifikaci. Nepopisuji zde všechnyproblémy, ale pouze ty, které jsou významné a důležité pro tuto práci. Praktické ukázkyníže popsaných problémů lze vidět na videích, které jsou součásti přílohy A.

Záměna identifikačních čísel

První velmi důležitý problém je zmizení a znovunalezení objektu. Všechny detekované ob-jekty, ať se jedná o ruce, prsty nebo nástroje, obsahují unikátní identifikační číslo. Jakmiledojde ke zmizení nějakého objektu, byť na velmi krátkou dobu, tak se ve většině případůstává, že mu po znovunalezení kontrolér přidělí jiné identifikační číslo než měl objekt před-tím. U rukou se tento problém projevuje tak, že je ruce přiděleno úplně nové identifikačníčíslo, u prstů jedné ruky je situace poněkud horší. Jak bylo popsáno v sekci 3.4, v pří-padně znovunalezení prsů se jim Leap Motion snaží přidělit stejné id jako měly předtím.Když zmizí více než jeden prst, tak ve velkém množství případů dojde k prohození jejichidentifikačních čísel.

9

Detekce šumu

Druhým neméně častým, ale závažným, problémem je detekce šumu. Občas zařízení dete-kuje i objekty, které se nad ním nenacházejí. Toto chování nezávisí na tom, zda je nějakýreálný objekt již detekován. U těchto objektů také nejsou detekovány žádné prsty nebo ná-stroje a tyto falešné objekty také velmi rychle a prakticky neustále mění svou pozici, rotacii směr, čehož lze využít při jejich eliminaci.

Obrázek 3.4: Vizuální debugger ukazující detekovaný šum.

Určení orientace

Pokud hráč nakloní ruku do pozice, ze které Leap Motion nedokáže po více snímků přesněurčit orientaci, pak zařízení po tuto dobu poskytuje velice rozdílné hodnoty normálového asměrového vektoru. Toto chování lze vidět na sadě obrázku 3.5. Popsaná chyba může mítvelmi negativní vliv na aplikace, které vyžadují velmi precizní ovládání odvozené z těchtoúdajů a je obzvlášť nepříjemná, protože se velmi špatně reprodukuje a ladí.

Obrázek 3.5: Ukázka špatného určení orientace ruky v průběhu času.

Další problémy, které ovšem nejsou důležité pro tuto práci popisuje L. E. Potter[10].Jeho práce se věnuje hlavně problémům s rozpoznáváním prstů, jejich detekci a identifikaci.

10

Kapitola 4

Tvorba 3D her v Unity

V této kapitole jsou popsány vlastnosti a možnosti software Unity. Cílem této kapitoly jeseznámit čtenáře s prvky enginu, které jsem využil v této bakalářské práci, popsat jehovýhody a vlastnosti. Při tvorbě hry jsem vycházel z oficiální dokumentace k Unity[16].

Části této kapitoly popisují práci s scénou 4.1, zdroji 4.2, možnosti skriptování 4.3,fyzikální engine který je součástí Unity 4.4, a tvorbu GUI 4.5.

Unity je souhrnný název pro editor a multiplatformní herní engine. Tento software jedostupný pod dvěma licencemi. Verze Unity Free neobsahuje všechny funkce a lze ji použítpouze k nekomerčním účelům, nebo u firem s obratem do 100 000 USD. Tuto verzi lzestáhnout zdarma z webových stránek1. Druhou verzí je Unity Pro, ta je dále rozdělenapodle cílových platforem. Tyto verze jsou sice placené, ale obsahují všechny funkce, jejichporovnání lze najít na webových stránkách2.

Obrázek 4.1: Unity editor.

1https://unity3d.com/unity/download2https://unity3d.com/unity/licenses

11

4.1 Scéna

Každý projekt v Unity je tvořen ze scén. Scéna je prostor, do kterého se vkládají objekty,světla, zdroje zvuku, kamery, spouštěcí události atd . . . . V průběhu hraní hry se pak přecházímezi jednotlivými scénami.

Rodičem každého prvku scény je GameObject . Ten obsahuje základní informace o ob-jektu, jako jsou pozice, rotace a zvětšení. Každému objektu lze přiřadit další moduly, jakje například renderer, kolizní modely, nebo lze z něj udělat světlo, kameru, zdroj zvuku, aletaké lze na něj aplikovat skupinu skriptů.

Unity používá pro umístění modelů do scény levoruký kartézský systém souřadnic, zob-razeným na obrázku 4.2. Jejich pozici a zvětšení ukládá v tříprvkovém vektoru, rotaci vestuktuře quaternion,

Objektu lze přiřadit značku, podle které s ním lze pracovat ve skriptech, případně hozařadit do vrstev, které slouží například pro omezení působnosti světel a výpočtu stínů,nebo pro omezení výpočtu kolizí, mezi objekty v různých vrstvách.

Obrázek 4.2: Systém souřadnic v enginu Unity.

4.2 Zdroje

V Unity se nazývají všechny externí objekty jako zdroje, ať se jedná o model, texturu,materiál, skript, animaci, skin pro GUI nebo prefab. Zdroje jsou většinou staticky vloženydo scény, existují ale také typy zdrojů, které lze dynamicky za běhu aplikace načítat aodstraňovat. Po vytvoření aplikace jsou zdroje zakomponovány do speciálního balíku, zekterého jsou poté načítány. Verze Pro disponuje vlastností, dovolující načítat i zdroje mimotento balík.

Do Unity lze vložit model a materiály z prakticky všech modelovacích nástrojů. Interněpro převod modelů z většiny těchto nástrojů se používá formát FBX. Přestože lze impor-tovat i materiály, je lepší je vytvářet přímo v Unity, protože materiály jsou zde velice úzcesvázány s shadery. Standardní shadery, které jsou k dispozici v Unity jsou rozděleny dotěchto pěti rodin: Normal , Transparent , Self-Illuminated , Reflective a Mobile. V každé sku-pině se pak nachází některý z shaderů těchto typů: Vertex-Lit , Diffuse, Specular , Bumped ,Parallax a jejich kombinace. Výběr shaderů, který se použije pro rendering materiálu, mávelmi velký vliv na rychlost renderování. Proto je velmi důležité vybírat shadery s ohledemna vlastnosti materiálu, vyhýbat se co nejvíce shaderům z rodiny Transparent , protožeu nich musí probíhat alfa test. V kritických situacích je vhodné používat rychlejší, ale méněsofistikované shadery ze skupiny Mobile. U objektů, které jsou vzdálené od kamery, nebonejsou tak často vidět, není nutné používat drahé shadery s normálovou mapou, která nanich nepůjde poznat. Unity používá pro psané shaderů jazyk Cg od společnosti Nvidia.

12

Unity podporuje 2D a 3D textury všech často používaných formátů. Textury je vhodnévkládat s rozměry, které jsou mocniny dvou, jinak je Unity na tyto rozměry transformuje,což je v některých případech nežádoucí. U textur které se používají jako normálové mapy, jevhodné je takto importovat, protože pak dochází k optimalizacím těchto textur. Normálovoutexturu lze v Unity vygenerovat také z bump mapy.

Jedním speciálním zdrojem je takzvaný Prefab. Tyto zdroje se vytváří přímo v Unitya slouží jako před vytvořené komponenty, skládající se z více GameObjektů. Tyto prefabylze pak používat ve více scénách. Jestliže pak dojde ke změně parametrů nějakého objektuv prefabu, tak se tyto parametry promítnou do všech objektů, které z tohoto prefabuvycházejí.

4.3 Skripty

Skriptovat lze v jednom z jazyků C#, Javascript nebo Boo. Každý objekt pak může ob-sahovat více skriptů, které řídí jeho chování. Tyto skripty obsahují třídu která je potomektřídy MonoBehaviour . Přetížením funkcí této rodičovské třídy lze s objektem manipulovatpomocí velmi rozsáhlého API.

Všechny použité skriptovací jazyky obsahují automatický správce paměti. Ten ale můžebýt zdrojem velkých výkonnostních problému, pokud se ve skriptech provádí velmi častoobrovské množství alokací. Například v jazyce C# je kritické například časté spojování ře-tězců, používání funkcí z LINQ, techniky zvané boxing, ale také použití foreach smyček. Tyv implementaci běhového prostředí Mono, která je součástí Unity, využívají pro průchodinstanci rozhraní IEnumerator alokovanou na hromadě, která je spravována právě auto-matickým správcem paměti[11]. Tyto způsoby mohou mít velký vliv na výkon, pokud seprovádí často například před nebo po vykreslení každého snímku.

4.4 Fyzika

Pro simulaci fyziky používá Unity fyzikální engine PhysX vyvíjený společností Nvidia. Jednáse ale o starší verzi 2.8 z roku 2007[9]. Tento engine je do Unity velmi dobře integrována na první pohled není vůbec vidět. Simulace fyziky je nedílnou součásti každé scény anelze ji vypnout. Jednotlivým objektům ve scéně se přidávají komponenty, které určujífyzikální vlastnosti objektu. Lze do něj přidat skupinu kolizních modelů, vytvořit z nějtuhé těleso, aplikovat na něj konstantní sílu nebo ho spoutat s jiným modelem. Simulacefyziky se provádí pro každý objekt v předdefinovaných časových intervalech, jestliže se všakobjekt nehýbe je tento interval prodloužen. Koliznímu modelu lze také přiřadit fyzikálnímateriál, který určuje jeho statické a dynamické tření a způsob jejich výpočtu při kolizis jiným objektem.

4.5 GUI

Součástí Unity je taky sada API pro práci s GUI. Jeho princip je založen na periodic-kém vykreslování elementů v předem stanovenou dobu. Grafické prvky se vytvářejí volánístatických funkcí které jako výsledek vracejí stav prvku. U tlačítek je to například zda jestisknuto, u textového vstupu jeho obsah, u posuvníků jejich hodnota atd. . . . Při kresleníse GUI chová jako stavový automat, čili když se změní nastavení hodnoty ve statické tříděGUI , všechny prvky vykreslené od tohoto místa dále, budou s touto hodnotou operovat.

13

API obsahuje velké množství grafických prvků jako jsou tlačítka, vstupní pole, zaškrtávacítlačítka, posuvníky atd. . . . Elementy se na obrazovku umisťují na přesně určenou pozici,nebo pomocí jednoduchých automatických rozložení. Vytvořené GUI lze přestylovat podlesvých požadavků.

4.6 Optimalizace scén

Unity jako herní engine obsahuje velké množství optimalizačních funkci, jako jsou napříkladStatic Batching, Occlusion Culling, Deferred Lighting Rendering Path, LOD, Light Probes.Všechny tyto funkce jsou k dispozici až ve verzi Unity Pro a mají význam až u rozsáhlýchprojektů s velkými scénami, s mnoha objekty a světly, nebo u projektů cílených napříkladna mobilní zařízení.

14

Kapitola 5

Návrh 3D hry labyrint ovládanépohybem rukou

Cílem této práce je vytvořit 3D hru labyrint ovládanou pohybem, náklonem a gesty ru-kou, s využitím zařízení Leap Motion. Tato kapitola popisuje návrh aplikace, její struk-turu a technologie, které jsem využil k realizaci hry. Důležitým tématem návrhu je vlastníknihovna, jejíž cílem je odstranit nedostatky Leap Motion SDK popsané v kapitole 3.6 aintegrovat ji do zvoleného herního enginu. Výsledkem práce bude multiplatformní aplikace,skládající se z menu a samotné hry.

Při vytváření hry jsem musel navrhnout řešení pro tyto části:

• Princip hry a její metriky

• Menu a scény

• Ovládání aplikace pohybem rukou

Ovládání menu

Ovládání náklonu herní desky

• Herní engine

• Fyzika

Detailní návrh řešení těchto aspektů je popsáno v následujících kapitolách.

5.1 Herní princip

Tato hra se inspiruje starou dřevěnou hrou labyrint, ve které je cílem dostat kuličku dosprávného důlku pomocí naklánění labyrintu. V mé modifikaci může uživatel hrát s vícekuličkami najednou, přičemž hra náhodně určuje pořadí v jakém je nutné kuličky do důlkudostat. Labyrinty mohou také obsahovat více míst, ze kterých se kuličky umísťují do scény.Během hraní se uživateli počítá skóre a také měří čas, za jak dlouho je schopen umístitvšechny kuličky do cílového důlku. Jestliže hráč umístí aktivní kuličku do správného důlku,přičte se mu ke skóre pět bodů. Pokud ovšem umístí neaktivní kuličku do libovolnéhodůlku nebo umístí aktivní kuličku do nekoncového důlku, odečtou se mu ze skóre dva body.Umístěním poslední kuličky do správného důlku hra konči a přestává se měřit čas. Výsledky

15

hry se budou podle úrovní ukládat do souboru umístěném ve skrytém adresáři v domovskésložce uživatele.

Hra bude obsahovat více modelů labyrintů a každý z nich lze hrát ve více konfiguracích,kde se mění celkový počet kuliček a počet aktivních kuliček. Zatím si bude možné vy-brat pouze z přednastavených konfigurací. Labyrint se pak bude nacházet v jedné náhodněvybraných scén.

Tuto hru jsem si vybral proto, že je zde potřeba velmi precizní ovládání, které lzerealizovat pomocí ovladače Leap Motion, ale je neuskutečnitelné na klávesnici nebo myši.

5.2 Ovládání hry pohybem rukou

Detekci rukou, jejich sledování budu provádět zařízením Leap Motion. Toto zařízení jsem sivybral proto, že je určeno právě pro snímání rukou, pomocí nichž se bude aplikace ovládata poskytuje velmi přesné informace o jejich poloze a rotaci.

5.2.1 Ovládání menu

Mým cílem je vytvořit aplikaci tak, aby bylo možné ovládat jak menu tak naklánění hracídesky pohybem rukou a gesty. Pro neznalé uživatele jsem ale zachoval ovládání menu pomocímyši.

GUI se ovládá tak, že uživatel dá svou ruku nad zařízení a objeví se mu na obrazovcekurzor. Ten se hýbe podle polohy uživatelovi ruky. Interakci s tlačítky jsem nejprve rea-lizoval gestem sevření ruky v pěst. Toto gesto se později ukázalo jako nevhodné, protožepři sevření ruky uživatel rukou mírně pohne a to při malé velikosti ovládacích prvků způ-sobí kliknutí vedle. Také je toto gesto pro neznalé uživatele neintuitivní. Obdobný problémzpůsobuje také, pokud má uživatel klikat na tlačítka pohybem ruky vpřed. Proto jsem klik-nutí na tlačítko realizoval časovačem. Jestliže uživatel najede kurzorem na prvek, dojde kezměně barvy kurzoru a spuštění časovače. Kurzor poté podle jeho hodnoty mění barvu,aby se indikoval čas do kliknutí. Kliknutí se provede jakmile časovač dosáhne jedné vteřiny.Jestliže kurzor opustí prvek před kliknutím dojde k vynulování časovače.

Obrázek 5.1: Náčrt principu ovládání menu.

5.2.2 Ovládání labyrintu

Ve samotné hře se ovládá pouze labyrint a to tak, že nakláněním dlaně se naklání i labyrint.Ten ovšem nelze naklánět pouze podle normálového vektoru ruky. ale je potřeba od něj

16

odečíst počáteční offset. To z důvodu, že hráč nikdy nedá ruku nad kontrolér tak, abyjejí normálový vektor mířil přesně dolů. Labyrint půjde také ovládat pomocí dvou rukou,které budou v horizontální poloze. To z důvodu, že Leap Motion velmi nepřesně rozpoznáváorientace rukou pokud jsou ve vertikální poloze.

Maximální úhel natočení labyrintu bude omezen na 40◦vůči vodorovné poloze, aby jejhráč nemohl otočit směrem dolů. V menu bude možné nastavit citlivost náklonu hrací desky.

Obrázek 5.2: Náčrt ovládání labyrintu jedou rukou.

5.3 Rozšíření Leap Motion API

Motivací pro vytvoření vlastní knihovny bylo, oddělit řešení problémů z Leap Motion odzbytku hry a vytvořit nad jeho API dokonalejší vrstvu, která se usnadní integraci do Unity.Jedná se o oddělenou sadu zdrojových souborů, které jsou součástí projektu, protože verzeUnity Free podporuje externí knihovny velmi omezeně. Tyto zdrojové soubory je možné vy-užit odděleně i v jiném projektu, případně z nich vytvořit dynamicky linkovanou knihovnu.

Hlavním úkolem knihovny bude integrovat Leap Motion API do Unity tak, aby zpraco-vání snímků probíhalo v době, která je tomu enginem určena. Dále budou součástí knihovnytřídy vytvářející obal nad detekovanými objekty pro jejich jednodušší použití v Unity, skriptdoplňující podporu v ovládání Unity GUI pomocí ovladače Leap Motion, třídu přidávajícídetekci gesta sevření ruky. Jak ukazují obrázky 3.1 a 4.2, Unity reprezentuje vektory v ji-ném souřadném systému než Leap Motion, proto knihovna obsahuje utilitu pro převodsouřadnicového systému Leap Motion API do souřadnicového systému Unity.

5.3.1 Řešení nedostatků z Leap Motion SDK

Část 3.6 popisuje nedostatky Leap Motion SDK, proto jedním z důvod vzniku této knihovnybyla motivace pro jejich částečné eliminování. Většina problémů totiž má velice významnývliv na hru, ve které se klade velký důraz na přesnost ovládání, která závisí hlavně naorientaci ruky a tu má občas senzor problém správně určit. V knihovně je proto definovánoněkolik konstant, které vychází z mnou provedených experimentů, přesto však nejsou tytometody vždy účinné a najdou se případy ve kterých nefungují.

Záměna identifikační čísel

Při zmizení ruky ze scény, nedojde k jejímu úplnému odstranění. Místo toho se spustíčasovač, který po překročení hraníce 0,4s prohlásí ruku za neaktivní, a po 1,0s za neplatnou.

17

Tato technika zajistí, že pokud dojde ke krátkodobém zmizení, tak se ruka zbytku aplikacejeví stále jako aktivní.

Pokud se objeví nová ruka, projdou se všechny neaktivní ruce, a jestliže se najde ruka,která se pozicí, rotací a směrem, velice podobá té neaktivní, pak se původní ID nahradíidentifikačním číslem nově nalezené ruky. Podobnost ruky je definována vzorcem 5.1, kdeI je neaktivní ruka N je nově nalezená ruka. ~p je vektor pozic, ~n je jednotkový normá-lový vektor, ~d je jednotkový směrový vektor. Touto metodou je zajištěno, že při změněidentifikačního čísla při výpadku se pro zbytek knihovny a aplikace nic nemění.

|~pI − ~pN | < 20 ∧ ] ~nI ~nH < 15◦ ∧ ]~pI ~pN < 15◦ (5.1)

Detekce šumu

Zařízení občas prezentuje jako ruce i objekty které se nad ním fyzicky nenacházejí. Jakpopisuje sekce 3.6 tyto objekty mají velice specifické chování. Proto pro odlišení musí hráčumístěnou ruku ponechat v klidu po dobu 0,5s, aby došlo k ověření, že se opravdu jednáo ruku. Klidový stav nastane, platí li výraz 5.2, kde ~p je vektor pozic, ~n je jednotkovýnormálový vektor, ~d je jednotkový směrový vektor, f je počet prstů a i je číslo snímku:

|~pi − ~pi−1| < 2 ∧ ]~ni ~ni−1 < 3◦ ∧ ]~pi ~pi−1 < 3◦ ∧ f >= 2 (5.2)

Eliminace špatného určení orientace

Nepřesná detekce, která nastává při nevhodné orientaci hráčovi ruky, má u této hry velmivýznamný vliv. Pokud dojde k velmi razantní změně v rotaci nebo směru, pak je tatozměna dočasně ignorována, uložena, dále se vynuluje časovač určující, že ruka je stabilní ačeká se na vyhodnocení dalšího snímku. Tato změna se také neprezentuje ven pro zbytekaplikace. Jestliže se při vyhodnocení následujícího snímku zjistí další razantní změna, značíto problém popsaný v kapitole 3.6 a tento postup se opakuje. Pokud se v dalším snímkuruka chová klidně, připočítá se k časovači doba mezi posledním snímkem a aktuálním apoté co suma těchto časů dosáhne 0,2s, pak se zbytku aplikace prezentuje poslední orientaceruky. Tento algoritmus zajistí potlačení velkých a dlouhodobých změn, které pravděpodobněnezpůsobuje hráč.

5.3.2 Gesto sevření ruky v pěst

Knihovna bude také rozšiřovat základní gesta z Leap Motion SDK o gesto sevření rukyv pěst. Toto gesto budu detekovat podle počtu rozpoznaných prstů ruky. Protože LeapMotion nedokáže detekovat prsty správně, pokud je ruka v jiné, než vodorovné poloze,je detekce gesta sevření ruky v pěst tímto podmíněna. V případě hry se jedná o dobrouvlastnost, protože je toto gesto využito k pozastavení hry, které by mělo nastat, když jelabyrint ve vodorovné poloze.

Jestliže počet rozpoznaných prstů klesne na jeden, je k časovači přičtena doba meziposledním a aktuálním snímkem. Když v následujícím snímku dojde k rozpoznání více nežjednoho prstu, je doba časovače snížena o jeden a půl násobku času mezi předchozím aaktuálním snímkem. Jakmile časovač dosáhne času 0,5s je gesto považováno za aktivní.Gesto je označeno z aktivního na neaktivní v případě že hodnota časovače klesne pod 0,2s.

18

5.3.3 Podpora Unity GUI

V Unity GUI je implementováno ovládání pouze pomocí myši, klávesnice a doteků. Jedná seo uzavřený systém, do kterého nelze systémově integrovat ovládání senzorem Leap Motion.Proto jsem se rozhodl vytvořit vlastní třídu implementující ovládání GUI zařízením LeapMotion, která bude mít velmi podobnou strukturu a sémantiku funkcí jako je tomu u prvkůGUI z Unity. Při vytváření GUI se budou volat standardní funkce z Unity, k nim se přidávolání funkcí z mé knihovny, které přidají podporu ovládání o gesta rukou.

5.3.4 Ovládání pomocí dvou rukou

Rozhodl jsem se, že labyrint půjde ovládat pomocí dvou rukou. Cílem knihovny je poskyto-vat stejné údaje jako v případě ovládání jednou rukou. Proto jsem se vymyslel algoritmus,který podle rozdílu polohy v ose Y a dle normálových vektorů dlaní, váženým průměremvypočítá vektor reprezentující rotaci podél osy Z. Průměrem směrových vektorů se vypočítávektor určující rotaci kolem osy X. Vektorovým součinem těchto dvou vektorů reprezentu-jící rotace v osách Z a X, dostaneme jeden normálový vektor, který reprezentuje rotaciobdobně jako kdyby uživatel ovládal labyrint jednou rukou. Schématický postup výpočtuje zobrazen na obrázku 5.3

Obrázek 5.3: Princip výpočtu normálového vektoru při ovládání dvěma rukama.

5.4 Menu, scény a labyrinty

Po zapnutí aplikace se uživateli zobrazí menu ve které budou následující položky:

• Nová hra - Po kliknutí na toto tlačítko se zobrazí uživateli mřížka s tlačítky repre-zentující jednotlivé úrovně a tlačítko zpět. Po kliknutí na jedno z tlačítek s úrovněmise spustí samotná hra s vybraným labyrintem.

• Výsledky - Vybráním sekce výsledky se zobrazí stejná mříž jako u nové hry, ale pozvolení jedné úrovně se zobrazí v seznamu pět nejlepších výsledků obsahující datum,dosažené skóre a čas za jaký byla hra dohrána. Výsledky budou seřazeny primárněpodle skóre a sekundárně podle času.

• Nastavení - V této části si bude moci hráč nastavit citlivost naklánění labyrintu

• Konec - Ukončení aplikace

Spuštěním samotné hry bude zobrazena scéna se stolem, na kterém bude labyrint s kulič-kami odpovídající zvolené konfiguraci. Jakmile hráč umístí jednu nebo obě ruce nad senzor

19

Leap Motion, dojde k spuštěním měřiče času a zvednutí labyrintu ze stolu. Ten se začnenaklánět podle hráčových rukou. Když hráč odejme ruce z dosahu senzoru, čas ve hře sepozastaví a labyrint se položí opět na stůl. Hru lze také pozastavit sevřením ruky v pěst.

Po dokončení hry se uživateli zobrazí seznam nejlepších výsledků z dané úrovně, kterýbude seřazený primárně dle skóre a sekundárně dle času.

Jestliže hráč stiskne během hry klávesu escape, čas ve hře se pozastaví, dojde k položenílabyrintu na stůl, a zobrazí se hráči menu s položkami:

• Pokračovat

• Hrát znovu

• Zpět do menu

• Konec hry

Při opětovném stisknutí klávesy escape, dojde ke schování menu.Hra bude obsahovat jeden ukázkový labyrint, na kterém si může hráč vyzkoušet ovládání

a případně upravit citlivost. Ostatní labyrinty budou vytvořeny tak, že hra bude vyžadovatprecizní ovládání. Cílem bude situovat důlky na místa, kde mohou hráči překážet a budetak zvýšená možnost že se do nich občas trefí. Stěny uprostřed labyrintu budou umístěnytak aby dráha kuličky od počátku do konce nebyla příliš krátká, také nebude možné použítstěny v režimu s více kuličkami k odložení kuliček na bezpečné místo. Pro některé labyrintybude existovat více předem určených startovacích pozic, ze kterých budou náhodně kuličkyzačínat.

5.5 Herní engine

Jako nástroj k vytvoření hry jsem si vybral engine Unity ve verzi Free a to proto, že sejedná o engine poskytovaný zdarma i pro malé komerční projekty, obsahuje široké API askriptování se provádí ve vysokoúrovňových jazycích. Unity integruje v sobě velmi kvalitnífyzikální engine PhysX, má sadu předdefinovaných a dobře optimalizovaných shaderů, umízobrazovat modely z velkého množství modelovacích nástrojů a obsahuje sadu nástrojů,které lze využít při optimalizacích hry.

5.6 Fyzika

Pro simulaci fyziky jsem použil fyzikální engine PhysX, který je dostupný přímo v Unity.I přesto nebyla implementace fyziky jednoduchá. V enginu se jedna jednotka rovná jednomumetru v realitě[16]. Tato vlastnost má velmi významný vliv na simulaci malých objektů,které jsou menších než 10 cm. Jelikož kulička v labyrintu je reálně menší než tato velikost,je nutné celý svět zvětšit tak, aby její velikost byla dostatečná. Proto jsem všechny modelyvytvořil v desetinásobném zvětšení. Také jsem musel upravit gravitační zrychlení, aby seobjekty ve scéně chovaly přirozeně. . . . Jako kolizní model pro celý labyrint, jsem nemohlpoužít původně zamýšlený MeshCollider . Tento kolizní model aplikovaný na tuhé tělesototiž nekoliduje s ostatními tuhými tělesy pokud není bázový model konvexní, nebo z nějnení spočítána konvexní obálka[16]. Proto se tento kolizní model používá pouze na některéčásti labyrintu. Ten se z většiny skládá z vice kolizních primitiv jako jsou například kvádry.

20

Obrázek 5.4: Fyzikální model labyrintu.

Fyzikální engine také slouží k detekci pádu kuličky do důlku. Každý důlek obsahujevirtuální kolizní objekt. Pokud kulička koliduje s tímto objektem, považuje se to za její páddo důlku.

Jako metodu výpočtu kolizí mezi kuličkou a labyrintem jsem využil spojitou detekcikolizí. To z důvodu malé velikosti kuličky vůči stěnám labyrintu. S diskrétní metodou do-cházelo k průletu kuličky stěnou. Tento problém je v známý pod anglickým názvem Bulletthrough paper [8] a se ještě výrazněji projevuje při pohybu dvou objektů proti sobě, což jepřípad naklánění labyrintu proti směru pohybu kuličky. Protože ani spojitá detekce kolizíneeliminovala tento problém úplně, zmenšil jsem velikost simulačního kroku na polovinupůvodní hodnoty a také jsem pro všechny venkovní stěny vytvořil větší kolizní modely abynedocházelo k průchodu kuličky mimo labyrint. Také jsem se snažil navrhovat labyrintytak, aby kulička nemohla dosáhnout potřebné rychlosti k průletu stěnou nebo podlahou.

Na rychlost pohybu kuličky mají vliv fyzikální materiály. Mým cílem bylo vytvořithru co nejpřesněji odpovídají realitě, proto jsem podle materiálu objektu použil fyzikálnímateriál, který určuje statické a dynamické tření. Materiály které jsem využil jsou součástíUnity, pouze jsem u nich mírně upravil konstanty tření, aby se hra chovala reálněji.

21

Kapitola 6

Implementace hry

Tato kapitola popisuje implementaci významných částí samotné hry labyrint v enginu Unity.Jejim cílem není detailně popsat všechny vlastnosti a funkce každého skriptu, spíše struk-turu aplikace a účely jednotlivých skriptů.

Jako programovací jazyk pro skriptování v Unity enginu, jsem si vybral C#. Modely dohry jsem vytvořil v modelovacím nástroji Blender1, základ pro textury jsem získal z webuCGTexures.com2, které jsem upravoval v programu Krita3.

6.1 Struktura

Výsledná aplikace se skládá z enginu Unity, knihoven pro Leap Motion a zdrojů pro aplikaci.Ty jsou rozděleny do složek podle typu na animace, zdroje pro GUI, textury, modely,materiály, scény a skripty. Ty jsou dále děleny na datové modely, skripty pro herní objekty,knihovnu rozšiřující Leap Motion SDK a skripty vytvářející menu. Oddělenou částí jsouzdroje pro labyrinty (modely, textury, materiály). To proto aby je bylo možno dynamickynačítat a uvolňovat v průběhu aplikace.

Obrázek 6.1: Struktura hry

6.1.1 Skripty a GameObjekty

Hlavním skriptem hry je GameController . Jeho cílem je udržovat stav hry (připravena,pozastavena, ukončena nebo zrušena) a zaznamenávat hráčovo skóre s odehraným časem.

1http://www.blender.org/2http://cgtextures.com/3http://krita.org/

22

Výsledky po úspěšném dokončení hry předá instanci třídy GameStatsManager , který jeimplementován návrhovým vzorem jedináček. Jeho úkolem je ukládat a načítat hráčovivýsledky ze souboru a poskytovat je zbytku aplikace.

Pro dynamické menu, scén, labyrintů a pro zobrazení načítací obrazovky slouží skriptLevelsManager . Ten po změně scény, zobrazí načítací obrazovku a po dvou sekundách spustísamotné načítání scény, To z důvodu, že ve verzi Unity Free nelze načítat scény v dalšímvlákně[16]. Pokud se načetla herní scéna tak po dokončení načítání je jeho úkolem načístze složky Assets/Resources požadovaný prefab labyrintu.

Všechny labyrinty je možné hrát ve více verzích, které se liší počtem kuliček. Ty se podlevybrané verze vytváří ve skriptu BallsManager . Ten je nejprve vytvoří, a zařadí do frontyčekajících kuliček, ze které se postupně kuličky umisťují do scény. Pro každou kuličku sevygeneruje náhodná pozice, která vychází z pozice jednoho z množiny vstupních bodů. K tése připočítá náhodný ofset a na základě této pozice je kulička umístěna do scény.

Každá kulička obsahuje skript BallController , který kontroluje zda nevyskočila nebonepropadla labyrintem dolů. Jestliže se tak stane, umístí ji do fronty čekajících kuličekk opětovnému umístění do labyrintu.

Všechny důlky obsahují imaginární kolizní objekt ve tvaru koule, na který je navázánskript HoleController . Dojde-li k průchodu kuličky s tímto objektem, je zavolána událostOnTriggerEnter a v ní dojde k rozhodnutí, zda je důlek cílový nebo ne. Také podle příznakuaktivity se buď kulička vymaže ze scény a je místo ní určena jiná aktivní kulička nebo jeumístěna do fronty čekajících kuliček k umístěni do labyrintu.

Jak popisuje kapitola 4.1 tak ve scéně musí být každý skript součástí nějakého Game-Objektu. Proto jsem zvolil způsob, že každý logický prvek hry bude jeden GameObjekt.Například skripty pro řízení hry, práci s kuličkami jsou jeden GameObjekt. Skripty proLeapMotion jsou součástí dalšího GameObjektu. Skript pro správu úrovní je další Game-Objekt atd. . . . Každý z těchto speciálních GameObjektů má svůj tag, přes který je možnízískávat referenci na daný GameObjekty a z něj skripty které jsou jemu přiřazeny. Všechnyvýznamné tagy jsou k definovány jako statické konstantní řetězce ve speciální třídě Tags.

6.2 Ovládání

Naklánění herní desky podle údajů z knihovny poslané v kapitole 5.3 je realizováno třídouLabController a jejím potomkem GameLabController . Ta získá instanci třídy LeapControllera z ní instanci HandsBundle. Jeho jednotkový normálový vektor podle citlivosti lineárněinterpoluje s jednotkovým vektor orientovaným směrem vzhůru. Výsledný normálový vek-tor použije k výpočtu quaternionu, podle kterého se před každou simulací fyziky labyrintnatočí.

6.3 Menu

Pro vykreslení menu jsem použil GUI elementy, které jsou součástí Unity. Bloky s elementyv aplikaci pozicují tak, aby jejich poloha byla nezávislá na rozlišení obrazovky, elementyv rámci bloků se pozicují pomocí automatických rozložení. Některé prvky jako je napříkladlogo, aplikace vykresluje rozměrově nezávisle na rozlišení okna. Pro jednotnost rozměrů,jsem vytvořil třídu GUIConsts, která obsahuje definice velikosti rozměrů a mezer. Pro in-terakci s prvky menu pomocí kontroléru Leap Motion jsem využil vlastní knihovnu popsanou

23

v kapitole 5.3.3. Vykreslování hlavního menu je implementováno ve třídě MainMenu, jejížhlavní částí je stavový automat reprezentující jednotlivé sekce menu.

Pro menu jsem vytvořil vlastní skin, ve kterém jsem upravil velikost písma, pozadítlačítek, posuvníků a schránek pod bloky elementů.

(a) Menu s výběrem labyrintů. (b) Prezentace výsledků po dohrání hry.

6.4 Modely, textury, materiály, shadery, světla a animace

Do hry jsem vytvořil sadu labyrintů a modelů v modelovacím nástroji Blender. Vytvářeljsem je s důrazem na nízký počet polygonů, s důrazem na použití pouze jednoho materiáluna každý objekt, to z důvodu snížení vykreslovacích volání. Všechny materiály v projektujsem vytvořil přímo v Unity a jsou na objekty aplikovány pomocí standardních shaderůdodávaných s enginem. Použil jsem hlavně shadery Diffuse a Specular a jejich Bumpledvarianty[16]. Typ shaderu jsem volil podle vzdálenosti objektu od kamery, doby vyobrazeníve scéně a požadavku na vizuální dojem. Import objektů z Blendru se děje automatickyv Unity přes exportní formát FBX. Importované modely je nutné otočit kolem osy X o -90◦,protože Blender používá jiný souřadný systém než Unity.

(a) Ukázka scény ze hry. (b) Modelu labyrintu ze hry.

24

Materiály jsou ve většině případů složeny z hlavní textury a normálové mapy. Hlavnítextura bývá často kombinace difuzní textury a textury ambientního osvětlění. Součástívětšiny těchto textur je také odrazová textura která je v Unity umístěna do alfa kanáluhlavní textury. Na většinu modelů je použita technika UV mapování. Všechny texturymají rozlišení 1024x1024, ty které jsou dál od kamery nebo nejsou často ani vidět, jsoupomocí Unity zmenšeny aby se ušetřila paměť a výkon. Stažené textury jsem upravovalv programu Krita. Použil jsem funkce Color-transfer pro obarvení textury jinou texturou,funkce Desaturate a Levels pro převod obrázku do supně šedi. Také jsem upravoval některétextury na bezešvé[15].

(a) Difuzní textura s okolním osvětlením. (b) Odrazová textura.

(c) Kombinace difuzní a odrazové textury. (d) Normálová mapa labyrintu.

Obrázek 6.4: Ukázky textur labyrintu.

Nasvětlení scény je realizováno tmavě modrým ambientním osvětlením, jedním hlavnímisměrovým světlem světle žluté barvy, ze kterého se počítají stíny a sekundárním směrovýmsvětlem tmavě oranžové barvy.

Animace kamery a šipky ukazující koncový důlek, jsem vytvořil přímo v Unity editoru,technikou klíčových snímků. Tyto animace jsou vytvořeny tak, aby se daly použít ve všechscénách a byly nezávislé na objektu se kterým animace pracuje.

25

6.5 Knihovna rozšiřující Leap Motion SDK

Vstupním bodem je třída LeapController . Ta podle událostí v Unity zpracovává snímkyz Leap Motion API. Podle detekovaných rukou vytváří instance třídy LeapHand , která máza cíl provázat ruku se stejným ID přes více snímků a uchovávat předchozí informace o rucesloužící pro odhalení chyb způsobené špatnou detekcí. V této třídě jsou také implemento-vány algoritmy pro popsané v částí 5.3.1.

Jelikož je ve hře podporován režim ovládání dvěma rukama, je součástí knihovny třídaLeapHandsBundle, která dodává jednotné informace pro ovládání labyrintu nezávisle natom, zda se ovládá jednou nebo dvěma rukama.

Součástí knihovny je také třída LeapFistGesture, jejíž úkolem je detekovat podle algo-ritmu v sekci 5.3.2 gesto sevření ruky v pěst.

Pro ovládání Unity GUI je v knihovně třída LeapGUI . Ta zajišťuje vykreslení kurzorupodle polohy ruky a poskytuje velmi podobné funkce pro práci s prvky GUI jako je tomuv Unity.

Obrázek 6.5: Diagram veřejného API knihovny.

26

Kapitola 7

Testování a hodnocení

V rámci testování jsem se snažil zjistit, jak rychle si uživatelé zvyknou na ovládání hrypomocí senzoru Leap Motion. Testování se zúčastnilo 12 lidí. Většina z nich neměla do-sud žádnou zkušenost se zařízením Leap Motion. Proto jsem jim nejprve vysvětil principovládání a prakticky ukázal jak funguje. Také jsem je seznámil s cílem hry, pravidly a metri-kami. Poté jsem je opakovaně nechal zahrát testovací labyrint, který má minimum překážeka je určený pro vyzkoušení ovládání. Výstupem toho testu je tabulka 7.1 průměrných časůjednotlivých pokusů, ve které jsou uživatelé rozděleni do dvou skupin podle předchozíchzkušeností s kontrolérem Leap Motion.

Předchozí zkušenosti Pokus 1 Pokus 2 Pokus 3Začátečník 58s 34s 26sPokročilý 45s 29s 21s

Tabulka 7.1: Průměry časů ukazující rychlost osvojení ovládání jednoduchého labyrintu.

Cílem druhého testu bylo vysledovat učící křivku přesnosti ovládání, během hraní la-byrintu 2-1. Metrikou testu byl čas dohrání a skóre jednotlivých pokusů, průměrné časy askóre uživatelů jsou zapsány v tabulce 7.2

Pokus 1 Pokus 2 Pokus 3 Pokus 4Herní čas 74s 56s 42s 29s

Skóre -8 -3 1 3

Tabulka 7.2: Průměrné časy a skóre ukazující učící křivku při hraní labyrintu 2-1

Při testování jsem vypozoroval následující věci. Skoro všichni uživatelé byli schopni velmipřesně ovládat labyrint už po druhé hře. První hra jim sice trvala v porovnání s ostatnímivelmi dlouho, ale od páté až šesté hry dále už nešlo vidět žádné rapidní zlepšení, protožev těchto hrách začala hrát roli i náhoda. Všichni uživatelé měli problém ovládat hru s většímmnožstvím kuliček. Soustředili se pouze na jednu což mělo za následek záporné skóre podokončení hry. Jako důležitá vlastnost hry se ukázalo nastavení citlivosti. Hráči preferovalimenší citlivost ovládání, proto jsem upravil jeho výchozí hodnotu. U uživatelů kteří do-sud neměli zkušenost se senzorem Leap Motion jsem vypozoroval, že ze začátku pohybujírukama příliš blízko nebo naopak daleko od senzoru, který tak nemohl jejich pohyby dete-

27

kovat. Z testování také vyplynulo, že Leap Motion hůře rozpoznává orientaci levé než pravéruky.

Výslednou hru jsem chtěl umístit do aplikačního obchodu Airspace, ve kterém se sdružujíaplikace speciálně navržené nebo upravené pro ovládání s pomocí kontroléru Leap Motion.Před nahráním aplikace do obchodu je potřebné se zaregistrovat jako vývojář, vytvořit profilpro aplikaci, vyplnit potřebné údaje a poslat vytvořenou aplikaci do schvalovacího procesu.Během něj je aplikace velmi důkladně otestována lidmi z Leap Motion a výsledkem jevelmi podrobný seznam chyb, problémů a doporučení, které se musí opravit. Pro zveřejněnímé aplikace, musím opravit pár drobností v menu, jako například přidat do hry tlačítkok vypnutí aplikace a vytvořit tutoriál. Také mi bylo doporučeno přidat více úrovní do hry,vylepšit ovládání menu a upravit tabulku výsledků.

Část připomínek z testování, jako je například vizuální odezva v menu, tlačítko ve hřek vypnutí aplikace a tutoriál jsem již zapracoval do aplikace, ale pro zveřejnění v aplikač-ním obchodě to není dostatečné. Také bych rád přidal do hry další mód ve kterém by sepo umístění kuličky do koncového důlku náhodně vybral jiný důlek nebo aby pro každoukuličku byl předem určen jiný cílový důlek. Dále bych rád přidal animaci padající kuličky dodůlku, rád bych obohatil hru o zvuky a přidal více netradičních úrovní například s šikmoupodlahou.

28

Kapitola 8

Závěr

Cílem této bakalářské práce bylo navrhnout a implementovat multiplatformní 3D hru laby-rint, která k ovládání využije technologii Leap Motion. Výsledkem práce je aplikace složenáz menu a samotné hry vytvořená v enginu Unity, která pro simulaci fyziky využívá enginePhysX a k sledování rukou Leap Motion SDK. Hra je od jiných ojedinělá svým ovládánímhlavně jeho přesností. Jejím jádrem je vlastní knihovna která integruje Leap Motion SDKdo Unity, přidává podporu v ovládání uživatelského rozhraní, eliminuje chybně detekovanéobjekty, řeší problém chybně přiřazených identifikačních čísel, dále eliminuje nedokonalostiv rozpoznávání orientace a přidává detekci gesta sevřeni ruky.

Aplikaci bych rád upravil, aby ji bylo možné umístit do obchodu AirSpace, obohatil jio zvuky a přidal do ní nové režimy hraní. Vytvořil do ní nové netradiční labyrinty, napříkladse šikmou podlahou nebo interaktivními prvky, které by více ztížili hraní.

29

Literatura

[1] Chen, F.-S., Fu, C.-M. a Huang, C.-L. Hand gesture recognition using a real-timetracking method and hidden Markov models. Image and Vision Computing. 2003,roč. 21, č. 8. S. 745–758.

[2] Clout, L. Spate of injuries blamed on Nintendo Wii [online]. 2008, 2008-01-22 [cit.2. května 2014]. Dostupné z: http://www.telegraph.co.uk/news/uknews/1576244/Spate-of-injuries-blamed-on-Nintendo-Wii.html.

[3] Corporation, M. Skeletal Tracking [online]. [cit. 5. listopadu 2014]. Dostupné z:http://msdn.microsoft.com/en-us/library/hh973074.aspx.

[4] Johnson, S. Daily Reacharound: Kinect Reactions [online]. 2010, 2010-11-04 [cit.2. května 2014]. Dostupné z: http://www.g4tv.com/thefeed/blog/post/708449/daily-reacharound-kinect-reactions/.

[5] Leap Motion, Inc. API documentation [online]. [cit. 20. dubna 2014]. Dostupné z:https://developer.leapmotion.com/documentation/csharp/devguide/Leap_

Overview.html.

[6] Leap Motion, Inc. Leap Motion product [online]. [cit. 2. května 2014]. Dostupné z:https://www.leapmotion.com/product.

[7] Manresa, C., Varona, J., Mas, R. et al. Hand tracking and gesture recognition forhuman-computer interaction. Electronic letters on computer vision and imageanalysis. 2005, roč. 5, č. 3. S. 96–104. ISSN 1577-5097.

[8] Nielsen, S. When Bullets Move Too Fast [online]. 2011, 2011-06-01 [cit. 25. dubna2014]. Dostupné z:http://www.aorensoftware.com/blog/when-bullets-move-too-fast/.

[9] NVIDIA Corporation. NVIDIA PhysX SDK Archives [online]. [cit. 27. dubna2014]. Dostupné z: http://www.nvidia.com/object/physx_archives.html.

[10] Potter, L. E., Araullo, J. a Carter, L. The Leap Motion Controller: A View onSign Language. In Proceedings of the 25th Australian Computer-Human InteractionConference: Augmentation, Application, Innovation, Collaboration. New York, NY,USA: ACM, 2013. S. 175–178. ISBN 978-1-4503-2525-7.

[11] Reich, W. C# Memory Management for Unity Developers [online]. 2013, 2013-11-09[cit. 4. května 2014]. Dostupné z:http://www.gamasutra.com/blogs/WendelinReich/20131109/203841/.

30

[12] Ren, Z., Meng, J., Yuan, J. et al. Robust Hand Gesture Recognition with KinectSensor. In Proceedings of the 19th ACM International Conference on Multimedia.New York, NY, USA: ACM, 2011. S. 759–760. MM ’11. Dostupné z:http://doi.acm.org/10.1145/2072298.2072443. ISBN 978-1-4503-0616-4.

[13] Rios Soria, D. J., Schaeffer, S. E. a Garza Villarreal, S. E. Hand-gesturerecognition using computer-vision techniques. 2013. S. 1–8.

[14] Schlömer, T., Poppinga, B., Henze, N. et al. Gesture Recognition with a WiiController. In Proceedings of the 2Nd International Conference on Tangible andEmbedded Interaction. New York, NY, USA: ACM, 2008. S. 11–14. TEI ’08.Dostupné z: http://doi.acm.org/10.1145/1347390.1347395. ISBN978-1-60558-004-3.

[15] Tvrdý, L. Create textures with Krita [online]. 2013-03-16 [cit. 30. dubna 2014].Dostupné z: http://lukast.mediablog.sk/log/?p=466.

[16] Unity Technologies. Unity documentation [online]. 2007-11-16 [cit. 27. dubna2014]. Dostupné z: http://unity3d.com/learn/documentation.

[17] Weichert, F., Bachmann, D., Rudak, B. et al. Analysis of the accuracy androbustness of the leap motion controller. Sensors (Basel, Switzerland). 2013, roč. 13,č. 5. S. 6380–6393. ISSN 1424-8220.

31

Příloha A

Obsah CD

• src - Projekt pro Unity se zdrojovými soubory aplikace

• bin - Přeložená aplikace pro platformy Windows x86 64 a OSX x86 64

• doc - Technická zpráva ve formátu PDF zdrojové texty pro prostředí LATEX

• video - Prezentační video projektu a videa ukazující problémy zařízení Leap Motion

32

Příloha B

Manual

Tato část přílohy obsahuje informace o překladu aplikace a spuštění

B.0.1 Potřebný software

Aplikace pro překlad vyžaduje Unity verze 4.3.4 a Leap Motion SDK verze 1.0.9.8391. Prosvůj běh pak nainstalované ovladače pro zařízení Leap Motion

B.0.2 Překlad a spuštění

Pro přeložení aplikace je zapotřebí naimportovat složku src do editoru Unity, nakopírovat zLeap Motion SDK knihovny Leap.dll a LeapCSharp.dll do kořenové složky naimportovanéhoprojektu a do podsložky Assets/Plugins knihovnu LeapCSharp.NET3.5.dll

Pro spuštění aplikace mimo editor je potřeba nakopírovat stejné soubory do kořenovéhoadresáře s přeloženou aplikací.

33