Finite Elements Visualization

(1)

Vizualizace kone ˇcn ´ych prvk ˚u

Finite Elements Visualization

(2)

(3)

(4)

(5)

Abstract

The main aim of this thesis is the implementation of the advanced visualization plug-in/addition to the application for viewing finite element method bodies. In particular, it is the techniques of body smoothing, advanced shading models, decomposition bodies on their subbodies etc. One of the secondary tasks is for example editing user interface. The thesis also includes performance tests and their evaluation.

(6)

DP – diplomov´a pr´ace

FPS – frame per second

(7)

3.1 Reprezentace tˇeles . . . 14 3.2 Zobrazovac´ı metody . . . 17 4 Implementace 23 4.1 Qt . . . 23 4.2 Struktura aplikace . . . 23 4.3 Implementované algoritmy . . . 24 5 Testován´ı 36 5.1 Testován´ı - fps . . . 38 5.2 Testován´ı - CPU . . . 40 5.3 Testován´ı - Pamˇet . . . 40 6 Závˇer 42 7 Reference 43

(8)

(9)

8 Stavba hraniˇcn´ıho modelu . . . 14 9 Troj ´uheln´ık . . . 15 10 CSG . . . 16 11 Mˇr´ıˇzka . . . 16 12 Raytracing . . . 19 13 Bounding box . . . 19

14 Hiearchie bounding boxu . . . 20

15 Octree . . . 20

16 Uk´azka Raytracingu . . . 21

17 Sch´ema vypoˇctu radiosity . . . 21

18 Ukázka dekompozice . . . 24 19 Ukázka vyhlazen´ı . . . 34 20 Ukázka QtTreePropertyBrowser . . . 35 21 Ukázka model 1 . . . 36 22 Ukázka model 2 . . . 37 23 Ukázka model 3 . . . 37

24 Testov´an´ı fps - stav v klidu . . . 38

25 Testov´an´ı fps -pracovn´ı stav . . . 38

26 Testov´an´ı fps s pr ˚uhlednost´ı . . . 39

27 Testov´an´ı CPU . . . 39

28 Testov´an´ı pamˇeti . . . 40

(10)

Seznam v ýpis ˚u zdrojov ého k ódu

1 Algoritmus pro rozklad Simple (UpdateMatrix) . . . 25

2 Pseudo algoritmus pro rozklad Tree (CreateLogic) . . . 26

3 Pseudo algoritmus pro rozklad Tree (CallUroven) . . . 27

4 Pseudo algoritmus pro rozklad Tree (NajdiShlukyRodic) . . . 27

5 Pseudo algoritmus pro rozklad Tree (UpdateMatrix) . . . 28

6 Pseudo algoritmus pro rozklad Springs (CreateLogic) 1/4 . . . 28

7 Pseudo algoritmus pro rozklad Springs (CreateLogic)2/4 . . . 29

10 Pseudo algoritmus pro rozklad Springs (UpdateMatrix) . . . 31

11 Pseudo algoritmus pro otoˇcen´ı norm´aly . . . 33

(11)

FEM je numerická metoda ˇreˇsen´ı, která se snaˇz´ı poskytnout pˇribliˇzné ˇreˇsen´ı. Tato metoda je ˇsiroce vyuˇz´ıvaná pˇri ˇreˇsen´ı statick ých i dynamick ých problém ˚u v r ˚uzn ých odvˇetv´ıch, jako jsou napˇr´ıklad mechanika kapalin, biomedicina, elektromagnetick ých jev ˚u apod. Hlavn´ım principem této metody je diskretizace spojitého prostoru na koneˇcné mnoˇzstv´ı prvk ˚u a následné interpolace mezi d ˚uleˇzit ými parametry, které jsou ve vrcho-lech tˇechto prvk ˚u.

Tato práce si mimo základn´ıch c´ıl ˚u, které byly vyjmenovány v ýˇse, klade i dalˇs´ı c´ıl, a to zachován´ı nebo vylepˇsen´ı urˇcit ých vlastnost´ı aplikace, ze které vycház´ı. Mezi tyto vlastnosti patˇr´ı hlavnˇe rychlost vykreslen´ı v ýsledk ˚u a vyuˇzit´ı pamˇeti RAM.

Tato diplomová práce navazuje na jiˇz existuj´ıc´ı projekt Ing. Petra Gajdoˇse, Ph.D. a dopl ˇnuje ho o v ýˇse uvedené funkce.

Hlavn´ı struktura pr´ace je:

1. Pˇredstaven´ı hlavn´ıch postup ˚u a metod pro vizualizaci koneˇcn ých prvk ˚u. 2. Anal ýza a návrh vybran ých vizualizaˇcn´ıch modul ˚u.

3. Implementace.

(12)

2 N ´avrh a anal ´yza

V této kapitole jsou informace o náhledu na strukturu modelu, která je zobrazována v aplikaci. Nalezneme zde základn´ı pohled na reprezentaci modelu, taktéˇz jsou zde popsány zdroje dat pro modely, se kter ými dokáˇze aplikace zacházet. V posledn´ı ˇcásti této kapitoly nalezneme popis zp ˚usobu uloˇzen´ı dat v pamˇeti poˇc´ıtaˇce.

2.1 Data

2.1.1 Reprezentace modelu

Objekt, kter ý je v aplikaci vykreslován a na kterém se provád´ı v ýpoˇcty, je tvoˇren mo-delem skládaj´ıc´ı se ze základn´ıch elementárn´ıch ˇcast´ı. Model se skládá z domén, které slouˇz´ı k rozdˇelen´ı sloˇzit ých model ˚u na menˇs´ı ˇcásti. Nad doménami se provád´ı operace posun, rotace nebo rozklad. Doména jiˇz nejde dále dˇelit, jedinou v ýjimkou je ˇrezan´ı po-moc´ı oˇrezové roviny nebo schováván´ı vybran ých element ˚u.

Obr´azek 1: Geometrick´a tˇelesa

Kaˇzdá doména se skládá z geometri´ı. Geometrie jsou geometrické objekty, které mo-hou nab ývat tvaru tetrahedron, pentahedron, hexahedron a octahedron. Základn´ı geo-metrické objekty jsou vyobrazeny na obrázku 1, kde objekt A je tetrahedron, B je penta-hedron, C je hexahedron a D je octahedron.

Soused´ıc´ı strany jednotliv ých geometri´ı mus´ı na sebe pˇresnˇe pˇriléhat. Nen´ı moˇzné, aby nˇejaká strana geometri´ı mˇela dva sousedy. Kaˇzdá geometrie se pak skládá z ele-ment ˚u. Eleele-menty jsou jednoduché základn´ı objekty, jako je troj úheln´ık a ˇctverec. Na obrázku 2 je ukázaná stavba hexahedronu. Hexahedron se skládá z 6 obdéln´ıku. Kaˇzd ý element se pak skládá z tˇr´ı pˇr´ıpadnˇe ˇctyˇr vrchol ˚u a v kaˇzdém vrcholu nebo na ploˇse je normála, která se pouˇz´ıvá pro osvˇetlován´ı pˇri vykreslován´ı.

Kaˇzd ý model m ˚uˇze obsahovat jeˇstˇe dodateˇcné informace. Tyto informace se váˇz´ı k vrchol ˚um geometri´ı a maj´ı informaˇcn´ı charakter, kter ý tˇreba slouˇz´ı k v ýpisu namˇeˇren ých hodnot teplot nebo hustoty.

2.1.2 Zdroje dat

Data lze nahrávat z lokáln´ıho disku nebo z online databáze. Nahráván´ı z disku podporuje formáty .geo a speciáln´ı formát. Pro nahráván´ı z online databáze je potˇreba b ýt pˇrihláˇsen na ˇskoln´ı s´ıti VˇSB-TUO.

(13)

Obr´azek 2: Hexahedron

Form át geo Formát .geo se skládá z jednoho souboru, ve kterém jsou obsaˇzeny vˇsechna data o modelu. Nejsou zde vˇsak obsaˇzené dodateˇcné informace. Strukturu formátu .geo obsahuje:

• n ´azev modelu

• datum vytvoˇren´ı modelu • nody

• elementy • vrcholy • aj..

Speci áln´ı form át Skládá se ze 2 textov ých souboru p.txt, t.txt. Neobsahuje dodateˇcné informace. V souboru p.txt se nacház´ı seznam vrcholu. Soubor t.txt je seznam element ˚u.

2.1.3 Strukt ˚ura dat

