ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ

Fakulta elektrotechnická

BAKALÁŘSKÁ PRÁCE

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ

Fakulta elektrotechnická

Katedra počítačů

BloF - Vytvoření realistického modelu budovy fakulty a implementace navigace

Čestné prohlásení

Prohlasuji, ze jsem zadanou bakalářskou práci zpracoval sám s přispěním vedoucího práce a konzultanta 17517i87r a pouzíval jsem pouze literaturu v práci uvedenou. Dále prohlasuji, ze nemám námitek proti půjčování nebo zveřejňování mé bakalářské práce nebo její části se souhlasem katedry.

Datum: 15.1.2008

podpis bakaláře

Zadání

Vytvořit ralistický model budovy fakulty elektrotechnické.

Anotace:

Časem

Summary:

Časem

Obsah

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íz název je "Dejvice 3D". Tato aplikace byla velikým zdrojem inspirace pro tuto bakalářskou práci.

Rozhodl jsem se vytvořit novou, graficky náročnějsí aplikaci - "BloF", která bude obsahovat podrobnějsí model skoly a dalsí nové funkce. Z aplikace "Dejvice 3D" jsem vyuzil pro urychlení práce několik jiz hotových věcí.

Hlavním cílem bakalářské práce je vytvoření základního modelu skoly, implementace nové aplikace do Cave, přidání navigace do vytvořeného modelu a přidání dalsích funkcí.

Vedlejsím cílem této bakalářské práce je nastudování vybraného enginu a vývojového prostředí, vytvoření postupu pro realizaci projektu.

2. Inspirace

Při realizaci se naskytlo mnoho mozností jak cíle realizovat, inspirací se staly mnohé z nich. Ale některé více nez jiné a konkrétní věci byly pouzity přímo pro vývoj, jako výchozí software, nebo jako zdroj informací apod. - málo konkrétní

2.1 Dejvice 3D

Hlavním motivem vytvoření aplikace "BloF" byla aplikace "Dejvice 3D" dvou studentů FEL. Původní myslenka byla tuto aplikaci vylepsit a zpřesnit model. Bohuzel to se ukázalo jako nemozné z mnoha důvodů. Jádrem aplikace je jednoduchý engine, který je značně nedokonalý a spoustu věcí neumozňuje. Bylo tedy nutné pouzít dokonalejsí engine, protoze vylepsování tohoto enginu by trvalo spoustu času a hlavní cíle by to nesplnilo. Jako nejvhodnějsí byl vybrán engine "Quake 3" (viz níze).

Dalsí myslenka byla do tohoto enginu převést jiz hotový model skoly a ten upravit do vlastností Quake. Bohuzel tento model nebyl velmi dobře optimalizovaný a obsahoval spoustu nepřesností. Spatné poměry nebyly vhodné pro Quake engine, dále i textury nebyly přílis kvalitní a navíc v nepouzitelném formátu BMP a TGA. Konečně i počet vertexů nebyl optimalizovaný z důvodu spatné volby modeláře.

Jediná mozná varianta byla vytvořit vlastní model za pouzití vývojových nástrojů vytvořených přímo pro Quake a pouzít model Dejvice 3D jako podklad i zdroj informací.

2.2 Quake III Arena

Je kvalitně napsaná hra z roku 1999, fascinující svojí jednoduchostí a dokonalostí. Není sice jiz spičkou v oboru, ale její výhodou zůstává, ze poskytuje volnost obohacovat hráčskou a programátorskou scénu vlastními výtvory. V roce 2005 uvolnili její tvůrci zdrojové kódy k samotné aplikaci a umoznili tak její libovolnou modifikaci a dalsí síření pod "general public licence".

Pro tento projekt to byla výtečná volba. Tedy engine, který je vyzkousený, po letech zdokonalený a je volně přístupný a dále siřitelný. Navíc je zde moznost velice jednoduse tuto aplikaci modifikovat, jelikoz je napsána v C a je připravena jako projekt do MSVS, kde je velice jednoduse vestavitelná a modifikovatelná.

2.3 Open Arena

V nedávné době se skupina vývojářů rozhodla přepracovat hru do volně siřitelné formy. Důvodem bylo, ze ID software sice uvolnil zdrojové kódy, ale nikoliv hru samotnou. Cílem této skupiny tedy bylo předělat vse, co se objevilo v "Quake 3", do nové podoby.

Díky tomu lze Open Arenu dále modifikovat a výsledek dále sířit. Z toho důvodu byla nová aplikace BloF vyvíjena jako modifikace pro Open Arenu a následně osamostatněna. Dá se tedy říci, ze Open Arena slouzila jako opěrný bod v raných fázích vývoje.

2.4 IO Quake

Po uvolnění zdrojového kódu k aplikaci Quake 3 se dalsí skupina nadsených programátorů amatérů rozhodla vyčistit kód Quake, přidat základní bezpečnostní prvky a zjednodusit kód, jak jen je mozné - tzv. IO Quake. Také se rozhodli přidat komentáře k jednotlivým funkcím.

