Ž ILINSKÁ U NIVERZITA V Ž ILINE
FAKULTA RIADENIA A INFORMATIKY
D IPLOMOVÁ PRÁCA
Študijný odbor: Informaˇcné a riadiace systémy
Michal Rybárik
Grafická manipulácia s topologickými
údajmi budov
Vedúci: doc. Ing. Penka Martincová, PhD.
Reg.ˇc. 78/2013
Máj 2014
Abstrakt
RYBÁRIK M ICHAL : Grafická manipulácia s topologickými údajmi budov [Diplomová práca]
Žilinská Univerzita v Žiline, Fakulta riadenia a informatiky, Katedra informatiky.
Vedúci: doc. Ing. Penka Martincová, PhD.
Stupeˇn odbornej kvalifikácie: Inžinier v odbore Informaˇcná systémy, Žilina.
FRI ŽU v Žiline, 2014 — 72 s.
Ciel’om diplomovej práce je na základe analýzy grafických technológií a grafických
formátov, vytvorit’ nástroj zameraný na hodnotenie bezpeˇcnostných systémov budov.
Aplikácia musí umožˇnovat’ tvorbu topológie budovy spolu s jej bezpeˇcnostnými prvkami a
ich priamu interakciu s užívatel’om. Z takto vytvorenej topológie je možné získat’ najkratšiu
cestu k zabezpeˇcovanému objektu v budove a následne ju zobrazit’.
Abstract
RYBÁRIK M ICHAL : Graphical manipulation of topological data of buildings [Diploma
thesis]
University of Žilina, Faculty of Management Science and Informatics, Department of
Informatics.
Tutor: Assoc. Prof. Ing. Penka Martincová, PhD.
Qualification level: Engineer in field Information systems, Žilina:
FRI ŽU v Žiline, 2014 — 72 p.
The aim of the diploma thesis is following of analysis of graphics technology and graphical
formats to create an instrument focused on the evaluation of security systems of buildings. The
application must allow the creation of topology building, together with its security elements
and their direct interaction with the user. The application can get the shortest path to the
security object from formed topology in the building and then display it.
Prehlásenie
Prehlasujem, že som túto diplomovú prácu napísal samostatne a že som uviedol všetky použité
pramene a literatúru, z ktorých som cˇ erpal.
V Žiline, dˇna 16.4.2014
Michal Rybárik
Pod’akovanie
ˇ
Dakujem
doc. Ing. Penke Martincovej za jej ochotu a cenné rady, ktorými ma usmerˇnovala
poˇcas písania tejto diplomovej práce.
Obsah
Úvod
5
1
Analýza úlohy
6
2
Grafické formáty
9
2.1
Typy grafických formátov . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2
Vektorovo orientované formáty . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.1
CAD formáty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.2
2D kresliace formáty . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.2.3
3D modelovacie formáty . . . . . . . . . . . . . . . . . . . . . . . .
18
3
4
Java a 3D grafika
22
3.1
Java ako platforma aj jazyk . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2
Mýtusy o Jave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.3
Tvorba 3D grafiky v Jave . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3.1
Open Graphics Library - OpenGL . . . . . . . . . . . . . . . . . . .
26
3.3.2
Priame väzby Javy na OpenGL . . . . . . . . . . . . . . . . . . . . .
27
3.3.3
API pre prácu s grafom scény . . . . . . . . . . . . . . . . . . . . .
28
3.3.4
Zhrnutie jednotlivých možností . . . . . . . . . . . . . . . . . . . .
32
Vyhl’adanie kritickej cesty
33
4.1
Budova ako graf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.1.1
34
Základné pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4
4.1.2
4.2
5
Transformácia na graf . . . . . . . . . . . . . . . . . . . . . . . . .
35
Algoritmy pre hl’adanie najkratšej cesty . . . . . . . . . . . . . . . . . . . .
36
4.2.1
Dijskstrov algoritmus . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2.2
Algoritmus A* . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.2.3
Floyd-Warshallov algoritmus . . . . . . . . . . . . . . . . . . . . . .
38
Návrh a implementácia riešienia
40
43section.5.1
5.2
Vizualizácia budovy a jej editor (visualization) . . . . . . . . . . . . . . . .
45
5.3
Užívatel’ské rozhranie(guiFx) . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.4
Vyhl’adanie kritickej cesty(pathFinder) . . . . . . . . . . . . . . . . . . . .
57
6
Záver
58
7
Dokumentácia používatel’a
59
7.1
Spustenie aplikácie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
7.2
Štruktúra aplikácie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
7.3
Navigácia v scéne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
7.4
Konštrukcia budovy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
7.5
Nájdenie kritickej cesty . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
Literatúra
71
Úvod
Moderné spoloˇcnosti pri ochrane svojho majetku investujú nemalé finanˇcné zdroje do
zabezpeˇcenia budov. Analýza zabezpeˇcenia priestorov budovy je tvorená zväˇcša priamo v
technickom pláne budovy, ktorý obsahuje použité zabezpeˇcovacie komponenty v
dverách,oknách a podobne. Avšak nie je z neho jednoduché urˇcit’, akú najkratšiu dobu bude
prípadný páchatel’ potrebovat’ na prelomenie zabezpeˇcenia k danému miestu a aké ochranné
systémy tým naruší.
Po preskúmaní súˇcasného stavu na trhu, neexistuje dostupný nástroj na takúto analýzu
použitých bezpeˇcnostných prostriedkov. Úlohou práce je takýto nástroj navrhnút’ a
implementovat’ v programovacom jazyku Java. Editor bezpeˇcnostných prvkov a databázový
model bol vytvorený v projektovej výuˇcbe1 inými študentami, preto sa nimi nebudem v tejto
práci zaoberat’, no aplikácia bude s týmito modulmi spolupracovat’.
V prvej kapitole popíšem potreby aplikácie a jej charakteristické cˇ rty. V druhej kapitole
preskúmame rôzne grafické formáty pre zobrazovanie dvojrozmerných a trojrozmerných
objektov, priˇcom sa zameriame na formáty s vektorovým charakterom. Tretia kapitola
pojednáva o možnostiach tvorby priestorovej grafiky využitím programovacieho jazyka Java.
Hl’adaním najkratších ciest sa zaoberá štvrtá kapitola. Tá pre riešenie tejto úlohy používa
matematický aparát teórie grafov, z ktorej sú popísané základné algoritmy hl’adania
najkratších ciest. Piata kapitola prestavuje praktickú cˇ ast’. V nej navrhnem a implementujem
dátovú a aplikaˇcnú vrstvu programu. Šiesta kapitola predstavuje záver diplomovej práce, po
ktorej nasleduje dokumentaˇcná príruˇcka k vytvorenej aplikácií.
1 Expertný
systém pre hodnotenie bezpeˇcnostných systémov ochrany objektov
5
Kapitola 1
Analýza úlohy
Ako bolo v úvode naˇcrtnuté, úlohou práce je vytvorit’ aplikáciu na hodnotenie
bezpeˇcnostných prvkov v budove. Pre možné nedorozumenie je na mieste podotknút’, že sa
jedná o hodnotenie bezpeˇcnostných prvkov budovy s pohl’adu ich pevnosti a odolnosti voˇci
mechanickému narušeniu. Pohybové alebo zvukové senzory spúšt’ajúce alarm, nie sú
záujmom aplikácie.
Dôležitou vlastnost’ou budovy je jej hierarchický charakter. Vd’aka nemu je výhodné
reprezentovat’ budovu vo vnútornej pamäti poˇcítaˇca pomocou rôznych stromových štruktúr.
Pre uchovanie dát budovy v databáze bola vytvorená študentami z projektu ’Expertný systém
pre hodnotenie bezpeˇcnostných systémov ochrany objektov’ databáza1 , ktorej model je
zobrazený na obrázku 1.1.
Koncept modelu je tvorený z dvoch cˇ astí : topologickej a bezpeˇcnostnej. Preto aj
informácie uložené v databáze delíme na bezpeˇcnostné, ktoré popisujú dvere, okná ... a
topologické, urˇcujúce tvar budovy. Štruktúra budovy je hierarchicky cˇ lenená z poschodí,
miestností a stien, priˇcom základným stavebným prvkom je plocha. Plocha predstavuje
priestorový prvok, na ktorý sú mapované bezpeˇcnostné prvky. Tie nesú už konkrétnu
informáciu o použitých materiáloch, odolnosti cˇ i typu.
1 Implementovaná
objektovo-relaˇcným databázovým systémom PostgreSQL
6
7
Databázové úložisko je pri práci viacerých expertov dobré riešenie zdiel’ania informácií.
Avšak v prípade nefunkˇcného spojenia s databázou, je na mieste disponovat’ možnost’ou
súborového zálohovania. Typy a možnosti súborových formátov budú podrobnejšie popísané
v nasledujúcej kapitole. Na základe získaných informácií, vytvorím vlastný formát pre
lokálne uloženie dát do súboru.
Tvorbu štruktúry budovy, ako aj pridávanie cˇ i odoberanie bezpeˇcnostných prvkov, má
umožˇnovat’ editor. Pre zjednodušenie práce konštruktéra, editor naˇcíta pôdorys budovy,
alebo podobný podkladový náˇcrt, podl’a ktorého je umožnené expertovi vytvorit’ jednotlivé
cˇ asti budovy. Zmenou súˇcasnej konštelácie použitých zabezpeˇcovacích prvkov sa ovplyvˇnuje
celkové zabezpeˇcenie budovy. Po vykonaných úpravách je úˇcelné zistit’ prípadnú najkratšiu
trasu k miestu záujmu. Z toho dôvodu má program na základe okolitých zabezpeˇcovacích
prostriedkov poskytnút’ túto najkratšiu trasu. Následne je dobré túto cestu ju vyznaˇcit’ spolu
s bezpeˇcnostnými prvkami ktoré boli prekonané. Možnost’ami nájdenia najkratšej cesty sa
budeme zaoberat’ v štvrtej kapitole.
Bežne je budova tvorená viacerými poschodiami, cˇ o zvýrazˇnuje zohl’adnit’ aj výškový
aspekt budovy. Preto je trojrozmerná priestorová reprezentácia budovy ovel’a prirodzenejšia
ˇ je vôbec
ako len jej náˇcrt pôdorysu a poskytuje expertovi celkový komplexnejší prehl’ad. Ci
možné efektívne tvorit’ trojrozmernú grafiku, založenú na platforme Java, si rozoberieme v
tretej cˇ asti.
8
Obr. 1.1: Vytvorený databázový model
Kapitola 2
Grafické formáty
Pre úˇcely aplikácie je nutné poznat’ štruktúru zabezpeˇcovanej budovy. Model budovy možno
vytvorit’ v externom editore a následne ho poskytnút’ aplikácií v príslušnom formáte.
Informácie o zložení a štruktúre budovy sú potom obsiahnuté v súbore ako grafické dáta, tie
získame interpretáciou daného grafického formátu z jeho špecifikácie.
Doposial’ bolo vytvorených nespoˇcetne vel’a rôznych grafických formátov. Ich vývoj
nastal z dôvodu cˇ oraz väˇcšej potreby efektívne ukladat’ a prenášat’ grafické dáta. Niektoré
formáty vznikli za bránami komerˇcných spoloˇcností a ich špecifikácie nie sú zd’aleka
kompletné, iné poskytujú vel’mi dobrú a zrozumitel’nú dokumentáciu. Mnohé z nich už nie
sú aktuálne, avšak svojimi nedostatkami inšpirovali tvorcov tých nových.
2.1
Typy grafických formátov
Vo všeobecnosti môžeme rozdelit’ grafické súbory podl’a spôsobu ako ukladajú grafické dáta.
Na základe toho delíme grafické súbory na :
• bitmapové1 (JPEG, PNG, TIFF, BMP, RAW . . . ),
• vektorové (SVG, CDR , DXF . . . ),
• metasúborové ( WMF, CGM . . . ).
1 Taktiež
sa používa názov rastrové
9
10
Bitmapové súbory ukladajú bitmapové dáta a vektorové zasa vektorové dáta, akými sú
geometrické tvary. Metasúborové formáty uchovávajú bitmapové a vektorové dáta v jednom
súbore.
Okrem týchto základných formátov existujú d’alšie typy ako scénové, multimediálne a
animaˇcné formáty. Bližšie sa budem zaoberat’ bitmapovými a vektorovými formátmi, no pre
úplnost’ zhrniem podstatu aj týchto odvodených typov.
Scénové, animaˇcné a multimediálne formáty
Scénové formáty 2 sú používané pre ukladanie obrazovej predlohy, alebo scény, ktorú poˇcítaˇc
následne použije pri rekonštrukcií pôvodnej predlohy. Rozdiel oproti vektorovým súborom je
v tom, že scénové formáty ukladajú konkrétne inštrukcie, ktoré program používa pre
znázornenie scény. Nesporný je fakt, že urˇcit’ presnú hranicu medzi vektorovým a scénovým
formátom je nel’ahké a cˇ asto je to aj vec vkusu.
Základnou myšlienkou animaˇcných formátov je princíp pohyblivých knižiek, kde je
pohyb vytvorený ako ilúzia, vd’aka rýchlemu otáˇcaniu stránok. Takisto aj pri animácií jeden
obrázok strieda d’alší, cˇ oho výsledkom je plynulý pohyb. Najzákladnejšie animaˇcné formáty
majú uložené všetky predlohy, ktoré sú potom postupne zobrazované a to cˇ asto v cykle. Tie
pokroˇcilejšie ukladajú len jednú obrazovú predlohu, spolu s viacero farebnými mapami,
ktoré sa v predlohe menia. Moderné animaˇcné formáty ukladajú iba rozdieli medzi
nasledujúcimi snímkami.
Relatívne nové formáty grafického charakteru sú multimediálne súbory. Dáta v týchto
súboroch obsahujú obrázky, zvuk, text, video alebo poˇcítaˇcové animácie. Multimediálne
súbory nedefinujú nové metódy uchovania týchto dát, avšak poskytujú možnost’ ich uložit’ v
jednom alebo viacerých štandardných formátoch[1].
2 Známe
sú aj ako formáty pre popis scény
11
Bitmapové formáty
Bitmapové súbory sa skladajú z obrazových bodov, ktoré spolu tvoria dvojrozmernú mriežku,
nazývanú aj raster. Každý bod mriežky si uchováva pozíciu a farbu. Vytovrený obraz je tým
viac kvalitnejší, cˇ ím väˇcšiu mriežku použijeme a cˇ ím viac bitov použijeme pre reprezentáciu
farby3 .
Grafika v bitmapových súboroch sa získava procesom rastrovania, kedy pomocou
zariadenia ako skenera cˇ i kamery snímame predlohu, cˇ ím vznikne hrubý formát. Tento
formát je zložený len z dát a neobsahuje žiadne informácie o ich štruktúre. Bitmapové
súbory sa skladajú z hlaviˇcky, bitmapových dát a použitej farebnej palety[1].
Vektorové formáty
Bitmapové súbory mapujú predlohu bod po bode, tie môžu bit’ v prípade potreby
rekonštruované zobrazovacou aplikáciou. Vektorové súbory obsahujú matematické formuly
pre popis predlohy. Rozdiel teda spoˇcíva v popise objektov scény a nie bodových hodnôt.
Matematický spôsob vyjadrenia objektov scény definuje tvar a polohu kriviek spolu s
d’alšími informáciami ako hrúbka cˇ i farba.
Vektorový formát v sebe zah´rnˇ a objekty, ktoré sú tvorené z menších, jednoduchších
objektov. Rozlíšenie súboru je potom dané detailnost’ou matematického opisu, priˇcom
výstupné rozlíšenie nie je až tak závislé na vstupnom rozlíšení, ako u bitmapových súboroch.
Výhodou takýchto súborov je ich relatívne malá vel’kost’ a možnost’ l’ahkej manipulácie bez
straty kvality. Ich tvorba nemusí zahrˇnovat’ dokonca ani špeciálny editor, jednoducho postaˇcí
textový zápis daných prvkov. Vektorový formát ma oproti rastrovému navrch vo viacerých
aspektoch, no nehodí sa na reprezentáciu príliš zložitých predlôh, ako napríklad pre
fotografiu, kde sa hodnota obrazových bodov mení z bodu na bod[1].
3 Oznaˇ
cuje
sa ako farebná h´lbka
12
Obr. 2.1: Zl’ava vektorová a rastrová reprezentácia
2.2
Vektorovo orientované formáty
Reprezentovat’ cˇ asti budovy ako hodnoty bitmapovej mriežky je celkom nepohodlné, ked’že
je nutné obsiahnut’ viac druhov informácií. Okrem topológie budovy rozoznávame aj použité
prvky, materiály, výrobcov bezpeˇcnostných prvkov a d’alšie, pre ktoré by bolo nutné použit’
viacero významových mriežok na ich zaznamenanie. Avšak pri použití vektorového zápisu
môžeme všetky tieto charakteristiky priradit’ objektu v scéne, preto je vektorový formát
vhodnejší pre reprezentáciu priestorových modelov, ako napríklad pre model budovy.
ˇ
Dalej
si priblížime vybrané vektorové formáty. Tie sa dajú kategorizovat’ podl’a oblasti
využitia na :
• CAD4 formáty - pre 2D a 3D projektovanie a konštrukciu,
• 3D modelovacie formáty - pre 3D modelovanie a animáciu objektov a scén,
• 2D kresliace formáty - pre popis všeobecnej dvojrozmernej grafiky, cˇ i už statickej alebo
animovanej.
2.2.1
CAD formáty
CAD alebo poˇcítaˇcom podporované projektovanie je odbor, využívajúci poˇcítaˇcové grafické
technológie pre navrhovanie a dokumentáciu projektov v oblasti architektúry, geodézie a
stavebníctva. CAD programy využívajú vektorový popis pre 2D a 3D objekty, za úˇcelom
digitálnej reprezentácie konštruovaných objektov. Ich výstupom sú väˇcšinou výkresové
4 CAD
- Computer-Aided Design („poˇcítaˇcom podporovaný návrh“ )
13
dokumentácie v papierovej alebo elektronickej podobe, alebo 3D modely obsiahnuté v
príslušných grafických formátoch.
Pokroˇcilejšie špecializované CAD nástroje dokážu okrem vizualizácie realizovat’ aj
rôzne inžinierske analýzy a výpoˇcty. Tie sa zameriavajú skôr na konkrétny obor urˇcenia.
Všeobecné CAD programy poskytujú nástroje a funkcie použitel’né v akomkol’vek obore.
Najviac rozšíreným CAD aplikáciou je AutoCAD od firmy Autodesk. Jeho natívnym
formátom je proprietárny súborový formát DWG5 ,spolu s výmennou textovou formou
DXF6 [2].
AutoCAD DXF
Jedná sa o komplikovaný formát, hlavne preto, že bol vyvíjaný jedinou firmou a je už dost’
zastaralý. Navzdory tomu je vel’mi rozšírený pre výmenu CAD informácií. Existuje aj jeho
binárna verzia DXB7 , ktorá sa používa pre rýchlejšie naˇcítanie a je prispôsobená potrebám
AutoCAD-u[3].
Organizácia súboru
DXF súbor je rozdelený do sekcií, priˇcom každá zaˇcína svojím identifikátorom a konˇcí
znaˇckou konca sekcie. To je výhodne napríklad ked’ potrebujeme naˇcítat’ informácie len o
geometriách, program potom môže iné sekcie preskoˇcit’ a zaˇcat’ od konkrétneho miesta.
Sekcie delíme na :
• HEADER - Hlaviˇcka s premennými, ktoré obsahujú informácie platné pre celý výkres a
jeho nastavenia.
• CLASSES - Informácie o vytvorených triedach 8 .
• TABLES - Dáta tabuliek môžu obsahovat’ rôzne informácie ako o použitých textových
štýloch, type cˇ iar . . .
• BLOCKS - V tejto sekcií sú uložené bloky, cˇ o sú zlúˇcené entity pod jeden identifikátor,
5 DWG
- DraWinG
- Drawing Exchange Format
7 DXB – Drawing Exchange Binary
8 táto sekcia sa objavila až v novších verziách DXF
6 DXF
14
Entita
Popis
POINT
Bod, ktorý môže byt’ l’ubovol’ne natoˇcený zadaným uhlom
LINE
Úseˇcka zadaná dvoma dvoma bodmi
TRACE
Úseˇcka s nenulovou šírkou nazývaná aj stopa
POLYLINE
Spojená lomená cˇ iara, prípadne využívajúca spline krivky
TEXT
Textový ret’azec zadaný rotáciou, výškou . . .
CIRCLE
Kružnica zadaná stredom a polomerom
ARC
Kruhový oblúk zadaný stredom a dvoma ohraniˇcujúcimi uhlami
Tabul’ka 2.1: Grafické prvky DXF
• ENTITIES - Najobjemnejšia sekcia dát, ktorá obsahuje zápis jednotlivých grafických
entít.
• OBJECTS - Tu sú uložené informácie týkajúce sa negrafických entít.
• THUMBNAILIMAGE - V tejto sekcií je možné vložit’ náhl’ad na výkres.
• EOF- Znaˇcka reprezentujúca koniec súboru na poslednom riadku[4].
Zápis grafických prvkov
Medzi najˇcastejšie používané grafické entity patria hlavne geometrické útvary popísané
tabul’kou 2.1. Ku každej grafickej entite je pridružených niekol’ko cˇ íselných, alebo textových
parametrov. Najdôležitejšie z nich sú informácie o jej geometrií, ako jej pozícia, vel’kost’ . . . .
ˇ
Dalšie
všeobecné atribúty sú hladina9 v ktorej entita leží, štýl cˇ iar a farba. Tabul’ka 2.2
popisuje atribúty pre entitu LINE. Obrázok 2.2 predstavuje cˇ ast’ DXF súboru, v ktorej sa
definujú prvky pre vykreslenie. Ako ilustraˇcný príklad znázorˇnuje vykreslenie úseˇcky v
trojrozmernom priestore. Sekcia zaˇcína príznakom sekcie, za ktorou nasledujú entity a ich
parametre. Tie sú zapísané v tvare £íslo skupiny-nový riadok-hodnota parametra.
9 Hladiny
je možné napríklad vypnút’ alebo zmrazit’
15
ˇ
Císlo
skupiny
Popis
62
Farba entity
8
Oznaˇcenie hladiny
10
x-ová súradnica prvého bodu
20
y-ová súradnica prvého bodu
30
z-ová súradnica prvého bodu
11
x-ová súradnica druhého bodu
21
y-ová súradnica druhého bodu
31
z-ová súradnica druhého bodu
Tabul’ka 2.2: Atribúty pre entitu typu LINE
Prednosti a nedostatky DXF
Asi najväˇcšou výhodou DXF je jeho rozšírenost’ a s tým súvisiaca programová podpora v
grafických aplikáciach. Okrem toho existuje aj vel’a konvertorov, ktoré prevádzajú dáta
ˇ
vektorového charakteru z/do formátu DXF. Dalšou
výhodou je jeho pomerne jednoduchá
vnútorná štruktúra, takže tieto súbory je l’ahké vytvárat’ ako aj naˇcítat’. Ked’že majú na
nepárnych riadkoch uvedené atribúty a na riadkoch kladných ich hodnoty, je naˇcítanie týchto
súborov možné aj bez špecializovaných knižníc(ako napríklad pri SVG formáte založeného
na XML).
Tento vektorový formát má však aj svoje nevýhody, ktoré vychádzajú z jeho staršieho
návrhu a silnej väzby na program AutoCAD. Dlhú dobu bol obmedzený poˇcet farieb entít.
Vlastnosti pre trojrozmerné telesa, napríklad optické vlastnosti a textúry, je t’ažko zapísat’.
Dost’ problematická je aj vel’kost’ týchto súborov. Tá je spôsobená riadkovým zápisom
jednotlivých atribútov, ked’že každému atribútu je priradený cˇ íselný kód, uložený na
samostatnom riadku. Ako sme videli aj jednoduchá úseˇcka musí bit’ zapísaná aspoˇn
pomocou desiatich textových riadkov. Toto množstvo dát potom spôsobuje pomalý import a
export. Vel’ký objem dát bol dôvodom, preˇco vznikla popri DXF jeho menšia binárna forma
DXB[4].
16
Obr. 2.2: Vykreslenie cˇ iary v DXF formáte
2.2.2
2D kresliace formáty
Vektorové všeobecné formáty pre dvojrozmernú grafiku majú narozdiel od CAD formátov
podporu vo viacerých vektorových nástrojoch ako CorelDraw, Inkscape, Zoner Callisto . . . .
Tieto formáty sú urˇcené pre tvorbu 2D grafiky l’ubovolného charakteru. Medzi takéto formáty
patria interné formáty uvedených vektorových nástrojov. Najuniverzálnejší formát, ktorým sa
budeme d’alej zaoberat’, je vektorový grafický formát SVG10 .
Formát SVG
SVG je znaˇckovací jazyk, zapísaný XML11 štruktúrou, ktorý slúži pre popis dvojrozmernej
grafiky, cˇ i už statickej alebo animovanej. Podporuje základné geometrické tvary, krivky, prácu
s textom a d’alšie vlastnosti, aké môžeme nájst’ aj v PostScripte. Avšak SVG umožˇnuje aj
tvorbu animácií a pridáva interaktivitu, cˇ o ho neurˇcuje len pre statické použitie.
10 SVG
11 XML
- Scalable Vector Graphics)
- eXtensible Markup Language
17
Organizácia súboru
Grafické objekty SVG súboru sú uložené prostredníctvom XML formátu, ktorý
zodpovedá oficiálne vydanej špecifikácií. Preto je možné každému SVG súboru pred
použitím skontrolovat’ jeho validitu. S použitím DOM12 je možné pridávat’, cˇ i inak
upravovat’ uzly stromu, cˇ oho výsledkom je zmenený aktuálny výkres. Pomocou DOM
taktiež môžeme reagovat’ na rôzne udalosti, ktoré vzniknú pri používaní SVG dokumentu
(Prechod kurzora ponad grafický prvok, . . . ). Rozoznávame nasledujúce základne elementy
tvoriace SVG dokument :
• Cesta : Cesta predstavuje krivku zloženú z úseˇciek, eliptických kružníc a kubických cˇ i
Bézierových kriviek. Ako bude daná cesta vykreslená, záleží na nastavených štýloch
vykreslenia ako napríklad farba, štýl cˇ iar, šírka . . . .
• Geometrické tvary : Je síce možné všetky tvary vykreslit’ pomocou zadanej cesty,
avšak pre zjednodušenie zápisu je efektívnejšie použit’ základne geometrické tvary. Na
výber máme kružnicu, úseˇcku, lomenú cˇ iaru, obd´lžnik, elipsu a polygon. Týmto
tvarom následne taktiež špecifikujeme štýly vykreslenia.
• Text : SVG podporuje vkladanie textu pomocou textového elementu. Príjemným
faktom je aj možnost’ pridania vysvetl’ujúcich poznámok pre rôzne elementy, ktoré sú
bez interakcie neviditel’né. Tak ako na ostatné elementy, tak aj na text je možné
aplikovat’ priestorové transformácie(rotácia, posun . . . ).
• Animáci : Vel’a SVG atribútov umožˇnuje menit’ ich hodnoty v cˇ ase, a tým vytvárat’
animáciu. Popísané sú iba kl’úˇcové stavy elementov, priˇcom ich medzistavy sú
generované automaticky[5][6].
Ukážkový príklad na obrázku 2.3 ilustruje štruktúru SVG formátu.
12 DOM
– Document Object Model
18
Obr. 2.3: Štruktúra SVG formátu
Prednosti a nedostatky SVG
Za najvýraznejšiu prednost’ SVG považujem jeho rozšírenost’ a otvorenost’, ktorá
umožˇnuje komukol’vek vytvárat’ a upravovat’ grafiku, dokonca aj bez použitia grafických
editorov. Jeho XML štruktúra udržuje súbor dobre organizovaný a poskytuje jeho l’ahkú
rozšíritel’nost’. Ked’že sa mu nedá upriet’ jeho orientácia na HTML a použitie v
internetových prehliadaˇcoch, vel’a webových vývojárov môže svoje skúsenosti l’ahko
preniest’ do práce s SVG.
SVG je relatívne mladý formát, cˇ oho dôsledok je absencia špiˇckového vývojového
prostredia, akým je napríklad Macromedia pre konkurenˇcný komerˇcný formát Flash. Taktiež
podpora nie je ešte úplná vo všetkých prehliadaˇcoch, no tento problém sa rieši rýchlym
zavádzaním pluin-gov. XML formát je dost’ robustný a preto môže byt’ aj znaˇcne
neefektívny, cˇ o sa do vel’kosti súboru týka, avšak po komprimácií sa redundantné dáta
stratia, cˇ ím je tento problém kompenzovaný.
2.2.3
3D modelovacie formáty
V poslednom desat’roˇcí sme boli svedkami 3D priestorovej revolúcie pri tvorbe technickej
dokumentácie budov, alebo návrhu produktov. Vizualizácia výrobkov v trojrozmernom
priestore, ešte pred spustením ich výroby, dokáže poodhalit’ technické nezrovnalosti cˇ i
19
chybiˇcky krásy daného návrhu. Takúto analýzu priestorových vzt’ahov dnes umožˇnuje 3D
modelovanie.
Na trhu je mnoho nástrojov umožˇnujúcich trojrozmerné modelovanie. Medzi
profesionálne platené nástroje patria 3D Studio Max, AutoCAD,CINEMA 4D, ktorým sa už
vyrovnajú aj bezplatné produkty ako Blender cˇ i Google SketchUp. Každý nástroj si
samozrejme preferuje svoj interný formát, v ktorom ukladá modelované objekty. No
vývojom týchto formátov sa zaužíval výmenný štandard OBJ, ktorý je cˇ asto používaný pre
zápis geometrických štruktúr a materiálov. V d’alšom texte sa budem tomuto formátu bližšie
venovat’.
Wavefront Object (OBJ)
OBJ súbory sa používajú pre ukladanie trojrozmerných geometrických objektov na disk a pre
výmenu týchto dát medzi aplikáciami. Aktuálna verzia tohto formátu je 3.0, ktorá vymenila
predchádzajúcu verziu 2.11. Dáta môžu byt’ uložené v ASCII formáte13 , alebo v
proprietárnom binárnom súbore14 . Ked’že je binárny formát majetkom Wavefront, popíšeme
si len jeho textovú formu.
OBJ formát pracuje s viacuholníkovými, ako ak s vol’ne definovanými prvkami. Zápis
viacuholníkovej geometrie je zabezpeˇcený pomocou bodov, cˇ iar a plôch. Vol’ná geometria
zasa využíva pre jej definovanie roviny a krivky( Bézierové, B-Spline krivky, . . . )[1].
Organizácia súboru
Štruktúra súboru nedefinuje žiadnu hlaviˇcku, ako je tomu u iných formátoch. Každý
riadok zaˇcína kl’úˇcovým identifikátorom, za ktorým nasledujú príslušné dáta. Programy
ktoré spracúvajú OBJ súbor, cˇ ítajú tieto identifikátory a ich dáta po riadkoch, dokým
nenarazia na identifikátor end. Niektoré zo základných kl’úˇcových identifikátorov zobrazuje
tabul’ka 2.3 a 2.4 .
Ukážka zápisu OBJ súboru je na obrázku 2.4. Na prvých riadkoch zvyˇcajne bývajú názvy
súborov s materiálmi, ktoré budme potrebovat’. Nasleduje sekcia z vrcholmi, ktoré majú
13 Pomocou
prípony .obj
prípony .mod
14 Prostredníctvom
20
zostavit’ výslednú geometriu kocky. Väzby medzi jednotlivými vrcholmi sú uvedené
identifikátorom plochy. Pred ním sa nachádza použitý materiál pre prvok a názov skupiny.
Obr. 2.4: Štruktúra OBJ formátu
Prvky
Popis
Dáta vrcholov
Popis
p
Bod
v
Geometrické vrcholy
l
ˇ
Ciara
vt
Štrukturálne vrcholy
f
Plocha
vn
Vrcholové normály
curv
Krivka
vp
Parametrické vrcholy
surf
Rovina
g
Skupina
Tabul’ka 2.3: Identifikátory prvkov
Tabul’ka 2.4: Identifikátory pre vrcholy
21
2D vektorové formáty
3D vektorové formáty
CDR (pre CorelDRAW)
BLEND (pre Blender)
ODG (pre OpenDocument Graphics)
FBX (pre Autodesk)
AI (pre Adobe Illustrator)
X3D (pre Xara)
WMF
3DS (pre Autodesk 3D Studio)
Tabul’ka 2.5: Niektoré d’alšie vektorové formáty pre príslušné programy
Zhrnutie
V tejto cˇ asti práce som sa venoval možnost’ami prevažne vektorových grafických formátov.
Tie boli rozdelené do kategórií, priˇcom z každej bol bližšie popísaný jeden známy predstavitel’
tohto typu. Samozrejme že dostupných používaných formátov je omnoho viac, preto je v
tabul’ke 2.5 uvedených niekol’ko d’alších známych formátov. Ak by sme chceli použit’ takýto
používaný formát pre našu aplikáciu, máme výhodu v možnosti použitia špecializovaných
editorov pre tvorbu budovy. No doplˇnujúce informácie o typoch bezpeˇcnostných prvkov by
sme museli doplnit’ ruˇcne, alebo si vytvorit’ rozširujúci editor na takéto pridávanie záznamov.
Ako hlavný favorit na uplatnenie vytvorených nákresov v AutoCAD-e, bol pre našu
aplikáciu formát DXF. No po jeho hlbšej analýze som došiel k záveru, že pre jednotlivé
vykresl’ujúce prvky neexistujú žiadne dáta o ich vzájomných väzbách. Preto by bolo
naˇcítanie takéhoto formátu problematické. Výhody d’alších formátov uplatním pri návrhu
vlastného interného súboru, ako aj pri tvorbe samotného editora.
Kapitola 3
Java a 3D grafika
3D grafika už dlho nie je výsadou len poˇcítaˇcových hier, alebo Hollywoodskych filmových
efektov. S jej aplikáciami sa cˇ oraz cˇ astejšie stretávame v bežných systémoch. Hlavný prúd
tvorby 3D grafiky je orientovaný na API DirectX, kvôli rozhraniu Direct3D, ktorého vývoj
úzko spolupracuje z výrobcami grafických kariet. Hlavnou slabinou API DirectX je jeho
závislost’ na platforme Microsoft Windows, cˇ o umožnilo vznik jeho konkurenta OpenGL1 .
OpenGL je vel’mi podobné funkcionalitou s API DirectX, avšak jeho implementácia
prebehla do viacerých platforiem a operaˇcných systémov ako aj do platformy Java. Táto
kapitola je zhrnutím rovnomennej kapitoly z bakalárskej práce [13], doplnenej o nové
informácie.
3.1
Java ako platforma aj jazyk
Java ako platforma
Platforma je chápaná ako prostredie pre beh alebo spúšt’anie programov. Java je naozaj
takouto platformou výnimoˇcnou tým, že pracuje nad d’alšími hardvérovými závislými
platformami. Platforma Java je zložená z virtuálneho stroja JVM2 , a aplikaˇcného
programového rozhrania API3 . JVM spracuváva bajtový kód, zatial’ cˇ o API predstavuje
1 OpenGL
- Open Graphics Library
- Java Virtual Machine
3 API - Application Programming Interface
2 JVM
22
23
zbierku programových komponentov rozdelených do knižníc[15].
Na obrázku 3.1je uvedený postup spustenie programu pomocou JVM. Najskôr sa celý
zdrojový kód uloží do neformátovaného textového súboru s príponou .java. Kompilátor javac
potom tieto zdrojové súbory kompiluje do súborov .class, kde sa nachádza bajtový kód, teda
strojový kód pre JVM.
Obr. 3.1: Kompilácia programu prekladaˇcom javac [19]
Java ako programovací jazyk
Java je moderný programovací jazyk spájaný s nasledujúcimi prívlastkami :
• prenositel’ný,
• nezávislý na architektúre,
• objektovo orientovaný,
• robustný,
• vysoko výkoný,
• bezpeˇcný.
Význam jednotlivých pojmov cˇ itatel’ môže nájst’ v [16]. Vel’kou výhodou sú aj vol’né
plnohodnotné vývojové prostredia ako NetBeans IDE4 a Eclipse. Vd’aka redukcií
komplikovaných syntaktických konštrukcií je písanie programov v jazyku Java ovel’a l’ahšie
oproti iným jazykom. Hlavnou výhodou programov napísaných v Jave je ich nezávislost’ na
platforme. Túto situáciu popisuje obrázok 3.2.
4 IDE
- Integrated Development Environment
24
Obr. 3.2: Spustenie programu na rôznych platformách [19]
3.2
Mýtusy o Jave
Výhody programovania v jazyka Java boli už uvedené. Hlavne sa jedná o využitie objektovej
paradigmy, prenositel’nosti a robustnosti jazyka. Napriek týmto výhodám bola a je Java
zatracovaná a neuznávaná pre tvorbu 3D aplikácií. Výhrady preˇco Java nie je vhodná na
takýto typ aplikácií môžeme zhrnút’ do troch bodov
• Java je príliš pomalá na programovanie 3D aplikácií
• Java nehospodári dobre s pamät’ou
• Java je jazyk vysokej úrovne pre programovanie 3D grafiky
Java je príliš pomalá na programovanie 3D aplikácií
Toto prehlásenie platí skôr pri porovnaní s jazykom C respektíve C++. V ranných dobách
Javy bolo toto tvrdenie naozaj pravdivé. Avšak s každou d’alšou vytvorenou verziou sa tento
názor stáva neopodstatneným. Toto zrýchlenie je zapríˇcinené najmä zdokonaleným návrhom
prekladaˇca. Hotspot technológia, využívaná od verzie J2SE5 1.3 umožˇnuje prekladaˇcu
identifikovat’ kritické cˇ asti programu. Sú to cˇ asti programu, ktoré zaberajú najviac
procesorového cˇ asu, takéto miesta potom sa prekladaˇc snaží preložit’ s vel’kým dôrazom na
výkon[7].
5 J2SE
- Java 2 Platform, Standard Edition
25
Java nehospodári dobre s pamät’ou
Jazyk Java nepracuje s ukazovatel’mi v takej podobe, ako je tomu v jazyku C. Preto sú
typické chyby, ktoré spôsobujú diery v pamäti, zachytené prekladaˇcom Javy. Obava o
nehospodárnost’ s pamät’ou sa týka situácie, kedy objekty ktoré už program nepotrebuje, nie
sú odstránené z pamäti. V takom prípade môže program tvorit’ stále nové objekty, priˇcom po
prekroˇcení maximálnej dostupnej pamäti program havaruje. To však nie je slabost’ jazyka,
ale nesprávneho štýlu programovania. Odstráneniu objektu z pamäti dôjde až vtedy, ked’ na
objekt už nikto neodkazuje. Možnost’ identifikovat’ cˇ asti programu, ktoré pohlcujú
neprimerané množstvo pamäti nám dáva nástroj JProfiler[22][7].
Java je jazyk vysokej úrovne pre programovanie 3D grafiky
Strojová nezávislost’ Javy predstavuje isté obmedzenie, ked’že operácie na nízkej úrovni, ako
naˇcítanie alebo zápis do pamäti grafickej karty, sa nedokážu vykonávat’ dostatoˇcne rýchlo.
Na základe toho sa neštandardné vstupno/výstupné zariadenia nedajú použit’. Ak však v
aplikácií potrebujeme takéto zariadenie, môžeme použit’ technológiu JNI6 , k napojeniu
priamo na C respektíve C++. Z histórie vieme že aj o C a C++ sa kedysi uvažovalo ako o
jazykoch privysokej úrovni na tvorbu hier a iných aplikácií, nato aby boli ich programy
dostatoˇcne rýchle ako v jazyku assembler. A napriek tomu je dnes tento názor opaˇcný[7].
Na záver pojednania o jazyku Java a jeho použitie pre 3D aplikácie môžeme zhrnút’, že
v nˇ om napísané programy bežia približne rovnakou rýchlost’ou ako v jazyku C++, i ked’
pomalšie. Je to síce jazyk vysokej úrovne, avšak poskytuje priamy prístup ku grafickému
hardvéru a externým zariadeniam. Všetky námietky voˇci Jave boli opodstatnené na konci
minulého storoˇcia, kedy tento jazyk nebol svojimi knižnicami tak prepracovaný ako je tomu
dnes[7].
6 JNI
- Java Native Interface
26
3.3
Tvorba 3D grafiky v Jave
Trojrozmerné objekty okolo nás, akými sú aj budovy, obsahujú množstvo informácií
potrebných pre vykresl’ovanie v poˇcítaˇcovej grafike. Nie je tomu ani tak dávno kedy sa o
všetku prácu, cˇ o sa týka grafických operácií a koneˇcného vykreslenia, staral procesor
poˇcítaˇca. Preto nebolo dostatoˇcne možné spracovat’ a vykreslit’ vel’ké množstvo dát. Vel’ké
spoloˇcnosti si tento problém uvedomovali a zaˇcali vyvíjat’ grafické akcelerátory, ktoré by
znížili zat’aženie CPU7 . K týmto akcelerovaným grafickým kartám sa súˇcasne vyvíjali aj
programové rozhrania. Takýmto moderným programovým rozhraním je dnes aj OpenGL.
3.3.1
Open Graphics Library - OpenGL
V roku 1981 vznikla spoloˇcnost’ SGI8 , ktorá sa špecializovala na vývoj softvéru a hardvéru
zameraného na poˇcítaˇcovú grafiku. Jej významný projekt bola programová knižnica Iris GL9 ,
ktorá bola ovplyvnená prvotným vývojom a tak obsahovala množstvo nedostatkov. Tie boli
spoloˇcnost’ou SGI odstránené spolu s cˇ ast’ami, ktoré sa netýkali poˇcítaˇcovej grafiky. V roku
1992 spoloˇcnost’ SGI uviedla toto upravené rozhranie pre prácu s poˇcítaˇcovou grafikou v
reálnom cˇ ase, pod názvom OpenGL[14].
Vývoj OpenGL ovplyvnili hlavne spoloˇcnosti ako Nvidia, IBM a Apple, ktoré si
vytvárali stále nové štandardy. Výhodou návrhu OpenGL je jeho hardvérová a softvérová
nezávislost’, vd’aka ktorým ho možno používat’ na rôznych druhoch zariadení. Pre
zariadenia, ktoré nedisponujú takými výkonnostnými parametrami ako bežné poˇcítaˇce,
existuje odl’ahˇcená verzia OpenGL ES[14].
Na zaˇciatku OpenGL podporovalo funkcie pre prácu s bodmi ako transformácie cˇ i
farebné operácie. Poradie týchto funkcií bolo pevne dané, cˇ o sa oznaˇcuje ako fixná
pipeline10 . Od verzie OpenGL 2.0 je zabudovaná programovatel’ná pipeline, ktorá umožˇnuje
7 CPU
- Central Processing Unit
- Silicon Graphics
9 Iris GL - Integrated Raster Imaging System Graphics Library
10 Predstavuje zret’azené spracovanie grafických operácií
8 SGI
27
riadit’ spracovanie dát prostredníctvom shaderov11 . Toto vylepšenie znamenalo pre OpenGL
výrazný posun vpred, cˇ ím sa vyrovnalo populárnemu DirectX[14].
V dnešnej dobe sa dá tvorit’ plnohodnotná 3D grafika aj pomocou Javy a to
predovšetkým vd’aka implementácií multiplatformového rozhrania OpenGL do tohto
programovacieho jazyka. Tvorbu 3D grafiky v Jave možno rozdelit’ podl’a využita :
• priamej väzby Javy na OpenGL,
• aplikaˇcného rozhrania pre prácu s grafom scény,
• väzby na herný systém.
Väzby na herné systémy predstavujú aplikaˇcné rozhrania, ktoré emulujú známe herné
systémy ako napríklad Odejava a Jake2. V d’alšom texte sa budem venovat’ prvým dvom
skupinám[13].
3.3.2
Priame väzby Javy na OpenGL
Za posledných pár rokov bolo vydaných niekol’ko väzieb Javy na OpenGL, ktoré bohužial’
majú sklon k neúplnosti a slabej dokumentácie. Ich kompletný zoznam môže cˇ itatel’ nájst’
na [8]. Prvotné väzby jGL a GL4Java12 boli vel’mi obl’úbené, ich výhoda spoˇcívala v
spolupráci s knižnicami Swing a AWT. Vývoj nových rozhraní však napredoval a tieto väzby
boli nahradené ovel’a modernejšími a komplexnejšími, ktorým sa budem d’alej venovat’.
Lightweight Java Game Library - LWJGL
LWJGL je grafické riešenie profesionálnych ako aj amatérskych Java programátorov ako
tvorit’ kvalitné hry. LWJGL poskytuje vývojárom prístup nielen ku OpenGL, ale aj
OpenCL13 a OpenAL14 . Táto väzba umožˇnuje prístup k zariadeniam akými sú herné
ovládaˇce, volanty a joystiky, pomocou jednoduchého API. Síce písanie programov v LWJGL
11 Shader
je program na riadenie jednotlivých cˇ astí grafickej pipeline
- OpenGL for Java
13 OpenCL - Open Computing Language
14 OpenAL - Open Audio Library
12 GL4Java
28
nie je najl’ahšie, no poskytuje vývojárom technológiu umožˇnujúcu prístup k zdrojom, ktoré
nie sú v Jave dobre implementované. Preto predstavuje hlavnú grafickú väzbu na OpenGL v
Jave, pre tvorbu herných cˇ i grafických enginov. Súˇcasná verzia je LWJGL 2.9.1. Niektoré z
herných enginov a knižníc využívajúce LWJGL [21] :
2D Engine a knižnice
Slick2D, PlayN, JMugen (Mugen Java),
3D Engine a knižnice
JMonkeyEngine, Ardor3D, Xith3D,
GUI knižnice
Nifty Gui, FengGUI, Gooei.
Java OpenGL - JOGL
Táto najmladšia väzba Javy na OpenGL, umožˇnuje prístup k väˇcšine funkcií OpenGL
dostupných pre C jazyk, pomocou JNI 15 . Ponúka prístup ako ku GL*, tak aj GLU*
funkciám, no prístup ku knižnici GLU 16 nie je možný. Zato však JOGL využíva svoje
vlastné okienkové riešenie v spolupráci s AWT a Swing, narozdiel od LWJGL[9].
3.3.3
API pre prácu s grafom scény
Tvorit’ 3D grafiku využitím priamych väzieb na OpenGL je vskutku lákavé, no nejde o
jednoduchú záležitost’. Programátor musí dokonale ovládat’ pokroˇcilé techniky poˇcítaˇcovej
grafiky, ako aj teóriu na pozadí. Tvorba takejto aplikácie potom najskôr pozostáva z
implementovania základných rutinných algoritmov pre vykresl’ovanie objektov a prácu s
nimi. Preto je cˇ oraz viac uplatˇnované využitie enginov, ktoré poskytujú predpripravené
knižnice, cˇ ím ul’ahˇcujú a zrýchl’ujú vývoj aplikácie.
Tieto aplikaˇcné rozhrania najˇcastejšie obsahujú možnosti naˇcítania modelov, zvukových
formátov a video formátov. Taktiež riešia problémy s mapovaním textúr, alebo interakciu s
15 JNI
- Java Native Interface
- OpenGL Utility Toolkit
16 GLUT
29
objektami. Typickým cˇ rtom je najmä graf scény. Graf scény predstavuje hierarchickú
stromovú štruktúru, zloženú z pospájaných uzlov. Uzlom môžu byt’ priradené geometrie,
teda objekty ktoré sa majú zobrazit’, alebo iné prvky scény akými sú zvuky a svetlá. Nad
takto vytvoreným zoskupením prvkov sa l’ahko aplikujú geomterické transformácie, cˇ i iné
operácie. Tento návrh v koneˇcnom dôsledku ul’ahˇcuje tvorbu 3D programov, nakol’ko skrýva
grafickú pipeline, a tým dáva možnost’ zamerat’ sa na návrh a tvorbu scény.
Obr. 3.3: Typická štruktúra grafu scény
Java 3D
Toto aplikaˇcné rozhranie obsahuje sadu konceptov na vysokej úrovni pre tvorbu a
manipuláciu s grafom scény. Vd’aka vysokoúrovˇnových konštrukcií je možné pol’ahky
vytvárat’ osvetlené scény s textúrami a efekty ako napríklad hmlu. Obsahuje sofistikované
mechanizmy pre animovanie scény a definovanie správania sa objektov v scéne. Java 3D v
sebe zluˇcuje dve varianty grafického rozhrania. Prvá je postavená nad rozhraním OpenGL a
druhá nad DirectX Graphics. Toto prepojenie Javy 3D s DirectX je výnimoˇcné vrámci
obdobných API v Jave. Vývoj tohto API bol od roku 2004 výrazne utlmený a pre mnohých
aj definitívne ukonˇcený. Príjemná správa prišla v roku 2012, kedy sa na Jave 3D zaˇcalo opät’
pracovat’, cˇ o prinieslo jej prepojenie z JOGL pre akcelerované hardvérové vykresl’ovanie[7].
Knižnica Java 3D používa k organizácií a riadeniu 3D aplikácie graf scény so štruktúrou
podobnou stromu. Miesto výrazu strom scény sa používa graf, pretože uzly v nˇ om môžu byt’
zdielané viacerými rodiˇcmi. Uzly sú dvoch hlavných typov. Sú to uzly typu Group a Leaf.
30
Uzol typu Group môže obsahovat’ d’alšie uzly, ktoré zoskupuje, teda operácie ako posunutie
alebo rotácia môžu byt’ aplikované hromadným spôsobom. Uzly typu Leaf predstavujú listy
grafu. Tie môžu reprezentovat’ viditel’né prvky v scéne ako modely a tvary, ale aj nehmotné
objekty, akými sú napríklad svetlá a zvuky. Taktiež tieto uzly môžu obsahovat’ d’alšie
pomocné komponenty, ktoré urˇcujú materiál a d’alšie vlastnosti uzlu. Do grafu scény
môžeme d’alej pridat’ chovanie, predstavujúce uzly s programovým kódom, ovplyvˇnujúce
iné uzly scény za behu programu. Takýto uzol najˇcastejšie pohybuje geometrickými tvarmi,
mení osvetlenie, alebo reaguje na kolízie. Názornú štruktúru grafu scény v Jave 3D možno
vidiet’ na obrázku 3.4 [7].
Obr. 3.4: Graf scény v Java 3D
Xith3D
Knižnica Xith3D používa rovnakú štruktúru pre graf scény ako Java 3D. Tieto rozhrania sú
natol’ko podobné, že preniest’ program z jedného API do druhého je pomerne l’ahká
záležitost’. Systém Xith3D narozdiel od Javy 3D už zozaˇciatku umožˇnoval volat’ operácie
rozhrania OpenGL. Táto skutoˇcnost’ znamenala podporu funkcionality pre výpoˇcet tieˇnov,
31
realizácie vertex a fragment programov, taktiež známych ako shader. Knižnica Xith3D sa
momentálne dokáže napojit’ na grafické rozhrania LWJGL, JOGL a JSR-321[7].
Možnosti formátov v Xith3D
• formáty textúr: PNG, JPG, GIF, BMP, PCX, TGA, DDS, SGI,
• zvukové formáty: WAV, OGG,
• Naˇcítanie modelov vo formátoch: ASE, AC3D, OBJ, 3DS, MD2, MD3, MD5, Cal3D,
COLLADA 1.4 [10].
jMonkeyEngine - jME
jMonkeyEngine predstavuje sadu knižníc pre tvorbu nízko-úrovˇnových hier a 3D aplikácií.
Pre vykresl’ovanie využíva LWJGL ako štandardné grafické rozhranie. Avšak je tu už aj
možnost’ prepnút’ na vykresl’ovanie založené na JOGL. Plne podporovaný je nielen OpenGL
2.0 ale aj OpenGL 4.0. Momentálne je možnost’ tvorit’ aplikácie pre platformy Linux, Mac,
ˇ
Windows a Android. Coskoro
sa chystá aj nasadenie pre iOS. Aktuálna stabilná verzia má
oznaˇcenie jMonkeyEngine 3.0 [11].
jMonkeyEngine je postavený na podobnej štruktúre grafu scény ako Java 3D. Rozdielom
je len jeho stromová štruktúra, kde uzly nezdiel’ajú svojich potomkov. Táto sada knižníc
umožˇnuje pridat’ do scény špeciálne efekty ako žiara, hmla,odraz cˇ i oheˇn. Okrem toho
obsahuje aj množstvo prepracovaných štruktúr a algoritmov na tvorbu fyzikálnych javov,
osvetlenia scény, detekciu kolízií alebo pridanie shaderov.
Výhodou jME je aj jeho integrovanie do vlastného vývojového prostredia, založeného na
Netbeans IDE. Toto prostredie napomáha vd’aka množstvu doplnkov písat’ a zefektívˇnovat’
programový kód. Pre import modelov je zasa nápomocná priama spolupráca s 3D
modelovacím nástrojom Blender. Dobrou cˇ rtou je aj jeho dobrá dokumentácia a vel’a
dostupných tutoriálov. V neposlednom rade je užitoˇcná aj vel’ká komunita používatel’ov, cˇ o
napomáha napredovat’ pri riešení podobných problémov, s ktorými sa stretli aj ostatný
programátori. Tento systém prevyšuje ostatné popísané API rozhrania ako aj d’alšie
neuvedené ako OpenMind, JiD, Aviatrix3D, jFree-D2.
32
Možnosti formátov v jME 3.0
• formáty textúr: PNG, JPG, GIF, DDS, HDR, TGA, PFM,
• zvukové formáty: WAV, OGG,
• Naˇcítanie modelov vo formátoch: blend, ogrexml, obj, COLLADA, scene, a cˇ oskoro aj
FBX[20].
3.3.4
Zhrnutie jednotlivých možností
Pre tvorbu 3D grafiky je nutné mat’ podporu rôznych funkcií, ktoré sú pri typu danej práce
potrebné. Tieto pomocné knižnice si môžeme naprogramovat’ sami, pomocou niektorej
priamej väzby na OpenGL. Takéto úsilie je však vel’mi pracné a skôr cˇ i neskôr narazíme na
problémy, ktoré sú už vyriešené. Vzhl’adom na to že program budem tvorit’ sám, rozhodol
som sa preto využit’ niektorý z popísaných enginov.
Systém Java 3D je znovu v ranných štádiách, ked’že sa znovu zaˇcal pred krátkou dobou
vyvíjat’. Vývoj Xith3D taktiež prestal napredovat’ a preto najoptimálnejším riešením pre
úˇcely mojej aplikácie je pre mˇna engin jME. Toto najmladšie aplikaˇcné rozhranie je
spomedzi ostatných najlepšie zdokumentované a poskytuje najviac možností pri práci s 3D
grafikou.
Obr. 3.5: Logá uvedených API. Menovite zl’ava: Java 3D, Xith3D, jME
Kapitola 4
Vyhl’adanie kritickej cesty
Úlohou aplikácie tejto práce je umožnit’ expertovi modifikovat’ umiestnenie a typ
bezpeˇcnostných prvkov budovy akými sú dvere, mreže cˇ i okná. Ked’že vieme cˇ as príchodu
zásahových zložiek pri spustení alarmu, prácou experta je nastavit’ bezpeˇcnostný systém tak,
aby doba prekonania systému prekroˇcila cˇ as príchodu ochranky. S uvedeného vyplýva zistit’
najkratší možný cˇ as dosiahnutia daného miesta v budove, spolu so zoznam prekonaných
prvkov zabezpeˇcenia. Tieto pojmy môžeme nazvat’ aj ako kritický cˇ as a kritická cesta.
Vyhl’adanie kritickej cesty je možné stotožnit’ s problémom vyhl’adania najkratšej cesty,
ktorým sa v minulosti zaoberali významný matematici. Ich poznatky zaháˇna cˇ ast’ diskrétnej
matematiky nazvanej teória grafov, zaoberajúca sa vlastnost’ami grafov. Problém nájdenia
kritickej cesty spolu s cˇ asom si znázorníme na dvojrozmernom prípade ilustrujúci obrázok
4.1.
Obr. 4.1: Úloha nájdenia kritickej cesty k oznaˇcenému miestu
33
34
4.1
4.1.1
Budova ako graf
Základné pojmy
Graf
Charakteristickou cˇ rtou grafu je jeho diskrétna štruktúra. Skladá sa z uzlov a hrán, ktoré
medzi nimi tvoria väzby. Grafy vd’aka svojej diskrétnej povahe slúžia ako abstrakcia pre
vel’kú skupinu problémov, v našom prípade pre abstrakciu budovy.
Matematicky definujeme graf G ako usporiadaní dvojicu G = (V, E), kde V je neprázdna
koneˇcná množina a E, E ∈ {{u, v}|u, v ∈ V } je množina ich dvojprvkových podmnožín.
Prvky množiny V nazývame vrcholy , respektíve uzly grafu a prvky množiny E hrany grafu.
Hrany zaˇcínajú a konˇcia v istom uzle, síce tieto koncové uzly môžu byt’ rovnaké1 , v našom
prípade budú vždy rôzne. Vrcholy s ktorými je vrchol u spojený hranu, sa nazývajú susedné
vrcholy2 . Stupeˇn vrcholu potom definujeme ako poˇcet hrán, ktoré prislúchajú danému
vrcholu. Oznaˇcujeme ho deg(v) priˇcom platí, že súˇcet všetkých vrcholov v grafe je
párny[18].
Typy Grafov
Hrany v grafoch môžu reprezentovat’ jednosmerný alebo obojsmerný vzt’ah, cˇ o znaˇcí cˇ i je graf
orientovaný alebo nie je. Orientovaný graf G je dvojica G(V, ~E), kde V je neprázdna množina
vrcholov a ~E je množina usporiadaných dvojíc takých že, (u, v) ∈ V xV pre u, v ∈ V [18].
Ak je prvkom grafu priradené ohodnotenie, potom hovoríme o ohodnotenom grafe.
Ohodnotený graf môže byt’ ako aj orientovaný tak aj neorientovaný. Rozoznávame dva typy
vážených grafov. Vrcholovo ohodnotený graf je graf s ohodnotenými uzlami3 , zatial’ cˇ o
hranovo ohodnotený graf je graf s ohodnotenými hranami4 [18].
1V
takom prípade hovoríme o sluˇcke
sú všetky vrcholy susedné hovoríme o úplnom grafe
3 Každému vrcholu prislúcha hodnota
4 Každej hrane prislúcha hodnota
2 Ak
35
Sled, t’ah a cesta
Striedavú postupnost’ vrcholov a hrán v grafe oznaˇcujeme ako t’ah. Jedná sa o l’ubovolnú
pochôdzku v grafe. Ak sa v t’ahu z vrchola v do u nevyskytuje opakujúca hrana, potom
takýto t’ah nazývame sledom. A koneˇcne cesta z vrchola v do u je zasa taký t’ah, v ktorom sa
neopakuje žiaden vnútorný uzol. Sled, ktorý nie je cestou, môžeme transformovat’ na cestu
vynechaním násobného vrchola. To znamená, že ak exituje medzi vrcholmi sled potom
existuje aj cesta[18].
Obr. 4.2: Zl’ava hranovo a vrcholovo-ohodnotený graf
4.1.2
Transformácia na graf
Obr. 4.3: Abstrakcia budovy na hranovo ohodnotený neorientovaný graf
Kritickú cestu k oznaˇcenému miestu na obrázku 4.1, získame aplikovaním grafových
algoritmov pre nájdenie najkratšej cesty. Skôr je však nutné vytvorit’ model budovy, ako graf
bezpeˇcnostných prvkov budovy. Vrcholmi tohto grafu budú miestnosti budovy a hranami
36
grafu budú bezpeˇcnostné prvky, ktoré ich oddel’ujú(steny,okná,mreže,dvere . . . ). Graf bude
hranovo-hodnotený, priˇcom hodnoty hrán budú reprezentovat’ jednotlivé cˇ asy prekonania
ˇ prekonania steny z miestnosti A do B bude vždy rovnaký ako
bezpeˇcnostných prvkov. Cas
cˇ as prekonania opaˇcným smerom, preto vytvorený graf bude neorientovaný a bez sluˇciek.
Transformáciu modelu budovy na graf ilustruje obrázok 4.3. Ako prvé vytvoríme vrcholy
oznaˇcujúce jednotlivé miestnosti a pridáme im spájajúce hrany. V l’avom obrázku sú naˇcrtnuté
možné prechody do miestnosti 3, priˇcom ak je medzi dvomi vrcholmi viacero možných ciest
do grafu staˇcí pridat’ hranu s najmenším ohodnotením. Vrchol 1 reprezentuje priestor mimo
budovy.
4.2
Algoritmy pre hl’adanie najkratšej cesty
Vo všeobecnosti sa dajú v grafoch vyhl’adávat’ cesty s maximálnou kapacitou,
najspol’ahlivejšie a najkratšie cesty. Táto cˇ ast’ sa venuje poslednej uvedenej možnosti, ktorú
d’alej delíme na prípad
• hl’adania najkratšej cesty medzi všetkými jednotlivými uzlami,
• hl’adania najkratšej cesty z poˇciatoˇcného uzla do všetkých,= ostatných uzlov,
• hl’adania najkratšej cesty z poˇciatoˇcného do koncového uzla.
4.2.1
Dijskstrov algoritmus
Je algoritmus pre zostrojenie najkratšej cesty v hranovo ohodnotenom grafe medzi
poˇciatoˇcným vrcholom a ostatnými vrcholmi. Jeho použitie je obmedzené pre grafy s
nezáporným ohodnotením hrán. Ako prvý ho v roku 1959 popísal holandský informatik
Edsger Wybe Dijkstra.
Každému vrcholu priradíme premennú uchovávajúcu najkratšiu vzdialenost’ sledu,
ktorým sme sa to daného vrcholu dostali, spolu s posledným vrcholom sledu. Algoritmus
d’alej postupne vyberá nenavštívené vrcholy s najmenšou vzdialenost’ou a skúša nájst’ nové
kratšie cesty do susedných uzlov.
37
Zápis algoritmu
Krok 1: Inicializácia – Všetkým vrcholom nastavíme vzdialenost’ na nekoneˇcno s výnimkou
poˇciatoˇcného. Vytvoríme zoznam nenavštívených vrcholov, ktorý obsahuje všetky
vrcholy okrem poˇciatoˇcného, ktorý vyberieme za aktuálny.
Krok 2: Susedným vrcholom aktuálneho vypoˇcítame najkratšie vzdialenosti cez aktuálny
vrchol. Ak je táto najmenšia vzdialenost’ menšia ako doposial’ uvedená, potom ju
prepíšeme novo nájdenou vzdialenost’ou a uvedieme jej posledný uzol ako aktuálny.
Po prepoˇcítaní všetkých susedných uzlov odstránime aktuálny uzol zo zoznamu
nenavštívených vrcholov.
Krok 3: Ak sme oznaˇcili ciel’ový vrchol ako navštívený, potom jeho aktuálna vzdialenost’ je
definitívna a algoritmus môžeme ukonˇcit’. Pokial’ chceme zistit’ najkratšie vzdialenosti
medzi d’alšími vrcholmi, oznaˇcíme nenavštívený vrchol s najmenšou vzdialenost’ou
ako aktuálny a pokraˇcujeme krokom 2.
Po ukonˇcení algoritmu máme v každom vrchole jeho najkratšiu vzdialenost’ k
poˇciatoˇcnému vrcholu a vrchol, z ktorého sme ho dosiahli. Postupným prechádzaním
vrcholov môžeme zistit’ presné smerovanie cesty až do poˇciatoˇcného uzlu. Zložitost’
Dijkstrovho algoritmu je O(n2 ), avšak ak nás zaujíma len cesta medzi dvoma vrcholmi,
algoritmus skonˇcí pravdepodobne skôr, ako preskúma všetky vrcholy[17].
4.2.2
Algoritmus A*
Tento vyhl’adávací algoritmus je špecializovaný na hl’adanie cesty medzi urˇceným
poˇciatoˇcným a koncovým vrcholom. Je postavený na Dijkstrovom algoritme, od ktorého sa
líši pridaným heuristickým prvkom. Toto vylepšenie usmerˇnuje prechod grafom v
najsl’ubnejšom smere, cˇ ím sa znižuje poˇcet navštívených vrcholov.
Táto heuristika približne urˇcuje výslednú vzdialenost’ ku koncovému vrcholu. K tomu
využíva heuristickú funkciu f (x) = g(x) + h(x), kde g(x) predstavuje najkratšiu cestu k
danému vrcholu a h(x) je odhad vzdialenosti z daného uzla do koneˇcného5 . Tá priradí
5 Odhad
môže využívat’ rôzne druhy metriky(vzdušná vzdialenost’, pravouhlá . . . )
38
každému vrcholu heuristický odhad, na základe ktorého sú vrcholy spracované v danom
ˇ
poradí. Cím
ma vrchol menší heuristický odhad, tým má sl’ubnejšiu východziu pozíciu
vzhl’adom k nájdeniu optimálnej cesty, a preto je preberaný skôr[12][18].
Obr. 4.4: Zl’ava Dijkstrov a A* algoritmus na vyhl’adanie optimálnej cesty[12]
4.2.3
Floyd-Warshallov algoritmus
Je to algoritmus hl’adania najkratšej cesty z každého vrchola grafu G = (V, H, c) do každého,
kde c(h) >= 0. Algoritmus využíva na reprezentáciu grafu maticu C = (ci j ) rozmeru NxN,
ktorej prvky sú definované nasledovne:
cii = 0, pre všetky i ∈ V
a pre všetky i, j, také že, i 6= j
ci j =


