• No results found

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 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ájmé-no a společně s datem a časem je nalezena místjmé-nost.

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

Related documents