ŽILINSKÁ UNIVERZITA V ŽILINE

FAKULTA RIADENIA A INFORMATIKY

DIPLOMOVÁ PRÁCA

Študijný odbor: Informacné 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 MICHAL: 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.

Stupen odbornej kvalifikácie: Inžinier v odbore Informacná 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 bezpecnostných systémov budov.

Aplikácia musí umožnovat’ tvorbu topológie budovy spolu s jej bezpecnostnými prvkami a

ich priamu interakciu s užívatel’om. Z takto vytvorenej topológie je možné získat’ najkratšiu

cestu k zabezpecovanému objektu v budove a následne ju zobrazit’.

Abstract

RYBÁRIK MICHAL: 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 cerpal.

V Žiline, dna 16.4.2014 Michal Rybárik

Pod’akovanie

Dakujem doc. Ing. Penke Martincovej za jej ochotu a cenné rady, ktorými ma usmernovala

pocas 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 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

4 Vyhl’adanie kritickej cesty 33

4.1 Budova ako graf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.1 Základné pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3

4

4.1.2 Transformácia na graf . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 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

5 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é spolocnosti pri ochrane svojho majetku investujú nemalé financné zdroje do

zabezpecenia budov. Analýza zabezpecenia priestorov budovy je tvorená zväcša priamo v

technickom pláne budovy, ktorý obsahuje použité zabezpecovacie komponenty v

dverách,oknách a podobne. Avšak nie je z neho jednoduché urcit’, akú najkratšiu dobu bude

prípadný páchatel’ potrebovat’ na prelomenie zabezpecenia 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 bezpecnostných prostriedkov. Úlohou práce je takýto nástroj navrhnút’ a

implementovat’ v programovacom jazyku Java. Editor bezpecnostných prvkov a databázový

model bol vytvorený v projektovej výucbe1 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é crty. V druhej kapitole

preskúmame rôzne grafické formáty pre zobrazovanie dvojrozmerných a trojrozmerných

objektov, pricom 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ú cast’. V nej navrhnem a implementujem

dátovú a aplikacnú vrstvu programu. Šiesta kapitola predstavuje záver diplomovej práce, po

ktorej nasleduje dokumentacná prírucka k vytvorenej aplikácií.

1Expertný systém pre hodnotenie bezpecnostných systémov ochrany objektov

5

Kapitola 1

Analýza úlohy

Ako bolo v úvode nacrtnuté, úlohou práce je vytvorit’ aplikáciu na hodnotenie

bezpecnostných prvkov v budove. Pre možné nedorozumenie je na mieste podotknút’, že sa

jedná o hodnotenie bezpecnostných prvkov budovy s pohl’adu ich pevnosti a odolnosti voci

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 pocítaca 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 bezpecnostných systémov ochrany objektov’ databáza1 , ktorej model je

zobrazený na obrázku 1.1.

Koncept modelu je tvorený z dvoch castí : topologickej a bezpecnostnej. Preto aj

informácie uložené v databáze delíme na bezpecnostné, ktoré popisujú dvere, okná ... a

topologické, urcujúce tvar budovy. Štruktúra budovy je hierarchicky clenená z poschodí,

miestností a stien, pricom základným stavebným prvkom je plocha. Plocha predstavuje

priestorový prvok, na ktorý sú mapované bezpecnostné prvky. Tie nesú už konkrétnu

informáciu o použitých materiáloch, odolnosti ci typu.

1Implementovaná objektovo-relacný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 nefunkcné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 ci odoberanie bezpecnostných prvkov, má

umožnovat’ editor. Pre zjednodušenie práce konštruktéra, editor nacíta pôdorys budovy,

alebo podobný podkladový nácrt, podl’a ktorého je umožnené expertovi vytvorit’ jednotlivé

casti budovy. Zmenou súcasnej konštelácie použitých zabezpecovacích prvkov sa ovplyvnuje

celkové zabezpecenie 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 zabezpecovacích

prostriedkov poskytnút’ túto najkratšiu trasu. Následne je dobré túto cestu ju vyznacit’ spolu

s bezpecnostný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, co zvýraznuje zohl’adnit’ aj výškový

aspekt budovy. Preto je trojrozmerná priestorová reprezentácia budovy ovel’a prirodzenejšia

ako len jej nácrt pôdorysu a poskytuje expertovi celkový komplexnejší prehl’ad. Ci je vôbec

možné efektívne tvorit’ trojrozmernú grafiku, založenú na platforme Java, si rozoberieme v

tretej casti.

8

Obr. 1.1: Vytvorený databázový model

Kapitola 2

Grafické formáty

Pre úcely aplikácie je nutné poznat’ štruktúru zabezpecovanej 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 nespocetne vel’a rôznych grafických formátov. Ich vývoj

