Virtuální průvodce budovou FEL. Pavel Holý

České vysoké učení technické v Praze Fakulta elektrotechnická

Bakalářská práce

Virtuální průvodce budovou FEL Pavel Holý

Vedoucí práce: Ing. Roman Berka

Studijní program: Elektrotechnika a informatika strukturovaný bakalářský Obor: Informatika a výpočetní technika červen 2008

Poděkování Rád bych na tomto místě poděkoval Ing. Romanu Berkovi za to, že mi dal možnost zpracovat toto téma jako bakalářskou práci. Dále bych chtěl poděkovat mnoha kolegům, kteří mě psychicky podporovali, obzvláště velký dík patří Adamu „napalm“ Konrádovi, bez jeho motivace by práce nebyla dokončena. V neposlední řadě chci poděkovat své matce za revizi této práce.

ii

Prohlášení Prohlašuji, že jsem svou bakalářskou 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 24. 5. 2008

………………………………………… iii

Abstract This thesis analyses existing virtual models of FEE building and applications for navigation within this building. It uses them as inspiration and describes the choice of a new engine and development of a virtual model for this engine and modification of existing application to achieve effective navigation in this model. It also describes implementation of the final product into electronic kiosk and into the virtual room called Cave. Finally it proposes future development of the model. For better imagination it includes pictures of modifications and final product.

Abstrakt Tato práce analyzuje stávající virtuální modely budovy FEL a aplikace pro navigaci po budově. Nepřímo se z nich inspiruje a popisuje výběr nového enginu a vývoj virtuálního modelu pro tento engine. Popisuje modifikaci původní aplikace za účelem umožnění efektivní navigace ve vytvořeném modelu. Dále pojednává o implementaci výsledného produktu do elektronického kiosku a do virtuální místnosti Cave. Závěrem navrhuje další vývoj tohoto modelu. U jednotlivých kapitol jsou, pro lepší znázornění provedených úprav a výsledného modelu, vloženy obrázky.

iv

OBSAH 1

ÚVOD

1

1.1

Motivace

1

1.2

Výzva jménem Dejvice 3D

1

1.3

Osobní výzva

1

1.4

Inspirace pro ostatní

2

2

ANALÝZA

2

Dejvice 3D

2

2.1.1

Model

3

2.1.2

Textury

3

2.1.3

Engine

4

2.1.4

Navigace

4

2.1.5

Věrnost

4

2.1

2.2

Průvodce po ČVUT FEL

5

3

PROJEKT BLOF

5

3.1

Výběr enginu

5

3.1.1

OGRE

6

3.1.2

Quake 3 engine

6

3.2

Obsah

7

3.2.1

Open Arena

7

3.2.2

Xreal

8

3.2.3

IOQuake

8

3.3

Zdrojový kód

9

3.4

Editor mapy

9

3.4.1

4

GTK radiant

9

TVORBA MAPY

11

4.1

Jednoduchá mapa

11

4.2

Rozvoj jednoduché mapy

12

4.3

Textury

13

4.4

Oživování mapy

13

4.5

Výchozí patro

14

4.6

Modelování pater

15

4.6.1 4.7

Architektonické plány budovy

15

Struktura mapy

15

v

4.8

Plnění mapy

15

4.8.1

Modelace objektů v Quake editoru

16

4.8.2

Modelace objektů v ostatních editorech

16

4.8.3

Nástěnky

17

Obohacování

18

4.9.1

Humor

18

4.9.2

Komiksy

18

4.9

4.10

Problémy při tvorbě

18

4.10.1

Velikost mapy

18

4.10.2

Hrany objektů

19

4.10.3

Úhly objektů

19

4.11

Možnosti vylepšení

19

4.11.1

Nové prostory

20

4.11.2

Více modelů

20

4.11.3

Shadery

20

4.12

Odlaďování

20

4.13

Statistiky

21

5

IMPLEMENTACE NAVIGACE

21

5.1

Analýza

21

5.2

Řešení

21

5.3

Vložení nové místnosti

22

5.4

Efektivita

22

5.5

Ukázka

23

6

ELEKTRONICKÝ KIOSEK

25

6.1

Shánění kiosku

25

6.2

Popis kiosku

25

6.3

Komplikace

26

6.4

Budoucnost

26

6.5

Ukázka

26

7

PREZENTACE NA WWW

27

8

BUDOUCNOST PROJEKTU

28

8.1

BloF jako nástroj

28

8.2

Přenosná zařízení

28

8.2.1

PDA a PPC

28

8.2.2

Mobilní telefony

29

8.2.3

Simulace evakuace

29

vi

9

ZÁVĚR

30

10 LITERATURA

30

PŘÍLOHA A

31

BLOF V CAVE

31

1. Co je Cave

31

2. Implementace

31

3. Řešení synchronizace

32

4. Řešení pohledů

32

5. Ukázka finálního kódu

33

PŘÍLOHA C

36

NÁSTROJE PRO TVORBU

36

1. Autodesk 3DS MAX

36

2. Adobe Photoshop

36

3. Adobe Premiere

37

PŘÍLOHA C

38

OBRAZÁRNA BLOFU

38

PŘÍLOHA D

45

UKÁZKA KÓDU

45

1.

Přidání entity

45

2.

Zpracování pozice a objevení bójky

45

PŘÍLOHA E

47

OBSAH CD

47

vii

Seznam obrázků Obrázek 2.1 Ukázka Dejvice 3D Obrázek 2.2 Ukázka textur Obrázek 2.3 Ukázka textur 2 Obrázek 2.4 Porovnání s realitou (Dejvice 3D vpravo) Obrázek 2.5 Ukázka programu Průvodce po ČVUT FEL Obrázek 3.1 Ukázka OGRE enginu Obrázek 3.2 Ukázka Quake 3 Arena enginu Obrázek 3.3 Quake 3 raytraced Obrázek 3.4 Quake 3 editor – GTK Radiant Obrázek 4.1 První mapa se čtyřmi stěnami Obrázek 4.2 Náznak první chodby Obrázek 4.3 Příklady textur Obrázek 4.4 Postupné oživování chodby Obrázek 4.5 Jedno kompletní patro Obrázek 4.6 Plány budovy v elektronické podobě Obrázek 4.7 Ukázka objektů vytvořených v GTK Radiantu Obrázek 4.8 Ukázka objektů vytvořených v externích editorech Obrázek 4.9 Ukázka objektů prázdné a zeditované nástěnky Obrázek 4.10 Komiks na téma BloF Obrázek 4.11 Klika s koulí před a po zjednodušení Obrázek 4.12 Příklad problikávající zdi a špatně natažené textury Obrázek 5.1 Ukázka výchozího stavu Obrázek 5.2 Bójka u hledané třídy Obrázek 5.3 Výzva „jdi o patro výš“ Obrázek 5.4 Místnost nalezena Obrázek 5.5 Přidání entity v editoru

2 3 3 4 5 6 7 8 10 11 12 13 14 14 15 16 16 17 18 19 20 23 23 24 24 25

Obrázek 6.1 Ukázka kiosku s funkčním BloFem

26

Obrázek 7.1 www stránky projektu

27

Obrázek 8.1 Quake na PPC Dell

28

Obrázek 8.2 Quake na iPhone

29

Obrázek A.1 Ukázka Cavu

31

Obrázek A.2 Grafický náznak problému otočených pohledů

33

Obrázek A.3 Příprava před vybudováním Cavu Obrázek A.4 BloF v Cavu Obrázek A.5 Prezentace Quake v Cavu na výstavě Eurographics 07 Obrázek A.6 Prezentace Quake v Cavu na výstavě Eurographics 07 Obrázek B.1 Příklad modelování v Max Obrázek B.3 Zpracování fotky v Photoshopu Obrázek B.4 Ukázka Premiere Obrázek C.1 Porovnání s realitou – 2. patro Obrázek C.2 Porovnání s realitou – zadní schodiště Obrázek C.3 Porovnání s realitou – odpadkové koše

34 34 35 35 36 37 37 38 38 39

viii

Obrázek C.4 Porovnání s realitou – schodiště Obrázek C.5 Porovnání s realitou – detail schodiště Obrázek C.6 Přízemí před PEO Obrázek C.7 Chodba ve 2. patře Obrázek C.8 Přízemí Obrázek C.9 Pohled na katedru elektrotechniky Obrázek C.10 Uvnitř katedry elektrotechniky Obrázek C 11 Pohled od stropu, 2.patro Obrázek C.12 - 5.patro, konec bočního schodiště Obrázek C.13 - 7.patro, konec hlavního schodiště Obrázek C.14 – Horní pohled na model v editoru Obrázek C.15 - Boční pohled na model v editoru

ix

39 39 40 40 41 41 42 42 43 43 44 44

KAPITOLA 1 ÚVOD