Svoje snazení dávají volně k dispozici a je mozno vyuzít jejich nové verze IO Quake, coz velmi zjednodusuje práci s kódem. A díky bezpečnostním prvkům se stává výsledek, ať jiz bude jakýkoli, stabilní a bezpečný proti útokům.

Značnou nevýhodou je v tomto případě neukončený vývoj, coz komplikuje přidávání vlastních funkcí, které se budou muset přenáset mezi novými verzemi. Ale výhody, které pouzití IO Quake přinásí, jsou značné. Hlavně zpřehlednění kódu a nové komentáře, které pomáhají pochopení jednotlivých částí kódu.

2.5 Xreal

Jedná se o podobný projekt jako je IO Quake. V tomto případě jeden německý programátor začal silně modifikovat engine Quake s cílem konkurovat současným hrám. Tomu se snazí přiblízit 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ů.

Bohuzel z Xrealu se stává nepouzitelná zálezitost díky nekompletnosti projektu. Doslo 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íse jako rozestavěná budova a není zcela jasné, jak bude vypadat. Proto je velmi tězké pouzít ho jako základ pro projekt. Ale nelze vyloučit pouzití některých zajímavých funkcí, které byly do Quake přidány.

Díky funkcím z Doom 3 také Zrezl zcela znemozňuje implementaci do Cave, jelikoz přidává do vykreslování funkce, které znemozňují stereoskopické vykreslování.

2.6 Hry současnosti

Cílem bylo vytvořit maximálně interaktivní aplikaci. To znamená zakomponovat do ní co nejvíce prvků, které jsou pro současné hráče zajímavé, i kdyz graficky nelze samozřejmě konkurovat nejmodernějsím produktům, na kterých pracují veliké týmy lidí.

Často se nejoblíbenějsí hry nepysnily dobrou grafikou, ale spíse dobrými nápady a provedeními. Jedním z cílů je do aplikace zabudovat pravidla, která udělají z BloFu interaktivní zálezitost, nikoliv pouze prázdné procházení budovou skoly.

2.7 Vlastní invence

Alfou a omegou kazdé nové hry je přidání něčeho nového, něčeho co tu jestě nebylo. Platí to i pro tuto aplikaci. Splnění tohoto se skrývá v podobě vytvoření plně realistického modelu budovy. Větsina her vychází z fantazie, a proto je velice snadné vyplnit prostory něčím smysleným, coz v tomto případě nelze.

Dalsí novinkou je implementace do Cave, coz jiz bylo dříve realizováno, ale velmi nepovedeným způsobem a vzdy se jednalo o import několika starých map z Quake 3.

Nejdůlezitějsí částí bylo vytvoření navigace. Tedy, ze v rámci projektu nebude vytvořena pouze aplikace jako pouhopouhá střílečka, ale bude mít svůj smysl i pro méně krvezíznivé občany.

Orientace v budově je pro nestudenty, nebo pro nové studenty velmi obtízná a realistický model by jim měl v budoucnu velmi pomoct, protoze si budou moct projít budovu a pak kdyz přijdou do té skutečné, tak najdou objekty a cedule přesně tam, kde je předtím viděli ve virtuálním modelu.

2.7 Architektonické plány budovy

K dosazení maximální přesnosti modelu byly pouzity přesné plány budovy, které díky speciálním prohlízečům DWG formátu umoznily měření v rozměrech upravených přímo pro Quake a tím tak velmi zjednodusily práci.

Bohuzel se v plánech nevyskytují objekty kazdodenního pouzití, tedy 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.

3. Vývoj

Kvůli časovému vytízení bylo třeba zvolit při vývoji BloFu správný postup. Důlezité bylo rozvrhnout vývoj do několika kroků, které mohou být postupně splněny. Je třeba vidět vývoj realisticky z pohledu schopností a časové náročnosti. Bohuzel kód není zcela jednoduchý na pochopení a práce s editory není z důvodu stáří programů přílis intuitivní, ale přesto se malé cíle zdají více nez reálné.

3.1 Aplikace pouzité při vývoji

Volba Quake enginu omezila i paletu jednotlivých aplikací, které jsou pouzitelné. Protoze samotný Quake má jistá omezení v tomto směru. Ke kazdé aplikaci zajisté existuje nějaká alternativa, ale i přes to si myslím, ze zvolené aplikace vyhovují nejvíce cílům projektu.

Kde to bylo mozné, byly pouzity nejnovějsí vývojářské aplikace a jejich nové verze. Jako kazdá hra se Quake skládá z jednotlivých komponent vyvíjených v různých aplikacích.

3.1.1 Open Arena

Pro vývoj je pouzita samotná aplikace, ale v konečné fázi nebude mít aplikace BloF s tímto produktem nic společného. Je pouze potřeba nedodělané věci nahradit jiz hotovými a vyzkouset tak funkčnost v průběhu vývoje, tím se setří čas a celý projekt je příjemnějsí na vývoj. Konkrétně při tvorbě prvních modelů map byly pouzity textury implementované do Open Areny, coz usetřilo čas potřebný na jejich tvorbu, kdyz jestě nebyly nezbytné. Také některé efekty a funkce byly pouzity pro dosavadní vývoj.

