Na tomto místě bude oficiální zadání vaší práce

Na tomto místě bude oficiální zadání vaší práce Toto zadání je podepsané děkanem a vedoucím katedry, musíte si ho vyzvednout na studiijním oddělení Katedry počítačů na Karlově náměstí, v jedné odevzdané práci bude originál tohoto zadání (originál zůstává po obhajobě na katedře), ve druhé bude na stejném místě neověřená kopie tohoto dokumentu (tato se vám vrátí po obhajobě). i

ii

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce Diplomová práce Možnosti prezentace 3D budov na webu Bc. Daniel Šrám Vedoucí práce: prof. Ing. Jiří Žára, CSc. Studijní program: Otevřená informatika, strukturovaný, Navazující magisterský Obor: Počítačová grafika 30. dubna 2012

iv

v Poděkování Velmi rád bych poděkoval a vyslovil uznání prof. Ing. Jiřímu Žárovi, CSc., vedoucímu mé diplomové práce, za trpělivé vedení, ochotu a mnoho cenných rad. Dále bych chtěl poděkovat rodičům za poskytnuté zázemí a podporu v průběhu celého mého studia.

vi

vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne 10. 5. 2012.............................................................

viii

Abstract This thesis consists of several parts. The first part is dedicated to technologies that allow to users display 3D real building model using web services. It comprehensively compares VRML, WebGL, Flash3D and Google Earth technologies by several aspects. The second part deals with presentation of real building virtual model and the model virtual scenes implementations using these technologies. The final presentation must meet criteria for high quality scene display, user interface, user control interaction and must be compatible with standard web browsers. The purpose of this work is to provide an overview and comprehensive description of significant advantages and disadvantages of mentioned technologies to programmers or developers, and also to provide this virtual building model to more internet visitors supported by modern technologies. Abstrakt Tato diplomová práce se skládá z několika částí. V první části se věnuje technologiím, které umožňují zobrazit 3D model reálné budovy pomocí webových služeb uživateli. Jedná se tak o komplexní porovnání technologií VRML, WebGL, Flash3D a Google Earth z několika hledisek. Druhá část práce se zabývá zobrazením virtuálního modelu reálné stavby a implementací virtuálních scén modelu v těchto technologiích. Výsledné prezentace přitom musí splňovat kritéria pro kvalitní zobrazení scény, uživatelské rozhraní, interakci uživatele se scénou a musí být kompatibilní s dnes běžně používanými prohlížeči. ix

x Cílem diplomové práce je nejen poskytnout budoucím tvůrcům a zájemcům o zmíněné technologie přehled o jejich výhodách a nevýhodách, ale také zpřístupnit uvedený virtuální model většímu počtu uživatelů pomocí moderních technologií.

Obsah 1 Úvod 1 2 Analýza projektu 3 2.1 Z hlediska diplomové práce............................ 3 2.2 Z hlediska technologického............................. 3 2.3 Z hlediska uživatelského.............................. 3 3 Popis technologií pro prezentaci 3D budov na webu 5 3.1 VRML/X3D..................................... 5 3.2 WebGL....................................... 5 3.3 Flash 3D....................................... 6 3.4 Google Earth.................................... 7 3.5 Další možnosti zobrazení budov.......................... 8 4 Srovnání použitých technologií 9 4.1 Záměr využití technologie............................. 9 4.2 Dostupné knihovny a frameworky 1........................ 10 4.3 Publikování 3D modelu............................... 10 4.4 Potřeba dodatečných instalací pro zobrazení modelu.............. 10 4.5 Integrace modelu s okolím............................. 11 4.6 Možnosti optimalizace dat............................. 11 4.7 Objektové programování.............................. 12 4.8 Funkcionalita v prohlížečích............................ 12 4.9 Programovací náročnost.............................. 13 4.10 Vývojové nástroje pro tvorbu scén........................ 13 4.11 Navigace uživatele scénou............................. 14 4.12 Podpora pro vývojáře ve formě výukových materiálů.............. 14 4.13 Export dat z modeláře............................... 15 4.14 Práce s daty modelu................................ 16 4.15 Velikost vkládaného modelu............................ 16 4.16 Oficiální dokumentace............................... 17 4.17 Tvorba her a logických celků............................ 17 1 Slovem frameworky se v této práci myslí nadstavby (též soubory knihoven), které představují ucelené struktury pro podporu programování v dané technologii. Mohou tak obsahovat řešené problémy ve formě návrhových vzorů, další knihovny či podpůrné programy. xi

xii OBSAH 4.18 Bezpečnost..................................... 17 4.19 Animace....................................... 18 4.20 Multimediální obsah................................ 19 4.21 Osvětlovací modely, světla............................. 19 4.22 Typy stínování................................... 20 4.23 Simulace mlhy, částicové systémy......................... 20 4.24 Možnosti interaktivních prostředí......................... 21 4.25 Stupeň grafické prezentace............................. 21 4.26 Velikost přenášených dat.............................. 21 4.27 Hardwarové nároky................................. 22 4.28 Složitost vytvoření virtuální prezentace...................... 22 4.29 Využitelnost technologií do budoucna a jejich vývoj............... 23 4.30 Další sledované parametry zvolených technologií................. 23 4.31 Kvalita zobrazení a rychlost výpočtu scény.................... 24 4.32 Kolize........................................ 25 4.33 Textury a jejich omezení.............................. 26 4.34 Grafické karty a ovladače............................. 26 4.35 Omezení technologie Flash............................. 26 5 Shrnutí srovnávaných kritérií 31 6 Realizace 33 6.1 VRML/X3D..................................... 33 6.2 WebGL....................................... 34 6.2.1 Použité frameworky a technologie, zvolený postup........... 34 6.2.2 Převod zdrojových dat........................... 35 6.2.3 Vytvoření základní scény.......................... 35 6.2.4 Implementace pohybu a omezení avatara................. 39 6.2.5 Navigační a ovládací prvky........................ 41 6.2.6 Virtuální procházka a vytvoření animací................. 42 6.2.7 Level of Detail............................... 46 6.2.8 Implementace galerie a propojení s aplikací............... 46 6.2.9 Vytvoření zjednodušené verze scény.................... 48 6.2.10 Optimalizace................................ 48 6.2.11 Shrnutí a výsledky měření obou verzí................... 50 6.3 Flash 3D....................................... 53 6.3.1 Použité frameworky, technologie a pracovní postup........... 53 6.3.2 Implementace scény............................ 53 6.3.3 Implementace navigace a HUD...................... 57 6.3.4 Řešené problémy.............................. 60 6.3.5 Virtuální procházka scénou a animace.................. 62 6.3.6 Implementace galerie............................ 62 6.3.7 Dvě verze scény............................... 65 6.3.8 Optimalizace vykreslování, LOD..................... 65 6.3.9 Shrnutí a výsledky měření obou verzí................... 66 6.4 Google Earth.................................... 70

OBSAH xiii 6.4.1 Pracovní postup.............................. 70 6.4.2 Objekt v modeláři............................. 71 6.4.3 Použití Google SketchUp......................... 71 6.4.4 Optimalizace modelu pro Google Earth................. 72 6.4.5 Texturování objektu............................ 74 6.4.6 Odeslání dat na Google.......................... 75 6.4.7 Editace modelu............................... 76 6.4.8 Omezení z hlediska aplikace........................ 77 6.4.9 Shrnutí................................... 77 7 Testování 79 7.1 Návrh uživatelských testů............................. 79 7.2 Scénáře pro testování................................ 79 7.3 Vyhodnocení pro jednotlivé technologie...................... 81 7.4 Návrhy na zlepšení do budoucna......................... 83 8 Závěr 85 Literatura 87 A Seznam použitých zkratek 91 B Obsah přiloženého CD 93

xiv OBSAH

Seznam obrázků 4.1 Simulace vody vytvořená pomocí technologie WebGL.............. 22 4.2 Testovací scéna pro měření použití obou renderovacích algoritmů....... 27 4.3 Graf měření pro renderovací algoritmus basic.................. 28 4.4 Graf měření pro renderovací algoritmus quadrant................ 29 6.1 Pracovní proces vytvoření scény.......................... 34 6.2 Cílový formát dat je formát Collada verze 1.4 s využitím parametrů..... 36 6.3 Červeně je naznačen prostor, kde se avatar nesmí pohybovat.......... 40 6.4 Uživatelské rozhraní aplikace technologie WebGL................ 43 6.5 Aktivní navigační prvek v objektu kostela.................... 44 6.6 Pohyb kamery při animaci s plynulým otáčením................. 45 6.7 Zjednodušený model scény v technologii WebGL................ 50 6.8 FPS virtuální procházky zjednodušené verze scény WebGL........... 51 6.9 FPS virtuální procházky plné verze scény WebGL................ 52 6.10 Pracovní proces vytvoření scény v technologii Flash3D............. 54 6.11 Uživatelské rozhraní pro technologii Flash3D.................. 59 6.12 Z-sorting problem při použití Basic renderer algoritmu............. 60 6.13 FPS virtuální procházky při použití Basic renderer algoritmu......... 67 6.14 FPS virtuální procházky při použití Quadrant renderer algoritmu....... 68 6.15 Zjednodušený model scény v technologii Flash3D................ 69 6.16 Pracovního postup realizace modelu v technologii Google Earth........ 70 6.17 Výběr lokality pro vložení 3D modelu....................... 72 6.18 Model zasazený do terénu v Google SketchUp.................. 73 6.19 Nanášení textury pomocí funkce import..................... 74 6.20 Proces odesílání dat do galerie 3D objektů a do procesu schválení....... 75 6.21 Uživatelské rozhraní 3D galerie modelů aplikace 3D Warehouse........ 76 7.1 Nastavení uživatelského testu pro testování jednotlivých aplikací........ 80 xv

xvi SEZNAM OBRÁZKŮ

Seznam tabulek 4.1 Další parametry srovnávaných technologií.................... 24 4.2 Měření FPS v závislosti na počtu polygonů s použitím obou vykreslovacích algoritmů....................................... 28 5.1 Shrnutí kritérií porovnánaných technologií.................... 32 6.1 Porovnání počtu polygonů v plné a ve zjednodušené verzi scény........ 49 6.2 Porovnání měření FPS pro viewpointy obou verzí scén technologie WebGL.. 51 6.3 Porovnání měření FPS pro viewpointy obou verzí scén technologie Flash3D. 67 7.1 Tabulka zůčastněných participantů........................ 80 xvii

xviii SEZNAM TABULEK

Kapitola 1 Úvod Tato diplomová práce se skládá ze dvou částí. V první části se věnujeme technologiím, které umožňují zobrazit 3D model reálné budovy pomocí webových služeb uživateli. Jedná se tak o komplexní porovnání vybraných 3D technologií z několika hledisek, přičemž jsou zohledněny vlastní zkušenosti a znalosti z oblasti webových služeb a počítačové grafiky. Druhá část práce se zabývá zobrazením virtuálního modelu z literatury [Šrám(2010)] a implementaci virtuálních scén modelu v těchto technologiích. Výsledné prezentace musí splňovat kritéria pro kvalitní zobrazení scény, uživatelské rozhraní pro interakci uživatele s objektem a musí být kompatibilní s dnes běžně používanými prohlížeči. Cílem diplomové práce je nejen poskytnout budoucím tvůrcům a zájemcům o zmíněné technologie přehled a komplexnější nahlédnutí do výhod a nevýhod technologií, ale také zpřístupnění uvedeného virtuálního modelu objektu většímu počtu uživatelů internetu pomocí moderních technologií. Virtuální model byl původně vytvořen jako obraz reálného kostela, který slouží pro mše, koncerty, ale také jako místo vernisáží umělkyně Adriany Skálové. K této příležitosti byla v předchozí práci [Šrám(2010)] vytvořena také webová aplikace pro správu výstav obrazů, které se poté ve virtuálním kostele zobrazují. Objekt kostela je rozdělen do dvou částí přízemí a balkonu. Galerie se nacházejí v přízemí kostela, balkon slouží jako místo pro starobylé varhany, jenž jsou, spolu s dalšími objekty, součástí celého modelu. 1

2 KAPITOLA 1. ÚVOD

Kapitola 2 Analýza projektu 2.1 Z hlediska diplomové práce Diplomová práce bude podle zadání realizovat několik samostatných celků. Prvním celkem je studium a popis technologií, které v tomto projektu využijeme pro realizaci cíle. To zahrnuje i porovnání použitých technologií z několika hledisek, programátorského a uživatelského. Dalším celkem je popis řešení, neboli implementace, což lze pojmout také jako popis při postupu vkládání 3D objektů do těchto technologií, včetně využití webové aplikace pro správu galerie. Posledním celkem práce bude testování, které je velice důležité z hlediska zpětné vazby od uživatele směrem k tvůrci projektu. Prostřednictvím uživatelských testů lze získat návrhy, nápady a poznámky uživatelů, které později budou sloužit jako hlavní předmět pro zlepšení jednotlivých částí. 2.2 Z hlediska technologického Z hlediska technologického bude projekt rozdělen do několika částí. Projekt totiž zahrnuje několik různých technologií, které budeme studovat a poté se v každé použité technologii budeme snažit vytvořit co nejvěrnější virtuální podobu reálného objektu. Každá část je tak popisem jedné této technologie, jejího obecného popisu a detailního návodu, jak při vkládání 3D objektu postupovat, aby bylo dosaženo co nejlepších výsledků. 2.3 Z hlediska uživatelského Tento projekt má za cíl umožnit co nejvíce uživatelům virtuálně nahlédnout do reálného objektu - kostela, popsaného v literatuře [Šrám(2010)]. Popsaný objekt slouží nejen pro mše a významné každoroční události, je také vzácnou památkou a místem, kde paní Adriana Skálová, česká malířka vystavuje své obrazy a pořádá výstavy. Bohužel na opravy takovéto památky nezbývá mnoho prostředků, a proto je naším dalším cílem umožnit lidem podílet se na zlepšení stavu objektu tím, že jej zpřístupníme ještě více lidem pomocí níže uvedených technologií. Sledujeme tím zvýšení zájmu, možnost vidět objekt z pohodlí domova ihned, pouze prostřednictvím virtuální reality na internetu. 3

4 KAPITOLA 2. ANALÝZA PROJEKTU

Kapitola 3 Popis technologií pro prezentaci 3D budov na webu Tato kapitola popisuje zvolené a dále v textu srovnávané technologie pro prezentaci 3D modelů budov ve webovém prostředí. Ke srovnání byla přiložena i technologie VRML, která byla použita v bakalářské práci [Šrám(2010)] pro zpřístupnění stavby kostela prostřednictvím prohlížeče. 3.1 VRML/X3D Popis technologie VRML, potažmo X3D je dostupný v literatuře [Šrám(2010)]. Literatura se věnuje podrobněji využití této technologie, způsobům vytvoření prezentace a její publikace pro veřejnost. V této práci technologii zahrnujeme pro srovnání mezi ostatní zmíněné techniky použité pro 3D zobrazení budov. 3.2 WebGL WebGL neboli Web Based Graphics Library je knihovna, která rozšiřuje možnosti jazyka JavaScript pro generování 3D scén. Tato knihovna umožňuje přístup k výpočetním prostředkům grafické karty a následné zobrazení scény tak probíhá v běžném webovém prohlížeči (který obsahuje podporu technologie WebGL). Tato knihovna tedy umožňuje vytvářet 3D scény, renderovat je v reálném čase a použít je tak pro webové prezentace či jiné účely. Pro uživatele to v budoucnu bude znamenat interaktivnější webové služby a vizuálně více zajímavý web [Vukićević(2010)]. Knihovna představuje webový standard, takže nepotřebuje ke svému spuštění žádný plugin. Do HTML kódu verze 5 se vkládá pouze pomocí elementu <canvas>. Technologie WebGL vznikla z experimentů nazvaných Canvas 3D Vladimira Vukićeviće, programátora Mozilly, který své experimenty poprvé prezentoval v roce 2006. Později se technologie rozšířila i mezi další společnosti, jako např. Opera. V roce 2009 poté nezisková organizace Khronos [Khronos(2011b)] a Mozilla založily pracovní skupinu WebGL jejíž první specifikace 1.0 byla vydána v březnu 2011. 5

6 KAPITOLA 3. POPIS TECHNOLOGIÍ PRO PREZENTACI 3D BUDOV NA WEBU Technologie je stále ještě v mohutném vývoji a dá se říci, že je stále velkou novinkou ve světě 3D technologií. Jak již bylo řečeno, pochází od skupiny Khronos, tedy organizace, která je zodpovědná za mnohé standardy, např. OpenGL nebo OpenGL ES (knihovny pro mobilní zařízení). Právě na OpenGL ES je založena i WebGL [Giles(2011b)]. Podporu nyní najdeme téměř ve všech webových prohlížečích. Oficiálně nemá zájem pouze Microsoft. Ostatní, jako Mozilla, Google či Apple se skupinou spolupracují a na vývoji se aktivně podílí. Nevýhody této technologie plynou nyní pouze z její krátké existence a rychlejším vývoji. Snadno se tak stane, že výuková pásma či ukázky této technologie jsou zastaralé, protože se specifikace [Khronos(2011a)] neustále mění. Najdeme tak mnoho ukázek, které nefungují, nebo potřebují starší verzi této knihovny. Nelze zaručit ani správný běh v prohlížečích všech verzí. Všechna tato úskalí se však během blízké budoucnosti pravděpodobně ustálí. C3DL Psaní kódu v čistém WebGL není příliš efektivní. V naprosté většině to znamená mnoho řádků kódu na zobrazení jednoduchého objektu, proto je velice výhodné využít některý Framework. C3DL je námi zvolený Framework, který poskytuje sady nástrojů a tříd pro práci s matematickými vzorci, scénou a 3D objekty, jako např. parsování formátu Collada, tzv. mouse-picking či možnosti animace [Bishop(2011), Goduguluri(2011)]. Opět zjednodušuje práci s WebGL a poskytuje programátorovi základní funkce, kterými lze objektově popsat a vytvořit scénu, naprogramovat kameru, virtuální procházky a místa pohledu (tzv. viewpoitny) a celkově tak scénu kvalitním způsobem zpracovat podle požadavku. K dispozici je mnoho testů a ukázek jednoduchých scén [Bishop(2011), Funnell(2011)], ve kterých se programátor rychle zorientuje a pochopí základní vlastnosti a konstrukce této technologie. Ostatní knihovny Další frameworky pro tuto technologii vznikají velice rychle, přičemž každý má své výhody a charakteristiky a neexistuje odpověď na to, zda je některý opravdu nejlepší pro použití nováčkem či zkušeným programátorem z oblasti grafiky. Za zmínku jistě stojí knihovny, které umožňují využití Javascriptu, generovaným přímo pomocí modelovacího nástroje, např. SceneJS [Kay(2011)] či Processing.js [Resig(2011)]. Další varianty jsou např. GLGE [GLGE(2011a)], javascriptová knihovna, která má za cíl usnadnit použití WebGL, oddělit programovací část od webové za účelem, aby se webový vývojář mohl více věnovat vytváření bohatších webových prezentací. Je také často nazývána WebGL for Lazy. Stručné porovnání knihoven pro WebGL nabízí literatura [Hedman(2011)]. 3.3 Flash 3D Flash je formát, který byl původně vyvinut pro tvorbu interaktivních prezentací, animací a her ve 2D formátu. Později se začalo uvažovat o jeho rozšíření i pro třetí rozměr. Pro tento účel byly vyvinuty speciální rozšiřující knihovny, především Papervision3D a Yogurt3D.

3.4. GOOGLE EARTH 7 Technologie Flash je navíc globálně velmi rozšířená a populární. Nedávno navíc společnost, která technologii vytvořila, koupil gigant - Adobe. Technologie jde neustále kupředu, před několika lety se objevila nová, složitější, ale zároveň mocnější verze ActionScriptu, objektově orientovaného jazyka pro tvorbu aplikací pro Flash. Společnost Adobe také poskytla velice kvalitní vývojové prostředí, tzv. Flash Builder, který zastřešuje vývoj několika typů projektů, umožňuje jejich propojení, kompilace a publikace v podobě webových služeb. Nevýhodou této technologie může být její nižší výkon a chybějící hardwarová akcelerace pro 3D aplikace a dále také placené zmíněné vývojové prostředí. Papervison3D Zvolená rozšiřující knihovna pro vývoj 3D aplikací a scén, která přináší řadu výhod pro programátory, jako je podpora formátu Collada, podpory textur, stínování, tvorby primitiv, více druhů kamery či mnoho optimalizačních triků. Tato technologie je velice populární, dostatečně propracovaná a méně náročná pro tvorbu scén, než ostatní rozšiřující knihovny [Lindquist(2010), Papervision3D(2007)]. Ostatní knihovny Mezi ostatní knihovny bych zahrnul především Yogurt3D. Podle oficiálního popisu z literatury [Yogurt3D(2010)] se jedná spíše o herní engine, založený na ActionScriptu verze 3.0. Byl vyvinut primárně pro tvorbu 3D her, které je možné spouštět v prohlížeči bez dodatečných instalací. Poskytuje systém pro tvorbu animací, export z modeláře či systém řízení scény. Sami vývojáři prohlašují knihovnu Yogurt3D jako mocný nástroj pro tvorbu 3D her. Z našeho pohledu se jedná o velmi dobrý nástroj, ovšem pro začátky s 3D technologiemi pro Flash příliš složitý. 3.4 Google Earth Projekt Google Earth pochází od světoznámé společnosti Google a představuje možnost, jak se virtuálně přenést pomocí počítače kamkoli na Zeměkouli. Aplikaci si může uživatel stáhnout do svého počítače, nebo lze nainstalovat příslušný plugin pouze pro internetový prohlížeč. Po spuštění se poté zobrazí uživateli náhled na celou Zeměkouli. Jednoduchou navigací pomocí uživatelského rozhraní se poté lze přemisťovat, zoomovat a procházet se tak po kterémkoli místě, které uživatele zajímá. Zeměkoule je 3D objekt, složený z fotografií zemského povrchu. Při přiblížení či oddálení se tak uživateli aktualizují snímky v daném výřezu čímž lze postupně vidět ostré obrázky do maximálního přiblížení několika desítek metrů. Rychlost aktualizace obrázků je však závislá na rychlosti připojení daného uživatele, protože aplikace si vždy stahuje data z webu. Protože se jedná o reálné fotografie, je tento datový tok nemalý, načtení snímků tak může trvat i desítky vteřin. Pomocí této technologie však lze spatřit při přiblížení jednotlivá vozidla i lidi. Aplikace samozřejmě nemapuje takto detailně 100% zemského povrchu, pro nás a většinu populace však obsahuje dostatečně podrobná data. Aplikace také umožňuje zobrazení vrstev, čímž lze využít další užitečné funkce a informace.