nastal z dôvodu coraz väcšej potreby efektívne ukladat’ a prenášat’ grafické dáta. Niektoré

formáty vznikli za bránami komercných spolocností 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 . . . ).1Taktiež 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

animacné 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é, animacné a multimediálne formáty

Scénové formáty 2 sú používané pre ukladanie obrazovej predlohy, alebo scény, ktorú pocítac

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 urcit’ presnú hranicu medzi vektorovým a scénovým

formátom je nel’ahké a casto je to aj vec vkusu.

Základnou myšlienkou animacný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ší, coho výsledkom je plynulý pohyb. Najzákladnejšie animacné formáty

majú uložené všetky predlohy, ktoré sú potom postupne zobrazované a to casto v cykle. Tie

pokrocilejšie ukladajú len jednú obrazovú predlohu, spolu s viacero farebnými mapami,

ktoré sa v predlohe menia. Moderné animacné 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 pocítacové 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].

2Zná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 ci 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 hlavicky, 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 spocí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 ci farba.

Vektorový formát v sebe zahrna objekty, ktoré sú tvorené z menších, jednoduchších

objektov. Rozlíšenie súboru je potom dané detailnost’ou matematického opisu, pricom

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í zahrnovat’ dokonca ani špeciálny editor, jednoducho postací

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].

3Oznacuje sa ako farebná hlbka

12

Obr. 2.1: Zl’ava vektorová a rastrová reprezentácia

2.2 Vektorovo orientované formáty

Reprezentovat’ casti 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 bezpecnostný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, ci už statickej alebo

animovanej.

2.2.1 CAD formáty

CAD alebo pocítacom podporované projektovanie je odbor, využívajúci pocítacové 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é

4CAD - Computer-Aided Design („pocítacom podporovaný návrh“ )

13

dokumentácie v papierovej alebo elektronickej podobe, alebo 3D modely obsiahnuté v

príslušných grafických formátoch.

Pokrocilejšie špecializované CAD nástroje dokážu okrem vizualizácie realizovat’ aj

rôzne inžinierske analýzy a výpocty. Tie sa zameriavajú skôr na konkrétny obor urcenia.

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 nacítanie a je prispôsobená potrebám

AutoCAD-u[3].

Organizácia súboru

DXF súbor je rozdelený do sekcií, pricom každá zacína svojím identifikátorom a koncí

znackou konca sekcie. To je výhodne napríklad ked’ potrebujeme nacítat’ informácie len o

geometriách, program potom môže iné sekcie preskocit’ a zacat’ od konkrétneho miesta.

Sekcie delíme na :

• HEADER - Hlavicka 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 ciar . . .

• BLOCKS - V tejto sekcií sú uložené bloky, co sú zlúcené entity pod jeden identifikátor,5DWG - DraWinG6DXF - Drawing Exchange Format7DXB – Drawing Exchange Binary8táto sekcia sa objavila až v novších verziách DXF

14

Entita Popis

POINT Bod, ktorý môže byt’ l’ubovol’ne natocený zadaným uhlom

LINE Úsecka zadaná dvoma dvoma bodmi

TRACE Úsecka s nenulovou šírkou nazývaná aj stopa

POLYLINE Spojená lomená ciara, 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 ohranicujú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- Znacka reprezentujúca koniec súboru na poslednom riadku[4].

Zápis grafických prvkov

Medzi najcastejš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 ciar a farba. Tabul’ka 2.2

popisuje atribúty pre entitu LINE. Obrázok 2.2 predstavuje cast’ DXF súboru, v ktorej sa

definujú prvky pre vykreslenie. Ako ilustracný príklad znázornuje vykreslenie úsecky v

trojrozmernom priestore. Sekcia zacína príznakom sekcie, za ktorou nasledujú entity a ich

parametre. Tie sú zapísané v tvare £íslo skupiny-nový riadok-hodnota parametra.

9Hladiny je možné napríklad vypnút’ alebo zmrazit’

15

Císlo skupiny Popis

62 Farba entity

8 Oznacenie 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 nacítat’. Ked’že majú na

nepárnych riadkoch uvedené atribúty a na riadkoch kladných ich hodnoty, je nací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ý pocet 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á úsecka musí bit’ zapísaná aspon

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, preco vznikla popri DXF jeho menšia binárna forma

DXB[4].

16

Obr. 2.2: Vykreslenie ciary 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ú urcené 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 znackovací jazyk, zapísaný XML11 štruktúrou, ktorý slúži pre popis dvojrozmernej

grafiky, ci 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, co ho neurcuje len pre statické použitie.

10SVG - Scalable Vector Graphics)11XML - 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’, ci inak

upravovat’ uzly stromu, coho 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 úseciek, eliptických kružníc a kubických ci