Pouzití Quake enginu má mnohé výhody, jako mnoho návodů a postupů, které jsou zveřejněny na Internetu. Dále moznost vyuzít spousty materiálů vytvořených v průběhu let, jako jsou například modely lidí, textury, objekty apod.

Bohuzel s sebou nese i nevýhody, jednou z nich je například stará technologie aplikace pro vykreslování - Open GL, která se promítá při práci s modely, ale i na výsledném produktu. Oproti tomu například novějsí DitectX umozňuje vyuzívat velmi jednoduse mnohé dalsí efekty pro vykreslování. Tento nedostatek lehce kompenzuje pouzitý IO Quake, který napojuje SDK ke kódu Quake a vyuzívá některé funkce DirectX 9.0. To ale na druhou stranu komplikuje vývoj, ale i přes to se jedná o velký přínos.

Dalsí nevýhodou je absence moderních prvků, jako například fyzikální engine. Fyzika jako takový je v Quake psána tzv. natvrdo, tedy vsechny úkazy jsou jednotlivě osetřeny v kódu a aplikovány na minimum objektů, v podstatě jen na to nejnutnějsí.

Fatálním nedostatkem Quake je absence dynamických světel, které jsou v současné době bězné. Na druhou stranu tato skutečnost dělá z Quake velice hardwarově nenáročnou zálezitost, ale v současné době výkonných počítačů je to spíse na skodu. Hardwarová nenáročnost je u Quake vyhnána do takového extrému, ze aplikace je spustitelná i na PDA a časem i na ultra-výkonných mobilních telefonech. Coz by nebylo spatné pouzití například pro vyhledávání tříd, které je součástí finálního produktu.

Mnohé dalsí nedostatky řesí IO Quake, případně také Xreal, který například vyřesil dynamická světla. Aplikace BloF je postavena tak, ze je do ní přeneseno co nejvíce těchto vlastností. Dalsí výhodou je přenositelnost aplikace mezi různými platformami OS, coz je mozné vyuzít.

Ve své podstatě byla volba Quake pro tuto aplikaci velmi dobrá, jelikoz nevyzaduje tolik pozornosti k zprovoznění a je zde spousta prostoru pro vlastní tvorbu. A také umozňuje implementaci do systému Cave, viz níze.

3.1.2 GTK Radiant

Pro své potřeby vytvořila vývojová firma ID Soft svůj vlastní modelářský software, který je silně přizpůsoben vývoji map pro enginy této firmy. Skrývá v sobě jednoduché funkce a ve své době velice intuitivní prostředí.

Postupem času byl tento software zdokonalen a pouzit i pro vývoj map k Doom 3 apod. Mapy ukládá jako modely do vlastní souborové struktury MAP, která můze být mnoha způsoby upravena na výslednou mapu, která je pak pouzívána samotnou aplikací.

Tento způsob práce s modelem mapy činí mapu zcela nezávislou na aplikaci, ve které je pouzívána, pokud ji daná aplikace podporuje. Je zde tedy moznost pouzí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řeseno velice sikovně pouzitím parametrů a funkcí, které s těmito parametry pracují. Je tedy mozné si vlastnosti editoru modifikovat a libovolně s označenými objekty v hlavní aplikaci pracovat.

Samotné uzivatelské rozhraní je rozporuplné, poněkud zastaralé a na první pohled neintuitivní, ale po pečlivém nastudování návodu, je více nez sikovné. Bohuzel není psané pro veřejnost, ale pro programátory?? Základní funkce nejsou přiřazena k tlačítkách na listě, ale pouze ke klávesovým zkratkách, bez jejich znalosti je práce s editorem nemozná.

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, coz je oproti například 3ds Maxu nezvyk. Ale díky tomu je místo na dalsí uzitečná okna. Jedno z opravdových vymozeností je okno, které simuluje výsledek ve hře. Tedy plnohodnotný 3D pohled na model mapy, kterou je mozno procházet. Navíc jsou jednotlivé části potazeny texturami, je tedy mozno si udělat rychle dojem, jak bude vypadat výsledný model. Proto není nutné tak často mapu zkouset v samotné aplikaci (renderovat), coz setří čas.

Poslední okno aplikace obsahuje náhled textur, které je mozné pouzít. Coz opět velice setří čas. V editoru je obsazena spousta uzitečných funkcí, ale vse je dokonale jednoduché a po přečtení návodu není problém vymodelovat takřka cokoli.

Velikou výhodou je moznost vkládání do modelu mapy externí modely z jiných editorů a to dělá z mocného nástroje nástroj jestě mocnějsí, zvládá základní formáty jako 3DS, ASE, OBJ apod. Je tedy mozné v jakémkoli bězně pouzívaném editoru vytvořit model a jednoduse ho importovat do vytvořené mapy.