8 KAPITOLA 3. POPIS TECHNOLOGIÍ PRO PREZENTACI 3D BUDOV NA WEBU V roce 2011 představil Google několik novinek, které tuto aplikaci posouvají vpřed. Uživatel má možnost tzv. průletu trasy helikoptérou. Pokud si tedy uživatel naplánuje v Google Earth trasu mezi místy a klikne na příslušnou ikonu, má možnost se virtuálně nad touto trasou proletět. Dalšími možnostmi aplikace jsou např. geotaging, záznam vlastní prohlídky kdekoli na světě, možnost street view módu či různých měření a zakreslování. Doplňků pro tuto aplikaci je mnoho a s postupem času jsou stále k dispozici doplňky nové [Google(2011a)]. Tato aplikace je pro náš projekt zajímavá z několika hledisek. Produkt je velice rozšířen a firma Google má obrovský potenciál úspěšnosti. Ale hlavně Google umožnil pomocí svého API vkládání vlastních 3D modelů reálných budov a objektů do tohoto systému, jako jsou letiště, hotely, památky a mnoho dalšího. Zde se dostáváme do pro nás nejvíce zajímavého bodu, tedy umístění kostela Sv. Petra a Pavla do Google Earth. Podrobný postup, jak takového cíle dosáhnout bude uveden v kapitole 4 diplomové práce. 3.5 Další možnosti zobrazení budov Jednou z dalších možností, kterou považuji za zajímavou, je novinka od společnosti Google, která spolupracuje s technologií WebGL. Oddělení Google Maps vydalo novou beta verzi map, ve kterých má uživatel možnost povolit funkci Google MapsGL [Cheredar(2011)]. Tím získá přístup k hardwarově akcelerované variantě map, zobrazitelných bez jakýchkoli pluginů a instalací přímo skrze browser. Navíc má uživatel možnost rychlé změny zobrazení do StreetView [Google(2012)] a plynulejší přechody při rotaci map. Zajímavé spojení technologie WebGL a myšlenky Google Earth bylo realizováno na Fakultě informatiky, Masarykovy univerzity v Brně při implementaci projektu WebGL Earth, neboli Virtuální glóbus v internetovém prohlížeči [Sloup(2011)]. Jedná se o projekt podobný myšlence Google Earth s rozdílem v použitých technologiích. Glóbus je tak přístupný v internetových prohlížečích bez nutnosti instalace pluginů a jiných aplikací, jako právě v případě Google Earth. Společnost Google vyvinula jednu z dalších technologií pro zobrazení virtuální reality prostřednictvím webového prohlížeče. Technologie používá poněkud jinou filozofii, kterou je překreslování změn namísto celé scény v každém obrazovém rámci pro lepší výkonnost. Jedná se o technologii O3D [Google(2011f), Ortiz(2010)]. O3D je tak další plugin od společnosti Google, jenž představuje nástroj pro zobrazení interaktivních her, reklam atd. Funguje na základě JavaScrip API v propojení s O3D softwarem, obsaženým v pluginu, a propojením s grafickým hardware počítače. Původní plugin se však postupně vyvinul do podoby knihovny pro technologii WebGL. Další možností zobrazení 3D na webu je tzv. GeoVRML [GeoVRML(2002)], což je rozšíření pro jazyk VRML pro podporu geografických aplikací. Skupina vznikla v roce 1998 s jasným cílem, kterým bylo využití jazyka virtuální reality pro zobrazení geografických dat.

Kapitola 4 Srovnání použitých technologií K porovnání technologií jsem využil komplexní sady pravidel, které jsem postupně sestavoval podle různých zdrojů literatury a podle svých zkušeností. Porovnání je složeno ze dvou částí podrobnějšího popisu a porovnávací tabulky. Textové porovnání uvádí především obsáhlejší celky, ke kterým je třeba dodat více informací a nepostačuje pouze krátký záznam v tabulce. V podkapitole 4.30 je pak uvedena tabulka, která obsahuje porovnávací kritéria, která jsou stručná a není třeba je doplňovat či jinak komentovat. Tato kapitola již také obsahuje doplnění kritérií z praktické části této práce. 4.1 Záměr využití technologie Technologie VRML byla zpočátku navržena pro popis 3D scén, objektů a virtuálních světů, které mohou obsahovat aktivní logické prvky. Možnosti využití této technologie jsou: reklamní, výukové či herní účely, tvorba rozsáhlých světů i geografických modelů atd. Google Earth byla původně navržena pro zobrazování map při pohledu na Zeměkouli. Později se přidala možnost zobrazování 3D budov, jejich vkládání od běžných uživatelů či navigace celým 3D městem. Technologie Flash3D, tedy její knihovny pro podporu 3D byly vytvořeny pro přidání třetího rozměru, který umožňuje vyvíjet atraktivnější aplikace. Do té doby bylo ve Flashi přístupné pouze prostředí 2D. Technologie původně sloužila pro animace, hry, výukové materiály a reklamu. Nyní se technologie snaží proniknout i do světa 3D virtuální reality. WebGL jako jediná ze zmíněných technologií byla navržena jako low-level JavaScriptové API, které nám prostřednictvím skriptů umožní přímo přistupovat k výkonu grafické karty. Nejedná se tedy o deklarativní jazyk jako VRML či knihovnu pro přidání rozměru, ale o novou technologii, která má uživateli zobrazit 3D objekty počítané grafickou kartou přímo v prohlížeči. 9

10 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ 4.2 Dostupné knihovny a frameworky 1 Obecně platí, že frameworky, jakožto části usnadňující práci programátora, existují téměř na jakoukoli technologii. Pro VRML ovšem k vytvoření virtuálního světa nejsou potřeba. Z vlastních zkušeností lze říci, že vytvoření modelu a jeho publikování pomocí této technologie vyžaduje pouze seznámení se se základními prvky a konstrukty tohoto jazyka. Složitější logické celky se programují pomocí jazyka Java Script, kde už by se o použití frameworku dalo hovořit, v základu však není potřeba. Google Earth umožňuje pouze vložení modelu a jeho zobrazení, přičemž model musí být co nejjednodušší, aby nevyužíval příliš mnoho prostředků pro své vykreslení. Programátor zde nemá možnost 3D model budovy programovat a vytvářet logické celky. Naopak pro technologie jako je Flash3D či WebGL může být použití frameworku výraznou výhodou. Pro technologii Flash existuje několik různých knihoven pro 3D zobrazování, které uvádím v kapitole 1 a které pomohou se sestavením scény. Důležitým parametrem je možnost parsování nějakého přijatelného formátu, který umožňuje exportovat 3D modelovací software. V našem případě jsme využili možnost parsování XML formátu Collada. Stejnou roli hrají frameworky u technologie WebGL. Zde je k dispozici několik variant, viz literatura [Giles(2011b)], každá má nějaké výhody a nevýhody, ale vždy umožní lépe a rychleji využít sílu této technologie. 4.3 Publikování 3D modelu Publikování 3D modelu je u technologií poměrně snadný proces. U VRML lze model prohlížet pomocí webového prohlížeče, stejně jako technologii WebGL nebo Flash. Nabízí se tedy možnost sdílet model pomocí datového úložiště, které je veřejně přístupné pomocí webových služeb. U technologie Flash je nutné před publikováním projekt se scénou zkompilovat do formátu swf, který poté již načte Adobe přehrávač a zobrazí tak scénu uživateli. Odlišný postup nabízí technologie Google Earth, která již z popisu obsahuje pouze modely reálných staveb. Ty navíc musí být do map umístěny co nejpřesněji. Google proto nabízí dvě varianty publikace. První variantou je sdílení modelu pomocí tzv. 3D Warehouse [Google(2011b)], což je galerie 3D modelů. Nahrát lze cokoli. Ostatní uživatelé si model mohou stáhnout a zobrazit. Model ale není přístupný bez toho, aniž by si ho uživatel ručně stáhl do svého počítače. Druhou variantou je vložení modelu do vrstvy Google Earth. Zde je však součástí i proces schválení, kde je ručně schvalována každá budova podle mnoha kritérií (přesnost modelu, umístění, reálnost, atd). Tento proces je poměrně delší, trvá cca 8 dnů, poté se však model zobrazuje ihned všem uživatelům přímo v aplikaci Google Earth. 4.4 Potřeba dodatečných instalací pro zobrazení modelu Jedinou technologií, která nevyžaduje dodatečné instalace, je technologie WebGL. Tato technologie umožňuje prohlížení 3D modelů přímo v prohlížeči prostřednictvím HTML verze 5 a 1 Slovem frameworky se v této práci myslí nadstavby (též soubory knihoven), které představují ucelené struktury pro podporu programování v dané technologii. Mohou tak obsahovat řešené problémy ve formě návrhových vzorů, další knihovny či podpůrné programy.

4.5. INTEGRACE MODELU S OKOLÍM 11 elementu <canvas>. Podmínkou zůstává pouze podpora WebGL samotným prohlížečem. Technologie VRML požaduje, stejně jako Google Earth instalaci pluginu do webového prohlížeče (např. plugin Cortona [Parallel Graphics Ltd.()]), který nám dovolí ve VRML 3D model zobrazit. Uživatel si může případně nainstalovat do svého počítače samostatnou aplikaci, umožňující další výhody. Je zde ovšem zapotřebí instalace nového software. Technologie Flash umožňuje prohlížení pomocí tzv. Flash Player [Adobe(2011)], pokud možno aktuální verze. Tento přehrávač ovšem většina uživatelů v prohlížeči má, neboť ho využívá i mnoho jiných služeb, ne pouze pro 3D zobrazování. Dá se tedy říci, že díky rozšířenosti této technologie by neměl být problém se zobrazením modelu, neboť většina uživatelů přehrávač pravděpodobně již má. 4.5 Integrace modelu s okolím V tomto ohledu jednoznačně vítězí technologie od společnosti Google. Jako jediná obsahuje celý svět, rychle přibývají nové modely, ale i celá města. Budovy se nyní dají modelovat velice rychle s využitím produktu Google Street View a SketchUp a uživatel tak má možnost pohybovat se po zeměkouli a sledovat virtuální budovy přímo v aplikaci. Ostatní technologie tuto možnost nenabízí, i když jazyk VRML obsahuje možnost vytvářet složité a rozsáhlé světy, ve kterých se uživatelé pohybují prostřednictvím svých avatarů. Technologie nabízí interakci v podobě her, ve kterých se avataři scházejí a interagují. Nabízí také tvorbu logických her či naučných celků. Interakce s okolím je v tomto bodě splněna. Technologie Flash a WebGL obsahují možnosti vytvářet hry podobně jako VRML, ale vzhledem k tomu, že se jedná o nové technologie, je tato interakce na vyšší úrovni. WebGL dovoluje programovat celé hry tak, jak je známe v klasické offline podobě již několik let. Stejně tak tomu je ve Flashi s tím rozdílem, že je technologie o poznání pomalejší a složité modely, které se budou zobrazovat, budou mít značný vliv na rychlost a plynulost celé scény. 4.6 Možnosti optimalizace dat Obecně platí sada pravidel, kterými by se měl grafik řídit při modelování objektů. Jedná se především o co nejnižší počet trojúhelníků, použití textur pro složité objekty, textury v POT 2 tvaru, omezení průhlednosti apod. Technologie Google a její program SketchUp sám nabízí při publikování modelu odstranění neviditelných částí a tím částečnou optimalizaci modelu. V Google Earth je navíc třeba odstranit z modelu vnitřek, čímž se v našem případě ušetří mnoho polygonů a výpočetně je tak model méně náročný. Ostatní technologie tuto možnost nemají a záleží tak kvalitě a složitosti samotného 3D modelu. Samozřejmostí při optimalizaci by mělo být užití textur v patřičných rozlišeních, což ostatně platí pro všechny technologie. VRML navíc nabízí možnosti definovat objekt a poté ho několikrát užívat, tzv. DEF a USE. Podporuje využití prototypů a také LOD pro optimalizaci při prohlížení dat. 2 POT nebo-li Power Of Two je tvar, ve kterém se textura nachází, pokud její rozlišení odpovídá mocninám čísla 2.

12 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ Pokud chceme zobrazit budovu, či složitější objekt v technologii Flash, bylo by vhodné využít textur a stínování namísto složitého modelování objektu. Flash, jak blíže uvádím v kapitole číslo 2.34 - Omezení technologie Flash, není schopný zvládnout velké množství dat (tisíce až desetitisíce trojúhelníků). Technologie, pokud požadujeme při renderování kvalitu, je příliš pomalá a snadno nám zahltí systém. Konkrétní optimalizační techniky jsou např. nastavení scény na nižší kvalitu, použití rychlejšího renderovacího algoritmu, využití POT textur či vypnutí přesnosti textur. Některé techniky však z našeho pohledu nelze použít, pokud chceme opravdu kvalitně vypadající 3D model. Některé další techniky pro zrychlení výpočtů se nachází v literatuře [Lively(2010b)]. Naopak technologie WebGL nám díky renderování přímo pomocí grafické karty umožňuje zobrazit složitá data v celku bez problémů a při vysokých hodnotách FPS. U této technologie, která se stále velice rychle vyvíjí, se dá navíc stále očekávat zlepšování a zrychlování výpočtů a zpracování složitých dat. 4.7 Objektové programování Jazyk VRML je, jak již bylo uvedeno, deklarativní. O objektovém programování by šlo uvažovat pouze v rámci JavaScriptu, kterým lze docílit logiky uvnitř VRML [Žára(1999)]. Technologie Google neumožňuje programově zasáhnout do 3D modelu logikou bohužel vůbec. WebGL a Flash při použití knihoven C3DL a Papervision3D objektové jsou. Obě tyto knihovny nám umožňují psát kód programu pomocí objektů, ovšem samotné WebGL, aniž bychom použili zmíněný framework (nebo některý další) objektové není, protože, jak již bylo zmíněno, je založeno na technologii OpenGL ES. Při použití frameworků se tedy otevírá možnost programovat objektově pomocí standardních konstrukcí jazyka, dědičnosti, a dalších. V technologii Flash při použití Papervision 3D programátor vytváří scénu pomocí ActionScripu [Grossman Huang(2006)Grossman, Huang], aktuální verze 3, což je objektově orientovaný jazyk pro aplikace vyvíjené pro prostředí Flash. ActionScript vychází z jazyka ECMA Script. Tento typ jazyka nám dovoluje využívat události, programovat interakci a vstup od uživatele, animace, využití LOD, ořezávání scény a mnoho dalšího. 4.8 Funkcionalita v prohlížečích Technologie VRML nabízí možnost zobrazení v klasickém webovém prohlížeči pomocí stažených pluginů. V literatuře [Šrám(2010)] uvádím testované prohlížeče a potřebné pluginy a jejich vyhodnocení. U technologie Flash se jedná opět pouze o dodatečný Flash Player plugin, který nám zaručí spuštění naší 3D prezentace. Pluginy pro Flash existují pro všechny dostupné prohlížeče, takže není problém model zobrazit kdekoli. Veliká rozšířenost je však pro tuto technologii plusem, který ji v tomto srovnání upřednostňuje. O poznání horší situace nastává při použití technologie WebGL a to z důvodu, že se jedná o novou technologii, která nedávno dosáhla verze 1.0. Oficiální zdroje [Illusoft(2007)] uvádí,

4.9. PROGRAMOVACÍ NÁROČNOST 13 že je zapotřebí používat prohlížeče typu Mozilla Firefox, Google Chrome či Apple Safari. Internet Explorer bohužel zatím neprojevil zájem spolupracovat s touto technologií. Další úskalí se nachází v rychlém vývoji, který způsobuje částečnou nefunkčnost starších dat a jejich výukových pásem. Další problém je v použití frameworků, přičemž různé frameworky pracují správně na v různých verzích zmíněných prohlížečů. Snadno se tedy stane, že virtuální budova je správně zobrazena v jednom prohlížeči, ale v některém jiném je zobrazena s chybami, nebo vůbec. Do budoucna však lze předpokládat ustálení situace a vyřešení nynějších nedostatků. Technologie Google Earth také podporuje možnost instalace pluginu a zobrazení dat v prohlížeči. Podporované prohlížeče podle oficiální literatury [Google(2011e)] jsou: Firefox, Internet Explorer, Google Chrome, Safari a Flock. 4.9 Programovací náročnost V technologii VRML lze vytvořit velice složité konstrukce v podobě her, nebo logických celků avšak tato logika se programuje pomocí JavaScriptu. VRML samo o sobě představuje pouze deklarace objektů, materiálů, primitiv a dalších, které lze poměrně jednoduše skládat dohromady a náročnost je tak poměrně nižší. Flash a WebGL díky frameworkům nabízí možnost programovat na vyšší úrovni abstrakce a proto pro zkušené programátory není problém zvládnout základy technologie rychleji, než pokud by framework nepoužili. Pokud je programátor zkušený v oblasti OpenGL, není problém psát kód scény v čistém WebGL, ovšem zde narážíme na problém s načítáním objektů, kde tato technologie v současnosti nativně podporuje pouze vstup ve formátu JSON. V nynější době tuto možnost modeláře běžně nenabízejí, a protože je technologie stále ve vývoji, nelze se na tento formát plně spolehnout. Pokud tedy máme vytvořený virtuální model a chceme vytvořit prezentaci ve WebGL, je dobré využít některý framework, který umí zpracovat data ve formátu OBJ či Collada. Technologie Flash je na trhu déle, a proto lze očekávat větší podporu ze strany frameworků i nejrůznějších doplňkových knihoven. Na různých internetových diskusích lze vypátrat, že novinka ve formě AC3 je oproti AC2 poměrně složitější, platí však, že nám dovoluje vytvářet dokonalejší a složitější logiku, než verze předchozí. AC3 je také o poznání rychlejší, dovoluje dokonalejší zpracování událostí, XML souborů či vylepšenou architekturu pro práci s obrazovými elementy. Celkově je programovací náročnost při použití frameworků srovnatelná s technologií WebGL. 4.10 Vývojové nástroje pro tvorbu scén VRML nabízí tzv. VRML pad, což je jednoduchý, uživatelsky oblíbený program. Dovoluje nám automaticky dokončovat definice, umožňuje kontrolu vytvořeného kódu či rychlý náhled objektu. Samozřejmostí jsou další vlastnosti, které programátor běžně zná z ostatních IDE. Tento jednoduchý program však není freeware a uživatel si musí zakoupit licenci. Pro Google Earth existuje pouze tzv. Google SketchUp, což je editovací program, ve kterém lze vytvářet modely, upravovat je, texturovat, ale ne psát kód. Jedná se tedy spíše o modelovací nástroj, prostřednictvím kterého lze model rychle publikovat se všemi potřebnými informacemi.

14 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ Zajímavé prostředí nabízí Adobe Flash. Jedná se o tzv. Flash Builder, k dispozici je pro studenty zcela zdarma, pro další využití je k dispozici k vyzkoušení na 60 dní. Je to velice dobře propracované prostředí pro vývoj aplikací pod Flashem. Nejzajímavější z našeho hlediska je možnost tvorby ActionScript projektů, možnost jejich kompilace, přidávání knihoven a balíčků. Toto prostředí je podobné běžným IDE typu Netbeans či Eclipse, velice dobře se v něm pracuje a nabízí opět technologie, které při psaní kódu programátorovi pomáhají (různé našeptávače, kontroly chyb, testování, debugování apod). Vývojové nástroje pro technologii WebGL naopak příliš rozšířená nejsou. Při použití frameworků to ale není nezbytná podmínka pro vytvoření kvalitní scény a využít tak lze běžná editovací prostředí či IDE typu PSPad, Vim či Netbeans. 4.11 Navigace uživatele scénou V tomto porovnání vítězí technologie VRML a Google Earth. U Google Earth je pohyb scénou předem definován prostředím aplikace, pohyb uživatele je velice intuitivní a snadno naučitelný. Lze využít standardní vstupy, nelze však programově do ovládání zasáhnout. Google Earth nabízí i možnost přepnutí do pohledu ze země, tedy jakoby uživatel chodil kolem objektu. VRML nabízí základní možnosti pro pohybování uživatele scénou. Každý prohlížeč definuje své druhy pohybů, většinou se jedná o chůzi, létání apod. V některých případech lze avatara i zobrazit. Programátor má možnost vložit vlastní viewpointy, mezi kterými VRML samo plynule přechází pomocí interpolace pohybu kamery. VRML také samo počítá kolize, takže nedovolí projít stěnou či vstoupit do nerovnosti terénu. U technologií Flash a WebGL je situace poněkud jiná. Vlastnosti popsané u VRML zde má na starost programátor, čímž dostává větší prostor pro tvorbu vlastností dané scény. Ovšem na druhou stranu tento přístup vyžaduje mnohem více programování a určování omezení, než tomu je u jazyka VRML. Lze tedy naprogramovat téměř vše, od avatara, po virtuální procházky i fyzikální vlastnosti objektů [Hedman(2011)] až po detailně propracované hry. Při použití knihovny C3DL pro WebGL jsme se setkali s problémem počítání kolizí, kde v oficiální dokumentaci tato metoda neexistuje, v implementaci knihovny však ano. Ovšem v samotné knihovně je třeba se více zorientovat a pečlivě kolize nastudovat před jejich využitím, neboť v příkladech není tato vlastnost popsána vůbec. Technologie Flash nabízí několik druhů kamer, které umožní pohyb po scéně. Základem je tzv. Camera3D, u které lze mnohé vlastnosti nastavit. Velkou výhodou může být použití dalších rozšiřujících doplňků, které nám umožní plynulé přechody, zoomování, jako např. doplněk GreenSock TweenMax [Doyle(2011)] a různé speciální efekty při prohlížení objektů ve scéně. 4.12 Podpora pro vývojáře ve formě výukových materiálů Největším objemem materiálů je díky své době existence bezpochyby technologie VRML. Materiály existují ve formě výukových pásem neboli tutoriálů, návodů pro řešení konkrétních problémů či kompletních dat i s ukázkami a funkčních kódů, ze kterých programátor může čerpat inspiraci.