Bézierových kriviek. Ako bude daná cesta vykreslená, záleží na nastavených štýloch

vykreslenia ako napríklad farba, štýl ciar, ší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, úsecku, lomenú ciaru, obdlž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 case, a tým vytvárat’

animáciu. Popísané sú iba kl’úcové stavy elementov, pricom ich medzistavy sú

generované automaticky[5][6].

Ukážkový príklad na obrázku 2.3 ilustruje štruktúru SVG formátu.

12DOM – 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 prehliadacoch, 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, coho dôsledok je absencia špickového vývojového

prostredia, akým je napríklad Macromedia pre konkurencný komercný formát Flash. Taktiež

podpora nie je ešte úplná vo všetkých prehliadacoch, 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 znacne

neefektívny, co 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’rocí 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 ci

19

chybicky 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 ci 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 casto 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 zabezpecený pomocou bodov, ciar 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 hlavicku, ako je tomu u iných formátoch. Každý

riadok zací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 zvycajne bývajú názvy

súborov s materiálmi, ktoré budme potrebovat’. Nasleduje sekcia z vrcholmi, ktoré majú

13Pomocou prípony .obj14Prostredníctvom prípony .mod

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

p Bod

l Ciara

f Plocha

curv Krivka

surf Rovina

Tabul’ka 2.3: Identifikátory prvkov

Dáta vrcholov Popis

v Geometrické vrcholy

vt Štrukturálne vrcholy

vn Vrcholové normály

vp Parametrické vrcholy

g Skupina

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 casti práce som sa venoval možnost’ami prevažne vektorových grafických formátov.

Tie boli rozdelené do kategórií, pricom 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 doplnujúce informácie o typoch bezpecnostných prvkov by

sme museli doplnit’ rucne, 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

nací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 pocítacových hier, alebo Hollywoodskych filmových

efektov. S jej aplikáciami sa coraz castejš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, co 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 operacný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ýnimocnou 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 aplikacného

programového rozhrania API3. JVM spracuváva bajtový kód, zatial’ co API predstavuje

1OpenGL - Open Graphics Library2JVM - Java Virtual Machine3API - Application Programming Interface

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 prekladacom 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ý,

• bezpecný.

Význam jednotlivých pojmov citatel’ 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.

4IDE - 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 preco 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

prekladaca. Hotspot technológia, využívaná od verzie J2SE5 1.3 umožnuje prekladacu

identifikovat’ kritické casti programu. Sú to casti programu, ktoré zaberajú najviac

procesorového casu, takéto miesta potom sa prekladac snaží preložit’ s vel’kým dôrazom na

výkon[7].5J2SE - 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é prekladacom 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, pricom po

prekrocení 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’ casti 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

nacítanie alebo zápis do pamäti grafickej karty, sa nedokážu vykonávat’ dostatocne 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

dostatocne rýchle ako v jazyku assembler. A napriek tomu je dnes tento názor opacný[7].

Na záver pojednania o jazyku Java a jeho použitie pre 3D aplikácie môžeme zhrnút’, že

v nom 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 voci Jave boli opodstatnené na konci

minulého storocia, kedy tento jazyk nebol svojimi knižnicami tak prepracovaný ako je tomu

dnes[7].

6JNI - 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 pocítacovej grafike. Nie je tomu ani tak dávno kedy sa o

všetku prácu, co sa týka grafických operácií a konecného vykreslenia, staral procesor

pocítaca. Preto nebolo dostatocne možné spracovat’ a vykreslit’ vel’ké množstvo dát. Vel’ké

spolocnosti si tento problém uvedomovali a zacali 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 spolocnost’ SGI8, ktorá sa špecializovala na vývoj softvéru a hardvéru

zameraného na pocítacovú 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

spolocnost’ou SGI odstránené spolu s cast’ami, ktoré sa netýkali pocítacovej grafiky. V roku

1992 spolocnost’ SGI uviedla toto upravené rozhranie pre prácu s pocítacovou grafikou v

reálnom case, pod názvom OpenGL[14].

Vývoj OpenGL ovplyvnili hlavne spolocnosti 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é pocítace,

existuje odl’ahcená verzia OpenGL ES[14].

Na zaciatku OpenGL podporovalo funkcie pre prácu s bodmi ako transformácie ci

farebné operácie. Poradie týchto funkcií bolo pevne dané, co sa oznacuje ako fixná

pipeline10. Od verzie OpenGL 2.0 je zabudovaná programovatel’ná pipeline, ktorá umožnuje

7CPU - Central Processing Unit8SGI - Silicon Graphics9Iris GL - Integrated Raster Imaging System Graphics Library

10Predstavuje zret’azené spracovanie grafických operácií

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,

• aplikacného rozhrania pre prácu s grafom scény,

• väzby na herný systém.