To s sebou nese rizika, jako například lehkou nekompatibilitu. Model je sice vlozen 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ě jednoduse řesí a to díky technice klipování, coz v jednoduchosti znamená vytvořit kolem vlozeného modelu objekt, který bude průhledný, ale bude ve hře mít odpovídající vlastnosti.

Celkově je práce s GTK Radiantem velkým usnadněním při vývoji aplikace BloF. Je třeba naplno vyuzít jeho potenciál, hlavně v oblasti dopisování nových vlastností daných objektů a vlastních funkcí.

Pro vyssí interaktivitu obsahuje editor také některé základní funkce, jako například výtahy, tlačítka a mnoho dalsího. Coz bylo velice uzitečné při ozivování virtuální budovy. Protoze pro maximální realističnost je třeba, aby se například páter noster pohyboval.

3.1.3 Autodesk 3DS MAX

Profesionální modelovací software, který umozňuje tvorbu libovoných modelů mnoha technikami, je tou nejlepsí volbou na doplnění do Radiantu.

Umoznuje modelovat cokoli a výsledné modely jsou za pouzití i těch nejslozitějsích modelovacích technik exportovány do velice čitelného a přehledného ASE formátu, se kterým si Quake velice jednoduse poradí.

Výhodou je ze Quake zvládne importovat i animace, které dokáze ve hře pouzívat. Je tedy nezbytností, aby tyto vlastnosti byly co nejvíce pouzity v aplikaci.

Mnohé problémy mohou nastat v přílisné slozitosti modelů, které mohou zpomalovat celou aplikaci, ale díky optimalizaci modelů při překládání mapy se tento jev minimalizuje. Dalsí nepříjemností je klipování, coz můze u některých obvzlástě slozitých modelů přidělávat práci. Neméně důlezité je měřítko, které se vůči mapě tezko odhaduje, a pozdějsí změny měřítek můze 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 pouzity je třeba modifikovat v externím editoru, protoze Radiant slouzí výhradně k modelování map. Pro tyto potřeby není vybaven nezbytnými funkcemi.

3.1.4 Milkshape

Jedná se o jeden z méně známých editorů, který vsak v sobé má funkci exportu jakéhokoli modelu, který je načten přímo do Quake. Navíc umozňuje automatické klipování exportovaných objektů. Při exportu převádí objekt do speciálního formátu, se kterým se pak mnohem lépe pracuje, jako například se dá invertovat, natáčet a zrcadlit.

3.1.5 Adobe Photoshop

Jediná mozná volba pro práci s obrázky, tedy texturami v aplikaci. Je zcela nezbytné, aby výsledné textury měly co nejvyssí kvalitu a co nejmensí velikost z důvodu rychlejsího načítání do paměti.

Drtivá větsina textur pro BloF je tvořená z fotek, které byly pořízeny přímo ve skole. Ve Photoshopu jsou pak z těchto fotek vytvořeny editací reálné textury. Pro účely BloFu i dalsích her je třeba, aby textury navazovaly ve vsech směrech samy na sebe, aby se daly kopírovat vedle sebe a nebyly patrné přechody.

To je samo o sobě velmi tězký úkol z důvodu nerovnoměrného nasvícení objektů ve skole. Na několika centimetrech se nasvícení objektů velmi znatelně mění a to pak znemozňuje plynulé navazování.

Z tohoto důvodu je pouzit Photoshop, který má v sobě zabudovány funkce, které zjednodusují práci s texturami a výsledek velmi kvalitně komprimují.

Konečná textura je pak pouze načtena Radiantem a přiřazena příslusnému objektu. Quake také jako jedna z prvních her své doby přisel s technologií mutlitexturování, coz je realizování pomocí skriptů (viz níze).

3.1.6 Microsoft Visual Studio

Vůbec nejdůlezitějsí aplikací ve vývoji je právě Visual studio, ve kterém je celá aplikace napsána, konkrétně tedy i IO Quake. Je tedy více nez jednoduché jí modifikovat a to zcela libovolně.

Vlastní aplikace BloF vytvořená ve Visual studiu se skládá z: Quake - jako 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í vse pro boty (počítačem ovládané postavy).

Celou aplikacei obsahující přes 4000 samostatných souborů je velice tězké pochopit a začít modifikovat. To bohuzel zabírá mnoho času, ale paradoxně ho také setří, protoze mnoho věcí, které budou ve výsledném produktu je v Quake jiz napsáno 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é setří práci. Na Internetu je k dispozici také mnoho návodů a tutoriálů, které práci s kódem vemi usnadňují.

Překonat takové mnozství řádek je velký úkol, ale moznosti jeho vyuzití a rozsíření jsou skoro neomezené a umozňují volnost, které je mozné vyuzít.

3.1.7 Adobe Premiere

Méně podstatná aplikace, která slouzí ke střihu videa na prezentaci aplikace. Spolu s malinkým programem Fraps, který umozňuje nahrávání videa přímo z Quake je jediná moznost na kvalitní editaci.

