eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£ové gra ky a interakce
Bakalá°ská práce
Virtuální model mate°ské ²koly v Pardubicích
Michal Samek
Vedoucí práce: Prof. Ing. Ji°í ára, CSc.
Studijní program: Softwarové technologie a management, Bakalá°ský Obor: Web a multimedia 26. kv¥tna 2010
iv
v
Pod¥kování P°edev²ím bych rád pod¥koval vedoucímu této bakalá°ské práce, panu prof. Ing. Ji°ímu árovi, CSc., nejen za vydání jeho Laskavého pr·vodce, ale hlavn¥ za jeho laskavý p°ístup a poskytnutí cenných rad p°i °e²ení problém·. Dal²í nemén¥ významné pod¥kování pat°í personálu Mate°ské ²koly Kamarád v Pardubicích. Paní °editelce Dan¥ P°edotové za poskytnuté materiály a mé matce Dan¥ Samkové za umoº¬ování p°ístupu do budovy za ú£elem po°izování podklad· a konzultace p°i psaní této práce.
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).
Abstract This bachelor thesis deals with the design of the structure and use of the virtual model of kindergarten Kamarád in Pardubice, its implementation in VRML format and subsequent integration into the school website. In all these phases the emphasis is on intuitive navigation and interactive behavior of the model for lay users (parents). At the end of the work results of testing the model in terms of its applicability and information value performed by independent users are presented.
Abstrakt Tato práce se zabývá návrhem struktury a vyuºití virtuálního modelu Mate°ské ²koly Kamarád v Pardubicích, jeho tvorbou ve formátu VRML a následnou integrací do webových stránek ²koly. Ve v²ech t¥chto fázích je kladen d·raz na intuitivní navigaci a interaktivní chování modelu pro laické uºivatele (rodi£e). V záv¥ru práce jsou prezentovány výsledky testování modelu z hlediska jeho pouºitelnosti a informa£ní hodnoty provád¥ného nezávislými uºivateli.
Úvod Tato bakalá°ská práce vznikla z podn¥tu vedení Mate°ské ²koly "Kamarád"v Pardubicích, jako moºnost zlep²ení prezentace této mate°ské ²koly pro ve°ejnost s vyuºitím moderních technologií. V dne²ní dob¥ je jiº standardem, ºe mate°ské ²koly mají na internetu své webové stránky, na kterých se snaºí náv²t¥vník·m p°iblíºit své prost°edí pomocí fotogra í. Lep²í moºnost seznámit se s prost°edím v²ak v dne²ní dob¥ p°iná²ejí technologie virtuálních prohlídek pomocí virtuálních model·. Proto se vedení mate°ské ²koly rozhodlo vyuºít moºnost vytvo°it takovýto model a za£lenit jej do webových stránek ²koly [10] v rámci bakalá°ské práce.
1
2
KAPITOLA 1.
ÚVOD
Kapitola 2
Analýza projektu 2.1 Popis problému, speci kace cíle Cílem práce je navrhnout strukturu a vyuºití virtuálního modelu Mate°ské ²koly Kamarád v Pardubicích, s ohledem na uºivatele, pro které je model ur£en. T¥mito uºivateli jsou p°edev²ím rodi£e, u kterých se p°edpokládá, ºe jsou v oblasti virtuálních model· a zacházení s nimi laiky. Dal²ím krokem je navrºenou strukturu implementovat ve formátu VRML tak, aby výpo£etní a pam¥´ové nároky byly co nejniº²í. Následujícím krokem je vytvo°ený model vhodným zp·sobem integrovat do jiº existujících webových stránek M Kamarád s d·razem na intuitivní ovládání. Na záv¥r je nutné správnost zvoleného návrhu a implementace modelu otestovat nezávislými uºivately.
2.2 Analýza a návrh °e²ení Mate°ská ²kola Kamarád v Pardubicích je pouze jednot°ídní ²kola, která by sama pln¥ nevyuºila ve²keré prostory budovy poskytované m¥stem, proto v levé polovin¥ p°ízemí budovy sídlí jedno odd¥lení jeslí. V prvním pat°e je v odpoledních hodinách provozován d¥tský klub pro d¥ti mlad²ího ²kolního v¥ku. Cílem této práce m¥l být pouze model mate°ské ²koly, proto se vzhledem k vý²e uvedeným skute£nostem nabízely tyto alternativy °e²ení. První z nich byla zam¥°it se pouze na vnit°ní prostory, které náleºí mate°ské ²kole, a nezabývat se vn¥j²ím vzhledem budovy. Druhou alternativou bylo vytvo°ení modelu vn¥j²í struktury celé budovy a následné za£len¥ní jednotlivých místností mate°ské ²koly do tohoto modelu. Po konzultaci se zadavatelem práce - vedením mate°ské ²koly, byla zvolena podrobn¥j²í alternativa, která v sob¥ zahrnuje jak interiér mate°ské ²koly, tak i exteriér celé budovy. D·vody pro tuto volbu byly lep²í prezentace ²koly pro ve°ejnost, moºnost p°iblíºit zakomponování budovy do okolního prost°edí tvo°eného ²kolní zahradou a parkem a moºnost následného roz²í°ení modelu o prostory jeslí a d¥tského klubu. Jako jazyk pro tvorbu modelu byl zvolen jazyk VRML kv·li znalostem tohoto jazyka získaným v p°edm¥tu 3D modelování a virtuální realita a také jeho v¥t²ímu roz²í°ení oproti jazyku X3D. K jazyku VRML také existuje velmi kvalitní p°íru£ka s názvem Laskavý pr·vodce virtuálními sv¥ty [1]. Ta poskytuje mnoho cenných informací pot°ebných k vytvo°ení kvalitního a dob°e pouºitelného virtuálního modelu.
3
4
KAPITOLA 2.
ANALÝZA PROJEKTU
Vzhledem ke sloºitosti a £lenitosti modelu byl zvolen následující postup. Jako základ modelu bude vytvo°ena vn¥j²í struktura budovy, která bude roz£len¥na na jednotlivé £ásti tak, aby se kaºdá vymodelovaná £ást dala ve výsledném modelu vyuºít co nejvícekrát pomocí konstrukcí DEF a USE. Následn¥ budou vytvá°eny modely jednotlivých místností a zakomponovány do modelu vn¥j²ku budovy. Modely t¥chto místností se budou skládat z £ástí zvolených tak, aby bylo umoºn¥no jejich otexturování, které by co nejlépe odpovídalo skute£nosti. Ve²keré tyto modely budou vytvá°eny podle stavebních plán· budovy zap·j£ených vedením mate°ské ²koly. Následn¥ budou vytvo°eny modely vybavení jednotlivých místností. Z d·vodu velkého mnoºství vnit°ního vybavení mate°ské ²koly a z toho plynoucích velkých £asových nárok· na jejich tvorbu nemohou být vytvo°eny modely ve²kerého vybavení, ale pouze toho nejzákladn¥j²ího. Výb¥r d·leºitých prvk· v interiéru byl osobn¥ konzultován s paní °editelkou. Pokud nemá dojít ihned v úvodu virtuální prohlídky k tomu, ºe by byl uºivatel zasko£en náro£ností ovládání nabízeného modelu a tím pádem odrazen od jeho dal²ího vyuºívání, je nezbytn¥ nutné nabídnout uºivateli jednoduchý zp·sob navigace. Pro usnadn¥ní pohybu po virtuálním modelu by bylo dobré uºivateli krom¥ standardn¥ pouºívaného zp·sobu °e²ení pomocí Viewpoint· nabídnout je²t¥ dal²í moºnost, která by byla intuitivn¥j²í a názorn¥j²í. K tomuto ú£elu by mohlo být vhodným zp·sobem vyuºito prvk· panelu HUD. Funk£nost modelu by také m¥la být ov¥°ována za pomoci alespo¬ dvou r·zných prohlíºe£· jazyka VRML, aby uºivatel nebyl nucen ke striktnímu vyuºívání pouze jednoho konkrétního prohlíºe£e, ale byla mu poskytnuta alespo¬ omezená moºnost svobodného výb¥ru. K tomuto ú£elu byly zvoleny prohlíºe£e Cortona 3D Viewer [5] (dále jen Cortona) a BS Contact [4], protoºe se jedná o voln¥ dostupné programy, jejichº vyuºívání není podmín¥no poskytováním ºádných nan£ních prost°edk· ze strany uºivatele.
Kapitola 3
Realizace 3.1 Modelování Jak jiº bylo zmín¥no v p°edchozí kapitole, celý model byl vytvá°en v jazyce VRML. Z d·vodu co nejv¥t²ího omezení výpo£etních nárok· byla celá budova i její vybavení modelována pouze s vyuºitím základních t¥les, která jazyk VRML nabízí a v p°ípadech, kde se s t¥mito t¥lesy nedalo vysta£it, s pouºitím jednoduchých sad ploch. K dispozici jsou v jazyce VRML £ty°i
Sphere, kvádr reprezentovaný uzlem Box, Cone a válec reprezentovaný uzlem Cylinder. Bohuºel tato t¥lesa
základní typy t¥les. Koule reprezentována uzlem kuºel reprezentovaný uzlem
nebylo moºné pouºít tam, kde bylo vyºadováno p°esné namapování textur, protoºe textury jsou na tato t¥lesa naná²eny automaticky a nelze jejich rozvrºení po objektu nijak ovlivnit. Proto bylo v n¥kterých p°ípadech nutné vyuºít i pro objekty, jejichº tvar odpovídá n¥kterému ze základních t¥les, zápis pomocí sady ploch. V jazyce VRML se k tomuto ú£elu pouºívá uzel
IndexedFaceSet,
který umoº¬uje mapování textur p°esn¥ de novat. Celý model se tedy ve
valné v¥t²in¥ skládá z objekt· vytvo°ených práv¥ pomocí tohoto uzlu. Vzhledem k rozhodnutí modelovat ve²keré objekty pouze jako jednoduché tvary, bylo ustoupeno od moºnosti vyuºít k jejich tvorb¥ sluºeb externího modelá°e. Jednak proto, ºe pouºívat profesionální nástroje na tvorbu takto jednoduchých tvar· bylo povaºováno za zbyte£né a jednak proto, ºe odpadne práce s £asto sloºitým exportováním vymodelovaných objekt· z modelá°e do kódu jazyka VRML. Takto vzniklý kód musí být £asto je²t¥ následn¥ upravován, coº p°iná²í dal²í £asové nároky. Celý kód byl proto psán ru£n¥, coº p°isp¥lo k jeho p°ehlednosti a také jednodu²²í orientaci p°i nutnosti u£init opravné zásahy v n¥které z jeho £ástí. Pro usnadn¥ní ru£ního psaní kódu bylo vyuºito editoru VrmlPad [12], který je navrºen práv¥ pro psaní kód· v jazyce VRML a p°iná²í spoustu uºite£ných prost°edk· pro urychlení jejich tvorby.
Vn¥j²í plá²´ budovy Jako první byl vytvá°en model vn¥j²ího plá²t¥ budovy. Ten byl roz£len¥n do t°í skupin, tvo°ících logické celky. Jsou jimi p°ední p°ístavba, první nadzemní podlaºí a druhé nadzemní podlaºí. Kaºdá ze skupin je pak rozd¥lena na n¥kolik £ástí, zvolených s ohledem na moºnost jejich vícenásobného pouºití pomocí konstrukce
5
DEF a USE pro sestavení výsledného modelu.
6
KAPITOLA 3.
REALIZACE
P°estoºe je budova mate°ské ²koly soum¥rná, je moºnost vyuºití n¥kterých jiº vymodelovaných prvk· omezená, protoºe v jazyce VRML neexistuje moºnost vymodelované prvky zrcadlit. V ur£itých p°ípadech se podobného výsledku dalo dosáhnout pouºitím rotace spolu s posunem, jinak ale musely být tyto prvky modelovány znovu. St°ed soustavy sou°adnic byl zvolen na svislé ose prost°edního sloupu p°ístavby v úrovni zem¥. Tato volba vzhledem k jiº zmín¥né soum¥rnosti budovy, umoº¬uje snadn¥j²í ur£ování polohy jednotlivých £ástí. Odpovídající si £ásti tak mají shodné sou°adnice pouze s opa£ným znaménkem. Nejlep²ím p°íkladem £ásti zvolené tak, aby bylo moºné ji opakovan¥ pouºít, byl prvek £ásti p°ední zdi s oknem, který bylo moºné °adit vedle sebe a tím vytvo°it celou p°ední st¥nu.Výsledek ukazuje obrázek 3.1. Stejným zp·sobem byly vytvá°eny a pouºity ve²keré prvky obsahující okna.
Obrázek 3.1: Ukázka opakovaného pouºití prvku modelu
Místnosti Po dokon£ení prací na modelu vn¥j²ího plá²t¥ budovy bylo p°istoupeno k modelování jednotlivých místností. Vzhledem k tomu, ºe strop v jednotlivých místnostech má tém¥° totoºnou barvu a navíc tato £ást místnosti nepat°í k t¥m, na které by se uºivatel zvlá²t¥ zam¥°oval, byl strop pro v²echny místnosti realizován jako jediná plocha. V p°ípad¥ podlah a st¥n uº tomu tak není. V kaºdé místnosti je podlaha opat°ena jiným povrchem, koberec, lino nebo dlaºdi£ky a barva st¥ny v kaºdé místnosti, n¥kdy dokonce i v rámci jedné, je odli²ná. Z tohoto d·vodu je kaºdá místnost modelována samostatn¥. Místnosti se skládají z n¥kolika sad ploch tak, aby po jejich otexturování vzhled místnosti co nejvíce odpovídal skute£nosti. Místnost nelze realizovat jako jedinou sadu ploch, protoºe p°i pouºití opakujících se textur lze nastavit po£et jejich opakování na kaºdé plo²e pouze pro sadu jako celek a ne pro kaºdou plochu zvlá²´. V takovém p°ípad¥ tedy dochází k tomu, ºe na kaºdé plo²e bez ohledu na její velikost dojde ke stejnému po£tu výskyt· textury, z £ehoº plyne, ºe na kaºdé této plo²e bude mít textura jinou velikost. Tento efekt je ale velmi neºádoucí u textur obsahujících prvky, jejichº velikost má být stále stejná. P°íkladem v modelu mate°ské ²koly je nap°íklad textura obklad· umývárny nebo d°ev¥ného obloºení jídelny. V takovýchto p°ípadech musí být model
3.1.
7
MODELOVÁNÍ
místnosti vytvo°en z n¥kolika sad ploch umoº¬ujících nezávislé nastavení po£tu opakování textur. P°i modelování místností byly také hledány prvky, které by bylo moºné vyuºít vícekrát. Stejn¥ jako p°i modelování plá²t¥ budovy byly vhodnými kandidáty prvky tvo°ící £ást st¥ny, kde jsou umíst¥na okna. U model· místností byly takovéto prvky nalezeny pouze t°i, a to okno do ulice a okno a dve°e do zahrady. Realizace t¥chto prvk· v²ak nebyla tak snadná jako v p°ípad¥ vn¥j²ího plá²t¥ budovy, nebo´ tyto prvky musejí být v kaºdé místnosti opat°eny jinou texturou. Jediným zp·sobem, jak v tomto p°ípad¥ umoºnit vícenásobné pouºití t¥chto prvk·, bylo ustanovit je jako prototypy. T¥mto prototyp·m pak lze nastavit poºadovanou texturu a po£et jejího opakování jako hodnoty ur£ených parametr·. Následující kód ukazuje záhlaví prototypu prvku s oknem do ulice:
PROTO Okno_predni [ field SFNode textury_MAT NULL #uzel ur£ující pouºitý materiál st¥ny field SFNode stena_TEX NULL #uzel ur£ující pouºitou texturu st¥ny field SFVec2f scale_TEX 1 1 #po£et opkování textury ve sm¥ru osy x a y ] Poté, co byly dokon£eny modely jednotlivých místností, následovalo jejich za£len¥ní do modelu vn¥j²ího plá²t¥ budovy. Jakmile byly v²echny místnosti na svém míst¥, bylo pot°eba vhodn¥ upravit p°echody mezi nimi. Následovalo tedy modelování zárubní a dve°í. Ty byly ideálními objekty pro vyuºití konstrukce
DEF
a
USE.
V budov¥ mate°ské ²koly jsou mezi
n¥kterými místnostmi pouze zárubn¥ bez dve°í, proto bylo nutné je vytvá°et jako samostatné objekty. Navíc se v budov¥ vyskytují dve°e o dvou r·zných ²í°kách, které bylo nutno z d·vodu návaznosti na jiº vymodelované místnosti dodrºet. Pro model dve°í byl p·vodn¥ vyuºit kvádr jako základní t¥leso. Nevyhovovalo v²ak automatické namapování textur, které zp·sobilo, ºe na kaºdé stran¥ dve°í byla klika na jiném míst¥. Proto byly dve°e následn¥ realizovány pomocí sady ploch a textury namapovány ru£n¥. Tím byl dokon£en kompletní model budovy a mohly za£ít práce na jejím vybavení.
Vybavení Jako první bylo modelováno vybavení chodby a ²atny. V obou t¥chto místnostech jsou výraznými prvky nást¥nky. Pro jejich vznik mohlo být pro jednoduchost pouºito základní t¥leso tvaru kvádru, protoºe v tomto p°ípad¥ není viditelný efekt nevyhovujícího automatického namapování textur. Na modelu ²atních sk°ín¥k uº by tento efekt viditelný byl, a proto byl modelován jako sada ploch. Díky tomu bylo také moºné vymodelovat pouze viditelné st¥ny a sníºit tak po£et ploch k zobrazení na polovinu. U modelu lavi£ek byl stejný problém s jejich vícenásobným vyuºitím jako u vnit°ních £ástí zdi s oknem. I v tomto p°ípad¥ byla lavi£ka de nována jako prototyp s parametrem nastavujícím její barvu. Pro realizaci sluní£ka nad dve°mi do ²atny byl pouºit zp·sob aplikování textury s pr·hledností na jednoduchou plochu. Tento zp·sob byl pak vyuºit v podobných p°ípadech i v jiných místnostech. V hern¥ stojí za zmínku hlavn¥ zp·sob, jakým byl vytvo°en u£itelský st·l. Ten je sloºen pouze ze základních t¥les. Nohy tvo°í kvádry a deska je sloºena z kvádru a válce, sesazených tak, aby spolu vytvo°ily pot°ebný tvar. U válce je také nastaveno nezobrazovat dolní podstavu, stejn¥ jako v dal²ích p°ípadech, kdy tato podstava není pro náv²t¥vníka viditelná. Také
8
KAPITOLA 3.
REALIZACE
d¥tské ºidle a stoly jsou vymodelovány pouze za pouºití základních tvar·. Dal²í zajímavostí je d¥tský hrad, který vznikl pouze nanesením textury s pr·hledností na kvádr. Bohuºel v d·sledku rendererem chybn¥ stanoveného po°adí, v jakém má být zobrazováno více textur s pr·hledností v zákrytu, dochází p°i ur£itém úhlu pohledu k prosvítání vzdálen¥j²ích objekt· skrz hrad. Tento problém ukazuje obrázek 3.2.
Obrázek 3.2: Ukázka chybného zobrazení hradu
V loºnici byl zvlá²tní zp·sob realizace pouºit u d°ev¥né stavebnice, konkrétn¥ u válce. Zde se op¥t objevil problém s nevyhovujícím otexturováním. Na plá²´ válce bylo pot°eba texturu aplikovat tak, aby se opakovala t°ikrát, zatímco na horní podstavu pouze jednou. V tomto p°ípad¥ v²ak k oprav¥ nebyla pouºita sada ploch, ale vyuºilo se moºnosti u válce ur£it kaºdé z jeho t°í £ástí, tedy horní podstav¥, dolní podstav¥ a plá²ti, zda má být zobrazena, £i nikoli. Byly tedy vytvo°eny válce dva. U jednoho byl zobrazen pouze plá²´ a u druhého pouze horní podstava. Kaºdému z nich pak mohl být nastaven individuáln¥ po£et opakování textury.
Nejv¥t²í problém p°i vytvá°ení modelu p°edstavovalo vybavení umývárny. Realizace sloºitých tvar·, jakými jsou umyvadlo a záchod, se zdála být pomocí základních t¥les nemoºná. Jako první bylo zvoleno umyvadlo, protoºe jeho tvar je v porovnání s tvarem záchodu jednodu²²í. Po dlouhém p°emý²lení, jak tento objekt vymodelovat, byl u£in¥n záv¥r, ºe tvaru umyvadla se ze základních t¥les nejvíce podobá kuºel. Jako základ pro tvorbu umyvadla byl tedy vymodelován kuºel s vrcholem sm¥°ujícím k zemi. Na ten byl napojen válec, znázor¬ující odpadní trubku. Vnit°ní tvar umyvadla m¥l být znázorn¥n alespo¬ texturou. P°i pokusu pouºít texturu na podstavu kuºele do²lo k deformaci textury. Z toho d·vodu musela být namísto podstavy vytvo°ena obdélníková plocha a na ní textura namapována. S tvarem záchodu uº to tak jednoduché nebylo, protoºe ten ºádné ze základních t¥les nep°ipomíná. Nakonec byl jako nejp°ijateln¥j²í zp·sob, jak náv²t¥vníkovi tvar záchodu alespo¬ p°iblíºit, zvolen stejný postup jako v p°ípad¥ umyvadla. Základní tvar byl nazna£en pomocí kuºele a válce a na vrchní £ást op¥t umíst¥na plocha s texturou. Jejich výsledný vzhled ukazuje obrázek 3.3.
3.2.
9
TEXTURY
Obrázek 3.3: Ukázka model· umyvadla a záchodu
3.2 Textury Vzhledem k tomu, ºe základní my²lenkou projektu bylo vytvo°it celý model budovy i jejího vybavení pouze s vyuºitím základních t¥les a jednoduchých sad ploch vzniklých p°ímím zápisem VRML kódu bez pouºití externího modelá°e, hrají textury pro výsledný vzhled modelu zásadní roly.
Po°ízení a úprava textur Ve²keré textury pro model byly aº na jedinou výjimku, kterou je venkovní zámková dlaºba, vytvo°eny z fotogra í po°ízených p°ímo za tímto ú£elem v budov¥ mate°ské ²koly. Tyto fotogra e musely být následn¥ upravovány, nebo´ byly po°ízeny na digitální kompaktní fotoaparát pr·m¥rné kvality. Projevilo se tak na nich tzv. soudkovité zkreslení, coº je vada objektivu, která zp·sobuje prohnutí rovných £ar sm¥rem k okraj·m obrazu. Ve²keré úpravy fotogra í byly provád¥ny v bitmapovém gra ckém editoru Gimp 2 [7]. K odstran¥ní jiº zmín¥ného soudkovitého zkreslení a také dal²ího problému, kterým bylo perspektivní zkreslení vzniklé nemoºností po°ídit n¥které snímky p°esn¥ pod pravým úhlem k fotografovanému objektu, byl pouºit nástroj Perspektiva. Výsledky úprav ukazuje obrázek 3.4.
Obrázek 3.4: Vlevo odstran¥ní soudkovitého a vpravo perspektivního zkreslení
10
KAPITOLA 3.
REALIZACE
Z n¥kterých záb¥r· musely být odstran¥ny ru²ivé odlesky zp·sobené nutným pouºitím blesku pro vytvo°ení kvalitního nerozmazaného snímku v nedostate£n¥ osv¥tleném interiéru budovy. Na jiných záb¥rech byly naopak tyto odlesky stejn¥ jako sv¥tlá místa vzniklá dopadajícím slune£ním svitem zám¥rn¥ ponechány, aby modelovaná scéna nep·sobila p°íli² um¥le. Porovnání nabízí obrázek 3.5.
Obrázek 3.5: P°ípady odstran¥ní a ponechání odlesk·
T°i textury byly vytvo°eny z obrázk· nalezených na internetu. První z nich byla jiº zmín¥ná textura pro venkovní zámkovou dlaºbu [6]. Dal²ími dv¥ma byly textury pouºité pro tla£ítka v panelu HUD. Textura pro tla£ítko ovládající zapnutí a vypnutí zobrazení mapy [9] a textura pro tla£ítko zaji²tující p°epínaní pohledu avatara mezi dít¥tem a dosp¥lým vzniklá úpravou obrázku dopravní zna£ky Stezka pro chodce [13].
Obrazové formáty textur
Podle toho, k jakým ú£el·m byly textury ur£eny, bylo d·leºité správn¥ zvolit obrazový formát, do kterého budou uloºeny. Pro v¥t²inu pouºitých textury, u kterých nebyla vyºadována ºádná pr·hlednost, byl zachován formát, ve kterém byly po°ízeny fotogra e pro jejich tvorbu. Jednalo se o formát JPEG, coº je obrazový formát k ukládání bitmapové (rastrové) gra ky podporující £ty°iadvacetibitovou gra ku (16 milion· barev) a pouºívající ztrátovou kompresi. Pro textury objekt· obsahujících pr·hledné £ásti jako nap°. okenní tabulky byl pouºit formát PNG. Ten na rozdíl od formátu JPEG umoº¬uje do obrázku p°idat pr·hlednost a pouºívá bezeztrátovou kompresi. Stejný formát byl pouºit také pro objekty, jejichº modelování by bylo p°íli² sloºité a jejich tvar byl nazna£en pouze pomocí textur s pr·hlednými oblastmi mimo tvar objektu. P°íklady takových objekt· jsou hrad nebo umyvadlo. Pro textury tla£ítek HUD, byl vzhledem k jejich malým rozm¥r·m a nízké náro£nosti na rozsah barev zvolen jako dosta£ující formát GIF. Tento formát podporuje osmibitovou gra ku (256 barev) a pouºívá bezeztrátovou kompresi.
3.3.
BARVY
11
Rozm¥ry a velikosti textur
Dal²ím d·leºitým parametrem u textur jsou jejich rozm¥ry, od kterých se následn¥ odvíjí jejich velikost. Je zapot°ebí najít kompromis mezi kvalitou a velikostí textur. Na jedné stran¥ stojí snaha uºivateli nabídnout co nejkvalitn¥j²í zobrazení, na stran¥ druhé pot°eba zabránit pomalému na£ítání a zobrazování textur, které je závislé práv¥ na jejich velikosti. Rozm¥ry textur je navíc dobré volit tak, aby alespo¬ jedna jejich strana m¥la hodnotu odpovídající mocnin¥ £ísla 2. Díky této volb¥ se dosáhne zlep²ení jejich ukládání do pam¥ti GPU. U objekt·, jako jsou nást¥nky, u kterých byl nutný vysoký stupe¬ detailu, protoºe obsahují informace pro rodi£e nebo výtvory d¥tí, byly pouºity textury s rozm¥rem del²í strany 1024 pixel·. V¥t²ina pouºitých textur jako jsou okna, dve°e, sk°ín¥ a dal²í vybavení má rozm¥r del²í strany 512 resp. 256 pixel·. Pro textury malých p°edm¥t· a opakující se textury jako jsou koberce, lino atd. byly zvoleny rozm¥ry del²í strany 128 resp. 64 pixel·. P°ehled v²ech pouºitých textur s rozm¥ry a velikostmi je k dispozici v p°íloze D.1. Tyto hodnoty byly zji²t¥ny pomocí programu IrfanView [8]. Celková velikost pouºitých textur na disku je p°ibliºn¥ 6,8 MB a jejich velikost v pam¥ti je p°ibliºn¥ 32,2 MB.
3.3 Barvy V¥t²ina vymodelovaných objekt· byla, jak uº bylo zmín¥no, opat°ena texturami. Úkolem t¥chto textur bylo ukázat skute£né tvary objekt·. Ty byly vytvo°eny pouze jako jednoduchá t¥lesa a bez jejich otexturování by uºivatel nepoznal, o jaký p°edm¥t se jedná. Proto nem¥lo valný význam u takovýchto objekt· nastavovat jakoukoli barvu, která by se zobrazila do doby, neº bude na£tena textura. Barvy tedy byly pouºity pouze u objekt·, na n¥º nebyly ºádné textury aplikovány. Jedná se o objekty, jejichº povrch má pouze jednoduché barvy a jejichº tvar lze snadno vymodelovat a není nutné ho nijak dokreslovat pouºitím textur. V p°ípad¥ modelu mate°ské ²koly se takových objekt· na²lo jen málo. Nejv¥t²í plochu, na kterou byla pouºita pouze barva, tvo°í vn¥j²í plá²´ budovy. Dal²ími p°edm¥ty opat°enými pouze barvou jsou zárubn¥ dve°í, lavi£ky v ²atn¥, modrý nábytek v malé hern¥, stoly v jídeln¥, konstrukce zást¥n odd¥lujících záchody a £ásti záchodu. Pro volbu barev t¥chto p°edm¥t·, které by m¥ly co nejvíce odpovídat skute£nosti, byl pouºit vzorník nalezený na internetu [2]. Ten v²ak obsahuje jen názvy jednotlivých barev. Po výb¥ru barvy tedy bylo nutné vyhledat hodnoty pro zápis barvy v jazyce VRML na jiné webové stránce [3]. Tato stránka obsahuje pouze názvy barev s pot°ebnými hodnotami bez ukázky, o jakou barvu se jedná.
3.4 Navigace Model má slouºit p°edev²ím rodi£·m a dal²ím rodinným p°íslu²ník·m, které lze ve valné v¥t²in¥ povaºovat za laické uºivatele v oblasti prohlídek virtuálních model·, a ve zp·sobu jakým se v takovýchto prohlídkách pohybovat a jak s modelem zacházet. Z toho d·vodu musí být sou£ástí modelu prvky poskytující t¥mto uºivatel·m jednoduchou intuitivní navigaci.
Umíst¥ní p°ed budovou M p°ed hlavním vchodem do M v hlavních dve°ích sm¥rem do chodby ve dve°ích z chodby sm¥rem do ²atny ve dve°ích ze ²atny sm¥rem do malé herny ve dve°ích z malé herny sm¥rem do chodbi£ky ve dve°ích z chodbi£ky sm¥rem do umývárny ve dve°ích z chodbi£ky sm¥rem do jídelny ve dve°ích z chodbi£ky sm¥rem do herny ve dve°ích z herny sm¥rem do loºnice
Tabulka 3.1: Seznam a umíst¥ní viewpoint·
3.4.1
Viewpointy
Prvním z prvk· usnad¬ujících navigaci je standardn¥ pouºívaný zp·sob s vyuºitím sady Viewpoint·. Jedná se o stanovi²t¥ uvnit° virtuálního sv¥ta s de novanou vý²kou a sm¥rem pohledu. P°esun mezi t¥mito stanovi²ti m·ºe být provád¥n dvojím zp·sobem. Bu¤ skokov¥ p°ímou zm¥nou pohledu, nebo plynulým p°eletem uvnit° virtuálního prostoru s postupnou zm¥nou sm¥ru pohledu. Model t¥chto stanovi²´ obsahuje 10. Tato stanovi²t¥ jsou umíst¥na jednak p°ed vstupem do budovy M a následn¥ u vstup· do jednotlivých místností. Pro p°esun mezi jednotlivými stanovi²ti byl zvolen zp·sob plynulého p°esunu, aby uºivatel neztratil pojem o tom, kde se v daný okamºik nachází. Seznam stanovi²´ s popisem jejich umíst¥ní ukazuje tabulka 3.1.
3.4.2
Panel HUD
Druhým zp·sobem, jak uºivateli usnadnit navigaci po virtuálním sv¥t¥, je model doplnit panelem HUD. Ten je tvo°en objekty, které se ve virtuálním sv¥t¥ pohybují spolu s avatarem a pro uºivatele tak p·sobí jako statické prvky na obrazovce.
Mapa Jako asi nejp°irozen¥j²í zp·sob, jaký je £lov¥k zvyklí pro svou orientaci v neznámém prost°edí pouºívat, je navigace pomocí mapy. Na základ¥ tohoto poznatku, jsem se rozhodl realizovat jednoduchou mapku budovy M jako jeden z prvk· zmín¥ného panelu HUD. Úkolem této mapky by m¥lo být nejen uºivateli zprost°edkovat informaci o tom, na jakém míst¥ se v danou chvíli uvnit° budovy nachází, ale také umoºnit mu se pomocí této mapy po budov¥ pohybovat. Základní p°edstava o tom, jak by m¥la mapa fungovat, byla následující. Mapa se bude skládat ze dvou £ástí. Jednak samotného plánku místností a jednak z ukazatele, který bude znázor¬ovat, jak aktuální pozici uºivatele, tak sm¥r, kterým hledí. Mapa by také m¥la uºivateli poskytnout moºnost jednoduchým zp·sobem se p°esouvat po budov¥ pomocí klikání na její plánek.
3.4.
13
NAVIGACE
Nejjednodu²²í moºností, jak vytvo°it plánek, bylo vymodelovat jednoduchý objekt a ten opat°it texturou. Pro tento objekt bylo zvoleno základní t¥leso typu byl p°ipojen
TouchSensor,
Box.
K n¥mu
zaji²´ující ode£ítání sou°adnic místa, na které uºivatel kliknul.
Pro volbu rozm¥r· tohoto t¥lesa byla zásadní dv¥ kritéria. Prvním bylo jeho umíst¥ní na obrazovce. Mapa by nem¥la zakrývat p°íli² velkou £ást pozorované oblasti, ale zárove¬ by m¥la být £itelná i p°i malých velikostech okna prohlíºe£e. Druhým kritériem byla závislost na skute£ných rozm¥rech budovy tak, aby bylo moºné snadno p°evád¥t sou°adnice z tohoto objektu na reálné sou°adnice budovy. Jako vyhovující se ukázalo vytvo°it objekt pro plánek v pom¥ru 1:200 k reálným rozm¥r·m. Textura byla vytvo°ena úpravou ofocených stavebních plánu budovy. Z nich byly odstran¥ny kóty s dal²ími nepot°ebnými informacemi a naopak byly dopln¥ny názvy jednotlivých místností. Jak se pozd¥ji ukázalo, p·vodní zám¥r s pouºitím této textury na jednoduchý tvar
Box
nebyl ideální, protoºe na plánku se vyskytla místa, do
kterých nem¥l mít uºivatel p°ístup. Prvním pouºitým zp·sobem °e²ení tohoto problému bylo vymazat z textury prostory nep°ístupné pro uºivatele a pomocí sou°adnic vymezit oblasti, do nichº uºivatel nebude p°esouván. Zvolené °e²ení v²ak bylo matoucí pro n¥které uºivatele, a proto bylo nutné u£init následující kroky. Místo jednoduchého t¥lesa typu byl plánek sestaven jako sada ploch typu
IndexedFaceSet
Box
p°esn¥ odpovídající prostorám
p°ístupným náv²t¥vníkovi. Na tyto plochy byla poté p°esn¥ namapována textura plánku. Pro tvar ukazatele polohy a sm¥ru pohledu byl zvolen jednoduchý rovnoramenný trojúhelník £ervené barvy, zásluhou které je pro uºivatele snadno a rychle identi kovatelný v mod°e podbarveném plánku. P·vodn¥ bylo zamý²leno umístit mapu do levého horního rohu obrazovky. Po pokusech se zm¥nami rozm¥r· okna webového prohlíºe£e v²ak bylo zji²t¥no, ºe nelze p°esn¥ de novat pozici mapy na obrazovce, protoºe tato pozice je závislá na pom¥ru stran okna webového prohlíºe£e. V p°ípad¥ umíst¥ní mapy ve velké vzdálenosti od st°edu obrazovky docházelo p°i zúºení okna prohlíºe£e ke zmizení £ásti mapy z obrazovky. Mapa proto musela být umíst¥na v horní £ásti obrazovky, co nejblíºe ke st°ední vertikální linii. K jiº zmín¥nému jevu mizení mapy m·ºe £áste£n¥ dojít i po této úprav¥. Jedná se v²ak o p°ípady extrémního zúºení okna prohlíºe£e, o nichº se p°edpokládá, ºe b¥ºn¥ u uºivatele nenastanou. Po posunutí blíºe ke st°edu se v²ak mapa dostala do oblasti, kam ve v¥t²in¥ p°ípad· sm¥°uje pohled uºivatele. V d·sledku této skute£nosti za£ala mapa p·sobit ru²iv¥. Neºádoucí efekt se poda°ilo zmírnit vyuºitím £áste£né pr·hlednosti aplikované na texturu plánku.
Tla£ítko pro skrytí mapy N¥kterým uºivatel·m by i p°es tuto úpravu mapa mohla stále kazit dobrý dojem z virtuální prohlídky, proto by bylo dobré jim nabídnout moºnost si tuto mapu zobrazit podle vlastní pot°eby. Za tímto ú£elem bylo do panelu HUD p°idáno tla£ítko umoº¬ující mapu zobrazit nebo skrýt. Toto tla£ítko bylo pro snadn¥j²í pochopení jeho funkce opat°eno texturou s obrázkem mapy a umíst¥no v horní £ásti obrazovky napravo od mapy.
Tla£ítko pro zm¥nu pohledu Dal²ím prvkem obsaºeným v panelu HUD je tla£ítko pro zm¥nu pohledu. Toto tla£ítko umoº¬uje uºivateli p°epínat mezi dv¥ma variantami pohledu - dosp¥lého a dít¥te, £ímº se
14
KAPITOLA 3.
REALIZACE
m¥ní vý²ka jeho avatara. M·ºe tedy nejen zjistit, jak vypadá prost°edí mate°ské ²koly z pohledu dosp¥lého £lov¥ka, ale také se vºít do role malého dít¥te a zjistit, jak se toto prost°edí jeví p°i pohledu d¥tskýma o£ima. Vý²ka o£í avatara byla zvolena na 160 cm pro pohled dosp¥lého a 100 cm pro pohled dít¥te. Toto tla£ítko bylo stejn¥ jako v p°ípad¥ tla£ítka pro zobrazení mapy opat°eno texturou. Pro jednoduchost byly zvoleny siluety dvou postav dít¥te a dosp¥lého. Aby uºivatel neztratil p°ehled o tom, v jakém pohledu se práv¥ nachází, byla tato textura vytvo°ena ve dvou verzích s £erven¥ vybarvenou postavou zastupující práv¥ pouºívaný pohled. Porovnání obou pohled· ukazuje obrázek 3.6.
Obrázek 3.6: Vlevo pohled dít¥te, vpravo pohled dosp¥lého
Textové pole pro nápov¥du Posledním prvkem, který se v panelu HUD vyskytuje, je pole pro zobrazení nápov¥dy ke dv¥ma vý²e zmín¥ným tla£ítk·m. Toto pole je realizováno uzlem typu
Text
a je umíst¥no
pod tla£ítky. Pro text bylo zvoleno bezpatkové písmo £erné barvy, aby korespondovalo s písmem, které bylo pouºito p°i tvorb¥ textury plánku pro názvy místností. Jakmile se kurzor dostane nad tla£ítko, je v n¥m zobrazena informace, k £emu dané tla£ítko slouºí. Pro tla£ítko ovládající zobrazení mapy je to nápis zobrazit/skryt mapu a pro tla£ítko zaji²´ující zm¥nu pohledu nápis pohled dospeleho/ditete. Výslednou podobu panelu HUD znázor¬uje obrázek 3.7.
3.5 Skripty Pro implementaci sluºeb, které by m¥l poskytovat panel HUD, zejména pak umoºn¥ní navigace po virtuálním sv¥t¥ pomocí mapy, uº nebylo moºné vysta£it jen s b¥ºnými uzly VRML. Pro zaji²t¥ní její funk£nosti bylo nezbytné vyuºít sluºeb, které poskytuje uzel
Script.
Tento uzel je jakousi schránkou na funkce napsané v jazyce Java nebo ECMAScript znám¥j²ím spí²e pod názvem JavaScript. Pro tento p°ípad je posta£ujícím druhý zmín¥ný, který sice nedisponuje takovou ²kálou prost°edk· jako jazyk Java, na druhou stranu je práce s ním snadn¥j²í a intuitivn¥j²í.
3.5.
15
SKRIPTY
Obrázek 3.7: Ukázka panelu HUD
Zobrazení polohy v map¥ Prvním p°ípadem, kdy bylo pot°eba pouºít skript, bylo p°evád¥ní pohybu avatara ve trojrozm¥rném prostoru virtuálního sv¥ta na pohyb ²ipky po dvourozm¥rném plánu budovy. K tomu, aby tento zám¥r mohl být realizován, bylo nejprve zapot°ebí n¥jakým zp·sobem zjistit, na jakých sou°adnicích se avatar ve virtuálním sv¥t¥ nachází. K tomuto ú£elu bylo moºné vyuºít jiº existujícího
ProximitySensoru
vytvo°eného za ú£elem zaji²t¥ní pohybu
panelu HUD po virtuálním sv¥t¥ spole£n¥ s avatarem. Tento senzor poskytuje informace jak o aktuální poloze avatara, tak o úhlu jeho nato£ení. Úkolem skriptu je tyto hodnoty pat°i£n¥ upravit a p°edat je ²ipce navigující po map¥. Vzhledem k tomu, ºe avatar se pohybuje v rovin¥ xz, ale ²ipka v rovin¥ xy, musejí být hodnoty z osy z ²ipce p°edávány jako hodnoty na ose y. Rovn¥º je nutné kv·li nevyhovující orientaci t¥chto os zam¥nit kladné hodnoty za záporné a naopak. Ve²keré hodnoty pak musejí být upraveny v jiº d°íve stanoveném pom¥ru 1:200. Rotace ²ipky probíhá pouze podle osy y, proto bylo moºné nastavit hodnotu ur£ující osu otá£ení stabiln¥ práv¥ na osu y. Hodnoty úhlu nato£ení avatara p°ijaté ze senzoru není moºné p°ímo p°edávat ²ipce, nebo´ senzor p°edává p°i oto£ení na jednu £i druhou stranu vºdy kladné hodnoty v rozsahu 0 aº 3,14. Je proto nutné u£init rozhodnutí, o který sm¥r se jedná na základ¥ hodnoty ur£ující osu otá£ení, která nabývá kladné nebo záporné hodnoty práv¥ v závislosti na sm¥ru otá£ení.
Skrytí mapy Zaji²t¥ní funk£nosti tla£ítka ovládajícího zobrazení nebo skrytí mapy bylo dal²ím p°ípadem, p°i n¥mº bylo nutno pouºít skript. P°ed realizací samotného skriptu bylo zapot°ebí stanovit
16
KAPITOLA 3.
mapu, tedy plánek a ²ipku, jako potomka uzlu
REALIZACE
Switch. Tento uzel umoº¬uje vybrat, který z
jeho potomk· má být zobrazen. Zobrazen m·ºe být bu¤ ºádný, nebo práv¥ jeden potomek. To je p°esn¥ p°ípad mapy, která se bu¤ zobrazit má, nebo její zobrazení ºádoucí není. Implicitn¥ je v uzlu
Switch nastaveno nezobrazovat nic. V na²em p°ípad¥ je ale d·leºité, aby se uºivatel
o existenci mapy dozv¥d¥l okamºit¥. Teprve pak se m·ºe rozhodnout, zda si její zobrazení p°eje £i nikoli. Z tohoto d·vodu bylo v odpovídajícím parametru uzlu
Switch
nastaveno
mapu p°i vstupu do virtuálního sv¥ta zobrazit. Skript pak má jen jednoduchý úkol. Je-li kliknuto na odpovídající tla£ítko, pouze zam¥nit hodnotu parametru ur£ujícího, zda se má mapa zobrazit £i skrýt.
Zm¥na pohledu Skriptem, jehoº implementaci provázely nejv¥t²í problémy, byl skript ovládající tla£ítko pro zm¥nu pohledu. Zpo£átku se zdálo, ºe nep·jde o ºádný sloºitý úkol. Skript m¥l pouze po zji²t¥ní, ºe na dané tla£ítko bylo kliknuto, zm¥nit jeho texturu a podle toho, o jaký pohled se jednalo, upravit hodnotu ur£ující vý²ku o£í avatara a sou°adnici ur£ující vý²ku pouºitých Viewpoint·. Poté, co byl skript s t¥mito funkcemi realizován, následovalo jeho testování ve dvou jiº zmín¥ných VRML prohlíºe£ích, Cortona a BS Contact. Testování v²ak p°ineslo velmi nep°íznivé výsledky. V prohlíºe£i Cortona do²lo ke zm¥n¥ vý²ky pohledu aº poté, co uºivatel s avatarem pohnul. To mohlo na uºivatele p·sobit dojmem, ºe dané tla£ítko neplní svou funkci. V prohlíºe£i BS Contact tento problém sice nenastal, zato se v²ak objevil jiný. Pokud uºivatel zm¥nil pohled z implicitn¥ nastaveného pohledu dosp¥lého na pohled dít¥te, v²e fungovalo jak má. Jakmile se ale pokusil p°epnout zp¥t do pohledu dosp¥lého, avatar z·stal jakoby zaseknutý v podlaze a nebylo moºné s ním ºádným zp·sobem pohybovat. Tento problém se poda°ilo vy°e²it aº vytvo°ením jakéhosi pohyblivého Viewpointu. Jedná se o nepojmenovaný Viewpoint, který není nijak zahrnut do 10 základních, které tvo°í stanovi²t¥ pro virtuální prohlídku. Po na£tení virtuálního sv¥ta je umíst¥n do st°edu soustavy sou°adnic a v okamºiku pouºití tla£ítka pro zm¥nu pohledu, je p°esunut na aktuální sou°adnice avatara a aktivován. Skript tedy pracuje tak, ºe si p°i kaºdé zm¥n¥ pozice a orientace avatara jejich hodnoty ukládá a jakmile dojde k vyuºití zm¥ny pohledu, po²le je jako sou°adnice zmín¥nému Viewpintu a sou£asn¥ tento Viewpoint aktivuje. Ani po odstran¥ní tohoto problému v²ak nebylo vyhráno, nebo´ v souvislosti s tímto °e²ením se u prohlíºe£e Cortona objevil problém nový. P°i testování tohoto °e²ení na míst¥ ihned po na£tení virtuálního sv¥ta se v²e zdálo být v po°ádku. Problém nastal, jakmile se avatar pohnul z místa a teprve potom do²lo k vyuºití zm¥ny pohledu. P°i kaºdém dal²ím stisku tla£ítka, byl avatar posunut práv¥ o vzdálenost odpovídající té, kterou p°ed první aktivací tla£ítka urazil. Po n¥kolikerých pokusech o odstran¥ní tohoto problému bylo zji²t¥no, ºe pokud se avatar p°emístí do jiného Viewpointu, zm¥na pohledu funguje jak má, ale znovu pouze do chvíle, neº se avatar pohne z místa. Jako moºné °e²ení se proto jevilo p°ed kaºdou zm¥nou pohledu k tomuto ú£elu ur£ený Viewpoint deaktivovat a hned vzáp¥tí znovu aktivovat. Toto °e²ení se v²ak dlouho neda°ilo realizovat, protoºe mezi dv¥ma bezprost°edn¥ následujícími kliknutími na tla£ítko nebyl ºádný prostor tuto operaci provést. Jediným nalezeným zp·sobem bylo Viewpoint deaktivovat po stisknutí tla£ítka my²i a znovu aktivovat po jeho uvoln¥ní. Tento zp·sob °e²ení s sebou ale p°iná²í moºnost, ºe pokud uºivatel podrºí tla£ítko my²i zmá£knuté dlouho, bude v d·sledku deaktivace Viewpointu p°emíst¥n na jiný aktivovaný. Co nejv¥t²ího omezení neºádoucího efektu lze dosáhnout pouºitím zvoleného °e²ení pouze pro prohlíºe£ Cortona,
3.5.
SKRIPTY
17
ve kterém se daný problém vyskytuje. Tato moºnost je k dispozici, nebo´ uvnit° skriptu lze zjistit název pouºívaného VRML prohlíºe£e. Výsledný skript vypadá takto:
S_pohled Script { eventIn SFBool klik #kliknutí na tla£ítko eventIn SFVec3f poloha #aktuální poloha avatara eventIn SFRotation rotace #aktuální nato£ení avatara field SFVec3f souradnice 0 0 0 #pole pro ukládání aktuální polohy avatara field SFRotation orient 0 0 0 0 #pole pro ukládání aktuálního nato£ení avatara eventOut MFFloat size #nové rozm¥ry avatara eventOut SFVec3f y #nová vý²ka Viewpoint· eventOut SFVec3f pozice #nová pozice pohyblivého Viewpointu eventOut SFBool bind #aktivace pohyblivého Viewpointu field SFBool dospely TRUE #p°íznak aktuálního pohledu eventOut SFRotation orientace #nová orientace pohyblivého Viewpointu eventOut MFString textura #název textury url "javascript: function poloha (hodnota, cas) #funkce pro ukládání aktuální polohy { souradnice=hodnota; } function rotace (hodnota, cas) #funkce pro ukládání aktuální orientace { orient=hodnota; } function klik (hodnota, cas) { if (hodnota) { if (dospely) { size[1]=y[1]=1; textura[0]='textury/pohled0.gif';} if (!dospely) { size[1]=y[1]=1.6; textura[0]='textury/pohled1.gif';} size[0]=0.25; size[2]=0.2; if (Browser.getName()=='Cortona3D Viewer') bind=false; #deaktivace Viewpointu pro Cortona 3D pozice[0]=souradnice[0]; pozice[2]=souradnice[2]; pozice[1]=y[0]=y[2]=orientace[0]=orientace[2]=0; orientace[1]=1; orientace[3]=orient[3]*orient[1]; dospely=!dospely; } else bind=true; #aktivace Viewpointu }"
18
KAPITOLA 3.
REALIZACE
Navigace pomocí mapy Jako dal²í byl implementován skript zaji²´ující navigaci pomocí mapy. Jedná se spolu se skriptem p°evád¥jícím polohu avatara na polohu ²ipky o nejd·leºit¥j²í skript, pouºitý ve virtuálním modelu mate°ské ²koly. Uºivatelé, kte°í se b¥ºn¥ nepohybují ve virtuálních sv¥tech, £asto ani nemusejí p°ijít na to, ºe v nich existuje navigace pomocí Viewpoint·, nebo jim tato navigace nemusí vyhovovat. Pro úsp¥²né uplatn¥ní virtuálního modelu je proto dobré uºivatel·m nabídnout je²t¥ jiný zp·sob navigace. Jak jiº bylo zmín¥no, skript ovládající ²ipku funguje na principu p°evád¥ní pohybu avatara ve trojrozm¥rném prostoru na pohyb ²ipky po dvourozm¥rné map¥. Tento skript by m¥l zaji²´ovat v podstat¥ opa£nou proceduru. Jeho úkolem je p°evod sou°adnic místa kliknutí v plánku na sou°adnice ve virtuálním sv¥t¥. P°ed samotnou realizací tohoto skriptu bylo d·leºité zodpov¥d¥t otázku týkající se volnosti pohybu uºivatele. Bylo by lep²í p°edp°ipravit sadu Viewpoint·, do kterých bude uºivatel p°esunut po kliknutí do ur£ité oblasti na plánku, nebo uºivatele p°emístit p°esn¥ na sou°adnice, kam uºivatel kliknul. Ob¥ tyto varianty mají své klady i zápory. První moºnost p°iná²í kontrolu nad tím, kam uºivatel m·ºe být p°emíst¥n, ale zárove¬ dosti omezuje volnost pohybu uºivatele. Druhá moºnost uºivateli dává plnou volnost v rozhodování, kam bude p°esunut. Zárove¬ ale m·ºe dojít k p°esunu na místa, kam by se uºivatel správn¥ dostat nem¥l. M·ºe dojít nap°íklad k zaseknutí uºivatele ve zdi nebo v nábytku. Po zhodnocení obou t¥chto moºností p°eváºila ta, jeº poskytuje uºivateli v¥t²í volnost. P°i realizaci tohoto skriptu byl vyuºit princip podobný tomu, který byl zvolen v p°ípad¥ p°epínání pohled·. Vyuºilo se tedy jiº existujícího pohyblivého Vievpointu s tím rozdílem, ºe se do n¥ho neposílají aktuální sou°adnice avatara, ale upravené sou°adnice ode£tené z mapy. Skript tedy d¥lá to, ºe p°i pohybu ukazatele my²i po map¥ ode£ítá sou°adnice, na kterých se nachází a ty pr·b¥ºn¥ ukládá. Tyto sou°adnice jsou op¥t transformovány v pom¥ru 1:200. Dále jsou upravovány tak, aby odpovídaly st°edy jejich sou°adných systém· a následn¥ zaokrouhlovány na celá £ísla. V okamºiku, kdy uºivatel na mapu klikne, se sou°adnice po²lou do pohyblivého Vievpointu a dojde k jeho aktivaci. I v tomto p°ípad¥ musel být odstran¥n vý²e zmín¥ný problém vyskytující se v prohlíºe£i Cortona.
Nápov¥da k tla£ítk·m Posledním skriptem, který se váºe k funkcionalit¥ panelu HUD, je skript zaji²´ující zobrazení nápov¥dy k tla£ítk·m. Tento skript se od ostatních li²í v tom, ºe je p°ímou sou£ástí prototypu tla£ítka. Jeho úkolem je v p°ípad¥, ºe uºivatel najede ukazatelem my²i nad tla£ítko, vzít text nápov¥dy p°edaný v prototypu jako parametr a ten poslat k zobrazení uzlu Text. Aby text nápov¥dy na obrazovce nez·stával i poté, co ukazatel my²i tla£ítko opustí, skript uzlu Text za²le prázdný °et¥zec.
3.6 Dynamika Pro oºivení jinak statického sv¥ta je dobré alespo¬ n¥které jeho sou£ásti rozpohybovat. V tomto p°ípad¥, kdy je modelována hlavn¥ budova a její vybavení, kterým je p°eváºn¥ nábytek, jsou moºnosti pouºití dynamiky zna£n¥ omezené. Vzhledem k tomu, ºe celý model byl vytvá°en s d·razem na pouºití co nejjednodu²²ích tvar· a dokreslením sloºitosti takto
3.7.
19
STRUKTURA PROJEKTU
modelovaných objekt· pouze pomocí textur, nebylo u nich moºné nalézt ºádnou sou£ást, s níº by bylo moºné pohybovat. Vhodnými objekty, na n¥º by bylo moºné dynamiku aplikovat, jsou dve°e. Zvaºována byla moºnost nastavit ve²keré dve°e jako zav°ené a ponechat jejich otevírání a zavírání na uºivateli. Ta ale nakonec nebyla realizována. Jednak proto, ºe by tento úkon mohl být pro uºivatele p°íli² sloºitý a jednak pro to, ºe uºivatel nemá moºnost n¥které dve°e otev°ít, coº by na n¥j mohlo p·sobit matoucím dojmem. Nakonec byly p°ece jen alespo¬ jedny dve°e rozpohybovány, aby uºivatel poznal, ºe ve virtuální prohlídce je moºné s objekty pohybovat. Zvoleny byly hlavní vchodové dve°e, které v²ak nejsou otevírány p°ímo uºivatelem, jak bylo p·vodn¥ zamý²leno. Tyto dve°e jsou automaticky otevírány pomocí inerpolátoru a £asova£e, poté co se k nim uºivatel na ur£itou vzdálenost p°iblíºí. Dve°e jsou rovn¥º automaticky zavírány v p°ípad¥, ºe se od nich uºivatel op¥t vzdálí.
3.7 Struktura projektu Struktura projektu byla volena v závislosti na po°adí, v jakém je nejvýhodn¥j²í jednotlivé £ásti modelu na£ítat, tak aby uºivatel co nejrychleji spat°il objekty v míst¥ svého vstupu do virtuálního sv¥ta. Hlavní soubor pojmenovaný
skolka_start.wrl obsahuje pouze informace
o souboru a jeho tv·rci, de nici zp·sobu procházení sv¥tem, de nice Viewpoint·, a panel HUD se skripty pot°ebnými k jeho funk£nosti. Do n¥ho je pomocí uzlu
Inline
vloºen
souborskolka_new.wrl obsahující model vn¥j²ího plá²t¥ budovy a modely dve°í. Do tohoto souboru jsou následn¥ znovu pomocí uzlu
Inline vkládány soubory obsahující modely jednot-
livých místností s jejich vybavením. Model d¥tské ºidle je kv·li jeho pouºití ve více místnostech uloºen v samostatném souboru
Inline.
zidle.wrl
a do t¥chto místností vkládán op¥t pomocí uzlu
Prototypy £ástí vnit°ních zdí s okny nebo dve°mi jsou uloºeny také v samostatných
souborech a do soubor· s místnostmi vkládány pomocí konstrukce EXTERNPROTO.
3.8 Integrace do webových stránek M Následujícím krokem po vytvo°ení kompletního modelu bylo vhodným zp·sobem vzniklý model integrovat do jiº existujících webových stránek mate°ské ²koly. Jednalo se o nejd·leºit¥j²í krok k tomu, aby model mohl za£ít plnit funkci, pro kterou byl od za£átku vytvá°en. Jednak umoºnit rodi£·m d¥tí, které jiº Mate°skou ²kolu Kamarád nav²t¥vují, p°edstavit prost°edí, kde jejich d¥ti tráví tém¥° celý den ostatním £len·m rodiny a známým. Rovn¥º má model nabídnout novým zájemc·m o umíst¥ní d¥tí do p°ed²kolního za°ízení moºnost si prostory zvolené mate°ské ²koly prohlédnout bez osobní náv²t¥vy a tím u²et°it jejich £as. P·vodní zám¥r byl vytvo°it stránku s modelem p°ímo ve webovém prostoru mate°ské ²koly, na adrese http://mstepleho-pardubice.xf.cz. Tento zám¥r ale nemohl být realizován, protoºe nebyl umoºn¥n p°ímý p°ístup do webového prostoru mate°ské ²koly s ohledem na ochranu osobních dat jejího vedení. Po domluv¥ s °editelkou ²koly byl zvolen jiný zp·sob, a to takový, ºe stránka s modelem bude umíst¥na v jiném webovém prostoru a do webových stránek M bude vloºena jako externí. Vzhledem k tomu, ºe stránky M jsou vytvo°eny pomocí rámc·, byl tento úkol zna£n¥ usnadn¥n. M uº ve svých stránkách pouºívala externí fotogalerii realizovanou pomocí webových alb programu Picasa, a tak mohl být uplatn¥n stejný zp·sob za£len¥ní externí stránky s modelem do stránek M. Do panelu Navigace,
20
KAPITOLA 3.
REALIZACE
který je sou£ástí hlavního rámce, byl p°idán odkaz s názvem Virtuální procházka sm¥rující na stránku s modelem, která se tak po p°echodu na tento odkaz zobrazí v hlavním rámci stránek M a bude p·sobit jako jejich sou£ást. Jak jiº bylo uvedeno, pro stránku s modelem musel být zaloºen nový webový prostor. Kv·li zachování integrity byl zvolen stejný poskytovatel webhostingu jako u stránek M, kterým je webzdarma.cz. Také byla zvolena adresa co nejpodobn¥j²í adrese stránek M a to http://mstepleho-pardubice.wz.cz. Design stránky byl upraven pouºitím CSS vytvo°ených tak, aby její vzhled byl totoºný se vzhledem stránek M a zapadal tak do jejich konceptu. Webová stránka byla vytvo°ena v programu NetBeans IDE 6.0.1 [11] a její kód vypadá následovn¥:
Pokud se vám vý²e nezobrazilo okno s virtuálním modelem (viz následující obrázek),
nemáte VRML prohlíºe£ nainstalován nebo není ve webovém prohlíºe£i povolen.
Výsledný vzhled stránky jiº zasazené do rámce stránek M ve webovém prohlíºe£i s nainstalovaným programem Cortona3D Viewer ukazuje obrázek C.1.
Kapitola 4
Testování Vzhledem k tomu, ºe pro prohlíºení model· virtuálního sv¥ta je zapot°ebí mít nainstalován ve webovém prohlíºe£i jako jeho roz²í°ení n¥jaký z dostupných prohlíºe£· VRML, bylo by dobré zahrnout do testování i to, zda je uºivatel schopen tento krok provést. Pokusit se tedy zjistit, zda uºivatel v·bec pochopí, ºe prohlíºe£ VRML pot°ebuje nainstalovat, kde takový prohlíºe£ získá a jak ho nainstaluje. Proto bylo zvoleno jako nejlep²í moºnost, aby testování provád¥l kaºdý uºivatel na svém vlastním po£íta£i. Z tohoto d·vodu bylo provád¥no testování vzdálen¥. Forma testování tedy byla taková, ºe uºivatel·m byly rozdány vizitky s adresou webových stránek mate°ské ²koly a byli poºádáni, aby bez jakýchkoli dal²ích instrukcí vyzkou²eli nov¥ p°idanou sou£ást webových stránek, tedy virtuální prohlídku. Poºádáno bylo 5 osob, které s virtuálními prohlídkami doposud nem¥ly ºádné zku²enosti, pouze 3 z nich v²ak poskytly kýºené informace v daném termínu. Poté, co uºivatelé potvrdili, ºe testování realizovali, byly jim bu¤ ústn¥ p°i osobním pohovoru, nebo písemn¥ pokládány následující otázky:
• Poda°ilo se Vám na webových stránkách M nalézt sekci s virtuální prohlídkou? • Pokud ano, poda°ilo se Vám podle instrukcí na webové stránce prohlídku zprovoznit? • Pokud ano, v jakém webovém prohlíºe£i jste prohlídku provád¥l/a? • Jaký prohlíºe£ VRML jste pouºil/a? • Jaký opera£ní systém pouºíváte? • Jak rychle se Vám zobrazily textury? • Nedocházelo v pr·b¥hu prohlídky k jejímu zasekávání? • Jak jste byl/a spokojen/a s moºnostmi navigace a jaký zp·sob jste nejvíce vyuºil/a? • Pochopil/a jste význam v²ech naviga£ních prvk·? • Vyuºil/a jste otev°ení prohlídky v novém okn¥, nebo pouze v p·vodní stránce? • Byla pro vás virtuální prohlídka v n¥jakém sm¥ru p°ínosná? • Vyskytly se u Vás n¥jaké problémy, nebo máte n¥jaké dal²í p°ipomínky? Výsledky od jednotlivých uºivatel· vypadají následovn¥:
21
22
KAPITOLA 4.
TESTOVÁNÍ
1.uºivatel
Stránka s virtuální procházkou byla nalezena bez problém·. Po jejím otev°ení se v míst¥ prohlídky objevil prázdný obdélník. Podle instrukcí na stránce byl nainstalován prohlíºe£ Cortona do webového prohlíºe£e Internet Explorer 8, pod opera£ním systémem Windows XP. Na£tení textur prob¥hlo okamºit¥ a nic se nezasekávalo. Mapa je p°ehledná a pouºívána ob£as v kombinaci s procházením pomocí my²i. U li²ty prohlíºe£e chvíli trvalo osvojení jejich funkcí. Byly vyuºity ob¥ moºnosti zobrazení prohlídky. P°ínosem bylo jednak seznámení s novou technologií a prost°edím M, kterou nav²t¥vuje vnuk. Jediným zji²t¥ným nedostatkem bylo p°esouvání na jinou pozici p°i podrºení stisknutého tla£ítka my²i na map¥. 2.uºivatel
Sekce s virtuální procházkou byla nalezena bez problém·. Do prohlíºe£e Internet Explorer 7 byl nainstalován prohlíºe£ Cortona. Pouºívaný opera£ním systémem je Windows XP. Na£tení textur prob¥hlo bez problém· a prohlídka se nezasekávala. Vyuºívány byly v²echny zp·soby navigace, ale za nejlep²í byla povaºována ta pomocí Viewpoint·. Funkce tla£ítek byla pochopena okamºit¥ a také vyuºívána. Byla vyuºita pouze moºnost otev°ení prohlídky v novém okn¥. P°ínosem bylo seznámení se s prost°edím M, do níº by m¥l syn nastoupit. Vzhledem k tomu, ºe £lov¥k nehledí p°ímo p°ed sebe, ale jeho pohled je mírn¥ sklopený, m¥lo by dojít k úprav¥ pohled· v tomto smyslu. 3.uºivatel
Nalezení stránky s prohlídkou ne£inilo problémy. Byl pouºit prohlíºe£ Cortona integrovaný do webového prohlíºe£e Mozila Firefox. Pouºívaný systémem je Windows XP. Na£tení textur prob¥hlo pomaleji, coº bylo nejspí² zp·sobeno známým problémem s pomalým internetovým p°ipojením. K zasekávání prohlídky ale nedocházelo. Jako nejlep²í a nejvíce vyuºívaná byla zvolena navigace pomocí mapy. Funkce naviga£ních prvk· byla jasná. První seznámení s prohlídkou prob¥hlo p°ímo ve stránce, poté bylo vyuºito její zobrazení v novém okn¥. P°ínosem bylo poznání nové technologie seznámení se s M, kterou nav²t¥vuje synovec. Chybí zde moºnost vyuºít pro pohyb po sv¥t¥ otá£ení kole£kem my²i a cht¥lo by lépe ozna£it hlavní vchodové dve°e. Shrnutí výsledk·
Ze získaných odpov¥dí lze usoudit, ºe by uºivatelé nem¥li mít problém ani se zprovozn¥ním ani s pouºíváním virtuální prohlídky. Tím se dá poºadavek na intuitivní ovládání povaºovat za spln¥ný. Také nenastaly ºádné váºn¥j²í problémy s na£ítáním virtuálního sv¥ta a se zasekáváním pohybu b¥hem jeho prohlídky. To ukazuje, ºe zvolený zp·sob vytvo°ení modelu byl vhodný a ºe tento model opravdu neklade ºádné vysoké nároky jak v oblasti výpo£etní, tak v oblasti pam¥´ového zatíºení. Uºite£nost virtuální prohlídky byla také testováním potvrzena. Co se tý£e p°ipomínek uºivatel·, ty budou zahrnuty mezi moºná vylep²ení do budoucna.
Kapitola 5
Záv¥r Cílem této bakalá°ské práce bylo vytvo°it virtuální model Mate°ské ²koly Kamarád v Pardubicích a p°isp¥t tak k propagaci tohoto ²kolského za°ízení. Vzhledem k tomu, ºe rodi£e jsou v sou£asné dob¥ v¥t²inou velmi pracovn¥ vytíºeni a internet je sou£ástí jiº tém¥° kaºdé domácnosti, jevil se tento zp·sob propagace jako optimální, nebo´ u²et°í jejich £as a umoºní jim porovnávat interiéry mate°ských ²kol, které jiº zp°ístup¬ují uºivateli seznámení se s prost°edím touto formou. Model byl tedy vytvo°en tak, aby se co nejvíce p°iblíºil reálné podob¥ mate°ské ²koly a byl umíst¥n do jejich webových stránek. Shoda, kv·li nutnému zjednodu²ení z d·vodu minimalizace nárok· na technické vybavení po£íta£·, které jsou v rodinách b¥ºn¥ k nalezení, nemohla být stoprocentní. Pokud by totiº byl model vytvo°en se v²emi dopl¬ky, které se v budov¥ M vyskytují, kladl by tento model p°íli² vysoké poºadavky na technické vybavení po£íta£·, £ímº by ztratil sv·j smysl zp°ístupnit prostory M ²iroké ve°ejnosti. K porovnání reality a virtuálního modelu jsou k dispozici obrázky B.1, B.2, B.3, B.4, B.5, B.6 a B.7 umíst¥né v p°íloze. Model byl po dokon£ení otestován z hlediska pouºitelnosti a informa£ní hodnoty nezávislými uºivateli. Výsledky tohoto testování ukázaly, ºe model je snadno pouºitelný i pro laického uºivatele a poskytuje mu o£ekávané informace.
23
24
KAPITOLA 5.
ZÁV R
Literatura [1] ára Ji°í. Laskavý pr·vodce virtuálními sv¥ty. http://www.cgg.cvut.cz/LaskavyPruvodce/, stav z 20. 5. 2010. [2] The RGB Color Calculator. http://www.drpeterjones.com/colorcalc/, stav z 20. 5. 2010. [3] Citera vrml color chart. http://www.theedventuregroup.org/citerawv/resources/, stav z 20. 5. 2010. [4] BS Contact. http://www.bitmanagement.com/en/products/interactive-3d-clients/ bs-contact, stav z 20. 5. 2010. [5] Cortona 3D Viewer. http://www.cortona3d.com/Products/Cortona-3D-Viewer.aspx, stav z 20. 5. 2010. [6] Textura zámková dlaºba. http://www.corelclub.cz/galerie/textury/materialy/zamkova_dlazba.jpg, 20. 5. 2010.
stav
z
[7] Gimp 2. http://www.gimp.org/, stav z 20. 5. 2010. [8] Irfanview. http://www.irfanview.cz/, stav z 20. 5. 2010. [9] Textura tla£ítka pro mapu. http://koha.lib.ntua.gr/opac-tmpl/prog/itemtypeimg/bridge/map.gif, 20. 5. 2010.
stav
z
[10] Mate°ská ²kola Kamarád v Pardubicích. http://mstepleho-pardubice.xf.cz/, stav z 20. 5. 2010. [11] Netbeans IDE 6.0.1. http://netbeans.org/, stav z 20. 5. 2010. [12] Vrml Pad. http://www.parallelgraphics.com/products/vrmlpad/, stav z 20. 5. 2010. [13] Dopravní zna£ka Stezka pro chodce. http://www.vsechny-autoskoly.cz/images/dopravni_znacky/velke/c7a.gif, 20. 5. 2010.
25
stav
z
26
LITERATURA
P°íloha A
Seznam pouºitých zkratek CSS Cascading Style Sheets GIF Graphics Interchange Format GPU Graphics Processing Unit HUD Head-up Display JPEG Joint Photographics Experts Group M Mate°ská ²kola PNG Portable Network Graphics VRML Virtual Reality Modeling Language X3D Extensible 3D
27
28
PÍLOHA A.
SEZNAM POUITÝCH ZKRATEK
P°íloha B
Porovnání se skute£ností
Obrázek B.1: Venkovní pohled na budovu
Obrázek B.2: Pohled do ²atny
29
30
PÍLOHA B.
POROVNÁNÍ SE SKUTENOSTÍ
Obrázek B.3: Pohled z herny do loºnice
Obrázek B.4: Pohled do loºnice
Obrázek B.5: Pohled do loºnice 2
31
Obrázek B.6: Pohled do jídelny
Obrázek B.7: Pohled do umývárny
32
PÍLOHA B.
POROVNÁNÍ SE SKUTENOSTÍ
P°íloha C
Webová stránka s instrukcemi pro uºivatele Základní instrukce pro uºivatele ohledn¥ zprovozn¥ní virtuální prohlídky jsou umíst¥ny p°ímo na stránce projektu. Stránka obsahuje okno s virtuální procházkou a pod ním je umíst¥na nápov¥da, jak postupovat v p°ípad¥, ºe je toto okno prázdné a není v n¥m zobrazen ºádný model. Její strukturu ukazuje obrázek C.1.
33
34
PÍLOHA C.
WEBOVÁ STRÁNKA S INSTRUKCEMI PRO UIVATELE
Obrázek C.1: Ukázka webové stránky s modelem za£len¥né do rámce stránek M
Obsah p°iloºeného CD • README.txt - obsah CD a popis zprovozn¥ní virtuální prohlídky • text - obsahuje text bakalá°ské práce ve formátu PDF • text_zdroj - obsahuje zdrojové soubory textu v programu LaTeX • model - obsahuje zdrojové soubory virtuálního modelu • web - obsahuje zdrojové soubory webové stránky s projektem