Väzby na herné systémy predstavujú aplikacné 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 citatel’ nájst’

na [8]. Prvotné väzby jGL a GL4Java12 boli vel’mi obl’úbené, ich výhoda spocí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ádace, volanty a joystiky, pomocou jednoduchého API. Síce písanie programov v LWJGL

11Shader je program na riadenie jednotlivých castí grafickej pipeline12GL4Java - OpenGL for Java13OpenCL - Open Computing Language14OpenAL - Open Audio Library

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 ci 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 JNI15. Ponúka prístup ako ku GL*, tak aj GLU*

funkciám, no prístup ku knižnici GLU16 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’ pokrocilé techniky pocítacovej

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 coraz viac uplatnované využitie enginov, ktoré poskytujú predpripravené

knižnice, cím ul’ahcujú a zrýchl’ujú vývoj aplikácie.

Tieto aplikacné rozhrania najcastejšie obsahujú možnosti nacítania modelov, zvukových

formátov a video formátov. Taktiež riešia problémy s mapovaním textúr, alebo interakciu s

15JNI - Java Native Interface16GLUT - OpenGL Utility Toolkit

29

objektami. Typickým crtom 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, ci iné

operácie. Tento návrh v konecnom dôsledku ul’ahcuje 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 aplikacné rozhranie obsahuje sadu konceptov na vysokej úrovni pre tvorbu a

manipuláciu s grafom scény. Vd’aka vysokoúrovnový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 zlucuje 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ýnimocné 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 ukoncený. Príjemná správa prišla v roku 2012, kedy sa na Jave 3D zacalo opät’

pracovat’, co 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 nom môžu byt’

zdielané viacerými rodicmi. 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é urcujú 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, ovplyvnujúce

iné uzly scény za behu programu. Takýto uzol najcastejš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ž zozaciatku umožnoval volat’ operácie

rozhrania OpenGL. Táto skutocnost’ znamenala podporu funkcionality pre výpocet tienov,

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,

• Nací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-úrovnový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á

oznacenie 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 ci ohen. 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ívnovat’

programový kód. Pre import modelov je zasa nápomocná priama spolupráca s 3D

modelovacím nástrojom Blender. Dobrou crtou je aj jeho dobrá dokumentácia a vel’a

dostupných tutoriálov. V neposlednom rade je užitocná aj vel’ká komunita používatel’ov, co

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,

• Nacítanie modelov vo formátoch: blend, ogrexml, obj, COLLADA, scene, a coskoro 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 ci 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 zacal 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 mna engin jME. Toto najmladšie aplikacné 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

bezpecnostných prvkov budovy akými sú dvere, mreže ci okná. Ked’že vieme cas príchodu

zásahových zložiek pri spustení alarmu, prácou experta je nastavit’ bezpecnostný systém tak,

aby doba prekonania systému prekrocila cas príchodu ochranky. S uvedeného vyplýva zistit’

najkratší možný cas dosiahnutia daného miesta v budove, spolu so zoznam prekonaných

prvkov zabezpecenia. Tieto pojmy môžeme nazvat’ aj ako kritický cas 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 cast’ diskrétnej

matematiky nazvanej teória grafov, zaoberajúca sa vlastnost’ami grafov. Problém nájdenia

kritickej cesty spolu s casom si znázorníme na dvojrozmernom prípade ilustrujúci obrázok

4.1.

Obr. 4.1: Úloha nájdenia kritickej cesty k oznacenému miestu

33

34

4.1 Budova ako graf

4.1.1 Základné pojmy

Graf

Charakteristickou crtou 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

konecná 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 zacínajú a koncia 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. Stupen vrcholu potom definujeme ako pocet hrán, ktoré prislúchajú danému

vrcholu. Oznacujeme ho deg(v) pricom 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, co znací ci 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’ co

hranovo ohodnotený graf je graf s ohodnotenými hranami4[18].

1V takom prípade hovoríme o slucke2Ak sú všetky vrcholy susedné hovoríme o úplnom grafe3Každému vrcholu prislúcha hodnota4Každej hrane prislúcha hodnota

35

Sled, t’ah a cesta

Striedavú postupnost’ vrcholov a hrán v grafe oznacujeme 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 konecne 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 oznacené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

bezpecnostných prvkov budovy. Vrcholmi tohto grafu budú miestnosti budovy a hranami

36

grafu budú bezpecnostné prvky, ktoré ich oddel’ujú(steny,okná,mreže,dvere . . . ). Graf bude

hranovo-hodnotený, pricom hodnoty hrán budú reprezentovat’ jednotlivé casy prekonania

bezpecnostných prvkov. Cas prekonania steny z miestnosti A do B bude vždy rovnaký ako

cas prekonania opacným smerom, preto vytvorený graf bude neorientovaný a bez sluciek.