3.2 Postup a fáze vývoje aplikace

Je nezbytná vhodná volba postupu při vývoji tak rozsáhlé aplikace. Je vhodné začít jednoduchými věcmi, ty postupně propojovat a přecházet k věcem slozitějsím, aby bylo mozno dovést projekt do finální podoby co nejdříve a flexibilně, podle potřeby.

I přes promyslený postup se naskytly časem obrovské problémy. Muselo být vytvořeno obecné patro, které se pak modifikovalo a celá skola vznikala z jednotlivých modifikovaných pater. Viz kapitola 3.2.4.

3.2.1 Jednoduchá mapa

Aplikace byla nejprve vytvořena v původní Open Arena, do které se postupně přidávaly objekty, které ve výsledku nahradily celou původní aplikaci. Nejprve byla vytvořena vlatní mapy vytvořená v Radiantu.

Bylo potřeba si vyzkouset samotné překládání mapy pro Quake a zvládnutí práce s editorem. K dispozici byly nastěstí oficiální manuály, takze tato fáze zabrala pouze několik dní studia manuálu.

K vytvoření jednoduché mapy byly pouzity původní textury z Quake. Pro tu nejjednodusí mapu stačily 4 stěny, světlo a startovní pozice hráče. Tato místnost při testování způsobovala lehkou klaustrofóbii.

Pro rozvoj mapy ji bylo nutné rozsířit a přidat více místností a průchody osadit dveřmi, na které uz byla pouzita první zabudovaná funkce door, která se stará o otevírání dveří v přítomnosti hráče.

3.2.2 Rozvoj jednoduché mapy

Při přecházení ke slozitějsím částem mapy bylo třeba sáhnout k vlastní tvorbě textur a s tím souviselo i natahování textur na objekty, coz je zcela nezbytná věc. Defaultně jsou textury ve velmi nízkém rozlisení z historických důvodů a je třeba je upravit tak, aby se dosáhlo co nejlepsího vzhledu. Nastěstí není velikost a kvalita textur omezená, coz je pro tento projekt veliká výhoda a mohou tak být pouzity fotorealistické textury o velkých rozliseních.

Dalsí fází pro vylepsení mapy je vyuzití dalsích zabudovaných funkcí, mezi podstatné patří "train" a "rotate", které pohybují danými objekty podle nastavení. K dispozici jsou i jiné, ale otázkou je jejich vyuzití v tomto projektu.

Součástí editoru je i jednoduché modelování a pouzívání oblých objektů, které je velice intuitivní.

Dalsím krokem bylo vytváření základů budovy skoly. V tomto případě bylo rozumné začít jedním patrem a k němu postupně přidělávat dalsí a vytvořit tak postupně celou budovu.

3.2.3 Ozivování mapy

Mapa můze být velice jednoduse doplněna externímy 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ějsí vzhled.

Dalsí silným nástrojem na ozivení mapy je zabudované skriptování vlastností shaderů. To znamená dopisování vlastností jednotlivých textur. Touto metodou je realizováno multitexturování, průhlednosti textur, jejich rozmazávání apod. Lze tak jednoduse vytvořit okno s efektem lesku, či lesk na podlaze. Ke skriptování se pouzívá několika přednastavených funkcí podle návodu, ale je moznost tyto funkce měnit a přidávat.

3.2.4 Defaultní patro

Po velmi neúspěsném prvním pokusu spojit 3 patra nad sebe bylo třeba celou mapu předělat, jelikoz více pater nad sebou se stalo needitovatelnými. Bylo proto nutné vytvořit obecné patro, které obsahuje pouze to, co se vyskytuje na kazdém patře, jako napsíklad sloupy a dřevěné vitríny.

Kazdé takové patro bylo zeditováno do podoby jednotlivých pater. To znamená, ze byly změněny textury podlah, pozice dveří apod.

Tato patra se pak spojila nad sebe a vznikl celek. V kazdém patře byly zastavěny schodistě, protoze přesahují mezi patry. Schody a výtahové sachty byly přidány az po spojení jednotlivých pater.

3.2.5 Struktura mapy

Celkově je struktura mapy rozdělena do jednotlivých bloků, aby bylo umozněno dynamické načítání jednotlicvých částí. Díky tomu se předeslo problémům s vytězováním procesoru a grafické karty.

Také vsechna schodistě byla rozdělena do bloků podle pater, aby se zamezilo načítání celého schodistě.

Tyto kroky byly nezbytné kvůli převodu do VRML (viz kapitola 7).

3.2.6 Programování

Po vytvoření mapy bylo třeba se začít zabývat samotnou aplikací, jelikoz výsledným produktem nebude bezmyslenkovitá střílečka, ale aplikace, která simuluje zivot na skole umozňující vyhledávání tříd.

Bylo nutné modifikovat jádro aplikace a přidat nové funkce a uzivatelské prostředí přetvořit na něco mírnějsího. To obnásí přepsání mnoha řádek kódu a vytvoření nových obrázků a textur pro menu.