4.13. EXPORT DAT Z MODELÁŘE 15 Technologie Google Earth je ve světě poměrně hodně rozšířená a proto také není problém nalézt návody na tvorbu budov veřejně dostupné pomocí internetu [O Netu(), Google(2011d)]. V programu od společnosti Google, který je však k tvorbě modelů určen je již integrována velice dobrá a interaktivní nápověda, která může mnoho postupů při tvorbě modelu usnadnit. Pokud chceme scénu zobrazit pomocí WebGL, máme k dispozici velice dobré materiály z literatury [Giles(2011b), Funnell(2011), Mozilla(2011)], kde najdeme podrobně rozepsané možnosti frameworků, příklady čistého WebGL, rady a postupy pro správné zobrazení scény. Bohužel podobně kvalitní literaturu pro tuto technologii je problém nalézt. Mnohdy uvedené příklady nefungují, neboť používají starší verze knihoven, nebo se mezi tím změnila specifikace. Nejlepším řešením je proto výběr některého frameworku, na jehož oficiálních stránkách poté najdeme konkrétní příklady (ty by měly být aktuální s tím jak se framework vyvíjí) s podporou oficiální dokumentace. U technologie Flash je situace poměrně lepší a výukových materiálů je k dispozici dostatek. Na oficiálních i neoficiálních webových stránkách [Lindquist(2010), Brichta(2007), Brimelow(2010), Feronato(2009)] nalezneme mnoho příkladů, návodů a rad. Situace se sice zkomplikovala s příchodem nové verze ActionScriptu, protože návody mohou být pouze pro starší verze a ukázky nemusí vždy fungovat, ale rychle vznikají nové, případně starší návody bývají aktualizované i pro nové verze knihoven. 4.13 Export dat z modeláře V této části se budeme zabývat exportem z modeláře Blender verze 2.49. Pro VRML existuje v tomto software integrovaná funkce pro export dat do formátu wrl, ovšem tento exportér má problém s texturami, které musí tvůrce scény přidat dodatečně, úpravou exportovaných dat. Další možností je instalace skriptu BS exporter, který umožňuje i exportování textur, které ale musí být mapovány pomocí UV souřadnic. Pro další zmíněné technologie je možné data exportovat opět pomocí dodatečného skriptu z literatury [Illusoft(2007)] do formátu Collada verze 1.4, který je založený na XML a velice dobře se s ním dále pracuje. Velkou výhodou je i možnost tato data zobrazit v technologiích WebGL, Flash a je možné ho importovat i do Google Earth. Formát Collada v sobě nese i údaje o UV souřadnicích textur, avšak zde si musíme dát pozor na cestu k jednotlivým texturám a ve výsledném souboru tyto cesty případně upravit. Samozřejmostí jsou i další varianty, což platí především pro WebGL. Existují další skripty, které umožní export do formátu JS, JSON či XML pro WebGL. Obě tyto varianty JS i XML se nám podařilo úspěšně exportovat, ovšem dále nastal problém s jejich zobrazením, protože tyto formáty podporují pouze některé frameworky v některých verzích. Navíc vývoj skriptů stále probíhá, takže kvalita exportu dosud není tak kvalitní. Celkově bychom při použití technologie WebGL doporučili formát Collada, který je nejvíce přehledný a máme jistotu, že se nám ho podaří správně zobrazit. Pro technologii Flash platí totéž, exportovat je možné přímo do ActionScript verze 3 [Rosengain.com(2008)], ovšem i zde bychom tuto variantu z počátku nedoporučovali, neboť je stále ve vývoji.

16 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ 4.14 Práce s daty modelu Po úspěšném exportu dat z modeláře se můžeme setkat s potřebou, dodatečně tato data upravit či zpracovat. Jak již bylo zmíněno, nejvhodnější je z našeho pohledu XML formát Collada. Pro příklad uvedeme změnu cest k texturám, které jsou v tomto formátu velice přehledně zaznamenány. Stačí tak změnit několik řádků s cestami k souboru, což nám dále může usnadnit mnoho práce při zobrazování dat. Pokud bychom se rozhodli exportovat data do formátu OBJ nebo přímo do JavaScriptu, tak přímá editace nebude tak přehledná a komfortní, jako u XML formátu Collada. U formátu VRML je export dat z modeláře kvalitní, a to i při použití integrovaného skriptu pro export do VRML. Obecně je formát VRML dobře strukturován a programátor se v něm může dobře a rychle zorientovat a pracovat s daty i bez potřeby dodatečného software pro tento formát. Příkladem může být ruční doplnění textur či optimalizace dat, kterou za nás modelář automaticky neprovede. Častým zásahem bývá užití DEF a USE či použití prototypů, změna orientace ploch a editace nastavení textur. Obecně je formát VRML založen na skládání z jednotlivých částí, tzv. uzlů. Ty mohou mít další uzly a parametry a lze u nich využít i dědičnost (transformací, materiálů apod.) známou z objektového programování. To vše lze rychle po exportu dat měnit přímo ve výsledném formátu. 4.15 Velikost vkládaného modelu Pokud máme zájem zpřístupnit náš model světu ve smyslu jeho umístění do vrstvy Earth, musí model splňovat mnoho kritérií, především na složitost modelu. Model by tak neměl být příliš detailní, detaily by měly být znázorněny texturami, velikost modelu by měla odpovídat měřítku atd. Kompletní sada kritérií je popsána v literatuře [Google(2011c)]. Z hlediska počtu trojúhelníků byl model kostela, který zde používáme, Googlem ohodnocen jako středně náročný. Dle požadavků byl model předem upraven ve smyslu odstranění objektů (varhany, oltář) a vnitřku kostela. VRML i WebGL technologie jsou schopné zvládnout v reálném čase zobrazení i velkých modelů z desetitisíců trojúhelníků. Konkrétně zde použitý model měl ve VRML cca 19000 polygonů a zobrazoval se plynule při 60FPS bez jakýchkoli problémů. Totéž se dá očekávat i u technologie WebGL. Kde však narazíme na problém, je technologie Flash. Jak popisuji v kapitolách níže, na velikosti modelu velice záleží a již při několika tisících polygonů začíná být scéna výrazně pomalá až nepoužitelná. Kvalitu scény lze snížit, stejně jako lze snížit kvalitu renderování objektu. Zobrazení se však stane velice špatné se spoustou chyb, které scénu diskreditují. Podle literatury [Winder Tondeur(2009)Winder, Tondeur] by se měl tvůrce vždy snažit udržet počet polygonů ve scéně pod hranicí 3000. Obecně lze tedy říci, že pro velké a rozsáhlé modely jsou vhodné pouze technologie VRML a v budoucnu nový standard WebGL.

4.16. OFICIÁLNÍ DOKUMENTACE 17 4.16 Oficiální dokumentace Velice dobrou oficiální dokumentací se může pochlubit Google [Google(2011a)]. U tak velké společnosti se to dá očekávat. Pravdou je, že dokumentace je velice kvalitní, obsahuje mnoho návodů, typů a rad, které jsou doplněny ze zpětné vazby uživatelů a častých otázek. Dokumentace je mnohdy interaktivní a napovídá podle toho, co tvůrce scény právě dělá. U Flash technologie a frameworku Papervision3D [Papervision3D(2007)] existuje také kvalitní dokumentace a literatura [Winder Tondeur(2009)Winder, Tondeur, Lively(2010a)], stejně jako u WebGL a C3DL [Bishop(2011)]. WebGL sice stále ve vývoji, ale obsahuje již nyní dostatek informací pro tvorbu kvalitní scény s mnoha prvky a událostmi, které vyžadujeme. Nevýhodou jsou pouze některé nefunkční příklady a návody, což je dáno rychlým vývojem obou technologií. Může se tedy lehce stát, že nalezená data nebudou funkční, proto nalezení kvalitní dokumentace a dat může být na delší dobu. Vzhledem k výsledkům, které lze s technologiemi dosáhnout je to však přijatelné minus. Pro VRML není problém na veřejně dostupné literatuře nalézt mnoho verzí dokumentace, která do detailu popisuje jednotlivé celky tvorby scény, gramatiku jazyka, definice a stavební prvky. Kvalitní dokumentaci pro tento jazyk lze nalézt velice snadno a rychle. 4.17 Tvorba her a logických celků Ve všech zmíněných technologiích lze vytvářet logické prvky a z nich poté i hry. Flash byl pro tento účel přímo stvořen a knihovny pro 3D pouze rozšiřují jeho pole působnosti i do virtuálního 3D světa. Programování je možné docílit pomocí ActionScriptu, popsaného v kapitolách výše např. s využitím knihoven třetích stran pro kolize, podporu fyziky či animací. VRML také nabízí možnost tvorby her, a to pomocí jazyku Java nebo Javascript, který do VRML lze vložit jako tzv. ECMA script [Žára(1999)]. S jeho pomocí funguje velice mnoho VRML aplikací dostupných na internetu, na kterých uživatel může vidět, co vše se dá v takové technologii dokázat včetně simulace fyzikálních jevů, apod. WebGL je technologie, stvořená přímo pro 3D, takže logické celky a hry jsou od počátku součástí vývoje. Existují ukázky, které věrně simulují částicové systémy, pohyby vody, viz obrázek 4.1 či velice propracované jízdy automobilem [GLGE(2011b)]. V technologii Google Earth nelze přímo říci, že by šly vytvořit hry s 3D budovou. To samozřejmě nelze, ovšem hry jako je např. nedávno spuštěná simulace průletu vrtulníkem, či projížďka virtuální dodávkou, takové logické hry vytvořit lze. Tvoří se také pomocí Javascriptu a API přímo pro Google Earth. 4.18 Bezpečnost V literatuře [Giles(2011b)] je uvedeno několik otázek ohledně bezpečnosti používání JavaScriptu, který nám prostřednictvím prohlížeče otevírá cestu ke grafické kartě v technologii WebGL. To nebezpečné samo o sobě není, ačkoli to podle literatury může vést k potenciálním bezpečnostním dírám. Vývojáři se zde vyjadřují v tom smyslu, že nebezpečí může být způsobeno škodlivým kódem aplikace, která poté svými výpočty kompletně zahltí výkon grafické

18 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ karty, tzv. DOS. Aplikace běžící pod Windows by však neměla vést k pádu systému, neboť systém umí sám v takovém případě resetovat grafickou kartu a vše tak vrátit do původního stavu. U Apple to již může vést k zamrznutí obrazovky a u OS Linux to záleží na konkrétní konfiguraci a ovladačích. Další bezpečnostní díra se objevuje v podobě škodlivého kódu, který by mohl útočníkovy pomoci shlédnout ostatní části obrazovky. Riziko je popsáno v literatuře [Giles(2011a)] či [Microsoft(2011)] a jedná se o tzv. kradení grafické paměti. Jde se o stav, kdy v prohlížeči běží aplikace, využívající technologii WebGL a vedle toho běží jiné aplikace, které také využívají výkon grafické karty k vykreslení oken ostatních aplikací. WebGL však může obsahovat škodlivý kód, který data ze sdílené paměti grafické karty přečte a odesílá útočníkovi. Popsané chyby, ačkoli již byla opravena, využila společnost Microsoft, která dlouhodobě říká, že WebGL není bezpečnou technologií [Microsoft(2011)]. V případě Google Earth tyto otázky nejsou aktuální, protože do 3D modelu nemáme možnost zasáhnout a ve Flashi musíme vždy ActionScript zkompilovat pro zobrazení v přehrávači a navíc zde není přímý přístup ke grafické kartě. Může se však stát, že velká scéna také zabere velkou část výpočetního výkonu procesoru. Pokud bychom hovořili o bezpečnosti dat z hlediska duševního vlastnictví, potom je nejlépe chráněna technologie Flash3D. Existují sice dekompilátory, ovšem představují krok navíc při získávání zdrojových kódů a ne vše se podaří odhalit. Ostatní technologie pracují s textovými zdrojovými soubory veřejně přístupnými, takže není problém kód číst. Google Earth naopak obsahuje pouze model, lze však v osobním účtu nastavit, zda umožníme ostatním jeho stažení nebo ne. 4.19 Animace Ve VRML lze animace vytvářet pomocí prvků, přímo specifikovaných ve VRML jako jsou Interpolator, Route, Sensor a další uzly, nebo pomocí propojení s Javascriptem pro hry a jiné logické prvky. Jde vcelku o jednoduchou proceduru, kde objektu nastavíme několik klíčových pozic, tzv. key-frame, mezi kterými poté VRML samo vypočítá dráhu pohybu a objekt přemisťuje, což je základ jednoduché animace. Stejně tak lze měnit barvu nastavením klíčových hodnot, mezi kterými technologie interpoluje a vypočítá přechodové barvy. V technologii Flash lze programovat animace přímo v ActionScriptu, který poté jednoduše zkompilujeme a výsledek publikujeme na web. Máme k dispozici sadu událostí, na které můžeme v programu reagovat. Tuto variantu událostí ve formě událostí a sensorů ostatně nabízí i VRML. Flash podporuje zadávání animací ručně pomocí proměnných, určování rychlosti, sílových bodů apod., či pomocí knihoven tweener [Doyle(2011)], ve kterých lze jednoduchým způsobem specifikovat, co se má s objektem provádět, kam se má přemístit, za jaký čas se má operace provést. Při použití WebGL opět programujeme scénu přímo v kódu aplikace. Zde máme téměř neomezené možnosti. Rychle se vyvíjející technologie nám nabízí nástroje pro takřka jakoukoli animaci. Dobrou možností je i export animace přímo z modeláře ve formátu Collada, kterou máme možnost zde využít. Ovšem pozor, ne všechny frameworky, které použijeme,

4.20. MULTIMEDIÁLNÍ OBSAH 19 nám dovolují v aktuálních verzích animace vytvářet! Naproti tomu Google Earth animace neumožňuje v modelu využít vůbec. Tedy například animaci dveří tak, jak je naprogramována ve VRML, zde neuvidíme. 4.20 Multimediální obsah Multimediálním obsahem ve virtuální realitě máme možnost rozšířit vjem koncového uživatele o další rozměr. Jedná se o doplnění virtuální scény o další rozšiřující prvky, jakými jsou např. audio nebo video. Technologie VRML opět podporuje obě tyto varianty. Jednoduše lze nadefinovat akce, při kterých se spustí zvuk či přehraje nějaký klip. Zvuky se mohou spouštět ve smyčkách s různými parametry. VRML dovoluje přehrát formáty jako wav, midi, či au. Nepodporuje však formát mp3. Pokud bychom měli zájem o přehrání videa, i to je možné pomocí tzv. movie textury, která se uzlu přiřadí jako obyčejná textura, ovšem s jinými parametry, mezi kterými bude i url na požadované video ve formátu MPEG (či sekvence GIF). Technologie Flash také podporuje přehrávání zvuků a video textury, např. ve formátu flv, nebo i jako stream. To obsahovala už z počátku verze pro 2D, ve které se vytvářely hry či reklamy. Jak již bylo řečeno v předešlých kapitolách, 3D tomuto multimediálnímu obsahu přidalo třetí rozměr. Všechny prvky z 2D pro multimediální obsah máme možnost použít i zde. WebGL také obsahuje tyto možnosti. Umožňuje navíc i možnost tzv. render to texture, kde již vytvořený virtuální objekt mapujeme do textury jako video. Do WebGL obsahu se vkládá prostřednictvím propojení s HTML5 elementem <video>, který poté voláme z WebGL skriptu a dále s ním pracujeme. Např. ho lze mapovat jako 2D texturu na kostku, jako je to znázorněno v literatuře [Shepherd(2011a)]. V technologii Google Earth musí být textury fotorealistické a animovat je a přidávat video obsah zde není při požadavku umístění do vrstvy Earth povoleno. 4.21 Osvětlovací modely, světla Jazyk VRML nám dovoluje využít několik typů světel, jimiž jsou: směrové světlo (bez počátku s konstantní intenzitou záření) a bodová světla, tzv. Point Light (všesměrové světlo s nastavitelnou intenzitou) a Spot Light (směrový reflektor nějakého rozsahu záření) [Žára(1999)]. Bohužel VRML neumí počítat vržené stíny, nebo počítat intenzitu po odrazu světla od textury. Pokud použijeme texturu jako obrázek, musíme počítat s konstantním osvětlením. VRML obsahuje při použití materiálu Phongův osvětlovací model, kde je barva objektu počítána ze tří složek: ambientního, odraženého a rozptýleného osvětlení. Technologie WebGL nám dovoluje opět při použití knihoven využít různé typy světel. Konkrétně C3DL umožňuje do scény přidat podobné světla jako je to u jazyka VRML, tedy tzv. Positional Light, které má pouze polohu a parametr útlumu světla. Dále směrové světlo, které nemá polohu ale pouze směr a posledním je Spot Light, které má opět polohu, směr a definovaný kužel, ve kterém vyzařuje. C3DL nám též jako VRML dovoluje využít 3 složky: ambientní, odražené a rozptýlené osvětlení, přičemž ambientní složku nastavujeme globálně pro celou scénu bez vytváření nového objektu typu světlo. Vzhledem k výpočetní náročnosti

20 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ tato knihovna nepodporuje vrhání stínů. Pokud bychom se rozhodli pro čisté WebGL, je dobré připomenout, že WebGL samo o sobě nemá podporu pro osvětlování a vše si tedy musíme napsat sami [Shepherd(2011b)]. Flash a Pepervision3D nabízí pouze tzv. PointLight3D s možností nastavení viditelnosti světelného objektu či otočením směru vyzařování. S dalšími doplňky, např. z literatury [Zupko(2008)] lze dosáhnout realistického vrhání stínů či dalších věrných efektů zobrazení scény. Mějme však na paměti, že tyto efekty budou scénu zpomalovat, neboť jsou výpočetně složité. Google Earth nedovoluje přidat své vlastní osvětlení do modelu, takže v tomto porovnání nelze s ostatními technologiemi srovnávat. Lze jen dodat, že Google Earth osvětlení je všude konstantní a ve scéně se nepočítá s vrženými stíny jednotlivých objektů. 4.22 Typy stínování Všechny srovnávané technologie kromě Google Earth obsahují několik možností stínování. VRML jakožto starší technologie podporuje pouze stínování konstantní, Phongovo a Gouardovo [Žára(1999)]. Technologie Flash přidává navíc (při použití knihovny Papervision3D) stínování typu Cartoon nebo také Cell [Lively(2010a)], což je typ stínování, využívaný při nefotorealistickém renderování objektů. Je ovšem třeba mít také definován reagující materiál [Pulkert(2010)]. Oproti tomu u technologie WebGL máme možnost naprogramovat si stínování jakékoli. Pokud se rozhodneme pro čisté WebGL toto není problém, protože musíme programovat kompletně celou scénu i se světly, základními tělesy (tzv. primitiva), kamerou atd. Při použití nějakého frameworku to záleží na našem výběru. Námi zvolená knihovna C3DL např. podporuje Cartoon, Standard, Gooch [Gooch et al.(1998)gooch, Gooch, Shirley Cohen], což je opět druh nefotorealistického renderování, často používaného v technických ilustracích. 4.23 Simulace mlhy, částicové systémy V technologii VRML je možné simulovat mlhu přímo pomocí uzlu Fog. Uzel obsahuje několik parametrů, kterými máme možnost scénu ovlivnit. Ve výsledku nám může pomoci ve scéně vytvořit více realistické prostředí či navodit požadovanou atmosféru. Pokud bychom chtěli zobrazi částicové systémy, jako simulaci ohně apod., museli bychom využít základní jednoduchá tělesa k vytvoření částic a poté naprogramovat chování mezi nimi, např. pomocí Javascriptu. Flash a technologie Papervision3D přímo obsahuje třídu pro práci s částicemi [Papervision3D(2011)] a umožňuje tak vytvořit zajímavé efekty záře, ohně, mlhy a jiných speciálních efektů. Další možností jak pracovat s částicemi je využít některou další rozšiřující knihovnu, kterých existuje mnoho. U WebGL, stejně jako v kapitole Typy stínování, lze říci, že pokud použijeme čisté WebGL a vše si budeme programovat sami, tak lze naprogramovat jakoukoli funkcionalitu, což platí i o částicích. Pokud však použijeme knihovny, např. C3DL [Bishop(2011)], máme k dispozici základní konstrukce, které můžeme využít k vytvoření kvalitních systémů, aniž bychom trávili

4.24. MOŽNOSTI INTERAKTIVNÍCH PROSTŘEDÍ 21 velice mnoho času jejich programováním od počátku. Zmíněná knihovna přímo uvádí jako jedno ze svých výukových pásem využití částicového systému i s vizualizacemi a podrobným návodem. Google Earth opět v tomto bodě srovnání nelze využít, neboť takové možnosti technologie nenabízí. 4.24 Možnosti interaktivních prostředí Interakci s okolím nemáme možnost v aplikaci Google Earth při vkládání modelu ovlivnit. V ostatních technologiích jsou přístupné techniky přímo pro podporu interakce, jako jsou události, sensory pro kliknutí myší, či přítomnost avatara v nějakém dosahu, časové sensory, počítání kolizí a další. Dá se říci, že všechny technologie umožňují interakci s virtuálním objektem, ovšem v Google Earth to není na tvůrci scény, ale na samotné aplikaci a jejích vývojářích. 4.25 Stupeň grafické prezentace Nejlepším stupněm grafické prezentace se může již nyní pochlubit jednoznačně technologie WebGL, která dovoluje vytvořit opravdu realistické objekty, simulace, pohyby s využitím shaderů, real-time raytracingu atd. a jejíž experimentální scény velice dobře shrnuje literatura [Chrome Experiments()]. Tento závěr je logický, protože zpřístupněním funkcí GPU máme možnost programovat scény, na které jsme zvyklí z počítačových her, které jsou v současnosti na velmi vysoké úrovni. Ukázka kvalitní scény, vytvořené pomocí WebGL z literatury [Hedman(2011)] se nachází na obrázku 4.1. Poměrně kvalitní scénu, ovšem s mnoha omezeními, lze vytvořit i pomocí technologie Flash. Pro složité modely ale bude technologie potřebovat i podporu ze strany GPU, která zatím není umožněna. Obecně je Flash solidní technologie, ve světě velice populární, ovšem vzhledem k neshodám mezi společnostmi jako jsou Apple a Adobe se tato technologie již nemusí dlouho na trhu v dosavadní míře udržet. Nižší stupně grafického zpracování představují Google Earth a VRML. U Google je to způsobeno především požadavky na 3D modely, jejich fotorealistické texturování, jednoduchost a další kritéria [Google(2011c)]. U VRML musíme jako u starší technologie počítat s tím, že zde nejsou dostupné takové zobrazovací možnosti a že se nám tak nepodaří vytvořit dokonale vypadající scény jako u novějších, modernějších technologií. 4.26 Velikost přenášených dat Při přenosu dat směrem k uživateli se ve VRML stahuje celý obsah, to znamená všechny potřebné wrl soubory, textury, případně zvuky a Javascript. Proto je dobré z hlediska optimalizace velkých modelů tyto soubory komprimovat, i když při dnešní rychlosti internetového spojen není přenos několika stovek KB problém. Stejný způsob funguje i u ostatních technologií, kdy se postupně načítají právě přenesené soubory. V GoogleEarth má model kostela 1.4MB, načte se tedy téměř ihned. U Flash