Transformáciu modelu budovy na graf ilustruje obrázok 4.3. Ako prvé vytvoríme vrcholy

oznacujúce jednotlivé miestnosti a pridáme im spájajúce hrany. V l’avom obrázku sú nacrtnuté

možné prechody do miestnosti 3, pricom ak je medzi dvomi vrcholmi viacero možných ciest

do grafu stací 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 cast’ 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 pociatocného uzla do všetkých,= ostatných uzlov,

• hl’adania najkratšej cesty z pociatocného do koncového uzla.

4.2.1 Dijskstrov algoritmus

Je algoritmus pre zostrojenie najkratšej cesty v hranovo ohodnotenom grafe medzi

pociatocný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 nekonecno s výnimkou

pociatocného. Vytvoríme zoznam nenavštívených vrcholov, ktorý obsahuje všetky

vrcholy okrem pociatocného, ktorý vyberieme za aktuálny.

Krok 2: Susedným vrcholom aktuálneho vypocí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 prepocítaní všetkých susedných uzlov odstránime aktuálny uzol zo zoznamu

nenavštívených vrcholov.

Krok 3: Ak sme oznacili ciel’ový vrchol ako navštívený, potom jeho aktuálna vzdialenost’ je

definitívna a algoritmus môžeme ukoncit’. Pokial’ chceme zistit’ najkratšie vzdialenosti

medzi d’alšími vrcholmi, oznacíme nenavštívený vrchol s najmenšou vzdialenost’ou

ako aktuálny a pokracujeme krokom 2.

Po ukoncení algoritmu máme v každom vrchole jeho najkratšiu vzdialenost’ k

pociatocnému vrcholu a vrchol, z ktorého sme ho dosiahli. Postupným prechádzaním

vrcholov môžeme zistit’ presné smerovanie cesty až do pociatocného uzlu. Zložitost’

Dijkstrovho algoritmu je O(n2), avšak ak nás zaujíma len cesta medzi dvoma vrcholmi,

algoritmus skoncí 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 urceným

pociatocným a koncovým vrcholom. Je postavený na Dijkstrovom algoritme, od ktorého sa

líši pridaným heuristickým prvkom. Toto vylepšenie usmernuje prechod grafom v

najsl’ubnejšom smere, cím sa znižuje pocet navštívených vrcholov.

Táto heuristika približne urcuje 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 konecného5. Tá priradí5Odhad 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 skoncení 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, pricom 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, co má za následok zlú výpoctovú zložitost’ (O(n3)). Pre

aplikácie v praxi má uplatnenie napríklad pri tvorbe železnicného grafikonu, kde má lepšie

vlastnosti ako násobne použitý Dijkstrov algoritmus pre všetky vrcholy.

Algoritmus ktorý sa zameriava výlucne 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, co 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 castí. 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é

castí programu, zadefinujme úlohy, ktoré bude užívatel’ požadovat’.

Na obrázku 5.1 je zobrazený diagram prípadov použitia, ktoré urcujú 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’

bezpecnostné prvky. Takto vytvorený model môže d’alej používatel’ uložit’ a v prípade

potreby zase nací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 oznacením priamo v scéne, alebo po

vyhl’adaní v nato urcenom panely. Po úprave bezpecnostný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 zabezpecovací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ý strucný popis jednotlivých balíkov, ktoré si

bližšie priblížime v nasledujúcich castiach.

• buffer : Tento modul udržuje štruktúru budovy v pamäti pocítaca 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 pocítaca, alebo

zvolenú databázu. Dáta ktoré obsahuje, ponúka d’alším modulom pre ich následné

1Vývoj aplikácie pre projekt ’Expertný systém pre hodnotenie bezpecnostný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 oznacovanie objektov. Tu sa takisto nachádza podpora pre

vytváranie plôch a bezpecnostný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 JavaFX2, 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 nou 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é zahrna, 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

2JavaFX 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žitocná 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ý

zabezpecuje jej prepojenie s grafom scény, ktorý zaobstaráva vykresl’ovanie prvkov .

Obr. 5.3: Návrhový model tried

3Balík s týmto názvom zodpovedá v programe za implementáciu riešených castí, uvedených v texte4AVL 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é clenské premenné pre špecifikovanie konkrétnej

vlastnosti prvku v hierarchií budovy. Zoznam potomkov, ktorý zdedili z abstraktného typu,

využívajú na zoskúpenie úrovnovo nižších prvkov budovy. Teda inštancia typu Building v

nom 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 zhmotnuje doposial’ zavedená kostra. Okrem toho obsahuje aj

zoznam bezpecnostný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

zabezpecovacích elementov. Tieto prvky sú charakterizované inštanciami triedy

SecurityElement, ktorá realizuje abstraktnú triedu Entity. Typ SecurityElement