Bylo mozné zachovat předchozí objekty a vlastnosti???, které souvisí spíse s nastavením aplikace a vykreslováním, jelikoz v součastném zpracování Quake je toto vyřeseno vskutku geniálně.

Modifikací jádra se objevilo mnoho problémů. Oproti tvorbě mapy není jádro aplikace nijak detailně popsáno.

3.3 Ozivování

I přes naplnění mapy objekty, které do skoly přirozeně patří, je poněkud vyprázdněná a mnoho se reailitě nepřiblizuje. Proto je třeba přidat někdete objekty, které se ve skole v průbehu dne vyskytují, ale nejsou součástí vybavení skoly.

3.3.1 Nové modely

Příkladem za vsechny je třeba pouzitý kelímek z automatu povalující se na chodbě. Případně papír pohozený na stole. Dalsí mozností jsou notebooky, které studenti pouzívají kazdý den v hojném mnozství.

Jedině za předpokladu přídání těchto objektů můze být model opravdu realistický.

3.3.2 Nástěnky

Za celkovbý duch skoly mluví nejvíce vsudypřítomné nástěnky. I kdyz větsina z nich byla updatována naposledy dlouho před prvním cinknutí klíčů na Václavském náměstí v roce 1989.

Je třeba se na tento skolní fenomén se zaměřit. Mozností je více - první a asi nejpřirozenějsí je ponechat ve virtuální skole původní podobu nástěnek. Coz je velmi pohodlné, ale pracné a ne přílis efektivní.

Dalsí mozností je vyuzít jich jako reklamních ploch. Z důvodu přítomnosti sponzorů v tomto projektu, neni tato myslenka tak nemozná. Ale je třeba se vyhnout kýčovitosti a přehrselu reklam.

Poslední a realizovanou mozností je nástěnky dynamicky aktualizovat z internetu. Coz je umozněno díky dobré struktuře souborů v quake. Vsechny textury jsou ulozeny v slozce textures a aktualizací se dají původní textury přepsat a v mapě se objeví pouze ty aktuální.

Na moznost realizovat tyto aktualizace bylo třeba pamatovat jiz při vývoji mapy, konkrétně při texturování. Je totiz třeba na kazdou nástěnku jednotlivě natahovat textury různých názvů, protoze při aktualizaci by se přepsali vsechny nástěnky.

V součastné době jsou na skole natazeny prázdné textury na nástěnkách, které jsou k dispozici ke stazení na internetových stránkách projektu. Jednotliví uzivatelé si mohou stáhnout jednotlivé textury a volně si je modifikovat a pak je nahrát zpět na stránky. Po lehkém cenzurování jsou textury ulozeny do speciálního ulozistě odkud se stahují do počítačů vsech uzivatelů BloFu. Tedy kazdý uzivatel vidí vsechny výtvory ostatních uzivatelů.

Příklad...

3.4 Obohacování

Jako na kazdém vývoji je třeba přidat něco svého. Při tak dlouhém vývoji je velmi tězké se vyhnout vtípkům na vlastní účet. Proto jedním z největsích obohacení je vlození humoru a vtipů do projektu.

3.4.1 Humor

Do samotné mapy bylopřídáno mnoho drobných zertů, které nemají za cíl někoho urázet, ale pobavit vývojáře, který jiz psychycky nezvládá dalsí vývoj. Pro příklad je lepsí se podívat přímo do mapy.

3.4.2 Komiksy

S laskavým souhlasem .... bylo dovoleno pouzít postavy z komiksů, které jsou na felu vseobecně známy. Stejně tak i komiksy samotné. Pouzity budou například i na nudné nástěnky. A postava Damiena Zla bude postupem času vymodelována, jako herní postava.

Příklad....

4. Textury

Hlavní náplní této semestrální práce bylo vyřesení problému implementace Quake (potazmo BloFu) do systému Cave

4.1 Co je Cave

Hlavní náplní této semestrální práce bylo vyřesení problému implementace Quake (potazmo BloFu) do

5. Cave

Hlavní náplní této semestrální práce bylo vyřesení problému implementace Quake (potazmo BloFu) do systému Cave.

4.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 uzivatel 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 moznosti pohledu nahoru a dolů. Coz je velmi omezující a pro plnou funkčnost BloFu je nezbytné, aby tento problém byl na Cave vyřesen.

4.2 Konkretizace problému

Quake sám o sobě má funkci vykreslování do sterea, a to díky přímému pouzí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 jednoduse 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é.

Hráč nemá moznost se podívat doleva nebo doprava ani ve hře, coz je velmi omezující faktor, oproti například leteckým simulátorům. Dalsí problém je, ze ostatní projektory jsou ovládány jinými počítači a je třeba nějak řesit synchronizaci a projekci té samé mapy.

4.3 Řesení problému

