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 tří-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:
<Description>Testovací objekt</Description>
<BuildingXMLFile>building0.xml</BuildingXMLFile>
<ExternalMapLink />
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ě:
"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í
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é
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
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í
+ LoadResource(string, <string, string>, callable) : void
LocationDB
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
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
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