1 Úvod V průběhu semestru se na hlavních stránkách fakulty objevil odkaz na aplikaci, která obsahovala virtuální podobu budovy ČVUT FEL včetně vyhledávání místností, jejíž název je „Dejvice 3D“. Tato aplikace byla velikým zdrojem inspirace pro tuto bakalářskou práci. Hlavním cílem této bakalářské práce bylo vytvoření základního modelu budovy školy v Dejvicích, implementace navigace do vytvořeného modelu a realizace praktického využití v elektronickém kiosku. Vedlejším cílem tohoto projektu bylo nastudování vybraného enginu a vývojového prostředí a vytvoření postupu pro realizaci takto velkého projektu.

1.1 Motivace Již od dětství jsem hrál počítačové hry a postupně jsem se začal zajímat, jak jsou tyto hry vytvořené a jak fungují. Sám jsem se pokoušel vyvinout velmi jednoduché hry, ale kvůli nedostatku vědomostí a dovednosti jsem moc neuspěl. Díky studiu na vysoké škole jsem mnohé nabyl, a proto jsem se rozhodl připojit se ke komunitě lidí, kteří hry vyvíjí resp. obohacují. Ve své práci jsem chtěl poděkovat škole a přispět ke spokojenosti jejích studentů. Také jsem si chtěl vyzkoušel kompletní vývoj hry se všemi jeho fázemi, včetně programovaní a modelování. Snažil jsem se svoji práci zaměřit na něco smysluplného, to znamená, aby měla praktické využití. Přál bych si, aby se tato práce stala do budoucna použitelná pro další studenty, kteří by na ní mohli dále pracovat, případně některou část použít pro svoji vlastní tvorbu.

1.2 Výzva jménem Dejvice 3D Prvním hnacím motorem pro realizaci této bakalářské práce byl právě zmíněný projekt studentů Petra Kratochvíla a Michala Mrhy z roku 2006 „Dejvice 3D“. Velice jsem si tento projekt oblíbil a byl pro mne dlouhou dobu výzvou k překonání a laťkou stanovenou velmi vysoko. Původně jsem chtěl tento model nejprve vylepšit a obohatit o další funkce, ale po hlubší analýze jsem se rozhodl začít znovu a vytvořit model nový.

1.3 Osobní výzva Pro náročnost projektu a hlavně rozsáhlost se jeho dokončení stalo velikou osobní výzvou. Chtěl jsem sám sobě dokázat, že jsem schopen zrealizovat projekt až do konce. Velmi cenným přínosem pro mne byla možnost vyzkoušet si jednotlivé fáze vývoje hry, včetně tvorby textur a použití neznámého enginu. Velkou výhodou pro mne bylo, že jsem si sám stanovoval jednotlivé úkoly a postupně jsem se v jednotlivých kategoriích zdokonaloval. Po čase se naskytly možnosti implementovat nový model do Cave a do elektronického kiosku, které celý model posunuly do použitelné podoby a dodaly mu tak praktický smysl.

1

KAPITOLA 2 ANALÝZA

1.4 Inspirace pro ostatní Rozsáhlost práce i zájem ostatních studentů způsobila, že jsem začal model školy považovat za nástroj, který by v budoucnu mohl být použit jako základ pro další zajímavé projekty, a jeho autoři by se nemuseli zdržovat vytvářením nového modelu. Sám jsem zvažoval realizaci dalších funkcí, ale pro velkou časovou složitost samotného modelování na ně zatím bohužel nezbyl čas. Osobně si ale myslím, že například pro předmět Intermediální tvorby a technologie by mohla být moje práce přínosná. Chtěl bych také v práci na projektu modelu školy pokračovat i po odevzdání této bakalářské práce .

2 Analýza V rámci fáze analýzy jsem se soustředil na posouzení stávajících virtuálních modelů a jejich použitelnost pro vylepšení stávajícího modelu školy. Bohužel byl výběr velmi omezený a nedal mi jiné možnosti, než vyvinout vlastní model. Z analyzovaných projektů jsem také čerpal inspiraci pro implementaci navigace, ale bohužel se velmi rozcházela s pokyny pro tuto práci, a proto jsem se s myšlenkou něco použít, musel rozloučit.

2.1 Dejvice 3D Velmi dlouho jsem zvažoval použití jediného stávajícího virtuálního modelu budovy FEL „Dejvice 3D“. Tento model má však příliš mnoho nedostatků, jak je detailně zanalyzováno v následujících kapitolách, že jsem se rozhodl od jeho použití jednoznačně ustoupit.

Obrázek 2.1 Ukázka Dejvice 3D 2

KAPITOLA 2 ANALÝZA 2.1.1

Model

Původní neoptimalizovaný model školy je velmi rozsáhlý a těžkopádný. Obsahuje mnoho zbytečných vertexů. Bohužel čísla nadbytečných vertexů jdou do tisíců, což velmi zatěžuje engine, který tak velký model vykresluje. Tento problém je způsoben modelovacím softwarem, který není určen právě k optimalizaci, ale naopak k velkému detailu objektů. Konkrétně se jednalo o německý Allplan, který sám o sobě nepatří mezi špičku architektonických softwarů. Tato závada by byla řešitelná na úrovni optimalizačních softwarů např. AC3D, který dokáže odstranit redundantní vertexy. 2.1.2

Textury

Aby bylo kompenzováno pomalé načítání a dynamika modelu, byl pro textury zvolen formát BMP a velmi nízké rozlišení, což nebylo zrovna šťastné rozhodnutí. Textury jsou neúměrně roztaženy do nerealistických poměrů, například na obrázku 2.2 připadá na šířku lavičky 1,3 dlaždičky, což je v reálu 21 cm.

Obrázek 2.2 Ukázka textur Samotná kvalita zpracování textur je mírně řečeno nedostatečná. Skoro žádná textura na sebe nenavazuje a místy se textury slévají viz obr 2.3.

Obrázek 2.3 Ukázka textur 2

3

KAPITOLA 2 ANALÝZA 2.1.3

Engine

Dalším problémem je neohrabanost enginu, který má velmi malé FPS (vypiš sem tu zkratku), konkrétně mezi 20 – 23. Engine načítá všechny textury do video paměti a tím snižuje počet uživatelů pouze na ty, kteří mají hodně výkonné grafické karty. Samotné načítání je velmi pomalé a výpočet matice sousednosti se zbytečně provádí při každém spuštění. V programu také zcela chybí jakákoli práce se světlem. Ale vzhledem k tomu, že byl napsán od nuly, tak je mu třeba složit velikou poklonu za to, že vše funguje. Ale bohužel je třeba přiznat, že se tím stává zcela nepraktickým. Například rychlost pohybu avatara je neúměrně nízká oproti tomu rozhlížení po okolí je nepřirozeně rychlé. 2.1.4

Navigace

Navigace byla v projektu řešena tradičním způsobem „follow the white rabbit“, který podle mého názoru příliš nepomáhá, pouze nutí uživatele k bezmyšlenkovitému sledování čáry na zemi. Tento způsob byl v zadání zakázán, proto jsem musel najít jiné řešení. 2.1.5

Věrnost

Nedokonalosti textur jsou navíc zvýrazněny jednoduchostí modelů a jejich malá věrnost s přispěním absence stínů netvoří dobrou kombinaci pro dobrý grafický dojem. Špatná dynamika pak dělá model málo použitelným pro vlastní vyhledávání.