Řesení je třeba hledat co nejjednodussí s vyuzitím dalsích vlastností, které Quake má. Problém synchronizace Quake umozňuje řesit velice jednoduse - pomocí tzv. síťové hry, resp. propojení totozný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 nastěstí jestě jedna funkce, která se nazývá spectate. Ta umozňuje hráči, který je připojen do nějaké hry, sledovat přesné pohyby hráče, kterého sleduje.

Tím je vyřeseno promítání stejné mapy a synchronizace, která se provádí jednoduchou komunikací typu klient - server. Po pouzití tohoto triku by ale výsledek byl následovní - na kazdé stěně by se promítalo to, co vidí jeden hráč, ale pohledem před sebe, coz je spatně. Je tedy nutno postraním počítačům říct, aby otočily pohled o 90 stupňů za pouzití stejné aplikace.

4.4 Advanced solution

Kvůli spolupráci po síti je třeba zachovat stejný build na vsech PC. Je tedy nějak potřeba ovládat jednotlivé pohledy parametrem. Proto byla v kódu vytvořena proměnná cg_FelCave. Ta funguje jako měnič pohledů. S hodnotou 0 je aktivován pohled popředu, s hodnotou 1 doprava, a 2 doleva.

Samotná změna v kódu tak jednoduchá není a vyzaduje dokonalou znalost systému řízení přerusení od mysi a příslusné reakce. Nutnou znalostí je také soustava proměnných a funkcí, které řídí zobrazování. Výsledek se můze zdát velmi jednoduchý, ale taková změna kódu vyzadovala spoustu testování.

4.5 Problém v problému

Pohled kamerou je dokonalé přirovnání k tomu, jak Quake opravdu funguje. Pro pohledy rovné bez naklonění, je vse bez problémů. Ty se vsak objevují při pohledu nahoru a dolů, jelikoz kamera se při těchto pohledech naklání a tím se rozjízdí 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 vsech tří pohledů.

Řesení se nabízí jediné. Převést proces, 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 řesení 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 geniální řesení, které by bylo krátké a jednoduché. Nastěstí v tom vysel Quake vstříc a díky systému na jakém funguje stačilo pár drobných úprav na správných místech. Konkrétně slo o zvýsení úhlu, ze kterého se kamera dívá na scénu a natočení tohoto pohledu. Také se jednalo o změnu kopírování vektorů, které jsou výsledkem vstupu mysi, na jiné operace s kamerou, nez jaké byly původně.

To celé je aplikováno jako závislé na hodnotě proměnné cg.felCave.

4.6 Ukázka finálního kódu

if( cg.felCave>0)

}

else

VectorCopy( ps->viewangles, cg.refdefViewAngles );

Raději bez zdlouhavých komentářů, samotné získávání Yaw, Roll a Pitch je velmi slozité a samotné přehazování bylo otázkou nastudování jak přesně fungují. Některé operace jako přičítání 30˚ k úhlu náklonu byly otázkou testování a původ spatné hodnoty zůstává nevysvětlen.

4.7 Ukázka v praxi

Screenshoty z testování řesení problému v praxi, na projektu BloF na jednom PC, který simuloval server s pohledem dopředu a pohledem do strany jako připojený klient.

5. Současný stav

V současné době je projekt v pokročilé fázi a tězký start má jiz zdárně za sebou. Je vytvořen kvalitní základ mapy, na kterou je aplikováno hodně efektů a je do ní vlozeno mnozství externích objektů.

V kódu aplikace proběhlo pár minoritních změn, ale vse je připraveno k plnohodnotnému rozvoji. Zatím největsí úspěch je zdárné dokončení implementace do Cave. Řesení bylo vyzkouseno a aplikace je tak připravena na pouzití.

5.1 Obrazárna

Na úspěchy dosazené při modelování map nejlépe poukazují následující obrázky. Zároveň také srovnávají realitu a model skoly v naprosté otevřenosti a upřímnosti.

Pohled na chodbu

Kose na tříděný odpad

Pohled na schodistě

Detail schodistě

6. Budoucnost projektu

Finální koncepce celého projektu jestě není zcela jasná. Jelikoz mozností je mnoho a je velmi tězké odhadnout časovou náročnost jednotlivých konceptů. Zatím je vse ve fázi promýslení. Je třeba jednoznačně určit cíle, coz se týká vsech fází vývoje.

6.1 Vývoj mapy

V mapách jsou cíle poměrně jasné, tedy dokončit budovu skoly co nejvěrohodněji s co nejvíce místnostmi. Otázkou je kde přestat, ale díky měnící se podobě skoly je toto poměrně nekonečný proces. Hlavním cílem je dodělat základ budovy, hlavní chodby a posluchárny, tedy vse co je podstatné pro aplikaci, která s modelem bude pracovat.

6.2 Vývoj aplikace

V aplikaci je finální cíl dosti nejasný, protoze projekt Quake je velmi rozsáhlý a přidávat do něj nové věci se dá takřka kdekoli. Otázkou je, co bude největsím přínosem pro projekt. Zda se soustředit na vývoj nových funkcí, jako implementace fyziky či dynamických světel, nebo na funkce z pohledu uzivatele, tedy třeba napojení aplikace na internetovou databázi, či přidělat autoupdate apod.