obsahuje všetky potrebné informácie o zabezpecovanom prvku ako jeho typ, odolnost’ a

zloženie.

Ukladanie a nací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, co 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é.

5Anglické 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á, zabezpecuje 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, urcí Mapper. Nacítanie dát z databázy, a ich

prevedenie na model budovy prebieha podobne v opacnom 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 nací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, co zjednodušuje jeho nacítanie a zápis. Preto pre tieto potreby bola

využitá vol’ná externá knižnica dom4j6. Pomocou nej je spracovanie súborov dostatocne

pohodlné, najmä vyhl’adanie sekcie dát podl’a kl’úcového slova a jej nací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 3D6Dom4j 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, co 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 strucnosti typ

Geometry reprezentuje hmotné objekty, ktoré budú nakoniec zobrazené, zatial’ co 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

7Koren stromu sa oznacuje ako rootNode, pricom 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

nacítaný model budovy, popísanou v predchádzajúcej casti. 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 konecnom 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

8Anglický 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 casti stien. Plocha 9 obsahuje hrany, ktoré ju ohranicujú, cim tvoria konvexný

alebo nekonvexný polygón. Najcastejš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, pricom zadefinujeme smer pre ich vykresl’ovanie. Poradie

vykresl’ovania vrcholov má dopad na to, z ktorej strany bude plocha viditel’ná12. Pre

tienovanie 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.5f);

// pridaj texturu povrchu

material.setTexture("ColorMap", getAssetManager ().

loadTexture("kamen.jpg"));

// pridaj vyskovu deformaciu povrchu

material.setTexture("BumpMap", getAssetManager ().

loadTexture("bump.jpg"));

9Plochu reprezentuje trieda Face10Používanejší výraz je mesh11Castejší výraz pre tento typ zásobníku je buffer12V prípade nastavenia príznaku mapovania na Mode.BothSide, sa budú vykresl’ovat’ obe strany

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 casti 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’ co 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 ovplyvnovat’ vzhl’ad objektu zasielaním správ pre zmenu príslušných

parametrov. Ukážka predchádzajúcej casti 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

13Materiál obsahuje pedpripravný vertex a fragment shader14Známejšia pod termínom bump map, ktorá sa používa pre simuláciu zakrivenia povrchu objektu

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, urcuje pohl’adový kužel’ kamery15. Ten je ohranicený prednou

a zadnou orezávaciou stenou16. Dalej ho definuje pomer strán zobrazovacej plochy a

vertikálny zorný uhol(FOV17), pricom horizontálny zorný uhol je dopocítaný. Kamera je

potom urcená týmto zobrazovacím kužel’om, d’alej polohou kamery a orientáciou kamery18.

Obr. 5.9: Popis kamery

Pri požiadavke na otocenie kamery okolo daného vektora, sú smerové vektory kamery

upravené transformacnou maticou, vyjadrujúcou rotáciu okolo daného vektora. Ak chceme

s kamerou pohnút’ v smere natocenia, vynásobíme smerový vektor ~F s rýchlost’ou pohybu

15Známy ako view frustum.16Používané sú zahranicné výrazy near clipping plane a far clipping plane17FOV – Field of view18Orientácia kamery je urcená predným,horným a l’avým smerovým vektorom kamery - ~F , ~U ,~L

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, ci oddialenie obrazu kamery je uskutocnené pomocou zmeny vertikálneho

zorného pol’a. Ak chceme obraz oddialit’, tento uhol zväcšíme, co 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 cast’ami kódu pre pohyb kamery.

Interakcia s objektami scény

Užívatel’ovi je umožnené oznacit’ 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 2D suradnice kliku na 3D

Vector2f click2d = enviro.getInputManager (). getCursorPosition ();

Vector3f click3d = camera.getWorldCoordinates

(new Vector2f(click2d.x, click2d.y), 0f);

// Vytvor vektor smeru oznacenia

Vector3f dir = camera.getWorldCoordinates

(new Vector2f(click2d.x, click2d.y), 1f). 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é urcit’, akému poschodiu a miestnosti sa majú

skonštruované steny priradit’. To zabezpecuje strom uzlov implementovaný v užívatel’skom

rozhraní, v ktorom sa po rozvetvení štruktúry budovy dopracujeme k miestnosti, ktorej steny

chceme vytvorit’.

Obr. 5.10: Nastavenie predlohy

Pre l’ahšie vytvorenie modelu

budovy je možné nací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

môžeme menit’ materiál, co sa týka jeho

farby a priehl’adnosti, cím docielime konecný stav predlohy.

Oznacenie 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á urcuje výšku poschodia, ktorému steny pridávame. Z kotevných

bodov sa stanú spodné hrany vytvorených plôch, pricom bocné 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: Oznacenie kotevných bodov miestnosti a vytvorenie jej stien