c(i, j), ak {i, j} ∈ H

∞,
ak {i, j} ∈
/H
Po skonˇcení algoritmu obsahuje matica C najkratšie vzdialenosti vrcholov. Ak by sme
chceli vediet’ aj presnú cestu v grafe, je nutné zostrojit’ maticu X = (xi j ) obsahujúcu posledný
navštívený vrchol pre každú dvojicu vrcholov i, j.
xii = i, pre všetky i ∈ V
a pre všetky i, j, také že, i 6= j
xi j =


i,
ak {i, j} ∈ H

∞, ak {i, j} ∈
/H
39
Programový zápis
for k ∈ N do
for i ∈ N do
for j ∈ N do
if ( ci j > cik + ck j )
{
ci j = cik + ck j
xi j = dik + xk j
}
Tento algoritmus postupne prechádza dvojice vrcholov v grafe, priˇcom sa snaží vylepšit’ cestu
medzi nimi. Ak takúto cestu nájde, tak ju uloží do matice vzdialenosti a do matice ciest uloží
informáciu, z akého uzlu cesta vedie. Zložitost’ algoritmu je kubická O(n3 )[17].
Zhrnutie
V tejto kapitole boli uvedené najpoužívanejšie algoritmy hl’adania najkratších ciest. Každý z
nich má svoje špecifiká a preto sa hodí na riešenie jemu vhodnej charakteristickej úlohy.
Špeciálnym prípadom bol Floyd-Warshallov algoritmus, ktorý zisti všetky najkratšie
cesty z každého vrchola do každého, cˇ o má za následok zlú výpoˇctovú zložitost’ (O(n3 )). Pre
aplikácie v praxi má uplatnenie napríklad pri tvorbe železniˇcného grafikonu, kde má lepšie
vlastnosti ako násobne použitý Dijkstrov algoritmus pre všetky vrcholy.
Algoritmus ktorý sa zameriava výluˇcne na nájdenie najkratšej cesty medzi dvomi danými
vrcholmi je A* algoritmus. Tento upravený Dijkstrov algoritmus dosahuje zlepšenie pridaním
heuristického odhadu, cˇ o mu umožˇnuje nájst’ riešenie rýchlejšie, za predpokladu že existuje.
Kapitola 5
Návrh a implementácia riešienia
Táto kapitola popisuje návrh a implementáciu riešenia požadovanej aplikácie. Nakol’ko si
myslím, že sa nejedná o triviálnu vec, ale o rozsiahly projekt, moju aplikáciu som rozdelil do
niekol’kých hlavných cˇ astí. Svoju pozornost’ d’alej upriamím najmä na architektúru aplikácie,
a na využité postupy pri riešení daných problémov. Ešte pred tým ako si priblížime jednotlivé
cˇ astí programu, zadefinujme úlohy, ktoré bude užívatel’ požadovat’.
Na obrázku 5.1 je zobrazený diagram prípadov použitia, ktoré urˇcujú aké úkony môže
používatel’ vykonat’ pri práci s programom. Ten si môže vytvorit’ svoj vlastný model budovy
v príslušnom editore. Okrem tvorby samotnej topológie môže pridávat’ a upravovat’
bezpeˇcnostné prvky. Takto vytvorený model môže d’alej používatel’ uložit’ a v prípade
potreby zase naˇcítat’. Aplikácia spolu s iným umožˇnuje virtuálnu prehliadku scény, v ktorej
sa nachádza budova záujmu. Pri prechádzaní scénou si užívatel’ môže nechat’ zistit’
informácie o daných objektoch, a to bud’ pomocou ich oznaˇcením priamo v scéne, alebo po
vyhl’adaní v nato urˇcenom panely. Po úprave bezpeˇcnostných prvkov si môže nechat’
užívatel’ vyhl’adat’ a zobrazit’ najkratšiu cestu k zvolenému miestu v scéne, spolu s
prekonanými zabezpeˇcovacími prvkami.
40
41
Obr. 5.1: Diagram prípadov použitia aplikácie
Základná architektúra
Aplikácie je zložená z množstva komponentov, ktoré poskytujú funkcionalitu pre tie
najvšeobecnejšie moduly. V tom najhrubšom priblížení aplikácia pozostáva z modulov
ˇ
uvedených na obrázku 5.21 . Dalej
je uvedený struˇcný popis jednotlivých balíkov, ktoré si
bližšie priblížime v nasledujúcich cˇ astiach.
• buffer : Tento modul udržuje štruktúru budovy v pamäti poˇcítaˇca prostredníctvom
ˇ
dátových štruktúr. Dalej
obsahuje podporné triedy, ktoré sú nutné pre modelovanie
budovy. Jeho povinnost’ou je taktiež umožnit’ ukladat’ dáta na disk poˇcítaˇca, alebo
zvolenú databázu. Dáta ktoré obsahuje, ponúka d’alším modulom pre ich následné
1 Vývoj
aplikácie pre projekt ’Expertný systém pre hodnotenie bezpeˇcnostných systémov ochrany objektov’,
prebiehal pod názvom IBSES
42
spracovanie.
• visualization: Poskytuje podporné triedy pre vykreslenie budovy, nastavenie kamery,
tvorbu grafu scény a oznaˇcovanie objektov. Tu sa takisto nachádza podpora pre
vytváranie plôch a bezpeˇcnostných prvkov, teda samotný editor.
• guiFx : Ponúka užívatel’ské rozhranie pre vkladanie požiadaviek od používatel’a, alebo
experta. To je tvorené prostredníctvom technológie JavaFX 2 , ktorú rozširujú pridané
triedy.
• databáza : Obsahuje všetky potrebné dáta budovy pre jej vykreslenie a jej manipuláciu.
V tejto práci sa nˇ ou nebudem zaoberat’, nakol’ko bola tvorená inými študentami. Jej
výsledný databázový model je zobrazený na obrázku 1.1.
• pathFinder : Modul poskytuje mechanizmus na vyhl’adanie kritickej cesty. Triedy
ktoré zah´rnˇ a, umožˇnujú pretavit’ topológiu budovy na graf, na ktorý následne môže
byt’ aplikovaný algoritmus vyhl’adania najkratšej cesty.
Obr. 5.2: Diagram modulov
2 JavaFX
je softvérová platforma pre vytváranie a poskytovanie RIA(Rich internet application) aplikácií
43
5.1
Dátová reprezentácia budovy (buffer3)
Každý objekt budovy je odvodený z generickej abstraktnej triedy Entity, ktorá
implementuje interfejs Comparable. Entity trieda bude tiež užitoˇcná pri návrhu
ˇ
komunikácie s databázou. Dalej
je táto abstrakcia rozšírená abstraktnou triedou
SceneEntity, ktorej realizácie budú tvorit’ topológiu budovy. V nej je uplatnený
hierarchický charakter topológie a to tak, že obsahuje odkaz na predka v štruktúre budovy a
zoznam potomkov typu SceneEntity. Zoznam je implantovaný generickou údajovou
štruktúrou AVL stromom4 . V tejto triede sa nachádza aj odkaz typu GraphNode, ktorý
zabezpeˇcuje jej prepojenie s grafom scény, ktorý zaobstaráva vykresl’ovanie prvkov .
Obr. 5.3: Návrhový model tried
3 Balík
4 AVL
s týmto názvom zodpovedá v programe za implementáciu riešených cˇ astí, uvedených v texte
strom je binárny vyhl’adávací strom, ktorý má tú vlastnost’, že je výškovo vyvážený
44
Abstraktný typ SceneEntity realizujú inštancie tried Building, Floor, Room, Face a
SecurityObject5 . Tie nesú potrebné cˇ lenské premenné pre špecifikovanie konkrétnej
vlastnosti prvku v hierarchií budovy. Zoznam potomkov, ktorý zdedili z abstraktného typu,
využívajú na zoskúpenie úrovˇnovo nižších prvkov budovy. Teda inštancia typu Building v
nˇ om uchováva odkazy na inštancie typu Floor a tak d’alej.
Spomínané úrovne predstavujú štrukturálne uzly, ktoré spájajú prvky do skupín, z
ktorých sa tvorí skelet budovy. Vykreslenie nastáva až na úrovni triedy Face, ktorá vytvára
geometriu plôch, cˇ ím sa zhmotˇnuje doposial’ zavedená kostra. Okrem toho obsahuje aj
zoznam bezpeˇcnostných objektov(dvere, mreže. . . ) typu SecurityObject, ktoré sú na danú
plochu nalepené. Tie sa taktiež v scéne zobrazujú a môžu byt’ zložené z konkrétnych
zabezpeˇcovacích
elementov.
Tieto
prvky
sú
charakterizované
inštanciami
triedy
SecurityElement, ktorá realizuje abstraktnú triedu Entity. Typ SecurityElement
obsahuje všetky potrebné informácie o zabezpeˇcovanom prvku ako jeho typ, odolnost’ a
zloženie.
Ukladanie a naˇcítanie modelu z databázy
Ak zmeníme prvok v strome štruktúry budovy, chceme aby sa táto zmena prejavila aj na
databáze. Riešením je vytvorenie nástroja, ktorý by na požiadanie zobrazil aktuálny stav
budovy do aktívnej databázy.
Ukladanie je implementované cez triedu Session, jej väzby na pomocné triedy ukazuje
obrázok 5.4. Pripojenie na databázu obstaráva trieda Connection. V návrhu tried budovy
bola predstavená abstraktná trieda Entity, ktorá zastrešuje všetky d’alšie v jej štruktúre.
Preto môžeme zavolat’ statickú metódu saveEntity, alebo deleteEntity nad
požadovaným prvkom v budove, cˇ o spôsobí zaradenie požiadavky na jeho zrušenie/uloženie
do fronty vykoanania. Pri žiadosti modifikovat’ stav databázy, podl’a aktuálneho modelu,
budú tieto požiadavky spracované.
5 Anglické
názvy tried významovo zodpovedajú ich slovenským ekvivalentom, t.j Building – budova, . . .
45
To aký konkrétny databázový príkaz sa vykoná, zabezpeˇcuje abstraktná generická trieda
Mapper. Z nej sú d’alej odvodnené jednotlivé triedy, ktoré mapujú inštancie Entity, podl’a
ich typu triedy a podl’a druhu pripojenej databázy(MySQL, PostrgeSQL. . . ). To že aká trieda
bude požadovanú inštanciu mapovat’ na databázu, urˇcí Mapper. Naˇcítanie dát z databázy, a ich
prevedenie na model budovy prebieha podobne v opaˇcnom garde. Dáta, ktoré sú vyžiadané
príslušnými dotazmi na databázu, sú konvertované na typovo správnu entitu, ktorá je d’alej
zaradená do štruktúry budovy.
Obr. 5.4: Triedy pre ukladanie dát do databázy
Ukladanie a naˇcítanie modelu zo súboru
Štruktúru súboru pre ukladanie modelu budovy zobrazuje obrázok 5.5. Samotný súbor
pozostáva z d’alších, ktoré nesú informácie o príslušných typoch entít. Tieto súbory majú
formát XML zápisu, cˇ o zjednodušuje jeho naˇcítanie a zápis. Preto pre tieto potreby bola
využitá vol’ná externá knižnica dom4j6 . Pomocou nej je spracovanie súborov dostatoˇcne
pohodlné, najmä vyhl’adanie sekcie dát podl’a kl’úˇcového slova a jej naˇcítanie respektíve
zapísanie.
5.2
Vizualizácia budovy a jej editor (visualization)
V tretej kapitole boli rozobrané možnosti vizualizácie scény v Jave. Z nich som si pre
potreby aplikácie vybral knižnicu jMonkeyEngine(JME). JME poskytuje na reprezentáciu 3D
6 Dom4j
je l’ahko použitel’ná open source knižnica pre prácu s XML, XPath a XSLT na platforme Java
46
Obr. 5.5: Štruktúra výmenného súboru pre zálohovanie
sveta graf scény, cˇ o je hierarchická stromová štruktúra7 , zložená z uzlov typu Spatial.
Tento abstraktný typ realizujú d’alšie dva, a to typ Node a Geometry. V struˇcnosti typ
Geometry reprezentuje hmotné objekty, ktoré budú nakoniec zobrazené, zatial’ cˇ o typ Node
predstavuje vnútorne uzly, ktoré zoskupujú geometrie do celkov a tak vytvárajú akúsi kostru
v grafe scény. Ak aplikujeme priestorovú transformáciu na takýto skupinový uzol,
aplikujeme ju aj na všetky jej podradené uzly.
Obr. 5.6: Diagram základných tried pre graf scény aplikácie
7 Koreˇ
n
stromu sa oznaˇcuje ako rootNode, priˇcom zobrazené môžu byt’ len jemu podradené uzly
47
Pre lepšiu manipuláciu s grafom scény som rozšíril typ Node na typ GraphNode, ktorý mu
umožˇnuje rekurzívne volat’ potrebné operácie na všetky jeho podradené uzly. Ten je ešte d’alej
rozšírený triedou SceneEntityNode, ktorá prepája graf scény s dátovou vrstvou, obsahujúcou
naˇcítaný model budovy, popísanou v predchádzajúcej cˇ asti. Inštancie tejto triedy sú vkladané
do grafu scény, cˇ ím tvoria kostru budovy. Túto situáciu zachytáva obrázok 5.7, a diagram
použitých základných tried obrázok 5.6.
To ako sa steny v koneˇcnom dôsledku zobrazia, je dané ich geometriou a vzhl’adom,
ktoré implementuje trieda Geometry. Jej hlavnou úlohou je popísat’ tvar a optické vlastnosti
daného objektu. K tomu jej slúži trieda Mesh a Material. Mesh udržiava dáta o geometrií
objektu(drôtený model8 ) v špecializovaných zásobníkoch, narozdiel od triedy Material,
ktorá definuje svetelné vlastnosti povrchu objektu nastavením jeho príslušných parametrov.
Tvorbou geometrie a materiálu objektu sa budem venovat’ v nasledujúcom texte.
Obr. 5.7: Graf scény aplikácie
8 Anglický
výraz pre tento pojem je mesh
48
Tvorba geometrie a materiálu objektu
Ako už bolo popísane, prvky zobrazené v scéne zastrešuje trieda Geometry. Pred tým ako jej
vytvorenú inštanciu zapojíme do grafu scény pre jej vykreslenie, musíme jej priradit’ tvar a
vzhl’ad nastavením jej kompozitných inštancií Mesh a Material.
Listing 5.1: Zdrojový kód definovania tvaru objektu v podobe siet’ky
// suradnice vrcholov
setBuffer ( Type . Position , 3 , new float []{
verticles [0]. x , verticles [0]. y , verticles [0]. z ,
verticles [1]. x , verticles [1]. y , verticles [1]. z ,
verticles [2]. x , verticles [2]. y , verticles [2]. z ,
verticles [3]. x , verticles [3]. y , verticles [3]. z
});
// suradnice mapovania
if ( map == Mode . BothSide ) {
indexes = new short []{3 , 0 , 1 , 1 , 2 , 3 , 3 , 2 , 1 , 1 , 0 , 3};
} else if ( map == Mode . RightMap ) {
indexes = new short []{0 , 1 , 2 , 0 , 2 , 3};
} else if ( map == Mode . LeftMap ) {
indexes = new short []{0 , 2 , 1 , 0 , 3 , 2};
}
// vytvor normaly
Vector3f [] triangleNorm = new Vector3f [ indexes . length / 3];
for ( int i = 0; i < 2; i ++) {
triangleNorm [ i ] = new Triangle ( verticles [ indexes [ i * 3]] ,
verticles [ indexes [ i * 3 + 1]] ,
verticles [ indexes [ i * 3 + 2]]). getNormal ();
}
// nastav dalsie zasobniky
setBuffer ( Type . Index , 3 , BufferUtils . createShortBuffer ( indexes ));
setBuffer ( Type . Normal , 3 , BufferUtils . createFloatBuffer ( triangleNorm ));
setBuffer ( Type . TexCoord , 2 , new float []{0 , 0 , 1 , 0 , 1 , 1 , 0 , 1});
// obnov
droteny model
updateBound ();
}
49
Nami vytvorená dátová štruktúra pre reprezentáciu budovy obsahuje plochy, ktoré treba
vykreslit’ ako cˇ asti stien. Plocha
9
obsahuje hrany, ktoré ju ohraniˇcujú, cˇ im tvoria konvexný
alebo nekonvexný polygón. Najˇcastejšie sa jedná o plochu tvorenú zo štyroch vrcholov, ktoré
sú popísané priestorovým vektorom.
Siet’ovina objektu10 takejto plochy sa vytvorí postupom ukázaným na predchádzajúcej
ukážke kódu. Ako prvé naplníme zásobník11 obsahujúci priestorové dáta o vrcholoch.
Grafické akcelerátory vedia najefektívnejšie zobrazovat’ trojuholníky, preto rozdelíme našu
plochu na dva trojuholníky, priˇcom zadefinujeme smer pre ich vykresl’ovanie. Poradie
vykresl’ovania vrcholov má dopad na to, z ktorej strany bude plocha viditel’ná12 . Pre
tieˇnovanie objektu je nutné nájst’ normály vzniknutých trojuholníkov, a naplnit’ nimi
zásobník normál. Tento zásobník normál predáme JME, spolu so zásobníkom vrcholov a
indexov. Ak chceme na steny pridat’ textúry, potom je nutné aktualizovat’ aj zásobník
textúrových koordinátov. Ak máme potrebné zásobníky naplnené, zavoláme metódu
updateBound nad vytváranou inštanciou typu Mesh, ktorá sa zavedie do geometrie objektu.
Listing 5.2: Zdrojový kód pre nastavenie materiálu objektu
Material material = new Material ( getAssetManager () , " Material . j3md " );
//
nastav odrazivu zlozku svetla
material . setColor ( " Specular " , ColorRGBA . White );
//
nastav difuznu - rozptylnu zlozku svetla
material . setColor ( " Diffuse " , ColorRGBA . White );
//
nastav lesklost povrchu
material . setFloat ( " Shininess " , 0.5 f );
//
pridaj texturu povrchu
material . setTexture ( " ColorMap " , getAssetManager ().
loadTexture ( " kamen . jpg " ));
//
pridaj vyskovu deformaciu povrchu
material . setTexture ( " BumpMap " , getAssetManager ().
loadTexture ( " bump . jpg " ));
reprezentuje trieda Face
výraz je mesh
11 Castejší
ˇ
výraz pre tento typ zásobníku je buffer
12 V prípade nastavenia príznaku mapovania na Mode.BothSide, sa budú vykresl’ovat’ obe strany
9 Plochu
10 Používanejší
50
Pri použití grafických knižníc sa vzhl’ad objektov popisuje pomocou shaderov, tak je
tomu aj v prípade OpenGL. V teoretickej cˇ asti pri popise OpenGL, bola spomenutá jeho
programovatel’ná pipeline. Knižnica JME dovol’uje úpravu vzhl’adu objektov pomocou
takzvaného vertex a fragment shadera. Vertex shader dovol’uje zmenit’ geometrické dáta
pred vykreslením, zatial’ cˇ o fragment shader umožˇnuje simuláciu svetelných javov na
povrchu objektu.
V JME je základný svetelný shader vytvorený, spolu s niektorými d’alšími. Jeho vertex
ako aj fragment shader sú uložené pomocou súboru .j3md, ktorý je predaný d’alej aplikácií.
Ak sú v tomto súbore definované premenené pomocou ktorých meníme nastavenia shaderov,
potom môžeme ovplyvˇnovat’ vzhl’ad objektu zasielaním správ pre zmenu príslušných
parametrov. Ukážka predchádzajúcej cˇ asti kódu túto situáciu popisuje. Po zvolení typu
materiálu13 nastavujeme parametre rozptýlenej a odrazenej zložky svetla, pri dopade na
povrch objektu ako aj jeho lesk. Taktiež sa dajú nastavit’ jednotlivé mapy, ktoré sa budú
mapovat’ na daný objekt, ako napríklad základná textúra, alebo mapa deformácie objektu14 .
Obr. 5.8: Vytvorenie geometrie objektu
13 Materiál
obsahuje pedpripravný vertex a fragment shader
pod termínom bump map, ktorá sa používa pre simuláciu zakrivenia povrchu objektu
14 Známejšia
51
Nastavenie kamery a pohyb po scéne
Na monitore sú zobrazované prvky, ktoré zachytí objekt typu Camera. To ktoré prvky v
zábere kamery sú, a ktoré nie, urˇcuje pohl’adový kužel’ kamery15 . Ten je ohraniˇcený prednou
ˇ
a zadnou orezávaciou stenou16 . Dalej
ho definuje pomer strán zobrazovacej plochy a
vertikálny zorný uhol(FOV 17 ), priˇcom horizontálny zorný uhol je dopoˇcítaný. Kamera je
potom urˇcená týmto zobrazovacím kužel’om, d’alej polohou kamery a orientáciou kamery18 .
Obr. 5.9: Popis kamery
Pri požiadavke na otoˇcenie kamery okolo daného vektora, sú smerové vektory kamery
upravené transformaˇcnou maticou, vyjadrujúcou rotáciu okolo daného vektora. Ak chceme
s kamerou pohnút’ v smere natoˇcenia, vynásobíme smerový vektor ~F s rýchlost’ou pohybu
15 Známy
ako view frustum.
sú zahraniˇcné výrazy near clipping plane a far clipping plane
17 FOV – Field of view
18 Orientácia kamery je urˇ
~ ~L
cená predným,horným a l’avým smerovým vektorom kamery - ~F, U,
16 Používané
52
kamery, a nastavíme kamere novú polohu, ktorá bude súˇctom starej polohy a pripraveného
smerového vektora. Pri prechode budovou je žiadúci pohyb rovnobežný s rovinou podlahy,
preto pri takomto druhu pohybu vynulujeme vertikálnu zložku smerového vektora.
Približovanie, cˇ i oddialenie obrazu kamery je uskutoˇcnené pomocou zmeny vertikálneho
zorného pol’a. Ak chceme obraz oddialit’, tento uhol zväˇcšíme, cˇ o spôsobí väˇcšiu plochu
záberu a teda aj menšie zobrazované objekty. Pri priblížení zorný uhol zasa zmenšíme. Použité
nové pojmy zobrazuje obrázok 5.9 , aj s cˇ ast’ami kódu pre pohyb kamery.
Interakcia s objektami scény
Užívatel’ovi je umožnené oznaˇcit’ objekt použitím kurzora myšky, ktorou zacieli na
požadovaný objekt a zaklikne ho. Kód vykonaný na pozadí tejto akcie je uvedený nižšie. Po
zakliknutí myšky je zistená súradnica kurzora, ktorá je za pomoci premietacej matice kamery
transformovaná do trojrozmerného bodu. Týmto bodom je preložený kolízny lúˇc, ktorý
zaznamená zrážky z grafom scény do zoznamu kolízií, ktoré sú d’alej ošetrované.
Listing 5.3: Zdrojový kód pre selekciu objektov
// Ziskaj kameru sceny a inicializuj zoznam kolizii
Camera camera = enviro . getGraphicsManager (). getActiveCam (). getCamera ();
CollisionResults results = new CollisionResults ();
// Transformuj 2 D suradnice kliku na 3 D
Vector2f click2d = enviro . getInputManager (). getCursorPosition ();
Vector3f click3d = camera . getWorldCoordinates
( new Vector2f ( click2d .x , click2d . y ) , 0 f );
// Vytvor vektor smeru oznacenia
Vector3f dir = camera . getWorldCoordinates
( new Vector2f ( click2d .x , click2d . y ) , 1 f ). subtractLocal ( click3d );
// Inicializuj luc selekcie na zaklade pociatku a smeru
Ray ray = new Ray ( click3d , dir );
// Vytvor kolizie luca s grafom sceny
enviro . getSceneGraph (). getRoot (). collideWith ( ray , results );
// Prechadzaj kolizie
if ( results . size () > 0) {
...
53
Konštrukcia stien
Pri vytváraní stien budovy je dôležité urˇcit’, akému poschodiu a miestnosti sa majú
skonštruované steny priradit’. To zabezpeˇcuje strom uzlov implementovaný v užívatel’skom
rozhraní, v ktorom sa po rozvetvení štruktúry budovy dopracujeme k miestnosti, ktorej steny
chceme vytvorit’.
Pre
l’ahšie
vytvorenie
modelu
budovy je možné naˇcítat’ jej pôdorys ,
ktorý sa zobrazí v scéne ako predloha.
Nástroje na to už boli popísané. Tento náˇcrt
pozostáva zo štvorcovej geometrie, ktorej je
ˇ
nutné nastavit’ textúrové súradnice. Dalej
je
tejto geometrií priradená textúra v správnej
orientácií,
ktorá
predstavuje
obrázok
ˇ
s pôdorysom budovy. Dalšími
úpravami
Obr. 5.10: Nastavenie predlohy
môžeme menit’ materiál, cˇ o sa týka jeho
farby a priehl’adnosti, cˇ ím docielime koneˇcný stav predlohy.
Oznaˇcenie kotevných bodov, na základe ktorých budú steny vystavané, používa už
popísanú selekciu objektov. Kolízia je detekovaná medzi vyslaným lúˇcom a danou
horizontálnou rovinou, ktorá urˇcuje výšku poschodia, ktorému steny pridávame. Z kotevných
bodov sa stanú spodné hrany vytvorených plôch, priˇcom boˇcné sa vytiahnu do užívatel’om
požadovanej výšky. Názornú predstavu popísaného postupu dáva obrázok 5.10 a 5.11.
Obr. 5.11: Oznaˇcenie kotevných bodov miestnosti a vytvorenie jej stien
54
5.3
Užívatel’ské rozhranie(guiFx)
Aplikácia zabezpeˇcuje interaktivitu s užívatel’om pomocou užívatel’ského rozhrania. Ked’že
je nutné vytvorit’ množstvo riadiacich panelov pre zadávanie príkazov, technológia pre
vytvorenie užívatel’ského rozhrania musí ponúkat’ jeho jednoduchú tvorbu a dobrú
organizáciu. Preto som sa rozhodol užívatel’ské rozhranie postavit’ na platforme JavaFX.
Platforma JavaFX
JavaFX19 je softvérová platforma zameraná na vývoj takzvaných RIA aplikácií. JavaFX
konkuruje Adobe Flash, cˇ i Microsoft Silverlight a môžem prehlásit’, že bude v blízkej
budúcnosti považovaná za hlavný nástroj pre tvorbu GUI20 v Jave.
JavaFX umožˇnuje cˇ iastoˇcné oddelenie návrhu GUI a aplikaˇcného kódu. Obsluha udalostí
spolu so štruktúru GUI komponentov, môžu byt’ zapísané pomocou kódu, ako aj využitím
XML zápisu v súboroch .fxml. Okrem toho ponúka menit’ vzhl’ad komponentov pomocou
kaskádových štýlov, ktoré sú vel’mi podobné tým webovým. Ja považujem za najlepšie
vytvorit’ GUI komponenty pomocou XML zápisu, a všetok kód na pozadí zapísat’ do
štandardných Java tried.
Obr. 5.12: GUI tlaˇcidlo vytvorené XML zápisom a trieda zodpovedná za ošetrenie udalostí
Štruktúra užívatel’ského rozhrania
Pre jednoduché vytváranie a integrovanie GUI panelov, každý panel dedí z triedy BasePane,
ktorá realizuje abstraktnú triedu BaseControl. V nich sa nachádzajú algoritmy pre naˇcítanie
19 Popísaná
20 GUI
je verzia JavaFX 2.0. Staršia verzia používa skriptovací jazyk JavaFX Script
- Graphical user interface (grafické užívatel’ské rozhranie )
55
použitých kaskádových štýlov, jazykovú podporu21 a príslušný .fxml súbor, ktorý definuje
štruktúru daného panela. Tieto panely sú potom integrované do GUI a zodpovedajú za
funkcionalitu vyplývajúcej z urˇcenia panela.
Obr. 5.13: Štruktúra GUI tried
V aplikácií sa grafický kontext sncény vykresl’uje v samostatnom JME vlákne, ako d’alšia
aplikácia. O jeho správne umiestnenie a natiahnutie sa stará vlákno na pozadí, ktoré detekuje
zmenu okna, na ktorú reaguje zodpovedajúcou zmenou vel’kosti a polohy vykresl’ovacieho
plátna.
Zasielanie správ grafickému vláknu
Nakol’ko vykresl’ovanie beží v JME vlákne a nie v GUI vlákne, priame volania metód
grafického kontextu nie sú možné. V prípade že meníme graf scény z iného vlákna ako JME,
ˇ
dôjde k vyvolaniu výnimky neoprávnenej modifikácie jeho dát. Dalej
popíšem mechanizmus
na riešenie tohto problému.
Riešením je vytvorenie fronty udalostí22 , ktoré sa budú vykonávat’ v cˇ ase, ked’ vlákno
JME bude vlastnit’ cˇ as procesora. Fronta ako dátová štruktúra obsahuje inštancie, ktoré
realizujú funkcionálne rozhranie Event. Vytvorené inštancie implementujú jedinú metódu
doAction, do ktorej umiestníme požadované príkazy pre modifikáciu grafu scény. Pri
vykonávaní vykresl’ovacej sluˇcky grafického kontextu je volaná metóda execute nad
21 Texty
v GUI zodpovedajú nastavenému jazyku
fronty správ
22 Respektíve
56
naplnenou frontou udalostí, ktorá volá metódy doAction jej udalostí typu Event v poradí
typickom pre frontu, cˇ ím dôjde k jej vyprázdneniu. Tento postup ilustruje obrázok 5.14,
spolu s diagramom tried.
Obr. 5.14: Diagram fronty udalostí
Podobne ako JME vláknu, tak ani JavaFX vláknu nemôžeme menit’ dáta, pokial’ nie je
aktívne. Ak proces bežiaci v JME vlákne chce poslat’ správu užívatel’skému rozhraniu, túto
správu odošle pomocou metódy Platform.runLater(Runnable), kde ako parameter predá
anonymnú triedu funkcionálneho rozhrania Runnable, s implementovanou metódou
run()(vid’ nižšie).
Listing 5.4: Zaslanie správy do GUI vlákna
Platform . runLater ( new Runnable () {
@Override
public void run () {
// prikazy pre vykonanie v JavaFX vlakne
// GUI_FX komponent -> zmen parametre ( farba , velkost ) , atd ...
}
});
57
5.4
Vyhl’adanie kritickej cesty(pathFinder)
Pre vyhl’adanie najkratšej cesty k danému miestu budovy využívam Dijkstrov algoritmus.
Avšak skôr ako je aplikovaný, je nutné vytvorit’ graf reprezentujúci budovu. K tomu
využívam siet’ku bodov, vloženú do scény spolu s budovou, po ktorej sa môže prípadný
páchatel’ pohybovat’. Rozlíšenie siet’ky a jej vel’kost’ sa nastaví podl’a potreby, teda podl’a
vel’kosti objektov v scéne.
Siet’ka môže byt’ dvojrozmerného, ako aj trojrozmerného charakteru23 . Vnútorný bod
tejto siet’ky je viazaný s jeho susednými bodmi pomocou príslušných úsekov24 . Tie sú
zobrazené do hrán grafu, zatial’ cˇ o body siet’ky predstavujú jeho vrcholy. Dijkstrov
algoritmus požaduje hranovo ohodnotený graf, preto ešte musíme vytvoreným hranám
priradit’ ohodnotenie, ktoré zodpovedá potrebnému cˇ asu na prekonanie daného úseku.
Ohodnotenie úseku je odvodené z ohodnotenia bezpeˇcnostného bodu, ktorým daný úsek
prechádza. Daný bezpeˇcnostný bod je urˇcený z interakcie úseku s grafom scény, ktorý pre toto
zistenie kolízie využíva nato urˇcenú dátovú štruktúru BIH 25 . V prípade že k žiadnej kolízií
nedošlo, hrana sa ohodnotí vopred urˇcenou konštantou. Nad takto vytvoreným grafom je už
možné aplikovat’ Dijkstrov algoritmus, vyhl’adat’ cestu a zobrazit’ ju.
Obr. 5.15: Zobrazenie budovy na graf a vyhl’adanie kritickej cesty
23 V
prípade poschodových budov
ˇ
sú l’avý, pravý, predný a zadný. Dalej
ich môžu rozširovat’ diagonály a vertikály
25 BIH - Bounding interval hierarchy
24 Základné
Kapitola 6
Záver
V tejto diplomovej práci som rozobral možnosti tvorby grafických aplikácií a následne som
vytvoril aplikáciu zameranú na vizualizáciu a manipuláciu topologických dát budov. Prácu
som rozdelil na teoretickú a praktickú cˇ ast’.
V teoretickej cˇ asti som analyzoval grafické formáty vhodné pre reprezentáciu budov,
spolu s možnost’ami tvorby priestorovej grafiky v programovacom jazyku Java. Pre potreby
zabezpeˇcovania budovy som popísal problematiku hl’adania najkratších ciest v grafoch spolu
so základnými algoritmami.
V praktickej cˇ asti som naˇcrtol implementaˇcné riešenia hlavných cˇ astí vytvorenej aplikácie.
Mojou hlavnou snahou bolo priblížit’ len dôležité cˇ asti programu, ktoré môžu byt’ pre cˇ itatel’a
zaujímavé, nie rutinné databázové pripojenia a podobne. Postupne som rozobral štruktúru pre
ˇ
reprezentáciu budovy v pamäti poˇcítaˇca, ako aj pre súborový výmenný formát. Dalej
som
implementoval editor a vizualizáciu budovy, ktorá bola postavená na knižnici JME3. Prácu
som zav´ršil popisom použitej platformy pre užívatel’ské rozhranie a spôsob vyhl’adávania
kritických ciest v budove.
Za hlavný prínos mojej práce považujem priblíženie 3D grafiky a jej využitie v praxi.
Taktiež aj prepojenie Javy a 3D grafiky, ktoré je poˇcítaˇcovej komunite doposial’ málo známe.
Samozrejme že pozitívnym výsledkom je aj fungujúca aplikácia na zabezpeˇcovanie budov. Pri
jej vývoji som prenikol do poˇcítaˇcovej grafiky a osvojil si pokroˇcilé techniky programovania.
58
Kapitola 7
Dokumentácia používatel’a
Manuál oboznámi cˇ itatel’a s možnosti programu ktoré poskytuje, spolu s jeho ovládaním.
7.1
Spustenie aplikácie
Program možno spustit’ zo súboru ibses.jar a to priamo využitím jeho ikony, alebo cez
príkazový riadok pomocou príkazu java -jar cesta...ibses.jar. Tento spustitel’ný
súbor sa musí nachádzat’ v adresári spolu s prieˇcinkom lib a storage, kde sú umiestnené
potrebné knižnice pre beh programu a uložené dáta. Potrebnú verziu Javy, ktorú musí mat’
užívatel’ v poˇcítaˇci a d’alšie požiadavky na spustenie upresˇnuje tabul’ka 7.1.
Operaˇcný systém
MacOSX, Windows, Linux, Solaris
Pamät’
> 10 MB
Grafická karta
AMD/ATI Radeon 9500, NVIDIA GeForce 5 FX, Intel GMA
4500, alebo lepšia podporujúca OpenGL 2.0, alebo novšiu verziu
CPU
> 1 GHz
Java Runtime
Java 7
Tabul’ka 7.1: Požiadavky na spustenie aplikácie
59
60
7.2
Štruktúra aplikácie
Pre rýchlejšie oboznámenie s aplikáciou je na obrázku 7.1 uvedená organizácia panelov, ktoré
budú bližšie popísané v nasledujúcom texte.
Obr. 7.1: Štruktúra aplikácie
ˇ
1. Hlavné menu : Poskytuje vytvorenie projektu, jeho naˇcítanie a uloženie. Dalej
sú tu
možnosti pre pridanie a odobranie ostatných riadiacich panelov.
2. Navigaˇcný panel : V tomto panely sa nachádza hierarchický strom organizácie
budovy, ktorého rozvetvením môžeme oznaˇcit’ požadované prvky. Panel obsahuje
d’alšie vnorené panely, ako panel vyhl’adávania podl’a identifikátora, panel vyhl’adania
kritickej cesty a panel pre tvorbu gradientovej mapy.
3. Editor : Editor takiež obsahuje strom uzlov budovy, ktoré môžeme pridávat’ a
odstraˇnovat’, cˇ ím vytvárame štruktúru budovy. Nachádzajú sa tu aj nástroje na tvorbu
stien a bezpeˇcnostných objektov, ako aj podpora pre naˇcítanie pôdorysu budovy a
kotvenie stien.
4. Nastavenie aplikácie : Obsahuje pomocné panely pre nastavenia parametrov programu
v príslušných oblastiach. Najhlavnejšie z nich sú nastavenia scény(pozadie, kamera . . . ),
nastavenia okna a jazyka.
61
5. Vykresl’ovacie plátno : Tento panel vykresl’uje scénu so všetkým, cˇ o sa v nej nachádza.
Spravuje ho samostatné vlákno rozdielne od GUI vlákna.
6. Informaˇcný panel : Ladenie programu je založené na textových výstupoch, ktoré môžu
byt’ smerodajné aj pre používatel’a.
7. Panel správ : Spodná lišta aplikácie upozorˇnuje správami užívatel’a na dôležité udalosti
ktoré nastali. Tie môžu mat’ informaˇcný, varovný a chybový charakter, cˇ omu zodpovedá
príslušné sfarbenie lišty, na ktorej sa zobrazuje správa.
7.3
Navigácia v scéne
Pre pohyb po scéne je užívatel’ovi poskytnuté intuitívne ovládanie pomocou kláves.
Natáˇcanie kamery je zabezpeˇcené pomocou klávesových šipiek, ako aj pohybom myšky.
Rýchlost’ pohybu a otáˇcania kamery je možné nastavit’ spolu s inými vlastnost’ami v panely
Scéna->Kamera.
Ak chceme pri prehliadke budovy oznaˇcit’ konkrétny prvok, je nutné zmrazit’ kameru
pravým tlaˇcidlom myšky, alebo klávesou s . V prípade že sme zablúdili, klávesou r vrátime
kameru do základnej pozície. Pri prechádzaní budovou je fixovaná výška pozorovatel’a, cˇ ím
je držaný stále v rovine rovnobežnej s podlahou. Ak si tento efekt neželáme a chceme s íst’
tam kam mieri kamera, potom pri pohybe držíme klávesu lCtrl .
Klávesa
Popis pohybu
Klávesa
Popis pohybu
w
dopredu
←
dol’ava
s
dozadu
→
doprava
a
dol’ava
↑
nahor
d
doprava
↓
nadol
q
dohora
lCtrl
vol’ný pohyb
z
dodola
c, lAlt
zmrazenie kamery
r
reštart pozície
Tabul’ka 7.2: Pohyb kamery
Tabul’ka 7.3: Otáˇcanie kamery
62
Obr. 7.2: Rozloženie riadiacich panelov
Ak chceme oznaˇcit’ viacero prvkov hromadne, musíme pri ich oznaˇcovaní držat’ klávesu
lCtrl . Oznaˇcovat’ prvky sa dá aj využitím organizaˇcného stromu budovy v l’avom panely,
kde sú znázornené poschodia, miestnosti a steny budovy. Tieto uzly tu môžu byt’ nastavené
ako neviditel’né, alebo ako zamrznuté, cˇ o znemožní ich oznaˇcenie. Nad oznaˇcenými objektami
d’alej môžeme aplikovat’ drôtený model, zmenu materiálu a polohy. Výhodné je aplikovanie
transparentného materiálu na objekty, ktoré chceme spriehl’adnit’, cˇ ím dosiahneme sklenného
efektu týchto prvkov.
V prípade že chceme zistit’ informácie o objekte, o ktorom vieme iba to aký ma názov,
využijeme panel pre vyhl’adávanie. V nˇ om zvolíme aké typy objektov sa majú hl’adat’, spolu
s filtrom vyhl’adávania. Nájdené objekty sú zobrazené v zozname výsledkov vyhl’adávania.
Po vybratí prvku z tohto zoznamu si môžeme nechat’ zacielit’ polohu kamery na jeho pozíciu.
Obr. 7.3: Pred a po aplikovaní transparentného materiálu na steny budovy
63
7.4
Konštrukcia budovy
Pravý panel užívatel’ského rozhrania predstavuje editor budovy s jeho pomocnými nástrojmi
pre kotvenie a zobrazovanie predlohy. Predloha je naˇcítaná zo štandardného grafického
súboru(.png, .jpg . . . ) v panely Skica/Ná£rt. Rozvrhnutie komponentov tohto panela je
zobrazené na obrázku 7.4. Po zadaní cesty k súboru s predlohou, je d’alej možné nastavenie
jeho rozmerov, umiestnenia a podfarbenia. Výhodné je nastavit’ farbu podkladu rozdielnu od
farby stien pre ich kontrast, alebo pridanie transparentnej zložky, ktorá sprehl’adní
modelovanie budovy.
Obr. 7.4: Nastavenie predlohy pre modelovanie
Pred samotnou tvorbou stien budovy, teda jej hmotnej stránky, je potrebné vytvorit’
organizaˇcnú štruktúru budovy. Nato je urˇcený panel Editor budovy. V jeho hornej cˇ asti sa
nachádza stom reprezentujúci hierarchiu budovy. Kliknutím pravým tlaˇcidlom na koreˇnový
uzol sa zobrazí možnost’ pre pridanie budovy. V dolnej cˇ asti panela sú následne vytvorené
zadávacie komponenty pre popis budovy. Po vyplnení zadávacieho formulára zvolíme
možnost’ na definitívne pridanie, následne sa budova zobrazí ako uzol v strome navigácie.
Ak teraz zaklikneme tento nový uzol pravým tlaˇcidlom myšky, na výber sa ponúkne
možnost’ vymazat’ budovu, upravit’ budovu a pridat’ miestnost’. Pri pridaní sa program
správa analogicky k už popísanému pridávaniu budovy.
Poschodiu je pri pridaní zobrazená ponuka pridat’ miestnost’. Po vyplnení jej názvu je
nutné d’alej urˇcit’ jej okrajové body, z ktorých sa vytvoria steny miestnosti. Pre presnejšie
64
zadávanie okrajových bodov, v panely Kotvenie nastavíme ich aktívne kotvenie k mriežke,
spolu so zobrazovaním znaˇcky miesta, kde bude bod pridaný. Ak sme sa poˇcas zadávania
bodov pomýlili, potom podl’a potreby použijeme tlaˇcidlo Spä´. Ak modelujeme
viacposchodovú budovu, je nutné nastavit’ výšku stien a odsadenie miestnosti od prízemia,
teda jej eleváciu nad zemou.
Pri konštrukcií budovy je vhodné kamere nastavit’ paralelný režim premietania, pri
ktorom sú rovnobežné steny zobrazené rovnako, nezávisle od položenia kamery. Paralelnú
projekciu zhora a zboku ilustruje obrázok modelovania budovy 7.5. Prepínanie paralelného a
perspektívneho premietania zabezpeˇcuje klávesa num5 a pohl’ad zhora klávesa num7 .
Obr. 7.5: Konštrukcia stien budovy
Konštrukcia bezpeˇcnostných objektov
Bezpeˇcnostné objekty predstavujú v budove dvere, okná, mreže a podobne. Ich pridanie na
konkrétnu stenu prebieha podobne ako vytváranie miestností. Po oznaˇcení steny, ktorej
chceme objekt pridat’, sa rozbalí navigaˇcný strom až na úroveˇn samotnej steny. Tá je
oznaˇcená a podobne ako pri inom pridávaní, pravým tlaˇcidlom vyberieme z ponuky možnost’
pridat’ bezpeˇcnostný objekt, cˇ ím sa nám otvorí zadávací panel bezpeˇcnostného objektu. Po
zadaní jeho názvu stlaˇcíme tlaˇcidlo Vytvori´ a vyznaˇcíme krajné body, na základe ktorých
sa objekt vytvorí a nanesie na stenu. Tento proces je zachytení na obrázku 7.6.
Po vytvorení bezpeˇcnostného objektu mu priradíme bezpeˇcnostné prvky, teda konkrétne
zabezpeˇcovacie zariadenia. Tabul’ka Bezpe£nostné prvky, uvádza všetky aplikované prvky
65
na objekt. Vybratý prvok zo zoznamu všetkých prvkov, aplikujeme tlaˇcidlom Prida´. Tento
zoznam je filtrovaním možné zúžit’ na prvky sp´lˇnajúce špecifike požiadavky, ktorý spustíme
pomocou tlaˇcidla Filtrova´.
Obr. 7.6: Pridávanie bezpeˇcnostných prvkov
Aby sme v našom modely znemožnili páchatel’ovi prechádzat’ medzi jednotlivými
poschodiami, musíme priradit’ miestnostiam podlahy a stropy. Aby sme ich nemuseli
zadávat’ po jednom vytvoríme jeden strop pre celé poschodie, teda jeho deku. Tú pridáme v
panely Poschodie, kde nastavíme výšku stropu, stlaˇcíme tlaˇcidlo Deka a štandardne
oznaˇcíme krajné body vytváranej plochy. Otvor v stene cˇ i podlahe modelujeme pridaním
objektu bez bezpeˇcnostných prvkov, cˇ o predstavuje nulový cˇ as na jeho prekonanie.
Modelovanú budovu pred a po vytvorení jej deky znázorˇnuje obrázok 7.7.
Obr. 7.7: Vytvorenie deky poschodia
66
Naˇcítanie a ukladanie projektu
Vytvorený model si môžeme nechat’ uložit’ do pripojenej databázy, alebo na lokálny súbor.
Súborové zálohovanie sprístupnime v hlavnom menu príkazom Projekt->Uloº->Do
súboru, kde si bud’ oznaˇcíme ciel’ový súbor, alebo zadáme názov pre nový. Ten istý panel
slúži aj na naˇcítanie, staˇcí si zvolit’ súbor a nechat’ ho naˇcítat’. Pre ukladanie do databázy
musíme
vytvorit’
databázové
spojenie
s
príslušnou
databázou
v
panely
Nastavenia->Databáza, zktorý slúži aj na naˇcítanie projektu z databázy. Potom staˇcí len
zvolit’ v hlavnom menu Projekt->Ulož->Do databázy.
Obr. 7.8: Naˇcítanie a uloženie projektu použitím XML súboru a databázového spojenia
7.5
Nájdenie kritickej cesty
Vyhl’adanie najkratšej, teda kritickej cesty je realizované v l’avom panely na karte Kritická
cesta. Pred samotným vyhl’adaním je nutné vytvorit’ graf reprezentujúci budovu stlaˇcením
tlaˇcidla Prepo£ítaj. Následne môžeme vykonat’ l’ubovolný poˇcet vyhl’adaní v scéne, no ak
došlo k modifikácií dát budovy, je nutné graf znova prepoˇcítat’.
Kritická cesta je urˇcená zaˇciatoˇcným a koncovým bodom. Zaˇciatoˇcný bod predstavuje
zaˇciatok cesty a koncový miesto do ktorého sa snažíme dostat’. Zaˇciatoˇcný bod môžeme
napríklad umiestnit’ mimo budovu, ak chceme zistit’ preniknutie z vonku. Zaklikneme
tlaˇcidlo Za£iatok a klikneme na požadované miesto pre zaˇciatoˇcný bod v scéne. Ak má bod
ležat’ v danej výške, nastavíme výšku prichytávacej siet’ky v panely Kotvenie.V scéne
meníme polohu zaˇciatoˇcného bodu , pokým nie je tlaˇcidlo Za£iatok znovu odkliknuté.
67
Koncový bod sa urˇcí analogicky, no tentoraz využijeme tlaˇcidlo Koniec. Po nastavení
urˇcujúcich bodov cesty stlaˇcíme tlaˇcidlo Vyh©adaj kritickú cestu, cˇ im dôjde k
vypoˇcítaniu a zobrazeniu kritickej cesty v scéne.
Obr. 7.9: Vl’avo zaˇciatoˇcný, vpravo koncový bod kritickej cesty
Po zobrazení cesty sú všetky prekonané bezpeˇcnostné objekty utriedené v tabul’ke podl’a
poradia v akom nasledujú, spolu s cˇ asom prekonania. Položky tabul’ky môžeme oznaˇcit’, cˇ ím
dôjde aj k oznaˇceniu príslušného objektu v scéne. Pri prechádzaní cesty si môžeme využitím
navigátora zobrazit’ budovu po poschodiach. Dobrým riešením je aj spriehl’adnenie celej
budovy, cˇ ím vidíme cez jej steny, a následné oznaˇcenie všetkých prekonaných objektov
pomocou tlaˇcidla Ozna£ v scéne.
Obr. 7.10: Aplikovanie transparencie na budovu a vyznaˇcenie prekonaných prvkov
Zoznam obrázkov
1.1
Vytvorený databázový model
. . . . . . . . . . . . . . . . . . . . . . . . .
2.1
Zl’ava vektorová a rastrová reprezentácia
2.2
Vykreslenie cˇ iary v DXF formáte
8
. . . . . . . . . . . . . . . . . . .
12
. . . . . . . . . . . . . . . . . . . . . . .
16
2.3
Štruktúra SVG formátu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.4
Štruktúra OBJ formátu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.1
Kompilácia programu prekladaˇcom javac [19]
. . . . . . . . . . . . . . . .
23
3.2
Spustenie programu na rôznych platformách [19] . . . . . . . . . . . . . . .
24
3.3
Typická štruktúra grafu scény
. . . . . . . . . . . . . . . . . . . . . . . . .
29
3.4
Graf scény v Java 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.5
Logá uvedených API. Menovite zl’ava: Java 3D, Xith3D, jME . . . . . . . .
32
4.1
Úloha nájdenia kritickej cesty k oznaˇcenému miestu . . . . . . . . . . . . . .
33
4.2
Zl’ava hranovo a vrcholovo-ohodnotený graf . . . . . . . . . . . . . . . . . .
35
4.3
Abstrakcia budovy na hranovo ohodnotený neorientovaný graf . . . . . . . .
35
4.4
Zl’ava Dijkstrov a A* algoritmus na vyhl’adanie optimálnej cesty[12] . . . .
38
5.1
Diagram prípadov použitia aplikácie . . . . . . . . . . . . . . . . . . . . . .
41
5.2
Diagram modulov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.3
Návrhový model tried . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.4
Triedy pre ukladanie dát do databázy . . . . . . . . . . . . . . . . . . . . . .
45
5.5
Štruktúra výmenného súboru pre zálohovanie . . . . . . . . . . . . . . . . .
46
5.6
Diagram základných tried pre graf scény aplikácie . . . . . . . . . . . . . . .
46
5.7
Graf scény aplikácie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
68
69
5.8
Vytvorenie geometrie objektu . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.9
Popis kamery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.10 Nastavenie predlohy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.11 Oznaˇcenie kotevných bodov miestnosti a vytvorenie jej stien . . . . . . . . .
53
5.12 GUI tlaˇcidlo vytvorené XML zápisom a trieda zodpovedná za ošetrenie udalostí 54
5.13 Štruktúra GUI tried . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.14 Diagram fronty udalostí . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.15 Zobrazenie budovy na graf a vyhl’adanie kritickej cesty . . . . . . . . . . . .
57
7.1
Štruktúra aplikácie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
7.2
Rozloženie riadiacich panelov . . . . . . . . . . . . . . . . . . . . . . . . .
62
7.3
Pred a po aplikovaní transparentného materiálu na steny budovy . . . . . . .
62
7.4
Nastavenie predlohy pre modelovanie . . . . . . . . . . . . . . . . . . . . .
63
7.5
Konštrukcia stien budovy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
7.6
Pridávanie bezpeˇcnostných prvkov . . . . . . . . . . . . . . . . . . . . . . .
65
7.7
Vytvorenie deky poschodia . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
7.8
Naˇcítanie a uloženie projektu použitím XML súboru a databázového spojenia
66
7.9
Vl’avo zaˇciatoˇcný, vpravo koncový bod kritickej cesty . . . . . . . . . . . . .
67
7.10 Aplikovanie transparencie na budovu a vyznaˇcenie prekonaných prvkov . . .
67
Zoznam tabuliek
2.1
Grafické prvky DXF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.2
Atribúty pre entitu typu LINE . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3
Identifikátory prvkov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.4
Identifikátory pre vrcholy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.5
Niektoré d’alšie vektorové formáty pre príslušné programy . . . . . . . . . .
21
7.1
Požiadavky na spustenie aplikácie . . . . . . . . . . . . . . . . . . . . . . .
59
7.2
Pohyb kamery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
7.3
Otáˇcanie kamery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
70
Literatúra
[1] Murray, J.- VanRyper , W. Encyklopedie grafických formát˚u, Computer Press Brno.
ISBN 80-85896-18-4
[2] http://www.cadwiki.cz/CAD.ashx
[3] http://www.fileformat.info/format/dxf/egff.htm
[4] http://www.root.cz/clanky/vektorovy-graficky-format-dxf/
[5] http://www.w3.org/TR/SVG/
[6] http://www.root.cz/clanky/vektorovy-graficky-format-svg/ic=serial-boxicc=text-title
[7] Davison, A. Programování dokonalých her v Javˇe, Computer Press a.s., Brno, 2006.
ISBN 80-7226-944-5
[8] http://www.opengl.org
[9] http://jogamp.org/jogl/www/
[10] http://xith.org/index.php?switch=features
[11] http://jmonkeyengine.org/
[12] http://theory.stanford.edu/ amitp/GameProgramming/AStarComparison.html
[13] RYBÁRIK, M. Vizualizácia zložitej dátovej štruktúry s hierarchickým charakterom dát.
Žilina: Žilinská Univerzita v Žiline. Fakulta riadenia a informatiky, Katedra Informatiky.
Vedúci: RNDr. Miroslav Benedikoviˇc, 2012. 47.s
71
72
[14] milos seleceni
[15] Zakhour, S.- Hammel, S.- Royal, J.- Rabinovitch, I.- Risser, T.- Hoeber, M. Java 6
Výukový kurz, Computer Press a.s., Brno, 2007. ISBN 978-80-251-1575-6
[16] http://www.oracle.com/technetwork/java/langenv-140151.html
[17] Palúch, S. Algoritmická teória grafov. Žilinská Univerzita v Žiline, 2008. 265.s
[18] MATULOVÁ, N. Grafy a grafové algoritmy. Brno: Vysoké uˇcení technické v Brnˇe,
Fakulta podnikatelská, 2009. 55 s. Vedoucí bakaláˇrské práce Mgr. Martina Bobalová,
Ph.D.
[19] http://docs.oracle.com/javase/tutorial/getStarted/intro/definition.html
[20] http://hub.jmonkeyengine.org/wiki/doku.php/jme3
[21] http://lwjgl.org/
[22] http://www.ej-technologies.com/products/jprofiler/overview.html
[23] World
of
mathematics,
wolfram.com/,
A
WolframAlpha
//www.wolframalpha.com/.
Wolfram
–
Web
Resource,
computational
http://mathworld.
knowledge
engine,
http:
Download

ŽILINSKÁ UNIVERZITA V ŽILINE DIPLOMOVÁ PRÁCA