Dalsí mozností je se soustředit na výsledek, který uzivatel opravdu bude vyuzívat, tedy finální aplikaci. V této oblasti je minimálně jasné, co projekt zahrne, ale sám projekt je koncipován jako soubor více mozností vyuzití modelu.

6.2.1 Vyhledávání tříd

Jedna ze základních funkcí v BloFu by měla být vyhledání pozadované třídy, jako to bylo u aplikace Dejvice 3D. To můze být uzitečné pro nové studenty Fel, kteří si nejen prohlédnou budovu skoly a v té se zorientují, ale také si budou moct dopředu najít třídu, aniz by museli hledat na mapkách skoly. Díky simulaci reality si tak budou moci zapamatovat okolí a nebudou bloudit budovou a obtězovat profesory a studenty dotazy na lokaci tříd.

Pro implementaci takové funkce bude třeba se zaměřit na importování slozitých datových struktur do Quake. A také bude třeba zanést body do mapy a udělat z nich graf, ve kterém bude mozno vyhledávat nejkratsí cestu ke zvolené třídě (bodu). To s sebou nese pozadavek na znalosti, které by měli studenti probírat v průběhu 4. semestru, coz je značná výhoda.

Samotný výpočetní algorytmus by mohl být jako nezávislé vlákno na hlavní aplikaci, do kterého by se posílaly pozadavky na nalezení bodu na mapě, a které by vracelo trasu vůči aktuální poloze. Tím by se dala cesta dynamicky měnit, podle změny polohy na tu v dané chvíli nejefektivnějsí.

Mozná je i varianta, ze by postava sama dosla nejkratsí cestou k vyhledávané třídě, tedy něco jako autopilot, který by se po cestě dal kdykoli vypnout a zapnout.

6.2.2 Simulace evakuace

Zajímavá myslenka je implementovat do BloFu evakuační plány skoly a hlavní postavu dát do situace, která vyzaduje nouzový únik a rychlé jednání. Okolní postavy, jejiz inteligence by musela být dopsána, 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 skolní databáze a student by musel projít bezpečnostním skolením.

Jedna z variant by obsahovala skolení přímo ve hře formou interaktviních tutoriálů. A výstupním testem by byla právě simulace skutečné krizové situace.

Zde by byl prostor pro libovolné programátorské experimentování, například systém síření ohně a jeho postup mezi různými povrchy. Také umělá inteligence dalsích postav by musela být napsána, v Quake je sice inteligence protivníků, kteří se snazí zabíjet co nejvíc a únik před ohněm jim je zcela lhostejný. Avsak dala by se zde pouzít celá řada napsaných funkcí a různých algorytmů pro boty.

6.2.3 Klasická "střílečka"

Pro studenty bohuzel bude pravděpodbně bezmyslenkovitá akčně-brutální řezba, která se podobá masovému vybíjení kuřat z chovu, kde byl nalezen virus ptačí chřipky. Samotná koncepce Quake nemusí být v BloFu vynechána, coz řesí základ této střílečky. Je zde tedy mozná hra po síti proti lidským oponentům, ale i proti počítačem řízeným protivníkům.

Zde je samozřejmě také prostor k rozvoji, ale tato větev je slepá, jelikoz BloF asi bude velmi tězko konkurovat moderním masovým vybíječkám s ultramoderní grafikou.

6.2.4 Dalsí experimenty

Na dalsí mozných variacích se pracuje, repsektive na jejich návrzích. Jak bylo jiz zmíněno, BloF je koncipován tak, ze by mohl obsahovat vsechny výse zmíněné moznosti a jestě mnohem víc a právě zde je prosto pro dalsí studenty, kteří budou chtít vyuzít model a velmi podajného kódu Quake 3.

7. Závěr

Já osobně vkládám do projektu velké naděje a chtěl bych ho odevzdat jako bakalářskou práci. Bohuzel rozsáhlost tohoto projektu převysuje schopnosti a časové moznosti jednoho člověka, proto je nezbytná spolupráce více lidí. Ti si ale práci mohou rozděli mezi jednotlivé části vývoje, nebo mezi jednotlivé módy aplikace.

Moznosti jsou opravdu skoro neomezené, ale je nutno vidět i jejich reálnost a splnitelnost. Rád bych tento projekt dotáhl co nejdál. A chtěl bych, aby z něj mělo uzitek co nejvíce lidí, případně aby se nasel někdo, kdo na projekt naváze.

Novinky a vývoj je mozné sledovat na stránkách projektu - www.blof.ic.cz

8. Literatura a zdroje

www.idsoftware.com

Manuál ke GTK Radiant

www.quakedev.com

fps.brainerd.net

www.qeradiant.com

tutorials.moddb.com

code3arena.planetquake.gamespy.com

a mnohé dalsí.