Obrázek 2.4 Porovnání s realitou (Dejvice 3D vpravo

4

KAPITOLA 3 PROJEKT BLOF Všechny tyto záležitosti vedly k mému rozhodnutí nepokračovat v původním modelu, i když jsem dostal povolení od jeho autorů. Rozhodl jsem se poučit se z chyb a nedostatků a posunout virtuální model školy na vyšší úroveň.

2.2 Průvodce po ČVUT FEL Dalším analyzovaným modelem byla aplikace pro mobilní telefony vytvořená studenty ČVUT FEL, která je jako jediná velmi hojně využívána pro svoji okamžitou použitelnost. Je to velice dobrá inspirace pro model navigace. Textové zpracování nutí k zamyšlení a může mít požadovaný efekt. Bohužel zde chybí vizuální simulace, což jsem se snažil napravit ve svém modelu.

Obrázek 2.5 Ukázka programu Průvodce po ČVUT FEL

3 Projekt BloF Projekt jsem pojmenoval z prozaických důvodů BloF. Před samotným vývojem jsem zkoumal mnohé možnosti jak se vydat cestou nejmenšího odporu za účelem dosažení nejlepšího výsledku. Strávil jsem mnoho času studováním různých materiálů popisujících tvorbu virtuálního prostředí a modifikaci stávajících enginů.

3.1 Výběr enginu Pro virtuální svět je kritický požadavek na kvalitní engine, který je přizpůsoben potřebám vývojáře. Moje požadavky byly jednoduchost, otevřené prostředí, modifikovatelnost, dynamičnost a kvalita. Současný trh je kvalitními enginy přesycen, ale málo z nich je dostupných z důvodu autorských práv. Naopak ty volně dostupné bohužel nesplňují požadavky na otevřenost a snadnou modifikovatelnost. Možnost napsat vlastní engine jsem skoro okamžitě vyloučil z časových důvodů a z nedostatku odvahy. Modifikaci enginu Dejvice 3D jsem zamítl z výše zmíněných důvodů, de facto by musel být přepsán natolik, že by vznikl nový engine. Poslední a jedinou možností je použití GNU – General public licence engine, kterých není mnoho, ale jsou kvalitativně na vysoké úrovni, ale je zde omezení na komerční využití. 5

KAPITOLA 3 PROJEKT BLOF 3.1.1 OGRE OGRE je velmi dobře známý a propagovaný engine, který je navíc dobře udržován a aktualizován a vzniklo na něm mnoho krásných her. Dokumentace a tutoriály jsou velmi detailní a použitelné. Bohužel jediný druh her, pro které se tento engine nepoužívá, je právě FPS (First Person Shooter) a to z důvodu jeho nízkého FPS (frames per second) a značné náročnosti na grafickou kartu. Vzhledem k nulovým zkušenostem s možnostmi tohoto enginu jsem ho vyloučil. Také jsem ještě nepotkal nikoho z vývojářské komunity, kdo by tento engine používal, což mě velmi odradilo. Většina projektů na něm jsou opět uzavřeny pro komerční účely??a některé jsou těžce komerční.

Obrázek 3.1 Ukázka OGRE enginu 3.1.2 Quake 3 engine Quake 3 Arena je velmi starý engine (dále jen „Q3A“), v roce 2008 slaví své desáté výročí. Jedná se o jeden z nejúspěšnějších enginů všech dob. Za jeho vznikem stojí legendární firma ID soft v čele s Johnem Carmackem, který je považován za jednoho z nevýznamnějších herních osobností vůbec. Jeho dílem je například Wolfenstein 3D, Doom, Quake a to v mnoha pokračováních. Dodnes si tento engine drží prvenství za nejrychlejší engine vůbec a způsobil ve své době malou revoluci na poli počítačových her. V dnešní době zdaleka není sice již špičkou v oboru, ale jeho výhodou zůstává, že poskytuje volnost obohacovat hráčskou a programátorskou scénu vlastními výtvory. V roce 2005 uvolnili jeho tvůrci zdrojové kódy k samotné aplikaci a umožnili tak její libovolnou modifikaci a další šíření pod „general public licence“. Pro tento projekt byl zvolen tento engine. To znamená engine, který je vyzkoušený, po letech zdokonalený a je volně přístupný a dále šiřitelný. Navíc je zde možnost velice jednoduše program modifikovat, jelikož je napsán v čistém C a je připraven pro migraci do MSVS (MicroSoft Visual Studio), kde je velice jednoduše přeložitelný a modifikovatelný. Rozhodujícím faktorem pro mě byla znalost chování a možností tohoto enginu a předchozí zkušenosti s modifikacemi této hry. Samozřejmostí vzhledem ke stáří jsou HW nároky, které jsou Pentium 90 MHz a 32 MB RAM. 6

KAPITOLA 3 PROJEKT BLOF Tato volba však znamenala nutnost použití již vytvořených nástrojů speciálně pro tento engine. Během let se tyto nástroje zdokonalily natolik, že jejich použití je velmi efektivní a snadné. Existuje také spousta návodů jak si počínat při modifikování a tvorbě obsahu. Největší krásou tohoto enginu není jen jeho jednoduchost, ale i dokonalá preciznost ve zpracování polí a matematických operací s vektory.

Obrázek 3.2 Ukázka Quake 3 Arena enginu

3.2 Obsah Z důvodu permanentního komerčního použití Q3A je zakázáno používat samotný obsah hry a je nutné v enginu vytvořit vlastní obsah, jako jsou například textury, modely avatarů či menu. Bohužel z časových důvodů nebylo možné vše vytvářet od začátku a bylo nutné použít jako základ jiný projekt pod licencí GPL, který nahradil obsah původní hry a tím zlegalizoval šíření celého balíčku. 3.2.1

Open Arena

Open Arena (dále jen „OA“) byl první projekt, který dokázal bezezbytku nahradit kompletní obsah hry a umožnil tak její volné šíření. Pro plnou legálnost svého projektu jsem se rozhodl použít jako podklad právě tuto modifikaci. Jedná se především o modely avatarů a menu. Vše ostatní jsem nahradil vlastní obsahem. Pro větší flexibilitu projektu jsem se rozhodl ponechat kompletní obsah OA na pozadí nezměněn. Což má za následek větší flexibilitu celé aplikace – je možné si zahrát klasickou střílečku.

7

KAPITOLA 3 PROJEKT BLOF 3.2.2

Xreal

Po uvolnění zdrojového kódu k aplikaci Quake 3 začal jeden německý programátor silně modifikovat engine Quake s cílem konkurovat současným hrám. Tomu se snažil přiblížit implementováním částí kódu z Doom 3, který je podobně stavěný jako Quake, ale obsahuje nové funkce. V Xrealu bylo přidáno například dynamické osvětlení a stíny, podpora nových modelů a fyzikálních enginů. Bohužel z Xrealu se stává nepoužitelná záležitost díky nekompletnosti projektu. Došlo k velmi zásadnímu přepsání kódu bez kompletní dokumentace v angličtině. Pouze některé části jsou popsány v němčině a kód je tak značně nečitelný. V současné době působí Xreal spíše jako rozestavěná budova a není zcela jasné, jak bude vypadat. Proto je velmi těžké použít ho jako základ pro projekt. Ale nelze do budoucna vyloučit použití některých zajímavých funkcí, které byly do BloF přidány. 3.2.3

IOQuake

Jedná se o projekt skupiny nadšených programátorů amatérů, která se rozhodla vyčistit kód Quake, přidat základní bezpečnostní prvky a zjednodušit kód, jak jen bylo možné, a vytvořili projekt IOQuake. Bohudík se také rozhodli přidat další komentáře k jednotlivým funkcím. Svoje snažení dávají volně k dispozici a je možno využít jejich nové verze IOQuake, což velmi zjednodušuje práci s kódem. A díky bezpečnostním prvkům se stává výsledek, ať již bude jakýkoli, stabilní a bezpečný proti útokům. Značnou nevýhodou je v tomto případě neukončený vývoj, což komplikuje přidávání vlastních funkcí, které se budou muset přenášet mezi novými verzemi. Ale výhody, které použití IOQuake přináší, jsou značné. Velmi použitelné novinky jsou napojení na open AL (zvuková knihovna), IPv6, VoIP, raytracing, avi support, MP3 support a další. Rozhodl jsem se pro model použít právě IOQuake z důvodu perfektní dokumentace a čistého kódu.

Obrázek 3.3 Quake 3 raytraced 8

KAPITOLA 3 PROJEKT BLOF

3.3 Zdrojový kód Vůbec nejdůležitějším nástrojem ve vývoji je Visual studio, ve kterém je celá aplikace napsána. Zde je více než jednoduché jí libovolně modifikovat. Vlastní aplikace vytvořená ve Visual studiu se skládá z: Quake – vlastní spustitelná aplikace, tedy .exe soubor, Renderer – pro vykreslování, Qagame – pravidla pro server ve formě dll, Cgame – pravidla pro klienta, UI – user interface a Botlib – knihovna obsahující vše pro boty (počítačem ovládané postavy). Celou aplikaci, obsahující přes 4000 samostatných souborů, je velice těžké pochopit a začít modifikovat. To bohužel zabírá mnoho času, ale paradoxně ho také šetří, protože mnoho věcí, které budou ve výsledném produktu, jsou v Quake již napsané a je třeba pouze správně zasahovat do určitých míst kódu. Velikou výhodou je přítomnost mnoha komentářů, které šetří práci. Překonat takové množství řádek je velký úkol, ale možnosti jeho využití a rozšíření jsou skoro neomezené a umožňují volnost, které je možné využít.

3.4 Editor mapy Po rozhodnutí použít Quake byla jediná volba pro vlastní tvorbu budovy školy editor vyvinutý přímo pro Quake, který byl v dalších letech použit i na vývoj např. Dooma 3. Jelikož je výstup a i modelování velmi specifické, nebylo i z tohoto důvodu vhodné použít původní model Dejvice 3D jako základ, se kterým by se dalo pracovat. Samotné použití quake editoru je velmi neintuitivní a velmi náročné na pochopení. 3.4.1

GTK radiant

GTK radiant je svým provedením editor „staré školy“, kde se všechny funkce schovávají pod klávesami a nikde jinde. Je tedy velmi těžké se při práci orientovat v pravých nástrojích. Mapy ukládá jako modely do vlastní souborové struktury MAP, která může být mnoha způsoby upravena na výslednou mapu, která je pak používána samotnou aplikací. Tento způsob práce s modelem mapy činí mapu zcela nezávislou na aplikaci, ve které je používána, pokud ji daná aplikace podporuje. Je zde tedy možnost použít mapu vytvořenou pro BloF i pro jiné hry jako je Doom 3, Quake 4 apod. Minimální provázání s hlavní aplikací je nezbytné, ale je vyřešeno velice šikovně použitím parametrů a funkcí, které s těmito parametry pracují. Je tedy možné si vlastnosti editoru modifikovat a libovolně s označenými objekty v hlavní aplikaci pracovat. Hlavní okno aplikace se skládá ze tří oken, v jednom je k dispozici 2D pohled na model mapy, který vykresluje pouze obrysy. Tento pohled se dá přepínat na různé osy, což je oproti například 3ds Maxu nezvyklé. Ale díky tomu je místo na další užitečná okna. Jedno z opravdových vymožeností je okno, které simuluje výsledek ve hře. Tedy plnohodnotný 3D pohled na model mapy, kterou je možno procházet v reálném čase. Navíc jsou jednotlivé části potaženy texturami, je tedy možno si udělat rychlou představu, jak bude vypadat výsledný model. Proto není nutné tak často mapu zkoušet v samotné aplikaci (renderovat), což šetří čas. 9

KAPITOLA 3 PROJEKT BLOF Poslední okno aplikace obsahuje náhled textur, které je možné použít. Což opět velice šetří čas. V editoru je obsažena spousta užitečných funkcí, ale vše je dokonale jednoduché a po přečtení návodu není problém vymodelovat takřka cokoli. Velikou výhodou je možnost vkládat do modelu mapy externí modely z jiných editorů a to dělá z mocného nástroje nástroj ještě mocnější. Editor tak zvládá základní formáty jako 3DS, ASE, OBJ apod. Je tedy možné v jakémkoli běžně používaném editoru vytvořit model a jednoduše ho importovat do vytvořené mapy. To ovšem představuje i určité riziko lehké nekompatibility. Model je sice vložen a vykreslen, ale pro hru nemá odpovídající vlastnosti, konkrétně lze modelem procházet a dokonce skrz něj střílet. Tohle Quake samozřejmě jednoduše řeší a to díky technice klipování, což v jednoduchosti znamená vytvořit kolem vloženého modelu objekt, který bude průhledný, ale bude ve hře mít odpovídající vlastnosti. Celkově byla práce s GTK Radiantem velkým usnadněním při vývoji aplikace BloF. Byl naplno využit jeho potenciál, hlavně v oblasti dopisování nových vlastností daných objektů a vlastních funkcí.

Obrázek 3.4 Quake 3 editor – GTK Radiant

10

KAPITOLA 4 TVORBA MAPY

4 Tvorba mapy Na počátku je třeba zvolit vhodný postup při vývoji tak rozsáhlé aplikace. Rozhodl jsem se začít tvorbou jednoduchých objektů, ty postupně propojovat a přecházet k objektům složitějším, aby bylo možno dovést projekt do finální podoby co nejdříve a flexibilně, podle potřeby. I přes promyšlený postup se naskytly časem obrovské problémy. Muselo být vytvořeno obecné patro, které se pak modifikovalo a celá škola vznikala z jednotlivých modifikovaných pater - viz níže.

4.1 Jednoduchá mapa Nejprve byla vytvořena v GTK Radiantu jednoduchá mapa. Bylo potřeba si vyzkoušet samotné překládání mapy pro Quake a zvládnutí práce s editorem. K dispozici byly oficiální manuály, přesto tato fáze zabrala mnoho dní studia manuálu. K vytvoření jednoduché mapy byly použity původní textury z Quake. Pro tu nejjednodušší mapu stačily 4 stěny, světlo a startovní pozice hráče. Tato místnost při testování způsobovala lehkou klaustrofobii. Pro další rozvoj mapy bylo nutné tuto jednoduchou mapu o něco rozšířit, tzn. přidat více místností a průchody osadit dveřmi, na které už byla použita první zabudovaná funkce door, která se stará o otevírání dveří v přítomnosti hráče.

Obrázek 4.1 První mapa se čtyřmi stěnami

11


4.2 Rozvoj jednoduché mapy Při přecházení ke složitějším částem mapy bylo třeba sáhnout k vlastní tvorbě textur a s tím souviselo i natahování textur na objekty, což je zcela nezbytná věc. Defaultně jsou textury ve velmi nízkém rozlišení z historických důvodů a je třeba je upravit tak, aby se dosáhlo co nejlepšího vzhledu. Naštěstí není velikost a kvalita textur omezená, což je pro tento projekt veliká výhoda a mohou tak být použity fotorealistické textury o velkých rozlišeních. Do mapy byly přidány další zabudované funkce. Mezi podstatné patří např. „train“ a „rotate“, které pohybují danými objekty podle nastavení. K dispozici jsou i jiné, ale otázkou je jejich využití v tomto projektu. Součástí editoru je i jednoduché modelování a používání oblých objektů, které je velice intuitivní. Dalším krokem byla práce se zdroji světla. V Quake jsou speciální entity s vlastností emise světla. Bohužel jakákoliv změna těchto entit znamená, že se musí pokaždé přepočítávat světelná mapa. Jejich stíny jsou statické a napevno vypočítané na povrchy jednotlivých textur.

Obrázek 4.2 Náznak první chodby

12


4.3 Textury Zásadní věcí pro opravdu realistický vzhled mapy jsou právě textury, které jsou nanášeny na jednotlivé objekty v mapě. Jelikož je Quake postaven výhradně na OpenGL, musí být textury o velikosti mocnin dvou. Pro dosažení pocitu reality byly použity textury, které byly vytvořeny z fotek pořízených přímo v budově školy. Všechny textury, které jsou v projektu použity, jsou autentické a originální. Jejich zpracování zabralo mnoho času. Ke zpracování byl použit program Adobe Photoshop.

Obrázek 4.3 Příklady textur

4.4 Oživování mapy Mapa může být velice jednoduše doplněna externími objekty. Jedná se konkrétně o doplňky, jako je například hasicí přístroj, kelímek od automatu a podobné detaily, které dodávají realističtější vzhled. Další silným nástrojem na oživení mapy je zabudované skriptování vlastností shaderů. To znamená dopisování vlastností jednotlivých textur. Touto metodou je realizováno multitexturování, průhlednost textur a jejich rozmazávání apod. Lze tak jednoduše vytvořit okno s efektem lesku, či lesk na podlaze. Ke skriptování se používá několika přednastavených funkcí podle návodu, ale je možnost tyto funkce měnit a přidávat.

13


Obrázek 4.4 Postupné oživování chodby

4.5 Výchozí patro Po velmi neúspěšném prvním pokusu spojit 3 patra nad sebe bylo třeba celou mapu předělat, jelikož více pater nad sebou se stalo needitovatelnými. Bylo proto nutné vytvořit obecné patro, které obsahuje pouze to, co se vyskytuje na každém patře, jako například sloupy a dřevěné vitríny. Každé takové patro bylo zeditováno do podoby jednotlivých pater. To znamená, že byly změněny textury podlah, pozice dveří apod. Tato patra se pak spojila nad sebe a vznikl celek. V každém patře byly zastavěny schodiště, protože přesahují mezi patry. Schody a výtahové šachty byly přidány až po spojení jednotlivých pater.

Obrázek 4.5 Jedno kompletní patro

14


4.6 Modelování pater Základem pro reálný model sloužící k navigaci je rozmístění místností, dveří, chodeb a autentických předmětů každodenního použití. 4.6.1 Architektonické plány budovy K dosažení maximální přesnosti modelu byly použity přesné plány budovy, které díky speciálním prohlížečům DWG formátu umožnily měření v rozměrech upravených přímo pro Quake a tím velmi zjednodušily práci. Bohužel se v plánech nevyskytují objekty každodenního použití, jako jsou například automaty a lavičky. Bylo tedy zapotřebí tyto informace sehnat přímo v terénu. I přes tyto nedostatky byly plány neocenitelné při návrzích celkových rozměrů chodeb a hlavně umístění dveří a jednotlivých učeben.

Obrázek 4.6 Plány budovy v elektronické podobě

4.7 Struktura mapy Celkově je struktura mapy rozdělena do jednotlivých bloků, aby bylo umožněno dynamické načítání jednotlivých částí. Díky tomu se předešlo problémům s vytěžováním procesoru a grafické karty. Také všechna schodiště byla rozdělena do bloků podle pater, aby se zamezilo načítání celého schodiště. Tyto kroky byly nezbytné kvůli převodu do VRML (viz níže).

4.8 Plnění mapy I přes naplnění mapy objekty, které do školy přirozeně patří, například lavičky, je poněkud prázdná a moc se realitě nepřibližuje. Proto je třeba přidat některé objekty, které školu dekorují a jsou pevnou součástí její zástavby.

15

KAPITOLA 4 TVORBA MAPY 4.8.1 Modelace objektů v Quake editoru Jednou z velmi efektivních metod jak zaplnit prázdné prostory je modelovat předměty přímo v GTK Radiantu. Je to velmi rychlý způsob, pro lidi znalé prostředí editoru je nanášení textur bezproblémové a výsledné modely jsou optimalizované pro engine. Nevýhodou je přílišná jednoduchost takto vytvořených modelů, jelikož nástroje pro tvorbu detailů jsou v editoru značně omezené. Touto metodou je proto vhodné vytvářet pouze základní objekty nevyžadující velký detail.

Obrázek 4.7 Ukázka objektů vytvořených v GTK Radiantu 4.8.2 Modelace objektů v ostatních editorech Vývojáři Quake si byli vědomi, že se hráči nespokojí pouze s jednoduchým modelováním objektů, a proto zakomponovali do editoru i import externích objektů v různých formátech. Dokonce šli tak daleko, že si vytvořili vlastní typ objektu, který má oproti ostatním plnou podporu v enginu hry. Mezi podporované formáty patří ase, obj, md3 a 3ds. To vnáší do tvorby úplně nové možnosti. Za malého přispění kolegy Radima Šoustala se podařilo obohatit mapu i externími objekty, které vypadají velmi krásně, ale bohužel jsou průchozí, což se dá v Quake ošetřit tzv. klipováním. Jedná se o vytvoření neviditelného bloku okolo předmětu, který má požadované fyzikální vlastnosti.

Obrázek 4.8 Ukázka objektů vytvořených v externích editorech 16

KAPITOLA 4 TVORBA MAPY 4.8.3 Nástěnky Za celkový duch školy mluví nejvíce všudypřítomné nástěnky. I když většina z nich není právě aktuální. Přesto je třeba se na tento školní fenomén zaměřit. Možností je více – první a asi nejpřirozenější je ponechat ve virtuální škole původní podobu nástěnek. Což je velmi pohodlné, ale pracné a ne příliš efektivní. Další možností je využít jich jako reklamních ploch. Z důvodu přítomnosti sponzorů v tomto projektu, není tato myšlenka tak nemožná. Ale je třeba se vyhnout kýčovitosti a velkému počtu reklam. Poslední a realizovanou možností je nástěnky dynamicky aktualizovat z internetu, což je umožněno díky dobré struktuře souborů v Quake. Všechny textury jsou uloženy ve složce textures a aktualizací se dají původní textury přepsat a v mapě se objeví pouze aktuální (toto je téma bakalářské práce mého kolegy Davida Eršila, nebudu ho tedy dále rozvádět). Na možnost realizovat tyto aktualizace bylo třeba pamatovat již při vývoji mapy, konkrétně při texturování. Znamená to, že je nutné na každou nástěnku jednotlivě natahovat textury různých názvů, protože při aktualizaci by se přepsaly všechny nástěnky. V součastné době jsou na nástěnkách v modelu školy nataženy prázdné textury, které jsou k dispozici ke stažení na internetových stránkách projektu. Jednotliví uživatelé si mohou stáhnout zvolené textury a volně si je modifikovat a pak je nahrát zpět na stránky. Po kontrole jsou textury uloženy do speciálního úložiště, odkud se stahují do počítačů všech uživatelů BloFu. Každý uživatel má tak možnost vidět i výtvory ostatních uživatelů.

Obrázek 4.9 Ukázka objektů prázdné a zeditované nástěnky

17


4.9 Obohacování Jako na každém vývoji je třeba přidat něco svého. Při tak dlouhém vývoji je velmi těžké se vyhnout vtípkům na vlastní účet. Proto jedním z největších obohacení je vložení humoru a vtipů do projektu. 4.9.1 Humor Do samotné mapy bylo přidáno mnoho drobných žertů, které nemají za cíl někoho urážet, ale pobavit vývojáře, který již psychicky nezvládá další vývoj. Pro příklad je lepší se podívat přímo do mapy. 4.9.2 Komiksy S laskavým souhlasem Jojina a HedgeHoga (autoři známého komiksu z tématikou FELu) bylo dovoleno použít postavy z komiksů, které jsou na ČVUT FEL všeobecně známy. Stejně tak i komiksy samotné. Použity budou například i na méně zajímavé nástěnky. Postava Damiena Zla bude postupem času vymodelována jako herní postava.

Obrázek 4.10 Komiks na téma BloF

4.10 Problémy při tvorbě Žádný takto rozsáhlý vývoj se při svém zrodu neobejde bez větších či menších problémů. Většina z nich se týkala neúměrně velké mapy, se kterou si engine nedokázal poradit, jelikož na tak veliké scény nebyl koncipován. 4.10.1 Velikost mapy Engine po spuštění má nastavenu defaultní hodnotu pro zápis do paměti, tedy kolik MB může použít pro načtení mapy – „Com_hunkmegs“. Z důvodu fyzické velikosti mapy byl tento limit překročen. Quake ale nabízí řešení přímo na úrovni enginu a tím je manuální zvýšení této hodnoty. Bez navýšení by načítání mapy skončilo chybou a aplikace by byla ukončena.

18

KAPITOLA 4 TVORBA MAPY 4.10.2 Hrany objektů V editoru GTK Radiant je limit pro počet hran na jednotlivých brushích (základní obdélníková struktura) – „Max_draw_edges“. Proto bylo třeba model optimalizovat, tedy ubrat přebytečné hrany a sjednotit jednotlivé brushe. Další metodou optimalizace je udat jednotlivým povrchům vlastnost caulk, což znamená, že povrch nebude vykreslován ve výsledné mapě. Toto je možné pouze u okrajových bloků, které nejsou nikdy vidět, ani kdyby byly vykreslovány. Toto dramaticky snižuje počet hran na editorem přijatelnou úroveň. 4.10.3 Úhly objektů Engine má také omezení na počet vertexů na jedné mapě – „Max_draw_verts“. Což bylo při tvorbě překročeno právě importovanými objekty, které nebyly dobře vymodelovány. Řešením je zjednodušení objektů na úrovni externího modelovacího software. Příkladem za všechny jsou kliky u dveří, kterých je na mapě mnoho. Při detailním plném modelu objektu měla každá klika 477 vertexů. Po nucené optimalizaci jich měla 36. Což ušetří u jedné kliky 441 vertexů a při počtu 50 klik na patro je celkový počet ušetřených vertexů 176 400. Tato optimalizace bohužel znamenala snížení kvality modelů objektů.

Obrázek 4.11 Klika s koulí před a po zjednodušení

4.11 Možnosti vylepšení Bohužel z časových důvodů se nepovedlo dovést model školy do dokonalosti, tedy alespoň do představované formy. Je zde stále hodně prostoru k vylepšení jeho vzhledu.

19

KAPITOLA 4 TVORBA MAPY 4.11.1 Nové prostory V současné verzi jsou pouze hlavní chodby a spojovací chodby a to pouze z fakulty elektrotechnické. Do budoucna je možné přidat strojní fakultu, či interiér jednotlivých tříd nebo poslucháren. 4.11.2 Více modelů Počet objektů není tak velký, jak by mohl být a nejsou obsaženy objekty předmětů každodenního užití. Příkladem může být notebook či odhozený kelímek. Takové objekty by vydatně prospěly k obohacení mapy. 4.11.3 Shadery Jedná se o skriptování vlastností textur. Některé jednoduché byly přidány do aktuální verze, například odlesky světel od podlahy, ale možnosti jsou mnohem větší. Například by se dal napsat shader na kovové předměty, který by reflektoval skutečný odraz Tatara, či okolí a to s lehkým zmatněním.

4.12 Odlaďování Při tvorbě vzniklo mnoho tzv. bugů neboli chyb v modelu. Jednalo se o prolínající se objekty, přeblikávájící textury, prázdná místa či nepropojené stěny. S laskavou pomocí kolegů se povedlo výsledek odladit proti faktickým chybám a nedostatkům. Viz obrázek z reportu bugů.

Obrázek 4.12 Příklad problikávající zdi a špatně natažené textu 20

KAPITOLA 5 IMPLEMENTACE NAVIGACE

4.13 Statistiky Výpis nejzajímavějších hodnot z aktuální verze mapy: • • • • • • • •

celkem 757 různých textur celková velikost textur je 19,5 MB velikost samotného souboru se strukturou mapy je 34,3 MB celkem 23 886 primitiv (jednotlivých stavebních bloků) 6 435 portálů (úseky pro vykreslování viditelných objektů) 364 266 vertexů pouze na základní struktuře 739 965 sloučených vertexů 3 395 228 luxelů (jednotky osvětlení)

5 Implementace navigace Hlavním cílem této bakalářské práce bylo implementovat navigaci do virtuálního modelu školy a to novátorským způsobem.

5.1 Analýza Například způsob navigace v aplikaci Dejvice 3D je nevhodný z důvodu přímočarosti a jednoduchosti. Po vyhledání třídy je před uživatelem nakreslená čára, kterou má následovat. To má za pozitivní následek použití nejkratší možné cesty, ale nezanechá v uživateli potřebné informace pro nalezení cesty ve skutečném světě. Bylo třeba zvolit zcela odlišný přístup. Z průzkumu, který byl proveden přímo v budově školy, vyplývá, že je velmi těžké se orientovat podle navigačního systému v budově, jelikož číslování bloků a tříd je zcela chaotické a i po tříletém studiu jej ovládá menšina studentů. Využití číslování bloků tedy není dobré řešení. Způsob, jak si zapamatovat cestu k hledané místnosti, je ve volnosti pohybu uživatele a v jeho vlastní invenci. Pokud se bude uživatel aktivně podílet na hledání místnosti, pak je velmi pravděpodobné, že si zapamatuje způsob, jakým místnosti hledal, případně tzv. body zájmu, kolem kterých procházel. Je ale potřeba uživateli nabídnout usnadnění při jeho hledání, avšak ne natolik, aby bezmyšlenkovitě našel místnost, ale ani ne málo, aby místnost mohl najít.

5.2 Řešení Jako ideální řešení byla zvolena audio-vizuální stimulace. Konkrétně, pokud uživatel zvolí, že chce hledat místnost, pak je vyzván (obrázek 5.1), aby zadal číslo nebo název místnosti. Místnost je poté hledána na mapě dle místa vstupu uživatele. Pokud není nalezena, pak je na to uživatel upozorněn a je mu nabídnuta možnost znovu zadat číslo místnosti. Je-li třída na mapě nalezena, pak se před danou místností objeví bójka ve tvaru kruhu (obrázek 5.2), která poskakuje a rotuje. Bójka je dostatečně velká, aby upoutala pozornost. Zároveň tato bójka 21

KAPITOLA 5 IMPLEMENTACE NAVIGACE vydává přerušované pípání, které je slyšitelné přes polovinu mapy. Čím je uživatel blíže bójce, tím se pípání zesiluje. Pokud je uživatel v jiném patře než je hledaná třída, tak aplikace uživatele vyzve, aby šel po schodech nahoru nebo dolů (obrázek 5.3). Po nalezení třídy (kontakt s bójkou) je přehrán vítězoslavný zvuk a bójka je odstraněna (obrázek 5.4). Místnost je tím považována za nalezenou. Pokud se uživatel rozhodne při hledání změnit hledanou třídu, pak bójka u původní místnosti zmizí a objeví se u nově hledané. Některé místnosti nemají číselné označení, jako například pedagogické oddělení, u takových místností je použito jako identifikátoru krátké slovní označení, jako například „peo“ pro pegadogické oddělení. V kódu bylo toto řešení implementováno do serverové části, ukázka kódu včetně postupu je v příloze D.

5.3 Vložení nové místnosti Dalším cílem při této implementaci bylo vytvoření možnosti vkládat nové místnosti, to znamená, aby umístění místností a jejich označení bylo dynamické a nebylo tzv. „natvrdo napsáno v kódu“. Toho bylo docíleno vytvořením nového typu entity (základní dynamická jednotka Quake), která má označení item_point (obrázek 5.5). Tato entita může být použita v editoru GTK Radiant na kteroukoliv mapu a spolu s kódem bude princip navigace fungovat kdekoli. Po vložení entity na správné místo do mapy je třeba entitu jednoznačně identifikovat, proto byla vytvořena vlastnost „jméno třídy“, což je identifikátor, podle kterého se následně v aplikaci entita vyhledává. Pak stačí mapu tzv. přeložit a je okamžitě použitelná v aplikaci, kód samotné aplikace není třeba nijak měnit.

5.4 Efektivita Podle mého názoru splňuje zvolený způsob požadavky na navigaci a přistupuje k ní nový způsobem. Účast uživatele na hledání je přiměřená a částečně usnadněná. Trajektorie k místnosti není tou nejkratší jako v aplikaci Dejvice 3D, ale díky rychlosti a dynamice pohybu se k ní uživatel dostane rychleji v řádu několika desítek minut. Po testech na zkušebních uživatelích bylo prokázáno, že uživatelé si zcela dokonale zapamatují blok, ve kterém se třída nacházela, což je nejdůležitější. Problémy jsou v zapamatování si patra podle procházené trajektorie, ale vzhledem k tomu, že první číslo v označení místnosti je patro, tak toto není problém. Cedulek s označením pater je na škole mnoho, a proto by uživatel neměl mít problém se zorientovat i v reálném modelu. Bójka zavede uživatele přímo k dané místnosti, což v reálném světě má za následek snazší orientaci v samotném bloku.

22


5.5 Ukázka

Obrázek 5.1 Ukázka výchozího stavu

Obrázek 5.2 Bójka u hledané třídy 23


Obrázek 5.3 Výzva „jdi o patro výš“

Obrázek 5.4 Místnost nalezena

24

KAPITOLA 6 ELEKTRONICKÝ KIOSEK

Obrázek 5.5 Přidání entity v editoru

6 Elektronický kiosek Již v průběhu realizace byly hledány možnosti jak navigaci v BloFu prakticky využít. Jedním z nápadů bylo umožnit vyhledávání místnosti hned po vstupu do budovy, bez potřeby vlastního počítače. Perfektním řešením je elektronický kiosek, který by byl umístěn u vchodu do školy. Na něm by si osoby vstupující do školy mohly okamžitě bez problémů najít cestu k hledané místnosti.

6.1 Shánění kiosku Vzhledem k tíživé finanční situaci bylo nemožné kiosek zakoupit, a proto byl hledán sponzor, který by věnoval nebo propůjčil kiosek škole. Bohužel tento nápad nezaujal většinu kontaktovaných firem. Bohudík se po čase podařilo zapůjčit kiosek od firem CRC technik a CorTec, kteří poskytly spolupráci výměnou za reklamu na kiosku.

6.2 Popis kiosku Jedná se o poměrně masivní venkovní kiosek, ve kterém je malý počítač, který je připojený na masivní klávesnici, veliký display a trackball. Kiosek umožňuje připojení na internet a vlastní bezpečnost běžící aplikace je zajištěna tak, že kiosek je vybaven speciální klávesnicí, která nemá systémové klávesy. Do kiosku je možné přidat tiskárnu, která by v budoucnu mohla tisknout cestu k vyhledané místnosti buď formou textové informace nebo jako plánek cesty.

25

KAPITOLA 6 ELEKTRONICKÝ KIOSEK

6.3 Komplikace Bohužel se při realizaci spuštění BloFu na kiosku objevily určité problémy. Největším problémem bylo, že počítač v kiosku byl málo výkonný na spuštění náročného enginu Quake. Počítač byl sice vyměněn z vlastních zdrojů za výkonnější, ale výkon zůstával stále nedostatečný. Další posílením byla výměna grafické karty za výkonnější – „Nvidia Vanta“, jelikož v počítači nejsou k dispozici jiné sběrnice než PCI. Avšak ani tato karta rychlost vykreslování ještě dostatečně neposunula. Ve finále bylo nastaveno maximální přetaktování a přimontován další větrák a výkon se konečně přiblížil použitelným 40 FPS.

6.4 Budoucnost Kiosek je v současné době připraven na provoz. Dne 25.6.2008 bude vystaven v budově školy na společné výstavě projektů skupiny IIM (Intermedia). Pak by měl být kiosek umístěn u vchodu do školy hned za vrátnicí, aby k němu mohl mít každý návštěvník přístup k vyhledání informací. Firma, která kiosek zapůjčila, by pravděpodobně mohla kiosek škole ponechat při úspěchu a účinnosti reklamy.

6.5 Ukázka

Obrázek 6.1 Ukázka kiosku s funkčním BloFem

26

KAPITOLA 7 PREZENTACE NA WWW

7 Prezentace na WWW Pro potřeby šíření aplikace k uživatelům byla vytvořena web stránka na portálu ic.cz. Zde je k dispozici aplikace ke stažení. Vedle samotné aplikace je zde možnost stáhnout si prezentaci videa (viz níže), obrázky z vývoje a součastného stavu a náčrty prázdných nástěnek. Upravené nástěnky je možné zpětně nahrát autorům přes upload souborů. K dispozici je také fórum, kde se návštěvníci mohou vyjádřit k aplikaci, mohou poskytnout nápady na vylepšení nebo připomínky k vlastnímu projektu. Samozřejmostí jsou novinky a krátké povídání o projektu. Ve chvíli vzniku této prezentace měla stránka registrovaných 2 519 návštěvníků a několik reakcí na fóru. Tato čísla se pravděpodobně navýší zveřejněním projektu, ke kterému by měl dopomoci právě kiosek a implementace do Cavu – viz kapitola 9. Adresa stránek je www.blof.ic.cz

Obrázek 7.1 www stránky projekt

27

KAPITOLA 8 BUDOUCNOST PROJEKTU

8 Budoucnost projektu V žádném případě projekt jako celek není ukončen touto bakalářskou prací. Osobně bych chtěl na projektu dále pracovat, zdokonalovat jej a hledat pro něj nová použití.

8.1 BloF jako nástroj Model školy sám o sobě by v budoucnu mohl být studenty použit jako základ pro nějaký nový projekt, například v předmětu ITT se hodně experimentuje s propojením mnoha oborů s virtuální realitou. Po osobních zkušenostech s předmětem vím, že je zde mnoho nápadů, které není čas uskutečnit. Proto by mohla tato práce v mnohém usnadnit jejich realizaci. Vzhledem k otevřenosti Quake a možnosti konvertovat mapy do různých formátů není problém například propojit Cave s okolním světem.

8.2 Přenosná zařízení Vzhledem k neustálému vývoji mobilních zařízení je velmi reálné, že v blízké budoucnosti bude možné importovat do nich Quake, jako se to již některým nadšencům povedlo (viz obrázky) a s tím souvisí možnost spuštění Blofu i na těchto zařízeních. 8.2.1 PDA a PPC Jedná se o počítače do kapsy, které mají v dnešní době poměrně silné procesory, ale podle dlouhodobých studií jsou na ústupu. V mnohých z nich již Quake bez problémů funguje. Problém importu je v současné době nedostupnost těchto zařízení na trhu.

Obrázek 8.1 Quake na PPC Dell

28

KAPITOLA 8 BUDOUCNOST PROJEKTU 8.2.2

Mobilní telefony

Mnohem větší naději mají v budoucnu mobilní telefony, které mají veliký výkon. Stává se tak z nich vhodný nástroj pro praktické využití při navigaci po budově školy. BloF by pak dostal zcela nový rozměr praktického použití, jelikož by si ho uživatelé mohli pustit a přímo se s ním pohybovat po budově školy. Mohli by tedy propojit virtuální navigaci s procházením budovy. Pak by pravděpodobně bylo rozumné naimplementovat jiný typ navigace, který by uživateli přímo ukazoval cestu ve virtuálním světě.

Obrázek 8.2 Quake na iPhone 8.2.3 Simulace evakuace Zajímavá myšlenka je implementovat do BloFu evakuační plány školy a hlavní postavu dát do situace, která vyžaduje nouzový únik a rychlé jednání. Okolní postavy by reagovaly nahodile a hlavní postava by se musela rozhodovat podle jejich chování a podle znalostí bezpečnostních řádů. Po ukončení akce by se chování postavy vyhodnotilo a bylo by odesláno do školní databáze a student by při špatných výsledcích musel projít bezpečnostním školením. Jedna z variant by obsahovala školení přímo formou interaktivních tutoriálů. A výstupním testem by byla právě simulace skutečné krizové situace. Otvírá se zde tak prostor pro libovolné programátorské experimentování, například simulace šíření ohně a jeho postup mezi různými povrchy. V daném případě by se samozřejmě muselo doprogramovat chování dalších postav v dané situaci. V Quake je nyní pouze popsáno chování protivníků při bojích a únik před ohněm jim je zcela „lhostejný“. Avšak dala by se zde použít celá řada napsaných funkcí a různých algoritmů pro boty.

29

KAPITOLA 9 ZÁVĚR

9 Závěr Tato práce mě osobně velmi obohatila. Vyzkoušel jsem si několik profesí z vývoje počítačových her. Některé z nich mě opravdu zaujaly, například programování v hotovém enginu, při kterém jsem využil všech svých nabytých znalostí ze studia na ČVUT. Do budoucna bych rozhodně chtěl v projektu pokračovat, případně začít pracovat na novém s podobným zaměřením, případně více orientovaném na online komunitu. Díky tomuto projektu jsem měl také jedinečnou příležitost účastnit se vzniku Cavu a jeho zprovoznění, za což bych chtěl ještě jednou velmi poděkovat panu Ing. Romanu Berkovi. Osobně jsem si dokázal, že jsem i přes problémy schopen dokončit větší projekt, který jsem si předsevzal a to je pro mě největší vítězství.

10 Literatura -

www.idsoftware.com

-

Manuál ke GTK Radiant

-

www.quakedev.com

-

fps.brainerd.net

-

www.qeradiant.com

-

tutorials.moddb.com

-

code3arena.planetquake.gamespy.com

-

engaget.com

-

www.google.com

30

PŘÍLOHA A BLOF V CAVE

Příloha A BloF v Cave Vedlejší náplní této práce bylo vyřešení problému implementace Quake (potažmo BloFu) do systému Cave. Což se před samotným dokončením stoprocentně povedlo.

1. Co je Cave Cave je multimediální místnost, která má na třech stěnách promítaný obraz ze tří propojených PC, kam se uživatel postaví a má dojem virtuální reality. Toho je docíleno tzv. stereo promítáním a je tak navozen dojem 3D vidění. Pro Cave byla vytvořena speciální knihovna, která je částečně kompatibilní s mapami pro Quake, ale potlačuje jakékoli funkce aplikace a omezuje se na pouhé procházení a to bez možnosti pohledu nahoru a dolů. Což je velmi omezující a pro plnou funkčnost BloFu je nezbytné, aby tento problém byl na Cave vyřešen.

Obrázek A.1 Ukázka Cavu

2. Implementace Quake sám o sobě má funkci vykreslování do sterea, a to díky přímému používání OpenGL, tedy pokud karta Stereo podporuje. Dokonce je v Quake i funkce ovládající hloubku vykreslovaní sterea, které se tak dá velice jednoduše ovládat. Problémem je absence různých pohledů z hlediska jednoho hráče (neboli jedné kamery). Je třeba s postavou hráče v této situaci kalkulovat jako s kamerou, která se pohybuje po mapě. Přední obraz v Cavu je bez problémů, je 3D a vykresluje pohled hráče směrem dopředu, ale ostatní stěny jsou prázdné.

31

PŘÍLOHA A BLOF V CAVE Hráč nemá možnost se podívat doleva nebo doprava ani ve hře, což je velmi omezující faktor, oproti například leteckým simulátorům. Další problém je, že ostatní projektory jsou ovládány jinými počítači a je třeba nějak řešit synchronizaci a projekci té samé mapy.

3. Řešení synchronizace Řešení je třeba hledat co nejjednodušší s využitím dalších vlastností, které Quake má. Problém synchronizace umožňuje Quake řešit velice jednoduše - pomocí tzv. síťové hry, resp. propojení totožných aplikací přes lokální síť. Ve hře toto funguje jako propojení 3 nezávislých hráčů do jedné mapy, kde by normálně hráli proti sobě. Ale pro potřeby Cavu je zde naštěstí ještě jedna funkce, která se nazývá spectate. Ta umožňuje hráči, který je připojen do nějaké hry, sledovat přesné pohyby hráče, kterého sleduje. Tím je vyřešeno promítání stejné mapy a její synchronizace, která se provádí jednoduchou komunikací typu klient – server. Po použití tohoto triku by ale výsledek byl následovný – na každé stěně by se promítalo to, co vidí jeden hráč, ale pohledem před sebe, což je špatně. Je tedy nutné u postranních počítačů nastavit v aplikaci otočení pohledu o 90 stupňů. Kvůli spolupráci po síti je třeba zachovat stejný build na všech PC. Bylo tedy nutné ovládat jednotlivé pohledy prostřednictvím parametru, který byl vložen do programu jako proměnná „cg_FelCave“. Proměnná nabývá tří hodnot a funguje jako měnič pohledů. S hodnotou 0 je aktivován pohled dopředu, s hodnotou 1 doprava, a 2 doleva. Úprava kódu není zcela jednoduchá a vyžaduje dokonalou znalost systému řízení přerušení od myši a příslušné reakce. Nutnou znalostí je také soustava proměnných a funkcí, které řídí zobrazování. Výsledek se může zdát velmi jednoduchý, ale taková změna kódu vyžadovala spoustu testování.

4. Řešení pohledů Pohled kamerou je dokonalé přirovnání k tomu, jak Quake opravdu funguje. Pro pohledy rovné bez naklonění, je vše bez problémů. Ty se však objevují při pohledu nahoru a dolů, jelikož kamera se při těchto pohledech naklání a tím se rozjíždí i jednotlivé úhly naklonění v otočených pohledech. To způsobuje nepříjemný efekt překrývání a vzniku slepých míst při kombinaci všech tří pohledů. Jako řešení se nabízelo převedení procesu, který v otočených pohledech, naklání pohledem, aby s ním namísto toho rotoval adekvátně k naklánění předního pohledu. V reálu je takovéto řešení jednoduché, ale v kódu by se mohlo jednat o desítky řádků, které by navíc mohly být zbytečné. Cílem bylo vymyslet řešení, které by bylo krátké a jednoduché. Naštěstí díky způsobu na jakém vlastně Quake funguje, stačilo pár drobných úprav na správných místech. Konkrétně šlo o zvýšení úhlu, ze kterého se kamera dívá na scénu a natočení tohoto pohledu. Navíc bylo nutné ještě změnit kopírování vektorů, které jsou výsledkem vstupu myši, na jiné operace s kamerou než jaké byly původně. To celé bylo aplikováno využitím hodnot proměnné cg.felCave. 32


Obrázek A.2 Grafický náznak problému otočených pohledů

5. Ukázka finálního kódu if( cg.felCave>0) { switch(cg.felCave) { case 1: cg.refdefViewAngles[YAW] = ps->viewangles[YAW]; cg.refdefViewAngles[PITCH] = 0; cg.refdefViewAngles[ROLL] = -ps->viewangles[PITCH]; cg.refdefViewAngles[ROLL] += 30; //otoceni pohledu cg.refdefViewAngles[YAW] -= 90; cg.refdefViewAngles[ROLL] -= 30; break; case 2: cg.refdefViewAngles[YAW] = ps->viewangles[YAW]; cg.refdefViewAngles[PITCH] = 0; cg.refdefViewAngles[ROLL] = ps->viewangles[PITCH]; //otoceni pohledu cg.refdefViewAngles[YAW] += 90; break; } } else VectorCopy( ps->viewangles, cg.refdefViewAngles );

33


6. Obrazárna BloFu v Cavu

Obrázek A.3 Příprava před vybudováním Cavu

Obrázek A.4 BloF v Cavu

34


Obrázek A.5 Prezentace Quake v Cavu na výstavě Eurographics 07

Obrázek A.6 Prezentace Quake v Cavu na výstavě Eurographics 07

35

PŘÍLOHA B NÁSTROJE PRO TVORBU

Příloha B Nástroje pro tvorbu 1. Autodesk 3DS MAX Autodesk 3DS MAX je profesionální modelovací software, který umožňuje tvorbu libovolných modelů mnoha technikami, je tou nejlepší volbou na doplnění objektů vložených do GTK Radiantu (editoru Quake). Umožňuje modelovat cokoli a výsledné modely objektů jsou za použití i těch nejsložitějších modelovacích technik exportovány do velice čitelného a přehledného ASE formátu, se kterým si Quake velice jednoduše poradí. Výhodou je že Quake zvládne importovat i animace, které dokáže ve hře používat. Je tedy nezbytností, aby tyto vlastnosti byly co nejvíce použity v aplikaci. Velmi důležité je měřítko, které se vůči mapě těžko odhaduje, a pozdější změny měřítek může model zcela znehodnotit. V modelovacím softwaru se nejedná pouze o editaci a tvorbu doplňků do mapy, ale také o tvorbu samotných postav hráčů, které je třeba upravit pro vlastní potřebu. Stejně tak jakékoli objekty, které jsou ve hře použity je třeba modifikovat v externím editoru, protože Radiant slouží výhradně k modelování map a tvorbu jednoduchých objektů.

Obrázek B.1 Příklad modelování v Max 3D

2. Adobe Photoshop Adobe Photoshop byl zvolen pro práci s texturami v aplikaci. Je zcela nezbytné, aby výsledné textury měly co nejvyšší kvalitu a co nejmenší velikost z důvodu rychlejšího načítání do paměti. Drtivá většina textur pro BloF je tvořená z fotek, které byly pořízeny přímo ve škole. Ve Photoshopu jsou pak z těchto fotek vytvořeny editací reálné textury. Pro účely BloFu i dalších her je třeba, aby textury navazovaly ve všech směrech samy na sebe, aby se daly kopírovat vedle sebe a 36

PŘÍLOHA B NÁSTROJE PRO TVORBU nebyly patrné přechody. To je samo o sobě velmi těžký úkol z důvodu nerovnoměrného nasvícení objektů ve škole. Na několika centimetrech se nasvícení objektů velmi znatelně mění a to pak znemožňuje plynulé navazování. Z tohoto důvodu je použit Photoshop, který má v sobě zabudovány funkce, které zjednodušují práci s texturami a výsledek velmi kvalitně komprimují. Konečná textura je pak načtena GTK Radiantem a přiřazena příslušnému objektu. Quake také jako jedna z prvních her své doby přišel s technologií mutlitexturování. Což bylo použito při některých efektech.

Obrázek B.3 Zpracování fotky v Photoshopu

3. Adobe Premiere Adobe Premiere je méně podstatná aplikace, která slouží ke střihu videa na prezentaci aplikace. Spolu s malinkým programem Fraps, který umožňuje nahrávání videa přímo z Quake je to jediná možnost na kvalitní editaci. Výsledkem práce s videi je prezentace celého projektu, která je ke stažení na http://www.blof.ic.cz/video/prezentace.avi.

Obrázek B.4 Ukázka Premiere

37

PŘÍLOHA C OBRAZÁRNA BLOFU

Příloha C Obrazárna BloFu

Obrázek C.1 Porovnání s realitou – 2. patro

Obrázek C.2 Porovnání s realitou – zadní schodiště

38


Obrázek C.3 Porovnání s realitou – odpadkové koše

Obrázek C.4 Porovnání s realitou – schodiště

Obrázek C.5 Porovnání s realitou – detail schodiště

39


Obrázek C.6 Přízemí před PEO

Obrázek C.7 Chodba ve 2. patře

40


Obrázek C.8 Přízemí

Obrázek C.9 Pohled na katedru elektrotechniky

41


Obrázek C.10 Uvnitř katedry elektrotechniky

Obrázek C 11 Pohled od stropu, 2.patro

42


Obrázek C.12 - 5.patro, konec bočního schodiště

Obrázek C.13 - 7.patro, konec hlavního schodiště

43


Obrázek C.14 – Horní pohled na model v editoru

Obrázek C.15 - Boční pohled na model v editoru 44

PŘÍLOHA D UKÁZKA KÓDU

Příloha D Ukázka kódu Jelikož byl modifikován celý, velmi obsáhlý, kód Quake je velmi těžké ho zde celý zveřejnit, proto je zde uvedena pouze velmi malá část kódu, která byli připsány. Komentáře nejsou v tomto případě na místě, jelikož jsou používány implicitní funkce Quake a jeho terminologie.

1. Přidání entity V souboru bg_misc.c se zpracovávají entity z načtené mapy. Jelikož byla vytvořená v editoru nová entita, musí být nadefinována v kódu. Je ale zachována dynamičnost přidávání místností, jelikož zpracování entit je obecné a nezáleží na tom kolik jich v editoru bylo přidáno, všechny se zpracují. Ukázka: /* definice entity item_point */ { "item_point", "sound/items/excellent.wav", { "models/nic.md3", "models/powerups/instant/quad_ring.md3", NULL, NULL }, /* icon */ "icons/iconh_yellow", /* pickup */ "Good job", 25, IT_HEALTH, //IT_POWERUP, 0, /* precache */ "", /* sounds */ "" },

2. Zpracování pozice a objevení bójky Ukázka: if (pomoc==1) {pomoc=0; ent->climm=NULL;znova=0;pom=NULL;} if (pomoc==2) {znova=0; pomoc=0;} if (!ent->climm) trap_SendServerCommand( ent->s.clientNum, va("cp \"Press 't' to enter room number\"")); if (pom){ pat1=patro(ent->s.pos.trBase[2])-patro(pom->s.pos.trBase[2]); if (pat1<0) trap_SendServerCommand( ent->s.clientNum, va("cp \"Go up the stairs\"")); if (pat1>0) trap_SendServerCommand( ent->s.clientNum, va("cp \"Go down the stairs\"")); if (pat1==0) trap_SendServerCommand( ent->s.clientNum, va("cp \"This is the right floor\"")); } if ((pom = G_Find(ent, FOFS(team), ent->climm))){

45

PŘÍLOHA D UKÁZKA KÓDU trap_LinkEntity( pom ); G_AddEvent( pom, EV_POWERUP_QUAD, 0 ); if (znova==0){ pom->think = RespawnItem; pom->nextthink = level.time+100; znova=1; } else{ pom->think = NULL; pom->nextthink = 0; } } else { if (ent->climm) { trap_SendServerCommand( ent->s.clientNum, va("cp \"Room not found\"")); ent->climm=NULL; } }

46

PŘÍLOHA E OBSAH CD

Příloha E Obsah CD •

Quake – složka se samotnou aplikací a modifikací aplikace, jejíž součástí je mapa

•

Code – cložka obsahující kompletní zdrojový kód aplikace

•

Návod.pdf – návod na zprovoznění a instalaci aplikace

•

Gtkradiant.msi – instalátor quake editoru

47

Virtuální průvodce budovou FEL. Pavel Holý

Recommend Documents