22 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ Obrázek 4.1: Simulace vody vytvořená pomocí technologie WebGL a WebGL je model složen, stejně jako u VRML z několika částí, které byly z modeláře exportovány do formátu Collada. Postupně se tedy zobrazí tyto části s texturami. Kostel bez vnitřního vybavení má při použití technologie WebGL cca 4.0MB a při použití Flash cca 2.8MB. 4.27 Hardwarové nároky Náročnost technologií na konfiguraci počítače samozřejmě záleží na velikosti a složitosti modelu, ovšem tím, že např. v Google Earth mohou být pouze jednodušší modely, nejsou nároky tak velké, jako např. u WebGL nebo Flash. WebGL i VRML obsahují hardwarovou podporu při renderování scény, což Flash zatím neobsahuje a proto je použití rozsáhlého modelu v této technologii obtížné. VRML nedovoluje vytvářet tak složité a pokročilé modely a vlastnosti, jaké nyní umožňuje WebGL, proto pro VRML teoreticky postačuje slabší konfigurace. To platí i z hlediska stáří technologie, kde u VRML máme prozatím větší pravděpodobnost, že se model podaří všude správně zobrazit. Ve WebGL máme možnost programovat věrné, opticky téměř dokonalé, ale zároveň složité scény a modely s různými fyzikálními vlastnostmi [Hedman(2011)], stínováním atd., ovšem pokud na zobrazení nemáme dostatek výkonu, objekty si neprohlédneme. 4.28 Složitost vytvoření virtuální prezentace Lze říci, že vytvoření prezentace nějakého modelu bude nejsnadnějším úkolem v Google- Earth při použití software SketchUp. Jednoduše postačí exportovat hotový model do formátu

4.29. VYUŽITELNOST TECHNOLOGIÍ DO BUDOUCNA A JEJICH VÝVOJ 23 Collada, případně ho upravit a prostřednictvím programu ho nahrát do galerie a čekat na schválení, které trvá cca 2 týdny. Střední obtížnost bude vyžadovat technologie VRML, protože se jedná o starší, i když schopnou technologii, ale stále vytvářenou pomocí deklarativního stylu s případným přidáním logiky pomocí Javascriptu. Exportovaný model lze upravovat fyzicky přímo ve výsledném formátu, který je dobře čitelný a dá se s ním rychle pracovat. Nejvíce náročné jsou technologie Flash a WebGL. Jednak se jedná stále ještě o novinky v oblasti virtuální reality a za druhé, scény musíme programovat. Lze si však vybrat z několika frameworků, které nám umožní objektové programování, nebo lze zvolit programování v čistém WebGL, stále však vytvoření prezentace v těchto technologiích zůstává pro nezkušené tvůrce poměrně složitým úkolem. 4.29 Využitelnost technologií do budoucna a jejich vývoj Nejnižší rozvoj aktuálně zaznamenává technologie VRML. Jedná se o velice dobrou technologii pro tvorbu virtuálních scén a světů na webu, ovšem doba jejího působení je již veliká a postupně ji nahrazují technologie ostatní. Zpočátku to bylo X3D, což je technologie pro 3D zobrazení založená na XML formátu. Nyní nastupují technologie Flash 3D nebo WebGL, které umožňují lépe využít potenciál grafických karet a výkonu procesoru počítače ke kvalitnějšímu zobrazení objektů a scén. Vývoj nových technologií probíhá velice rychle, zejména u WebGL, které se měnilo s postupem měsíců. I nyní tyto změny ve specifikacích, ve frameworcích, příkladech probíhají velmi rychle, proto se tato technologie prozatím nedá považovat za kompletní. Flash je na tom o něco lépe, protože technologie, konkrétně nyní knihovna Papervision3D existuje již od roku 2005/2006. Postupem času se samozřejmě stále vyvíjí, nyní pracuje již na 3 verzi programovacích skriptů a stále je co zlepšovat. Technologie Google Earth již není takovou novinkou, existuje již řadu let, ovšem stále se snaží držet krok s ostatními. Jak bylo uvedeno v kapitolách výše, nedávno Google odhalil novinku spolupráci map s WebGL, což přinese velké zlepšení a nové možnosti zobrazení a využití mapových podkladů. Z nynějšího pohledu se dá téměř s jistotou říci, že budoucí technologie pro zobrazení 3D virtuální reality budou WebGL na prvním místě a poté Flash spolu s Google Earth pro zobrazení map s využitím integrací 3D prostředí. 4.30 Další sledované parametry zvolených technologií Následující tabulka 4.1 popisuje některá další kritéria porovnání technologií 3, pro která není třeba uvádět podrobnější informace či další popis. Jejich vlastnost plyne přímo z názvu. 3 Srovnání bylo provedeno pro použité frameworky Papervision3D pro technologii Flash3D a C3DL pro technologii WebGL.

24 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ Google Flash3D WebGL VRML Earth Pouze POT textury ne ne ano ne Podpora α-kanálu v texturách ano ano ne ano Stupně detailu modelu LOD ne ano\cite{lit36} ve vývoji ano Podpora hardwarové akcelerace ano ne ano ano Možnost stereoskopického režimu ano ano ano ano Tvorba primitiv ano ano ano ano Nurbs křivky ne ne ano ano Předdefinovaný avatar ano ne ne ano Odebírání objektů mimo pohledový objem ano ano ano ano (frustum culling) Rozšíření pro tablety a mobilní telefony ano ano ano ne Integrace v HTML kódu ano ano ano ano Licence vlastní MIT MIT OS Tabulka 4.1: Další parametry srovnávaných technologií 4.31 Kvalita zobrazení a rychlost výpočtu scény První technologie, Google Earth nemá s 3D stavbou problém. Tato technologie však nelze adekvátně porovnat s ostatními, protože v budoucnu nebude vnitřek stavby obsahovat vůbec. Protože se uživatel do vnitřku kostela nepodívá, bylo by zbytečné ponechat v modelu i vnitřní stěny a průhledná okna, proto je tento model dle požadavků společnosti Google zjednodušen do maximální možné míry. Kvalita zobrazení odpovídá 3D modelu tak, jak ho vidí uživatel v modeláři, s texturami není problém, vše se vykresluje dostatečně kvalitně a nejsou z pohledu na objekt patrné chyby. Technologie WebGL při použití knihovny C3DL také nemá s vykreslením problém. Podobně jako VRML zvládá bez problémů při FPS cca 30 vykreslit celý korpus kostela, přední, poměrně složitou, stěnu i bezprostřední okolí ve formě terénu kostela. K vykreslení používáme standardní renderer a není potřeba podnikat úpravy v načítaných datech a přílišnou optimalizaci ve smyslu nastavení kvality scény apod. Při použití této technologie pravděpodobně nebude problém se zobrazením vnitřních objektů kostela včetně galerie, která bude generována aplikací z literatury [Šrám(2010)]. Jednoznačně největší problém s takto velkými daty (tisíce trojúhelníků) jaká virtuální model kostela představuje má technologie Flash. I při optimalizaci ve formě zmenšení kvality scény, nastavení textur do POT tvaru a dalších technikách je scéna příliš pomalá, téměř nepoužitelná. V průběhu realizace modelu v této technologii byly aplikovány všechny typy renderovacího nastavení, od tzv. Lazy rendereru, který je, jak již název napovídá, nejhorší možností, přes základní renderovací algoritmy nazvané Basic, až po kvalitou nejlepší renderování pomocí Quadrant renderer. Lazy i Basic sice scénu dovolují používat ve formě, kde se uživatel má možnost v reálném čase pohybovat pomocí standardních prvků typu klávesnice,

4.32. KOLIZE 25 myš, obsahuje však nepřehlédnutelné chyby. Ty jsou v takové míře, že se špatně vykreslují textury, prosvítají trojúhelníky, výpočet scény probíhá velice nepřesně, což se odráží v celkovém vjemu. Jak již bylo řečeno, je zde nutné použít Quadrat renderer, aby scéna vypadala do maximální míry tak, jak má. To však systém zpomalí tak, že scénou nelze plynule procházet. Testování omezení této technologie je blíže popsáno v kapitole Omezení technologie Flash. 4.32 Kolize Pro tvorbu scény, ve které chceme zapojit výpočet kolizí, např. avatar se pohybuje a my potřebujeme, aby následoval terén, neprocházel zdmi apod. je nejjednodušší použití technologie VRML. Při implementaci scény se o tyto nastavení nemusí tvůrce scény starat, vše je aplikováno automaticky na velice dobré úrovni. Lze tak snadno definovat ve scéně např. schody, nerovný terén atd. a avatar, při pohybu v módu chůze, respektuje tyto nerovnost a přizpůsobuje se jim. Tyto vlastnosti lze ještě blíže nastavit pomocí parametrů avatara tak, že na např. na velký schod nemusí avatar přejít. Naopak nejhorším výběrem je Google Earth, což je opět dáno filozofií této technologie. Zde se o vše stará aplikace programu a jako tvůrci 3D objektu výpočet kolizí neovlivníme. Při použití technologie Flash3D lze zapojit do aplikace tzv. fyzikální enginy třetích stran, které jsou určeny nejen pro výpočty kolizí, ale jak název napovídá, pro řešení fyzikálních simulací obecně. Jak popisuje literatura [Winder Tondeur(2009)Winder, Tondeur] proces má výhodu v tom, že nemusíme vyvíjet tyto simulační techniky a pouze využijeme dostupné knihovny, nevýhodou je dvojité zpracování objektů, na které chceme fyziku aplikovat. Důvodem je to, že při vytvoření základního objektu (např. koule) musíme vytvořit jemu korespondující fyzikální objekt a ten poté základnímu objektu přiřadit. Tím se do našeho základního objektu dostane fyzikální simulace, např. právě reakce na kolize s objekty ostatními. Jako oblíbené enginy pro tyto simulace literatura zmiňuje např. WOW engine, nebo Jiglib. Naopak použití detekcí kolizí není snadné v technologii WebGL. Opět zde záleží na zvoleném frameworku. V případě C3DL máme na výběr ze dvou možností: výpočet kolizí založen na objektech typu Collada (obálce objektu), nebo na geometrii těles, které objekt tvoří. Způsoby detekce kolizí popisuje i literatura [Žára et al.(2004)žára, Beneš Felkel], jenž se zabývá přesnou detekcí kolizí právě nad obálkami těles. Efektivita algoritmu tak závisí také na těsnosti obálek těles. V našem případě se, pravděpodobně z důvodu optimalizace, jedná pouze o jednoduché obálky typu kvádr. V obou případech, které framework nabízí, detekce fungují, ovšem za cenu dalšího výpočetního výkonu. Po detekci je již na programátorovi, jak si s kolidujícími objekty poradí a jakým způsobem vygeneruje odezvu aplikace na danou kolizi. Nevýhodou je, že ve scéně lze buď kolize pro všechny objekty zapnout, nebo vypnout, ale nelze je aplikovat jen na některé objekty, navíc avatar existuje pouze jako bod kamery a kolize se tak na něj nevztahují. V tomto případě je nutné kolem kamery ručně vytvořit další těleso. Paradoxem poté je, že v oficiální dokumentaci frameworku tuto metodu pro provádění kolizí vůbec nenajdeme (otázkou tak zůstává, proč tomu tak je), ačkoli v implementaci scény existuje.

26 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ 4.33 Textury a jejich omezení U technologií VRML, WebGL a Google Earth není s texturami při implementaci scény žádný problém. VRML umožňuje navíc i ruční vložení textur do výsledného souboru. Ostatní formáty umožňují ruční definice textur také, ale výhodnější a rychlejší je použití UV mapování, což lze navíc exportovat přímo z 3D modeláře. Problém s texturami byl zaznamenán pouze v technologii Flash, která je o poznání pomalejší kvůli chybějící hardwarové akceleraci. Textury se při renderování různě pokrucují a deformují a nejsou přesné, což nám při pohybu scénou vadí. Samozřejmě máme možnost nastavit jejich parametry tak, aby se zobrazováním nedeformovaly, ovšem za cenu výkonu. Konkrétně k tomu lze využít parametr percise s hodnotou true, ale musíme poté optimalizovat scénu dalšími technikami. Jedním z dalších problémů byla nutnost definovat tzv. MaterialList pro objekt, na kterém chceme zobrazit textury z více zdrojových souborů. Technologie Flash dále také umožňuje použít tzv. bump texturu, která simuluje hrbolatost a reflection texturu, která odráží světlo [Pulkert(2010)]. Tyto typy textur lze využít samozřejmě také ve WebGL. VRML umožňuje použití pouze bump textur. 4.34 Grafické karty a ovladače S novými technologiemi, zejména s WebGL mohou mít některé starší grafické karty, nebo starší verze ovladačů problém z hlediska náročnosti požadované scény. Pokud chceme zobrazit scénu ve WebGL, musí navíc naše grafická karta podporovat tzv. shader rendering. Z vlastního porovnání usuzujeme, že již na cca 4 roky staré konfiguraci počítače není možné některé ukázky z frameworků pro WebGL spustit. Že se jedná o problém konfigurace a ne frameworku bylo ověřováno na dalších počítačích s pokročilejším nastavením. Zejména knihovna GLGE má se staršími kartami problém. U ostatních technologií se tyto problémy neprojevily, protože Google Earth ani VRML tak náročné nejsou. Flash do tohoto srovnání zapojit nelze, neboť scénu kompletně počítá pouze procesor. 4.35 Omezení technologie Flash V této kapitole se budeme věnovat testování technologie Flash z hlediska omezení počtu trojúhelníků ve scéně při použití několika renderovacích technik. Pro toto horní omezení scény vzhledem k výpočetní rychlosti byla vytvořena jednoduchá scéna, se kterou máme možnost interaktivně pracovat ve smyslu přidávání a ubírání polygonů. Konfigurace byla použita stejná jako při testování FPS v realizaci jednotlivých technologií. Ve scéně máme k dispozici statistiky a základní orientaci (klávesnice, myš). Dále scéna obsahuje pouze vložené polygony, viz obrázek 4.2. Scéna je naprogramována tak, že po stisknutí tlačítka M se do scény přidá deska složená ze 450 trojúhelníků. Při každém dalším stisknutí se vloží další deska, pouze s jinou transformací. Tlačítkem N máme možnost desky ze zásobníku scény mazat a tlačítkem K scénu resetujeme. Testován byl základní renderovací engine: Basic a nejlepší, tzv. Quadrant. Oba

4.35. OMEZENÍ TECHNOLOGIE FLASH 27 Obrázek 4.2: Testovací scéna pro měření použití obou renderovacích algoritmů ve 12 krocích při průběžném měření hodnot FPS. Detailní údaje popisuje tabulka 4.2 a grafy 4.3 a 4.4. Principem Quadrant renderer engine je přesnější řazení trojúhelníků podle hloubky, řešení protínajících se polygonů, které algoritmus dále rozdělí a seřadí, nebo použití obou těchto technik zároveň. Tento postup je sice časově náročnější, ale zato přesnější a řeší nedostatky Basic renderer engine, který využívá metodu malířova algoritmu. Z naměřených výsledků plynou jistá omezení pro obě techniky. Z pohledu rychlosti se zde jeví výhodnější použití základního renderovacího enginu, jak však bylo popsáno v kapitolách výše, základní renderer působí mnohé potíže se zobrazením. Při použití textury (stisknutím tlačítka B ) se situace ještě zhorší, avšak zde záleží, jak kvalitní a velké textury máme, zda je chceme zobrazit přesně či jestli se textury mají zobrazovat oboustranně. Všechny tyto parametry hrají ve výkonu velkou roli. Obecně však stále s většími objekty budeme mít problém i při použití malých textur, protože u objektů budeme požadovat jejich přesné zobrazení, bez deformací. Technologie Flash se tedy celkově pro velká data s několika tisíci polygony příliš nehodí. Hranicí je podle našich měření cca 3000 polygonů, což potvrzuje i literatura [Winder Tondeur(2009)Winder, Tondeur]. Z teoretického a praktického srovnání lze říci, že pokud v budoucnu nebude mít podporu ze strany GPU, bude tato technologie zastíněna především WebGL, které bez problémů zobrazení velkých scén dovoluje.

28 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ Měření Počet polygonů FPS Basic algoritmuritmus FPS Quadrant algo- 1 450 30 30 2 900 30 18 3 1350 27 10 4 1800 23 6 5 2250 18 4 6 2700 14 3 7 3150 11 2 8 3600 7 1 9 4050 4 <1 10 4500 3 <1 11 4950 2 <1 12 5400 1 <1 Tabulka 4.2: Měření FPS v závislosti na počtu polygonů s použitím obou vykreslovacích algoritmů. Obrázek 4.3: Graf měření pro renderovací algoritmus basic

4.35. OMEZENÍ TECHNOLOGIE FLASH 29 Obrázek 4.4: Graf měření pro renderovací algoritmus quadrant

30 KAPITOLA 4. SROVNÁNÍ POUŽITÝCH TECHNOLOGIÍ

Kapitola 5 Shrnutí srovnávaných kritérií V následující tabulce 5.1 je uvedeno celkové shrnutí všech kritérií, popsaných blíže v kapitole 4. Kapitolu 4.1 Záměr využití technologie zde nelze nijak hodnotit. U ostatních se vždy přikláním k výhodě +, či jisté nevýhodě vůči ostatním technologiím, označené znaménkem -. 31

32 KAPITOLA 5. SHRNUTÍ SROVNÁVANÝCH KRITÉRIÍ Kriérium Google Flash3D WebGL VRML Earth 1 Záměr využití technologie x x x x 2 Dostupné knihovny a frameworky - + + - 3 Publikování 3D modelu - + + + 4 Potřeba dodatečných instalací - - + - 5 Integrace modelu s okolím + - - + 6 Možnosti optimalizace dat + + + + 7 Objektové programování - + + - 8 Funkcionalita v prohlížečích + + - + 9 Programovací náročnost + + - + 10 Vývojové nástroje pro tvorbu scén + + - + 11 Navigace uživatele scénou + - - + 12 Podpora pro vývojáře ve formě výukových + + - + materiálů 13 Export dat z modeláře + + + + 14 Práce s daty modelu + + + + 15 Velikost vkládaného modelu - - + + 16 Oficiální dokumentace + + + + 17 Tvorba her a logických celků - + + + 18 Bezpečnost + + - + 19 Animace - + + + 20 Multimediální obsah - + + + 21 Osvětlovací modely, světla - + + + 22 Typy stínování - + + + 23 Simulace mlhy, částicové systémy - + + + 24 Možnosti interaktivních prostředí - + + + 25 Stupeň grafické prezentace - + + - 26 Velikost přenášených dat + + + + 27 Hardwarové nároky + - - + 28 Složitost vytvoření virtuální prezentace + - - + 29 Využitelnost tech. do budoucna a jejich + + + - vývoj 30 Pouze POT textury - - + - 31 Podpora?-kanálu v texturách + + - + 32 Stupně detailu modelu LOD - + + + 33 Podpora hardwarové akcelerace + - + + 34 Možnost stereoskopického režimu + + + + 35 Tvorba primitiv + + + + 36 Nurbs křivky - - + + 37 Předefinovaný avatar + - - + 38 Frustum culling + + + + 39 Rozšíření pro tablety a mobilní telefony + + + - 40 Integrace v HTML kódu + + + - 41 Licence + + + + 42 Kvalita zobrazení a rychlost výpočtu + - + + scény 43 Kolize - + + + 44 Textury a jejich omezení + - + + 45 Grafické karty a ovladače + + - + Tabulka 5.1: Shrnutí kritérií porovnánaných technologií

Kapitola 6 Realizace V této kapitole jsou uvedeny kompletní postupy pro vytvoření scény v cílové technologii. Součástí některých technologií je implementace navigačních a ovládacích prvků, virtuální procházky, či virtuální výstavy obrazů a propojení s existující webovou aplikací. V průběhu vývoje virtuálních scén byly zjištěny některé nedostatky, omezení či optimalizační metody, které v této kapitole také detailně popisujeme. Tato část diplomové práce sloužila zároveň jako zdroj praktických implementačních detailů, které doplňují předchozí srovnání všech uvedených technologií z různých hledisek. 6.1 VRML/X3D Technologický postup pro přípravu 3D modelu, vytvořeného v prostředí modeláře Blender [Blender Foundation()], je kompletně popsáno v literatuře [Šrám(2010)]. Literatura zahrnuje popis od vytvoření 3D modelu podle fotografií a výkresového plánu, po převod modelu do technologie VRML až po jeho optimalizaci a zpřístupnění ve webovém prostředí. 33