54

5.3 Užívatel’ské rozhranie(guiFx)

Aplikácia zabezpecuje 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, ci 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 ciastocné oddelenie návrhu GUI a aplikacné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 tlacidlo 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 nacítanie

19Popísaná je verzia JavaFX 2.0. Staršia verzia používa skriptovací jazyk JavaFX Script20GUI - 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 urcenia 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 case, ked’ vlákno

JME bude vlastnit’ cas 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 slucky grafického kontextu je volaná metóda execute nad21Texty v GUI zodpovedajú nastavenému jazyku22Respektíve fronty správ

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’ co 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 casu na prekonanie daného úseku.

Ohodnotenie úseku je odvodené z ohodnotenia bezpecnostného bodu, ktorým daný úsek

prechádza. Daný bezpecnostný bod je urcený z interakcie úseku s grafom scény, ktorý pre toto

zistenie kolízie využíva nato urcenú dátovú štruktúru BIH25. V prípade že k žiadnej kolízií

nedošlo, hrana sa ohodnotí vopred urcenou 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

23V prípade poschodových budov24Základné sú l’avý, pravý, predný a zadný. Dalej ich môžu rozširovat’ diagonály a vertikály25BIH - Bounding interval hierarchy

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ú cast’.

V teoretickej casti som analyzoval grafické formáty vhodné pre reprezentáciu budov,

spolu s možnost’ami tvorby priestorovej grafiky v programovacom jazyku Java. Pre potreby

zabezpecovania budovy som popísal problematiku hl’adania najkratších ciest v grafoch spolu

so základnými algoritmami.

V praktickej casti som nacrtol implementacné riešenia hlavných castí vytvorenej aplikácie.

Mojou hlavnou snahou bolo priblížit’ len dôležité casti programu, ktoré môžu byt’ pre citatel’a

zaujímavé, nie rutinné databázové pripojenia a podobne. Postupne som rozobral štruktúru pre

reprezentáciu budovy v pamäti pocítaca, 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 završ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 pocítacovej komunite doposial’ málo známe.

Samozrejme že pozitívnym výsledkom je aj fungujúca aplikácia na zabezpecovanie budov. Pri

jej vývoji som prenikol do pocítacovej grafiky a osvojil si pokrocilé techniky programovania.

58

Kapitola 7

Dokumentácia používatel’a

Manuál oboznámi citatel’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 priecinkom 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 pocítaci a d’alšie požiadavky na spustenie upresnuje tabul’ka 7.1.

Operacný 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 nacítanie a uloženie. Dalej sú tu

možnosti pre pridanie a odobranie ostatných riadiacich panelov.

2. Navigacný panel : V tomto panely sa nachádza hierarchický strom organizácie

budovy, ktorého rozvetvením môžeme oznacit’ 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

odstranovat’, cím vytvárame štruktúru budovy. Nachádzajú sa tu aj nástroje na tvorbu

stien a bezpecnostných objektov, ako aj podpora pre nací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, co sa v nej nachádza.

Spravuje ho samostatné vlákno rozdielne od GUI vlákna.

6. Informacný 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 upozornuje správami užívatel’a na dôležité udalosti

ktoré nastali. Tie môžu mat’ informacný, varovný a chybový charakter, comu 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 zabezpecené 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 oznacit’ konkrétny prvok, je nutné zmrazit’ kameru

pravým tlacidlom 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

w dopredu

s dozadu

a dol’ava

d doprava

q dohora

z dodola

r reštart pozície

Tabul’ka 7.2: Pohyb kamery

Klávesa Popis pohybu

← dol’ava

→ doprava

↑ nahor

↓ nadol

lCtrl vol’ný pohyb

c, lAlt zmrazenie kamery

Tabul’ka 7.3: Otácanie kamery

62

Obr. 7.2: Rozloženie riadiacich panelov

Ak chceme oznacit’ viacero prvkov hromadne, musíme pri ich oznacovaní držat’ klávesu

lCtrl . Oznacovat’ prvky sa dá aj využitím organizacné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é, co znemožní ich oznacenie. Nad oznacený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 nom 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 nací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’

organizacnú štruktúru budovy. Nato je urcený panel Editor budovy. V jeho hornej casti sa

nachádza stom reprezentujúci hierarchiu budovy. Kliknutím pravým tlacidlom na korenový

uzol sa zobrazí možnost’ pre pridanie budovy. V dolnej casti 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 tlacidlom 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 urcit’ 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 znacky miesta, kde bude bod pridaný. Ak sme sa pocas zadávania

bodov pomýlili, potom podl’a potreby použijeme tlacidlo 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 zabezpecuje klávesa num5 a pohl’ad zhora klávesa num7 .

Obr. 7.5: Konštrukcia stien budovy

