Webová aplikace pro orientaci uvnitř budov
Diplomová práce
Studijní program: N2612 Elektrotechnika a informatika Studijní obor: Informační technologie
Autor práce: Bc. Stanislav Tvrzník Vedoucí práce: Ing. Jiří Jeníček, Ph.D.
Prohlášení
Byl(a) jsem seznámen(a) s tím, že na mou diplomovou práci se plně vztahuje zákon č.
121/2000 Sb. o právu autorském, zejména § 60 – školní dílo.
Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé diplomové práce pro vnitřní potřebu TUL.
Užiji-li diplomovou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tomto případě má TUL právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.
Diplomovou práci jsem vypracoval(a) samostatně s použitím uvedené literatury a na základě konzultací s vedoucím diplomové práce a konzultantem.
Současně čestně prohlašuji, že tištěná verze práce se shoduje s elektronickou verzí, vloženou do IS STAG.
Datum:
Podpis:
Poděkování:
Na tomto místě bych rád poděkoval svému školiteli Ing. Jiřímu Jeníčkovi, Ph.D. za vedení mé diplomové práce, odbornou pomoc a cenné rady při zpracování zadaného tématu.
Abstrakt
Práce má za cíl řešit možnosti zobrazení budov a navigaci uživatele v prostorovém modelu budov s využitím technologie WebGL. Jsou zde popsány některé techniky pro jejich návrh a následné možnosti zobrazení se zaměřením na vybrané části připraveného modelu.
Dále jsou v této práci popsány možnosti propojení dat 3D modelu se systémem IS/STAG a vyhledávání cest ze získaných dat. Pro toto vyhledávání byl použit A* algoritmus.
Klíčová slova
3D modely, WebGL, navigace, Unity3D, A* algoritmus
Abstract
The aim of this work is to discuss options for displaying buildings and navigating the user in a 3D model using WebGL technology. It describes some techniques for designing these models and subsequent display options with focus on selected parts of the model. It also describes the possibilities of linking 3D model data from the IS/STAG system and searching the paths from the acquired data. A* algorthm was used for searching between received two points.
Keywords
3D models, WebGL, navigation, Unity3D, A* algorithm
Obsah
1. Úvod ... 12
2. Existující řešení ... 13
2.1.Městské interaktivní navigační tabule ... 13
2.2.Zakázkové systémy ... 14
2.3.Systém pro navigaci ve virtuální realitě s využitím herního enginu ... 14
2.4.Předchozí práce pro navigaci v budovách TUL ... 14
3. Použité prostředky pro řešení ... 15
3.1.Herní engine Unity3D ... 15
3.1.1.Struktura projektu v Unity Editoru ... 15
3.1.2.Inspektor komponent ... 16
3.1.3.Scéna ... 16
3.2.Uživatelské rozhraní (UI) ... 17
3.3.Blender ... 17
3.4.JSON ... 17
4. Příprava modelů budov TUL ... 19
4.1.Konverze modelů z 3DS MAX a Maya ... 19
4.2.Vytvoření nového modelu budovy G ... 19
4.3.Vytvoření zjednodušeného modelu areálu Husova ... 20
5. Vypracované řešení ... 21
5.1.Nastavení a možnosti projektu ... 21
5.1.1.Formát pro uložení a načtení rozpracovaného projektu ... 22
5.2.Správa jednotlivých budov v projektu ... 22
5.2.1.Nároky na 3D model budovy pro správné zobrazení ... 23
5.2.2.Technika renderování řezu geometrií budovy ... 23
5.3.Stavba a úpravy grafu navigační sítě ... 25
5.4.Příprava projektu pro spuštění ve webové aplikaci ... 26
5.5.Zobrazování upozornění a chybových zpráv ... 26
5.6.Lokalizace ... 26
5.7.Propojení se systémem STAG ... 28
6.4.Algoritmus nejkratší cesty v připraveném grafu ... 35
6.5.Zobrazení cesty v budově ... 36
7. Testování editoru a WebGL aplikace ... 37
7.1.Testy rozlišení editoru ... 37
7.2.Testy WebGL aplikace v prohlížečích ... 37
7.3.Testy na mobilních zařízeních ... 38
8. Závěr ... 40
Seznam použité literatury ... 41
Seznam ilustrací
Ilustrace 2.1: Příklad zjednodušeného provedení tabule s volbou hlášek [1]...12
Ilustrace 2.2: Ukázka aplikace Guide3D...13
Ilustrace 3.1: Nástroje pro ovládání objektů v otevřené scéně...16
Ilustrace 4.1: Příklad zjednodušené geometrie prvního patra budovy G...19
Ilustrace 5.1: Návrh rozělení úlohy do dvou samostatných aplikací...20
Ilustrace 5.2: Sestavení efektu řezu 3D modelu – objekt, stencil buffer a výsledek...23
Ilustrace 5.3: Textura šrafování...23
Ilustrace 5.4: Závislost tříd pro lokalizaci uživatelského prostředí...27
Ilustrace 5.5: Vytvořený atlas s podporou českých znaků pro uživatelské rozhraní...27
Ilustrace 5.6: Schéma komunikace mezi WebGL a IS/STAG...29
Ilustrace 5.7: Závislosti modulu pro komunikaci s IS/STAG...30
Ilustrace 6.1: Rozložení uživatelského rozhraní WebGL aplikace...33
Ilustrace 6.2: Příklad procházení čtvercového grafu A* algoritmem s překážkou [13]...34
Ilustrace 6.3: Postup vyhlazování cesty Chainkinsonovým algoritmem...35
Seznam tabulek
Tabulka 1: Využívané REST zdroje ze systému IS/STAG...28
Tabulka 2: Testy rozlišení aplikace editoru budov...36
Tabulka 3: Výsledky testů WebGL aplikace ve vybraných prohlížečích...37
Tabulka 4: Test kompatibility mobilních zařízení s Unity WebGL aplikací...38
Významy použitých zkratek a pojmů
UI User interface, rozhraní pro uživatele k ovládání aplikace nebo zobrazení informací
GUI Graphics user interface, uživatelské rozhraní využívající grafické prvky společně s textem
XML Extensible Markup Language
JSON JavaScript Object Notation, formát pro uložení strukturovaných dat FPS Frames per second, představuje rychlost vykreslování obrazu
WebGL Web Graphics Library, knihovna pro zobrazení OpenGL ES grafiky na webu
Wasm WebAssembly, binární formát pro aplikace určené pro webové prohlížeče API Application Programming Interface, popisuje možnosti komunikace mezi
aplikací a modelem, kterému rozhraní náleží
APK Android Package Kit, datový formát pro android aplikace
asset Jakýkoliv typ souboru využitý v projektu. Například textura nebo JSON vertex Pozice v trojrozměrném prostoru
mesh Trojrozměrná síť vertexů a ploch mezi těmito vertexy tvořící povrch objektu
PBR Physicaly based rendering, způsob renderování modelu se simulací fyzikálních veličin použitého materiálu
IS/STAG Informační systém studijní agendy REST Representational state transfer
POI Point of Interest, určuje bod s přidanou informační hodnotou FBX Filmbox, souborový formát pro uložení 3D modelu
1. Úvod
Cílem diplomové práce je návrh a realizace interaktivní aplikace v budovách Tech- nické Univerzity v Liberci využívající technologii WebGL ve webových prohlížečích.
Výsledná aplikace by mohla pomoci novým studentům s orientací v prostorách školy v zá- vislosti na osobním rozvrhu. Volně dostupných aplikací pro vytvoření interaktivní navigace uvnitř budov není mnoho a jejich uplatnění ve webových prohlížečích se využije jen zřídka.
Tato práce prozkoumává možnosti REST architektury při získávání dat ze systému IS/STAG Technické univerzity v Liberci. Z tohoto systému využívá část veřejně dostupných dat pro spárování s daty v připraveném projektu.
Aplikace je strukturovaná tak, aby bylo možné v případě poskytnutí zdrojových dat jiných budov vytvořit model pro navigaci v jakémkoliv areálu. V takovém případě by bylo nutné vyměnit použitý modul pro komunikaci se školním systémem IS/STAG za jinou da- tabázi využívající připravený interface.
Současně tato práce slouží k ověření aktuálních možností WebGL podpory v herním enginu Unity. Tato technologie byla zpřístupněna několik verzí před verzí používanou pro vytvoření aplikace (Verze Unity použitá pro tuto práci je 5.6.3p1). WebGL je relativně nová technologie nahrazující Flash a další interaktivní formáty bez nutnosti používat do- plňky. Další výhodou této technologie je její multiplatformní podpora.
2. Existující řešení
Při navrhování webové aplikace byly brány v úvahu interaktivní aplikace provo- zované ve světě. Možnosti interakce jednotlivých řešení se značně liší podle navrženého umístění a použitých technologií.
2.1. Městské interaktivní navigační tabule
Jednoduchý systém pro navigaci a prezentování stručných informací o okolí jsou zvukové navigační tabule ve městech. Tyto tabule jsou obvykle vybavené hlasovým zá- znamníkem, číselnou klávesnicí a světelnou signalizací umístěnou v mapě. Každý bod na mapě zvýrazněný světelnou signalizací má přidělené číslo. Po zadání tohoto čísla na klávesnici se bod rozsvítí a tabule přehraje uložený zvukový záznam popisující vybrané místo. Počet záznamů je omezen na maximálně několik stovek připravených nahrávek.
Tyto informační tabule se nejčastěji využívají pro vyznačení zajímavých míst pro turisty nebo pro komentář k vystaveným objektům ve vitrínách. [1]
Ilustrace 2.1: Příklad zjednodušeného provedení tabule s volbou hlášek [1]
2.2. Zakázkové systémy
Při vyhledávání existujících řešení bylo nalezeno i několik pre- zentací komerčních projektů nejčastěji jako video ukazující ně- které funkce na konkrétním řešení.
Tyto projekty nabízejí uživatelsky přehledné a podrobné informace a často jsou s nimi spojeny i vlastní hardwarová řešení například
v podobě dotykových panelů nebo promítaných vizualizací zobrazující nové informace v reálném čase. Veřejně dostupné informace o těchto řešeních jsou většinou omezené na krátký výčet nejzajímavějších funkcí nebo jen video-prezentací ukazujících tyto funkce na připraveném projektu. Příklad takovéhoto systému je například video-prezentace s ukázkou navigace systému Guide3D v areálu Alice-Hospital Darmstadt v Německu. [2]
2.3. Systém pro navigaci ve virtuální realitě s využitím herního enginu
Využití herního enginu pro vizualizaci existujících prostor a interakci je často vo- leným nástrojem. Při takto zvoleném řešení je herní engine používaný jako modul, na kterém je postavena aplikační logika. Herní engin je vytvořený tak, aby byl nezávislý na aplikaci, která ho využívá. Výhodou tohoto řešení je odstínění práce s nízkoúrovňovým grafickým API nebo závislost na provozovaném sytému. Herní enginy často poskytují jak možnosti pro zobrazení trojrozměrného prostředí, tak i možnosti pro interakci s tímto prostředím. Může to být například simulace fyziky pro kolizi kamery nebo sjednocené zpracování různých vstupních periferií jako je myš nebo dotyková obrazovka. [4]
2.4. Předchozí práce pro navigaci v budovách TUL
Práce s podobným zaměřením byla už na Technické univerzitě v Liberci řešena. Je- jím cílem bylo prozkoumat možnosti vyhledávání cest v trojrozměrném modelu a metody vykreslování a optimalizace 3D modelů v počítačové grafice [3]. Na této práci z větší části staví tato diplomová práce.
Ilustrace 2.2: Ukázka aplikace Guide3D
3. Použité prostředky pro řešení
3.1. Herní engine Unity3D
Unity je herní engine poskytující kompletní řešení pro tvorbu aplikací pro stolní po- čítače, mobilní zařízení, web a další platformy. Engine mimo práce s 2D a 3D grafikou nabízí i simulaci 2D a 3D fyziky, import a přehrávání mnoha zvukových formátů a systém pro animace objektů. První verze Unity byla vydána v roce 2005 ve verzi 1.0. Pro tvorbu aplikace editoru byla využita verze 5.6, která podporuje export projektu pro Windows i WebGL. [6]
3.1.1. Struktura projektu v Unity Editoru
Každý projekt v Unity se skládá z jedné nebo více scén a úložiště dat. V editoru je otevřená scéna reprezentována prvky uspořádanými v stromové hierarchii. Každý prvek ve scéně je reprezentován jako 3D objekt, který má danou pozici, rotaci a velikost ve virtu- álním světě. Vlastnosti tohoto objektu určují komponenty, které jsou k objektu připojeny.
V úložišti dat jsou umístěny všechny skripty, grafika, zvuky a také přednastavené objekty scény nazývané prefaby, na které se mohou objekty ve scéně odkazovat.
Prefab je objekt se stejnou strukturou, jako objekty ve scéně. Není ale umístěn nikde v 3D prostoru. Jeho účelem je vytvoření prototypu, který může být ve scéně opakovaně po- užit pro jeden nebo více objektů se stejnými vlastnostmi. Objekty ve scéně vytvořené z prefabu se nazývají instance. V případě změny některé z vlastností v prefabu se tyto změ- ny promítnou i do všech vytvořených instancí objektu za předpokladu, že změněná vlastnost nebyla v instanci přepsána novou hodnotou.
Komponenty připojené k objektům jsou skripty obsahující programovou třídu zdě- děnou z rodičovské třídy MohoBehaviour. Každá třída, která je potomkem této bázové třídy může být umístěna na jakýkoliv objekt ve scéně. Veřejně deklarované jednoduché da- tové typy nebo soukromé datové typy s nastavenou vlastností serializace jsou přístupné v editoru pro nastavení jejich aktuálních hodnot. Skripty dědí z rodičovské třídy přes 20 metod volaných během životního cyklu objektu. Nejčastěji využívanými metodami jsou
dokončení procesu vytváření instancí všech nových objektů a její využití je vytvoření vazeb mezi více objekty. Na těchto metodách je závislá komunikace mezi jednotlivými komponentami výsledné aplikace.
Komponenty v Unity mohou být napsány v jednom ze dvou podporovaných programovacích jazyků. Těmito jazyky jsou C# a JavaScript. Zmíněný JavaScript je jazyk vytvořený pro Unity programování a nemá žádnou souvislost s JavaScriptem pro webové stránky. Oba jazyky podporují možnosti platformy .NET ve verzi 2.0. Tato starší verze je z důvodu využívání knihoven Mono, které byly jedinou možností multiplatformního vý- voje.
3.1.2. Inspektor komponent
Inspektor je jedno z oken v prostředí Unity editoru umožňující nastavení vystavených vlastností komponent vybraného objektu nebo pre- fabu. Zpřístupňuje také nastavení pro importované zdroje jako jsou obrázky, 3D modely a zvuky.
Pokud není možné z nějakého důvodu zob- razit nastavení komponenty v editoru zveřejněním vlastností, podporuje inspektor možnost napro- gramování vlastního editoru. Tento editor je podobně jako komponenta tvořen skriptem s třídou tentokrát zděděnou z rodičovské třídy Editor. Ten umožňuje využít všechny dostupné grafické prvky Immediate Mode GUI a naprogramovat k nim funkce chybějící v základním inspektoru. Více o Immediate Mode GUI v sekci Uživatelské roz- hraní (UI).
3.1.3. Scéna
Okno scény zprostředkovává pohled na tvořený 3D prostor právě otevřené scény.
Pro manipulaci se scénou jsou připraveny 4 operace: posun, změna velikosti, rotace a po- hyb kamery. V jednu chvíli může být používána jen jedna z těchto operací. Mezi nimi lze
přepínat buď klávesovými zkratkami Q, W, E, R náležející jednotlivým operacím ve stejném pořadí nebo nástrojovou lištou nad oknem scény.
3.2. Uživatelské rozhraní (UI)
Do verze Unity 4.6 bylo jedinou integrovanou možností zobrazování ovládacích prvků v aplikaci využívání Immediate Mode GUI (Zkráceně IMGUI). Toto uživatelské roz- hraní bylo postaveno na principu vytváření dočasné geometrie s přednastaveným grafickým stylem. Všechny prvky bylo možné vytvářet pouze z programového kódu bez možnosti vidět vytvářené prvky před spuštěním programu. Unity tento typ ovládání nadále využívá v nejnovějších verzích editoru pro okna a menu a editoru samotného. Tím je možné rozšířit funkce editoru přímo ze zdrojového kódu aplikace. Obvykle se toho využí- vá pro vytvoření nástrojů při práci na větších projektech, které se kompletují v prostředí unity. IMGUI je stále možné využívat i v nových verzích. V editoru je využíván pro spuštění testů pro jednotlivé moduly v prostředí editoru.
Nové API představené ve verzi 4.6 pojmenované Unity UI (občas se lze setkat i s označením New UI) je navržené tak, aby bylo možné všechny prvky vytvořit z prostředí Unity editoru a také rozšířilo grafické možnosti o nastavení barev a textur.
3.3. Blender
Blender je volně dostupný nástroj pro 2D a 3D modelování s otevřeným zdrojovým kódem. Cílem tohoto nástroje je poskytnout sadu nástrojů pro zhotovení 3D prostředí od návrhu až po animace a export. Na jeho vývoji se podílí početná komunita z celého světa, která má možnost přispívat novými funkcemi. Projekty vytvořené v tomto nástroji se vy- rovnají kvalitou profesionálním programům. [7]
3.4. JSON
Ilustrace 3.1: Nástroje pro ovládání objektů v otevřené scéně
Data jsou v JSON souboru uložena v párech oddělených dvojtečkou. První hodnota je název parametru a za dvojtečkou následuje jeho hodnota. Textové řetězce a názvy atributů jsou umístěny v uvozovkách. Tato hodnota může nabývat jeden z podporovaných typů. Tyto typy jsou následující [10]:
• Textový řetězec
• Číslo
• Vnořený JSON objekt
• Pole
• Binární hodnota true/false
• Hodnota null
Formát JSON je často voleným řešením pro přenos dat ve webových aplikacích zej- ména díky malému množství nadbytečných dat a možnosti snadného čtení a editace člověkem. Příklad zkrácené JSON struktury získávané dotazem na IS/STAG (více v kapi- tole 5.7 Propojení se systémem STAG):
[ {
"mistnostInfo": [ {
"zkrBudovy": "A",
"cisloMistnosti": "TK6", "katedra": "MTI",
"typ": "Počítačová učebna", "kapacita": 25,
"poznamka": "BUDOVA a – PŘÍZEMÍ", "vyskaMistnosti": null,
"dvereCislo": "78", "podlazi": "1",
"urlBudova": "http://www.mapy.cz/#!
x=15.078001&y=50.772847&z=15&t=s&q=Liberec%252C%2520H
%25C3%25A1lkova
%25206&qp=15.058168_50.767607_15.103181_50.782360_14", "identifikatorMistnost": "A01078"
} ] }]
4. Příprava modelů budov TUL
Pro realizaci aplikace byly zpřístupněny existující modely budov z dříve vypra- covaných projektů. Tyto modely byly přizpůsobeny pro použití ve webovém prostředí.
4.1. Konverze modelů z 3DS MAX a Maya
Při zpracování modelů pro webové prostředí bylo prvním krokem jejich převedení z původních formátů do nového více přístupného formátu OBJ. Důvodem pro převod byla malá podpora původních formátů v jiných aplikacích pro modelování, než ve které byly vytvořeny. Formát OBJ byl zvolen ze dvou důvodů. Prvním důvodem byla jeho podpora v použitém modelovacím programu Blender. Druhým důvodem byla jeho snadná čitelnost spolu s dokumentací popisujícím tento formát. Díky tomu je možné tento formát zpracovat ve vytvořené aplikaci bez využití knihoven pro práci s 3D modely.
Převedení původních formátů byl proveden ve dvou krocích. Prvním bylo z pů- vodních souborů aplikací Maya a 3D Studio Max vytvořit fbx soubory. Tento typ souborů je možné otevřít importováním do Blenderu, ze kterého se následně exportoval OBJ soubor v trojúhelníkovém formátu. Aplikace Maya i 3D Studio Max nabízejí export přímo do OBJ nativně, ale exportované soubory při importu do Blenderu obsahovaly chybné indexování ploch.
4.2. Vytvoření nového modelu budovy G
Mezi modely dostupnými z předchozích projektů nebyl vytvořen model pro novou budovu G, která byla postavena a otevřena až po dokončení předchozích prací. Tato bu- dova byla vymodelována z dostupných pasportů, aby mohl být vytvořen celý areál Husova v okolí informační centra. Modelování budovy bylo rozděleno na několik částí. Budova byla modelována po jednotlivých patrech a pro každé patro byly použity tyto kroky:
• Vymodelování obvodových stěn
• Vytvoření podlahové roviny a k ní otočené stropní části umístěné níže
• Modely vnitřních stěn v samostatném objektu
4.3. Vytvoření zjednodušeného modelu areálu Husova
Z vypracovaných modelů budov byl sestaven model celého areálu – modely jednot- livých budov byly zjednodušeny tak, že obsahovaly pouze obvodové zdi. Průhledy okny a dveřmi byly vyplněny plochami bránícími náhledu do nitra budovy. Pro vyplnění areálu byly přidány siluety okolních budov tak, aby uživateli zjednodušily orientaci.
Jako výchozí model areálu byl využit model informačního centra vytvořeného dříve pro jiný projekt. Tento model obsahuje data o výšce okolní krajiny a část okolních budov.
Ilustrace 4.1: Příklad zjednodušené geometrie prvního patra budovy G
5. Vypracované řešení
Výsledné řešení bylo rozděleno na dvě samostatné aplikace podle způsobu použití.
První aplikací je editor projektu spustitelný jako samostatná aplikace pro systém Windows.
Editor projektu je stolní aplikace vytvořená za účelem přípravy dat pro WebGL aplikaci.
Uživateli připravující prostředí pro navigaci v budově umožňuje prohlížet geometrii bu- dovy způsobem, jakým bude budova prezentována ve webové aplikaci. Bez modelu budovy nemá webová aplikace žádný výchozí bod pro spuštění. Poskytuje také nástroje pro vytváření a úpravu navigačních bodů v podobě trojrozměrného grafu.
Druhou částí je WebGL aplikace určená pro prezentování připravených dat expor- tovaného projektu z editoru ve webových prohlížečích. Úkolem této aplikace je uživatelsky přehledné zobrazení modelu areálu a poskytnutí funkcí pro vyhledávání tras a poloh v při- pravené navigační síti.
5.1. Nastavení a možnosti projektu
Každý projekt je specifikován názvem a stručným popisem. Tyto dvě vlastnosti projektu slouží hlavně k jeho identifikaci při práci s více projekty současně a také pro informování návštěvníka webové aplikace s tímto projektem. Každý projekt musí mít nej- méně jednu budovu pro export do webové aplikace. Vlastnosti jednotlivých budov jsou popsány v podkapitole Správa jednotlivých budov v projektu.
Ilustrace 5.1: Návrh rozělení úlohy do dvou samostatných aplikací
5.1.1. Formát pro uložení a načtení rozpracovaného projektu
Všechna data projektu ukládaná mimo prostředí editoru jsou ukládána ve formátu XML. XML byl zvolen hlavně pro snadnou čitelnost v textové podobě a tím i možnost úprav obsahu mimo editor. Tento formát se využívá jak k ukládání dat rozpracovaného projektu, tak k exportu dat pro WebGL, kde je tento formát snadno zpracovatelný.
Při exportu dat projektu z editoru se objevily potíže s podporovaným kódováním souboru. XML Serializer bez specifikovaného kódování využíval nastavení běžícího systé- mu. V případě testovacího prostředí to bylo kódování Windows-1250. Zde nastal první problém, protože webová aplikace je načítána ve webové stránce s nastaveným kódováním UTF-8. Po načtení aplikace a stažení inicializačního souboru s popisem projektu a sezna- mem budov se tento rozpor v nastaveném kódování projevil tím, že texty obsahovaly místo české diakritiky pouze prázdné mezery.
Při nastavení kódování na UTF-8 bylo v deklaraci XML dokumentu uvedeno správné kódování UTF-8, ale soubor samotný měl nastavení kódování UTF-8 BOM (Byte order mark). Toto kódování vzniklo z důvodu ukládání dat Mesh objektu budovy v by- tovém poli. Problémem s tímto kódování byly chyby generované WebGL aplikací při pokusu o načtení souboru s touto znakovou sadou. WebGL verze aplikace vytvořená v Unity tuto znakovou sadu nepodporuje. Projekt tedy nebylo možné načíst a po spuštění se zobrazila jen úvodní statická obrazovka s dočasnými texty.
Řešením obou problémů bylo využití třídy XMLTextWritter místo obecnější StreamWritter třídy a současně nastavení kódování vytvořením nového objektu Sys- tem.Text.UTF8Encoding s nastavením hodnoty konstruktoru na hodnotu false. Tím je výstupní formát nastaven tak, aby nevkládal značky pořadí bajtů.
5.2. Správa jednotlivých budov v projektu
Každá budova má podobně jako projekt vlastní název a popisek. Název je použit pro spárování dat ze sytému IS/STAG. Navíc je možné přidat k popisu budovy i odkaz na webovou stránku a informaci o počtu podlaží. Webový odkaz je na webu zobrazen jen pokud je vyplněn a umožňuje zobrazit další informace o budově i mimo WebGL aplikaci.
Při nastavování parametrů budovy je mimo zmíněných vlastností možné vybrat připravený 3D model budovy uložený v souboru typu Wavefront (obvykle s příponou .obj).
Při výběru 3D modelu se z vybraného souboru provede import geometrie, která se převede na objekt unity typu Mesh. Tento objekt je uložený v konfiguraci každé budovy a používá se v editoru i následně ve WebGL aplikaci.
5.2.1. Nároky na 3D model budovy pro správné zobrazení
Aby se 3D model v editoru mohl zobrazit správně a bylo možné zobrazovat dyna- micky řez budovou, musí být model budovy nejdříve upravený tak, aby splňoval následující tři vlastnosti:
• Jedna jednotka délky odpovídá jednomu metru.
• Budova musí být tvořena jedním souvislým objektem.
• Geometrie musí mít na základně pod obrysy budovy umístěnou plochu s normálo- vým vektorem směrem dolů.
V budově je také doporučené umístit takovéto plochy do míst, které nejsou průchozí mezi patry. Splnění těchto vlastností zajistí, že šrafování při řezu geometrií nebude pře- krývat viditelné sekce skrz geometrii a zároveň bude budova plynule navazovat na grafickou mřížku editoru.
5.2.2. Technika renderování řezu geometrií budovy
Všechny budovy a areál využívají při vykreslování materiál bez textur s upraveným programem pro grafické shadery. Tento program zajišťuje několik funkcí, které dohroma- dy vykreslují geometrii budov s efektem šrafovaného řezu. Základem shaderu je asset z balíčku Cross Section Shaderů využívající jednu rovinu pro maskování geometrie. Funk- ce shaderu jsou následující:
• Pro renderovaný objekt se nastaví maska stencil bufferu.
• Provede se porovnání, zda se vykreslovaný bod nachází pod ořezovou rovinou, pokud ne, vykreslování pro tento bod se ukončí.
• Pokud má být bod vykreslen, použije se standardní unity PBR shader
• Shader přepne vykreslování pouze na backface plochy.
Stencil buffer je jeden z výstupních grafických bufferů z shaderu. Jeho velikost je rozlišení okna programu v pixelech a může uchovávat dodatečné informace o vyrende- rovaném objektu. Pro ukládání informací používá bytové hodnoty a může tedy uchovávat informaci v rozsahu 0 až 255.
Stencil maska je několik parametrů, které se využijí při každém průchodu shaderem.
Tyto hodnoty jsou bytová hodnota pro zápis do stencil bufferu, pokud má být fragment do bufferu zapsán a dále jsou to binární operace závislé na tom, zda je aktuální fragment sou- částí frontface nebo backface.
Backface rendering probíhá porovnáváním normálového vektoru plochy se smě- rovým vektorem aktivní kamery. Pokud normálový vektor směřuje ke kameře, je ploška renderovaná jako frontface. Pokud směřuje normálový vektor od kamery, je renderovaná jako backface.
Této vlastnosti se často využívá při takzvaném backface culling ke zmenšení množ- ství geometrie, kterou musí kamera vykreslit při každém novém snímku. Předpokladem pro tuto metodu je, že paprsek vypuštěný z kamery musí nejdříve vstoupit do objektu, aby mohl narazit na jeho zadní stěnu. U objektů které nejsou průhledné tento stav tedy obvykle nemůže nastat a vynechaná geometrie sníží celkovou náročnost rende- rované scény.
Efekt šrafování je renderován v pořadí až po dokončení rende- rování všech objektů využívajících materiál se zápisem do stencil bufferu. Výsledný stencil buffer je použit jako maska. Šrafování je vy- Ilustrace 5.2: Sestavení efektu řezu 3D modelu – objekt, stencil buffer a výsledek
Ilustrace 5.3:
zvětšených na velikost maskovaného objektu. Tento čtverec je umístěn do stejné výšky, jako je výška řezu. Na tuto jednoduchou geometrii je aplikována textura šrafování s nasta- venou průhledností mezi jednotlivými šrafy. Při renderování se využívá dříve vytvořený stencil buffer jako maska pro zobrazení šrafování. Textura se pro umělé zvýšení detailu na přeložené rovině opakuje v obou mapovaných osách.
5.3. Stavba a úpravy grafu navigační sítě
Navigační síť se v editoru skládá ze samostatných bodů umístěných v 3D prostoru.
Pro usnadnění práce s objekty v 3D prostoru, je pro vytváření a úpravu navigační sítě vy- tvořeno několik nástrojů jak k její vizualizaci tak editaci. Navigační síť se upravuje při zapnutém režimu navigační síť v pravém menu editoru. Nástroje pro správu sítě umožňují tyto funkce:
• Vytváření nových bodů
• Změnu pozice existujících bodů
• Odstranění existujících bodů
• Spojení dvou bodů cestou s jedním z podporovaných typů
• Rozpojení bodů
Při vytváření nových bodů se rozlišuje, zda jde o navigační bod pro průchod po síti nebo bod typu POI. Pokud je vytvářený bod typu POI, zpřístupní se dodatečné nastavení.
Toto nastavení umožňuje pojmenovat bod, nastavit zda je vstupem do budovy, přidat popi- sek a vybrat jednu z místností načtenou z IS/STAG pro právě upravovanou budovu.
Pro umístění a posun bodů je využit fyzikální model v Unity engine. Pro zjištění po- zice v 3D prostoru pro umístění bodu je při stisknutém levém tlačítku myši v každém snímku zjištěna kolize paprsku promítnutého do 3D. Směr tohoto paprsku je vypočítán z pozice kurzoru myši v okně aplikace a pozice kamery. Paprsek prochází geometrií bu- dovy a pro každou kolizi, která nastane se porovnávají dvě vlastnosti. Pozice kolize musí být níž než je rovina řezu budovou a normálový vektor plochy, se kterou kolize nastala, musí směřovat vzhůru. Pro umístění bodu je tím zaručeno, že bude umístěn nad podlahu v patře, které je v editoru zobrazeno.
5.4. Příprava projektu pro spuštění ve webové aplikaci
Struktura dat projektu je velice podobná uložení projektu v editoru. Pro uložení se využívá serializace tříd do XML. Pro vytvoření konfiguračního souboru s projektem je v editoru vybrána cesta k uložení projektu. Cílem musí být existující složka. Po výběru cesty k souboru se zkopírují data z datové třídy projektu ProjectData do upravené třídy pro webový projekt WebData. Problém při serializaci je geometrie budov a areálu, protože tří- da UnityEngine.Mesh není serializovatelná. Pro přenos dat meshe se před samotnou serializací mesh převede do bytového pole, ze kterého bude po načtení ve webové aplikaci obnoven do původní podoby. Ve vybrané složce jsou vytvořeny soubory webinit.xml a je- den XML soubor pro každou budovu v projektu.
Příklad jak vypadá konfigurační soubor projektu:
<?xml version="1.0" encoding="utf-8"?>
<WebProject xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Buildings>
<WebBuildingProperties>
<Name>Budova A</Name>
<Description>Testovací objekt</Description>
<BuildingXMLFile>building0.xml</BuildingXMLFile>
<ExternalMapLink />
</WebBuildingProperties>
</Buildings>
<ProjectName>Ukázkový projekt</ProjectName>
<ProjectDescription>Popis projektu</ProjectDescription>
</WebProject>
Všechny vytvořené soubory z exportu jsou umístěny do složky StreamingAssets u WebGL aplikace a tím je exportovaný projekt připravený ke spuštění.
5.5. Zobrazování upozornění a chybových zpráv
Chybové zprávy jsou generovány uvnitř jednotlivých modulů. Pro jejich efektivní zpracování a zobrazení uživateli je vytvořena komponenta přijímající chybové zprávy přes rozhraní IErrorMessage. Moduly implementující toto rozhraní jsou zaregistrovány při spuštění aplikace a pokud přes toto rozhraní zašlou chybovou zprávu, zobrazí se uživateli samostatné okno s touto zprávou.
5.6. Lokalizace
Pro lokalizaci aplikace do připravených jazykových verzí byl vytvořený samostatný
jazyce. K pojmenování jazykové verze se využívá formát jazykových kulturních jmen.
Tento formát byl zvolen z důvodu častého využití pro webové stránky, které jsou cílenou platformou pro tuto aplikaci. Zároveň tento formát umožňuje zadat jazykovou verzi dat při dotazu do systému IS/STAG. Lokalizace je zapsána malými znaky. Názvy těchto souborů jsou odvozeny od pojmenování lokalizace v konfiguračním souboru s příponou json. Podle tohoto vzoru je tedy pro českou verzi aplikace název lokalizace cs-cz a přeložené texty jsou uloženy v souboru cs-cz.json.
Jednotlivé jazykové verze jsou uložené v samostatných souborech. Datový formát JSON je použit pro snadnou editaci stávajících nebo nových jazykových verzí po sestavení aplikace. Struktura konfiguračního souboru uchovávající vytvořené jazykové verze je jednoduché pole:
{"localizations":["cs-cz","en-en"]}
Datový soubor s daty pro překlad obsahuje název lokalizace, který je zobrazen v aplikaci při výběru jazyka a texty překladu pro vytvořené klíče. Tyto klíče jsou použity pro přiřazení přeložených textů ke správným komponentám. Struktura tohoto souboru vy- padá následovně:
{
"localizationName":"Čeština", "translationItems":{
"items":[
{
"key":"unity.text.example",
"value":"Přeložený ukázkový text"
} ] } }
Všechna lokalizační data jsou uložena ve složce StreamingAssets. Tato složka má v Unity unikátní funkci. Při sestavování aplikace se data v této složce ignorují a složka i s celým obsahem se vloží do cílového adresáře sestavené aplikace. Data ze všech lokalizačních souborů se z této složky načtou při spuštění aplikace a deserializují se do připravených tříd.
Tyto třídy využívá třída LocalizationManager, která slouží pro přístup ostatních částí aplikace k lokalizaci a její nastavení. K propojení LocalizationManager s uživatelským
překlad. Pokud se v projektu vytvoří nová komponenta například pro překlad nadpisu okna pro vyhledávání cesty, může bez další interakce LocalizationManager vytvořit novou verzi překladových souborů s novým klíčem připraveným pro vyplnění překladu.
Pro podporu českých znaků musela být vytvořena nová mapa znaků s fontem, který tyto znaky podporuje. Pro aplikaci byl použit font Roboto-regular s českými znaky. Tento font je licencován pod Apache 2.0 licencí. Nástroje pro vygenerování této znakové mapy jsou součástí použitého pluginu TextMesh Pro. Doplnění českých znaků do atlasu je docí- leno zadáním hexadecimálního rozsahu hodnot, ve kterém se české znaky vyskytují v UTF-8 kódování. Všechny znaky z tohoto rozsahu jsou vyhledány v znakové sadě a rasterizovány do volných míst v atlase.
Rasterizace je prováděna vytvořením čtvercové mřížky, přes kterou se překrývají vektorové znaky. U každého čtverce se porovná velikost plochy, kterou vektorový objekt překrývá a na jejím základě se tomuto čtverci přidělí barevná hodnota v odstínech šedé.
5.7. Propojení se systémem STAG
IS/STAG Technické univerzity v Liberci poskytuje přístup k získávání části uložených dat bez nutnosti autorizace přes rozhraní architektury REST. Přístup k tomuto rozhraní probíhá prostřednictvím protokolu https na adrese https://stag-ws.tul.cz/ws.
Ilustrace 5.5: Vytvořený atlas s podporou českých znaků pro uživatelské rozhraní
LocalizationManager Translation configurations
+ RegisterTranslatableComponent(ILocalizationText): void + SetCurrentLocalization(string): void
+ LoadLocalizationConfigs(): void
ILocalizationText + GetLocalizationString(): string + ApplyTranslation(string): void
UITextTranslator + GetLocalizationString(): string + ApplyTranslation(string): void
Ilustrace 5.4: Závislost tříd pro lokalizaci uživatelského prostředí
REST definuje sadu principů, podle kterých je možné popsat webové služby se za- měřením na správu zdrojů a přenosem přes http protokol. Jednou z klíčových charakteristik je použití HTTP metod definovaných protokolem podle normy RFC 2616 [11]. Základní metody pro volání a jejich významy jsou tyto:
• GET pro načtení obsahu zdroje.
• POST pro vytvoření nového obsahu.
• PUT pro změnu stavu zdroje nebo jeho aktualizaci.
• DELETE pro odebrání zdroje.
Pro účely této aplikace je vyžadováno pouze načítání dat z IS/STAG. Pro všechny odesílané požadavky je proto využita pouze metoda GET. V následující tabulce jsou uve- deny všechny zdroje, které obě aplikace využívají. Součástí zdroje je i vrácený interface.
REST rozhraní může být v aplikaci vyměněno za libovolný jiný databázový systém, pokud bude vytvořen modul pro komunikaci s tímto systémem implementující uvedená rozhraní.
Tabulka 1: Využívané REST zdroje ze systému IS/STAG
Název zdroje Popis Odesílané
parametry Vracená struktura ucitel/
najdiUcitelePodleJmena
Vyhledá seznam učitelů které odpovídají vyplněnému jménu nebo příjmení
jmeno, prijmeni
ITeacher[]
ucitel/
getUcitelInfo
Vyhledá učitele podle zadaného identifikátoru učitele v IS/STAG
ucitIdno ITeacher[]
mistnost/
getMistnostiInfo
Vyhledá všechny místnosti odpovídající identifikátoru.
CisloMistnosti může být například A11
cisloMistno- sti
ILocation[]
mistnost/
getMistnostiInfo
Vyhledá všechny místnosti v zadané budově
zkrBudovy ILocation[]
rozvrhy/
getRozvrhByUcitel
Vyhledá rozvrhové aktivity pro učitele zadaného identifikátorem v IS/STAG v definovaném časovém rozsahu
ucitIdno, datumOd, datumDo
ISchedule[]
Protože načítání dat z webové služby může trvat až několik vteřin, není možné čekat na odpověď serveru při volání funkce pro načtení dat. Oddělení tohoto zpoždění od běhu aplikace je vyřešeno spuštěním volání v korutině. Tento postup je doporučený z doku- mentace Unity enginu. Zpracování korutiny probíhá v každé programové smyčce. Korutina při prvním zavolání sestaví a odešle požadavek na server a následně čeká na stažení dat.
Pokud data nejsou kompletně stažena, provádění funkce je přerušeno v bodě kontroly sta- žení a program dokončí programovou smyčku. Při další programové smyčce se korutina opět spustí, ale zpracování programu začne od místa posledního přerušení, tedy čekání na stažení dat. Tento cyklus se opakuje až do doby, než jsou data stažena a připravena ke zpracování. Stažená data jsou předána do callback metody předané korutině při startu. Tato metoda zajistí zpracování stažených dat a jejich prezentaci v uživatelském rozhraní, pří- padně může vyvolat jinou aktivitu.
REST rozhraní IS/STAG používá pro všechny využívané dotazy dva společné voli- telné parametry. Prvním je datový formát, ve kterém se očekává odpověď. Pokud tento parametr není uveden nebo je uveden ve výchozím nastavení, vrací se v odpovědi doku- ment XML. Tento formát byl vhodný zejména pro snadné identifikování chyb při odesílání chybných požadavků, například se špatným formátem data. Editor i WebGL aplikace zpra- covávají výstupní data ve formátu JSON.
Druhým parametrem je jazyková verze, ve které jsou data vrácena. Výchozí nasta- vení je čeština, ale část dat je přeložená i do anglického jazyka. Jazyk se zadává parametrem lang a ve výchozím nastavení je nastaven na hodnotu cs. Zde je využito toho, že parametr jazyka odpovídá formátu jazyka z lokalizace před pomlčkou. Proto může sys- tém inteligentně žádat o správnou jazykovou verzi v každém odeslaném požadavku, pokud jsou při nastavení lokalizace dodrženy pravidla pro jejich pojmenování.
Využití dat v JSONu přineslo jednu komplikaci. Téměř všechny odpovědi se vracely formátované jako pole obsahující jeden objekt. Třída pro práci s daty v JSONu implemen- tovaná v Unity ale nepodporuje deserializaci pole objektů na nejvyšší úrovni. Proto
IS/STAG Server REST API
WebGL klient
JSON objekt Požadavek na zdroj
Ilustrace 5.6: Schéma komunikace mezi WebGL a IS/STAG
všechny metody zpracovávající odpověď před deserializací odstraňují vnější hranaté zá- vorky a vytvářejí dočasný obalový objekt, do kterého se data dočasně uloží. Po úspěšné deserializaci se vyjme obsah z tohoto obalového objektu a dále se zpracovává v jeho oče- kávané podobě.
K odeslání požadavku do systému IS/STAG je využita Unity třída UnityWebRequest. Tato třída podporuje všechny základní REST metody a je pro získávání dat vhodnější než alternativní třída WWW. Ukázka samostatného vytváření a odeslání požadavku:
UnityWebRequest webRequest = new UnityWebRequest();
webRequest.url = path;
webRequest.SetRequestHeader("Content-Type",
"application/json");
webRequest.method = UnityWebRequest.kHttpVerbGET;
yield return webRequest.Send();
StarRequester IS/STAG Base url
+ LoadResource(string, <string, string>, callable) : void
LocationDB
+ FindLocationByName(string): void + FindLocsByBuilding(string): void
ILocation
+ GetRoomID(): int + GetBuildingName(): string + GetDescription(): string + GetRoomName(): string ScheduleDB
+ FindScheduleForTeacher(int): void + FindScheduleForStudent(string): void
TeacherDB
+ FindTeachersByName(string): void + FindTeachersByID(int): void
ISchedule
+ GetScheduleBuilding(): string + GetSchedRoomName(): string + GetSchduledTeacher(): ITeacher + GetScheduledTeacherID(): int + GetName(): string + GetShortcut(): string + GetScheduledDay(): string + GetStartTime(): string + GetEndTime(): string
ITeacher
+ GetTeacherID(): int + GetTeacherFullName(): string User Interface
+ CallbackMethods(ILocation[]): void + CallbackMethods(ITeacher[]): void + CallbackMethods(ISchedule[]): void
Ilustrace 5.7: Závislosti modulu pro komunikaci s IS/STAG
6. WebGL aplikace pro vizualizaci a navigaci
Druhou částí této práce je WebGL aplikace. Její úlohou je vizualizace areálu a jeho budov a vyhledávání v těchto prostorách cesty v závislosti na požadavcích uživatele.
Aplikace používá data z IS/STAG pro vyhledávání počátečních a koncových bodů a při- pravený model s navigační sítí pro vyhledávání cest mezi těmito body.
6.1. Spuštění WebGL aplikace s přiloženým projektem
Před tím, než bude moci uživatel začít využívat vytvořenou aplikaci, musí proběh- nout několik inicializačních kroků. Prvním z nich je stažení a spuštění samotného herního enginu po načtení stránky. Unity po načtení stránky spustí vlastní loader, který nejdříve zkontroluje kompatibilitu prohlížeče a pokud vyhovuje stáhne nejdříve samotný herní en- gin a následně vytvořený projekt. Oba stahované soubory jsou komprimovány souborovým formátem gzip pro snížení velikosti. Po stažení všech souborů se spustí Unity projekt.
Připravený unity projekt je jen základní aplikace bez dat pro zobrazení. K tomu slouží konfigurační soubor projektu vytvořený předchozím editorem. Tento soubor ob- sahuje data pro zobrazení geometrie areálu a navigační síť pro pohyb mezi budovami.
K tomu také obsahuje odkazy pro jednotlivé budovy. Stažením a deserializací tohoto sou- boru dojde k zobrazení areálu a uživatel může začít s aplikací pracovat.
Pro zkrácení doby načítání aplikace a zmenšení objemu stahovaných dat je při spuštění aplikace stažen pouze konfigurační soubor projektu obsahující model areálu.
Pokud uživatel změní pohled na konkrétní budovu, musí být tato budova při prvním zob- razení nejdříve stažena. Stažené modely budov i s vnitřní navigační sítí zůstávají v paměti aplikace až do jejího ukončení. Z tohoto důvodu jsou modely, které jsou datově nejobjem- nější částí v paměti, zjednodušeny o detaily v interiéru nebo komplexní geometrii.
6.2. Ovládání WebGL aplikace
Ovládání webové aplikace je vytvořeno tak, aby byly všechny funkce prohlížení dostupné kliknutím nebo držením levého tlačítka myši. Klávesnice je využívaná pouze pro zadání textových vstupů do formulářových prvků. Ty vyžadují, aby na ně uživatel nejdříve klikl a tím přepnul fokus do okna aplikace. V případě, že by aplikace neměla fokus v pro- hlížeči, mohl by pokus o ovládání klávesnicí spustit nechtěné akce v závislosti na nastavení prohlížeče. To platí také pro kliknutí pravého tlačítka myši.
Nejčastěji používanou funkcí aplikace je prohlížení areálu a budov, případně nale- zené trasy. Při návrhu ovládání byl proto kladen největší důraz na snadné ovládání kamery v prostoru. Držením levého tlačítka myši a tažením se pohybuje kamera v horizontální rovině. Pokud má myš kolečko, ovládá se rolováním výška zobrazeného řezu. Pro zařízení, která mají pouze dvoutlačítkovou myš nebo například dotykové plochy notebooků, je v aplikaci umístěno, v levé části, ovládání kamery. To se skládá z posuvníku nahrazující rolování myší a dvěma tlačítky pro rotaci kolem vertikální osy pozorovaného bodu.
Pro rotaci kamery se v prostoru udržuje 3D souřadnice sloužící jako objekt, který kamera sleduje. Od tohoto objektu se počítá vzdálenost a rotace kamery. Výpočet transfor- mační matice je ukryt v implementaci Unity třídy Transform. Změny parametrů této matice se provádí voláním funkcí nad instancí této třídy u každého objektu ve scéně. V případě kamery je to pro použití nového úhlu rotace funkce void RotateAround(Vector3 point, Vector3 axis, float angle). Pozice se vypočítává vektorovým sklá- dáním. Při každé změně je k současné pozici přičten vektor změny v daném snímku.
Přepočítávání pozice vypadá následovně:
transform.position = Vector3.SmoothDamp(transform.position, new Vector3(targetPosition.x,
currentHeight, targetPosition.z), ref cameraMovementVelicity,
Time.deltaTime * cameraHeightChangeSpeed);
V kódu je vidět využití metody SmoothDamp, která je použita místo jednoduchého přiřazení nové hodnoty pozice. Tato funkce provádí lineární interpolaci mezi první a druhou hodnotou v závislosti na posledním parametru. Posledním parametrem je rychlost změny a čas uběhlý od posledního vykresleného snímku v milisekundách. Touto kombina- cí je dosaženo plynulého pohybu kamery nezávislého na snímkové frekvenci.
6.3. Uživatelské rozhraní pro navigaci a informace
Uživatelské rozhraní aplikace je rozděleno do 3 sloupců. Každý sloupec sdružuje ovládací prvky pro jednu sadu funkcí programu. Levý sloupec obsahuje posuvník ovládají- cí výšku kamery a řez budovou a další tlačítka ovládají rotaci kamery.
dá nová nalezená cesta pokračuje z konečného bodu předchozí cesty. Pokud není předchozí cesta zatím nastavena, je počátečním bodem vchod do budovy, ve které první cesta končí.
Druhou částí okna je sada nástrojů pro vyhledávání cílového bodu. Tyto nástroje umožňují dotazovat se přes REST rozhraní do systému IS/STAG na možné cílové pozice.
Tato pozice je vždy číslo místnosti obsahující název budovy, poschodí a pořadové číslo.
Z tohoto čísla se naplánuje nejdříve cesta přes areál do nové budovy. Pokud je počáteční bod ve stejné budově jako konečný, je tento krok přeskočen. V budově je provedeno vyhle- dávání nejkratší cesty mezi počátečním bodem a číslem místnosti.
Číslo místnosti lze vyhledat dvěma způsoby. Buď je získáno z rozvrhu studenta v zadaném čase nebo je získáno z rozvrhu učitele v daném čase. Pro získání rozvrhu stu- denta stačí zadat osobní číslo. Pro získání rozvrhu učitele je nejprve nutné znát jeho ID.
Pro zjištění tohoto ID je do IS/STAG poslán požadavek pro nalezení všech učitelů se za- daným jménem nebo příjmením. Předpokládá se, že zadané jméno může být jen jeho část a dotaz na jméno a příjmení je proložen znakem % pro nalezení všech odpovídajících jmen. Aplikace po získání výsledků nabídne seznam jmen učitelů, ze kterého je jedno jmé- no vybráno a společně s datem a časem je nalezena místnost.
Pro vyhledávání pozice učitele mimo vyučovací hodiny jsou doplněny pravidla mimo IS/STAG. Pokud je čas menší než 7:00 a nebo větší než 20:00, je zobrazena chybová zpráva, že učitel není v prostorách školy. V opačném případě se aplikace pokusí najít číslo
Ilustrace 6.1: Rozložení uživatelského rozhraní WebGL aplikace
místnosti v doplňkové databázi a pokud není číslo kanceláře nalezeno, je opět zobrazena chybová zpráva s informací, že je učitel v kanceláři a pozice není známa.
6.4. Algoritmus nejkratší cesty v připraveném grafu
Pro vyhledávání nejkratší cesty mezi dvěma body je v aplikaci použit A* algorit- mus. Tento algoritmus je založen na podobném principu pro vyhledávání cesty v grafu jako Dijkstrův algoritmus. Rozdíl je ve způsobu výběru nejvhodnějších uzlů v každém cyklu pro pokračování. Při výbě- ru se uvažuje nejen součet vzdálenosti do současného bodu, ale i předpokládaná
vzdálenost do cílového bodu (1). Tato předpokládaná vzdálenost je vypočítávaná podle používané metriky. Implementace použitá v této aplikaci využívá Euklidovskou metriku a předpokládaná vzdálenost je délka úsečky mezi aktuálním a konečným bodem. A* algo- ritmus vrací vždy nejkratší cestu v grafu a v optimálních případech, kdy nejsou do cesty kladeny překážky ovlivňuje malé množství bodů navíc mimo nejkratší cestu.
(1)
Postup pro sestavení nejkratší cesty A* algoritmem probíhá následovně:
1. Inicializace prázdné cesty
2. Označení všech uzlů grafu jako nenavštívené 3. Vložení počátečního bodu do zásobníku
4. Prováděj cyklus dokud jsou nové body nebo je nalezena cesta 5. Vyber ze zásobníku uzel, který není uzavřený
6. Zkontroluj, jestli není vybraný uzel koncovým 7. Najdi nové okolní body, které nejsou uzavřené
8. Zmenši předchozí vzdálenost k novým bodům, pokud je menší než uložená
9. Nastav předchůdce z vybraného uzlu 10. Nastav nové body jako otevřené
11. Setřiď body podle celkové vzdálenosti od nejdelší 12. Vlož nové body na zásobník
13. Uzavři vybraný uzel
Ilustrace 6.2: Příklad procházení čtvercového grafu A* algoritmem s překážkou [13]
f (n)=g(n)+h(n)
6.5. Zobrazení cesty v budově
Pro zpřístupnění možnosti vyhledávání cest v budově je nejdříve nutné v menu projektu vybrat konkrétní budovu, ve které se bude cesta hledat. Pokud by se uživatel pokusil otevřít menu pro navigaci bez výběru budovy, je místo menu zobrazena chybová zpráva.
Body nalezené jako výsledná cesta mezi počátečním a koncovým uzlem se před navrácením zpět pro vykreslení nejdříve vyhladí Chaikinsovým algoritmem [5]. Tento algoritmus v každém cyklu z původních n bodů vytvoří 2n nových bodů a rozloží je pro- porcionálně mezi body původní podle (2).
Qi=3 4 Pi+1
4Pi+1
(2)
Z nově sestavených bodů se vytvoří posloupnost zobrazena ve vzorci (3). Chainkin- sonův algoritmus má pro body, které netvoří uzavřený kruh nevýhodu v tom, že krajní body se každou provedenou iterací vzdalují od původní koncové pozice. Proto je vždy po vytvoření nových bodů přidán na začátek a konec řady původní počáteční a koncový bod.
V každém cyklu tak vznikne místo původních 2n bodů 2n+2 nových bodů.
(3)
Po provedení několika cyklů je výsledná posloupnost předána do komponenty Line- Renderer. Ta je součástí Unity engine a vytváří na základě předaných bodů mesh
procházející těmito body. Výsledná geometrie je zobrazena uživateli v podobě cesty pro- cházejí areálem nebo budovou.
Ri=1 4 Pi+3
4 Pi+1
Ilustrace 6.3: Postup vyhlazování cesty Chainkinsonovým algoritmem {P0, Q0, R0, Q1, R1,... , Q(n−1), R(n−1), P(n−1)}
7. Testování editoru a WebGL aplikace
U Unity aplikací se občas může stát, že dynamicky se přizpůsobující prvky nereagují v některých případech na podněty vstupních zařízení, například kliknutí myši. K tomuto jevu dochází při překrytí nebo vypnutí kolizního boxu jiným prvkem. Tyto chyby uživatel- ského rozhraní nemusí být při pozorování zřejmé, protože překrývající objekty mohou mít deaktivovanou grafickou část, ale kolizní box je stále aktivní. Proto byla aplikace editoru otestována v rozlišení, které nabízel dostupný hardware.
7.1. Testy rozlišení editoru
Tabulka 2: Testy rozlišení aplikace editoru budov
Testované rozlišení Viditelné prvky UI Interakce prvků UI
1280×720 Ano Ano
1366×768 Ano Ano
1650×1080 Ano Ano
1920×1080 Ano Ano
7.2. Testy WebGL aplikace v prohlížečích
WebGL aplikace byla umístěna na virtuální server zapůjčeného hostingu, ze kterého byla aplikace spouštěna v testovaných prohlížečích. V testovaných prohlížečích byla ově- řena funkce WebGL aplikace, velikost spotřebované paměti po 5 minutách provozu a funkce jednotlivých modulů. Získané výsledky jsou uvedeny v tabulce Tabulka 3: Vý- sledky testů WebGL aplikace ve vybraných prohlížečích
Testování paměťové náročnosti proběhlo ve všech prohlížečích při otevřené jediné záložce s nástroji pro vývojáře. Všechny testované prohlížeče umožňují pořízení snímku paměti s jejím obsahem. Během měřeného času byla v aplikaci provedena totožná sada úloh pro zapojení vytvořených modulů. Tímto se zároveň ověřila funkčnost všech modulů v daném prohlížeči. Testované moduly byly následující:
• Výběr jazykové verze aplikace
• Zobrazení budovy s rozvrhovou akcí
Ve výsledku nebyly s aplikací zjištěny žádné potíže s výjimkou Internet Exploreru, který i přes uvedení podpory WebGL[12] nemohl aplikaci spustit z důvodu vyvolané chy- by InvalidStateError způsobené skriptem UnityLoader.js.
Tabulka 3: Výsledky testů WebGL aplikace ve vybraných prohlížečích Prohlížeč Podpora
WebGL[12]
Spustitelná aplikace
Průměrná velikost zabrané paměti
Fungují všechny moduly Google Chrome
V61.0.3163.79
Ano Ano 355 MB Ano
Mozilla Firefox
V55.0.3 Ano Ano 324 MB Ano
Internet Explorer V11.1593
Ano Ne Nelze změřit Nelze testovat
Microsoft Edge V38.14393
Ano Ano 342 MB Ano
Opera
V47.0.2631 Ano Ano 398 MB Ano
7.3. Testy na mobilních zařízeních
I když Unity uvádí v dokumentaci, že sestavené WebGL aplikace nejsou podporová- ny, výjimečně se objeví aplikace, která je dostatečně jednoduchá na to, aby byla na mobilních zařízeních spustitelná. Při otevření webové stránky s aplikací zobrazuje Unity oznámení, že zařízení není podporováno, ale umožní po potvrzení aplikaci spustit.
Webová aplikace byla testována na mobilním telefonu Samsung i9100 s verzí andro- idu s vestavěným prohlížečem, mobilní verzí prohlížeče Firefox a na tabletu Apple iPad 2 s prohlížečem Safari.
Tabulka 4: Test kompatibility mobilních zařízení s Unity WebGL aplikací Typ zařízení Zobrazení zprávy
o kompatibilitě
Stažení unity engine Spuštění aplikace Samsung i9100
(vestavěný prohlížeč)
Ano Ano Ne
Samsung i9100 (mobilní verze Firefoxu)
Ano Ne – Program spadl
z důvodu nedostatku paměti
Ne
Apple iPad 2 (Safari) Ano Ne – stránka se sama obnovila po 10 vteřinách
Ne
Výsledky potvrzují nedostatek kompatibility WebGL verze Unity pro mobilní za- řízení v použité verzi. Částečnou náhradou pro tato zařízení může být vytvoření APK souboru pro obchod Google Play, aby bylo možné spustit navigační aplikaci nativně.
Nicméně pro použití této aplikace na mobilních zařízeních by bylo nutné aktivovat instala- ci aplikací z cizích zdrojů nebo ji umístit jako registrovaný vývojář do obchodu Google Play.
8. Závěr
V této práci se podařilo převést existující modely z původních formátů programů 3D Studio Max a Maya do více nezávislého formátu OBJ. Tyto modely byly upraveny tak, aby byly vhodné pro zobrazení na webu zejména s ohledem na datovou velikost. K převe- deným modelům byla vytvořena nová budova G z dodaných pasportů a ze všech dostupných budov areálu Husova.
Pro použití těchto modelů byl vytvořen editor projektu jako aplikace pro systém Windows v herním enginu Unity. Tato aplikace umožňuje připravit vytvořené modely ve formátu OBJ jako projekt pro druhou aplikaci pro WebGL. Editor mimo připravení modelů umožňuje vytvořit i navigační síť nad modelem pro vyhledávání cest. Připravený projekt je prezentován ve WebGL aplikaci vytvořenou také v Unity. Tato aplikace umožňuje vyhle- dávat v připravených modelech cesty na základě dotazů na REST rozhraní systému IS/STAG. Jazykové prostředí této aplikace je možné za běhu přepínat do připravených pře- ložených jazykových verzí. Jednotlivé budovy čerpají z IS/STAG i geografická data pro zobrazení umístění budovy na mapě mimo prostředí WebGL.
Dalšími možnostmi pro rozšíření funkcí této aplikace je využítí velkého množství podporovaných platforem Unity pro přenesení této aplikace na mobilní zařízení, na kterých vytvořená Unity verze WebGL aplikace zatím nefunguje. Zejména pro mobilní zařízení by mohla být vhodným doplňkem možnost uložit nalezené cesty na prohlížení později.
Seznam použité literatury
[1] Zvukové informační tabule a vitríny. EGMenergo: Speciální elektronika [online].
c2005-2015 [cit. 2017-09-03]. Dostupné z: http://www.egmenergo.cz/index.php?
text=mluvici-zvukove-informacni-tabule-vitriny
[2] 3D-Wayfinding and Indoor Navigation. Youtube [online]. 10.04.2013 [cit. 2017-08- 17]. Dostupné z: https://youtu.be/h1ofq_5V9bY. Kanál uživatele
SISsigninfosystems
[3] HOLEC, Petr. Vyhledávání optimální trasy v 3D modelu terénu. Liberec, 2013.
Diplomová práce. TECHNICKÁ UNIVERZITA v LIBERCI. Vedoucí práce Ing.
Jiří Jeníček, Ph.D.
[4] SHARKAWI, K. H.; UJANG, Muhamad Uznir; ABDUL-RAHMAN, A. 3D navigation system for virtual reality based on 3D game engine. Proceedings of the International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Beijing, China, 2008, 37.
[5] CHAIKIN'S ALGORITHMS FOR CURVES. The Institute for Data Analysis and Visualization [online]. Beaverton: Ken Joy, 2000 [cit. 2017-05-08]. Dostupné z:
http://graphics.cs.ucdavis.edu/education/CAGDNotes/Chaikins- Algorithm/Chaikins-Algorithm.html
[6] A feature-rich and highly flexible editor. Unity - Game Engine [online]. Unity Technologies, 2017 [cit. 2017-05-08]. Dostupné z: https://unity3d.com/unity/editor [7] Blender [online]. [cit. 2017-07-16]. Dostupné z: https://www.blender.org/
[8] A* Search Algorithm. GeeksforGeeks | a computer science portal for geeks [online]. Unity Technologies, 2016 [cit. 2017-05-08]. Dostupné z:
http://www.geeksforgeeks.org/a-search-algorithm/
[9] JSON: jednotný formát pro výměnu dat. Zdroják.cz [online]. Devel.cz Lab, 2008 [cit. 2017-09-06]. Dostupné z: https://www.zdrojak.cz/clanky/json-jednotny- format-pro-vymenu-dat
[11] RESTful Web services: The Basics. IBM: developerWorks [online]. Alex Rodriguez, 2008 [cit. 2017-09-06]. Dostupné z:
https://www.ibm.com/developerworks/webservices/library/ws-restful/
[12] WebGL - 3D Canvas graphics. Can i use [online]. 2017 [cit. 2017-05-03].
Dostupné z: http://caniuse.com/#feat=webgl
[13] Heuristics for grid maps. Standford Theory Group [online]. Amit Patel, ©2017 [cit. 2017-09-03]. Dostupné z:
http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html