34 KAPITOLA 6. REALIZACE 6.2 WebGL Tato kapitola obsahuje popis implementace scény s využitím technologie WebGL. Zabýváme se zde pracovními postupy, popisem převodu dat a návodem pro kompletní vytvoření scény s využitím navigačních prvků, chůze, omezením pohybu a dalších detailů. Stejně jako při využití technologie VRML v bakalářské práci [Šrám(2010)] se i zde počítá s využitím dat galerie. Data jsou generovaná webovou aplikací, která umožňuje správu virtuálních výstav obrazů. Celá virtuální prohlídka tak bude přístupná v další z dnes používaných webových technologiích. 6.2.1 Použité frameworky a technologie, zvolený postup Při vytváření scény v technologii WebGL má tvůrce možnost volby z několika dostupných frameworků pro podporu vývoje, např.: [Bishop(2011), Kay(2011), GLGE(2011a)], nebo má možnost programování v čistém WebGL. První varianta je více efektivní, rychlejší a navíc s možností využití objektového programování či dalších podpůrných prostředků (načítání různých formátů dat, využití událostí atd.). Samozřejmě ne všechny typy frameworků toto umožňují, proto je vždy třeba zvážit nejvhodnější volbu. V našem případě byl vybrán Framework C3DL [Bishop(2011)], který umožňuje kvalitně využít všechny aspekty pro tvorbu kvalitní scény v této technologii, navíc s využitím objektů, či formátu Collada pro zdrojová data. Pracovní postup pro vytvoření scény od počátečního modelu je zobrazen na obrázku 6.1. Obrázek 6.1: Pracovní proces vytvoření scény

6.2. WEBGL 35 6.2.2 Převod zdrojových dat Celá scéna byla v bakalářské práci, ze které čerpáme, vytvořena v modelovacím programu Bender [Blender Foundation()] a následně převedena do technologie VRML. Zde existují dvě možnosti, jak zdrojová data převést do námi požadovaného formátu, jakým je pro framework C3DL formát Collada, optimálně ve verzi 1.4. Pokud máme přístup ke zdrojovým datům např. v podobě nativního formátu modeláře, provedeme pouze export dat do cílového formátu, který je naznačen na obrázku 6.2. Další možností, kterou považujeme za výhodnou, je importovat do programu Blender, wrl soubory z technologie VRML, které lze poté opět snadno exportovat do formátu Collada 1.4, bez nutnosti dispozice zdrojových dat modelu v modelovacím software. Pozn.: program Blender vyžaduje k exportování instalaci doplňku Python [Python Software Foundation()], případně doplňku pro export do verze 1.4 formátu Collada. Python stačí pouze stáhnout ve tvaru pro náš operační systém a nainstalovat. Doplněk Collada poté pouze importujeme do modeláře. Formát Collada je založen na XML a je tedy vhodný i z hlediska budoucích úprav nebo kontroly při programování scény. Důležitým krokem pro správné zobrazení dat ve WebGL je nastavení exportu v modeláři, kde využijeme hlavně vlastnost zápisu relativních cest k texturám, zápisu texturovacích souřadnic pomocí UV a poté možnost exportování celé scény nebo pouze vybraných částí. Textury musí být před převodem dat mapovány pomocí UV souřadnic, jinak se je nepodaří správně zobrazit a objekty ve scéně tak zůstanou černé. Pokud bychom měli textury z nějakých důvodů v jiném adresáři se složitější cestou, než cílovou aplikaci, je právě díky XML formátu možnost jednoduše tyto cesty zkontrolovat a vyhnout se tak případnému ladění na straně programu scény. V exportovaných datech stačí pouze vyhledat sekci <library_images > a provést kontrolu relativních cest, případně je upravit na požadovaný tvar. 6.2.3 Vytvoření základní scény Pro vytvoření scény ve vybrané technologii bylo využito klasických postupů a konstrukcí, popsaných v oficiální dokumentaci frameworku a jejich šablonových příkladů [Bishop(2011)]. Tyto však pokrývají pouze naprostý základ, např. jak zobrazit objekt s texturou. Další vlastnosti a postupy musí programátor vytvořit a naprogramovat dodatečně. Celý postup od začátku tvorby scény bude v této kapitole detailně vysvětlen. Zdrojové soubory přiložené na DVD jsou dokumentované a též přehledně popsané. Prvním krokem pro vytvoření scény a použití objektů zdrojových dat, generovaných modelářem, je stažení aktuální verze frameworku C3DL z oficiálních stránek [Bishop(2011)]. Dalším krokem je poté správné umístění a vytvoření adresářové struktury. Zdrojové soubory framewroku by měly kopírovat následující strukturu.

36 KAPITOLA 6. REALIZACE Obrázek 6.2: Cílový formát dat je formát Collada verze 1.4 s využitím parametrů \webgl \\c3dl -soubory knihovny \\myscene -scene.js -index.html -data objektů dae -textury -css Pro zobrazení scény je potřeba správně nastavit soubor (v našem případě index.html), který bude scénu spouštět a zobrazovat. V hlavičce HTML přidáme dva skripty, jeden na C3DL API a druhý na naši scénu scene.js v jazyce JavaScript. V těle dokumentu poté vytvoříme HTML5 element <canvas> s parametrem id, což je textový identifikátor. Musí se shodovat s hlavní callback funkcí, kterou budeme definovat v souboru scene.js, čímž se oba soubory propojí. Poté máme možnost nastavit další parametry, jako jsou výška a šířka okna, případně jeho styl. Na začátku programu scény si vytvoříme konstanty s cestou ke zdrojovému souboru s objektem. Pokud máme objektů pro vložení více (klasicky se scéna bude skládat z více objektů), budeme konstant definovat více. Poté již následuje definování hlavní callback funkce