Konštrukcia bezpecnostných objektov

Bezpecnostné objekty predstavujú v budove dvere, okná, mreže a podobne. Ich pridanie na

konkrétnu stenu prebieha podobne ako vytváranie miestností. Po oznacení steny, ktorej

chceme objekt pridat’, sa rozbalí navigacný strom až na úroven samotnej steny. Tá je

oznacená a podobne ako pri inom pridávaní, pravým tlacidlom vyberieme z ponuky možnost’

pridat’ bezpecnostný objekt, cím sa nám otvorí zadávací panel bezpecnostného objektu. Po

zadaní jeho názvu stlacíme tlacidlo Vytvori´ a vyznací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í bezpecnostného objektu mu priradíme bezpecnostné prvky, teda konkrétne

zabezpecovacie zariadenia. Tabul’ka Bezpe£nostné prvky, uvádza všetky aplikované prvky

65

na objekt. Vybratý prvok zo zoznamu všetkých prvkov, aplikujeme tlacidlom Prida´. Tento

zoznam je filtrovaním možné zúžit’ na prvky splnajúce špecifike požiadavky, ktorý spustíme

pomocou tlacidla Filtrova´.

Obr. 7.6: Pridávanie bezpecnostný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, stlacíme tlacidlo Deka a štandardne

oznacíme krajné body vytváranej plochy. Otvor v stene ci podlahe modelujeme pridaním

objektu bez bezpecnostných prvkov, co predstavuje nulový cas na jeho prekonanie.

Modelovanú budovu pred a po vytvorení jej deky znázornuje obrázok 7.7.

Obr. 7.7: Vytvorenie deky poschodia

66

Nací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’ oznacíme ciel’ový súbor, alebo zadáme názov pre nový. Ten istý panel

slúži aj na nacítanie, stací si zvolit’ súbor a nechat’ ho nací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 nacítanie projektu z databázy. Potom stací len

zvolit’ v hlavnom menu Projekt->Ulož->Do databázy.

Obr. 7.8: Nací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 stlacením

tlacidla Prepo£ítaj. Následne môžeme vykonat’ l’ubovolný pocet vyhl’adaní v scéne, no ak

došlo k modifikácií dát budovy, je nutné graf znova prepocítat’.

Kritická cesta je urcená zaciatocným a koncovým bodom. Zaciatocný bod predstavuje

zaciatok cesty a koncový miesto do ktorého sa snažíme dostat’. Zaciatocný bod môžeme

napríklad umiestnit’ mimo budovu, ak chceme zistit’ preniknutie z vonku. Zaklikneme

tlacidlo Za£iatok a klikneme na požadované miesto pre zaciatocný 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 zaciatocného bodu , pokým nie je tlacidlo Za£iatok znovu odkliknuté.

67

Koncový bod sa urcí analogicky, no tentoraz využijeme tlacidlo Koniec. Po nastavení

urcujúcich bodov cesty stlacíme tlacidlo Vyh©adaj kritickú cestu, cim dôjde k

vypocítaniu a zobrazeniu kritickej cesty v scéne.

Obr. 7.9: Vl’avo zaciatocný, vpravo koncový bod kritickej cesty

Po zobrazení cesty sú všetky prekonané bezpecnostné objekty utriedené v tabul’ke podl’a

poradia v akom nasledujú, spolu s casom prekonania. Položky tabul’ky môžeme oznacit’, cím

dôjde aj k oznaceniu 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é oznacenie všetkých prekonaných objektov

pomocou tlacidla Ozna£ v scéne.

Obr. 7.10: Aplikovanie transparencie na budovu a vyznacenie prekonaných prvkov

Zoznam obrázkov

1.1 Vytvorený databázový model . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Zl’ava vektorová a rastrová reprezentácia . . . . . . . . . . . . . . . . . . . 12

2.2 Vykreslenie ciary v DXF formáte . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Štruktúra SVG formátu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Štruktúra OBJ formátu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Kompilácia programu prekladacom 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 oznacené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 Oznacenie kotevných bodov miestnosti a vytvorenie jej stien . . . . . . . . . 53

5.12 GUI tlacidlo 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 bezpecnostných prvkov . . . . . . . . . . . . . . . . . . . . . . . 65

7.7 Vytvorenie deky poschodia . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.8 Nacítanie a uloženie projektu použitím XML súboru a databázového spojenia 66

7.9 Vl’avo zaciatocný, vpravo koncový bod kritickej cesty . . . . . . . . . . . . . 67

7.10 Aplikovanie transparencie na budovu a vyznacenie 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átu, 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 Jave, 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 Benedikovic, 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é ucení technické v Brne,

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, A Wolfram Web Resource, http://mathworld.

wolfram.com/, WolframAlpha – computational knowledge engine, http:

//www.wolframalpha.com/.