České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Bakalářská práce
Aplikace Mantichora II – Komunikační model Jan Matoušek
Vedoucí práce: Ing. Jiří Chludil
Studijní program: Elektrotechnika a informatika, strukturovaný, Bakalářský Obor: Výpočetní technika 23. května 2010
iv
v
Poděkování Děkuji všem, kteří mě podporovali při psaní práce – své rodině, týmu Mantichory a vedoucímu práce Ing. Jiřímu Chludilovi. Z týmu Mantichory za podporu a diskusi děkuji jmenovitě svým týmovým kolegům: Danielu Slavíkovi, Jiřímu Šemberovi, Martinu Šmardovi a Pavlu Šrámkovi. Také děkuji svým projektovým předchůdcům – Vladimíru Blažkovi, Ondřeji Čermákovi, Zdeňku Hákovi, Jiřímu Nekolovi, Václavu Podlipnému a Michalu Vaňkátovi – za jejich vykonanou práci. Děkuji každému čtenáři, který si tuto práci přečte a řekne si, že je to zajímavé.
vi
vii
Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
Abstract This bachelor thesis is part of long-term project of simulator and visualiser called Mantichora. The thesis states basis of communication model by presenting metalanguage used to describe terms and objects specific to each simulation domain. Furthermore the thesis presents scene language design principles and module interface design principles with steps leading to their generation from domain described using the metalanguage. The metalanguage and the dependant format design principles form the base of future project architecture and will allow its expansion.
Abstrakt Tato bakalářská práce je součástí dlouhodobého projektu Mantichora, který má za úkol vizualizovat a provádět simulace. Práce pokládá základ komunikačního modelu pomocí návrhu metajazyka sloužícího k popisu pojmů a objektů specifických pro každou simulační doménu. Dále tato práce navrhuje zásady jazyka scény a komunikačních rozhraní modulů společně s postupy vedoucími k jejich vytvoření z metajazykem popsané domény. Navržený metajazyk a zásady vytvoření jazyka scény a komunikačních rozhraní utvoří základ budoucí architektury projektu a umožní jeho rozšiřování.
ix
x
Obsah 1 Mantichora 1.1 Popis projektu . . . . . . . 1.1.1 Cíle projektu . . . . 1.1.2 Rysy projektu . . . . 1.2 Historie projektu . . . . . . 1.2.1 Lidé, kteří se podíleli 1.3 Současnost projektu . . . . 1.4 Možné využití projektu . .
2 Analýza zadání 2.1 Komunikační model prototypu z prvního roku vývoje 2.2 Závěry z prvního roku vývoje . . . . . . . . . . . . . 2.2.1 Hodnocení komunikačního modelu prototypu 2.2.2 Potřeba zobecnění . . . . . . . . . . . . . . . 2.3 Současný stav vývoje nové architektury . . . . . . . 2.3.1 Modulární struktura aplikace . . . . . . . . . 2.3.2 Zamýšlený způsob práce s Mantichorou . . . 2.4 Požadavky na jazyk pro popis světa . . . . . . . . .
Mantichora Slovo mantichora označuje bájné zvíře, které se rodí v poušti a které řecký učenec Plinius starší ve svém díle Přírodověda popisuje takto: Má tři řady zubů nahoře spojených na způsob hřebene, lidskou tvář a uši, modré oči, lví tělo krvavě červené barvy a ocas zakončený ostnem jako u štíra. Je nesmírně rychlé a rádo si pochutnává na lidském mase. Hlasem připomíná píšťalu kombinovanou s trubkou... [4] V různých mytologiích je tvor zvaný mantichora1 zobrazován různě. Průnikem těchto popisů je lev červené srsti, bez hřívy a s kratší tlamou (což může připomínat lidskou tvář). Zmínka o ocasním ostnu poukazuje na možnost, že mantichora byla jeskynní lev. Různé legendy mantichoru přibarvují – zmiňují např. dolů směřující rohy s ostrými konci či tři řady zubů na způsob hřebene (což by mohlo znamenat, že mantichora byla šavlozubá šelma), nebo (už méně uvěřitelná) křídla. Dle původu legend žila mantichora v oblastech Persie, Indie, Malajsie a Indonésie. Samo slovo mantichora je původem ze staré perštiny, kde znamená „lidí požírač“.[13] Popis tohoto bájného tvora připomíná jakousi zoologickou koláž, kde spojením více věcí dohromady vznikne věc nová s novými vlastnostmi.
1.1
Popis projektu
Mantichora je víceletý týmový výzkumný projekt, jehož cílem je vytvořit modulární aplikaci určenou k interaktivní simulaci a vizualizaci fyzikálních dějů.
1.1.1
Cíle projektu
• Simulovat a vizualizovat výlety do vesmíru a děje ve sluneční soustavě, v budoucnu potom i úplně jiné popsatelné děje. • Výzkum optimalizačních technik v rámci jednotlivých modulů a jejich vzájemné komunikace. 1
někdy též mantikora
1
2
KAPITOLA 1. MANTICHORA
1.1.2
Rysy projektu
• Modularita aplikace. Ta umožňuje členit vývoj do několika na sobě nezávislých částí, rozšiřovat aplikaci o nové funkčnosti a snadnou obměnitelnost jednotlivých částí aplikace. Další výhodou modularity je možnost provozu jednotlivých modulů na různých strojích. • Multiplatformita jednotlivých modulů. Je možné provozovat Mantichoru na více platformách a na různých strojích různých platforem, tudíž i vzájemná komunikace modulů může probíhat napříč různými platformami. • Tým. Rozsah projektu přesahuje možnosti2 jednoho člověka. Práce v týmu však tento nedostatek řeší, přesto je projekt Mantichora víceletý, či spíše dlouhodobý. Výhodou týmové práce je také možnost řešení několika problémů současně, navíc se jedná o cenný zdroj zkušeností a čím dál obvyklejší způsob (nejen) vědecké práce.
1.2
Historie projektu
Projekt byl založen Ing. Jiřím Chludilem, který je vedoucím všech závěrečných prací týkajících se projektu Mantichora. Myšlenka modulární aplikace k simulaci dějů ve sluneční soustavě jej napadla před několika lety, ale sám neměl dost času k její realizaci, proto v akademickém roce 2008/20093 sestavil tým a zahájil práce na projektu. • V roce 2009 vznikl funkční prototyp – důkaz, že aplikace Mantichora může fungovat. • V roce 2010 projekt probíhá druhým rokem a navazuje na zkušenosti a bakalářské práce z prvního roku. Vznikají základy pro finální verzi aplikace.
1.2.1
Lidé, kteří se podíleli na funkčním prototypu
• Václav Podlipný Jeho úkolem bylo vybrat a zdokumentovat [15, kap 6] vhodný nástroj, kterým by bylo možné práci na projektu řídit a spravovat. Zvolil Assemblu [15, kap 5.4]. V současnosti je členem tzv. support týmu, který pracuje na vytvoření vlastního projektového a komunitního serveru Mantichory. • Zdeněk Hák Provedl rešerši modulárních aplikací [11, kap 2.2] a technologií [11, kap 3]. Rozebral možnosti tvorby modulárního softwaru ve vývojovém prostředí Eclipse [11, kap 5]. • Ondřej Čermák Navrhl a implementoval editor scény, ve kterém je možné poskládat scénu z různých objektů (slunce, planety, rakety). Také navrhl formát uložení scény[9, kap 4.3]. 2 3
zejména časové dále jen 2009, beru za důležitý rok napsání příslušné bakalářské práce
1.3. SOUČASNOST PROJEKTU
3
• Jiří Nekola Vytvořil jednoduchý prototyp[14, kap 6.1] matematicko-fyzikálního modulu, jehož úkolem je počítat polohy a pohyby objektů ve scéně. Řešil také problematiku komunikace mezi jeho modulem a vizualizačním modulem[14, kap 3.2]. • Vladimír Blažek Stvořil vizualizační modul pomocí knihovny Java3D. Řešil také popis scény [8, kap 4.1] a komunikaci s matematicko-fyzikálním modulem [8, kap 4.2]. • Michal Vaňkát Pracuje na vizualizačním modulu napsaném pomocí knihovny OpenGL. Svou bakalářskou práci odevzdává až letos. Bude zajímavé srovnat jeho modul s Blažkovým. [8, kap 7.3.5]
1.3
Současnost projektu
Na Mantichoře v současné době spolupracují následující tři „podtýmy“4 : • Graficko-fyzikální tým Pracuje na vizualizačních a matematicko-fyzikálních modulech. Také pracuje na tvorbě dat (textur, 3D modelů). • Komunikační tým Řeší obecnou strukturu aplikace, vazby mezi moduly, komunikační protokoly a způsoby vytváření modulů a jejich komunikačních rozhraní. V současné době je tento tým klíčový, protože musí vytvořit základ pro implementaci modulů. Náplň mé bakalářské práce souvisí právě s tímto týmem. • Support tým Zajišťuje zázemí pro práci týmů a stará se o propagaci projektu. Jeho úkolem je vytvoření komunitního a vývojářského serveru.
1.4
Možné využití projektu
Mantichora jako simulační a vizualizační nástroj může sloužit jednak jako pomůcka při výuce na základních, středních i vysokých školách, jednak jako nástroj využívaný na vědecké úrovni k simulaci složitějších fyzikálních, případně biofyzikálních dějů.[14, kap 2.4.4] Mantichora se může stát i základem masových online her.
4
části týmu Mantichory; dále jen týmy s konkrétním názvem
4
KAPITOLA 1. MANTICHORA
Kapitola 2
Analýza zadání V této kapitole uvedu okolnosti vedoucí k zadání mé bakalářské práce a zdůvodním její potřebnost zasazením zadání do kontextu těchto okolností.
2.1
Komunikační model prototypu z prvního roku vývoje
Zamýšlená modulární architektura (viz obr. 2.1 na str. 6) se skládá z jádra, ke kterému jsou připojeny konkrétní moduly. Některé moduly (např. matematicko-fyzikální engine) mohou využívat služeb 3rd party programů (např. Matlab). V prototypu byla tato architektura zjednodušena. Byly vytvořeny pouze editor scény[9], vizualizační modul[8] a matematicko-fyzikální modul[14]. Také nebylo řešeno, kolik modulů stejného typu a které moduly poběží dohromady. V jedné spuštěné instanci aplikace (tedy v jedné spuštěné simulaci) je vždy právě jedna instance vizualizačního modulu a právě jedna instance matematického modulu. Život simulace a komunikace mezi částmi prototypu vypadají následovně[14, kap 3.2.2]: • Vytvoření scény Autor sestaví scénu z různých objektů (planet, raket, družic, vesmírných stanic) buď v libovolném textovém editoru (scéna je v XML formátu), nebo v editoru scény. • Inicializace simulace Uživatel spustí grafický modul, ten načte vloženou scénu a z databáze objektů si případně stáhne data příslušející konkrétním objektům (např. hmotnost Země). Poté se pomocí TCP (potřebujeme jistotu, že data dorazí) připojí k matematicko-fyzikálnímu modulu a pošle mu fyzikální data scény. Oba moduly si svá data uloží do svých struktur. • Běh simulace Simulace běží v reálném čase. S každým snímkem (kterých je 25 za sekundu) matematickofyzikální modul vypočte nové souřadnice pohybujících se objektů a pošle je pomocí UDP packetu (chceme rychlost a plynulost) vizualizačnímu modulu. Vizualizační modul hlídá vstupy uživatele a při změnách parametrů scény (např. tahu a směru raket) odešle zprávu pomocí TCP (uživatel zasahuje do scény, chceme jistotu, že zpráva dorazí) matematicko-fyzikálnímu modulu.
5
6
KAPITOLA 2. ANALÝZA ZADÁNÍ
Obrázek 2.1: Prvotní myšlenka architektury aplikace Mantichora
Formát a obsah packetů posílaných mezi vizualizačním a matematicko-fyzikálním modulem[14, kap 3.2.3 a přílohy A a B] je binární a je šitý na míru konkrétním druhům objektů (planet, raket, družic, vesmírných stanic), které se ve scéně nacházejí. Simulovaná scéna je popsána XML souborem, který obsahuje grafické, vizualizační a matematicko-fyzikální informace o jednotlivých objektech umístěných ve scéně.[9, kap 4.3]
2.2
Závěry z prvního roku vývoje
Z funkčního prototypu z prvního roku bylo získáno několik cenných poznatků a zkušeností, což byl jeho účel. Z nich také plyne další směr vývoje. Některé části funkčního prototypu budou využity, jiné úplně přepsány nebo nahrazeny.
2.2.1
Hodnocení komunikačního modelu prototypu
Největším problémem prototypu je použitý způsob návrhu. Navrhovalo se od konkrétních záležitostí směrem k obecným. Příkladem budiž návrh komunikačního schématu. Nejprve
2.2. ZÁVĚRY Z PRVNÍHO ROKU VÝVOJE
7
byl vytvořen vzorový XML popis konkrétní scény. Z něj byly vytvořeny parsovací algoritmy v modulech a DTD. A potom byl bez náznaku přesného postupu vytvořen komunikační protokol přímo šitý na míru konkrétnímu DTD a konkrétnímu uspořádání modulů. Tento postup není příliš optimální [8, kap 7.1]. Jeho výsledkem je aplikace, která má malou rozšiřitelnost a univerzálnost. Lze sice vylepšovat její jednotlivé moduly, ale přidání nových funkčností (např. nových druhů prvků scény nebo modulů) vyžaduje rozsáhlé netriviální úpravy. Problém má hlavní příčinu v tom, že se v prvním roce nikdo nevěnoval návrhu komunikace jako hlavnímu tématu své práce1 , a komunikační model tedy postrádal ucelenější koncepci. Přitom komunikační model je nutný základ, bez kterého nelze pokračovat. Proto bylo učiněno rozhodnutí, že je třeba začít projekt Mantichory řešit globálně a že vznikne celý tým, který se bude komunikační problematikou zabývat. Práce na komunikačním schématu bude probíhat ještě několik let a z počátku budou její výsledky spíše teoretického rázu.
2.2.2
Potřeba zobecnění
Po vytvoření prototypu byla také vyslovena myšlenka rozšíření Mantichory či jejích částí k simulaci nebo vizualizaci i jiných dějů či struktur než dějů ve sluneční soustavě [14, kap 6.3], např. neuronových sítí nebo létání [9, kap 8.1]. Aby bylo možné takto Mantichoru rozšířit, je třeba takové simulované světy umět popsat. Existují dvě rozdílné cesty: a) Rozšířit stávající jazyk scény a komunikační protokol tak, aby zahrnoval co největší množinu možných objektů a událostí. Výhodami jsou jednorázový návrh jazyka a menší počet úrovní, nevýhodami jsou přehlcení uživatele velkým množstvím příkazů a obtížnější a pracnější rozšiřitelnost jazyka. b) Vytvořit metajazyk, kterým bude možné definovat pojmy, se kterými se v daném světě operuje. Tento popis potom stanoví základ pro ostatní části aplikace, které bude možné pomocí jasně daných postupů jednoduše sestavit. Výhodami jsou přesné vymezení pojmů, se kterými bude pracovat uživatel a snadná rozšiřitelnost jazyka, nevýhodami jsou vyšší počet návrhových úrovní, nutnost vytvoření speciálních modulů pro každý svět a roztříštěnost popisu scén a objektů. Možnost a jsme vyloučili, protože touto cestou se vydalo příliš mnoho podobných projektů (viz. kapitola 3 na straně 11). Zvolená varianta b se jeví zajímavější a učiní z Mantichory nástroj k tvorbě simulátorů. Návrh metajazyka pro popis libovolného (v rámci potřeb projektu) světa a jeho zákonitostí a sestavení postupů k vytvoření příslušných částí aplikace jsou cíli této bakalářské práce. Každý svět popsaný tímto metajazykem vyjádří požadavky na části aplikace a bude podkladem k vytvoření či doplnění jednotlivých modulů a nástrojů. Také poslouží jako podklad pro předpis pro zápis scény, díky čemuž bude potom možné sestavit scénu. 1
Někdo měl na návrhu komunikace pracovat, ale jak se zdá, dotyčný z projektu vypadl. O pozici „síťového projektanta“ se zmiňuje ve své práci Jiří Nekola.[14, kap 2.4.2]
8
2.3
KAPITOLA 2. ANALÝZA ZADÁNÍ
Současný stav vývoje nové architektury
Aby měl jazyk pro popis světa význam, bylo třeba v rámci týmu prodiskutovat a vyřešit i další obrysy aplikace. Ty budou více rozepsány v závěrečných pracích ostatních členů týmu, kteří se jim budou věnovat hlouběji.
2.3.1
Modulární struktura aplikace
Běžící aplikace Mantichora (viz obr. 2.2 na str. 8) se skládá z jedné nebo více simulačních jednotek běžících na oddělených strojích. Každá simulační jednotka obsahuje jádro a k němu jeden nebo více připojených modulů. Simulační jednotky mezi sebou komunikují prostřednictvím komunikačních modulů. Sestava modulů v simulační jednotce není pevně dána, ale ovlivňuje funkčnost aplikace (např. bez dostupného interakčního modulu v alespoň jedné simulační jednotce nepoběží simulace).
Simulační jednotka
Simulační jednotka
Datový modul
Komunikační modul
Komunikační modul
jádro Mat.-fyz. modul
Vizualizační modul Nemusí být všechny přítomny
Obrázek 2.2: Modulární struktura aplikace Jádro propojuje komunikaci mezi jednotlivými moduly a stará se o její směrování. Také si udržuje přehled o připojených modulech a jejich rozhraních. Komunikační moduly propojují simulační jednotky. Jejich úkolem je směrování dat mezi jádrem simulační jednotky a komunikačními moduly ostatních simulačních jednotek. Interakční modul provádí interakce mezi objekty ve scéně a stará se o výpočty jejich veličin. Vizualizační modul zobrazuje simulovanou scénu na obrazovce uživatele.
2.4. POŽADAVKY NA JAZYK PRO POPIS SVĚTA
2.3.2
9
Zamýšlený způsob práce s Mantichorou
Vytvoření jazyka pro popis světů umožní vytváření různých obměn Mantichory pro různá odvětví a použití, Mantichora se tedy stane spíše nástrojem pro vytváření různých simulací. Postup vytvoření simulace v aplikaci Mantichora je shrnut na obrázku 2.3 na straně 9. Editor světů
Generátor
MWD
MSDL
Popis světa
Moduly
Jazyk scény
MSD Kostry modulů
Editor scény
Editor objektů
Scéna
Simulace
MDB Databáze objektů
Obrázek 2.3: Postup vytvoření simulace v projektu Mantichora
Očekává se, že vznikne tzv. editor světů, který umožní členům budoucí komunity okolo Mantichory vytvářet vlastní světy, které budou zveřejněny na komunitním serveru. Editor světů bude obsahovat generátor, který zkontroluje a zpracuje zadaný popis světa a vytvoří pravidla pro popis scény, rozhraní modulů aplikace a případné další soubory. Členové komunity potom dotvoří těla rozhraní (vygenerovaná rozhraní jsou jenom jejich kostry) a sestaví scény odpovídající danému světu. Na pomoc jim přijde jimi spravovaná databáze objektů, ze kterých budou moci scénu poskládat. Dále vytvoří scénáře, což jsou rozšíření scény o konkrétní simulované události nebo aktivity a ovládací prvky (např. scénou je sluneční soustava, scénářem může být přistání Apolla 11, let sondy Voyager nebo bitva s Borgy o sektor 001). Po vytvoření modulů a scény je odnož Mantichory připravena ke spuštění simulace. Ta může probíhat na jednom nebo více strojích.
2.4
Požadavky na jazyk pro popis světa
Z výše uvedeného účelu jazyka pro popis světa vyplývají tyto základní požadavky: • Obecnost Jazyk musí zvládnout co nejblíže charakterizovat daný svět s použitím co nejmenší množiny příkazů.
10
KAPITOLA 2. ANALÝZA ZADÁNÍ
• Univerzálnost Jazykem musí být možné popsat co nejvíce možných myslitelných světů. • Zpracovatelnost Ze světa popsaného tímto jazykem musí být možné automaticky vygenerovat potřebné části aplikace, které se scénami z daného světa mají pracovat.
Kapitola 3
Přehled existujících formátů popisu světů V následující kapitole uvedu přehled způsobů (formátů), kterými jiné osoby či projekty popisují svět a jeho zákonitosti. Většina formátů, na které jsem narazil, je jednostranně zaměřených na určitý obor lidského konání a specifikují spíše scénu, než svět1 . Nalezené nástroje a formáty jsem rozdělil do několika kategorií podle jejich primárního využití.
3.1
Matematické modely
Matematické modely obecně umožňují simulovat libovolný systém díky přímým popisům celého systému a jeho jednotlivých částí pomocí rovnic. Univerzálnost jejich použití pramení z velkého množství matematických funkcí a nástrojů.
3.1.1
MATLAB
Softwarové prostředí MATLAB (MATrix LABoratory) a stejnojmenný skriptovací programovací jazyk založený na jazyce Fortran jsou určeny pro vědeckotechnické numerické výpočty, modelování a počítačové simulace. MATLAB používá numerických metod a matic. Výrobcem MATLABu je firma The MathWorks. Simulační prostředí i jazyk obvykle slouží jako základ pro jiné simulační systémy.[3]
3.1.2
Simulink
Simulační systém Simulink umí simulovat dynamický systém sestavený z různých bloků, které jsou součástí rozsáhlé knihovny bloků. Sestavení a propojení bloků je ulehčeno díky grafickému editoru blokových schémat. Systém obsahuje řadu analytických a ladicích nástrojů a je nástavbou systému MATLAB, s jehož pomocí lze definovat nové bloky.[5] 1
mám-li se držet terminologie nasazené v předešlé kapitole
11
12
KAPITOLA 3. PŘEHLED EXISTUJÍCÍCH FORMÁTŮ POPISU SVĚTŮ
Obrázek 3.1: Simulink – schématický popis simulace vnitřní sluneční soustavy.3 Parametry vesmírných objektů zadané vlevo dole jsou svedeny do bloku, který počítá jejich jednotlivá gravitační zrychlení a polohy. Tyto výsledky jsou vyvedeny jako polohy do vizualizačního bloku na pravé straně schématu. Rychlosti otáčení jsou počítány zvlášť a také přivedeny do vizualizačního bloku.
3.1.3
DYNAST
DYNAST je software původem z ČVUT, který dovoluje vytvářet a počítat matematické modely bez nutnosti znát simulační jazyk pomocí grafických dialogů. Matematické modely dynamických soustav jsou popsány pomocí soustav rovnic, které lze vygenerovat z grafického schématu utvořeným z různě propojených bloků. Modely lze propojit s programy MATLAB a Simulink.[1] Systém DYNAST je velmi podobný výše uvedenému Simulinku, taktéž obsahuje rozsáhlou knihovnu bloků, ať už čistě matematických (např. sčítačka, odčítačka, násobička, integrátor), fyzikálních (např. rezistor, pružina, působiště síly), nebo modelů reálných komponent (např. tranzistory, hydraulické komponenty, motory, PID řídící prvky). Vizualizace využívají VRML nebo animačního nástroje DYNASTu.[10] 3
Zdroj obrázku: MathWorks, ukázky použití Simulinku; URL: http://www.mathworks.com/products/ 3d-animation/demos.html?file=/products/demos/3d-animation/vr1/solar.html
3.2. KONSTRUKTÉRSTVÍ
13
Obrázek 3.2: DYNAST – experiment s raketou spalující palivo.5 Ve schematu jsou z růžové rakety I1 vyvedeny veličiny popisující chování rakety – hmotnost paliva, tah trysek, gravitační zrychlení. Vpravo jsou výsledky simulace – průběhy rychlosti rakety, výškové polohy rakety, tahu trysek, hmotnosti rakety a gravitačního zrychlení působícího na raketu.
3.2
Konstruktérství
Formáty používané v konstruktérství jsou zaměřeny na co nejbližší popsání konstruovaného objektu (budovy, strojního zařízení). K tomu obvykle využívají velice široké škály konstrukčních prvků organizovaných v obrovských knihovnách. Formát není příliš určen k simulaci, protože cíli jsou spíše popis, evidence a vizualizace.
3.2.1
IFC
Datový model IFC (Industry Foundation Classes) je objektově orientovaný formát vyvinutý firmou buildingSMART k zajištění interoperability ve stavebním průmyslu. Formát IFC je otevřený a standardizovaný normou ISO/PAS 16739. Dánská vláda jej uzákonila jako povinný formát pro veřejné stavební projekty.[2] 5
Zdroj obrázku: Prezentace pana Ševčenka.[10]
14
KAPITOLA 3. PŘEHLED EXISTUJÍCÍCH FORMÁTŮ POPISU SVĚTŮ
Modulární formát IFC je členěn do čtyř vrstev:[12] • Resource layer (vrstva zdrojů) Nejnižší vrstva; obsahuje základní pojmy, jako např. hmotnost, rozměr, cena, množství, datum a čas. Tyto základní pojmy nejsou spjaty se stavebnictvím. • Core layer (jádrová vrstva) Obsahuje pojmy typické pro organizaci práce, jako např. aktér, skupina a proces. Dále obsahuje základní stavební pojmy jako např. prostor, místo, budova, prvek budovy a další moduly přidávají pojmy jako úkol, rozvrh prací atd. • Interoperability layer (vrstva interoperability) Definuje obecné prvky používané ve stavebnictví, jako např. zeď, sloup, traverza, dveře. • Domain layer (doménová vrstva) Nejvyšší vrstva; zahrnuje konkrétní prvky toho kterého oboru činnosti, např. boiler, chladič, umyvadlo, vypínač, světlo atd. Moduly procházejí napříč vrstvami a rozšiřují výčet pojmů/objektů definovaných v jednotlivých vrstvách. Objekty ve vyšších vrstvách jsou definovány pomocí objektů ve stejné či nižších vrstvách.
3.3
Virtuální realita
Jazyky virtuální reality se typicky zaměřují na grafickou stránku simulace. Nepoužívají žádné rozsáhlé databáze stavebních prvků, ale modelují je jako geometrické objekty. Světy virtuální relity jsou interaktivní, světy virtuální reality tedy mívají i nějakou formu popisu fyzikálních zákonů.
3.3.1
VRML
VRML (Virtual Reality Modelling Language) je jazyk určený k popisu virtuální reality. Zaměřuje se na popis třírozměrné geometrie scény. Interakce fungují za pomoci senzorů (např. dotykových – TouchSensor), událostí, tras (routes) a interpolátorů, které umožňují provádět jednoduché úpravy vlastností objektů ve scéně.[6][16] Do scény lze také přidat libovolný skript v jazyce JavaScript nebo Java[6], čehož se využívá k rozšíření VRML na nástroj vizualizace soustav simulovaných v matematických modelech. Scéna zapsaná v jazyce VRML je hierarchická a syntaxe jazyka – původem z Open Inventoru – připomíná složenými závorkami skládání bloků v mnoha programovacích jazycích, např. C.[16]
3.4. SHRNUTÍ
3.3.2
15
X3D
Formát X3D postupně vytlačující VRML je jeho ideovým nástupcem. Jedná se především o VRML převedené do XML podoby. Výhodou X3D oproti VRML je jeho rozšiřitelnost6 . Norma však připouští i starší VRML syntaxi (označovanou jako VRML 97) a existuje i binární formát.[7] X3D zahrnuje některá rozšíření VRML, např. podporu NURBS nebo humanoidních pohybů.[7]
3.4
Shrnutí
Výše uvedené jazyky a formáty představují výřez z toho, co je dnes na světě k dispozici. Pokoušel jsem se najít projekt podobný Mantichoře řešící podobný problém způsobem podobným tomu, kterým jsme se rozhodli vydat my (metajazyk pro popis světů, viz varianta b v kap. 2.2.2 na str. 7). Bohužel musím konstatovat, že jsem byl při hledání podobného projektu neúspěšný, a proto je třeba navrhnout zcela vlastní jazyk. Přesto jsou uvedené projekty dobrou inspirací.
6
což pramení z vlastností XML
16
KAPITOLA 3. PŘEHLED EXISTUJÍCÍCH FORMÁTŮ POPISU SVĚTŮ
Kapitola 4
Návrh jazyka pro popis světa V této kapitole navrhnu jazyk pro popis světa, který splňuje požadavky uvedené výše v kapitole 2.4 (str. 9). Shrnu základní principy simulace v projektu Mantichora, popíši jazyk a uvedu několik příkladů popisu světa.
4.1
Základní principy a pojmy světa v Mantichoře
Navrhovaný jazyk MWDL (Mantichora World Definition Language) člení zákonitosti světa do několika rovin. Nejdůležitější částí je rovina objektů a interakcí; zde se odehrává vlastní simulace. Ostatní roviny jsou podpůrné a doplňují svět o další pravidla.
4.1.1
Objekt
Objekt definuje pojem simulovaného světa. Představuje strukturovaný datový typ, případně druh vizualizovatelného simulovaného prvku scény. Každý objekt má své typické vlastnosti – položky. Objekty je možno dědit, což znamená, že každý objekt může převzít definici položek z jednoho, nebo i více rodičovských objektů. Objekty lze také zanořovat, a to pomocí položky, jehímž typem je zanořovaný objekt.
4.1.2
Interakce
Interakce poskytují nástroj k popisu vztahů mezi objekty. Každá interakce zahrnuje několik (obvykle 2, může však i 1 nebo více) stran – objektů. Zahrnutý objekt zastává v interakci jasně určenou roli označenou jednoznačným názevm. U každého zahrnutého objektu se pro příslušnou interakci uvažují jen zadané parametry, čímž lze zmenšit množství přenášených dat. Jedna strana může představovat i všechny objekty daného typu, což je výhodné pro interakce probíhající mezi blíže nespecifikovaným množstvím stejných objektů. Interakce jsou dvojí — implicitní a explicitní. Implicitní jsou generovány automaticky Mantichorou (při inicializaci scény) pro všechny přípustné kombinace vstupujících objektů. Explicitní musí zadat autor scény. Jednotlivé interakce jsou seskupovány do bloků, které umožňují určit jejich pořadí výpočtu.
17
18
KAPITOLA 4. NÁVRH JAZYKA PRO POPIS SVĚTA
V průběhu simulace jsou interagující objekty odesílány interakčnímu modulu, který provede výpočty a případně změní parametry interagujících objektů.
4.1.3
Integritní omezení
Integritní omezení popisují podmínky, které musí parametry objektů splňovat, aby byla daná scéna utvořena podle pravidel popisovaného světa. V současné fázi vývoje projektu mají pouze informativní charakter.
4.2
Popis jazyka pro popis světů
MWDL je založen na XML a je definován pomocí DTD (viz příloha C na str. 49). Veškerá klíčová slova v jazyce jsou z praktických důvodů psána anglicky. Strukturu jazyka stručně vyjadřuje obr. 4.1.