6.2. WEBGL 37 scény zavoláním metody c3dl.addmaincallback(canvasmain, "scene"); kde scene je právě název našeho id, elementu canvas v HTML souboru. Poté již následuje přidání jednotlivých modelů metodou c3dl.addmodel(cesta k souboru). Dále potřebujeme vytvořit proměnné, které budou reprezentovat objekt. S těmi se bude pracovat v programu při určování kliknutí, nastavení velikosti, animací atd. Nyní již budeme tvořit funkce pro zobrazení scény. Jednou z důležitých částí je callback funkce, která se bude volat při každém obnovení scény, tedy při každém vykreslení obrazovky. Do ní později naprogramujeme animace kamery, pohybu dveří, nebo blikání navigační šipky uvnitř kostela. Program bude pokračovat hlavní funkcí tzv. canvasmain, kterou jsme již na začátku programu použili ke spárování s elementem canvas. Jedná se o funkci, ve které vytvoříme objekt typu scéna, WebGL renderer a přiřadíme ho ke scéně. Kód vypadá následovně: function canvasmain(canvasname){... //Vytvoření objektu typu scéna scn = new c3dl.scene(); scn.setcanvastag(canvasname); //Vytvoření GL contextu renderer = new c3dl.webgl(); renderer.createrenderer(this); //nastavení rendereru //Přiřazení rendereru ke scéně scn.setrenderer(renderer); scn.init(canvasname); //inicializace Dále testujeme, zda je renderer správně připojen ke scéně. Pokud ano, můžeme již začít pracovat s objekty. Nejprve vytvoříme objekt typu Collada. Ten bude později obsahovat námi načtený model pro vložení do scény. Poté provedeme inicializaci modelu pomocí konstanty, kterou jsme nastavili na začátku programu. V dalších několika příkazech máme možnost nastavení měřítka objektu, nastavení možnosti kliknutí na objekt, nebo změny pozice a dalších vlastností. Když máme objekt v požadovaném tvaru a nastavení, provedeme jeho vložení do scény. Kód pro jeden objekt vypadá následovně: //Fce isready() testuje, zda je renderer připojen ke scéně if(renderer.isready() ) { //Vytvoření collada objektu, který bude obsahovat importovaný model //pro pozdější vložení do scény objekt = new c3dl.collada(); //Inicializace objektu typu collada strecha.init("webgl_strecha.dae");

38 KAPITOLA 6. REALIZACE... //Nastavení celkové změny měřítka objektu scény var scale_arr = new Array(2.0,2.0,2.0); //nastavení počátečního měřítka strecha.scale(scale_arr); //Nastavení, zda je možné na objekty kliknout nebo ne var pick = false; skybox.setpickable(pick); //Vložení objektu do scény scn.addobjecttoscene(strecha); Tím máme práci s objektem hotovou. Dále potřebujeme vytvořit objekt typu kamera a provést další nastavení, které popisuje kód níže. Důležitým parametrem je nastavení iniciální pozice kamery a směru pohledu. V následujícím kódu je kamera cam nastavena na počáteční viewpoint a počáteční směr, definovaný v sekci viewpointů virtuální procházky, která bude popsána níže.... //Vytvoření kamery typu FreeCamera var cam = new c3dl.freecamera(); //Umístění kamery, nastavení nultého viewpointu a směru pohledu kamery cam.setposition(c_home); cam.setlookatpoint(c_home_lap); //Přidání kamery do scény scn.setcamera(cam); //Callback funkce pro uvolnění, stisknutí tlačítka nebo pohyb, kolečko myši scn.setkeyboardcallback(up,down); scn.setmousecallback(mouseup,mousedown, mousemove,mousescroll); //Definnování, která funkce se má zavolat, když dojde ke kliknutí na objekt scn.setpickingcallback(handler); //Přidání callback funkce scn.setupdatecallback(callbackfunc); //Start scény scn.startscene(); Funkci pro kliknutí na některý objekt, který má nastaven parametr pro kliknutí můžeme definovat až na konci souboru. Tato funkce bude obsahovat dvě základní proměnné, které jsou:

6.2. WEBGL 39 var buttonused=result.getbuttonused();//zjištění, které tlačítko bylo použito var objectspicked=result.getobjects();//pole všech objektů, na které bylo kliknuto Poté vytvoříme cyklus přes všechny objekty, kde se v každém cyklu můžeme ptát, zda objekt, na který uživatel kliknul některým tlačítkem, je náš požadovaný objekt (např. dveře kostela) a pokud ano, provedeme zavolání funkce pro animaci dveří, nebo provedeme některé další operace. Tímto je základ scény hotový. V dalších kapitolách budeme postupně přidávat další implementační rozšíření, které umožní vytvoření kompletní scény včetně navigace, galerie a dalších prvků. 6.2.4 Implementace pohybu a omezení avatara Při použití frameworku C3DL nemá programátor k dispozici žádné základní navigace, jako například v technologii VRML a musí je tedy vytvořit sám včetně pohybu, rotací atd. Ve scéně této funkcionality docílíme pomocí odchytávání událostí kláves, pohybu myši a tlačítek myši a algoritmem poté budeme počítat souřadnice pohybu, případně testovat nějaké podmínky. První, co však musíme do již vytvořené scény vložit, je metoda pro poslouchání událostí a případném volání dalších metod, které již provádí operace, tzv. callback funkce, a to jak pro událost myši, tak i klávesnice. Tyto funkce definujeme před voláním metody scn.start(). Volání vypadá následovně: scn.setkeyboardcallback(up,down), kde up a down jsou volané funkce, které musíme do programu doplnit. Druhou callback funkcí je scn.setmousecallback (mouseup, mousedown, mousemove, mousescroll) opět s funkcemi jako parametry metody. Callback funkce se v programu mohou vyskytovat libovolně. Nejprve popíšeme funkci down, která je volána při stisknutí klávesy. Prvním krokem je zjištění objektu kamery pomocí funkce scn.getcamera(). Následuje rozhodnutí, zda je současně stisknuta klávesa shift, která se použila v kódu pro ladění a i uživatel ji může využít pro vertikální pohyb nahoru či dolu po globální ose y. Pomocí konstrukce switch a kódu klávesy provedeme jednotlivé operace. Pokud nebyl stisknut prvek shift, jedná se o pohyb kamery rovnoběžný s osou z. V tomto kroku potřebujeme zjistit směr kamery metodou cam.getdir() a nastavit mu souřadnici y na 0. To provedeme z toho důvodu, abychom při pohybu myši směrem k obloze či naopak k podlaze a následném pohybu simulovali chůzi avatara, tedy chceme fixní souřadnici y, jinak by se avatar např. vznesl, čímž bychom simulovali mód létání. Dále vytvoříme proměnnou pro pozdější určení pohybu, tedy např. mov=[0,0,0], zatím nulový pohyb. Poté se pomocí stisknutí příslušného tlačítka, zde např. šipka vpřed, provede důležitá operace mov = c3dl.multiplyvector(direction,0.01,mov), která vezme vektor směru kamery a násobí ho konstantou pohybu, konkrétně skalárem 0.01. Výsledek uložíme do proměnné pohybu mov. Na konci funkce poté provedeme jednoduchý příkaz pro nastavení pohybu kamery metodou cam.setlinearvel(mov) a pohyb kamery tak může začít. Samozřejmostí je individuální nastavení pro každou požadovanou klávesu. V našem případě je jedná o pohybové šipky, klávesy s a w pro vertikální pohyb a Page up/down pro přepínání mezi viewpointy, tedy pozorovacími body. V této funkci je implementováno i omezení pohybu u varhan, ve kterém se při stisknutí klávesy ptáme na aktuální viewpoint.

40 KAPITOLA 6. REALIZACE Pokud se poté naše pozice shoduje s viewpointem v horní části na balkónu u varhan, pohyb zakážeme a povolíme pouze otáčení a prohlídku pomocí myši. V těle funkce je implementována i vlastnost celkového omezení pohybu a kolize s virtuálními boxy kolem stěn kostela. Omezení provedeme tak, že se u klávesy šipek ptáme, zda na danou pozici avatar smí vstoupit. Voláme tím funkci, která nám omezuje pohyb avatara a řeší případné kolize s omezujícími souřadnicemi algoritmicky. Pohyb avatara je omezen tak, aby uvnitř kostela nemohl projít obvodovými zdmi a vně kostela nemohl projít zdmi dovnitř, jak naznačuje obrázek 6.3. Obrázek 6.3: Červeně je naznačen prostor, kde se avatar nesmí pohybovat Volaná funkce se skládá z výpočtu, zda se avatar nachází uvnitř objektu či vně a podle toho se aplikují jednotlivá omezení s návratovými hodnotami. Hodnoty poté určují, co se má se souřadnicemi avarata (kamery) provést, když se překročí povolené hranice. Vždy se jedná o pohyb, který avarata přesune zpět do povolené zóny pohybu. Omezení byla volena tak, aby nebylo zamezeno pohledům na jednotlivé objekty nebo výstavy obrazů uvnitř kostela, a aby se avatar mohl pohybovat i skrze dveře kostela. Nyní popíšeme funkci up pro vstup z klávesnice. Funkce slouží pro detekci uvolnění klávesy. Klávesa je rozpoznána pomocí čísel a stačí nám tak opět konstrukce switch s několika možnostmi. V našem případě se po uvolnění šipek pohybu pohyb kamery zastaví, tedy nastaví se parametr velocity na hodnotu 0 pro každou souřadnici. Pokud byla stisknuta zároveň klávesa shift, zastavíme rotaci kamery pomocí metody setangularvelocity() s parametry souřadnic nastavenými na hodnotu 0. Reakce na pohyb myši obstarávají především funkce mouseup, mousedown, mousemove. Jak je z názvů patrné, první funkce zjišťuje kliknutí pravým tlačítkem a nastavuje proměnnou

6.2. WEBGL 41 isdragging na hodnotu true. Tato proměnná se uchovává pro další metodu s cílem výpočtu nových souřadnic směru kamery. Druhá funkce dělá od-nastavení této proměnné a funkce třetí, tedy mousemove při stisknutém pravém tlačítku a pohybu myši přepočítává souřadnice na pohyb kamery. Tato metoda je důležitá protože mapuje pohyb myši na kameru. V metodě potřebujeme znát poslední souřadnici, od které budeme pohyb počítat a hlavně potřebujeme nastavit vektor up kamery na hodnotu 0,1,0, tedy na vektor totožný s globálním souřadným systémem. Tím dosáhneme rotace kamery vždy kolem globální osy y. Simulujeme tím pohyb člověka stojícího na zemi, který se otáčí. Při spočítání pohybu kurzoru od poslední známé hodnoty se poté pohyb převede podle proměnné citlivosti a změny pohybu kurzoru na rotaci kamery. Výsledek si nakonec uložíme pro opětovné zavolání funkce, abychom věděli, kde s počítáním pozice začít. Techniku znázorňuje následující kód. //Funkce volaná při pohybu myši (pracuje, pokud uživatel drží levé tlačítko) //Funkce určuje, jak daleko se kurzor pohnul a podle toho počítá pohyb kamery //tak, aby odpovídal pohybu myši function mousemove(evt) { if(isdragging == true) //pokud držíme levé tlačítko { var cam = scn.getcamera(); //Důležité nastavení - chceme, aby se kamera vždy otáčela kolem osy y //globálního souř. systámu, tedy jako když člověk stojí na zemi a otáčí //se kolem. Jinak by docházelo k převrácení kamery. cam.setupvector(new Array(0.0, 1.0, 0.0)); //nastavení up vektoru var x = xevtpos(evt); var y = yevtpos(evt); //Určení, jak moc se kurzor pohnul od posledního pohybu var deltax = x - rotationstartcoords[0]; var deltay = y - rotationstartcoords[1]; //Pohyb kamery podle změn a nastavení citlivosti cam.yaw(-deltax * SENSITIVITY); cam.pitch(deltay * SENSITIVITY); } } //Zaznamenání, kde bude rotace začínat příště, po zavolání této funkcce rotationstartcoords = [x,y]; 6.2.5 Navigační a ovládací prvky Ovládací prvky, kromě popsané klávesnice a myši pro implementaci pohybu, lze umístit přímo pod element CANVAS do HTML stránky. Máme tak možnost vytvořit navigační panel pomocí tlačítek a ostatních HTML elementů ke snadné a intuitivní navigaci uživatele virtuální scénou.

42 KAPITOLA 6. REALIZACE V našem případě byl vytvořen panel s několika tlačítky, které po kliknutí volají některou z funkcí programu scény, tedy funkci, která se nachází v souboru scene.js. Zde naprogramujeme reakce na tyto události. Základem pro pohyb ve scéně však zůstává pohyb pomocí kurzoru myši a šipek, které je pro uživatele nejvíce intuitivní. Navigační panel se skládá z několika tlačítek, kterými lze přecházet mezi jednotlivými viewpointy pomocí animace. Viewpointy jdou po sobě podobně, jako tomu bylo u předchozí verze v jazyku VRML a je tedy možné si virtuálně prohlédnout celý kostel zevnitř spolu s případnou virtuální výstavou a poté lze nahlédnout i na celou scénu a kostel zvenčí. Stejně jako tlačítka další a předchozí funguje i klávesa PageUp a PageDown s tím rozdílem, že tlačítka klávesnice slouží pro rychlý přechod mezi viewpointy, tedy nespouštíme animaci, ale rychle uživatele přeneseme na bod zájmu. Uživatel tedy není odkázán pouze na klikání na tlačítka, ale má možnost využít klasický vstup pomocí kláves, jako tomu je ve VRML. Výhodou může být volnost grafické úpravy HTML tlačítek pomocí CSS stylů, ovšem to není předmětem popisu tvorby scény. Styl lze vytvořit podle vkusu jakýkoli. Důležitou navigací je také seznam viewpointů, které jsou k dispozici v rámci virtuální procházky. Tento seznam je umístěn vedle obrazovky scény a je interaktivní, takže umožňuje uživateli po kliknutí na libovolný bod procházky na tento bod pomocí animace přejít. Libovolné přecházení je umožněno vzhledem k implementaci algoritmu pro omezení pohybu, díky kterému vždy víme, zda se uživatel nachází vně či uvnitř kostela a lze tak okamžitě reagovat na případné změny viditelnosti objektů ve scéně. I při přechodu z/do kostela algoritmus v každém obrazovém rámci ví, kde se uživatel nachází, proto lze objekty ze scény odebrat, či je přidat přesně při průchodu hranicemi kostela. Pod seznamem se dále nachází informace, na kterém viewpointu se uživatel nachází, nebo zda se ve scéně volně pohybuje. Poslední viewpoint, na kterém se uživatel nacházel je poté v navigaci obarven odlišnou barvou, aby uživatel poznal, odkud bude případně procházka pokračovat při stisknutí tlačítek Další / Předchozí. Uživatelské rozhraní naznačuje obrázek 6.4. Obě HTML tlačítka navíc v průběhu animace prostřednictvím JavaScriptu vypínáme (nastavíme parametr disabled na hodnotu true), aby nedošlo k vícenásobnému kliknutí, čímž by se začátek animace mohl posunout a ve scéně by tak mohla vzniknout chyba. Po skončení přesunu tlačítka opět povolíme. Dalším navigačním prvkem je blikající šipka u schodů kostela, viz obrázek 6.5, po kterých není umožněno chodit, neboť avatar nekopíruje měnící se výšku terénu. Při pohledu v přízemí na schody za dveřmi vpravo, vidí uživatel blikající šipku, která ho po kliknutí na ni přenese na balkon. Tam má uživatel možnost prohlídky pouze pomocí myši. Může se tak libovolně otáčet, ale nesmí se jinak pohybovat. Na balkoně se nachází druhá šipka, která uživatele po kliknutí opět přenese do přízemí, odkud může pokračovat. Místo šipek lze samozřejmě využít i kláves či tlačítek v navigačním panelu. 6.2.6 Virtuální procházka a vytvoření animací Tato kapitola popisuje vytvoření animací jednotlivých objektů ve scéně a následně i virtuální procházky kostelem. Animace nejsou frameworkem podporovány ve formě dalších podpůrných knihoven, jako tomu je např. u technologie Flash, ale máme zde možnost tento problém vyřešit pomocí dodatečných funkcí. Prvním krokem pro vytvoření animace kamery, a tím vytvoření virtuální procházky, je nadefinování jednotlivých bodů pohledu neboli viewpointů. Ty se skládají z pozice kamery

6.2. WEBGL 43 Obrázek 6.4: Uživatelské rozhraní aplikace technologie WebGL a bodu, na který kamera směřuje (kam se uživatel z bodu dívá). Těchto bodů je ve scéně celkem 11. Viewpointy jsou definovány jako souřadnice ve 3D prostoru. Vytvoříme si tedy dvě pole jedno pro viewpointy, druhé pro body pohledu kamery. Poté nastavíme souřadnice pro všech 11 viewpointů i bodů a vložíme je do příslušných polí. Mezi viewpointy se vždy kamera přesunuje jiný čas, který je též třeba nadefinovat pro každý viewpoint. Vznikne tak třetí pole, které bude obsahovat pouze číselné hodnoty, reprezentující časy pohybu. Animace kamery je volána vždy po stisknutí tlačítka pro přesun mezi viewpointy, tedy např. tlačítkem v HTML kódu stránky Předchozí, nebo Další. V tomto případě se provede několik příkazů a spustí se pohyb kamery. Jednotlivé kroky popisuje následující kód. //Nastavení počáteční pozice viewpointu, ze které se budeme hýbat cam.setposition(viewpoints[actual_viewpoint]); actual_viewpoint++; //Nastavení cílového viewpointu. Pokud je za hranicí pole, nastavíme //zpět na viewpoint 0 if(actual_viewpoint>viewpoint_count){ actual_viewpoint = 0; }

44 KAPITOLA 6. REALIZACE Obrázek 6.5: Aktivní navigační prvek v objektu kostela //Nastavení pohledu kamery na viewpoint cam.setlookatpoint(viewpoints[actual_viewpoint]); mov = c3dl.multiplyvector(cam.getdir(),0.01,mov); //spočítání pohybu kamery cam.setlinearvel(mov); //nastavení pohybu kamery timeanimation = 0; //čas animace kamery nastavíme na začátek - čas 0 //Budeme se plynule dívat na příští viewpoint při animaci pohybu kamery, //uživatel navíc během animace nesmí myší měnit pohled lookatviewpoint = true;... Nastavení času animace na hodnotu 0 nám umožní počítání času callback funkci, která byla popsána při vytváření scény. Jedná se o funkci, která se volá vždy při obnovení scény. V této funkci nyní definujeme animaci kamery pomocí následujícího kódu. cam = scn.getcamera(); //zjistíme objekt kamery

6.2. WEBGL 45 timeanimation+=time; //při každém volání ubíhá čas //Pokud čas pro animaci kamery mezi viewpointy vypršel if(timeanimation >=movetime[actual_viewpoint]){ cam.setlinearvel([0,0,0]); //zastavíme pohyb kamery lookatviewpoint = false; //povolení pohybu a interakce se scénou } //pokud animace trvá if(lookatviewpoint == true){ //Kamera se dívá vždy na cílový viewpoint, uživatel pohled neovlivní, //dokud animace neskončí cam.setlookatpoint(viewpoints_dir[actual_viewpoint]); }... Posledním příkazem cam.setlookatpoint vytvoříme iluzi příjemnějšího a plynulého pohybu kamery. Ta se při pohybu po přímce v každém obrazovém rámci plynule otáčí tak, aby pohled vždy směřoval na daný bod, na který se kamera z viewpointu kouká. Pohyb naznačuje obrázek 6.6. Obrázek 6.6: Pohyb kamery při animaci s plynulým otáčením Pokud se ovšem avatar pohybuje mimo definované viewpointy, např. volně po objektu, nebo vně objektu a stiskne tlačítka, nebo odkaz pro přesun na některý viewpoint, animace by takto popsaným způsobem nejprve přesunula avatara na poslední bod procházky, a poté by se teprve spustila animace přechodu na další viewpoint. Vhodnější v této situaci je implementace doplňkové funkce, která při požadavku přesunu nejprve vypočítá pomyslnou animační křivku mezi dvěma body v prostoru (aktuální pozice kamery a pozice požadovaného viewpointu). Ze vzdálenosti obou bodů a konstanty následně vypočítáme čas, potřebný pro animaci kamery k požadovanému bodu a poté již spustíme výše popsanou animaci (pouze s upravenou konstantou timeanimation). Z jakéhokoli místa tak získáme plynulou animaci kamery k požadovanému viewpointu neboli bodu pohledu.

46 KAPITOLA 6. REALIZACE Touto metodou se nám podařilo implementovat výpočetně velice jednoduchou a rychlou animaci kamery, aniž bychom museli provádět výpočty složitějších animačních křivek a orientace objektu v čase, jak popisuje literatura [Žára et al.(2004)žára, Beneš Felkel]. V kapitole Počítačová animace se literatura zabývá právě problémem výpočtu křivek podle zadaných bodů, přičemž algoritmus provádí interpolaci mezi body a výpočty rychlosti pomocí parametrizace křivky procházející těmito body. Vzhledem k očekávanému vývoji knihovny C3DL nebyla popsaná metoda implementována. Počítáme s tím, že v příštím vydání knihovny již budou dostupné pokročilé metody animace objektů ve scéně. Algoritmus pro přesný výpočet může být také námětem pro budoucí vylepšení této aplikace. Animace šipky u schodů a na balkonu kostela je vytvořena také pomocí měnícího se času. Vždy po uplynutí několika stovek milisekund se provede změna textury objektu šipky. Protože je tato funkce s metodou pro animace volána při každém obnovení scény, šipka tak bude blikat dokud scénu neukončíme. Animace dveří je naprogramována podobně jako přechod mezi viewpointy. Rozdíl je zde v nastavení otáčení podél osy y a zapamatování si stavu, ve kterém se dveře nachází. Při kliknutí na objekt dveří se tedy nastaví čas animace dveří na hodnotu 0. Objekt nastavíme tak, aby se na něj nemohlo kliknout a dále nastavíme pravou rotaci dveří. Tím se v callback funkci aktivuje přičítání času a testuje se podmínka na čas, za který se dveře animují. Po dosažení času se dveře zastaví a uživatel na ně může znovu kliknout. Tím se celý proces opakuje, pouze s opačnou rotací, dveře se zavírají. 6.2.7 Level of Detail Tato kapitola popisuje implementaci LOD neboli Level of Detail. Funkce v C3DL není nativně podporována jako ve VRML. V našem případě jsme ji vyřešili pomocí nastavení konkrétního viewpointu, ze kterého je plný detail varhan na balkonu kostela vidět. Na počátku scény je ve scéně vložen objekt typu Collada, který obsahuje jednoduchou verzi varhan. Ta je vidět z vnitřku kostela. Pokud se uživatel přemístí pomocí navigačních prvků (blikající šipky, tlačítek nebo kláves PageUp/Down) na balkon, algoritmus provede odebrání objektu jednoduchých varhan a vloží do scény složitější, původní model, sestávající se z několika tisíc plošek. Při dalším pohybu a opuštění balkonu se objekt opět přepne na jednoduché varhany, čímž snížíme výpočetní náročnost aplikace. Porovnání složitosti obou modelů obsahuje tabulka 6.1. Další implementace LOD pouze ve variantě 1/0, tedy objekt je vidět, nebo vidět není, byla provedena spolu s optimalizační částí scény. Při pohybu avatara máme díky algoritmu pro omezení pohybu stále informaci, jestli se avatar nachází vně či uvnitř kostela. Můžeme tak dynamicky měnit objekty ve scéně, kterým nastavujeme parametr objekt.setvisible na hodnotu true/false. Pokud jsme např. vně kostela, nemusíme počítat s objekty uvnitř a naopak. 6.2.8 Implementace galerie a propojení s aplikací Část programu se zabývá zobrazením virtuální výstavy, generované pomocí webové aplikace. Jedná se o možnost tvorby individuální výstavy, kde lze měnit obrazy, jejich umístění ve 3D modelu kostela, či jejich velikost a následně lze tuto výstavu zobrazit ve virtuálním objektu.

6.2. WEBGL 47 V této technologii, na rozdíl od VRML, nelze tak jednoduchým způsobem definovat prototyp obrazu, který by měl měnitelné vlastnosti pouze některých částí (zde plátna). V C3DL musíme vždy vytvořit dva objekty typu Collada, ze kterých se obraz bude skládat. Jeden pro rám s předem určenými UV souřadnicemi pro texturu dřeva a druhý objekt plátno, což je jednoduchý polygon, kterému nastavíme zdrojový soubor textury při generování výstavy pomocí metody settexture(). UV souřadnice jsou také předem dané ve zdrojovém souboru typu Collada. Oba objekty poté inicializujeme, nastavíme měřítko a vlastnost, kde řekneme, že na objekty se nebude smět kliknout pomocí myši (tzv. setpickable(false)). Poté nastavíme pozici objektů a vložíme je do scény. Toto provedeme pro každý obraz, který chceme do scény vložit. Zdrojový kód pro jeden obraz vypadá následovně. var obraz = new c3dl.collada(); //vytvoření proměnných pro objekt var platno = new c3dl.collada(); //Inicializace rámu i plátna obrazu podle nastavených konstant obraz.init(ram); platno.init(platno); //Nastavení individuální textury plátna podle databáze platno.settexture("./obrazy/sample.jpg"); obraz.scale([1,1,1]); //nastavení měřítka, podle databáze obraz.setpickable(false); //nastavení vlastnosti kliknutí na objekt platno.scale(([1,1,1]); platno.setpickable(false); obraz.translate([5.5,16.5,12]); //nastavení posunu podle databáze obraz.yaw(0.8); //aplikace rotace objektu platno.translate([5.5,16.5,12]); platno.yaw(0.8); //Vložení objektu obrazu včetně plátna do scény scn.addobjecttoscene(obraz); scn.addobjecttoscene(platno);... Nesmíme zapomenout na začátek souboru scene.js přidat konstanty s cestami k oběma objektům a přidat do C3DL modely metodou c3dl.addmodel(). Z hlediska počtu řádků je tento postup delší než u VRML nebo u technologie Flash, popsané v kapitole 6.3.6 - Implementace galerie, avšak vzhledem k tomu, že tento kód generuje aplikace a nemusí se o něj starat ani uživatel ani programátor, to nemusí vadit. Z našeho pohledu programátora tuto proceduru nastavíme pouze jedenkrát a poté opakujeme pro požadovaný počet obrazů s různými parametry, které jsou nastavené uživatelem a uložené v databázi webové aplikace.

48 KAPITOLA 6. REALIZACE Protože celá scéna je složena z jednoho JavaScript souboru, který obsahuje i galerii, lze tento program celý generovat aplikací, kde část před a po galerii bude neměnná a pouze část galerie se bude dynamicky měnit. Z aplikace se tak vytvoří jeden soubor, reprezentující celou scénu v technologii WebGL i s konkrétní galerií. Změny ve webové aplikaci spočívají v úpravě algoritmu pro generování výstavy, ve kterém musíme přidat část pro WebGL popsanou výše, a poté v úpravě php objektu typu obraz. Ten bude mít nyní navíc vlastnosti měřítka, pozice, rotace a textury pro technologii WebGL (textura musí být jiná, protože WebGL při zvoleném frameworku neumožňuje z optimalizačního hlediska využít texturu v NPOT tvaru). Texturu pro WebGL ukládáme do nového adresáře. Před uložením ji vždy navíc změníme rozlišení na mocniny dvou. Dále v aplikaci upravíme funkci třídy GalleryBean, ve které dochází ke změně měřítka obrazu při jeho editaci pomocí webové aplikace. Musíme zde přidat tabulku pro přepočet měřítka mezi technologií VRML, pro kterou byla aplikace původně navržena, a WebGL. Pro každou hodnotu měřítka VRML nám tedy aplikace nastaví hodnotu měřítka pro WebGL a tu v objektu aktualizuje. Poslední změnoy jsou ve statických šablonách a php třídách jednotlivých stránek aplikace, ve kterých přidáme další pole s iniciálními souřadnicemi obrazů pro tuto technologii. 6.2.9 Vytvoření zjednodušené verze scény Při vytváření scény jsme zaznamenali pomalejší chod aplikace na starším typu počítače (cca 4 roky). V plném detailu by tak cílový uživatel či tvůrce výstavy v objektu neměl možnost plynulé procházky a zobrazení galerie. Rozhodli jsme se proto vytvořit druhou, zjednodušenou verzi virtuálního modelu kostela, obsahující o tisíce polygonů méně. Zjednodušení probíhalo v programu Blender, ve kterém byl původní model vytvořen. Proces se sestával z nahrazení složitých ploch, jako sloupů, terénu a detailně modelovaných objektů jednoduchými primitivy s jejich případným dodatečným upravením. Poté byly aplikovány totožné textury, jako u originálů. Výsledek je velice podobný a díky použitým texturám rozdíl poznáme až při zaměření se na detail. Uživatel pomalejší konfigurace počítače tak dostane možnost prohlédnout si model, aniž by přišel o pocit detailního zpracování modelu. Program generující scénu pro tento model byl použit totožný jako pro původní, složitější variantu. Není třeba ani dodatečně upravovat aplikaci pro generování galerie, neboť zdrojová data výstavy zůstanou stejná. Porovnání počtu polygonů v plné a ve zjednodušené verzi modelu popisuje tabulka 6.1. Výsledný zmenšený model je zobrazen na obrázku 6.7. Ve výsledku tak máme jednu aplikaci, která používá buď data původní nebo data zjednodušená. 6.2.10 Optimalizace Ve scéně bylo provedeno několik optimalizačních kroků, které mají za cíl zmenšit počet objektů a tím scénu zrychlit. Díky algoritmu pro omezení pohybu avatara v každém okamžiku víme, kde se avatar nachází a můžeme tak objekty ve scéně přidávat či ubírat. Technicky tato operace nelze provádět způsobem, popsaným v kapitole 6.3.8 u technologie Flash, kde je využito vlastnosti virtuální procházky a jednotlivých viewpointů. V této implementaci scény se avatar může libovolně pohybovat a pouze na viewpointy se tak odkazovat nelze.

6.2. WEBGL 49 Objekt Plná verze Zjednodušená verze Terén, střecha 800 190 Kostel stavba 3400 1480 Varhany 6900 470 Oltář 2950 70 Kazatelna 1200 130 Kříž v kostele 300 40 Lavice 1700 420 Doplňky (obrazy, stromy) 1500 500 Celkem 18750 3300 Tabulka 6.1: Porovnání počtu polygonů v plné a ve zjednodušené verzi scény Co ale můžeme provést, je dynamicky měnit počet objektů ve scéně podle polohy avatara vně či uvnitř objektu. Jedním z náročnějších objektů, pokud jde o počet polygonů, je např. přední stěna kostela. Pokud se ovšem avatar nachází uvnitř, nemusíme přední stěnu ve scéně mít. Stejným způsobem pak lze odstranit terén, střechu kostela nebo objekty typu varhany, oltář a další vnitřní vybavení. Zmíněný algoritmus je umístěn ve funkci, která při pohybu avatara pomocí šipek, nebo animace zjišťuje jeho polohu a poté provádí příslušné kroky přidání/odebrání objektu. Jedná se tedy o funkci pohybmozny(), která podle polohy rozhoduje, kde se avatar nachází. Funkci navíc voláme i během animace přechodu mezi viewpointy. Výsledky návratových hodnot nás zde sice nezajímají, protože během animace kolize nepočítáme, volání funkce ovšem umožní zapnutí viditelnosti objektů přesně ve chvíli, kdy animace přesouvá avatara dovnitř kostela či ven. Nenastane tak situace, že avatar po animaci přesunu vidí pouze prázdný kostel, a až po stisknutí šipky, kdy se provede volání funkce, se objekty zobrazí. Zároveň nemusíme volat funkci při každém obnovení obrazovky a neprovádíme tak zbytečné operace. Dalšími optimalizačními technikami z hlediska počtu polygonů se zabývala literatura [Šrám(2010)] při samotném vytváření virtuálního modelu.

50 KAPITOLA 6. REALIZACE 6.2.11 Shrnutí a výsledky měření obou verzí V technologii WebGL se nám podařilo vytvořit požadovanou scénu v původní složitosti 3D modelu včetně galerie, a to s příznivými výsledky měření FPS na běžné konfiguraci počítače. Ve scéně byly použity vlastnosti, které nabízela i technologie VRML, ve které byl model původně využit. Jedná se tak především o pohyb avatara, virtuální procházku, animaci dveří či omezení pohybu. Výsledky měření FPS plnohodnotné i zjednodušené verze scény ukazuje tabulka 6.2, shrnutí hodnot FPS všech viewpointů virtuální procházky obou verzí poté zobrazují grafy 6.8 a 6.9. Obrázek 6.7: Zjednodušený model scény v technologii WebGL Pro měření byla využita následující konfigurace: Procesor: Intel(R) Core(TM)2 Duo CPU T6600 2.20GHz, Operační paměť: 4GB, Verze systému: Microsoft Windows 7 (x64),

6.2. WEBGL 51 Grafická karta: ATI Mobility Radeon HD 4500. Pozn. Při pohybu avatara se obě scény pohybují okolo 27 FPS. Verze Viewpoint FPS Pohled od dveří na oltář 16 Pohled na pravou galerii 20 Plná verze Pohled od oltáře do kostela 15 Pohled z balkonu 16 Celá scéna 15 Pohled od dveří na oltář 18 Pohled na pravou galerii 21 Zejdnodušená verze Pohled od oltáře do kostela 17 Pohled z balkonu 18 Celá scéna 16 Tabulka 6.2: Porovnání měření FPS pro viewpointy obou verzí scén technologie WebGL Obrázek 6.8: FPS virtuální procházky zjednodušené verze scény WebGL

52 KAPITOLA 6. REALIZACE Obrázek 6.9: FPS virtuální procházky plné verze scény WebGL Hlavní aspekty programu: Zjednodušená druhá verze Interaktivní tlačítko u schodů uvnitř kostela Omezení pohybu u varhan LOD varhan Pohyb avatara, standardní vstup, chození (fixní souřadnice y) Omezení pohybu pomocí algoritmu Virtuální procházka animace kamery Animace dveří Propojení s aplikací galerie Navigační prvky Počet řádků programu cca 1050(bez galerie) + použité knihovny

6.3. FLASH 3D 53 6.3 Flash 3D V této kapitole je kompletně popsán vývoj virtuální scény v technologii Flash3D s využitím frameworku Papervision3D a programovacího prostředí Adobe Flash Builder. K programovací části patří zmínka o rozdílu mezi vývojovými prostředími Flash a Flex. Při vytváření multimediální prezentace v technologii Flash si mnozí nejprve představí prvky, jako jsou banery, obrázky, přechody, či klasické animace, závislé na čase. V našem případě však neexistuje při vývoji žádná věc, jakou je např. časová osa a další vlastnosti typického Flashe. Programování bude probíhat pod prostředím Flex. Flex je na rozdíl od Flashe čisté programování pomocí ActionScriptu, kde program scény píšeme v objektově orientovaném jazyce, podobnému jazyku Java či JavaScript. Adobe Flex je tedy jakýsi soubor tříd, komponent a nástrojů, určený pro vývoj aplikací s cílovým formátem SWF. Zatím co zdrojové soubory klasického Flashe jsou uloženy jako soubor s příponou FLA, k jehož otevření potřebujeme mít nainstalované vývojové prostředí Flash IDE, Flex obsahuje zdrojové soubory, které lze editovat v jakémkoli textovém editoru. Přípona souborů je ac (ActionScript) a jejich obsahem je zdrojový kód aplikace ve formě textu. Po kompilaci zdrojových souborů získáme výsledný SWF formát dat, který je shodný s formátem Flashe a lze klasicky spustit v Adobe prohlížeči. Ačkoli lze program psát v jakémkoli textovém editoru, v našem případě jsme se rozhodli využít prostředí Adobe Flash Builder, které je podobné např. prostředí Netbeans a poskytuje programátorovi prvky usnadňující a urychlující vývoj aplikace, včetně kompilátorů apod. Pro studenty je navíc k dispozici zdarma. Pokud uživatel nemá k dispozici popsané vývojové prostředí, má k dispozici další možnosti [Allen Others(2008)Allen, Others], kterými jsou např.: IDE Flash Develop nebo IDE Eclipse. Detailním návodem pro použití těchto prostředí včetně debugovacích procesů a kompilací se zabývá literatura [Allen Others(2008)Allen, Others]. 6.3.1 Použité frameworky, technologie a pracovní postup Pro vývoj scény v technologii Flash jsme se rozhodli využít framework Papervision3D, který je určen pro realizaci virtuálních objektů a scén v zobrazovacím prostředí Flash. Důvodem byla především komplexnost celého frameworku a dále také menší složitost vývoje, než např. pod konkurenčním frameworkem Yogurt3D. Pro realizaci objektů z původní scény bylo, stejně jako při vývoji ve WebGL, využito formátu Collada verze 1.4, který Papervision3D umí načíst a zpracovat. Při exportování objektu z modelovacího software jsme tedy ušetřili jeden krok při vytváření scény ve více technologiích, protože všechny v této práci implementované technologie umožňují využití právě tohoto formátu dat. Data scény jsou tedy totožná s daty, které obsahuje zjednodušená verze scény pro technologii WebGL. Pracovní postup pro vytvoření scény od počátečního modelu s využitím dat galerie je zobrazen na obrázku 6.10. 6.3.2 Implementace scény V této kapitole bude detailně popsán postup pro vytvoření virtuální scény a vložení objektů typu Collada. Tyto objekty jsou obsahově shodné s objekty zjednodušené scény, použité pro

54 KAPITOLA 6. REALIZACE Obrázek 6.10: Pracovní proces vytvoření scény v technologii Flash3D technologii WebGL. Pro vytvoření základu scény nám postačuje vytvoření několika prvků kamery, viewportu, scény a poté již můžeme spustit cyklické renderování. Na počátku je však nutné správně umístit získané soubory knihoven a inicializovat projekt v prostředí Adobe Flash Builder [Adobe(2012)], které jsme k vývoji celé aplikace použili. Detailní popisy objektů typu kamera, viewport nebo scéna blíže popisuje literatura [Lively(2010a)]. Knihovny frameworku Papervision3D lze stáhnout přímo z oficiálního webu organizace, stejně jako další potřebnou knihovnu pro práci s animací. Animaci se blíže věnuje kapitola 6.3.5. Prvním krokem pro implementaci je založení tzv. Action Script projektu ve vývojovém prostředí, které nám poskytne vše potřebné pro vytvoření scény. Soubory získaných frameworků poté umístíme do kořenového adresáře aplikace do podsložky src. Vývojové prostředí by mělo soubory automaticky načíst. Tento proces lze urychlit výběrem operace Refresh, kterou využijeme i při případných změnách nebo laděních aplikace. Po založení projektu následuje vytvoření základu scény, kterým je inicializace kamery, algoritmu pro vykreslení scény a dalších nastavení (pozice kamery, body pohledu viewpointy a další). První kód, který musíme do programu vložit je inicializace proměnných, které budeme dále v aplikaci používat. Základem jsou proměnná pro scénu - Scene3D, viewport - Viewport3D, kameru - Camera3D a vykreslovací algoritmus BasicRenderEngine (nebo pokročilý kvadrátový algoritmus - QuadrantRendererEngine). Dále definujeme objekty typu Collada, do kterých budeme načítat data a dále s nimi pracovat. Vzhledem k problémům při práci s texturami je nutné definovat i seznam použitých materiálů pro daný objekt, tzv. materiallist, a to ke každému objektu, na kterém chceme, aby se zobrazovala textura. Soubory textury načteme do proměnných typu BitmapFileMaterial pro každý obrázek s texturou. Další implementací je virtuální procházka, která pracuje s viewpointy. Těm tedy nadefinujeme dvě pole. Jedno pro souřadnice kamery viewpointu a druhé pro rotace kamery na dané souřadnici.

6.3. FLASH 3D 55 Při implementaci virtuální výstavy budeme potřebovat XML soubor s konfigurací galerie, kterému musíme vytvořit proměnné typu XML, které budou reprezentovat data souboru a dále metodu pro načtení souboru typu URLLoader. Nyní implementujeme hlavní funkci programu, zobrazenou v následujícím kódu. //Hlavní funkce aplikace public function MyCollada() { setuppv3d(); //volání funkce pro nastavení scény setupviewpoints(); //nastavení viewpointů //Nastavení objektů typu Collada do scény addcollada(); addkorpus(); addprednistena(); addskybox(); //Vložení objektů do scény addobjectstoscene(); //Vložení objektů uvnitř kostela do scény addobjects(); //Nastavení galerie podle konfiguračního XML souboru myloader.load(new URLRequest("xml.xml")); myloader.addeventlistener(event.complete, processxml); //Nastavení head-up displeje createbuttons(); } //Nastavení události při obnovení scény addeventlistener(event.enter_frame, loop); //Reakce na vstup z klávesnice a na akci myši stage.addeventlistener(keyboardevent.key_down, onkeyup); stage.addeventlistener(mouseevent.mouse_move, onmousemove);... Všechny části implementace budou popsány níže. Základní funkcí je funkce setuppv3d, viz kód níže, ve které celou virtuální scénu vytvoříme. V této funkci definujeme objekty typu scéna, viewport, kamera či vykreslovací algoritmus s možností dalšího nastavení každého objektu. Zejména objekt kamera nás bude zajímat, protože bychom měli nastavit požadované iniciální informace o pozici a rotaci tak, abychom scénu správně zobrazili a mohli případně ladit další detaily. Výhoda použitého vývojového prostředí je především rychlá interakce, našeptávání či kontroly a report chyb směrem k programátorovi.

56 KAPITOLA 6. REALIZACE private function setuppv3d():void { stage.quality = StageQuality.LOW;//nastavení kvality hl. scény(stage) scene = new Scene3D(); vp = new Viewport3D(500,400,false,true); //Nastavení kamery a její pozice cam = new Camera3D(); cam.fov = 45; cam.x = -105; cam.y = 930; cam.z = -2380; cam.rotationx = 4; cam.rotationy = 0; cam.rotationz = 0; //Renderovací algoritmy - základní a pokročilý(quadrant) bre = new BasicRenderEngine(); bre2 = new QuadrantRenderEngine(QuadrantRenderEngine.CORRECT_Z_FILTER); } //vložení viewportu addchild(vp);... Dalšími důležitými metodami hlavní funkce jsou funkce pro přidávání objektů do scény. V každé takové funkci bychom měli definovat seznam materiálů objektu, nastavit mu textury s názvy částí, ke kterým textura patří a dále správným způsobem načíst zdrojová data objektu. Poté již lze vložit objekt do scény. Kód níže popisuje příklad pro vložení objektu se skyboxem včetně vytvoření seznamu materiálu a jedné textury. //Vytvoření materiálu ze souboru var frontmat:bitmapfilematerial = new BitmapFileMaterial ("front.jpg"); //Vytvoření kontejneru pro materiály objektu var materialslist:materialslist = new MaterialsList(); materialslist.addmaterial(frontmat,"front"); //přidání textur //Vytvoření objektu typu Collada se seznamem materiálů private var skybox = new Collada("flash_skybox.dae",materialList); scene.addchild(skybox); //vložení do scény...

6.3. FLASH 3D 57 Další metoda addobjectstoscene() v našem případě pouze sdružuje všechny operace scene.addchild, které se týkají objektů do námi vytvořené scény. Zejména při ladění programu tak máme na jednom místě možnost rychle měnit objekty, které chceme ve scéně vykreslit. Popis implementace virtuální výstavy a implementace navigačních prvků včetně HUD je popsán v kapitolách 6.3.6 - Implementace galerie a 6.3.3 - Implementace navigace a HUD. Posledním krokem pro správné zobrazení je definování funkce pro poslouchání událostí eventlinsteneru, pro cyklické vykreslování scény s parametrem volané funkce. V našem případě voláme funkci loop, ve které voláme vykreslovací funkci objektu renderer s parametry scény, kamery a viewportu. V této funkci máme možnost volat jakoukoli operaci, kterou chceme provést při každém vykreslení scény. Může to být například rotace objektu kolem osy y, což lze využít při počátečním ladění aplikace. Lze tak vidět objekt postupně ze všech stran, aniž bychom museli předem implementovat pohyb kamery ve scéně a další navigační prvky. 6.3.3 Implementace navigace a HUD Pokud chceme vytvořit základní navigaci, máme možnost volby mezi vstupem z klávesnice, myši, nebo lze vytvořit tzv. head-up display, který se uživateli při procházce virtuální scénou bude zobrazovat vždy v pozici před kamerou tak, aby byl zřetelně vidět. Tento display poté obsahuje tlačítka a další navigační prvky. V našem případě lze aplikaci ovládat jak pomocí klávesnice, tak pomocí tohoto displeje. Vstup z klávesnice musíme nejprve inicializovat tak, že do hlavní funkce třídy přidáme eventlistener, který poslouchá události z klávesnice a volá funkci při nějaké aktivitě. Funkce poté podle kódu klávesy provede operaci nebo zavolá další funkci. To lze v ActionScriptu pod Flexem bez problémů implementovat. Výsledkem je možnost přecházení směrem vpřed či zpět (klávesa PageUP/PageDown) nebo otevírat či zavírat dveře kostela (mezerník). Poněkud složitější je situace s implementací head-up displeje, dále jen HUD, který musí ve třídě být vytvořen jako prvek typu Sprite. Ten poté přidáme do scény jiným způsobem, než tomu bylo např. u objektů typu Collada. Jedná se totiž o 2D panel, který musíme ručně vytvořit a nakreslit, neboť ve Flexu při implementaci virtuální scény nemáme k dispozici klasická tlačítka, která známe např. z HTML, a které se ve Flashi běžně používají. V hlavní třídě tedy implementujeme funkci pro vytvoření tlačítka ve tvaru šipky. Funkci popisuje následující kód. protected function createbutton():sprite { var btn:sprite = new Sprite(); //tlačítko bude objekt typu Sprite btn.graphics.beginfill(0x333333); //začátek vyplňování polygonu btn.graphics.moveto(0, 0); //postupné určení hranic btn.graphics.lineto(0, 20); btn.graphics.lineto(10, 10); btn.graphics.lineto(0, 0); btn.graphics.endfill(); //konec vyplňování polygonu

58 KAPITOLA 6. REALIZACE } return btn; //vrátíme hotový tvar... V další funkci již pomocí předchozí metody vytváříme jednotlivá tlačítka, přiřazujeme parametry jako pozici, velikost, událost po kliknutí a umisťujeme je do hlavní scény, tzv. stage. Zobrazení tohoto prvku je však odlišné než u objektů. Provádí se voláním obecné metody addchild, bez přiřazení k našemu objektu typu 3D scéna, jako tomu bylo u virtuálních objektů typu Collada (scene.addchild). Tím docílíme fixního zobrazení tlačítek na obrazovce, která se jeví, jakoby byla umístěna před kamerou, ale nepohybují se tak v závislosti na pohybu kamery. K prvkům máme možnost vytvořit textová pole s popisem tlačítek, která se vytváří jako další objekt typu TextField. K textovému poli máme možnost přidat formát pomocí vytvoření dalšího objektu typu TextFormat. Jak lze vidět, programování ve Flexu je objektové, někdy však tyto objekty, které musí být vytvořeny i na prosté formátování jednoduchého textu, mohou překážet a zbytečně zdrojový kód prodloužit. Pro pouhé zobrazení jednoho popisku tlačítka tak potřebujeme ve zdrojovém kódu 8 řádků. Ukázka zdrojového kódu pro zobrazení jednoho tlačítka s popiskem (pro další je postup analogický), kterému nastavíme po kliknutí událost, zobrazuje kód níže. protected function createbuttons():void { rightbtn = createbutton();//vytvoření obrázku tlačítka addchild(rightbtn); //přidání do hl. scény (stage) rightbtn.buttonmode = true; //zapnutí módu pro tlačítko //Přidání funkce volané po kliknutí rightbtn.addeventlistener(mouseevent.click, buttonnext); //Nastavení pozice tlačítka rightbtn.x = stage.stagewidth - 120; rightbtn.y = stage.stageheight / 2; //Vytvoření textového popisku a objektu formát pro popisek var format:textformat = new TextFormat("Arial, Helvetica, _sans", 8, 0x333333); var text:textfield = new TextField(); //pole pro text text.width = 19; //šířka textovéno pole text.text = "next"; //nastavení textu typu String text.settextformat(format); //přiřazení formátu k textu addchild(text); //vložení do stage } //Nastavení pozice popisku text.x = stage.stagewidth - 142; text.y = (stage.stageheight / 2)+2;

6.3. FLASH 3D 59 Dalším prvkem uživatelského rozhraní neboli navigačního panelu bylo vytvoření osy virtuální procházky, která v každém okamžiku naznačuje, ve které fázi se uživatel nachází. K dispozici jsou i názvy jednotlivých viewpointů, neboli míst procházky. Uživatelské rozhraní s navigačními prvky je zobrazeno na obrázku 6.11. Vzhledem k optimalizaci scény, popsané v kapitole 6.3.8 - Optimalizace vykreslování, LOD, není umožněno přecházet mezi body procházky libovolným způsobem, jako tomu je např. ve VRML nebo WebGL. Důvodem je, že v každém bodě vidíme pouze některé objekty, což je v aplikaci nastaveno předem (neboť víme, kde se bude avatar nacházet a co uvidí) a při každém přechodu mezi dvěma body se objekty ve scéně dynamicky mění podle předchozího/budoucího a současného bodu pohledu. Při přeskoku na libovolný bod procházky by se tak stávalo, že uživatele animace přesune poloprázdným kostelem, nebo že věci budou během animace mizet tak, aby vyhovovaly výslednému bodu pohledu. Animace však trvá několik sekund, takže by uživatel mohl být z používání aplikace poněkud zmatený. Obrázek 6.11: Uživatelské rozhraní pro technologii Flash3D

60 KAPITOLA 6. REALIZACE 6.3.4 Řešené problémy Technolgoie Flash se setkává s mnohými problémy při využití frameworků, zobrazujících 3D virtuální realitu. Především se složitějšími tvary těles a mnoha polygony si tato technologie neumí zcela poradit. Jedná se zejména o tzv. z-sorting problem 6.12. Kompletní porovnání a zmíněné nedostatky jsou blíže rozpracovány v kapitole 4 - porovnání technologií pro reprezentaci budov na webu. Obrázek 6.12: Z-sorting problem při použití Basic renderer algoritmu Z hlediska naší konkrétní implementace tak muselo být realizováno několik omezení, aby se výsledný vjem nekorektního a chybného zobrazení scény minimalizoval. Jedním z omezení je pohyb avatara (kamery) po scéně, který je zde realizován pouze jako předem nastavená virtuální procházka, jejíž realizaci blíže popisuje kapitola 6.3.5 - Virtuální procházka scénou a animace. Při pohybu scénou se mnohdy stává, že některé polygony, zejména při použití základní renderovací techniky, tzv. Basic, prosvítají před jinými nebo úplně mizí. Technologie se při využití této vykreslovací metody neumí dobře vypořádat s tzv. z-sortingem a některé polygony dále od pozorovatele jsou nekorektně zobrazeny v popředí. Řešením této situace je např. využití pokročilého vykreslovacího algoritmu s názvem Quadrant, který je ovšem o poznání náročnější pro výpočet. Virtuální procházka zůstává stejná, ovšem uživatel musí

6.3. FLASH 3D 61 být více trpělivý, protože celá scéna je i přes zjednodušení oproti původnímu modelu mírně zpomalená. Problémy a řešení vykreslování dobře popisuje literatura [Lively(2010a)], kde autoři uvádí několik možností, jak se se z-sortingem vypořádat. Avšak naše implementace neumožňuje navrhovaná řešení plně využít. Jednou z možností je např. vykreslování objektů do vrstev, čímž však zpomalíme výpočet scény a problém tím i tak zcela nevyřešíme. Naše pokusy s těmito řešeními nebyly zcela úspěšné. Předpokládáme, že problém je především ve vysokém počtu polygonů ve scéně, se kterým má technologie Flash problémy. Ve výsledku jsme se rozhodli využít pokročilého vykreslovacího algoritmu s optimalizací vykreslování objektů, popsaným níže. Zjednodušený model scény používáme právě hlediska velké náročnosti původního modelu. Plná verze modelu je složena z cca 19 000 polygonů, což by v případě této technologie nebylo možné v reálném čase vůbec zobrazit při použitelných hodnotách FPS. Byl tedy vytvořen a použit zjednodušený model, stejně jako v kapitole 6.2.9 - Vytvoření zjednodušené verze scény, u techologie WebGL. Kompromisem mezi výkonem a kvalitou se stala nabídka několika verzí, které se liší právě v technice vykreslování scény. Uživatel má tedy ve výsledku možnost zvolit méně kvalitní, plynulou a rychlou prohlídku, či více kvalitní, ale výpočetně náročnější prohlídku kostela, obě včetně virtuální výstavy obrazů, generované webovou aplikací. Dalším problémem, se kterým jsme se při programování scény setkali, je nekorektní zobrazení některých textur i přes správné nastavení jejich UV souřadnic. Tento problém ale nastává jen u několika případů a uživateli tak nebude působit újmu na vizuální kvalitě zobrazení. Problém s texturami je patrný především na objektu schodiště nebo na pravé vnitřní stěně ihned za dveřmi kostela. Korektní mapování textur bylo ověřeno nejen v modelovacím software, ale především v technologii WebGL, která ve zjednodušené verzi používá totožné soubory objektů typu Collada, které se používají ve scéně zde. Programátor má sice k dispozici několik prvků, které mají pomoct korektně texturu zobrazit (jedná se především o parametr textury nazvaný percise, tedy přesnost) za cenu náročnějšího výpočtu a tím i zpomalení scény, ale ani to někdy nemá vliv a chyba se i přes to projeví. S texturami má obecně dle našeho výzkumu technologie Flash problém. Při zpracování objektů z formátu Collada dochází k chybě čtení cesty k souborům textury, takže se ve scéně zobrazí pouze obrysové hrany těles. Problém byl vyřešen vytvořením objektu typu materiallist, do kterého se všechny textury, definované jako BitmapFileMaterial, tedy materiál načtený ze souboru, přidají. Tento postup není pro tvůrce scény příjemný, je však řešením daného problému. Znamená totiž několik desítek řádků v programu navíc a nutnost vyhledání názvu textur s jejich přiřazením k objektům přímo v souboru objektu typu Collada. Vyhledání ale na druhou stranu není problém, protože zdrojový soubor dat je z modeláře exportován ve velice přehledné formě. Korektnost exportovaných dat byla opět ověřena v konkurenční technologii WebGL, která s týmiž soubory nemá problém, textury najde a bez problémů zobrazí. Zvolený přístup, ve kterém využíváme strukturu materiallist je popsán i jako oficiální řešení problému s texturami v literatuře [Winder Tondeur(2009)Winder, Tondeur], pokud potřebujeme v technologii Flash zobrazit v jednom objektu typu Collada textury z více souborů najednou.

62 KAPITOLA 6. REALIZACE 6.3.5 Virtuální procházka scénou a animace Jak již bylo zmíněno v kapitole předešlé, pohyb uživatele scénou je omezen na virtuální prohlídku z předem daných stanovišť - viewpointů, což má zamezit chybnému zobrazení scény při konkrétních bodech zájmu. Jednotlivé viewpointy se sestávají ze 3D souřadnic a rotace, kterou kamera zaujímá. Pro uložení těchto hodnot byla vytvořena dvě pole, podobně jako v technologii WebGL, které naplníme předem danými hodnotami. Hodnotami jsou 3D souřadnice cílového místa a tři hodnoty rotace podle jednotlivých os souřadného systému. Viewpointů ve scéně je celkem 20 a jsou rozloženy nejen uvnitř kostela, ale i vně, aby bylo možné si stavbu prohlédnout ze všech stran. Pro animaci kamery mezi jednotlivými viewpointy používáme externí knihovnu Tween- Max [Doyle(2011)], která nám umožní realizaci plynulého přechodu mezi souřadnicemi i s použitím rotací [Lively(2010a)]. Přechod mezi viewpointy byl realizován pomocí grafických navigačních prvků, i pomocí klasického vstupu z klávesnice klávesami Page Up/Down, jako tomu je i u ostatních implementací téže scény. Dveře kostela je možné otevřít a zavřít pomocí mezerníku, nebo tlačítkem na HUD. Přechod mezi viewpointy a parametry funkce TweenMax ukazuje následující kód. public function move():void { //Zjištění rotace a pozice pro viewpoint var dir:number3d = viewpoint_dir[actual_viewpoint]; var num:number3d = viewpoint[actual_viewpoint]; } //Volání funkce pro přechod mezi viewpointy s parametry pozice, //rotace a typu animace TweenMax.to(cam, 2, {x:num.x, y:num.y, z:num.z, rotationx:dir.x, rotationy:dir.y, rotationz:dir.z, ease:quad.easeout});... Animace dveří kostela je implementována podobně, jako pohyb kamery, tedy pomocí funkce TweenMax externí knihovny. Před animací je však nutné, aby byl model při exportu z modelovacího software umístěn v počátku souřadného systému, kolem kterého implicitně rotuje. Poté při importu objektu do scény změníme jeho souřadnice na požadované místo a můžeme spouštět animaci. V animaci dveří ponecháme souřadnice na počáteční hodnotě, měníme pouze hodnoty rotace dveří a ukládáme si informace o stavu, ve kterém se dveře nachází. Ovládání této animace může uživatel provést z ovládacího panelu popsaného v kapitole 6.3.3. 6.3.6 Implementace galerie Pro realizaci virtuální výstavy obrazů existuje v této technologii několik možných přístupů. Prvním z nich je generování zdrojového souboru pomocí aplikace. Tento zdrojový soubor by

6.3. FLASH 3D 63 obsahoval jak data a nastavení scény, tak i nastavení a data galerie. Technologie Flash a s tím i Flex, tedy programovací část celku, je však nutno před publikací vždy zkompilovat. Tím se vytvoří výsledný swf soubor, který již uživatel může spustit a prohlédnout. Bez tohoto mezikroku není spuštění programu možné. Tento způsob se nám jevil jako zbytečně výpočetně náročný, navíc s dalším krokem navíc, kterým je právě kompilace na serveru. Celý proces vytváření virtuální scény s galerií by se tak zpomalil. Druhý, námi zvolený přístup, je vytvoření aplikace scény, která bude po kompilaci uložená na serveru a data galerie pro ni budeme generovat do konfiguračního XML souboru, který aplikace přečte a objekty typu obraz podle něj vytvoří. Tato varianta je rychlejší, více elegantní a nepotřebuje ke svému vytvoření vždy projít krokem kompilace. V programu scény však potřebujeme provést několik změn. Především se jedná o metodu pro čtení a zpracování konfiguračního souboru galerie, který je generován webovou aplikací spravující galerii a vypadá následovně: <?xml version="1.0" encoding="utf-8"?> <GALLERY> <IMAGE TITLE="p1" POSITION="34;81;47" ROTATION="0;85;0" SCALE="1;1;1">1.jpg</IMAGE> <IMAGE TITLE="p1" POSITION="30;81;33" ROTATION="0;15;0" SCALE="1;1;1">2.jpg</IMAGE> <IMAGE TITLE="p1" POSITION="27;81;59" ROTATION="0;43;0" SCALE="1;1;1">3.jpg</IMAGE> </GALLERY> V metodě pro zpracování vytvoříme smyčku, která pro všechny obrazy, definované ve virtuální výstavě, provede jejich inicializaci a vložení do scény, a to s individuálním nastavením parametrů, kterými jsou zde textura obrazu, pozice, rotace a měřítko. Metodu pro zpracování galerie ve výsledné prezentaci technologie Flash naznačuje následující kód. V implementaci algoritmu je využito vlastnosti, kdy se obraz skládá ze dvou částí rámu obrazu a plátna. Rám má vždy pevně definovanou texturu dřeva. Plátnu texturu nastavujeme podle XML souboru. Poté jsou již všechny ostatní vlastnosti (rotace, pozice, měřítko) pro oba objekty nastavovány shodně, také podle vstupu z XML konfigurace virtuální galerie. private function processxml(e:event):void { myxml = new XML(e.target.data); //objekt pro XML soubor //Vytvoření material listu pro rám obrazu a přiřazení textury var materiallist_ram:materialslist = new MaterialsList(); var bitmapmaterial_ram:bitmapfilematerial = new BitmapFileMaterial ("textury/tmave_drevo_2.jpg"); materiallist_ram.addmaterial(bitmapmaterial_ram,"tmave_drevo_2_jpg"); //Generování obrazů podle konfiguračního XML souboru for(var i:int = 0; i<myxml.*.length(); i++){ //pro každý obraz v XML cesta = new String(myXML.IMAGE[i]); //cesta k texture obrazu //Vytvoření material listu k plátnu a nastavení textur z XML var materiallist_image:materialslist = new MaterialsList();

64 KAPITOLA 6. REALIZACE var bitmapmaterial_image:bitmapfilematerial = new BitmapFileMaterial(cesta); bitmapmaterial_image.doublesided=true; //obraz bude oboustranný kvůli otáčení materiallist_image.addmaterial(bitmapmaterial_image,"all"); if(myxml.image[i].@title=="p1"){ //typ p1 - pro šířku //Vložení plátna var obraz:collada = new Collada("obraz_platno.dae",materialList_image); }else if(myxml.image[i].@title=="p5"){ //typ p5 - pro výšku //Vložení plátna var obraz:collada=new Collada("obraz_vyska_platno.dae",materialList_image); } //Nastavení pozice obrazu var temp:array = myxml.image[i].@position.split(";"); obraz.x = temp[0]; obraz.y = temp[1]; obraz.z = temp[2]; //Nastavení rotace obrazu var temp2:array = myxml.image[i].@rotation.split(";"); obraz.rotationx=temp2[0];obraz.rotationy=temp2[1];obraz.rotationz=temp2[2]; //Nastavení měřítka obrazu temp2 = myxml.image[i].@scale.split(";"); obraz.scalex = temp2[0]; obraz.scaley = temp2[1]; obraz.scalez = temp2[2]; scene.addchild(obraz); //Vložení obrazu do scény obraz obrazy.push(obraz); //Přidáme obraz do pole kvůli pozdější optimalizaci } //pro rám obrazu je postup analogický } //Nastavení viditelnosti pro ceou galerii na hodnotu false - na //prvním viewpointu galerii nevidime, protože jsme vně kostela for(var i:int = 0; i<obrazy.length; i++){ var obraz:collada = obrazy[i]; obraz.visible=false; }... Při vkládání objektů obrazů bylo myšleno i na budoucí optimalizaci. Obrazy bude potřeba odebírat a přidávat do scény, pokud je budeme chtít zobrazit. To realizujeme vytvořením pole, do kterého všechny objekty obrazů při jejich vytváření uložíme. Při potřebě přidání/odebrání obrazů ze scény tak pouze projdeme toto pole a každému prvku nastavíme parametr visible na hodnotu true/false. Na začátku scény tak obrazy ve scéně vidět nebudou, neboť se při prvních 4 krocích procházky díváme na kostel pouze z venku. Webová aplikace pro správu virtuální výstavy se změní v modelu typu obraz, kterému

6.3. FLASH 3D 65 přidáme další vlastnosti - pozici, měřítko a rotaci pro technologii Flash. Texturu obrazu lze využít tutéž, jako pro technologii WebGL. Při vytváření nové výstavy v aplikaci musely být upraveny jednotlivé šablony obrazovek, aby nyní obsahovaly i data pro tuto technologii, což ale nebyl větší zásah. Stejně tak musel být upraven soubor pro generování výstavy, kde jsme přidali sekci pro generování XML souboru. Další změnou bylo řešení změny měřítka, pro které musí uživatel ve webové aplikaci přejít do sekce Editace, a až zde měřítko mění. Dělá to však jen pro technologii VRML. Problém byl vyřešen stejným způsobem jako u předchozí technologie WebGL, a to tabulkou pro přepočet změny měřítka vycházejícího z hodnot pro technologii VRML. Přepočet souřadnic probíhá ve třídě, která modifikuje jednotlivé objekty typu obraz, které uživatel měnil, tedy ve třídě GalleryBean. Pro každé měřítko obrazu je tak určeno optimální měřítko pro technologii Flash. Výsledek se poté objektu nastaví a uloží. 6.3.7 Dvě verze scény Při implementaci virtuální scény ve stejném rozsahu jako v technologii VRML jsme došli ke zjištění, že počet polygonů nebude možné v takové míře zobrazit se zachováním alespoň minimální plynulosti scény. Technologie Flash neumožňuje při režimu 3D použít hardwarovou akceleraci a tím se její využití markantně zužuje. Pro zjištění přibližných mezních hodnot, které technologie zobrazit dovoluje byly sestaveny testovací scény, které jsou blíže popsány v kapitole 4.35. Aby bylo možné objekt alespoň v nějaké podobě přenést k uživateli využitím této technologie, byly podniknuty kroky zjednodušení celé virtuální scény. Celkový počet polygonů však nebylo možné snížit na méně než cca 3300 plošek. Porovnání složitosti obou scén popisuje tabulka 6.1. Uživateli jsou nabídnuty dvě verze scény. Obě scény používají totožná data virtuálních objektů. První aplikace však obsahuje tzv. základní vykreslovací algoritmus, který však nezobrazuje scénu zcela korektně kvůli problémům při z-sortingu. Lehce se tak stane, že při pohledu zvenčí vidí uživatel objekty za stěnou nebo je část stěny průhledná i když by být neměla. Ačkoli byly podniknuty optimalizace a pokusy o zlepšení tohoto problému, nepodařilo se chybné vykreslování při použití základního algoritmu zcela vyřešit. Z-sorting problem je bohužel vlastností tohoto algoritmu. Druhá verze aplikace využívá pokročilého vykreslovacího algoritmu, který již scénu zobrazuje korektně tzv. Quadrant render engine [Lively(2010a)], má však podstatně větší výpočetní náročnost a tím pádem se ne každému uživateli podaří scénu zobrazit při vysokých hodnotách FPS. Načítání trvá o několik procent déle a plynulost scény není zaručena ze všech předem definovaných pohledů. Vykreslení však již probíhá ve většině případů v pořádku. Důležité optimalizační kroky jsou popsány v kapitole 6.3.8 - Optimalizace vykreslování, LOD. 6.3.8 Optimalizace vykreslování, LOD Pro velkou náročnost pokročilého vykreslovacího algoritmu, použitého v druhé implementaci virtuální scény, musely být podniknuty optimalizační kroky, které mají za cíl zjednodušení celé scény, co se počtu polygonů týče. Pro toto zjednodušení byla vytvořena konstrukce

66 KAPITOLA 6. REALIZACE typu swich, kterou jsme umístili do funkcí, volaných při kliknutí na navigační prvky virtuální procházky. Tyto konstrukce jsou si velice podobné pro tlačítko vpřed i zpět a fungují následovně: při každé změně pozice (přechodu mezi viewpointy) se zároveň určí, které objekty nemohou být z dané pozice vidět a ty poté ze scény odstraníme. Naopak ty objekty, které vidět jsou, do scény přidáme. Každý viewpoint tak má sadu příkazů typu objekt.setvisible=true/false, kterým objektu říkáme, zda se s ním má ve scéně počítat, zda se renderuje, aniž by to musel počítat algoritmus vykreslování scény. Při průchodu procházkou směrem vpřed i zpět jsou tato nastavení mírně odlišná, proto musí být konstrukce dvě, pro každou z metod směru přechodu. Tímto jsme vlastně implementovali zjednodušené LOD, které má pouze 2 stupně 1 nebo 0. Při virtuální procházce totiž nikdy nevidíme kompletní scénu se všemi objekty. Např. při pohledu z venku kostela je objekt prázdný, při průchodu uvnitř je naopak odstraněna přední ozdobná stěna, terén kolem kostela a střecha, čímž ušetříme výpočty mnoha polygonů. Tímto průběžně vykreslujeme či nevykreslujeme v každém bodu pohledu jen některé objekty. Úpravou bylo dosaženo zrychlení, které již umožňuje pokročilý algoritmus vykreslování reálně použít. Při některých pohledech se sice hodnoty FPS dostávají nízko, takže se scéna někdy na malý okamžik zasekne, ale v ostatních případech je tato scéna dobře použitelná. V literatuře [Lively(2010a)] se autoři zmiňují o dalších typech optimalizace, jako např. nastavení vlastnosti testquad objektu typu Colladana hodnotu false, čímž se objekt nebude renderovat pomocí pokročilého algoritmu, ale pouze algoritmem základním. I tento postup byl vyzkoušen, ale změny nebyly znatelné, proto jsme ho do výsledné aplikace nezahrnuli. Jednou z dalších optimalizačních technik je dynamická změna vykreslovacího algoritmu při běhu programu. Toho lze využít např. v místech, kde základní vykreslování postačuje k zobrazení scény bez kritických chyb ve vykreslování. Jedná se tak o některé pohledy na celou stavbu kostela, kde tímto krokem dosáhneme rapidního zrychlení scény, nebo na některé body zájmu uvnitř virtuálního objektu. Technika byla vyzkoušena, avšak z důvodu zachování co nejlepší kvality scény při použití pokročilého vykreslovacího algoritmu byla ve výsledku nepoužita. Optimalizací se v této implementaci technologie Flash3D stala i samotná zobrazená scéna, neboť došlo k rapidnímu zjednodušení původně složitého, detailního modelu. Dále byly využity textury z technologie WebGL, které jsou v POT tvaru. Samozřejmostí je poté zachování standardních technik, popsaných v literatuře [Šrám(2010)], např. odstranění neviditelných ploch, atd. 6.3.9 Shrnutí a výsledky měření obou verzí Technologie Flash není podle implementace a výsledků provedených měření vhodnou technologií pro zobrazení složitějších scén, obsahující tisíce polygonů. Literatura [Winder Tondeur(2009)Winder, Tondeur] také uvádí, že by se tvůrce scény měl snažit udržet počet polygonů pod 3000 z důvodu zachování plynulosti a rychlosti výpočtů. Při použití základního vykreslovacího algoritmu mohou nastat potíže se zobrazením, stejně jako při potřebě použití textur, které jsou nezbytnou součástí většiny virtuálních scén. Technologie má stále mnoho nedostatků, které ji ve využití virtuální reality posouvají i za starší technologie, jako je např. VRML. Výhodou této technologie zůstává její rozšířenost, ovšem jak dlouho tomu tak bude, není jisté. Celkově bychom tuto variantu doporučili jen pro omezená data, ve

6.3. FLASH 3D 67 smyslu počtu polygonů a náročnosti celé scény. I přes mnohé problémy a nevýhody se podařilo scénu implementovat a zobrazit ji uživateli v alespoň upravené a zjednodušené podobě. Nelze však zaručit úplnou bezchybnost zobrazení a kvalitu scény srovnatelnou např. právě s mnohem starší technologií pro zobrazení virtuálních scén VRML. Výsledek implementace scény s využitím technologie Flash3D zobrazuje obrázek 6.15. Výsledky měření hodnot FPS z několika různých viewpointů ukazuje tabulka 6.3, která tak porovnává použití obou vykreslovacích algoritmů s využitím optimalizace. Výsledné grafy 6.13 a 6.14 pro oba vykreslovací algoritmy poté naznačují průběh hodnot FPS napříč celou virtuální prohlídkou objektu. Verze Viewpoint FPS Pohled od dveří na oltář 25 Pohled na pravou galerii 25 Základní (Basic) vykreslovaní algoritmus Pohled od oltáře do kostela 24 Pohled z balkonu 24 Celá scéna 23 Pohled od dveří na oltář 25 Pohled na pravou galerii 23 Pokročilý (Quadrant) vykreslovací algoritmus Pohled od oltáře do kostela 8 Pohled z balkonu 15 Celá scéna 6 Tabulka 6.3: Porovnání měření FPS pro viewpointy obou verzí scén technologie Flash3D Obrázek 6.13: FPS virtuální procházky při použití Basic renderer algoritmu

68 KAPITOLA 6. REALIZACE Obrázek 6.14: FPS virtuální procházky při použití Quadrant renderer algoritmu Pro měření byla využita následující konfigurace: Procesor: Intel(R) Core(TM)2 Duo CPU T6600 2.20GHz, Operační paměť: 4GB, Verze systému: Microsoft Windows 7 (x64), Grafická karta: ATI Mobility Radeon HD 4500. Hlavní aspekty programu: Virtuální scéna se zjednodušenými objekty Virtuální procházka animace kamery vně i uvnitř kostela Head-up display, navigační prvky Virtuální výstava a propojení s existující webovou aplikací Počet řádků programu cca 1300 + použité knihovny Animace dveří Optimalizace

6.3. FLASH 3D 69 Obrázek 6.15: Zjednodušený model scény v technologii Flash3D

70 KAPITOLA 6. REALIZACE 6.4 Google Earth Samotné technologie Google v sobě zahrnují mnoho podpurných aplikací, pro uživatele i vývojáře. Při realizaci převodu virtuálního objektu do technologie Google Earth jsme využili některých aplikací, které uživateli umožňují data pohodlně konvertovat a zpřístupnit je tak světu v podobě objektu v aplikaci Google Earth. Tato kapitola se tak zabývá převodem zdrojových dat virtuálního modelu do aplikace Google Earth včetně implicitního zobrazení, tedy aby uživatel nemusel model nijak stahovat do svého počítače. 6.4.1 Pracovní postup Kompletní pracovní postup shrnuje obrázek 6.16, ve kterém se chronologicky zobrazují jednotlivé akce a stavy, potřebné pro vytvoření optimálního 3D modelu a jeho úspěšného umístění do aplikace Google Earth. Obrázek 6.16: Pracovního postup realizace modelu v technologii Google Earth Pro realizaci scény v technologii Google Earth využijeme aplikace Google SketchUp, poskytované touto společnosí. Ta umožňuje vytváření, import, úpravu a publikaci modelů do skladu 3D objektů, nazvaného Google 3D Warehouse, a poté i do aplikace Google Earth. Jedná se tedy o jakýsi zjednodušený modelovací software pro tvorbu modelů, převážně pak budov. Aplikace 3D Warehouse tak sdružuje všechny objekty, které si mezi sebou uživatelé mohou sdílet, zobrazovat je v aplikaci Earth, či je vzájemně vylepšovat. Vzniká tím rozsáhlá kolekce různých modelů budov, přístupným všem uživatelům, kteří pracují s aplikací Google Earth. Výstupem z aplikace SketchUp je soubor ve formátu SK. Model po publikaci do 3D Warehouse pak lze stáhnout v několika dalších formátech včetně nativního SketchUp. Jedná se především o formát KMZ a ZIP archiv. KMZ je pouze přejmenovaný ZIP a po jeho rozbalení zjistíme, že obsahem je, stejně jako při rozbalení ZIP archivu, textový soubor s cestami k texturám, adresář s texturami, adresář s modelem ve formátu collada a soubor ve formátu KML. KML se při nainstalované aplikaci Google Earth v této aplikaci otevře a automaticky zobrazí virtuální model objektu. Formát KML je založený na XML, podobně

6.4. GOOGLE EARTH 71 jako např. Collada. Prvotně byl vyvinut společností Keyhole pro publikace geodat, ale později ho koupil Google právě pro svoji aplikaci Earth. 6.4.2 Objekt v modeláři První věc, kterou je třeba realizovat je vytvořit objekt v modeláři. V naší práci máme již tento model hotový z literatury [Šrám(2010)], ale pokud by se jednalo o jeho vytvoření, bylo by potřeba, aby byl model co možná nejjednodušší. Složitější tvary a příliš mnoho ploch by nám později mohlo vadit při pokusu o nasazení modelu do programu Google Earth z hlediska omezujících podmínek popsaných níže. V našem projektu se však zaměříme i na možnost, že objekt je poměrně složitý a bude ho tedy v budoucnu potřeba co nejvíce zjednodušit. Naše práce se dále zabývá tímto případem, protože základní objekt je poměrně složitějších tvarů a věrně kopíruje reálné struktury stavby. Z modeláře pomocí jediného příkazu model exportujeme do formátu Collada, s příponou dae, což bude vstupní formát pro následující aplikaci. Exportování probíhá pomocí doplňku Collada exporter pro modelovací software Blender ve verzi 1.4. podobně, jako tomu bylo u technologií Flash3D nebo WebGL. 6.4.3 Použití Google SketchUp Společnost Google nabízí technologie, prostřednictvím kterých lze model do prostředí Google Earth snadno a rychle vložit. Aplikace Google SketchUp navíc nabízí i možnost vytvoření takového objektu od počátku. Tímto případem se zde ovšem zabývat nebudeme. Lze jen říci, že aplikace poskytuje velice vyspělé techniky pro rychlé učení uživatele s aplikací v podobě tzv. Instruktora, což je chytrá nápověda, zobrazující podrobněji to, co právě s nástroji děláme. Obecně lze říci, že jako všechna uživatelská rozhraní firmy Google jsou velice vyspělá, ani toto není výjimkou. Aplikace je pro nás důležitá z hlediska toho, že Google Earth obsahuje výškové mapy krajiny, neboli terén. Tento terén samozřejmě není dokonalý, ovšem existuje a my musíme objekt do toho terénu správným způsobem zasadit bez toho, aniž bychom modelovali příliš mnoho dodatečného terénu okolo budovy. V nápovědách na webových stránkách se vyskytují případy pro verzi SketchUp 6, my však používáme nejnovější verzi 8 a pro tuto verzi se také náš popis bude dále vztahovat. Před načtením modelu je třeba určit lokalitu, kde se náš objekt bude nacházet. Najdeme ji proto pomocí adresy či ručně pomocí příkazu: File -> Geo-lacation -> Add location. Zde nám nástroj umožní vybrat lokalitu a přidat ji do aplikace. Z výřezu, který při příkazu vybíráme, se stane malý kus terénu, na kterém lze vidět družicový snímek našeho objektu. Výběr výřezu pro lokalitu je zobrazen na obrázku 6.17. Nyní přepneme terén pomocí obrazové ikony v horní liště aplikace, nazvaného Přepnout terén. V aplikaci tak uvidíme 3D terén tak, jak je zobrazován v Google Earth. Naše práce může začít. Nyní je potřeba vložit náš model z modeláře. To provedeme pomocí importu formátu Collady, tedy: File -> Import a vybereme náš dříve uložený model ve formátu Collada. Model může být třeba upravit (zmenšit velikost, přemístit, posunout atd.). K těmto operacím zde slouží velice podobné nástroje jako v modeláři. Poněkud jiné uživatelské operace

72 KAPITOLA 6. REALIZACE Obrázek 6.17: Výběr lokality pro vložení 3D modelu s nástroji se mohou zdát zpočátku nezvyklé, jejich používání je však snadné a po chvíli uživatel nemá problém s nástroji rychle pracovat. Zobrazený model spolu s výřezem výškové mapy je zachycen na obrázku 6.18. V aplikaci SketchUp se model může jevit jako namalovaný. Tato aplikace pro tyto účely může sloužit také. Uživatel má mnoho možností, jak svůj model nakreslit do 3D prostoru a následně rychle obarvit, případně texturovat pomocí vložených textur. Texturování objektu se dále věnujeme v kapitole 6.4.5 - Texturování. 6.4.4 Optimalizace modelu pro Google Earth Velice důležitým tématem, které nelze vynechat, je optimalizace modelu pro cílovou aplikaci. V našem případě má tato aplikace mnoho požadavků (kritérií) pro schválení a vložení objektu do prostředí Google Earth, která však také slouží jako možný návod pro modelování a optimalizaci modelu. Jednotlivá omezení popisujeme níže. Optimalizace modelu je potřeba v každé aplikaci. Je nežádoucí, aby byl model až příliš složitý a obsahoval i části, které nemohou být vidět atd. V tomto případě jde však optimalizace ještě dále. Budovy v Google Earth nemohou zobrazovat vnitřek. Je tedy doporučením

6.4. GOOGLE EARTH 73 Obrázek 6.18: Model zasazený do terénu v Google SketchUp celý vnitřek budovy odstranit, což je první věc, kterou ve SketchUp provedeme. Aplikace pracuje běžným způsobem s plochami, vrcholy a hranami, takže odebírání či přidávání je otázkou několika málo okamžiků. Z modelu byly odebrány všechny vnitřní stěny, podlaha, strop a ostatní položky, které nejsou pro Google Earth nezbytné. Další optimalizací je použití textur u složitějších tvarů. Tuto techniku jsme použili v bakalářské práci při modelování některých složitých části vnitřní výzdoby kostela. Zde bychom mohli zjednodušit pouze přední ozdobnou stěnu, která obsahuje čtyři složitěji modelované sloupy. V našem případě se však počet polygonů již snížil odstraněním vnitřku kostela, proto ji v našem modelu zachováváme. Tato vlastnost navíc přispívá při výsledném zobrazení v cílové aplikaci k věrnosti celého 3D modelu, z důvodu toho, že lze vidět plastické římsy a ozdoby a ne pouze jejich plošné fotografie. Optimalizací rozumíme i další proces, kterým je zasazení objektu do tvarovaného terénu. Tento terén byl již modelován v literatuře [Šrám(2010)]. Zde se však nepatrně liší a proto je třeba proceduru provést a kostel správným způsobem zakotvit do terénu. Některé plochy je třeba mírně upravit (např. prodloužit pomocí nástroje move a tažením za hranu příslušné stěny, nebo pomocí nástroje scale a zvětšením celé požadované plochy). Následně je třeba upravit i texturu upravené plochy. V reálném prostředí se ke schodům kostela jde do mírného kopce, který v Google Earth samozřejmě není, proto je zde možnost terén domodelovat (pokud ho není mnoho) a zajistit tak plynulou návaznost terénu a objektu.

74 KAPITOLA 6. REALIZACE 6.4.5 Texturování objektu V našem případě byl objekt z modeláře již texturovaný, výstup je tak stejný jako pro ostatní zmíněné technologie s výjimkou VRML. V bakalářské práci se texturování provádělo ručně až v souborech wrl, které představují vstupní data pro zobrazení VRML modelu. Texturování, pokud je potřeba, je ve SketchUp jednoduché a v rámci realizace převodu dat mezi modelářem a Google Earth zde popíšeme i techniku texturování v použité aplikaci. Texturování lze v aplikaci provést několika způsoby. SketchUp integruje přidání fotografie pomocí Google Street View, což je obrovská výhoda pro modelování městských budov. Pro náš účel se tato technika nevyužije, neboť kostel je obklopen porostem a z předního pohledu ho zakrývají z pohledu od obecní komunikace stromy. Dalším způsobem je použití předem dodaných jednoduchých textur, které jsou dostupné v okně materiály, které se otevře automaticky po kliknutí na nástroj plechovka barvy, se kterým se poté objekt texturuje. Pro texturování pomocí fotografií či předem připravených textur je třeba nejprve importovat pomocí příkazu File -> Import obrázek a zvolit v příkazu možnost importovat jako texturu. Poté se obrázek zobrazí jako průsvitná plocha, kterou lze nanést na nějaký předmět. Ukázku této operace ilustruje obrázek 6.19. Textura se nám poté uloží do materiálů, kde s ní lze pracovat pomocí plechovky barev. Texturu lze upravovat podle potřeby pomocí příkazu: Texture -> Position. Obrázek 6.19: Nanášení textury pomocí funkce import