Pro uloˇzen´ı dat v pamˇeti byla zachována struktura modelu, ve kterém je naˇc´ıtána (pen-tahedron, hexahedron, oc(pen-tahedron,. . . ). Pro rychlejˇs´ı poˇc´ıtan´ı nˇekter ých problém ˚u byla struktura lehce upravena. Pˇrilehlé elementy dvou geometri´ı byly nahrazeny jedn´ım je-din ým elementem a znalost´ı geometri´ı, ke kter ým patˇr´ı.

Takováto struktura umoˇz ˇnuje rychlejˇs´ı v ýpoˇcet viditelnosti okrajov ých ploch. A pˇri klasickém zobrazen´ı zobrazovat pouze tyto plochy. Vlastnost´ı teto struktury je jedna normála pro dvˇe strany. Nedá se tedy urˇcit, na kterou stranu je element natoˇcen ý. Tato vlastnost bude jeˇstˇe pˇripomenuta pˇri popisu implementace osvˇetlen´ı.

Byla zachována i struktura domén, kdy kaˇzdá geometrie spadá do nˇejaké domény. Domény slouˇz´ı pouze k rozdˇelen´ı sloˇzitého modelu, napˇr´ıklad pro rozpad ˇci jinou ma-nipulaci. Nakonec jsou vˇsechny elementy pˇrerozdˇeleny do seznamu. Kaˇzd ý seznam má sv ˚uj pˇr´ıznak, podle kterého se urˇcuje, kam maj´ı b ýt elementy dány a také se podle flagu ˇr´ıd´ı vykreslován´ı. Flag obsahuje:

(14)

• GFT_LINE - Zda se jedn ´a o ´useˇcku.

• GFT_TRIANGLE - Zda se jedn á o troj úheln´ık. • GFT_QUAD - Zda se jedn á o ˇctverec.

• GFM_NONE - ˇZ´adn ´y flag nen´ı nastaven.

• GFM_IS_SELECTED - Urˇcuje, zda je dan ý element vybrán. • GFM_IS_BOUNDARY - Urˇcuje, zda je dan ý element hraniˇcn´ım.

• GFM_IS_REDUNDANT - Slou ˇz´ı pro prvotn´ı v ´ypoˇcet. D´ale v programu nen´ı pouˇzit.

2.2 Dekompozice 2.2.1 Uloha dekompozice´

U velk ých a sloˇzit ých model ˚u b ývá potˇreba zobrazit jejich ˇcásti tak, aby byly lépe vidˇet a nespokoj´ıme se s pouh ým schován´ım nˇekter ých ˇcásti. Proto pouˇz´ıváme dekompozici, tedy obvyklé rozloˇzen´ı ˇcásti modelu, tak aby kaˇzdá ˇcást byla lépe vidˇet. Povˇetˇsinou se to provád´ı posunut´ım nebo rotac´ı ˇcásti modelu.

Dekompozici provád´ıme na doménách modelu, protoˇze rozdˇelen´ı modelu na ˇcisté elementy by bylo ˇspatnˇe realizovatelné. Z tˇechto domén si bereme pouze jejich pozici (centrum) a pracujeme pouze s n´ı, jako s bodem.

2.2.2 Typy dekompozice

Byly navrhnuty tˇri typy technik pro dekompozici, které se liˇs´ı svou komplexnost´ı. Od nejjednoduˇsˇs´ı, která je jednoduchá na ovládán´ı, ale nenab´ız´ı prostor k manipulaci, aˇz po komplexn´ı, která je vhodná na sloˇzité typy modelu nebo specifické ovládán´ı rozpadu.

Simple Jedná se o jednoduchou dekompozici, kde se jednotlivé domény transformuji od poˇcátku stejnˇe rychle a nen´ı moˇznost je jakkoli ovlivnit ˇci zasahovat do ˇcásti modelu. Jediné moˇzné ovládán´ı je rychlost rozpadu vˇsech ˇcást´ı po osách x, y a z.

Tree Dekompozice Tree je oproti dekompozici Simple rozˇs´ıˇrena o jednoduchou logiku sdruˇzován´ı domén do shluk ˚u a kontrolován´ı tˇechto shluk ˚u.

Algoritmus se skládá ze tˇr´ı krok ˚u. Z poˇcáteˇcn´ıch domén se vytvoˇr´ı shluky a z tˇechto shluk ˚u se vytvoˇr´ı dalˇs´ı shluky. V tˇret´ı vlnˇe se z jiˇz vytvoˇren ých shluk ˚u vytvoˇr´ı jeden velk ý shluk. Dostáváme tak strom o hloubce tˇri, kde listy stromu jsou domény objektu. A uzly stromu reprezentuj´ı shluky.

Shluky se provád´ı na jednoduchém algoritmu, kter ý poˇc´ıtá vzdálenost´ı mezi doménami. Pokud je nalezen potencionáln´ı shluk, ve kterém je nejdelˇs´ı vzdálenost mezi doménami menˇs´ı neˇz pˇredem stanovena hranice, a pokud je poˇcet domén v tomto potencionáln´ım shluku vetˇs´ı neˇz poˇzadovaná hodnota, tak se z tˇechto domén vytvoˇr´ı shluk.

(15)

Obr´azek 3: Dekompozice Tree

Obdobnˇe tento algoritmus funguje i ve druhém kroku, kdy z vypoˇcten ých shluk ˚u tvoˇr´ıme dalˇs´ı shluky. Pro v ýpoˇcet pozice u shluku se pouˇz´ıvá aritmetick ý pr ˚umˇer vˇsech pozic domén ve shluku. Na obrázku 3a lze vidˇet poˇcáteˇcn´ı scénu s 11 doménami a obrázek 3b ukazuje, jak vypadá logické spojen´ı domén ve stromˇe pomoc´ı shluku po v ýpoˇctu.

Následná manipulace se stromem prob´ıhá tak, ˇze si uˇzivatel m ˚uˇze oznaˇcit uzly nebo listy stromu, u kter ých chce, aby se na nˇe dekompozice projevila nebo ne. Poté m ˚uˇze pouˇz´ıt rozpad po osách x, y a z, kter ý se projev´ı jen na ty domény, které si uˇzivatel zvolil. Byly provádˇeny pokusy o nalezen´ı jin ých geometrick ých útvar ˚u, neˇz je shluk, pˇresnˇeji kruˇznice, pˇr´ımka a rovina. Bohuˇzel od tˇechto technik bylo upuˇstˇeno, protoˇze nedávaly dobré v ýsledky.

Springs Pˇredcházej´ıc´ı dekompozice stavˇely své domény do jednoduch ých strom ˚u. Coˇz vˇsak nemus´ı vyhovovat u nˇekter ých sloˇzit ých model ˚u. Proto byla navrhnuta tˇret´ı de-kompozice, která stav´ı domény do grafu. V ideáln´ım stavu je kaˇzdá doména spojena s nejbliˇzˇs´ımi doménami hranami v grafu.

Graf je vytvoˇren pomoc´ı techniky zametán´ı roviny. Na zaˇcátku mˇejme dva seznamy. V jednom seznamu mˇejme seˇrazeny vˇsechny domény v nˇejaké ose. Druh ý seznam bude slouˇzit pro uchováván´ı právˇe zpracovávan ých domén. Seznam bude umˇet uloˇzit odkaz na doménu a k této doménˇe dalˇs´ı tˇri odkazy na domény, které budou reprezentovat do-sud nalezené tˇri nejbliˇzˇs´ı domény. Oznaˇcme tento seznam jako P.

Následnˇe procház´ıme se zametac´ı rovinou prvn´ım seznamem seˇrazen ých domén. U kaˇzdé domény se zastav´ıme a provedeme tˇri kroky.

V prvn´ım kroku zjist´ıme, zda se v seznamu P nenacház´ı domény, u kter ých uˇz m ˚uˇzeme ˇr´ıct, ˇze jsme naˇsli tˇri nejbliˇzˇs´ı domény. Pokud doména má uˇz nˇejaké tˇri nejbliˇzˇs´ı domény

(16)

Obr´azek 4: Pˇr´ıklad v ´ypoˇctu hran pomoc´ı zametac´ı roviny.

Obr´azek 5: Tuhost pruˇzin

vyplnˇené a vzdálenost od domény k zametac´ı rovinˇe je delˇs´ı neˇz vzdálenost domény a tˇret´ı nejbliˇzˇs´ı domény, tak jsme jiˇz pro danou doménu nalezli 3 nejbliˇzˇs´ı domény a m ˚uˇzeme ji vyˇradit a vytvoˇrit hrany.

V druhém kroku spoˇc´ıtáme pro kaˇzdou doménu v seznamu P vzdálenost s doménou na zametac´ı rovinˇe a za pˇredpokladu, ˇze je aspo ˇn tˇret´ı nejbliˇzˇs´ı , ji vloˇz´ıme do seznamu nejbliˇzˇs´ıch domén.

V tˇret´ım kroku pˇrid´ame do seznamu P dom´enu ze zametac´ı roviny.

Nakonec, aˇz projdeme cel ý seznam seˇrazen ých domén, tak vytvoˇr´ıme pro zb ývaj´ıc´ı body seznamu P hrany s dosud nalezen ými nejbliˇzˇs´ımi doménami.

Takto vytvoˇren ý graf ovládáme tak, ˇze vybereme doménu, kterou chceme posouvat, a pomoc´ı rozkladu ji posouváme po osách x, y a z. Domény, jenˇz jsou na tuto doménu pˇripojené , se posouvaj´ı o urˇcitou konstantu pomaleji. Dalˇs´ı domény, které jsou pˇripojeny k doménˇe, která se posouvala, se posouvaj´ı zase o urˇcitou konstantu pomaleji, atd. Po-sun jednotliv ých domén je znázornˇen vzorcem. Domény jsou brány vˇzdy s nejkratˇs´ı vzdálenosti od vybrané domény.

(17)

Pro lepˇs´ı objasnˇen´ı uved’me ukázku. Na obrázku 4 je situace, kdy v seznamu P je jiˇz bod d1, d2, d3, d4. Na zametac´ı rovinˇe je právˇe poˇc´ıtan ý bod d5. Bod d1 má ve svém seznamu nejbliˇzˇs´ıch domén hrany e1, e2, e3. Následnˇe se spoˇc´ıtá vzdálenost d1 a d5 a zjist´ı se, ˇze hrana e4 je bl´ıˇze neˇz e1, a proto se nahrad´ı.

2.3 Vedlej ˇs´ı ´ulohy

Pˇri tvorbˇe diplomové práce vznikaly malé, ale d ˚uleˇzité vedlejˇs´ı úlohy, které bylo potˇreba ˇreˇsit.

2.3.1 Vyhlazov ´an´ı

Pro lepˇs´ı vizuáln´ı vjem m ˚uˇze vzniknout poˇzadavek na vyhlazen´ı povrchu modelu. Pro v ýpoˇcet algoritmu na vyhlazen´ı povrchu mus´ıme sjednotit normály vrchol ˚u, jenˇz jsou identické, jenom kaˇzd ý patˇr´ı jiné geometrii. Pˇri sjednocen´ı normál zapoˇc´ıtáme nejdˇr´ıv pr ˚umˇernou normálu a poté kaˇzdé normále pˇriˇrad´ıme tuto pr ˚umˇernou normálu. Ne vˇsechny normály se ale pr ˚umˇeruj´ı, obvykle se urˇc´ı úhel mezi dvˇema normálami, kter ý urˇcuje mez, pˇri které daná normála se zpr ˚umˇeruje nebo se vynechá. O zbytek se postaraj´ı shadery. Ne kaˇzd ý shader vˇsak um´ı interpolovat normály, záleˇz´ı, jak je dan ý shader napsán. Na obrázku 6, lze vidˇet, jak se ze 4 vrcholu na sobˇe leˇz´ıc´ıch zpr ˚umˇeruj´ı normály.

Toto vˇsak nen´ı jediná metoda pro_”narovnán´ı normál“, dalˇs´ı metodou m ˚uˇze b ýt pˇriˇrazen´ı váhy kaˇzdé normále, podle toho, jak je dan ý polygon, jehoˇz je normála vrcholu souˇcást´ı, velk ý a poté, pˇri rovnán´ı normal se normály s vetˇs´ı váhou pod´ılej´ı v´ıce neˇz normály s menˇs´ı váhou.

2.3.2 Shadery

Grafické karty umoˇz ˇnuj´ı programovat ˇcást grafického ˇretˇezce grafické karty. Takov ýmto program ˚um ˇr´ıkáme shadery. Shadery se programuj´ı pomoc´ı speciáln´ıch programovac´ıch jazyk ˚u, napˇr. GLSL, Cg, HLSL. V dneˇsn´ı dobˇe máme nˇekolik typu shaderu. Mezi základn´ı patˇr´ı vertex shader, pixel shader a geometri shader. Vertex shader - Na vstupu pˇreb´ırá je-den vrchol a na v ýstupu vrac´ı jeje-den vrchol. Uvnitˇr funkce se obvykle realizuje nˇejaká transformace daného vrcholu. Geometry shader - Oproti vertex shader um´ı generovat nebo odeb´ırat vrcholy. Tento shader m ˚uˇzeme pouˇz´ıt tˇreba ke generován´ı vegetace. Pixel shader - Pouˇz´ıvá se u rasterizace a urˇcuje v ýslednou barvu pixelu.

(18)

Obrázek 6: Pr ˚umˇerován´ı normál

Tato diplomová práce pouˇz´ıvá pouze vertex a pixel shader. Pro v´ıce informac´ı o sha-derech doporuˇcuji pˇreˇc´ıst [2],[3],[4],[5] a [6].

Phong ˚uv osv ˇetlovac´ı model Phonguv osvˇetlovac´ı model na rozd´ıl od Gauradovoho st´ınovan´ı interpoluje normály nam´ısto pouhé interpolace barvy, a t´ım dosahuje lepˇs´ı vizuáln´ı vjem, hlavnˇe spekulárn´ı sloˇzka je poˇc´ıtána lépe. Pˇri v ýpoˇctu se do sebe zapoˇc´ıtává difusn´ı, ambientn´ı a spekulárn´ı sloˇzka.

Difusn´ı sloˇzka Difuzn´ı sloˇzka nám udává, jak se odráˇz´ı svˇetlo od daného materiálu.

Id= Cd∗ (I ∗ n) ∗ Ld (1)

Ambientn´ı sloˇzka Udává, jak moc dan ý materiál emituje vlastn´ı svˇetlo.

Ia= Ca∗ La (2)

Spekul árn´ı sloˇzka Spekulárn´ı sloˇzka je zde pro v ýpoˇcet odlesku materiálu.

Is= Cs∗ Ls∗ cosα(γ) (3)

Celková intenzita se poˇc´ıtá pro kaˇzdou sloˇzku RBG zvláˇst’.

(19)

(20)

3 Metody vizualizace

V této kapitole jsou popsány zakladn´ı typy dat. Prob´ırány jsou hraniˇcn´ı reprezentace pˇres CGS aˇz po voxelovou reprezentaci. Následnˇe jsou popsány techniky pro zobrazován´ı hraniˇcn´ıch tˇeles a objemov ých tˇeles. U hraniˇcn´ıch tˇeles to je hlavnˇe základn´ı zobrazovac´ı ˇretˇezec, ray tracing a radiozita.

3.1 Reprezentace t ˇeles 3.1.1 Hrani ˇcn´ı reprezentace

Nejbˇeˇznˇejˇs´ı reprezentaci objektu, se kterou se m ˚uˇzeme setkat, je hraniˇcn´ı reprezentace. Objekt je reprezentován pouze obalem. Pro zobrazen´ı nen´ı potˇreba vˇedˇet, co je uvnitˇr objektu, a tak se s informac´ı o vnitˇrn´ı reprezentaci objektu nepoˇc´ıtá. Obal nesm´ı b ýt ni-kde pˇreruˇsen, mus´ıme b ýt schopni rozliˇsit mezi bodem, kter ý by byl uvnitˇr nebo venku modelu.

Na obr´azku 8 vid´ıme, jak vypad´a napˇr´ıklad hraniˇcn´ı model krychle.

Obr´azek 8: Stavba hraniˇcn´ıho modelu

Nejˇcastˇeji se takov ýto model skládá z bod ˚u, hran a stˇen. Pokud by mˇela b ýt vyob-razena nˇejaká zakˇrivená plocha, tak se aproximuje na troj úheln´ıky. Dalˇs´ı potˇrebnou in-formac´ı je normála bodu a stˇeny. Tato informace nen´ı potˇrebná pro konstrukci modelu, ale neobejdeme se bez n´ı pˇri vykreslen´ı modelu. Hraje ned´ılnou souˇcást v pokroˇcil ých osvˇetlovac´ıch modelech jako je Phong ˚uv osvˇetlovac´ı model.

Nejstarˇs´ı hraniˇcn´ı reprezentaci je hranová reprezentace. Skládá se pouze ze seznamu bod ˚u a seznamu hran. V ýhodou hranové reprezentace je jej´ı úspora, avˇsak nev ýhodou je nejednoznaˇcnost objektu. D´ıky chybˇej´ıc´ı informaci o plochách m ˚uˇze nastat pˇr´ıpad, kdy má v´ıce r ˚uzn ých reprezentac´ı tˇeles.

Rozˇs´ıˇren´ım hranov´e reprezentace o informaci s plochami dostaneme ploˇskovou re-prezentaci. Seznam hran nahrad´ıme seznamem ploch. Nejˇcastˇeji se body plochy zapisuji

(21)

Obr´azek 9: Troj ´uheln´ık

proti smˇeru hodinov ých ruˇciˇcek, abychom byli schopni odvodit správnou normálu plo-chy a nemuseli tak uchovávat tuto informaci zvláˇst’.

Nejzákladnˇejˇs´ı ploˇskou je pouˇzit troj úheln´ık, protoˇze má dobré vlastnosti, napˇr´ıklad vˇsechny jeho body jsou vˇzdy v rovinˇe, je nejmenˇs´ı moˇznou plochou a m ˚uˇze se dobˇre dˇelit.

Bodová reprezentace je speciáln´ım pˇr´ıpadem. Uchováváme pouze body na povrchu tˇelesa. K bodu obvykle pˇridáváme nˇejakou dodateˇcnou informaci, napˇr´ıklad barvu. Obecnˇe ale tˇechto bod ˚u jsou miliony (aˇz stovky GB) a tedy tato metoda má velkou pamˇet’ovou nároˇcnost. Bodovou reprezentaci nejˇcastˇeji najdeme u skenován´ı objekt ˚u.

Okˇr´ıdlen é plo ˇsky Tato reprezentace uchovává u hran informaci o bodech na zaˇcátku a konci, o vˇsech pˇrilehl ých hranách, sousedn´ıch plochách a libovolnou dalˇs´ı hranu. V ýhody: rychlé nalezen´ı sousedn´ıch ploch, rychlé nalezen´ı smyˇcky hran, plocha nemus´ı b ýt kon-vexn´ı, plocha m ˚uˇze obsahovat d´ıry.

Konstruktivn´ı geometrie t ˇeles Z jednoduch ých geometrick ých tˇeles jako je kvádr, válec, jehlan, ale i NURBs plocha, vytvoˇr´ıme pomoc´ı mnoˇzinov ých operac´ı v ýsledné tˇeleso. Mezi mnoˇzinové operace ˇrad´ıme pr ˚unik, sjednocen´ı a rozd´ıl. Operace a jednoduchá tˇelesa ˇrad´ıme do stromu, tak abychom dostali oˇcekávané komplexn´ı tˇeleso.

3.1.2 Objemov ´a reprezentace

Pro vizualizaci mraku nebo v ýsledku z tomografu se hraniˇcn´ı reprezentace nehod´ı. Proto se pouˇz´ıvá objemová reprezentace. Data se vˇetˇsinou uchovávaj´ı v mˇr´ıˇzce. Mˇr´ıˇzka m ˚uˇze nab ývat 7 r ˚uzn ých podob:

• kartézsk á • pravideln á

(22)

Obrázek 10: CSG • pravo úhlá • strukturovan á • nestrukturovan á • blokovˇe strukturovan á • hybridn´ı

Nejˇcastˇeji se setkáme s pravideln ými prostorov ými mˇr´ıˇzkami. Hodnotou v mˇr´ıˇzce je základn´ım elementem voxel, kter ý nab ývá nejˇcastˇeji tvaru kvádru. Má v celém svém ob-jemu stejnou hodnotu. Je to analogicky protˇejˇsek k pixelu v 2D grafice. Pro v´ıce informac´ı o objemové reprezentaci tˇeles doporuˇcuji pˇreˇc´ıst [27].

(23)

oboje. Vˇzdy je potˇreba se rozhodnout, kterou strategii zvol´ıme, napˇr´ıklad pro modelo-vac´ı editor budeme cht´ıt rychle vykreslen´ı, ideálnˇe 60 sn´ımk ˚u za sekundu. Naopak, pro v ýsledn ý render celoveˇcern´ıho animovaného filmu budeme cht´ıt v ýsledek kvalitn´ı, na hranici realistiˇcnosti. Pro v´ıce informac´ı o zobrazovac´ıch metodách doporuˇcuji pˇreˇc´ıst [21],[22],[23],[24] a [25].

3.2.1 Standartn´ı zobrazovac´ı ˇret ˇezec

Jedná se o metodu, která má za c´ıl vykreslit obraz rychle na úkor realistiˇcnosti. Je to základn´ı stavebn´ı kámen, napˇr´ıklad pro CAD programy, poˇc´ıtaˇcové hry nebo modelo-vac´ı editor Blender. ˇRetˇezec se skládá z 8 krok ˚u, které se vˇsak m ˚uˇzou odliˇsovat podle konkrétn´ı situace, napˇr´ıklad podle toho, jak ý zvol´ıme osvˇetlovac´ı model (Phong, atd.).

Na zaˇcátku mus´ıme m´ıt popis scény, kterou chceme vykreslit. Obsahuje mnoˇzinu ob-jekt ˚u, které chceme vykreslit. Dále mnoˇzinu svˇetel, které se ve scénˇe nacház´ı, a popis, jak danou scénu chceme vykreslit (m´ısto, odkud se chceme d´ıvat, atd...).

Prvn´ım krokem je vygenerován´ı ploch (nejlépe vygenerován´ı troj úheln´ık ˚u) ze vˇsech objekt ˚u ve scénˇe, které aproximuj´ı jejich povrch. Pokud se jiˇz naˇse tˇeleso skládá z tˇechto ploch, tak m ˚uˇzeme tento krok pˇreskoˇcit, pokud vˇsak je naˇse tˇeleso popsáno jako koule o pr ˚umˇeru r, tak je tˇreba zvolit dobrou aproximaˇcn´ı techniku, která udˇelá z koule mnoˇzinu troj úheln´ık ˚u s body a normálami ve vrcholech.

Druh ým krokem je odstranˇen´ı tˇech ploch, které zcela jisté nep ˚ujdou vidˇet. Kaˇzd ý troj úheln´ık ve scénˇe má svou vlastn´ı normálu, tato normála nám urˇcuje smˇer natoˇcen´ı troj úheln´ıka. Pokud je normála ve stejném smˇeru jako pohled, kter ým se na scénu d´ıváme. Tak lze pˇredpokládat, ˇze dan ý troj úheln´ık se nacház´ı na protˇejˇs´ı stranˇe objektu, a tud´ıˇz nebude vidˇet. Odtud tedy m ˚uˇzeme zjistit, které troj úheln´ıky v tomto kroku m ˚uˇzeme vyˇradit. K v ýpoˇctu pouˇzijeme skalárn´ı souˇcin normály plochy a smˇeru naˇseho vykres-lovac´ıho pohledu.

Tˇret´ım krokem je v ýpoˇcet osvˇetlen´ı ve vrcholech kaˇzdé plochy. Osvˇetlen´ı je jedn´ım z d ˚uleˇzit ých krok ˚u, protoˇze urˇcuje, jak budeme vn´ımat dané tˇeleso. Mezi nejjednoduˇsˇs´ı techniky ˇrad´ıme konstantn´ı st´ınován´ı, které jednotlivé ploˇsky vypln´ı stejnou barvou. Po-kroˇcilejˇs´ı je Gouradovo st´ınovan´ı, které vypoˇcte v kaˇzdém vrcholu vlastn´ı barvu, a poté ji interpoluje po celé ploˇsce. Rozˇs´ıˇren´ım je Phongovo st´ınován´ı, které interpoluje normály z vrcholu, a aˇz poté vypoˇc´ıtává barvu daného pixelu. Osvˇetlen´ı se ovˇsem net ýká vrhán´ı st´ınu. Na st´ıny se pouˇz´ıvaj´ı jiné techniky.

(24)

ˇ

Ctvrt ´ym krokem je proveden´ı transformace pro vˇsechny vrcholy. Pˇredem vypoˇctenou prom´ıtac´ı matici vyn´asob´ıme s vrcholem v homogenn´ıch souˇradnic´ıch.

Pát ým krokem je oˇrezán´ı zorn ým objemem. Zde se odstran´ı dalˇs´ı plochy, které nep ˚ujdou vidˇet. D´ıky tomu se nebudou muset kreslit plochy, které náˇs pohled nezab´ırá, a dojde t´ım ke zrychlen´ı vykreslovac´ıho ˇretˇezce.

ˇSest´ym krokem je pˇrechod od homogenn´ıch souˇradnic k afinn´ım souˇradnic´ım.

Sedm ým krokem je transformace souˇradnic vrcholu na souˇradnice v ýstupn´ıho zaˇr´ızen´ı. Posledn´ım osm ým krokem je rasterizace. Pro viditelnost se pouˇz´ıvá Z-buffer.

3.2.2 Monte Carlo metody

Monte carlo je stochastická metoda. Vyuˇz´ıvá pseudonáhodné ˇc´ıslo, které aproximuje ˇreˇsen´ı. V ýhodou tˇechto metod je, ˇze pouˇz´ıvaj´ı tzv. sledován´ı paprsku. Lze v nich snadno vypoˇc´ıtat zrcadlov ý obraz, empirická sloˇzitost je log (n) a maj´ı n´ızkou pamˇet’ovou nároˇcnost.

Rekurzivn´ı sledov án´ı paprsku Z poˇcátku byly metody zaloˇzené na sledován´ı paprsku od zdroje svˇetla. Tyto metody jsou zaloˇzené na sledován´ı paprsku od zdroje svˇetla k po-zorovateli. Bohuˇzel, mnoho paprsku od zdroje nedoraz´ı k pozorovateli, a tedy poˇc´ıtaj´ı se zbyteˇcnˇe. Proto se v ýpoˇcet obrátil, a poˇc´ıtaj´ı se paprsky od pozorovatele ke zdroji svˇetla, takovéto metodˇe ˇr´ıkáme rekurzivn´ı sledován´ı paprsku. V ýhodou této techniky je auto-matické poˇc´ıtán´ı svˇeteln ých odraz ˚u a st´ın ˚u. Také je implementaˇcnˇe velmi jednoduchá.

Nev ýhodou je práce pouze s bodov ými svˇetly a tud´ıˇz st´ıny, které tvoˇr´ı, jsou ostré. Ray tracing, jak se také nˇekdy tato metoda naz ývá, poskytuje kvalitn´ı v ýsledky oproti standartn´ımu zobrazovac´ımu ˇretˇezci.

Algoritmus pro v ýpoˇcet je velmi snadn ý. Od pozorovatele vyˇsleme paprsek skrz poˇc´ıtan ý pixel. Na tomto paprsku najdeme nejbliˇzˇs´ı pr ˚useˇc´ık s objektem ve scénˇe. Po-kud nen´ı ˇzádn ý pr ˚useˇc´ık, vrát´ıme barvu pozad´ı. V opaˇcném pˇr´ıpadˇe se na nalezeném pr ˚useˇc´ıku vypoˇc´ıtá barva. Barva se poˇc´ıtá ze samotného objektu a z pˇr´ıspˇevk ˚u od okoln´ıch svˇetel. Následnˇe se vypoˇc´ıtá paprsek odrazu, a pokud je objekt pr ˚usvitn ý, tak i lomen ý paprsek a celé se to rekurzivnˇe opakuje. Poˇcet odraˇzen´ı jednoho paprsku se obvykle ome-zuje, protoˇze ˇc´ım v´ıcekrát se paprsek odráˇz´ı, t´ım ménˇe dan ý odraz pˇrisp´ıvá do v ýsledného pixelu.

Na nalezen´em pr ˚useˇc´ıku se poˇc´ıt´a barva podle vzorce.

I(P ) = IL(P ) + IG(P ) = IL(P ) + KnoI(Po) + KnpI(Pp)

Kde:

P - pr ˚useˇc´ık

Po- dalˇs´ı pr ˚useˇc´ık odraˇzen´eho paprsku

Pp- dalˇs´ı pr ˚useˇc´ık lomen´eho paprsku

Kno- koeficient odrazu

Knp- koeficient lomu

Metoda rekurzivn´ı sledován´ı paprsk ˚u je nároˇcná na v ýkon. Proto se v ýpoˇcet snaˇz´ıme zefektivnit. Tˇelesa uzav´ıráme do jednoduch ých bounding boxu. Pˇr´ıkladem m ˚uˇze b ýt

(25)

ku-Obr´azek 12: Raytracing

lová plocha, která obep´ıná celé tˇeleso co nejtˇesnˇeji. Pˇri hledan´ı nyn´ı nejdˇr´ıve provedeme v ýpoˇcet paprsku s bounding boxem a pokud se nalezne pr ˚useˇc´ık, tak aˇz teprve potom dˇeláme sloˇzitˇejˇs´ı pr ˚useˇc´ık paprsku s tˇelesem.

Obr´azek 13: Bounding box

Techniku m ˚uˇzeme zdokonalit t´ım, ˇze do boundin boxu uzavˇreme v´ıce tˇeles, kter´e jsou bl´ızko u sebe. M ˚uˇzeme takto rekurzivnˇe vytvoˇrit v´ıce bounding boxu a vytvoˇrit strom, ve kter´em bude hledan´ı pr ˚useˇc´ıku snaˇzˇs´ı.

Jiná metoda pouˇz´ıvá pro rychlejˇs´ı hledán´ı pr ˚useˇc´ık ˚u Octree. Jde o kvadrantov ý strom, kter ý prostor rekurzivnˇe dˇel´ı na 8 dalˇs´ıch podprostoru. Kaˇzd ý podprostor je tvaru krychle se seznamem tˇeles, které do toho podprostoru spadaj´ı. Dˇelen´ı je ukonˇceno, pokud je prostor prázdn ý, nebo se tam nacház´ı jen jedno tˇeleso, nebo dˇelen´ı prostoru pˇrekroˇcilo urˇcitou mez. Následné skládán´ı pr ˚useˇc´ıku se nejdˇr´ıv provád´ı s hledán´ım pr ˚useˇc´ıku v podprostoru, a aˇz pokud je nalezen pr ˚useˇc´ık s podprostorem, je hledán pr ˚useˇc´ık s tˇelesem v tomto podprostoru. D´ıky v ýhodám stromu je vyhledán´ı pr ˚useˇc´ıku zrychleno.

(26)

Obr´azek 14: Hiearchie bounding boxu

Obr´azek 15: Octree

Jednou z nev ýhod je i vznik aliasingu. Paprsek se obvykle vys´ılá stˇredem pixelu, to m ˚uˇze m´ıt za pˇr´ıˇcinu vzniku nehezk ých zub ˚u, napˇr´ıklad na okraji koule. Aliasingu se m ˚uˇzeme zbavit vys´ılán´ım v´ıce paprsku v r ˚uzn ých bodech pixelu a v ýsledn ý pixel vytvoˇrit zpr ˚umˇerován´ım vyslan ých paprsk ˚u. Nebo m ˚uˇzeme pouˇz´ıt metodu tˇresen´ı pa-prsku, kdy se vys´ılá jen jeden paprsek, ale vys´ılá se náhodn ým m´ıstem pixelu.

3.2.3 Radiozita

Radiozita je jedna z dalˇs´ıch metod pro vykreslen´ı scény. Oproti sledován´ı paprsku vˇsak jej´ı v ýpoˇcet nezávis´ı na pozici pozorovatele. Staˇc´ı ji pro scénu jednou zapoˇc´ıtat a poté je moˇzné rychlé vykreslen´ı v jakékoliv pozici pozorovatele. Tato metoda se nejlépe hod´ı na interiéry. Nezvládá vˇsak vykreslovat zrcadlov ý odraz.

Celá scéna je pokryta ploˇskami. Kaˇzdá ploˇska reprezentuje, jak je daná ˇcást scény osv´ıcena. V oblastech, kde nedocház´ı k ˇzádn ým velk ým zmˇenám, jsou ploˇsky velké, na-opak v oblastech, kde docház´ı k velk ým zmˇenám osvˇetlen´ı (okraje st´ınu, apod... ), jsou

(27)

Obr´azek 16: Uk´azka Raytracingu

malé. Na zaˇcátku je rozdˇelen´ı ploˇsek ve scénˇe udˇeláno intuitivnˇe, v dalˇs´ıch kroc´ıch je ale dˇelen´ı upraveno, tak aby lépe vyhovovalo v ýsledku vykreslen´ı.

Pro kaˇzdou ploˇsku je vypoˇc´ıtaná intenzita osvˇetlen´ı, která na ploˇsku dopadá ze vˇsech ploˇsek, a která je ploˇskou vyˇrazena do prostoru, at’ uˇz odrazem, nebo pokud sama inten-zitu vyˇrazuje.

Obr´azek 17: Sch´ema vypoˇctu radiosity

Protoˇze by na hranˇe mezi sousedn´ımi ploˇskami vznikala viditelná hrana, tak se u vrchol ˚u, které nejsou na hranˇe vrcholu ˇzádného objektu, zpr ˚umˇeruje intenzita vˇsech pˇriléhaj´ıc´ıch ploˇsek. Nakonec m ˚uˇzeme v ýsledek vykreslit pomoc´ı Gouradova st´ınovan´ı.

3.2.4 Objemov ´e algoritmy

Algoritmy, zobrazuj´ıc´ı povrchy Algoritmy, zobrazuj´ıc´ı povrchy, ˇrad´ıme mezi nepˇr´ımé algoritmy. Ze vstupn´ıch dat se spoˇc´ıtá pomocná geometrie, která se pak dále zobrazuje a s p ˚uvodn´ımi daty se dál nepoˇc´ıtá. Vytvoˇrená pomocná geometrie je povrch, jenˇz

(28)

aproxi-muje povrch p ˚uvodn´ıch dat. To také znamená, ˇze jsme se pˇresunuli z objemov ých tˇeles k hraniˇcn´ım tˇeles ˚um. A m ˚uˇzeme v ýsledek vykreslit, napˇr´ıklad pomoc´ı technik uveden ých v ýˇse.

Pˇr´ım é objemov é algoritmy Naproti tomu jsou pˇr´ımé zobrazovac´ı objemové algoritmy, které se snaˇz´ı zobrazovat vstupn´ı objemová data pˇr´ımo. Mezi takovéto algoritmy ˇrad´ıme napˇr´ıklad raytracer POV-Ray.

(29)

4.1 Qt

Grafické uˇzivatelské rozhran´ı (GUI) je napsáno v knihovnˇe QT. QT je jedna z nejpo-pulárnˇejˇs´ıch multiplatformn´ıch knihoven pro Windows, Linux a Mac. Byla vytvoˇrena v roce 1999 spoleˇcnosti Trolltech. A v roce 2008 prodána spoleˇcnosti Nokia.

Qt knihovna byla naps´ana pro jazyk c++, ale existuj´ı verze i pro jin´e programovac´ı jazyky, napˇr´ıklad pro python,... . Mezi jej´ı pˇrednosti kromˇe multiplatformosti ˇrad´ıme i dobrou dokumentaci. Pro v´ıce informac´ı o Qt doporuˇcuji pˇreˇc´ıst [8],[9],[10],[11] a [12].

Aplikace byla naps´ana pro QT verzi 4.7.2.

4.2 Struktura aplikace

Celá aplikace se skládá z d´ılˇc´ıch projekt ˚u.

• Projekt Database slou ˇz´ı k nahráván´ı modelu z databáze.

• Projekt DataCore obsahuje z ákladn´ı prvky SceneData, SceneTree, parentNode a en-tityNode, které slouˇz´ı k obecnému vykreslen´ı objektu pomoc´ı hierarchie stromu. Také zde nalezneme podporu shader programu a speciáln´ı entitu pro ˇrezan´ı mo-delu pomoc´ı cliping plane.

• Projekt FemDataCore rozˇsiˇruje tˇr´ıdy parentNode a enitityNode o potˇrebné elementy pro vykreslován´ı naˇsich konkrétn´ıch modelu. Nalezneme zde jiˇz zm´ınˇené rozˇs´ıˇren´ı entity_Mesh_{a entity_Meshpart, samotné data modelu v tˇr´ıdách Mesh a} Me-shPart a tˇr´ıdy pro v ýpoˇcet a proveden´ı rozpadu tˇeles.

• Projekt FemManager hlavn´ı projekt, jen ˇz se star´a o manager. A obsahuje funkci main.

• Projekt Renderer projekt, jen ˇz obsahuje tˇr´ıdu SimpleViewer, kter´a se star´a o vykres-lovac´ı okno OpenGL.

• Projekt QGLViewer projekt, jen ˇz upravuje QGLviewer pro potˇreby aplikace • Projekt GGradientViewer obsahuje v ´ychoz´ı tˇr´ıdu pro SimpleViewer.

(30)

4.2.1 Popis struktury

Hlavn´ım projektem je FemManager, ve kterém se nacház´ı tˇr´ıda Manager. Tˇr´ıda Manager, vycházej´ıc´ı z tˇr´ıdy QMainWindow, má na starost hlavn´ı okno, signály pro manipulaci s nahráván´ım objektu, gui prvky a také drˇz´ı d ˚uleˇzitou strukturu SceneData.

Tˇr´ıda SceneData, jak uˇz z názvu vypl ývá, zapouzdruje data aplikace. Je navrˇzena jako pseudo singleton. Také uchovává stavy pro urˇcen´ı, jak ým zp ˚usobem se má dan ý model vykreslit, a nastaven´ı globáln´ıho vykreslen´ı. Toto nastaven´ı nalezneme v tˇr´ıdˇe DrawMo-delFlags. Globáln´ı nastaven´ı se skládá z barvy pozad´ı, hran, bod ˚u, velikost´ı alfa koefici-entu, pro pr ˚uhledné vykreslován´ı. Samotné data jsou obsazena v tˇr´ıdˇe SceneTree.

Stromem, kter ý drˇz´ı ˇcást´ı modelu, je SceneTree. Obsahuje ukazatel na koˇren stromu, ˇcást´ı vykreslovaného modelu a LogicInterface, kter ý udává zp ˚usob rozkladu. Uzly stromu jsou tvoˇreny tˇr´ıdou SceneTreeNode. Z této tˇr´ıdy se odvozuji parentNode, jenˇz pˇredstavuje vnitˇrn´ı uzly stromu a entityNode, kter ý pˇredstavuje listy stromu. Z parentNode se odvo-zuje Entity Mesh, kter ý pˇredstavuje cel ý model, a z EntityNode se odvoodvo-zuje Entity meshpart, jenˇz pˇredstavuje jednotlivé domény modelu.

4.3 Implementovan ´e algoritmy 4.3.1 Dekompozice

Tˇr´ıda LogicInterface Jedná se o virtuáln´ı tˇr´ıdu, z n´ıˇz se dˇed´ı tˇr´ıdy pro popis rozkladu modelu. I kdyˇz je v názvu slovo interface, tak se nejedná o interface, jak ý je napˇr´ıklad k nalezen´ı v jave. Jedná se o abstraktn´ı datov ý typ, kter ý pouze urˇcuje jaké hlavn´ı funkce je tˇreba implementovat pro v ýpoˇcet rozkladu.

Obr´azek 18: Uk´azka dekompozice

Tˇr´ıda je navrˇzena jako návrhov ý vzor Abstraktn´ı továrna. Tˇr´ıda úzce spolupracuje s jedn´ım GUI prvkem. Tento prvek je QTreeWidget a zajiˇst’uje zobrazen´ı logické struk-tury rozkladu pro snadnˇejˇs´ı manipulaci ( vyb´ıran´ı kl´ıˇcov ých domén/skupin pro rozpad).

(31)

• CreateLogic() - nejd ˚uleˇzitˇejˇs´ı funkce, jenˇz má za úkol vytvoˇrit logiku pro v ýpoˇcet rozkladu. Tato funkce je volaná pokaˇzdé po funkci LoadPoint()

• FillTable() - Funkce pro GUI napl ˇnuje tabulku s daty pro manipulaci s ˇcástmi ob-jektu. Tato funkce je volaná pokaˇzdé po funkci CreateLogic()

• ClickTable() - Zpracov án´ı událost´ı pˇri kliknut´ı na nˇejak ý item v tabulce. Funkce se volá pokaˇzdé pˇri interakci s GUI pro rozklad.

• Reset() - Funkce pro obnoven´ı v ýchoz´ı pozice modelu. Je volaná po stisknut´ı pˇr´ısluˇsného tlaˇc´ıtka v menu, nebo pˇri zapnut´ı oˇrezové roviny.

Tˇr´ıda dále obsahuje seznam bod ˚u, kter ý se vypl ˇnuje pomoc´ı funkce LoadPoint. Tento seznam bod ˚u reprezentuje seznam domén v modelu. Pro jednoduchost jsme se omezili pouze na centra domén a vypustili jsme informaci o prostorové velikosti domény. Dále zde nalezneme seznam matic, jenˇz reprezentuj´ı transformaci jednotliv ých ˇcást´ı modelu z rozkladu, a seznam element ˚u, které pˇredstavuj´ı vnitˇrn´ı logiku daného rozkladu.

Simple Jedná se o nejjednoduˇsˇs´ı zp ˚usob rozkladu. Pro svou jednoduchost nepotˇrebuje funkci CreateLogic. Proto tato funkce z ˚ustává prázdná. D ˚uleˇzitou ˇcást´ı je ale funkce pro v ýpoˇcet aktuáln´ı pozice domén:

void LISimple::UpdateMatrix(float s,float x, float y, float z)

{

matice.clear () ; glPushMatrix();

for( int i = 0; i < seznamElementu.size(); i++)

{

glLoadIdentity () ;

cLIElement∗u = seznamElementu.at(i);

if (u−>bRozpadUse)

glTranslated(u−>centrum.x∗x + u−>centrum.x∗s ,u−>centrum.y∗y + u−>centrum.y∗s , u−>centrum.z∗z + u−>centrum.z∗s);

MATRIX4x4 mat;

glGetFloatv(GL MODELVIEW MATRIX, mat.m);

if (matice.size () > i)

matice[i ] = mat;

else

(32)

}

glPopMatrix(); }

V ´ypis 1: Algoritmus pro rozklad Simple (UpdateMatrix)

Ve funkci nejprve vyˇcist´ıme seznam matic. Pro zachován´ı zobrazovac´ı matice ji uloˇz´ıme. Na 5. ˇrádku projdeme v cyklu pˇres vˇsechny elementy (domény) a vytvoˇr´ıme matici s jed-noduch ým posunem závisej´ıc´ım na v ýchoz´ı pozici modelu a s´ıly posunu rozkladu. Tato matice je poté vloˇzena do seznamu matic. Nakonec vytáhneme zobrazovac´ı matici zpˇet z pamˇeti, aby bylo vˇse v poˇrádku.

Tree Rozˇs´ıˇren ý algoritmus pro d´ılˇc´ı ovládán´ı modelu. Pˇresn ý popis algoritmu je napsán v kapitole 2.2.2.

void LIStrom::CreateLogic()

{

vybrany = NULL; vector<cUzelv2∗> base;

for( int i =0; i <seznamElementu.size(); i++)

base.push back((cUzelv2∗)seznamElementu[i]); vector<cUzelv2∗>∗ uroven0 = CallUroven(&base,0.003); vector<cUzelv2∗>∗ uroven1 = CallUroven(uroven0,0.003); koren = new cUzelv2Rodic();

cVector c (0,0,0) ;

for( int i =0; i < uroven1−>size(); i++)

{

koren−>seznam.push back(uroven1−>at(i)); cUzelv2∗pom = uroven1−>at(i);

cVector vecPom(pom−>centrum.x, pom−>centrum.y, pom−>centrum.z); c += vecPom; } c = c∗ (1.0/( double)uroven1−>size()); koren−>centrum = c; UpdateRodic(koren); }

V ´ypis 2: Pseudo algoritmus pro rozklad Tree (CreateLogic)

Seznam bodu (center domén) se nejdˇr´ıve pˇrekop´ıruje do pomocného seznamu base. Následnˇe je pomoc´ı funkce CallUroven nad t´ımto seznamem vytvoˇren seznam shluk ˚u (uroven0). A poté je i nad seznamem shluk ˚u (uroven0) vytvoˇren seznam shluk ˚u (uroven1). Jako pˇredposledn´ı akce je vytvoˇren´ı hlavn´ıho uzlu a vyplnˇen´ı jeho seznamu potomk ˚u se-znamem uroven1. Takto jsme z´ıskali stromovou strukturu s hloubkou 3, hlavn´ım uzlem (koˇren) a listy stromu reprezentuj´ıc´ı centra domén modelu. Nakonec je zavolaná funkce UpdateRodic, která vˇsem uzl ˚um nastav´ı správného rodiˇce, pro snazˇs´ı pr ˚uchod stromu.

(33)

naj´ıt nejdˇr´ıve malé shluky a poté vetˇs´ı shluky. Nakonec je cel ý seznam vrácen.

Následuj´ıc´ı v ýpis funkce NajdiShlukyRodic() byla kv ˚uli své velikosti zredukována jen na podstatné ˇcást´ı a zredukované ˇcást´ı byly nahrazeny tˇremi teˇckami a komentáˇrem o funkci, kterou plnily.

void LIStrom::NajdiShlukyRodic(double d,vector<cUzelv2∗>∗ sezU,vector<cUzelv2∗>∗ sezL, int meze)

{

vector<int> ∗ maxSez = new vector<int>; for( int i =0; i < sezL−>size(); i++)

{ ...

// vytvoren cVector a reprezentujici shluk z i−teho prvku sezname sezL

for( int mm=0; mm < sezL−>size(); mm++)

{ ...

// vypocet vzdalenost´ı delka mm−teho prvku z seznamu sezL k reprezentantu

if (delka <= d) { sez−>push back(mm); pocet++; } } ...

// Pokud nalezeny seznam splnuje pozadavky na minimalni hodnotu a je nejvetsi nalezeny stava se maxSez, jinak je smazan

} ...

// Vytvoreni uzlu predstavujici rodice nalezeneho shluku ...

// Vpocet stredu shluku z aritmetickeho prumemeru vsech prvku z seznamu maxSez ...

// Vyrazeni nalezenych prvku z seznamu sezL NajdiShlukyRodic(d, sezU, sezL, meze); }

(34)

Funkce NajdiShlukyRodic nejprve vyhledá v cyklu nejvˇetˇs´ı moˇzn ý shluk. Následnˇe pro takov ýto shluk vytvoˇr´ı rodiˇce a nalezené prvky do nˇej pˇriˇrad´ı. Nakonec jsou nalezené prvky ze seznamu vyˇrazeny a cyklus se rekurzivnˇe provede znovu, dokud nen´ı seznam sezL prázdn ý nebo uˇz nejde vytvoˇrit shluky.

void LIStrom::UpdateMatrix(float s,float x, float y, float z)

{

matice.clear () ; glPushMatrix();

for( int i = 0; i < seznamElementu.size(); i++)

{

glLoadIdentity () ;

if ((( cUzelv2 ∗)seznamElementu[i])−>setTransformation(s,x,y,z))

{

MATRIX4x4 mat;

glGetFloatv(GL MODELVIEW MATRIX, mat.m);

if (matice.size () > i) matice[i ] = mat; else matice.push back(mat); } } glPopMatrix(); }

V ´ypis 5: Pseudo algoritmus pro rozklad Tree (UpdateMatrix)

Ve funkci nejprve vyˇcist´ıme seznam matic. Pro zachován´ı zobrazovac´ı matice ji uloˇz´ıme. Na 5. ˇrádku projdeme v cyklu pˇres vˇsechny elementy(domény) a vytvoˇr´ıme matici s transformac´ı podle funkce setTransformation, která se provede podle vnitˇrn´ı logiky vy-tvoˇreného rozpadu. Tato matice je poté vloˇzena do seznamu matic. Nakonec vytáhneme zobrazovac´ı matici zpˇet z pamˇeti, aby bylo vˇse v poˇrádku.

Springs Teoretick ý popis fungovan´ı Springs rozpadu je napsán v kapitole 2.2.2. Tˇr´ıda cLIElement, jenˇz reprezentuje vnitˇrn´ı prvek rozpadu a ˇcásteˇcnˇe tak definuje chován´ı celé tˇr´ıdy pro rozpad, byla rozˇs´ıˇrena na tˇr´ıdu cSpring. Do tˇr´ıdy cSpring byl pˇridán seznam ukazatel ˚u na dalˇs´ı tˇr´ıdy. Seznam ukazatel ˚u pˇredstavuje logické spojen´ı dvou domén. Pˇri pˇrirovnán´ı ke grafu je to jednosmˇerná hrana grafu.

Dále byla navrhnuta struktura sTMPBod pro v ýpoˇcet nalezen´ı nejbliˇzˇs´ıch domén. Ob-sahuje kromˇe informace, ke které doménˇe patˇr´ı (cSpring), také pole délky tˇri pˇredstavuj´ıc´ı nejbliˇzˇs´ı nalezené domény. Pro v ýpoˇcet aktualizace transformaˇcn´ıch matic byla pˇridána struktura sTMPMinBod, která obsahuje informaci o doménˇe a o s´ıle, která na tuto doménu p ˚usob´ı.

Následuj´ıc´ı k ód, popisuj´ıc´ı algoritmus pro rozpad pomoc´ı Springs, byl kv ˚uli své veli-kosti rozdˇelen na 4 ˇcásti.

void LISprings::CreateLogic()

{

(35)

Nejprve je vytvoˇren pomocn ý vektor tmpList, do kterého je pˇrekop´ırován obsah se-znamu center domén seznamElementu. Dále je tento seznam seˇrazen podle jedné z os. Pomoc´ı standartn´ı funkce sort je zavolána funkce sortFce, která zaˇrizuje porovnáván´ı. T´ımto krokem pˇripravujeme algoritmus na pr ˚uchod zametac´ı rovinou po d ˚uleˇzit ých bo-dech ze seznamu tmpList. Také je vytvoˇren seznam aktuálnˇe zpracovávan ých bod ˚u lis-tZBod.

for( int i =0; i < tmpList.size() ; i ++)

{

cSpring∗ tmpBod = tmpList.at(i) ; plane = tmpBod−>centrum.z;

for( int j =0; j < listZBod.size () ; j ++)

{

sTMPBod∗ bod = &listZBod.at(j); // 1. vyradit body z seznamu // podminka pro maxVzdalenost

if (bod−>pocet == 3)

if (( plane − bod−>bod−>centrum.z) > bod−>nejblizsi[2].vzdalenost)

{ // vyradit bod−>bod−>pruziny.push back(bod−>nejblizsi[0].bod); bod−>bod−>pruziny.push back(bod−>nejblizsi[1].bod); bod−>bod−>pruziny.push back(bod−>nejblizsi[2].bod); bod−>nejblizsi[0].bod−>pruziny.push back(bod−>bod); bod−>nejblizsi[1].bod−>pruziny.push back(bod−>bod); bod−>nejblizsi[2].bod−>pruziny.push back(bod−>bod); // smazat z listu listZBod.erase(listZBod.begin()+j ) ; j−−; continue; }

V ´ypis 7: Pseudo algoritmus pro rozklad Springs (CreateLogic)2/4

T´ımto setˇr´ıdˇen ým seznamem tmpList zaˇcneme procházet a posouvat zametac´ı rovinu podle aktuáln´ıho prvku ze seznamu. Pro kaˇzd ý posun zametac´ı roviny se projde seznam aktuálnˇe zpracovávan ých bod ˚u listZBod. A jestliˇze je splnˇena podm´ınka pro vyˇrazen´ı

(36)

to-hoto bodu, je bod vyˇrazen. Podm´ınky pro vyˇrazen´ı jsou dvˇe. Prvn´ı podm´ınka: poˇcet za-znamenan ých nejbliˇzˇs´ıch bod ˚u je roven tˇrem, a druhá, d ˚uleˇzitˇejˇs´ı podm´ınka: vzdálenost roviny od bodu z aktuálnˇe zpracovávaného seznamu listZBod je vˇetˇs´ı neˇz vzdálenost bodu z aktuálnˇe zpracovávaného seznamu listZBod k tˇret´ımu nejbliˇzˇs´ımu nalezenému bodu.

Vyˇrazen´ı bodu se provád´ı t´ım, ˇze se nejprve vytvoˇr´ı logické vazby mezi bodem, kter ý se vyˇrazuje, a tˇremi nejbliˇzˇs´ımi nalezen ými body. Nakonec je bod smazán ze seznamu listZbod. Podm´ınka je ukonˇcena pˇr´ıkazem continue, protoˇze se jiˇz dále t´ımto aktuáln´ım bodem zab ývat nemus´ıme.

// 2. spocitat vzdalenposti k tmp

float vzd = sqrt ( bod−>bod−>centrum.z∗ tmpBod−>centrum.z +

bod−>bod−>centrum.y∗ tmpBod−>centrum.y + bod−>bod−>centrum.x∗ tmpBod−>centrum.x); // jestlize je pocet mensi jak 3 tak pridat

if (bod−>pocet < 3) { bod−>nejblizsi[bod−>pocet].vzdalenost = vzd; bod−>nejblizsi[bod−>pocet].bod = tmpBod; bod−>pocet++; continue; } if (vzd < bod−>nejblizsi[0].vzdalenost) { bod−>nejblizsi[2] = bod−>nejblizsi[1]; bod−>nejblizsi[1] = bod−>nejblizsi[0]; bod−>nejblizsi[0].vzdalenost = vzd; bod−>nejblizsi[0].bod = tmpBod; continue; } if (vzd < bod−>nejblizsi[1].vzdalenost) { bod−>nejblizsi[2] = bod−>nejblizsi[1]; bod−>nejblizsi[1].vzdalenost = vzd; bod−>nejblizsi[1].bod = tmpBod; continue; } if (vzd < bod−>nejblizsi[2].vzdalenost) { bod−>nejblizsi[2].vzdalenost = vzd; bod−>nejblizsi[2].bod = tmpBod; continue; } } // 3. pridat tmp do seznamu sTMPBod novy;

(37)

se vˇsak tento bod nalézá v bl´ızkosti, tak je zaˇrad´ıme na pˇr´ısluˇsné m´ısto do seznamu nejbliˇzˇs´ıch bod ˚u. Nakonec je bod ze seznamu tmpList zkop´ırován do seznamu listZbod, aby se i pro nˇej nalezly nejbliˇzˇs´ı body.

for( int j =0; j < listZBod.size () ; j ++)

{

sTMPBod∗ bod = &listZBod.at(j);

for( int i =0; i < bod−>pocet; i++)

{

bod−>bod−>pruziny.push back(bod−>nejblizsi[i].bod); bod−>nejblizsi[i ]. bod−>pruziny.push back(bod−>bod); }

}

matice.clear () ;

for( int i =0; i < seznamElementu.size();i++)

{

glLoadIdentity () ; MATRIX4x4 mat;

glGetFloatv(GL MODELVIEW MATRIX, mat.m); matice.push back(mat);

} }

V ´ypis 9: Pseudo algoritmus pro rozklad Springs (CreateLogic)4/4

Po skonˇcen´ı cyklu procházej´ıc´ı seznam tmpList se m ˚uˇzou nacházet v seznamu aktuálnˇe zpracovávan ých bodu listZbod body, pro které nebyly vytvoˇreny logické vazby a nebyly vyˇrazeny. Proto je nutné pro tyto body vytvoˇrit logické vazby a vyˇradit je. A nakonec je jeˇstˇe vytvoˇren seznam matic pro v ýpoˇcet transformac´ı.

Funkce pro aktualizaci transformaˇcn´ıch matic je oproti dekompozici Tree sloˇzitˇejˇs´ı. Funkce pracuje následovnˇe: poˇcáteˇcn´ı stav mˇejme takov ý, ˇze jedna z domén byla vybrána a posunuta v prostoru nˇejak ým smˇerem. Oˇcekávejme, ˇze d´ıky Springs dekompozici se následnˇe posunou i ostatn´ı domény stejn ým smˇerem, ale jinou s´ılou. S´ıla, o kterou se domény posunou, bude záviset na jejich vzdálenosti od prvn´ı vybrané posunuté domény.

ˇ

C´ım vzdálenˇejˇs´ı budou domény, t´ım by mˇela b ýt s´ıla menˇs´ı. V ýpoˇcet vzdálenosti zde nahrad´ıme vazbami mezi jednotliv ými doménami (pruˇzinkami). D´ıky tomu ve v ýsledku nemus´ı na vzdálenosti záviset s´ıla, ale pouze na logickém propojen´ı mezi doménami.

(38)

{

glPushMatrix();

vector<int> pouziteUzly;

vector<sTMPMinBod∗> cekaNaZpracovani;

cSpring∗ b = (cSpring ∗)seznamElementu.at(vybrany); pouziteUzly.push back(vybrany);

for( int i =0; i < b−>pruziny.size(); i++)

{

sTMPMinBod∗ zrp = new sTMPMinBod; zrp−>bod = b−>pruziny.at(i); zrp−>vzdalenost = 0.9; cekaNaZpracovani.push back(zrp); } // Vykonat posunuti glLoadIdentity () ;

glTranslated(b−>centrum.x∗x∗10 ,b−>centrum.y∗y∗10, b−>centrum.z∗z∗10); MATRIX4x4 mat;

glGetFloatv(GL MODELVIEW MATRIX, mat.m); matice[vybrany] = mat;

for (; cekaNaZpracovani.size() != 0 ;)

{

sTMPMinBod∗ pr = cekaNaZpracovani.at(0);

cekaNaZpracovani.erase(cekaNaZpracovani.begin());

if (std :: find (pouziteUzly.begin(), pouziteUzly.end() ,pr−>bod−>node−>getID()) !=

pouziteUzly.end()) continue; pouziteUzly.push back(pr−>bod−>node−>getID()); // Vykonat posunuti glLoadIdentity () ; glTranslated(b−>centrum.x∗x∗pr−>vzdalenost∗10 ,b−>centrum.y∗y∗pr−>vzdalenost∗10, b −>centrum.z∗z∗pr−>vzdalenost∗10); MATRIX4x4 mat2;

glGetFloatv(GL MODELVIEW MATRIX, mat2.m); matice[pr−>bod−>node−>getID()] = mat2;

for( int i =0; i < pr−>bod−>pruziny.size(); i++)

{

sTMPMinBod∗ zrp = new sTMPMinBod; zrp−>bod = pr−>bod−>pruziny.at(i); zrp−>vzdalenost = 0.8∗ pr−>vzdalenost; cekaNaZpracovani.push back(zrp); } } glPopMatrix(); }

(39)

cekaNaZpracovani, kter ý bude zajiˇstovat, v jakém poˇrad´ı se maj´ı uzly zpracovávat. Dále provedeme prvn´ı v ýpoˇcet posunut´ı pro vybranou primárn´ı doménu (uzel). Nej-prve vezme vˇsechny logické vazby, jdouc´ı od tohoto uzlu k jin ým, a pˇridáme je do se-znamu cekaNaZpracovani. Pro tyto úˇcely vyuˇzijeme strukturu sTMPMinBod, která je obohacena o koneˇcnou s´ılu p ˚usob´ıc´ı na doménu, která je na druhé stranˇe logické vazby (pruˇziny). Posléze vypoˇcteme transformaˇcn´ı matici pro vybranou doménu a uloˇz´ıme ji.

Potom v cyklu procház´ıme seznam cekaNaZpracovani. Pro kaˇzd ý cyklus vezmeme aktuáln´ı prvek ze seznamu. Projdeme seznam pouziteUzly a pokud se v tomto seznamu náˇs aktuáln´ı uzel nenacház´ı, tak ho tam pˇridáme. Dále vypoˇcteme pro tento uzel trans-formaˇcn´ı matici a uloˇz´ıme ji. Nakonec vytáhneme z aktuáln´ıho prvku seznam vˇsech lo-gick ých vazeb, které u sebe má, a uloˇz´ıme je do seznamu cekaNaZpracovani.

Cyklus konˇc´ı v okamˇziku, kdy nen´ı ˇz´adn ´y prvek v seznamu cekaNaZpracovani.

4.3.2 Shader - phong

Teoreticky popis Phongova st´ınovan´ı je naps´an v kapitole 2.3.2.

Navrˇzená struktura pro vykreslen´ı modelu má v urˇcitém pohledu jednu vlasnost, která je potˇreba vyˇreˇsit pˇred samotn ým vykreslen´ım. Vnitˇrn´ı stˇena mezi dvˇema pˇrilehaj´ıc´ımi doménami se duplikuje. Takto sice vzniknou dvˇe stˇeny, kaˇzdá u jedné domény, ale tyto stˇeny sd´ılej´ı jednu normálu. Pˇri posunut´ı ˇci otoˇcen´ı domény m ˚uˇze b ýt vidˇet, jak se neko-rektnˇe st´ınuj´ı tyto stˇeny. Proto pˇri vykreslován´ı v shaderu se kaˇzdá normála troj úheln´ıku, která by byla ve stejném smˇeru jak je pohled kamery, otáˇc´ı. jak znázor ˇnuje v ý ˇnatek k ód ˚u z vertex shaderu.

if (dot(vViewVec, vNormal) < 0.0)

vNormal∗= −1.0;

V ýpis 11: Pseudo algoritmus pro otoˇcen´ı normály Zde ukázan ý k ód z pixel shaderu je zredukovan ý jen na podstatné ˇcást´ı.

...

void main (void)

{ ...

(40)

if (lambertTerm > 0.0)

{

final color += color ∗ lambertTerm; vec3 E = normalize(vViewVec);

vec3 R = reflect (−normalize(vViewVec), vNormal);

float specular = pow( max(dot(R, E), 0.0), 30);

final color += MSpecular∗(specular/5.0); }

gl FragColor = final color ; }

V ´ypis 12: Pixel shader

Nejprve se vypoˇcte úhel mezi smˇerem kamery a normálou vykreslované stˇeny. Poté se rozhodne, zda je stˇena osv´ıcená. Nakonec se pˇridá reflexn´ı sloˇzka a spekulárn´ı sloˇzka.

4.3.3 Vyhlazov ´an´ı

Popis algoritmu pro vyhlazov´an´ı byl naps´an v kapitole 2.3.1.

Pro potˇreby algoritmu pro vyhlazován´ı bylo potˇreba zajistit správné pˇrisazen´ı reáln ých ID vrchol ˚u jednotliv ých element ˚u, protoˇze se v pr ˚ubˇehu zpracováván´ı modelu ID vr-cholu mˇenily. ˇReˇsen´ım tohoto problému bylo vytvoˇren´ı speciáln´ıho pole integeru s názvem RealID. Toto pole se poté vyplnilo reáln ými indexy vrchol ˚u ve funkci InitializeMeshParts tˇr´ıdy FEMCreator z dat GeometryInfo.

Následné vyhlazen´ı prob´ıhá po zavolán´ı funkce smooth, která je funkc´ı tˇr´ıdy Sce-neTree. Pro zrychlen´ı algoritmu je pole RealID setˇr´ıdˇeno. A ve funkci pomSSrovnej se provede samotné vyhlazen´ı.

(41)

Obr´azek 20: Uk´azka QtTreePropertyBrowser

Pouˇzit´ı této tˇr´ıdy najdeme uvnitˇr tˇr´ıdy visualDockWidget. K této tˇr´ıdˇe byla navrhnuta speciáln´ı tˇr´ıda visualVariantItem, která byla zdˇedˇena z QtVariantProperty a pˇredstavuje jednotlivé poloˇzky ze seznamu nastaven´ı. Interakce s t´ımto GUI prvkem byla zprostˇredkována skrze funkci valueChangedProp, která byla spojena pomoc´ı funkce connect s slotem va-lueChanged.

(42)

5 Testov ´an´ı

Tato posledn´ı kapitola je vˇenována testován´ı aplikace. Nalezneme zde popis modelu, konfiguraci PC, na kter ých byly provedeny testy. Testy byly provedeny ve tˇrech vlastnos-tech. Jako vlastnosti, které budou otestovány, byly vybrány fps, vyt´ıˇzen´ı pamˇeti a zátˇeˇz CPU. U kaˇzdého testu nalezneme pˇrehledn ý graf a zhodnocen´ı v ýsledk ˚u tohoto testu.

Testován´ı je ned´ılnou souˇcást´ı kaˇzdé aplikace. Na této diplomové práci (aplikaci) byly provádˇeny testy tˇr´ı vlastnost´ı. Prvn´ı vlastnost´ı bylo poˇcet frame per second (sn´ımku za sekundu), dále oznaˇcováno jen jako fps. Druhou vlastnost´ı byla vyt´ıˇzenost CPU a tˇret´ı vlastnost´ı bylo sledován´ı pamˇeti RAM.

Obr´azek 21: Uk´azka model 1

Aplikace byla testovan´a na poˇc´ıtaˇci s konfiguraci Intel Core2 Duo CPU 2.10 GHz, NVIDIA GeForce G205M, 4 GB RAM a syst´em Windows 7.

Jako testovac´ı modely byly zvoleny 3 základn´ı modely, jenˇz se naˇc´ıtaly z disku a byly ve speciáln´ım formátu. Modely vypadaj´ı totoˇznˇe, jenom se liˇs´ı v detailnosti propracován´ı a poˇctu domén.

Prvn´ı model zab´ırá na disku 1,94 MB. Má 3045 vrchol ˚u a skládá se z 13 domén. Na obrázku 21 si m ˚uˇzete prohlédnout, jak model vypadá.

Druh ý model zab´ırá na disku 15,7 MB. Má 90081 vrchol ˚u a skládá se ze 17 domén. Na obrázku 22 si m ˚uˇzete prohlédnout, jak model vypadá.

Tˇret´ı a nejsloˇzitˇejˇs´ı model ze vˇsech testovan ých model ˚u zab´ırá na disku 52,6 MB. Má 273976 vrchol ˚u a skládá se z 64 domén. Na obrázku 23 si m ˚uˇzete prohlédnout, jak model vypadá.

K testován´ı fps byly pouˇzity údaje, které poskytuje sama aplikace, pro testovac´ı úˇcely byla vypnuta vertikáln´ı synchronizace. Takˇze rychlost fps neodpov´ıdá skuteˇcné rychlosti zobrazován´ı na monitoru, ale udává potenciáln´ı rychlost v ýpoˇctu pro zobrazen´ı na mo-nitoru. Na testován´ı vyt´ıˇzenosti CPU byl pouˇz´ıt program Samurize, jenˇz je k dispozici pod licenc´ı Freeware. Autorem tohoto programu je Gustav & Oscar Lundh. K monito-rován´ı pamˇeti RAM byl pouˇz´ıt program RAM graf verze 1.999, kter ý je taky k dispozici pod licenc´ı Freeware. Autorem programu RAM Graf je DExUS.

(43)

FPS tedy poˇcet sn´ımku za sekundu je, jak uˇz název vypov´ıdá, d ˚uleˇzit ý pro rychlost vykreslován´ı. Rychlost vykreslovan´ı je jedn´ım z nejd ˚uleˇzitˇejˇs´ıch faktoru pro poˇc´ıtaˇcovou grafiku. N´ızká hodnota fps m ˚uˇze zp ˚usobovat sekán´ı obrazu nebo kazit iluzi pohybu. Pro bezproblémové sledovan´ı pohybu objektu pro naˇse oko je nejmenˇs´ı udávanou hodnotou 25 fps. Naprosto dostaˇcuj´ıc´ı hodnota b ývá 60 fps.

V ýkon CPU je taktéˇz d ˚uleˇzit ý. Vˇetˇs´ı v ýkon CPU znamená vˇetˇs´ı námahu na poˇc´ıtaˇc a nˇekdy znamená i poˇr´ızen´ı rychlejˇs´ıho CPU a tedy draˇzˇs´ı náklady.

Velikost spotˇrebovávané pamˇeti by mˇela j´ıt ruku v ruce s velikost´ı naˇc´ıtaného objektu. Takˇze i zde by mˇela b ýt snaha o co nejmenˇs´ı spotˇrebu pamˇeti, protoˇze velká spotˇreba pamˇeti znamená vˇetˇs´ı pamˇet’, a to zase navyˇsuje potˇrebu vˇetˇs´ı investice penˇez.

(44)

5.1 Testov ´an´ı - fps

Testován´ı fps prob´ıhalo ve tˇrech kroc´ıch. Prvn´ım krokem bylo zmˇeˇren´ı fps v klidovém stavu, kdy se s modelem nijak nemanipulovalo. Druh ý test se zamˇeˇril na mˇeˇren´ı fps pˇri náhodné manipulaci s modelem. Ve tˇret´ım testu bylo mˇeˇreno fps pˇri manipulaci s ˇcásteˇcnˇe pr ˚uhledn ým modelem. Testy prob´ıhaly nad shaderem typu phong.

Obr´azek 24: Testov´an´ı fps - stav v klidu

V grafu vid´ıme, ˇze model 1 a model 2 je jeˇstˇe nad hranic´ı dobré rychlosti fps. Model 3 je vˇsak uˇz pod hranic´ı, poˇcet fps se pohybuje okolo 24 sn´ımk ˚u za sekundu, coˇz je pˇribliˇznˇe frekvence sn´ımk ˚u u filmu, ale u poˇc´ıtaˇcové grafiky je to uˇz na hranˇe se sekán´ım obrazu. Model 3 má vˇsak 91krát v´ıce vrchol ˚u neˇz model 1 a vzhledem k tomu je 24 fps dostaˇcuj´ıc´ı.

Obr´azek 25: Testov´an´ı fps -pracovn´ı stav

Na grafu 2 vid´ıme m´ırn ý propad fps pˇri manipulaci s modelem. To je pochopitelné a oˇcekavatelné, protoˇze pˇri manipulaci s objektem se vykresluj´ı nav´ıc dalˇs´ı grafické prvky,

(45)

Obr´azek 26: Testov´an´ı fps s pr ˚uhlednost´ı

Na grafu 3 lze vidˇet pˇrekvapuj´ıc´ı zv ýˇsené fps oproti normálu. Oˇcekávali bychom pro-pad fps, protoˇze vykreslován´ı s pr ˚uhlednost´ı je sloˇzitˇejˇs´ı. Avˇsak pr ˚uhlednost je pouˇzita na objekty, u kter ých je vypnuta manipulace, a dále jsou tyto modely zjednoduˇsenˇe vykres-lovány. Proto je v ýsledné vykreslen´ı obrazovky u ˇcásteˇcnˇe pr ˚uhledn ých model ˚u rychlejˇs´ı neˇz normáln´ı vykreslen´ı.

(46)

5.2 Testov ´an´ı - CPU

Testován´ım vyt´ıˇzenosti CPU (obrázek 27) bylo zjiˇstˇeno, ˇze nejsloˇzitˇejˇs´ı model 3, jenˇz má 91krát v´ıce vrchol ˚u neˇz model 1, zatˇeˇzuje CPU dvakrát tak v´ıce neˇz model 1.

5.3 Testov ´an´ı - Pam ˇet

Pˇri testu pamˇeti bylo hlavn´ım c´ılem zjistit jej´ı vyuˇzit´ı pˇred a po naˇcten´ı jednotliv ých mo-delu. Testy byly provádˇeny dva. Jeden na zjiˇstˇen´ı, kolik dan ý model zab´ırá v pamˇeti m´ısta. A druh ý test, jenˇz byl vypoˇcten z prvn´ıho, byl zamˇeˇren na zjiˇstˇen´ı pomˇeru vyuˇzit´ı pamˇeti modelem k poˇctu vrchol ˚u, ze kter ých se model skládá.

Obr´azek 28: Testov´an´ı pamˇeti

Graf 28 nám ukazuje absolutn´ı vyuˇzit´ı pamˇeti. Tento graf nám vˇsak neˇrekne skoro nic, proto je lepˇs´ı pod´ıvat se na dalˇs´ı graf 29, kde je zobrazen pomˇer vyuˇzit´ı pamˇeti k poˇctu vrchol ˚u modelu. Zde vid´ıme, ˇze se hodnota pohybuje okolo ˇc´ısla dvˇe. Z toho vypl ývá, ˇze r ˚ust velikosti modelu v pamˇeti je lineárn´ı k velikosti modelu.

(47)

(48)

6 Z ´av ˇer

Vˇsechny c´ıle byly splnˇeny. Po implementaˇcn´ı stránce byly navrhnuty a vypracovány vˇsechny zadané úkoly, jmenovitˇe dekompozice Simple,Tree,Springs, vyhlazován´ı, sha-der, úprava a pˇridán´ı GUI rozhran´ı a pˇridán´ı alfa kanálu. Testy na fps prokázaly, ˇze si aplikace porad´ı s mal ými a stˇrednˇe velk ými modely. U velk ých model ˚u testy prokázaly, ˇze zobrazovac´ı rychlost fps je na hranˇe pˇr´ıpustné úrovnˇe, ale stále dostaˇcuj´ıc´ı. Testy na pamˇet nám ukázaly, ˇze spotˇrebovaná pamˇet roste linearnˇe s velikost´ı model ˚u. Velkou roli pro rychlost fps také pˇrispˇelo permanetn´ı nastaven´ı kreslen´ı pouze vnˇejˇs´ıch element ˚u. Doposud se kreslily i vnitˇrn´ı elementy.

Implementace dekompozice do aplikace se zdaˇrila. Vˇsechny tˇri dekompozice maj´ı navrhnuté vlastnosti a schopnosti. Dekompozice Simple je jednoduchou alternativou, která je vhodná pro rychlou dekompozici pro jednoduché modely. Dekompozice Tree je vhodnou volbou pro sloˇzitˇejˇs´ı modely, jenˇz potˇrebuj´ı pˇri rozpadu ˇcásteˇcnou kontrolu nad modelem. Posledn´ı tˇret´ı dekompozice Springs se ukázala jako vhodná volba pro sloˇzité modely, pro které jsou predeˇslé dvˇe dekompozice nedostaˇcuj´ıc´ı.

V ýpoˇcet vyhlazen´ı modelu je rychl ý a normály ve vrcholem správnˇe nastavuj´ı. Vyhla-zován´ı a navrhnut ý shader zlepˇsuje obrazov ý vjem modelu. Pˇridané prvky grafického uˇzivatelského rozhran´ı byly ˇrádné um´ıstˇeny do oblasti, kam by mˇely intuitivnˇe patˇrit, taktéˇz jejich ovládán´ı je jednoduché a pˇrehledné.

Vykonané testy ukázaly dobrou kvalitu aplikace. Testy na fps prokázaly dostateˇcnˇe rychle vykreslen´ı i pro sloˇzité modely. Testy na vyuˇzit´ı pamˇeti provˇeˇrily dobré hospodaˇren´ı s pamˇeti, tedy vyuˇzit´ı pamˇeti roste lineárnˇe s velikost´ı modelu. A CPU testy nezazname-naly, ˇzádné velké zat´ıˇzen´ı procesoru. Celkové je aplikace sviˇzná a rychlá.

(49)

[4] Mike Bailey: Using GPU Shaders for Visualization, IEEE Computer Graphics and Ap-plications, 2009.

[5] Yinlong Sun, Qiqi Wang: Interference Shaders of Thin Films, Comput. Graph. Forum, 2008.

[6] Mike Bailey: Teaching OpenGL shaders: Hands-on, interactive, and immediate feedback, Computers and Graphics, 2007.

[7] Wolfgang Engel: GPU Pro: Advanced Rendering Techniques, ISBN-10: 1568814720, 2010.

[8] Alan Ezust, Paul Ezust: Introduction to Design Patterns in C++ with Qt (2nd Edition), Prentice Hall, 2008.

[9] Jasmin Blanchette and Mark Summerfield: C++ GUI Programming with Qt 4 (2nd Edition) - The official C++/Qt book, Prentice Hall, 2008.

[10] Mark Summerfield: Advanced Qt Programming: Creating Great Software with C++ and Qt 4, Prentice Hall, 2010.

[11] Johan Thelin: Foundations of Qt Development, Apress, 2007.

[12] Frank H. P. Fitzek, Tommi Mikkonen, Tony Torp: Qt for Symbian, Forum Nokia, 2010. [13] Boudewijn Rempt: Python: Qt Edition, OpenDocs, LLC , 2002.

[14] J. N. Reddy: Introduction to the Finite Element Method, McGraw-Hill Science/Enginee-ring/Math; 2 edition, 1993.

[15] David Moratal: Finite Element Analysis, Sciyo, August, 2010

[16] S.S. Bhavikatti: Finite Element Analysis, New Age International, 2007.

[17] Daryl L. Logan: A First Course in the Finite Element Method, Cengage Learning, 2007 [18] Thomas J. R. Hughes: The Finite Element Method: Linear Static and Dynamic Finite

(50)

[19] Tirupathi R. Chandrupatla, Ashok D. Belegundu: Introduction to finite elements in en-gineering, Prentice Hall, 1997.

[20] Eduard Sojka, Poˇc´ıtaˇcová grafika II: metody a nástroje zobrazován´ı 3D scén, VˇSB-TUO. [21] Andrew S. Glassner: An Introduction to Ray Tracing, Morgan Kaufmann, 1989. [22] Peter Shirley, R. Keith Morley: Realistic Ray Tracing, A K Peters Ltd, 2009.

[23] Tomas M ¨oller, Eric Haines, Naty Hoffman: Real-Time Rendering, CRC Press, 2008. [24] Matt Pharr, Greg Humphreys, Greg Humphreys (Ph. D.): Physically Based Rendering:

From Theory To Implementation, Morgan Kaufmann, 2004.

[25] Henrik Wann Jensen: Realistic image synthesis using photon mapping, A K Peters, 2001. [26] John R. Wallace: Radiosity and Realistic Image Synthesis, Morgan Kaufmann, 1993. [27] Arie Kaufman: Volume visualization, IEEE Computer Society Press, 1991.

[28] Min Chen, Arie Kaufman, Roni Yagel: Volume graphics, Springer, 2000.

[29] Erhard Neher, Alistair Savage, Weiqiang Wang: Geometric Representation Theory and Extended Affine Lie Algebras, American Mathematical Soc., 2011.

[30] Michael Richard Gosz: Finite Element Method: Applications in Solids, Structures, And Heat Transfer, Taylor and Francis, 2006.

[31] Young W. Kwon, Hyochoong Bang: The Finite Element Method Using Matlab, CRC Press, 2000.