VRUT V aclav Kyba, Anton n M sek a dal s

Ceske vysoke ucenı technicke v Praze, Fakulta elektrotechnickaSkoda-auto a.s.

Dokumentace aplikace

VRUT

Vaclav Kyba, Antonın Mısek a dalsı

Odborny konzultant: Ing. Jirı Bittner, Ph.D.

unor 2010

2

Obsah

1 Uvod 111.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1.1 Historie a struktura dokumentace . . . . . . . . . . . . 12

2 Analyza a navrh resenı 132.1 Jadro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 Spravce modulu . . . . . . . . . . . . . . . . . . . . . 142.1.2 Logovanı zprav . . . . . . . . . . . . . . . . . . . . . . 152.1.3 Uzivatelske rozhranı . . . . . . . . . . . . . . . . . . . 152.1.4 Spravce promennych . . . . . . . . . . . . . . . . . . . 152.1.5 Spravce scen . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Sprava a distribuce udalostı . . . . . . . . . . . . . . . . . . . 152.2.1 Distribuce . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2 Prıjem a zpracovanı . . . . . . . . . . . . . . . . . . . 16

2.3 Graf sceny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.1 Transformacnı hierarchie . . . . . . . . . . . . . . . . . 172.3.2 Komunikace se scenou . . . . . . . . . . . . . . . . . . 172.3.3 Typy uzlu . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.4 Geometrie . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.5 Material . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.6 Sdılenı dat . . . . . . . . . . . . . . . . . . . . . . . . 202.3.7 Alternativy . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Hierarchie obalek . . . . . . . . . . . . . . . . . . . . . . . . . 212.4.1 Vztah BVH a sceny . . . . . . . . . . . . . . . . . . . 21

2.5 Moduly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.1 Komunikace . . . . . . . . . . . . . . . . . . . . . . . . 222.5.2 Typy modulu . . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Komercnı resenı . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Realizace a implementace 353.1 Jadro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2 Komunikacnı system . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.1 Prıjem a zpracovanı . . . . . . . . . . . . . . . . . . . 38

3

4 OBSAH

3.2.2 Udalosti . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3 Zobrazovacı system . . . . . . . . . . . . . . . . . . . . . . . . 413.4 Scena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4.1 Transformace uzlu . . . . . . . . . . . . . . . . . . . . 423.4.2 Entity ve scene . . . . . . . . . . . . . . . . . . . . . . 433.4.3 Pravidla prıstupu k datum sceny . . . . . . . . . . . . 463.4.4 Uprava sceny . . . . . . . . . . . . . . . . . . . . . . . 47

3.5 BVH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.5.1 Konstrukce . . . . . . . . . . . . . . . . . . . . . . . . 483.5.2 Aktualizace . . . . . . . . . . . . . . . . . . . . . . . . 503.5.3 Orezanı pohledovym jehlanem . . . . . . . . . . . . . 50

3.6 Uzivatelske rozhranı . . . . . . . . . . . . . . . . . . . . . . . 543.6.1 Graficke uzivatelske rozhranı . . . . . . . . . . . . . . 563.6.2 Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.6.3 Renderer . . . . . . . . . . . . . . . . . . . . . . . . . 573.6.4 Drag&Drop . . . . . . . . . . . . . . . . . . . . . . . . 573.6.5 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 57

3.7 Moduly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.7.1 Identifikace . . . . . . . . . . . . . . . . . . . . . . . . 593.7.2 Hlavnı smycka . . . . . . . . . . . . . . . . . . . . . . 593.7.3 Aktivace . . . . . . . . . . . . . . . . . . . . . . . . . . 613.7.4 Komunikace s jadrem . . . . . . . . . . . . . . . . . . 623.7.5 Synchronnı komunikace . . . . . . . . . . . . . . . . . 633.7.6 Casovy limit pro prıjem udalosti . . . . . . . . . . . . 643.7.7 Typy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.7.8 Alokace pameti versus modul . . . . . . . . . . . . . . 653.7.9 Registrovane parametry . . . . . . . . . . . . . . . . . 653.7.10 kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.7.11 Implementace konkretnıch typu modulu . . . . . . . . 70

3.8 Zakladnı moduly . . . . . . . . . . . . . . . . . . . . . . . . . 743.9 Moduly studentu . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.9.1 IOVRML (autori Hana Truskova a Michael Smutny) . 753.9.2 (autor Milan Stezka) . . . . . . . . . . . . . . . . . . 763.9.3 Tracking a TrackingManipulator (autor Radek Bien) . 763.9.4 CollisionDetection (autor Filip Krystl) . . . . . . . . . 763.9.5 Scripting (autori Jakub Zelenka a Vojtech Sedlacek) . 77

3.10 Strucny prehled modulu . . . . . . . . . . . . . . . . . . . . . 793.10.1 IO moduly . . . . . . . . . . . . . . . . . . . . . . . . 793.10.2 Podpora HW . . . . . . . . . . . . . . . . . . . . . . . 793.10.3 Uprava sceny . . . . . . . . . . . . . . . . . . . . . . . 793.10.4 Interakce . . . . . . . . . . . . . . . . . . . . . . . . . 803.10.5 Renderery . . . . . . . . . . . . . . . . . . . . . . . . . 803.10.6 Literatura . . . . . . . . . . . . . . . . . . . . . . . . . 80

OBSAH 5

4 Seznam vnitrnıch udalostı VRUT 83

5 Podpora Unicode 89

6 Instalace wxWidgets 916.1 Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . 916.2 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7 Zdrojove soubory VRUT 997.1 Dokumentace . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

8 Novy modul 1038.1 Prıprava . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038.2 Doporucenı . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

9 Uzivatelska prırucka 1059.1 Instalace a spustenı VRUTu . . . . . . . . . . . . . . . . . . . 105

9.1.1 Struktura VRUTu . . . . . . . . . . . . . . . . . . . . 1059.1.2 Spustenı aplikace . . . . . . . . . . . . . . . . . . . . . 105

10 Stereoskopie 10710.1 Zadanı ulohy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10710.2 Uvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

10.2.1 Motivace a popis problemu . . . . . . . . . . . . . . . 10710.2.2 Souvisejıcı prace . . . . . . . . . . . . . . . . . . . . . 108

10.3 Navrh resenı . . . . . . . . . . . . . . . . . . . . . . . . . . . 10810.3.1 Obecna perspektiva . . . . . . . . . . . . . . . . . . . 10810.3.2 Kamerove konfigurace . . . . . . . . . . . . . . . . . . 10810.3.3 Tracking perspektivy . . . . . . . . . . . . . . . . . . . 109

10.4 Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . 11010.4.1 Trıda Camera . . . . . . . . . . . . . . . . . . . . . . . 11010.4.2 Trıda Scene . . . . . . . . . . . . . . . . . . . . . . . . 11110.4.3 Ruzne . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

10.5 Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11110.5.1 Ovladanı . . . . . . . . . . . . . . . . . . . . . . . . . 11110.5.2 Udalosti . . . . . . . . . . . . . . . . . . . . . . . . . . 112

10.6 Zaver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

11 Pruvodce programatora 11511.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11511.2 Hodnocenı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

11.2.1 Hodnocenı zaverecne zpravy . . . . . . . . . . . . . . 11511.2.2 Hodnocenı zdrojoveho kodu . . . . . . . . . . . . . . . 115

11.3 Popis jadra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11711.3.1 Jak vytvorit novy uzel ve scene . . . . . . . . . . . . . 117

6 OBSAH

11.3.2 Jak zmenit geometrii nebo material . . . . . . . . . . 11711.3.3 Je jadro thread-safe? . . . . . . . . . . . . . . . . . . . 117

11.4 Popis vrut AM.sln, * AM.proj, makefile.win, atd. . . . . . . . 11711.4.1 Jak vytvorit * AM.vcproj pro novy modul . . . . . . . 11811.4.2 Jak vytvorit makefile.win pro novy modul . . . . . . . 11811.4.3 Jak zajistit, aby se novy modul prekladal spolecne s

projektem . . . . . . . . . . . . . . . . . . . . . . . . . 11811.4.4 Jak vytvorit makefile.debian pro novy modul . . . . . 11811.4.5 Kompilace trva prılis dlouho, kompilace zabere prılis

mnoho pameti, apod. . . . . . . . . . . . . . . . . . . 11911.4.6 Projekt nelze zkompilovat . . . . . . . . . . . . . . . . 119

11.5 Poznamky k programovacım technikam . . . . . . . . . . . . 11911.5.1 Proc je lepsı pouzıt referenci nez odkaz? . . . . . . . . 11911.5.2 Optimalizace rychlosti . . . . . . . . . . . . . . . . . . 11911.5.3 Uniky pameti a dalsı chyby . . . . . . . . . . . . . . . 12011.5.4 Proc nenı vhodne pouzıvat wxStringTokenizer, wxString::ToDouble,

wxString::Format(wxT(”%f”), val) a dalsı veci z wxWid-gets? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

11.5.5 Co je spatne na konstrukci: Vector3 vec2 = Vector3(vec1);?121

12 Modul C3Dconnexion 12312.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12312.2 Ovladanı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12312.3 Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

12.3.1 Windows . . . . . . . . . . . . . . . . . . . . . . . . . 12312.3.2 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

12.4 Popis implementace . . . . . . . . . . . . . . . . . . . . . . . 12412.4.1 Windows . . . . . . . . . . . . . . . . . . . . . . . . . 12412.4.2 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

13 Modul AdamsToDG 12513.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

14 Modul CameraManipulator 12714.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

15 Modul Cluster 12915.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12915.2 Detaily implementace . . . . . . . . . . . . . . . . . . . . . . 12915.3 Navod na pouzitı . . . . . . . . . . . . . . . . . . . . . . . . . 130

15.3.1 Jednorazova synchronizace sceny . . . . . . . . . . . . 13015.3.2 Prubezna aktualizace klientu . . . . . . . . . . . . . . 13015.3.3 ConfigurationTable . . . . . . . . . . . . . . . . . . . . 13015.3.4 CarpetsTable . . . . . . . . . . . . . . . . . . . . . . . 130

OBSAH 7

15.4 Problemy a chyby . . . . . . . . . . . . . . . . . . . . . . . . 13015.5 Vzdalena sprava klientu . . . . . . . . . . . . . . . . . . . . . 131

15.5.1 Ukazka pouzitı PSTools . . . . . . . . . . . . . . . . . 13115.6 Konfigurace projekce . . . . . . . . . . . . . . . . . . . . . . . 132

16 Modul IOAC3D 13516.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13516.2 Formaty AC a ACC . . . . . . . . . . . . . . . . . . . . . . . 13516.3 Omezenı s specifika implementace . . . . . . . . . . . . . . . . 135

17 Modul IOCSB 13717.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13717.2 Format CSB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13717.3 Omezenı s specifika implementace . . . . . . . . . . . . . . . . 137

17.3.1 Import . . . . . . . . . . . . . . . . . . . . . . . . . . . 13717.3.2 Export . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

18 Modul IODOF 13918.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13918.2 Format DOF . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

18.2.1 Omezenı formatu . . . . . . . . . . . . . . . . . . . . . 13918.3 Omezenı a specifika implementace . . . . . . . . . . . . . . . 139

18.3.1 Import . . . . . . . . . . . . . . . . . . . . . . . . . . . 13918.3.2 Export . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

19 Modul IOFHS 14119.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14119.2 Format FHS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14119.3 Omezenı a specifika implementace . . . . . . . . . . . . . . . 141

19.3.1 Import . . . . . . . . . . . . . . . . . . . . . . . . . . . 14119.3.2 Export . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

20 Modul IOImage 14320.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

21 Modul IOOBJ 14521.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14521.2 Format OBJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14521.3 Omezenı a specifika implementace . . . . . . . . . . . . . . . 145

21.3.1 Import . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

22 Modul IORDF 14722.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14722.2 Format RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

22.2.1 Omezenı formatu . . . . . . . . . . . . . . . . . . . . . 147

8 OBSAH

22.3 Omezenı a specifika implementace . . . . . . . . . . . . . . . 14722.3.1 Import . . . . . . . . . . . . . . . . . . . . . . . . . . . 14722.3.2 Export . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

23 Modul IOSTL 14923.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14923.2 Format STL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14923.3 Omezenı a specifika implementace . . . . . . . . . . . . . . . 149

23.3.1 Import . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

24 Modul MaterialAssign 15124.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15124.2 Popis ovladanı . . . . . . . . . . . . . . . . . . . . . . . . . . 151

24.2.1 sceneID . . . . . . . . . . . . . . . . . . . . . . . . . . 15124.2.2 materialLibrarySceneID . . . . . . . . . . . . . . . . . 15124.2.3 tableFile . . . . . . . . . . . . . . . . . . . . . . . . . . 15124.2.4 load . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15124.2.5 save . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15124.2.6 assignMaterials . . . . . . . . . . . . . . . . . . . . . . 15224.2.7 simulateAssigning . . . . . . . . . . . . . . . . . . . . 152

25 Modul MaterialEditor 15325.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15325.2 Popis ovladanı . . . . . . . . . . . . . . . . . . . . . . . . . . 153

25.2.1 sceneID . . . . . . . . . . . . . . . . . . . . . . . . . . 153

26 Modul Optimize 15526.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15526.2 Popis metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

26.2.1 SceneID . . . . . . . . . . . . . . . . . . . . . . . . . . 15526.2.2 nameMask . . . . . . . . . . . . . . . . . . . . . . . . 15526.2.3 delete . . . . . . . . . . . . . . . . . . . . . . . . . . . 15526.2.4 simplifyStructure . . . . . . . . . . . . . . . . . . . . . 15526.2.5 removeUnesedMaterials . . . . . . . . . . . . . . . . . 15626.2.6 unifyMaterials . . . . . . . . . . . . . . . . . . . . . . 15626.2.7 unifyVertices . . . . . . . . . . . . . . . . . . . . . . . 15626.2.8 removeUnesedGeometries . . . . . . . . . . . . . . . . 15626.2.9 mergePrimitives . . . . . . . . . . . . . . . . . . . . . 15626.2.10 deleteNormals . . . . . . . . . . . . . . . . . . . . . . . 15626.2.11 deleteTexCoords . . . . . . . . . . . . . . . . . . . . . 15626.2.12 removeLODs . . . . . . . . . . . . . . . . . . . . . . . 15626.2.13 stripe . . . . . . . . . . . . . . . . . . . . . . . . . . . 15626.2.14 statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 157

26.3 Navod na optimalizaci sceny importovane z CSB . . . . . . . 157

OBSAH 9

27 Modul RenderGL 15927.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

28 Modul SeatStitcher 16128.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16128.2 Detaily implementace . . . . . . . . . . . . . . . . . . . . . . 161

28.2.1 computeNormal . . . . . . . . . . . . . . . . . . . . . . 16128.2.2 Direct . . . . . . . . . . . . . . . . . . . . . . . . . . . 16128.2.3 Perpendicular . . . . . . . . . . . . . . . . . . . . . . . 16228.2.4 Cross . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

28.3 Navod na pouzitı . . . . . . . . . . . . . . . . . . . . . . . . . 162

29 Modul Terrain 16329.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

30 Multipass rendering for VRUT 16530.1 Task Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 16530.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

30.2.1 Motivation and Problem Overview . . . . . . . . . . . 16530.2.2 Related work . . . . . . . . . . . . . . . . . . . . . . . 166

30.3 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . 16630.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 167

30.4.1 Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . 16730.4.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 168

30.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16830.6 User Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

30.6.1 Module Parameters . . . . . . . . . . . . . . . . . . . . 17030.6.2 Module Controls . . . . . . . . . . . . . . . . . . . . . 17030.6.3 Module Events . . . . . . . . . . . . . . . . . . . . . . 170

30.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

31 Modul SceneGraph 17531.1 Co to je . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17531.2 Popis metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

31.2.1 SceneID . . . . . . . . . . . . . . . . . . . . . . . . . . 175

10 OBSAH

Kapitola 1

Uvod

1.1 Co to je

Aplikace pro vizualizaci a editaci 3D dat vytvarena ve spolupraci SKODAAUTO a.s. a CVUT, ktera si klade za cıl:- vyuzitı novych technologiı- poskytnutı zvlastnı funkcionality- podpora systemu a formatu Skoda auto- vysoka rychlost- pouzitelnost pro vyuku a experimenty

Obrazek 1.1: Bitmapovy obrazek.

Projekt s nazvem VRUT vznikl v ramci spoluprace katedry pocıtacovegrafiky a interakce CVUT FEL s firmou Skoda Auto. Jeho podstatou je zo-brazenı grafickych dat a podpora modulu. Moduly umoznujı rozsırenı funkcıhlavnı aplikace pri relativnı nezavislosti na nı.

Nazev VRUT je zkratkou anglickeho Virtual Reality Universal Toolkita mel by zhruba evokovat, co aplikace nabızı, tj. univerzalnı a flexibilnı

11

12 KAPITOLA 1. UVOD

nastroj pro praci s grafickymi daty. VRUT muze fungovat jako urcity spojo-vacı clanek mezi nekolika subjekty. Jednotlive subjekty mohou zadavat ruzneulohy tykajıcı se zobrazenı nebo jinych operacı nad grafickymi daty a resiteletechto uloh vytvorı kompatibilnı modul (plugin). Nova funkcnost realizo-vana formou modulu je pote pouzitelna vsude tam, kde se VRUT pouzıva.Zatımco na strane skoly bude VRUT slouzit spıse jako pomocny vyvojovynastroj, ve Skoda Auto budou skrze nej uvedeny do praxe nejruznejsı modulyvytvorene treba prave studenty skoly. Resitelum uloh odpada nutnost imple-mentovat casti, jako je vstup, vystup, graficky vystup, graf sceny a mnohedalsı, ktere se netykajı prımo ulohy. Mısto toho se mohou plne soustredit naresenı sveho problemu ve vlastnım modulu.

Obrazek 1.2: VR Skoda Auto

1.1.1 Historie a struktura dokumentace

Ve VRUTu probıha stale hodne zmen a dokumentace je tak v podstateneustale v nekterych castech zastarala. Nemuzete-li chyby opravit, alesponje prosım nahlaste.

Hlavnı cast teto dokumentace vznikla jako diplomova prace VaclavaKyby (prvnıch sedm kapitol). Pozdeji byl stanoven jednotny system psanıdokumentace pro jednotlive moduly, ktera je nynı pridana na konec tohotodokumentu.

Pro detailnı informace o implementaci a rozhrannı slouzı dokumentacegenerovana pomocı Doxygenu.

Kapitola 2

Analyza a navrh resenı

Modularnı aplikace vyuzıva pro svuj chod moduly (pluginy). Funkcnostposkytovana moduly muze byt pro aplikaci zasadnı nebo pouze rozsirujıcı.Vzhledem k pozadavku na maximalnı flexibilitu projektu je v prıpade VRUTvhodnejsı prvnı moznost. Minimalizace hlavnı casti a presun co mozna nejvıcefunkcnıch prvku do externıch modulu muze mıt v dusledku sva pro a proti.Vyhodou je bezpochyby snadna nahraditelnost jednotlivych castı a na urovnikodu snadnejsı sprava a testovanı. Nevyhodou muze byt zvysena rezie a jistaomezenı v zavislosti na zvolene forme modulu.

Projekt by se dal rozdelit na dve casti, hlavnı aplikace nebo jadro azakladnı balıcek modulu. Hlavnı aplikace je sama o sobe z uzivatelskehohlediska nepouzitelna pro jakoukoliv praci; az s pomocı zakladnıch modulujsou zprıstupneny funkce, jako naprıklad nactenı a zobrazenı sceny. Poj-menovanı jadro jakozto stezejnı cast hlavnı aplikace (viz obr. 2.1) muzebyt v dalsım textu zameneno za hlavnı aplikaci a naopak, vyrazy se dajıpovazovat za ekvivalentnı.

Prvnı cast kapitoly (sekce 2.1) strucne predstavuje prıme soucasti jadra,dale nasleduje blizsı popis stezejnıch castı VRUT, kterymi jsou system ko-munikace v aplikaci (sekce 2.2), scena (sekce 2.3), hierarchie obalek (sekce2.4) a sprava modulu (sekce 2.5). Poslednı cast srovnava resenı s komercnımiprodukty (sekce 2.6). Popis realizace a poznamky k implementaci projektujsou v kapitole 3.

2.1 Jadro

Primarnımi funkcemi jadra jsou sprava modulu a sprava grafickych dat,dale pak jadro poskytuje pomocne prvky pro spravny beh a ovladanı ap-likace. Velmi podstatnou castı jadra je take sprava udalostı tvorıcı centralnıprvek komunikacnıho kanalu mezi jednotlivymi castmi aplikace a moduly.

13

14 KAPITOLA 2. ANALYZA A NAVRH RESENI

2.1.1 Spravce modulu

Spravce modulu zjist’uje dostupnost modulu pro danou platformu a takejejich kompatibilitu s jadrem. Spravce poskytuje zcela transparentnı uvedenıdostupneho modulu do zivota a jeho korektnı spojenı s jadrem. Modulyjsou aktivovany pouze na zadost v prıpade potreby, navıc je mozne vıceaktivacı tehoz modulu, aniz by se navzajem nechtene ovlivnovaly. V prıpadevıce modulu poskytujıcıch stejnou funkci se spravce rozhoduje podle priorit,pokud jsou definovany.

Vzhledem k potrebe obslouzit velmi rozlicne pozadavky smerovane vevysledku na ruzne typy modulu obsahuje spravce modulu dılcı casti, spravcejednotlivych typu. Spravci majı na starosti urcitou podskupinu modulustejneho nebo kompatibilnıho typu. Kazdy pozadavek na funkcnost poskyto-vanou modulem je smerovan odpovıdajıcımu serveru, ktery se snazı vyhovetpodle danych pravidel a aktivovat prıslusny modul. Provazanost nekterychtypu modulu s jadrem vyzaduje zvlastnı zachazenı, proto typy spravcu doznacne mıry odpovıdajı typum podporovanych modulu.

Import/export spravce

Spravce sdruzuje moduly pro praci se soubory. Moduly slouzı k nactenınektereho z grafickych formatu a prevedenı sceny do internı reprezentace.Na strane jadra je podpora pro archivy, prace s nimi je transparentnı, tzn.naprıklad pri nacıtanı sceny z archivu je automaticky vznesen pozadavekpro nactenı sceny z dekomprimovaneho obsahu archivu. Moduly zpravidlaposkytujı take moznost exportu sceny do prıslusneho formatu.

Spravce zobrazovacıch modulu

Spravce poskytuje modulum prıstup ke grafickym datum v grafu sceny.Primarne jde o moduly pro graficke zobrazenı. Spravce navıc zajist’uje spravneprirazenı a aktualizaci zobrazovacıch oken.

Spravce manipulatoru

Dalsı skupinu modulu sdruzuje spravce manipulatoru, jehoz hlavnı funkcıje prirazenı uzlu sceny (napr. kamery) k prıslusnemu manipulatoru a spravnepropojenı toku udalostı ze vstupnıch zarızenı.

Obecny spravce

Vsechny ostatnı typy modulu, ktere nevyzadujı specialnı provazanı sjadrem, sdruzuje obecny spravce. Obecny spravce umı modul nahrat a ak-tivovat, ale dalsı operace jsou uz zalezitostı modulu a zavisı na moznostechAPI jadra.

2.2. SPRAVA A DISTRIBUCE UDALOSTI 15

2.1.2 Logovanı zprav

Jedinou funkcı teto casti jadra je volitelny zaznam nastalych udalostı dosouboru a specialnıho okna. Parametrem kazde zpravy je priorita, s jakouma byt uzivatel upozornen, od nejvyssı fatalnı chyby pres varovanı a infor-mativnı az po debugovacı zpravy. V okne s vypisy lze nastavit minimalnıuroven zprav, ktere majı byt zobrazovany.

2.1.3 Uzivatelske rozhranı

Krome pasivnıho vystupu v podobe log zprav je nekolik moznostı jakaktivne ovlivnit beh aplikace. Nejmocnejsım nastrojem je prıkazova kon-zole, ktera je prımou soucastı GUI a umoznuje zadavanı prıkazu, ktere jsouhned po zadanı prıslusne interpretovany a provedeny. Prıkazy lze zadat takeformou skriptu, ktery je nacten pri spustenı nebo az za chodu prıkazemkonzole.

Prirozenym zpusobem interakce jsou GUI prvky, ktere jsou prımo spo-jeny s urcitou operacı a/nebo zpusobı vyslanı popisujıcı udalosti do systemu(viz sekce 2.2). Trochu mene obvyklym zpusobem ovladanı muze byt systemregistrovanych parametru, ktery nenı primarne urcen pro tento ucel (vizsekce 2.1.4).

2.1.4 Spravce promennych

Tato cast jadra sleduje aktualnı stav registrovanych promennych s moznostıjejich uprav. Kazdy modul ma moznost zaregistrovat si jednu ci vıce promennychruznych typu a sledovat nebo upravovat jejich hodnotu. Hlavnı vyznamspocıva v moznosti provadet tyto upravy za behu aplikace bez nutnostijakehokoli zasahu do vlastnı implementace. Sledovanı a uprava registrovanychpromennych probıha prostrednictvım prıkazove konzole nebo grafickeho rozhranı.

2.1.5 Spravce scen

Dulezitou soucast jadra tvorı spravce scen, ktery zastresuje vsechnagraficka data ve forme scen. Spravce scen poskytuje prıstup ke spravovanymscenam a take datum sdılenym mezi scenami (viz obr. 2.2), pracuje jakohlavnı uloziste obrazovych dat - textur.

2.2 Sprava a distribuce udalostı

Aplikace je rozdelena na jednotlive casti, ktere jsou na sobe maximalnenezavisle (predevsım co se modulu tyce). Casti je mozne si predstavit jakoobjekty, ktere mezi sebou potrebujı komunikovat, ale jinak si do jiste mıryzijı vlastnım zivotem. Pojmy nezavislost a samostatnost platı obzvlaste promoduly, ktere zpravidla pracujı ve vlastnım vlakne.


Zvoleny system komunikace pracuje na bazi udalostı (zprav) podobnejako treba u objektoveho programovacıho jazyka SmallTalk. Dıky komu-nikaci zasılanım udalostı nenı nutne znat programove rozhranı jednotlivychobjektu, stacı, aby kazdy zapojeny objekt umel prijmout a zpracovat udalost.Ve vıcevlaknovem prostredı je zasılanı udalostı zcela bezpecne, nenı trebadbat zvysene opatrnosti nebo pouzıvat specialnı strategie paralelnıho pro-gramovanı tak jako pri pouzitı prımeho prıstupu k programovemu rozhranıobjektu. System udalostı muze velmi usnadnit prıpadnou potrebu komu-nikovat take mezi procesy nebo uzly sıte, stacı pridanı jednoduche vrstvypro prenos naprıklad formou modulu. Kazdy komunikacnı objekt muze bytjak prıjemcem, tak odesılatelem udalostı.

Nevyhodou udalostı je ne zcela trivialnı synchronizace, protoze zaslanıudalosti je pouze jednosmernou operacı. Pro synchronizaci dvou nebo vıceobjektu je treba, aby zaslana udalost vyvolala odezvu v podobe jine znameudalosti, na kterou objekty vyckajı v blokujıcım modu.

Udalosti zpravidla prochazı skrze centralnı spravu udalostı v jadru. Spravceudalostı obsahuje v jiste forme kazdy objekt zapojeny do systemu komu-nikace, v prıpade jadra je to prave centralnı spravce. Krome zpracovanıudalostı adresovanym prımo jadru poskytuje nekolik operacı navıc, zajist’ujebezpecnou alokaci a dealokaci dat pridruzenych k udalostem a distribuci.

Udalosti nejsou zpravidla adresovany konkretnımu objektu, ale jsou zasılanycentralnımu spravci, ktery je distribuuje prıslusnym odberatelum (viz sekce2.2.1). Udalost lze take zaslat soukrome prımo cılovemu objektu (pokudjım nenı jadro) bez ucasti centralnıho spravce. Prıma komunikace muzebyt vyhodna v prıpade potreby minimalnı delky odezvy, udalost neprochazızadnymi meziclanky. Na druhou stranu nenı takova udalost distribuovanadalsım prıjemcum.

2.2.1 Distribuce

Centralnı komunikacnı kanal je volne prıstupny, kazdy objekt tak muzeprijımat libovolny typ udalostı v systemu. Podmınkou je, aby udalost slastandardnı cestou pres centralnıho spravce a aby objekt byl u nej zareg-istrovan k odberu daneho typu udalosti. Objekt se tımto zpusobem samoznacı za adresata vsech budoucıch udalostı zaregistrovaneho typu. Znazornenıdistribuce udalosti registrovanym odberatelum je na obr. 2.4. Kazdy novevytvoreny objekt (napr. modul) tak muze ihned reagovat na stavajıcı udalostibez jakehokoliv programoveho zasahu do ostatnıch objektu.

2.2.2 Prıjem a zpracovanı

Udalosti jsou zpracovavany objektem ve stejnem poradı, v jakem bylyprijaty metodou FIFO (First In First Out - obslouzena je vzdy prvnı polozkav rade). Tato vlastnost je dulezita pro operace skladajıcı se z vıce udalostı,

2.3. GRAF SCENY 17

kde zalezı na poradı a nenı nutna synchronizace. Vyjimkou jsou udalosti za-slane s vyssı prioritou, ktere jsou zpracovany prednostne. V prıpade prijetıvıce prioritnıch udalostı najednou probıha zpracovanı metodou LIFO (LastIn Last Out - obslouzena je vzdy posledne prijata polozka). Tento modelumoznuje spojenı udalostı obou priorit do jedine fronty s razenım prioritnıchudalostı na zacatek. Prıznak priority nenı soucastı udalosti, je nastaven ar-gumentem pri volanı metody pro odeslanı. Poradı zpracovanı podle odeslanıv case je znazorneno na obr. 2.5 (cervena barva znacı udalosti odeslane svyssı prioritou).

2.3 Graf sceny

Graf sceny predstavuje hlavnı a strukturovane uloziste grafickych dat. N-arnı strom reprezentuje vzajemne vztahy mezi logickymi celky sceny. Vzhle-dem k tomu, ze jde o cast s nejvyssım poctem prıstupu, je graf sceny umıstenprımo v jadre bez moznosti nahrady externım modulem. Datove strukturygrafu jsou jednoznacne dane a spolecne pro vsechny moduly, ktere s grafemsceny prijdou do styku.

Je velmi dulezite, aby reprezentace sceny byla dobre navrzena a splnovalaco nejvıce pozadavku zakladnıch, ale i budoucıch modulu. Naprosta vetsinamodulu nejakym zpusobem pracuje s pridelenou scenou, reprezentace scenyje zcela zasadnı pro celou aplikaci. Zasah do nı znamena zasah do jadra, cozmuze zpusobit nekompatibilitu mnoha stavajıcıch modulu.

2.3.1 Transformacnı hierarchie

Zakladnım prvkem grafu sceny je uzel. Uzel muze obsahovat prımo grafickadata a muze mıt libovolny pocet potomku. Graf sceny predstavuje trans-formacnı hierarchii (viz obr. 2.6). Kazdy uzel sceny bez ohledu na typma transformacnı matici, ktera definuje umıstenı podstromu (uzlu a jehopotomku) jako logickeho celku v lokalnım merıtku. Umıstenı ve svetovemmerıtku lze zıskat postupnym nasobenım transformacnıch matic od korenestromu po vybrany uzel. Transformacnı matice ve svetovem merıtku jeautomaticky predpocıtavana u kazdeho uzlu, protoze se predpoklada jejıcaste vyuzitı z ruznych modulu. Moduly usetrı cas za cenu o malo vyssıpamet’ove narocnosti. V prıpade, ze by si moduly musely pocıtat vyslednetransformacnı matice samy, je pravdepodobne, ze nektere z nich by si vysledkyuchovavaly ve vyrovnavacı pameti a mohlo by tak dojıt k duplicitnım datumv nekolika modulech a v dusledku toho jeste vyssı pamet’ove narocnosti.

2.3.2 Komunikace se scenou

Graf sceny je plne integrovan do systemu udalostı. Kazda operace nadgrafem vyvolava udalost odeslanou centralnımu spravci udalostı, takze li-


bovolny modul nebo jiny zaregistrovany prıjemce udalostı muze mıt kom-pletnı prehled o denı ve vybrane scene. Ruzne operace vyvolavajı ruzne typyudalostı a modul tak muze reagovat pouze na operace, ktere ho zajımajı.

Jadro umoznuje i opacny smer komunikace, tedy zadavanı prıkazu scenepomocı udalostı. Udalosti pro operace nad scenou nejsou zpracovavany prımoscenou, ale centralnım spravcem udalostı, ktery udalost interpretuje a provedeprıslusnou operaci skrze rozhranı sceny. Prakticky vsechny operace prove-dene pomocı udalostı jsou synchronizovatelne, protoze v prıpade modifikacesceny je vzdy vyvolana reakce v podobe udalosti s udaji o prıslusne modi-fikaci.

2.3.3 Typy uzlu

Vzhledem k potrebe ruzne funkcnosti uzlu v grafu a moznosti spravnereprezentace scen z co nejvetsıho poctu grafickych formatu podporuje scenanekolik typu uzlu. Jak uz bylo zmıneno, vsechny typy vychazı ze zakladnıhotransformacnıho uzlu s transformacnımi maticemi a libovolnym poctem po-tomku. Neexistujı zadna omezenı v hierarchii v zavislosti na typu, je moznalibovolna kombinace typu na pozici rodice nebo potomka. Prehled uzlu:

• Zakladnı uzelPredstavuje logicky celek ve scene, muze definovat relativnı umıstenıvzhledem k rodici. Je vychozım typem, ze ktereho vychazı vsechnyostatnı.

• Korenovy uzelPouze jine oznacenı zakladnıho uzlu pro jediny uzel ve scene - korenovy.

• Uzel s geometriıTento typ uzlu pridava informace o geometrii a materialu.

• Uzel se svetlemUzel predstavuje zdroj svetla. Dıky reprezentaci svetla formou uzlu stransformacı je mozne se svetlem manipulovat stejne jako s ostatnımiuzly, vcetne naprıklad pripojenı svetla pod jiny uzel do logickeho celku.Dalsı vyhodou takove reprezentace muze byt pouzitı pouze lokalnıplatnosti svetla na uzly v podstromu (pouzitı teto vlastnosti zavisı nazobrazovacım modulu).

• KameraSpecialnı typ uzlu reprezentujıcı kameru. Krome vlastnıho umıstenıkamery obsahuje automaticky aktualizovanou projekcnı matici a in-formace o pohledovem jehlanu vcetne obalky v podobe koule. Prokameru platı stejne vyhody umıstenı v transformacnı hierarchii, kterebyly zmıneny u uzlu se svetlem. Naprıklad pouzitı kamer pro stere-oskopicke zobrazenı nebo jiny typ zobrazenı s vıce pevne svazanymi

2.3. GRAF SCENY 19

kamerami se tak velmi zjednodusuje zarazenım kamer do hierarchie srelativnı odchylkou umıstenı a/nebo natocenı vuci hlavnı kamere.

2.3.4 Geometrie

Geometrie je hlavnım ulozistem dat popisujıcıch geometrii jednotlivychobjektu ve scene. Hlavnı reprezentacı geometrie je seznam geometrickychprimitiv, ze kterych se sklada vysledny objekt, a jejich vlastnostı. Vzhledemk tomu, ze jadro je na vnitrnı reprezentaci prakticky nezavisle, je moznev budoucnu pouzıt temer jakoukoliv reprezentaci pro popis 3D objektu vescene - napr. NURBS nebo voxelova data pro objemovou reprezentaci (vıceviz [?]). Naopak moduly jsou na vnitrnı reprezentaci geometrie vıce ci menezavisle, protoze pracujı casto prımo s daty na nejnizsı urovni. Kompati-bility modulu s novymi geometrickymi reprezentacemi lze za cenu vyraznenizsı efektivity docılit prevodem na vychozı reprezentaci v podobe seznamugeometrickych primitiv (nejcasteji trojuhelnıku), prevod musı poskytovatvsechny typy geometrie (vıce informacı k podmınkam pro dalsı typy geome-trie je v sekci 3.4.2).

Kazda geometrie ma krome grafickych dat jeste obalku v podobe AABBv lokalnım merıtku, ktera ulehcuje zapojenı do hierarchie obalek. Vıce oobalkach a jejich hierarchii je v sekci 2.4.

2.3.5 Material

Dalsı podstatnou informacı pro popis objektu ve scene jsou vlastnostipouzitych materialu - barva, textura, odrazove vlastnosti, pruhlednost apod.Opet platı, ze pro dosazenı maximalnı flexibility je treba, aby pouzita reprezen-tace poskytovala co nejvetsı prostor pro nejruznejsı atributy pri zachovanıprijatelne pamet’ove narocnosti. Konkretnı definice materialu ve scene jepopsana v sekci 3.4.2.

Shader

Krome standardnıch atributu lze definovat i tzv. shadery, ktere velmirozsirujı moznosti nastavenı materialu a dokonce i geometrie, na kterou budematerial aplikovan. Shader umoznuje na podporovanem hardware zasadneovlivnit klasicky prubeh vykreslenı na nejnizsı urovni v graficke karte, jdeo relativne maly program, ktery se aplikuje vzdy na prıslusnem mıste pripruchodu grafickou pipeline. Vertex shader pracuje s vrcholy a umı do jistemıry ovlivnit geometrii, ale casteji slouzı jako modifikator vstupu pro pixelshader, ktery je aplikovan pri rasterizaci pro kazdy pixel a urcuje jehobarevnou hodnotu. Geometry shader rozsiruje moznosti upravy geometrie,ale nenı podporovan.

Pro vlastnı program shaderu se s vyhodou dajı pouzıt vyssı programovacıjazyky podobne klasickym imperativnım jazykum pro psanı aplikacı. Vzhle-


dem k tomu, ze jadro zadnym zpusobem nepracuje prımo s obsahem shaderu,je z jeho pohledu velka volnost pro vyber pouziteho jazyka - nejcastejsımijsou GLSL, HLSL nebo CG. Jinak je tomu z pohledu zobrazovacıho modulu,ktery musı dany jazyk podporovat pro spravne zobrazenı. Vıce o shaderecha jejich programovanı viz napr. [?].

2.3.6 Sdılenı dat

Sdılenı obrazovych dat na urovni spravce scen uz bylo zmıneno v sekci2.1.5. V ramci jedne sceny je vyhodne sdılet geometrie a materialy hnedz nekolika duvodu, tou hlavnı a zrejmou je nizsı pamet’ova narocnost. Ma-terialy byvajı casto definovany zvlast’ a nasledne odkazovany v mnoha grafickychformatech (FHS, VRML, Inventor a dalsı). Navıc je vysoka pravdepodobnost,ze bude material pouzit ve scene vıce nez jednou. Sdılenı geometrie vıce uzlyma navıc vyhodu pro pokrocilejsı techniky zobrazenı, kdy stacı danou ge-ometrii ulozit do graficke pameti pouze jednou a snızit tak potrebu prenasetvelka data mezi grafickym hardware a operacnı pametı. Nabızı se taketechnika zvana geometry instancing, ktera krome uvedeneho efektivnejsıhovyuzitı graficke pameti umı plne vyuzıt graficky hardware podporujıcı ShaderModel 3.0 a vyrazne tak urychlı vykreslenı opakovanych geometriı (vıce viz[?]).

Obrazek 2.7 znazornuje sdılenı materialu, geometrie a textur ve scene.Za povsimnutı stojı podstromy prvnıho a druheho patra se shodnymi castmi(uzly Zdi a Okna), ktere by se daly sloucit a sdılet podobne jako ostatnı data.Tato vlastnost nenı zatım podporovana, uzly sceny tvorı strom.

2.3.7 Alternativy

Existuje nekolik otevrenych knihoven poskytujıcıch velmi flexibilnı a ro-bustnı grafy sceny. Vetsina z nich pouzıva velmi podobny system s vyse pop-sanym, tj. reprezentace sceny v podobe grafu s ruznymi typy uzlu a sdılenymidaty. Rozdıly mezi nimi vychazı z odlisneho smerovanı k cılovemu pouzitı,zatımco z nekterych se stava spıse hernı engine, jine stavı na maximalnıflexibilite a rozsiritelnosti.

V soucasne dobe nejznamejsı a nejpouzıvanejsı projekty jsou OpenSG(viz [?]) a OpenSceneGraph (viz [?]). Oba jsou modernı grafy sceny, kterevznikly ve druhe polovine devadesatych let minuleho stoletı po zaniku pro-jektu Fahrenheit spolecnostı SGI a Microsoft. Zatımco OpenSG se spıse drzıpuvodnıho Fahrenheit projektu, OpenSceneGraph je casto srovnavan s pro-jektem Performer spolecnosti SGI, ze ktereho puvodne vychazı.

Duvodem vlastnı implementace grafu sceny je predevsım minimalizaceexternıch zavislostı a vyhnutı se znacne expanzi kodu. Vlastnı implementaceposkytuje plnou kontrolu nad projektem, ktery jde spıse cestou postupnehorozsirovanı podle potreby a v neposlednı rade umoznuje experimentovanı s

2.4. HIERARCHIE OBALEK 21

novymi vlastnostmi, jejichz aplikovanı by bylo na externı projekt tak velkehorozsahu velmi problematicke.

2.4 Hierarchie obalek

Hierarchie obalek je obsazena prımo v jadre z duvodu castych prıstupupodobne jako u grafu sceny, ale za urcitych podmınek je mozne jeho nahrazenıv modulu. Hierarchie obalek (zkracene BVH z anglickeho Bounding VolumeHierarchy) slouzı predevsım ke zefektivnenı nekterych operacı nad scenou,jakymi jsou naprıklad orezanı pohledoveho jehlanu, detekce kolizı nebo testypri vrhanı paprsku.

Hierarchie obalek je strom reprezentujıcı prostorove rozdelenı sceny. Konkretnepouzity typ BVH je binarnı strom postaven metodou delenı sceny shora dolupodle prostoroveho medianu (BVH-Median). Blizsı popis zpusobu vytvorenıBVH je v sekci 3.5.

Zatımco vnitrnı uzly grafu jsou pouze logickym celkem ve scene, list grafuvzdy predstavuje prave jeden uzel grafu sceny s geometrickymi daty. Kazdyuzel reprezentuje cast sceny vymezenou urcitym telesem - obalkou, pouzitymtypem obalky je kvadr zarovnany s osami, tzv. AABB (Axis Aligned Bound-ing Box) znazorneny na obr. 2.9. Platı, ze obalka potomka je vzdy plneobsazena v obalce rodice, tudız korenovy uzel predstavuje AABB obepsanykolem cele sceny. Ukazka BVH spolu se scenou je na obr. 2.10.

Z mnoha metod prostoroveho delenı sceny a reprezentacı hierarchie obalekbyl zvolen BVH-Median pro jednoduchy a rychly algoritmus konstrukce avelmi dobre vysledky operacı nad nım (viz [?]). Zda se byt take vhodnyjakozto univerzalnı resenı pro vsechny typy scen, coz je dulezite u aplikace,kde nenı dopredu jiste, jake typy scen budou nejcasteji pouzıvany. Alterna-tivou a casto pouzıvanou metodou pro stavbu BVH je algoritmus SurfaceArea Heuristics (BVH-SAH) s heuristikou pro volbu delıcı roviny v jed-notlivych krocıch stavby. Zatımco BVH-Median jednoduse delı prostor napoloviny v nejdelsım rozmeru, BVH-SAH bere v potaz vlastnosti objektu vprostoru.

2.4.1 Vztah BVH a sceny

Ke kazde scene je prirazena prave jedna hierarchie obalek. Z kazdeholistu BVH vede prıma cesta k uzlu sceny, BVH je tak prımo zavisla nascene (viz obr. 2.11), opacny vztah uz tak pevny nenı z duvodu planovanemoznosti prirazenı vıce BVH k jedne scene. Pro konstrukci a aktualizaciBVH je nutny prımy prıstup do sceny k obalkam geometriı. Pokud je ge-ometrie ve scene jakymkoliv zpusobem modifikovana, je potreba prepocıtatobalky urcite podmnoziny BVH. Oznamenı o modifikovanych uzlech s ge-ometriı je predano ze strany sceny, coz je take jedine spojenı smerem odsceny k BVH a do budoucna se nabızı vyuzitı systemu udalostı. Hierarchie


obalek zavisı vyhradne na prostorove hierarchii geometrie ve scene, nikolivna transformacnı hierarchii sceny.

2.5 Moduly

Hlavnım smyslem modularnı aplikace je moznost rozsirovanı o nove funkce.Aby modularnı aplikace dobre plnila svou funcki, je treba poskytnout vhodnysystem spravy modulu, bezpecnou metodu prıstupu modulu k jadru a comozna nejvetsı nezavislost na jadru. Moduly jsou aktivovany a spravovanyprıslusnym spravcem modulu (viz 2.1.1). V jeden moment muzou byt ak-tivnı vsechny dostupne moduly a navıc libovolne mnozstvı instancı od jed-notlivych modulu. Kazdemu modulu, resp. kazde instanci modulu je prirazenovlastnı vlakno, ve kterem probıha zpravidla veskera cinnost modulu. In-stance a paralelnı beh modulu ve vlastnım vlakne jsou popsany v dalsı kapi-tole v sekci 3.7, ukazka vztahu mezi instancemi a spravcem je na obr. 2.12.

2.5.1 Komunikace

System komunikace mezi objekty pomocı udalostı (popsany v sekci 2.2)nabızı do znacne mıry bezpecnost i nezavislost komunikujıcıch objektu a bylproto zvolen pro realizaci hlavnıho spojenı mezi moduly a jadrem.

Vsechny moduly bez rozdılu mohou pouzıvat system udalostı, a to jakoprıjemci i odesılatele. Je vzdy odpovednostı prıjemce udalosti (jadra nebomodulu), aby vhodnym zpusobem reagoval a nebyla pro nej fatalnı prıpadnachyba druhe strany pri rozesılanı neplatnych nebo jinak nevhodnych udalostı.Z tohoto pohledu je komunikace pomocı udalostı povazovana za zcela bezpecnouna rozdıl od prımeho prıstupu k jadru, ktery je povolen pouze urcitym typummodulu.

Komunikace mezi moduly navzajem je vzdy neprıma skrze jadro. Vyuzıtlze opet systemu udalostı, kdy prıjemce musı byt prihlasen k odberu danehotypu udalosti. Druhou moznostı je komunikace pomocı registrovanych parametru,i kdyz nastavenı registrovanych parametru se rovnez deje s pomocı udalostı.Odesılatel musı navıc znat identifikacnı udaje parametru.

2.5.2 Typy modulu

Vzhledem k velke variabilite pozadavku na funkcnost modulu je z hlediskabezpecnosti a prehlednosti pri tvorbe novych modulu vhodne definovat nekolikskupin modulu. Typy se mohou lisit v urovni povoleneho prıstupu k jadru apredevsım v mıre a zpusobu integrace do chodu hlavnı aplikace. Nasledujeseznam typu modulu:

• ObecnyModul zcela nezavisly na jadre zijıcı vlastnım zivotem. Jedinym spo-jenım s jadrem (navıc neprımym) je pomocı udalostı. Prıkladem muze

2.6. KOMERCNI RESENI 23

byt prekladac udalostı ze vstupnıho zarızenı na udalosti srozumitelnepro jadro nebo jiny modul.

• Modul scenyNavıc oproti obecnemu modulu ma prımy prıstup ke spravci scen,zadna jina cast jadra nenı prıstupna. Typ vhodny pro nejruznejsıoperace nad scenou bez potreby hlubsı integrace do hlavnı aplikace.Prıkladem muze byt detekce kolizı nebo editace sceny.

• Modul pro import a exportTento typ vychazı z modulu sceny a na strane jadra vyzaduje o necotesnejsı spolupraci oproti predchozım, co se tyce vyberu spravnehomodulu pro pozadovany format dat. Prıkladem muze byt modul proimport a export sceny ve formatu FHS.

• Zobrazovacı modulOpet rozsiruje vlastnosti modulu sceny. Modul vyzaduje relativne vysokoumıru propojenosti ze strany jadra, naopak ze strany modulu k zadnemurozsırenı prıstupu k jadru nedochazı. Prıkladem muze byt kterykolivmodul s grafickym vystupem. Duvodem pro tesnejsı spolupraci s jadremje prımy prıstup modulu do grafickeho uzivatelskeho rozhranı (kreslenıdo okna), coz vyzaduje dodrzenı mnohych pravidel a pevne rızenı zestrany jadra.

• ManipulatorLisı se od modulu sceny pouze zpracovanım specialnıch udalostı zevstupnıch zarızenı. Prıkladem muze byt modul pro interakci se scenou.

• Manipulator kameryOproti manipulatoru je vıce specializovan na ovladanı kamery, ale khlubsı integraci do jadra nedochazı. Prıkladem muze byt modul proprochazenı scenou.

• Modul jadraTento specialnı typ modulu vychazı z obecneho modulu, ale pridavazasadnı zmenu v komunikaci. Modul jadra ma zprıstupneno cele jadroa navıc je integrovan do behu hlavnı aplikace. Prıkladem muze bytmodul poskytujıcı sofistikovanejsı rozhranı pro ovladanı aplikace, napr.s moznostı naprogramovat chovanı aplikace.

Popis hierarchie modulu a konkretnı pozadavky pro implementaci vsechtypu modulu je v dalsı kapitole v sekci 3.7.11.

2.6 Komercnı resenı

Projekt VRUT nelze jednoznacne zaradit do urcite kategorie softwarea srovnanı s jinymi produkty nenı snadne. Presto existujı komercnı ap-


likace s podobnym zamerenım a vlastnosti nekterych z nich byly inspiracıpri zadavanı pozadavku na projekt VRUT.

• VRCOM Virtual Design 2 (VD2)Software vyvinuty nemeckou firmou VRCOM ([?]) pracuje s mnohaformaty, zameruje se na moznosti editace a zobrazenı 3D scen s vyuzitımhardware pro virtualnı realitu (viz obr. 2.13), pouzıva se naprıklad vautomobilovem prumyslu (BMW, Volkswagen Group). VD2 pracujepouze na operacnım systemu Linux. Vyvoj a prodej v puvodnı verzibyl ukoncen, firma se stala soucastı spolecnosti IC:IDO.

• IC:IDO VDPNemecka spolecnost IC:IDO ([?]) vyvıjı software VDP a snazı se jımnahradit ukonceny projekt VD2. VDP pracuje pouze na operacnımsystemu Microsoft Windows.

• RTT DeltaGenDeltaGen pochazı taktez z Nemecka od firmy RTT ([?]). Zameruje sena vizualizaci s podporou hardware pro virtualnı realitu, predpokladanympouzitım je prumyslovy design (viz obr. 2.14). DeltaGen pracuje pouzena operacnım systemu Microsoft Windows. Nepodporuje graficky formatFHS, ktery je velmi vyuzıvan ve Skoda Auto.

• Autodesk Opticore, Realizer, ShowCaseVizualizacnı produkty spolecnosti Autodesk ([?]) pro operacnı systemMicrosoft Windows.

• Dasault VirtoolsDalsı vizualizacnı a editacnı software, pochazı od firmy Dasault ([?]).

• VRED, LivingSolids, Eon ...

Zasadnı nevyhodou vetsiny komercnıch produktu nejen pro vizualizacia editaci grafickych dat je mala nebo vubec zadna moznost ovlivnit neborozsırit vlastnosti, v nekterych prıpadech jsou problemem dokonce i opravychyb. Vyvoj se muze ubırat jinym smerem, nez je treba, a prechod na jineresenı je zpravidla velmi nakladne s rizikem stejneho vysledku v budoucnu.Dalsımi problemovymi vlastnostmi jsou:

• PlatformaKomercnı produkty jsou casto zavisle pouze na jednom operacnımsystemu, v prıpade 32bitove platformy navıc vyvstavajı problemy slimitem vyuzitelne operacnı pameti.

• Paralelnı behMale nebo vubec zadne vyuzitı vıcevlaknoveho zpracovanı snizuje efek-tivitu software. Podobna situace je s distribuovanym vypoctem a vyuzitım


paralelnıho behu na vıce pocıtacıch, omezenım byva v prıpade podporyzavislost na jedne platforme nebo dokonce konkretnım hardware.

• Podpora hardwarePri vizualizaci 3D scen je casto vyuzıvan specialnı hardware pro virtualnırealitu, pro obrazovy nebo jiny vystup (viz obr. 2.15) a vstup proovladanı. Komercnı aplikace byva svazana jen s urcitou skupinou hard-ware, naprıklad od jednoho vyrobce na zaklade smluvnıch podmıneka doplnenı podpory pro novy hardware muze byt dlouhodoby proces.

• Propojenı s dalsımi aplikacemiPropojenı se specialnımi aplikacemi tretıch stran (napr. simulace ruznehohardware) je bez podpory vyvojaru problematicke nebo nemozne.

• Sdılenı datKazda aplikace podporuje urcitou mnozinu grafickych formatu, nekteredefinujı vlastnı s novymi nebo upravenymi vlastnostmi. Pro sdılenı datmezi dvema ruznymi aplikacemi je treba najıt prunik techto mnozin.Pokud je vubec nejaky format podporovan obema stranami, nenı zarucena100% kompatibilita nebo jde o format, ktery obsahne jen cast puvodnıinformace.

• Osud spjaty s vyrobcemZivotnı cyklus komercnı aplikace je uzce spjat s vyrobcem jakoztoekonomickym subjektem, ktery podleha nekompromisnım podmınkamtrhu. Bankrot, prodej firmy nebo programu znacı vetsinou velky zasahdo dalsıho vyvoje a nemusı byt pozitivnı.

Vyvoj vlastnıho resenı muze byt zdlouhavy, projekt muze trpet porodnımibolestmi, koncepty dılcıch castı mohou koncit ve slepe ulicce, nicmene vprıpade i jen castecneho uspechu je zde stale moznost vlastnımi prostredkypokracovat v budovanı a jıt k cıli dıky prakticky absolutnı kontrole nadvyvojem.


Obrazek 2.1: Navrh architektury aplikace


Obrazek 2.2: Spravce scen - prıklad sdılenı dat

Obrazek 2.3: Komunikace mezi objekty udalostmi (prıma komunikace)


Obrazek 2.4: Distribuce udalosti

Obrazek 2.5: Prıjem a zpracovanı udalosti


Obrazek 2.6: Graf sceny s hierarchiı transformacı

Obrazek 2.7: Sdılenı dat v grafu sceny


Obrazek 2.8: OpenSG a OpenSceneGraph loga

Obrazek 2.9: Osove zarovnane obalky - AABB

Obrazek 2.10: Ukazka hierarchie obalek


Obrazek 2.11: Vztah BVH a sceny


Obrazek 2.12: Prıklad vztahu pro moduly sceny

Obrazek 2.13: VRCOM Virtual Design 2


Obrazek 2.14: RTT DeltaGen

Obrazek 2.15: CAVE - hardware pro virtualnı realitu


Kapitola 3

Realizace a implementace

Vlastnı praci na implementaci predchazela teoreticka prıprava, kteramela dopredu odhalit nevhodne ci ve vysledku nerealizovatelne postupy.Presto vzhledem k rozsahu prace, nepochopenı nekterych pozadavku az dodusledku a nedostatku zkusenostı autora v nekterych oblastech byly mnohekoncepty prepracovany, odlozeny nebo uplne zruseny. Tato kapitola prezen-tuje dosavadnı stav implementace projektu VRUT, presneji hlavnı aplikace anekterych zakladnıch modulu. Prvnı cast se zabyva prevazne hlavnı aplikacı,druha pak moduly a jejich spravou.

Programovacım jazykem pro cely projekt je C++ s maximalnım vyuzitımprincipu objektoveho programovanı. Jedinou zasadnı externı zavislostı kodujsou otevrene knihovny wxWidgets ([?]) a OpenGL ([?]). Zatımco knihovnaOpenGL je vyuzıvana vyhradne pro zobrazovanı (a to prevazne v modulech),wxWidgets prostupuje temer vsechny casti VRUT. wxWidgets tvorı urcitouvrstvu mezi operacnım systemem a aplikacı, dıky cemuz poskytuje aplikacnırozhranı nezavisle na platforme pro mnoho systemovych operacı. Poskytujıtrıdy pro GUI (okna a ovladacı prvky), praci se soubory, vlakna, sıt’ovoukomunikaci, databaze, lokalizaci a mnoho dalsıch.

Nasleduje strucne objasnenı nekterych pojmu, vetsina z nich je detailnevysvetlena dale v textu:

• Hlavnı aplikaceHlavnı aplikacı je zde myslena spustitelna aplikace VRUT bez jakychkolivmodulu.

• ModulDynamicky linkovana knihovna (plugin) pridavajıcı nebo rozsirujıcıvlastnosti VRUTu, vıce viz sekce 3.7.

• Instance moduluPro vlastnı pouzitı modulu je nutne vytvorit jeho instanci, muze exis-tovat vıce instancı tehoz modulu. Vıce viz sekce 3.7.

35

36 KAPITOLA 3. REALIZACE A IMPLEMENTACE

• JadroZ implementacnıho hlediska predstavuje hlavnı a vetsinovou cast hlavnıaplikace. Toto oznacenı je mozne povazovat za synonymum hlavnı ap-likace, pokud nebude uvedeno jinak. Vıce viz sekce 3.1.

• UdalostZakladnı komunikacnı jednotka VRUTu, ktera oznamuje zmenu stavunebo naopak zmenu stavu zada. Udalost je ve skutecnosti zprava vys-lana do systemu, vıce viz sekce 3.2 a 3.7.4.

• ScenaPoskytuje metody pro operace nad scenou a predstavuje kontejner proveskera data sceny (hierarchie, geometrie, materialy), vıce viz sekce3.4.

• BVHHierarchie obalek pro scenu, poskytuje metody pro dotazy na prıslusnouscenu, vıce viz sekce 3.5.

• Registrovane parametryParametry, ktere jsou spravovany v jadre a jejichz hodnoty lze zjistitci upravovat z uzivatelskeho rozhranı. Vıce viz sekce 3.7.9.

3.1 Jadro

Jadro tvorı zcela zasadnı cast VRUTu (viz obr. 2.1). Je implementovanojako singleton, existuje tedy pouze jedina instance prıstupna temer od-kudkoliv pomocı makra KERNEL, nicmene v modulu je zakazano jehopouzitı. Staticka promenna nemusı byt spravne definovana v prostredı mod-ulu (zalezı na platforme) a prımy prıstup k jadru z modulu odporuje kon-cepci VRUTu.

Hlavnı funkce jadra v bodech:

• Interpretace prıkazu ze skriptu nebo konzole, vıce viz sekce 3.6.

• Sprava vsech scen, jadro je vlastnıkem scen (potazmo jejich BVH) azasah do sceny se deje skrze nej. V tomto ohledu existuje vyjimka provyse zmıneny zakaz prımeho prıstupu k jadru, prımy prıstup ke sceneje za urcitych okolnostı z modulu povolen (viz sekce 3.4).

• Sprava registrovanych parametru, vıce o praci s registrovanymi parame-try viz sekce 3.7.9.

• Sprava vsech modulu skrze nekolik dılcıch spravcu pro konkretnı typ(viz sekce 3.7).

– zjistenı dostupnosti modulu

3.1. JADRO 37

– nahranı/uvolnenı modulu a kontrola verze

– vytvorenı/uvolnenı instance konkretnıho modulu

– aplikovanı predem nastavenych registrovanych parametru

– kontrola chodu vlakna prirazeneho instanci modulu

– priority modulu pri aktivaci

Zastavme se u spravy modulu. VRUT nema po spustenı zadne povedomıo dostupnych modulech, dostupne moduly se zjist’ujı az pri pozadavku naakci, ke ktere je nejaky modul treba. Hledanı dostupnych modulu v predepsanychadresarıch (viz tab. 3.3) se provadı pri kazdem pozadavku, takze je moznepridavat moduly za chodu. Pokud se z nejakeho duvodu nepodarı vytvoritinstanci modulu, pri prıstım hledanı dostupneho modulu je tento ignorovan(zarazen do zakazanych modulu). Duvodem neuspechu vytvorenı instancemuze byt jina verze modulu nez ma hlavnı aplikace, tato kontrola zamezujepouzitı modulu postaveneho na starsı verzi hlavnı aplikace. Po vytvorenıinstance modulu jsou aplikovany preddefinovane parametry. Pokud zadneparametry preddefinovany nebyly, pouzijı se hodnoty zakompilovane v kodu.Systemu registrovanych parametru je popsan v sekci 3.7.9.

Spravci modulu mohou mıt k dispozici vıce modulu pro stejnou funkci,v takovem prıpade se zpravidla vybere prvnı pouzitelny. Vyber lze ovlivnitpomocı tzv. preferovanych nebo zakazanych modulu. Zakazany modul budevzdy ignorovan pri hledanı dostupnych modulu. Pokud se dostane modulna seznam zakazanych, kdyz uz existujı jeho instance, nejsou tyto nijakovlivneny, ale vytvorenı dalsıch instancı uz nenı mozne. U seznamu prefer-ovanych modulu na rozdıl od zakazanych zalezı na poradı, nejvyssı priorituma posledne pridany modul. Dıky tomu lze jasne definovat, ktery modul bymel byt pouzit v danou chvıli. Modul je odstranen ze zakazaneho seznamujeho preferovanım a naopak. Preferovat nebo zakazat modul muzeme dvemazpusoby, prıkazem konzole nebo skriptu usemodule resp. forbidmodule apomocı udalostı EVT MODULE PREFER resp. EVT MODULE FORBID.Argumentem je vzdy jmeno modulu (nezalezı na velikosti pısmen). Prıkladskriptu:

usemodule IoFHS#pro nasledny import bude pouzit modul se jmenem IoFHS, pokud je k dispoziciimportscene test.fhs

usemodule IoFHS2forbidmodule IoFHS#pro nasledny import bude pouzit modul se jmenem IoFHS2,#pokud je k dispozici, ale v zadnem prıpade se nepouzije IoFHSimportscene test.fhs


Knihovna modulu je standardne uvolnena, pokud jiz nezbyva zadnainstance. Smazanı kazde instance modulu predchazı ukoncenı behu jejıhovlakna. Pokud se tak nestane do urciteho casoveho limitu, je instance uvolnenabez ohledu na stav vlakna. Kazdy modul by mel byt napsan tak, aby pricasove narocnejsıch operacıch provadenych ve vlastnım vlakne pravidelnekontroloval, zda nenı pozadovano jeho ukoncenı, v sekci 3.7.2 je popsanomozne resenı.

3.2 Komunikacnı system

Komunikacnı system VRUT pohlızı na komunikujıcı casti aplikace jakona zapouzdrene objekty, neprıstupne zvenku. Jediny kontakt s okolnım svetemtvorı prijımac a vysılac datovych balıcku - udalostı. Implementace vyuzıvanekterych vlastnostı komunikacnıho systemu wxWidgets a je s nım do jistemıry kompatibilnı. Komunikacnımi objekty v pojetı wxWidgets jsou prevazneGUI okna a ovladacı prvky, v pojetı VRUT jde o jadro a moduly.

VRUT vyuzıva jako komunikacnı jednotku konkretnı typ udalosti defino-vane ve wxWidgets, coz umoznuje castecne propojenı obou systemu. Systemudalostı ve wxWidgets je relativne sofistikovany, vıce viz dokumentace [?].Komunikacnı objekty wxWidgets umı prijmout a zpracovat jak udalostiwxWidgets, tak udalosti VRUT, moduly prijımajı az na vyjimky pouzeudalosti VRUT. Spojovacım clankem obou systemu je centralnı spravceudalostı v jadru, ktery pusobı jako prekladac a distributor. Prıkladem budizudalost ze vstupnıho zarızenı, ktera je odchycena v okne GUI, prochazıwxWidgets systemem a je preposlana centralnımu spravci udalostı v jadru,coz se deje vzdy pri odchycenı tohoto typu udalostı oknem. Centralnı spravceudalostı udalost prijme, prıpadne prelozı na udalost kompatibilnı s VRUT apreda ke zpracovanı internımu systemu udalostı VRUT, ktery ji prıslusnymzpusobem distribuuje dal prihlasenym odberatelum. Na obrazku 3.1 je videt,ze udalost muze byt distribuovana nejen modulum, ale take prihlasenym ob-jektum wxWidgets, a to dıky zmınene kompatibilite.

Nektere udalosti pochazejıcı z modulu nebo jadra jsou v ramci zpra-covanı prevedeny na wxWidgets udalost a odeslany prımo konkretnımu ob-jektu a do systemu wxWidgets (viz obr. 3.2).

3.2.1 Prıjem a zpracovanı

V modulech i jadru jsou udalosti razeny do FIFO fronty realizovanetrıdou, jejız metody jsou bezpecne pro paralelnı prıstup. Udalosti s vyssıprioritou jsou razeny vzdy na zacatek fronty, coz naopak odpovıda LIFOrazenı. Udalosti v centralnım spravci jsou zpracovavany v hlavnım vlakneaplikace a v prıpade modulu vzdy v prıslusnem vlakne dane instance.

Fronta udalostı je v pravidelnych intervalech kontrolovana a pokud jenalezena udalost ke zpracovanı, je okamzite zpracovana a kontrola obratem

3.2. KOMUNIKACNI SYSTEM 39

Obrazek 3.1: Spojenı komunikacnıch systemu z wxWidgets do VRUT

zopakovana, v opacnem prıpade dochazı k predanı rızenı dal hlavnı smyccewxWidgets v prıpade jadra nebo uspanı v prıpade modulu. Vıce o hlavnısmycce modulu a casovych prodlevach je v sekci 3.7.2. Centralnı spravceudalostı v jadru ma vyhodu dıky napojenı na wxWidgets udalosti, jejichzprijetı ma za nasledek predanı rızenı spravci v nejblizsı mozne dobe, takzenedochazı k zadnym prodlevam. To bohuzel neplatı pro klasicke VRUTudalosti, proto je v pravidelnych intervalech umele vyvolana wxWidgetsudalost wxEVT IDLE, ktera ma za normalnıch okolnostı pouze informo-vat o dokoncenı zpracovanı vsech zprav ve fronte. Spravce totiz po prijetıjakekoliv wxWidgets udalosti krome jejıho zpracovanı vzdy navıc kontrolujei frontu VRUT udalostı.

Pro prıpad zahlcenı fronty je definovano maximum zprav, ktere lze zpra-covat pred predanım rızenı hlavnı smycce programu. Hlavnı smycka za-jistı prıpadne prekreslenı GUI, obslouzı systemove udalosti a pokud nebylafronta zprav v predchozı iteraci vyprazdnena, preda rızenı obratem zpet apokracuje se ve zpracovanı.

3.2.2 Udalosti

Udalosti mohou byt ciste informacnıho charakteru nebo predstavovatpozadavek pro provedenı urcite operace, prıpadne obojı. Z implementacnıhohlediska je udalost reprezentovana trıdou wxCommandEvent, ta umoznujeuchovat nekolik ruznych datovych typu najednou.


Obrazek 3.2: Spojenı komunikacnıch systemu z VRUT do wxWidgets

Posılanı dat

Udalost je datovou strukturou s nekolika preddefinovanymi typy, kteredokaze pojmout. Jsou ale prıpady, kdy je potreba poslat vlastnı datovoustrukturu. K tomu slouzı v udalosti polozka s obecnym odkazem na mıstov pameti, nicmene problemem muze byt platnost alokovane pameti mod-ulem v momente jeho uvolnenı (viz 3.7.8). Z tohoto duvodu jsou data od-kazovana v udalosti pri pruchodu centralnım spravcem udalostı v jadruklonovana (viz kopie udalostı napr. na obr. 3.2), takze kazdy odberatel dis-tribuovane udalosti ma jistotu vlastnı instance dat, se kterou muze libovolnenakladat, ale take prebıra odpovednost za jejı uvolnenı. Uvolnenı pametialokovane pro udalosti je v jadru a v modulech pri dodrzenı standardnıchpostupu prıjmu a zpracovanı zcela automaticke. Pro spravnou funkci au-tomatickeho klonovanı a uvolnenı je nutne, aby typ distribuovane udalostibyl znam jadru. Poslanım dat neznameho typu nebo zcela bez ucasti jadraprebırajı odpovednost za alokaci a uvolnenı pameti ucastnıci komunikace,ale i pri sebevetsı snaze o korektnost muze dojıt k fatalnı chybe, naprıkladpri predcasnem ukoncenı a uvolnenı instance modulu odesılatele. Tento faktma za dusledek neprıjemnou zavislost jadra na modulech, kterych se to tyka.

Typy udalostı

Trıda Event zastresuje vsechny vnitrnı udalosti VRUTu a poskytujepomocne metody pro vytvorenı a spravne prirazenı dat. Ruzne udalosti

3.3. ZOBRAZOVACI SYSTEM 41

pouzıvajı ruzny pocet a ruzne typy dat. Pomocna metoda pro vytvorenıudalosti ma vzdy nazev jako typ udalosti s predponou GET , napr. Event::GET EVT EXIT()vratı udalost typu EVT EXIT. Seznam vsech udalostı se nachazı v prıloze4.

Kazda udalost s sebou nese identifikaci odesılatele, identifikace je shodnapro vsechny odesılatele na strane jadra a v prıpade modulu jde o unikatnıidentifikator kazde instance (viz sekce 3.7.1).

3.3 Zobrazovacı system

Zobrazovacı system v podanı jadra VRUT je v podstate jen propojenızobrazovacıho modulu s nekterymi castmi jadra. Hlavnı slovo ma spravce zo-brazovacıch modulu, ktery krome modulu spravuje take zobrazovacı okna.Zobrazovacı okno je spojovacım clankem mezi vsemi zucastnenymi subjekty(viz obr. 3.3), tj. mezi okennım systemem wxWidgets, zobrazovacım mod-ulem a jadrem. Na strane jadra jde konkretne o jiz zmıneneho spravce zobra-zovacıch modulu a centralnıho spravce udalostı, kteremu okno zasıla kromestandardnıch udalostı VRUT take udalosti ze vstupnıch zarızenı odchycenewxWidgets podsystemem.

Obrazek 3.3: Zobrazovacı system

Na zaklade pozadavku na vykreslenı sceny vytvorı spravce zobrazovacıchmodulu novou instanci zobrazovacıho modulu a k te priradı nove vytvorenezobrazovacı okno, na kazdy zobrazovacı modul pripada prave jedno okno.


Jednım z duvodu uzkeho propojenı zobrazovacıho modulu s jadrem jevlastnı vykreslenı sceny. Kazde zobrazovacı okno ma prideleno vlastnı OpenGLkontext, do ktereho zobrazovacı modul pristupuje a pouzıva pro grafickyvystup. OpenGL kontext v podobe wxWidgets trıdy wxGLContext lze obecnesdılet, prıpadne je naopak mozne sdılet nektera OpenGL data (napr. displaylisty) nekolika OpenGL kontexty najednou, podpora by ale vyzadovala mno-hem komplikovanejsı rızenı ze strany jadra, a proto nenı zadne takove sdılenıpodporovano.

Prıstup do kontextu a vykreslenı do okna z vlakna modulu jsou velmiproblematicke operace a v soucasne dobe nejsou podporovana, mısto tohojadro uchovava informace o vsech svych oknech a vola metodu modulu provykreslenı podle potreby z hlavnıho vlakna. Pro minimalizaci zateze jsouokna prekreslovana pouze podle potreby a nikoliv v nekonecne smycce. Ak-tualizaci krome systemovych udalostı (napr. zmena velikosti okna) auto-maticky vyvola take jakakoliv zmena ve scene, prıpadne o ni lze explicitnezazadat vyslanım udalosti. Transformacı a dalsıch modifikacı sceny muzeprichazet velke mnozstvı po sobe a bylo by zbytecne po kazde transformaciprekreslovat scenu, proto centralnı spravce udalostı zajist’uje, ze kazde oknoje v iteraci zpracovanı udalostı (viz 3.2.1) prekresleno maximalne jednou.

Zavrenı zobrazovacıho okna uzivatelem ma za nasledek uvolnenı instanceprirazeneho zobrazovacıho modulu, data sceny zustavajı nedotcena.

3.4 Scena

Scena ve VRUT nenı pouze kontejnerem pro graficka data a informaceo hierarchii, ale navıc predstavuje zapouzdrenı vsech jejıch soucastı do kon-trolovaneho systemu. Kazda scena ma svuj identifikator, podle nehoz jemozne si scenu vyzadat u spravce scen, ktery je obzvlaste dulezity pro mod-uly pracujıcı se scenou, jelikoz jde pro ne o jedinou prımo zprıstupnenoucast jadra.

3.4.1 Transformace uzlu

Acyklicky graf reflektuje transformacnı hierarchii ve scene. Kazdy uzelsceny ma transformacnı matici, kterou prımo ovlivnuje sve potomky. Prominimalizaci duplicitnıch vypoctu ma uzel nejen svou lokalnı transformacnımatici, ale i vyslednou svetovou transformacnı matici zıskanou vynasobenımsve lokalnı transformacnı matice s platnou svetovou transformacnı maticıpredka. Po jakekoliv zmene transformace uzlu se svetova transformacnı mat-ice uzlu (a jako dusledek hierarchie i vsech jeho potomku) stane neplatna apred kazdym pokusem o jejı zıskanı je nutne ji aktualizovat:

scene->UpdateTransformation(node->GetID());///Az ted’ je transformacnı matice platna

3.4. SCENA 43

node->GetWorldTransMatrix();

Metoda UpdateTransformation prepocıta matici, pouze je-li potreba, takzenenı nutne pred jejım volanım testovat validitu uzlu. Aktualizace nenı au-tomaticka, aby nebyla zbytecne pocıtana po kazde zmene transformace,protoze obecne pozadavek zıskanı matice predchazı mnoho zmen transfor-macı. Pri zneplatnenı svetove transformacnı matice uzlu sceny je automat-icky zneplatnen i prıslusny uzel hierarchie obalek (a jako dusledek hierar-chie i vsechny rodicovske uzly az po koren). Aktualizace uzlu sceny nema zadusledek aktualizaci prirazeneho uzlu hierarchie obalek, tu je potreba udelatzvlast’ (tyka se jen uzlu sceny s geometriı). Naopak aktualizace uzlu hierar-chie obalek v prıpade potreby zahrnuje i aktualizaci uzlu sceny, protoze jetreba zjistit aktualnı polohu geometrie pro vypocet obalky (viz sekce 3.5).

3.4.2 Entity ve scene

Specialnım obsahem sceny jsou geometrie, materialy a svetla. Zatımcosvetla jsou prımo soucastı uzlu prıslusneho typu, geometrie a materialy jsouspravovany scenou (viz obr. 2.7). Scena je jejich vlastnıkem a prirazujejim identifikatory, ktere jsou unikatnı v ramci sceny. Krome identifikatorujsou pozadovana unikatnı take jmena geometriı a materialu, a to z duvodumoznosti tvorby sceny pomocı udalostı, vıce viz 3.4.4. Specialnım prıpademjsou textury, ktere jsou spravovany jeste o uroven vyse spravcem scen, cozumoznuje sdılenı textur i mezi scenami (viz obr. 2.2). Material i geome-trie dodrzujı podobny princip prıstupu jako uzly (viz sekce 3.4.3), tj. povlozenı do sceny jsou mozne modifikace pouze skrze rozhranı sceny a nikolivnaprıklad pres rodicovsky uzel.

Moznosti entit ve scene vychazejı predevsım z potreby co nejlepe reprezen-tovat graficky format FHS. Prestoze je format FHS velmi obecny, predpokladase rozsırenı nekterych vlastnostı entit podle potreby. Vzhledem k objek-tovemu pojetı a znacne nezavislosti implementace sceny na reprezentacigrafickych dat by slo o nebolestivy ukon z pohledu jadra, vetsı problemymuze cinit modulum pristupujıcım k datum na nejnizsı urovni.

Materialy

Material je soucastı sceny a muze byt odkazovan pouze uzlem s geometriı.Datova struktura pro definici materialu obsahuje informace o barvach priinterakci se svetlem, parametry pruhlednosti, prıpadny identifikator texturynebo prımo shader program (viz sekce 2.3.5). V prıpade pouzitı textury jsoudefinovany nejruznejsı parametry filtrovanı a mapovanı. Nektere parametrytrıdy Material:

• id - identifikator materialu (jednoznacny v ramci sceny)


• name - nazev materialu (jednoznacny v ramci sceny)

• ambient - RGBA barva pri reakci se stalym okolnım osvetlenım

• diffuse - RGBA barva pri reakci s prımym difuznım svetlem

• specular - RGBA barva odrazeneho svetla

• emission - RGBA barva vlastnıho vyzarovaneho svetla

• shininess - intenzita lesku

• depthFunc - relace pro testovanı hloubky objektu

• flags - dalsı prıznaky materialu (pruhlednost, bez osvetlenı, obous-tranny material, atd.)

• texFlags - dalsı prıznaky textury (zpusoby mapovanı a filtrovanı)

• texBlendSrc/Dst - definuje operace pri pocıtanı pruhlednosti

• imageName - cesta k souboru s texturou

• shader - ukazatel na shader

Vlastnıkem shaderu je prımo material, sdılet lze tedy jen jako cely ma-terial. Shader obsahuje kod programu zvlast’ pro vertex a pixel shader v tex-tove podobe v nekterem z podporovanych jazyku pro programovanı shaderu,momentalne jsou jimi GLSL a OpenRT. Argumenty pro shader programyjsou realizovany formou seznamu, jehoz polozky predstavujı ruzne typy argu-mentu, od N -slozkoveho vektoru az po texturu. Shader pres argumenty od-kazuje na texturu nebo textury stejnym zpusobem jako material, neporusujetedy princip sdılenı.

Svetla

Svetlo je prımo soucastı uzlu se svetlem, nenı tedy mozne jeho sdılenı.Svetlo je realizovano jednoduchou datovou strukturou definujıcı typ svetlaa jeho parametry. Podporovanymi typy svetel jsou vsesmerova, smerova akuzelova, kazdy typ ma specificke parametry jako pozice, smer, dosah apod.Spolecnym parametrem je RGB informace o barve.

Geometrie

Geometrie je soucastı sceny a muze byt odkazovana pouze uzlem s ge-ometriı, nenı nijak zavisla na materialu, takze geometrie muze byt sdılenavıce uzly pri pouzitı ruznych materialu v kazdem z nich. Zatımco datovastruktura pro material tvorı pouze kontejner pro data, geometrie vyuzıva

3.4. SCENA 45

C++ dedicnosti pro moznost definice vıce typu geometriı (viz sekce 2.3.4).Vsechny typy geometriı majı svou obalku typu AABB v lokalnım merıtku ge-ometrie a umoznujı prevod geometrickych dat do univerzalnı formy v podobeseznamu trojuhelnıku. Virtualnı metody k definici v odvozenych trıdach odGeometry jsou nasledujıcı:

• virtual void BuildAABB()Metoda pro vytvorenı nebo prepocıtanı AABB obalky geometrie

• virtual bool Intersects(const Ray & ray, float * dist) constMetoda pro zjistenı, zda paprsek protına geometrii a v jake vzdalenosti

• virtual std::vector<Triangle> Triangulate() constMetoda pro prevod geometrie na univerzalnı reprezentaci v podobeseznamu trojuhelnıku

• virtual void Add*Nekolik pomocnych metod pro pridanı jednoduchych geometrickychutvaru - kvadr, koule, rovina apod.

Zatım jedinym implementovanym typem geometrie je trojuhelnıkovareprezentace sestavajıcı ze seznamu vrcholu a indiciı (indexu do pole vr-cholu), volitelne pak normal a souradnic pro textury. Reprezentaci indexo-vane trojuhelnıkove geometrie lze dale rozdelit podle zpusobu interpretaceprimitiv, podporovany jsou nasledujıcı:

• TRI LIST Seznam nezavislych trojuhelnıku. N/3 trojuhelnıku je defi-novano, kde N je pocet indexovanych vrcholu, viz Triangle List naobr. 3.4.

• TRI FAN Seznam trojuhelnıku se spolecnym vrcholem. N−2 trojuhelnıkuje definovano, kde N je pocet indexovanych vrcholu, viz Triangle Fanna obr. 3.4.

• TRI STRIP Seznam pospojovanych trojuhelnıku. N − 2 trojuhelnıkuje definovano, kde N je pocet indexovanych vrcholu, viz Triangle Stripna obr. 3.4. Tento zpusob interpretace zvladne popsat libovolnou struk-turu geometrie a pritom minimalizuje pamet’ove prenosy a je vhodnypro soucasny graficky hardware, proto byva nejcastejsı volbou.

• POLYGON Konvexnı polygon definovany N vrcholy.

• LINES Seznam nezavislych car. N/2 car je definovano, kde N je pocetindexovanych vrcholu.

• LINE STRIP Seznam pospojovanych car. N−1 car je definovano, kdeN je pocet indexovanych vrcholu.


• POINTS Seznam nezavislych bodu. N bodu je definovano, kde N jepocet indexovanych vrcholu.

• QUADS Seznam nezavislych ctyruhelnıku. N/4 ctyruhelnıku je defi-novano, kde N je pocet indexovanych vrcholu.

Obrazek 3.4: Ukazka nekterych typu razenı trojuhelnıku

Blizsı popis nejen techto zpusobu interpretace primitiv je naprıklad vdokumentaci OpenGL ([?]), z nız take vychazela volba podporovanych typu.Trojuhelnıkova geometrie umoznuje libovolnou kombinaci podporovanychzpusobu interpretace primitiv v ramci jedine geometrie pomocı seznamu,jehoz polozkami jsou dvojice - typ interpretace a index do pole indiciı. Indexdo pole indicıı znacı zacatek platnosti dane interpretace, konec platnostivyplyva z indexu do pole indiciı dalsı polozky seznamu (pokud uz zadnadalsı nenı, platnost trva az do konce vykreslovanı geometrie). Index v prvnıpolozce je ignorovan, zacına se vzdy od zacatku indiciı.

3.4.3 Pravidla prıstupu k datum sceny

Veskere zmeny uzlu, jako je transformace, zmena jmena, prirazenı ge-ometrie apod. nenı mozne provadet prımo, ale pouze skrze rozhranı sceny.Vsechny upravy uzlu prochazı pres scenu samotnou, takze je zajistena spravnaposloupnost nekterych operacı a vyvolanı prıslusnych udalostı. Vetsina op-eracı nad uzly pracuje s identifikatory jednotlivych entit na rozdıl od prımychukazatelu.

3.4. SCENA 47

Modifikace entit a v nekterych prıpadech i uzlu ve scene probıha nazaklade principu Copy On Write, tj. data jsou sdılena z jednoho mısta proctenı, ale pri pozadavku na modifikaci je nutne vytvorit kopii a az na teprovest modifikace (viz [?]).

3.4.4 Uprava sceny

Prıklad vlozenı uzlu s geometriı do sceny a prirazenı geometrie prımymvolanım metod sceny:

///Pro uspesne pridanı do sceny musı mıt uzel unikatnı jmenowxString nodeName = __getUniqueName();

///Vytvorıme uzel typu geometrie, ale zatım bez geometrie a materialuSceneNode * node = new GeometryNode(nodeName);///Vlozıme uzel do sceny jako potomka jineho uzluNODE_ID nodeID = scene->Insert(node, parentID);///Uzlu byl prirazen identifikator, pokud ne, vlozenı selhaloif (nodeID == NODE_ID_NONE)

return;

///Nynı vytvorıme trojuhelnıkovou geometrii,///opet s unikatnım jmenem - stacı v ramci geometriı,///muze byt tedy stejne jako jmeno uzluGeometry * geom = new GeometryTriangles(nodeName);///Naplnıme daty__fillGeometry(geom);///Pridame do scenyGEOMETRY_ID geomID = scene->AddGeometry(geom);///Geometrii byl prirazen identifikator, pokud ne, vlozenı selhaloif (geomID == GEOMETRY_ID_NONE)

return;///Az ted’ muzeme geometrii priradit uzluscene->SetGeometry(nodeID, geomID);///Obdobne pro material

Prirazenı materialu by se provedlo zcela analogicky. Stejna operace zvlastnıho vlakna modulu je mozna pouze pri zajistenı exkluzivity prıstupu,ale jednotny koncept pro zamykanı sceny ve VRUT zatım nebyl definovan.Resenım jsou udalosti, ktere jsou zcela bezpecne pro paralelnı prostredı,na druhou stranu majı nekolik omezenı. Vzhledem k tomu, ze zpracovanıudalostı je asynchronnı, kontrola vysledku zpracovanı po vyslanı udalostije mozna pouze pomocı synchronizace udalostı, ktera nenı vzdy zadoucı(viz sekce 3.7.5). S tım take souvisı problem identifikatoru, ktere nejsou


prirazeny hned, z tohoto duvodu je nutne pracovat s nazvy uzlu a entit,jejichz unikatnost je pozadovana pri vkladanı do sceny. Opet pridanı uzlu ageometrie, tentokrat z vlakna modulu pomocı udalostı:

///Pro uspesne pridanı do sceny musı mıt uzel unikatnı jmenowxString nodeName = __getUniqueName();///Vytvorıme uzel typu geometrie, ale zatım bez geometrie a materialuSceneNode * node = new GeometryNode(nodeName);///Zazadame o vlozenı uzlu do sceny jako potomka jineho uzluwxCommandEvent evt= Event::GET_EVT_SCENE_NODE_INSERT(sceneID, node, parentName);PostToKernel(evt);

///Nynı vytvorıme trojuhelnıkovou geometrii,///opet s unikatnım jmenem - stacı v ramci geometriı,///muze byt tedy stejne jako jmeno uzluGeometry * geom = new GeometryTriangles(nodeName);///Naplnıme daty__fillGeometry(geom);///Zazadame o vlozenı do scenywxCommandEvent evt2 = Event::GET_EVT_SCENE_GEOMETRY_ADD(sceneID, geom);PostToKernel(evt2);///Nakonec posleme prıkaz k prirazenı geometrie///Udalosti jsou zpracovavany poporade, takze az se zacne zpracovavat///pozadavek k prirazenı, geometrie uz bude pridana z predchozı udalostiwxCommandEvent evt3= Event::GET_EVT_SCENE_NODE_GEOMETRY_SET(sceneID, nodeName, geoName);PostToKernel(evt3);

3.5 BVH

Hierarchie obalek (BVH - Bounding Volume Hierarchy) je napojena nakazdou scenu, rozdeluje scenu podle osove zarovnanych obalek (AABB - AxisAligned Bounding Box) jednotlivych uzlu s geometriı. Dıky tomu posky-tuje velmi efektivnı operace nad scenou, jako je orezanı sceny pohledovymjehlanem (VFC - View Frustum Culling) nebo vyber objektu paprskem.Pred temito operacemi je nutne BVH vytvorit. Vytvorenı BVH se provadına zadost, takze nijak nezatezuje system, pokud nenı BVH pouzıvan.

3.5.1 Konstrukce

Hierarchie obalek reflektuje prostorove umıstenı jednotlivych geomet-rickych objektu. Pouzitym algoritmem pro vytvorenı binarnıho stromu obalek

3.5. BVH 49

je BVH-Median provedeny smerem shora dolu, zacına se s celou scenou akorenovym uzlem BVH:

• Vytvor celkovou obalku AABB pro uzly s geometriı a prirad’ aktualnımuuzlu BVH

• Pokud zbyva jen jeden uzel s geometriı, prirad’ ho k aktualnımu uzluBVH a ukonci postup

• Jinak vyber delıcı rovinu v polovine nejdelsıho rozmeru AABB

• Opakuj postup od prvnıho bodu pro uzly s geometriı prevazne najedne a na druhe strane delıcı roviny, pro obe skupiny vytvor poduzlyaktualnıho BVH uzlu

Obrazek 3.5: Vypocet AABB a transformacı. Scena pro jednoduchostznazornena pouze jednou vetvı stromu.


Zakladem pro vypocet AABB je lokalnı obalka geometrie, ktera se trans-formuje svetovou transformacnı maticı uzlu sceny s touto geometriı (vizobr. 3.5). Obalka vıce uzlu s geometriı se jednoduse zıska sjednocenım vsechprıslusne transformovanych AABB geometriı. V BVH platı, ze obalka vnitrnıhouzlu je vzdy sjednocenım AABB potomku.

Krome AABB ma kazdy uzel BVH take pomocnou obalku v podobekoule, ktera obsahuje celou geometrii uzlu vcetne AABB, takze je nevhodnapro operace narocne na presnost, nicmene poskytuje velmi rychly vylucovacıtest pruniku s obalkou jineho uzlu.

3.5.2 Aktualizace

Po vlozenı novych uzlu s geometriı do sceny je treba projevit zmeny i vBVH. Pridanı novych uzlu nebo vytvorenı, pokud je BVH prazdny, zajist’ujemetoda sceny:

BVH * bvh = scene->UpdateBVH();

Scena si uchovava informace o nove pridanych uzlech s geometriı a priaktualizaci BVH je preda k doplnenı. Pro spravnou funkci by se vzdy predpouzitım BVH mela tato aktualizace provest, pro zobrazovacı moduly je ak-tualizace provedena automaticky pred kazdym volanım Draw metody mod-ulu. Je ovsem zcela zakazano volat tuto metodu z modulu z duvodu pop-sanych v sekci 3.7.8. Z modulu je mozne zazadat o aktualizaci vyslanımudalosti EVT SCENE BVH UPDATE a synchronizovat udalostı EVT SCENE BVH UPDATED.Aktualizace BVH neznamena nutne aktualizaci jednotlivych obalek, ale pouzedoplnenı BVH o nove vlozene uzly sceny s geometriı od poslednı aktualizace.Pokud existuje uzel, ktery je treba vlozit do BVH, vsechny obalky jsou vdusledku algoritmu pro vlozenı aktualizovany, v opacnem prıpade se nicnestane a metoda pouze vracı ukazatel na instanci BVH.

Zmena transformace uzlu sceny s geometriı ma za nasledek zneplatnenıprıslusneho uzlu nebo uzlu BVH (viz sekce 3.4.1). Aktualizace uzlu BVH seprovadı zcela analogicky s aktualizacı uzlu sceny, jen dusledek zneplatnenıuzlu je rozdılny. Zatımco u sceny jsou pri zneplatnenı uzlu ovlivneni vsichnijeho potomci (skladanı transformacı se sırı smerem od korene dolu), u BVHjsou to uzly cesty v grafu ke korenu (skladanı obalek jde smerem od listu kekoreni).

3.5.3 Orezanı pohledovym jehlanem

Orezanı pohledovym jehlanem, z anglickeho View Frustum Culling (dalejen VFC), je jednou z nejdulezitejsıch metod pro optimalizaci a zrychlenı zo-brazovanı rozsahlych scen. Myslenka je velmi jednoducha: nekreslit objektyve scene, ktere nemuzou byt videt – jsou mimo pohledovy jehlan, tedy viewfrustum (dale jen VF). VF je geometrickou reprezentacı casti sceny, ktera

3.5. BVH 51

je viditelna virtualnı kamerou (viz obr. 3.6). VF je definovan sesti rovinamivymezujıcımi tento prostor. Jelikoz VF zabıra casto jen zlomek cele sceny,dıky VFC lze dosahnout vyrazneho urychlenı vykreslovanı.

Obrazek 3.6: Pohledovy jehlan z ptacı perspektivy

Efektivita VFC algoritmu zavisı predevsım na spravnem zpusobu prochazenısceny pri testovanı, zda je objekt uvnitr VF, a take efektivite vlastnıho testu.Pro pruchod je s vyhodou pouzita hierarchie obalek a pro zefektivnenı testuse aplikuje nekolik optimalizacı.

Pruchod stromem

Vlastnı algoritmus zacına korenovym uzlem BVH a postupuje nıze stromempodle vysledku testu vzajemnych pozic kamery a obalek jednotlivych uzlu.Kamera jako specialnı typ uzlu sceny nema obalku typu AABB, ale koule.Nasleduje posloupnost a popis testu vzajemnych pozic objektu nebo obalek:

• Test, zda je kamera uvnitr obalky uzluZvlastnı prıpad. Pokud je kamera uvnitr obalky testovaneho uzlu,vysledek se uvazuje jako by se VF s obalkou uzlu protınaly a prechazıse k testum potomku uzlu, v opacnem prıpade se pokracuje dalsımtestem.

• Test koule versus kouleJednoduchy test vzdalenostı stredu obou obalek uzlu a kamery. Pokudse protınajı, nasleduje dalsı test, jinak se uzel i s potomky ignoruje -jsou mimo pohledovy jehlan.


nx ny nz p-vrchol n-vrchol+ + + [xmax, ymax, zmax] [xmax, ymin, zmin]+ + - [xmax, ymax, zmin] [xmax, ymin, zmax]+ - + [xmax, ymin, zmax] [xmax, ymax, zmin]+ - - [xmax, ymin, zmin] [xmax, ymax, zmax]- + + [xmin, ymax, zmax] [xmin, ymin, zmin]- + - [xmin, ymax, zmin] [xmin, ymin, zmax]- - + [xmin, ymin, zmax] [xmin, ymax, zmin]- - - [xmin, ymin, zmin] [xmin, ymax, zmax]

Tabulka 3.1: Tabulka pro vyber n, p vrcholu

• Test AABB s VF

– Pokud je AABB obalka uzlu cela uvnitr VF, vykreslı se veskerageometrie odkazovana listy podstromu BVH bez dalsıch testu.

– Pokud je venku, uzel i s potomky se ignorujı.

– V prıpade, ze se protınajı, prechazı se k testum potomku. Pokudjde o list, testujı se vrcholy odkazovane geometrie, v prıpadejedineho vrcholu uvnitr VF se geometrie vykreslı.

Ve velmi vyjimecnych prıpadech muze test geometrie selhat, napr. velkytrojuhelnık protınajıcı pohledovy jehlan se vsemi svymi vrcholy mimo nej.Nejnarocnejsı castı algoritmu je test vzajemne pozice AABB a pohledovehojehlanu reprezentovaneho sesti rovinami. Existuje nekolik optimalizacı protento ukon:

Obrazek 3.7: n, p - vrcholy

3.5. BVH 53

• n, p – vrcholyMısto testovanı vsech osmi vrcholu AABB s kazdou ze sesti rovin VFjsou testovany pouze vrcholy dva, tzv. zaporne (negative) a kladne(positive) vrcholy. Jejich pozici ve vztahu k testovane rovine znazornujeobr. 3.7. Pokud je n-vrchol na vnejsı strane roviny VF, je cely AABBmimo VF. Pokud je p-vrchol na vnitrnı strane, je na vnitrnı strane(nikoliv nutne uvnitr VF) i cely AABB. Nalezenı n, p vrcholu je vprıpade AABB trivialnı, stacı je vyhledat v predpripravene tabulce(viz tab. 3.1) podle znamenka jednotlivych slozek normaly testovaneroviny.

• Koherence rovinTato optimalizace vychazı z jednoduche myslenky. V prıpade, ze bylaAABB obalka vyrazena kvuli tomu, ze se nachazela na vnejsı stranejedne z rovin VF, je vysoce pravdepodobne, ze se situace bude opako-vat i v dalsım testu. Zmenou poradı testovanych rovin tak, ze se zacnes touto rovinou (viz 3.8), lze usetrit nekolik casto zbytecnych testu.

• Maskovanı rovinPokud je AABB uzlu na vnitrnı strane jedne z rovin, to same nutneplatı pro vsechny potomky uzlu a nema pro ne cenu tuto rovinu testo-vat. Indexy rovin, ktere nemusejı byt testovany, jsou posılany pripruchodu BVH v podobe bitove masky.

Obrazek 3.8: Koherence rovin

Vıce nejen ke zmınenym optimalizacım je k nalezenı napr. v [?] nebo [?],pouzite algoritmy v [?].


3.6 Uzivatelske rozhranı

VRUT poskytuje nekolik moznostı jak ovlivnit jeho chovanı a vyuzıtvsechny jeho funkce. Prvnı se nabızı hned pri spoustenı aplikace, VRUTpovoluje dva typy argumentu na prıkazove radce:

• -D<vlastnık.param>=<value> - nastavenı hodnoty a vychozı hodnotyregistrovaneho parametru, vıce viz 3.7.9

• <skript> - spustenı skriptu s prıkazy

Oba tyto argumenty mohou byt libovolne opakovany a razeny. Po spustenıjsou nejdrıve aplikovana vsechna nastavenı registrovanych parametru z prıkazoveradky, pote je spusten skript autoexec.cfg a nasledujı dalsı prıpadne skriptyz prıkazove radky. autoexec.cfg ma vysadnı postavenı, je spusten pri kazdemstartu aplikace, hleda se v pracovnım adresari VRUTu. Spustenı skriptu jeekvivalentnı se zadanım stejne posloupnosti prıkazu do konzole, coz je dalsızpusob interakce s uzivatelem.

Konzole s prıkazovou radkou je vychozı soucastı hlavnıho okna. Prizadavanı prıkazu se zobrazı napoveda k prıkazu odpovıdajıcımu zadanymznakum, tabelatorem lze znaky expandovat na zobrazeny prıkaz. Prove-denı prıkazu ma vetsinou za nasledek vystup v podobe zpravy v okne slog udalostmi, ktere je take soucastı hlavnıho okna (viz obr. 3.9). Tabulka3.6 obsahuje vypis vsech prıkazu i s argumenty.

Prıkaz Argumenty Popis

cardisplay [texturepath:str ] Specialnı funkce pro prevod texturyratiox:unsignedratioy:unsigned

dumpscene sceneID:unsigned Ulozı textovy soubor s vypisem scenyexit Ukoncı aplikaciexportscene sceneID:unsigned Ulozı scenu do souboru

fileName:strfit windowID:unsigned Posune kameru, aby zabrala celou scenu

(bez zmeny natocenı)forbidmodule moduleName:str Zakaze dalsı vytvarenı modulufullscreen windowID:unsigned Zapne nebo vypne zobrazenı pres celou

enable:bool obrazovku pro dane oknogetparam [module[.param[.instID]]:str] Vypıse seznam odpovıdajıcıch

reg. parametru a jejich hodnotgetvideomodes [displayID:unsigned] Vypıse dostupne mody zobrazenı

pro dany monitorhelp Vypıse seznam prıkazu s argumenty

3.6. UZIVATELSKE ROZHRANI 55

importscene fileName:str Nahraje scenu ze souborulistmodules Vypıse seznam dostupnych modulu

a vytvorenych instancılistscenes Vypıse seznam scenls [path:str ] Vypıse obsah adresaremodhelp [module:str ] Vypıse popis modulurenderscene sceneID:unsigned Zobrazı scenu v novem okneresetview windowID:unsigned Posune kameru, aby zabrala celou scenu

(vychozı natocenı kamery)runmodule moduleName:str Vytvorı instanci modulu

a spustı jeho vlaknosavegraphviz sceneID:unsigned Ulozı GraphViz soubory s grafy sceny

a BVH (nutna GraphViz podpora)setloglevel loglevel:str Nastavı novou uroven logovanı

Povolene hodnoty: disable, errors,warnings, messages, all

setparam module[.param[.instID]]:str Nastavı reg. parametr(y)value:str [default:bool] na zadanou hodnotu

setvideomode displayID:unsigned Nastavı parametry zobrazenıwidth:unsigned pro dany monitorheight:unsignedbpp:unsigned

refresh:unsignedshowpane panename:str Zobrazı/skryje panel GUI

show:boolshowparam paramname:str Zobrazı ovladacı prvek pro parametr

show:bool nebo skryje celou zalozku s parametryswitchvideoouts displayID:unsigned Specialnı funkce pro prepınanı

width:unsigned vystupu graficke kartyheight:unsignedbpp:unsigned

refresh:unsignedusemodule moduleName:str Zaradı modul na prvnı pozici

preferovanych moduluHranate zavorky znacı nepovinnou polozku

Tabulka 3.2: Seznam prıkazu konzole


Obrazek 3.9: Hlavnı okno aplikace

3.6.1 Graficke uzivatelske rozhranı

Zakladem GUI je hlavnı okno, ktere sdruzuje vsechny ovladacı prvky agraficke vystupy. Krome jiz zminovane prıkazove konzole a okna s vypisemlog zprav se zde nachazejı ovladacı prvky pro registrovane parametry a zo-brazovacı okna (viz obr. 3.9). Jednotlive casti okna jsou vytvoreny v dojiste mıry experimentalnım dynamickem prostredı poskytovanem knihov-nami wxWidets, ktere umoznuje panely ruzne preskupovat, menit jejich ve-likost nebo je zcela odpojit od hlavnıho okna, prıpadne skryt. Zobrazenı askrytı panelu lze vyvolat i vyslanım prıslusne udalosti ci prıkazem konzole,coz dava modulum nebo skriptum moznost v male mıre menit vzhled GUI.

3.6. UZIVATELSKE ROZHRANI 57

3.6.2 Log

Okno se zpravami systemu. Pocet vypsanych zprav zalezı na nastavenıurovne. Vypisovanı muze byt uplne zakazano, nebo mohou byt zobrazovanydetailnı informace, coz muze pomoct pri resenı problemu. Vypisovanı velkehomnozstvı zprav muze zpomalovat system.

3.6.3 Renderer

Okno s 3D vizualizacı sceny. Do toho okna vykreslujı scenu moduly typurender a ovladanı zajist’ujı moduly manip.

3.6.4 Drag&Drop

VRUT ma velice jednoduchou podporu pro Drag&Drop technologii. Pretazenısouboru na okno Console lze soubor importovat, pretazenım na jinou castaplikace lze soubor importovat a soucasne zobrazit. Pridrzenım tlacıtka Con-trol se soubor importuje do sceny, ktera je vyrenderovana v aktivnım okne(pokud zadna nenı, nic se neimportuje).

Poznamky

1. Po pretazenı souboru na vrut.exe system spustı VRUT a dany souborpouzije jako parametr prıkazove radky. Je mozne pretahnout vıce souborunaraz.2. VRUT je mozne pouzıt pro otevrenı daneho typu souboru poklepanım(prıpadne pres prave tlactko mysi Otevrıt/Otevrıt s).

3.6.5 Parameters

Zobrazuje parametry spustenych modulu. Kazdy parametr ma jmeno,hodnotu a muze mıt ToolTip (kratka napoveda zobrazena pri najetı mysınad ovladacı prvek). Kazdy parametr ma prirazen ovladacı prvek (textovepole, zatrhavacı ramecek, rozbalovacı nabıdku, atd.). Typ ovladacıho prvkuje urcen modulem a uzivatel jej nemuze ovlivnit.

GUI pro registrovane parametry

Registrovane parametry modulu mohou byt zobrazeny ve forme ovladacıchprvku zarazenych v zalozkach podle instance modulu. Nazev zalozky sesklada ze jmena modulu a identifikatoru instance, kazdy ovladacı prvekpak nese nazev registrovaneho parametru, tato trojice tvorı kompletnı iden-tifikaci registrovaneho parametru (vıce o registrovanych parametrech vizsekce 3.7.9). Trıda GUIEnvironment spravujıcı zalozky a ovladacı prvky reg-istrovanych parametru je nezavislou nadstavbou trıdy Environment, kterama na starosti spravu samotnych reg. parametru. Komunikace probıha obema


smery standardne pomocı udalostı, zmena hodnoty v GUI se nasledne pro-jevı ve skutecne hodnote reg. parametru a naopak.

Ovladacı prvky jednotlivych parametru lze pridavat za chodu vyslanımprıslusne udalosti nebo prıkazem konzole, podmınkou je, aby parametr bylpredtım zaregistrovany. Skrytı ovladacıch prvku jednotlive v soucasne dobenenı mozne, skryt lze pouze cela zalozka se vsemi parametry instance mod-ulu.

Obrazek 3.10: Rozdelenı panelu se zobrazovacımi okny

Zobrazovacı okna

Nejvetsı plocha hlavnıho okna aplikace bude vetsinou uzivatelu nejspısevenovana zobrazene scene. Panel se zobrazovacımi okny je resen opet po-mocı zalozek, z nichz kazda pojme prave jedno zobrazenı urcite sceny. Dıkydynamickemu GUI prostredı lze panel rozdelit na casti a zobrazit vıce okennajednou (viz obr. 3.10).

3.7. MODULY 59

3.7 Moduly

VRUT je od pocatku koncipovan jako modularnı aplikace, snadna moznostjeho rozsirovanı byla hlavnım pozadavkem zadavatele. Pres vsechnu snahuo maximalnı flexibilitu aplikace a moznosti rozsırenı existuje pro modulynekolik omezenı a pravidel. Tato sekce pokryva vetsinu informacı nutnychpro uspesnou tvorbu vlastnıch modulu a mela by byt dukladne prostudovanaprıpadnymi autory novych vlastnostı VRUTu.

Modul (nebo plugin) je ve skutecnosti dynamicky linkovana knihovna sprıponou so nebo dll podle pouzite platformy - Linux nebo Microsoft Win-dows. Pro vyuzitı funkcı knihovny je treba vytvorit instanci modulu, presnejireceno knihovna poskytuje funkci, ktera vratı instanci trıdy definovane kni-hovnou. Z hlavnı aplikace tedy nejsou volany prımo exportovane funkce kni-hovny, ale metody trıdy. Trıda implementovana v modulu je vzdy potomkemtypove nadtrıdy definovane v hlavnı aplikaci, spolecnou nadtrıdou vsechje trıda Module (viz ukazka na obr. 3.11). Tvorba modulu je dıky tomutozpusobu snadnejsı a prehlednejsı, vyuzıva se standardnı C++ dedicnosti.Ukazka vztahu instancı, modulu a spravce je na obr. 2.12. V dalsıch castechkapitoly bude pro zjednodusenı mınena pod pojmem modul konkretnı in-stance modulu, pokud nebude uvedeno jinak.

3.7.1 Identifikace

Zakladnımi parametry kazde instance modulu jsou jmeno, typ a iden-tifikator. Zatımco jmeno a typ jsou shodne pro vsechny instance danehomodulu, identifikator je unikatnı pro kazdou instanci, sklada se ze trı castı -identifikator spravce daneho modulu, cıslo modulu (ve smyslu knihovny) acıslo instance. Jmeno je pouzıvano pro srozumitelnejsı kontakt s uzivatelem(vypisy log a nektere prıkazy) a pro registrovane parametry. Typ slouzıpredevsım k overenı, zda dany modul poskytuje pozadovane metody, teo-reticky muze v sobe modul spojovat vıce typu najednou. Identifikator jeunikatnı v ramci cele aplikace a podava jasne informace o puvodu instancemodulu, tedy ktereho modulu je instancı a ve kterem spravci. Drtiva vetsinametod v aplikaci pracuje prave s identifikatorem nebo s nejakou jeho castı.Jmeno je definovano modulem programove stejne jako metoda vracejıcıstrucny popis modulu. Typ a identifikator jsou prideleny automaticky. Typje prebran z nadrazene trıdy, ale muze byt za urcitych okolnostı upraven.

3.7.2 Hlavnı smycka

Kazdemu modulu je hned po vytvorenı prideleno vlakno, ve kterem budemodul zpravidla vykonavat svoji cinnost. I kdyz konkretnı modul nevyzadujenebo nesmı pouzıt (zobrazovacı nebo jiny modul s prıstupem ke GUI) vlastnıvlakno pro svou hlavnı cinnost, vlakno je vzdy prideleno a spusteno, slouzı


Obrazek 3.11: Ukazka hierarchie trıd modulu pro import/export scen

totiz ke komunikaci s jadrem.Modul zije vlastnım zivotem v nekonecne smycce ve vlastnım vlakne,

dokud nenı vyzvan k ukoncenı. V kazde iteraci hlavnı smycky jsou prove-deny dva ukony, zpracovanı jedne udalosti z fronty zprav a zavolanı metodyrun. Metoda run je standardne prazdna a poskytuje v novych modulechmoznost implementovat cinnost, ktera ma byt provedena v kazde iteracihlavnı smycky modulu, ovsem je dobre mıt na pameti, ze intervaly mezijednotlivymi iteracemi se mohou velmi zasadne menit.

Pred uvolnenım modulu je modulu zaslana udalost EVT EXIT, kteraznacı pozadavek k ukoncenı hlavnı smycky. Zpracovanı teto udalosti je im-plementovano v zakladnı trıde Module, nicmene odvozene moduly musı za-jistit, ze ke zpracovanı vubec dojde. Jadro ceka od odeslanı pozadavku kukoncenı urcity casovy interval (v radu sekund) a pokud se do te dobymodul neukoncı, je nasilne ukoncen a smazan, coz muze vest k nespravneuvolnene pameti. Je proto nutne, aby moduly s casove narocnymi oper-acemi prubezne kontrolovaly, zda neprisel pozadavek k ukoncenı. K tomu

3.7. MODULY 61

slouzı metoda TestExit:

///Casove narocna metoda volana ve vlastnım vlakne (v iteraci hlavnı smycky)void MyModule::LongOperation(){

allocMyData();for (int i = 0; i < 1000; i++){

doSomething();///Dobre napsany modul musı pravidelne kontrolovat,///zda je nadale zadoucı jeho existenceif (TestExit()){

///Mame byt ukonceni, dealokujeme lokalne alokovana datadeallocMyData();///A co nejdrıve vracıme kontrolu hlavnı smyccce,///ta se postara o zbytekreturn;

}}deallocMyData();

}

3.7.3 Aktivace

Modul poskytuje vetsinou jednu nebo dve stezejnı funkce, kvuli kterymbyl vytvoren. Cinnost modulu je zahajena zpravidla na zaklade udalosti,ktera je zaslana modulu. Predanı argumentu k dane cinnosti muze bytprımo soucastı spoustecı udalosti nebo udalosti jine, ciste pro tento ucelvytvorene, prıpadne je provedeno pomocı registrovanych parametru. Jelikozzpracovanı udalostı modulu probıha v jeho vlastnım vlakne v hlavnı smycce,vyvolana cinnost bude probıhat take ve vlastnım vlakne, je tedy treba dbatna bezpecnost, pokud je pristupovano k prostredkum sdılenym mezi vlakny.

Nekdy muze byt nezadoucı provadet cinnost ve vlastnım vlakne a vtakovem prıpade je cinnost modulu vyvolana prımo z jadra. O tom, zda budecinnost provadena v hlavnım vlakne ci nikoliv, rozhoduje jadro, presnejireceno jde o pevne dane schema pro konkretnı typy modulu. Vetsina modulureaguje na udalosti a vyuzıva vlastnı vlakno, prıkladem modulu s prımymvolanım je zobrazovacı typ modulu, ktery zasahuje do grafickeho rozhranı,coz nenı povoleno v jinem nez hlavnım vlakne.

Dalsı moznostı aktivace modulu je pomocı prıkazu konzole runmodule,ktery vytvorı modul a spustı jeho vlakno. Takto lze pustit modul libovolnehotypu, ale hlubsı provazanı s jadrem chybı. Je zalezitostı modulu, jak budeprobıhat interakce s uzivatelem a jadrem, k dispozici ma standardnı formy


komunikace popsane v sekci 3.7.4.

3.7.4 Komunikace s jadrem

Neprımou a nejen z hlediska vlaken bezpecnou komunikaci mezi modulya jadrem obema smery zajist’ujı udalosti. Metoda PostEvent slouzı k zarazenıudalosti do fronty zprav modulu. Z pohledu modulu je zajımavejsı metodaPostToKernel, ktera prevezme udalost, prida k nı identifikator modulu apreda jadru ke zpracovanı. Odeslanı udalosti z modulu je jednoduchy proces,hlavne dıky pomocnym metodam pro vytvorenı udalostı, ktere priradı datana spravna mısta. Odeslanı udalosti centralnımu spravci muze vypadat trebatakto:

///Pomocna metoda priradı argumenty do spravnych polozek udalostiwxCommandEvent rndEvt = Event::GET_EVT_RENDER_UPDATE(scene->GetID());///Nasleduje prirazenı ID modulu jako ID odesılatele a poslanı udalosti jadruPostToKernel(rndEvt);

Vsechny metody pro poslanı udalosti majı druhy nepovinny argument,kterym lze udalost poslat prioritne. Posılanı udalostı je velice jednoduche,ale ma-li modul pracovat spravne, musı spravne zpracovat prıchozı udalosti.Zpracovanı zakladnıch udalostı je implementovano v nadtrıdach, v novychmodulech je treba implementovat pouze zpracovanı dalsıch udalostı, na kterema modul reagovat. To lze udelat snadno pretızenım virtualnı metody pro-cessEvent:

class MyModule : public ManipulatorModule{

...

///Pretızenım nasledujıcı metody muzeme zpracovat nove udalostivirtual void processEvent(wxCommandEvent & evt){

///Pro korektnı chovanı modulu je potreba zavolat///tutez metodu nadtrıdy!

///Volanı by se melo nachazet hned na zacatku metodyManipulatorModule::processEvent(evt);

///Dıky jednoduche identifikaci udalostı lze pouzıt switchswitch (evt.GetEventType()){

case Event::EVT_SCENE_RAY_PICK:LOG(wxT("Pick ray event received"));break;

default:

3.7. MODULY 63

break;}

}

...};

Pro korektnı zpracovanı zakladnıch udalostı nadtrıd je nutne zavolatpuvodnı metodu nejblizsı nadtrıdy. Dıky tomuto schematu je rovnez moznedoplnit zpracovanı zakladnıch udalostı. S jinym schematem a trochou obezretnostilze zcela prevzıt kontrolu nad zpracovanım zakladnıch udalostı.

Poslednı krok nutny pro zpracovanı udalosti modulem je zadost o reg-istraci ve spravci udalostı. Spravce udalostı v jadre je centralnı prvek, presktery prochazejı zpravidla vsechny udalosti aplikace. K tomu, aby mohl dis-tribuovat udalosti modulum, musı vedet, kterou udalost kam poslat. Protento ucel poskytuje spravce udalostı metodu RegisterListener a pro prehlednejsıkod je v modulu definovano makro REGISTER LISTENER:

///Registrace modulu pro prıjem udalosti - vetsinou v konstruktoru moduluREGISTER_LISTENER(Event::EVT_SCENE_RAY_PICK);

Zrusenı registrace se deje automaticky pro vsechny typy udalostı v de-struktoru, ale je mozne i explicitnı zrusenı za chodu pomocı metody Unreg-isterListener. Jsou vyjimecne prıpady, kdy je udalost poslana prımo modulubez ucasti centralnıho spravce a tehdy registrace nema zadny vliv. Dalsıinformace o udalostech jsou v sekci 3.2.

3.7.5 Synchronnı komunikace

Standardnı komunikace pomocı udalostı je asynchronnı, vyslana udalostje zpracovana v jinem vlakne a odesılatel nema k dispozici informaci ovysledku. Za predpokladu, ze vyslana udalost ma za nasledek vytvorenı jineudalosti, k jejız odberu je navıc odesılatel prihlasen, lze komunikaci synchro-nizovat. Modul poskytuje metodu WaitForEvent, ktera uspı vlakno, dokudnedorazı pozadovana odpoved’. Jednım z argumentu metody je maximalnıcasovy limit pro cekanı, dale je mozne ocekavanou udalost blıze specifikovathodnotami pro porovnanı a vyloucit tak udalosti stejneho typu adresovanejinemu prıjemci. Protoze synchronizace pozastavı vlakno, je dobre puvodnıudalost vyslat s vyssı prioritou a minimalizovat tak ztraceny cas. Zvlastnımprıpadem je pozadavek na ukoncenı modulu, ktery zpusobı okamzite vracenıneuspesneho vysledku z metody. Proto by melo vzdy nasledovat volanı metodyTestExit a prıslusna reakce na jejı vysledek.


3.7.6 Casovy limit pro prıjem udalosti

Velmi dulezitym parametrem kazdeho modulu je casovy limit pro prıjemudalosti. V kazde iteraci hlavnı smycky modulu je zkontrolovana frontaudalostı a pokud nenı prazdna, je zpracovana jedna udalost a pokracuje sedale. V prıpade, ze je fronta prazdna, ceka vlakno modulu prave dany casovylimit. Je zrejme, ze tato hodnota zasadnım zpusobem ovlivnuje chovanı mod-ulu a v dusledku i zatez procesoru. Vychozı hodnota je 1000 ms, ktera jev drtive vetsine prıpadu zcela vyhovujıcı a pokud modul nedostava zadneudalosti a je neaktivnı, zatez je prakticky nulova. Hodnotu casoveho limitulze menit pres registrovany parametr eventTimeout (vıce o registrovanychparametrech v sekci 3.7.9). Pokud je modul neustale zasobovan udalostmi,nema casovy limit zadny vliv a udalosti jsou zpracovavany bez prerusenı.Hodnoty casoveho limitu v souctu pod 10 ms mohou zvysit zatez a nemelyby byt pouzıvany, pro dostatecne rychlou odezvu uplne stacı mnohem vyssıhodnoty.

Zpracovanı udalostı klavesnice a mysi

Nektere typy modulu zpracovavajı zvlast’ vstupnı udalosti z klavesnicea mysi, ktere jsou jineho datoveho typu nez ostatnı udalosti ve VRUTu aradı se do vlastnıch front. Obe nove fronty majı vlastnı casove limity prozpracovanı - keyEventTimeout a msEventTimeout. Pri zpracovanı udalosti vjedne iteraci hlavnı smycky se kontrolujı vsechny tri fronty, a proto by melybyt hodnoty casovych limitu nastaveny tak, aby se navzajem prılis nebloko-valy. Naprıklad modul ovladanı kamery pouze pomocı mysi muze mıt msEv-entTimeout na hodnote treba 1000 ms, ale keyEventTimeout a eventTimeoutby mely mıt hodnotu nızkou (napr. 10 ms), aby frekvence odchytu pohybumysi byla dostatecne vysoka a pohyb plynuly (v tomto prıpade maximalnejednou za 10 + 10 ms - soucet obou zbylych casovych limitu). Pro registraciudalostı mysi a klavesnice platı stejna pravidla a system jako pro ostatnı:

///Prihlasenı k odberu vsech udalostı klavesniceREGISTER_LISTENER(Event::EVT_INPUT_KEY);///Prihlasenı k odberu vsech udalostı mysiREGISTER_LISTENER(Event::EVT_INPUT_MOUSE);

Tato registrace a zpracovanı udalostı mysi a klavesnice jsou jiz soucastımodulu typu Manipulator a jeho potomku, ke spravne funkci stacı pretızitprıslusne metody (viz sekce 3.7.11).

3.7.7 Typy

Jadro zastresuje nekolik spravcu modulu, z nichz kazdy spravuje jedennebo vıce typu modulu. Pro kazdy typ modulu je definovana relativnı cesta

3.7. MODULY 65

Spravce Typ modulu Relativnı cestaManipulatorManager MODULE TYPE MANIPULATOR modules/manip

MODULE TYPE CAMERAIOManager MODULE TYPE IO modules/io

RenderManager MODULE TYPE RENDER modules/renderGeneralManager MODULE TYPE SCENE modules

MODULE TYPE KERNELvsechny typy vsechno v modules

Tabulka 3.3: Predepsane adresare pro ruzne typy modulu

ke knihovne, jejich vycet je v tabulce 3.3. Blizsı popis pozadavku na imple-mentaci konkretnıch typu modulu je v sekci 3.7.11.

3.7.8 Alokace pameti versus modul

Na nekterych platformach ma modul v podobe dynamicke knihovnyvlastnı haldu pro pamet’. Pokud je knihovna uvolnena, je ztracena i haldas alokovanymi daty. Problem nastava, kdyz jsou data sdılena jadrem nebojinym modulem. Jsou situace, kdy je potreba data v modulu alokovat auchovat v jadre i po ukoncenı modulu. Bezpecny zpusob prenosu dat (nikolivsdılenı) je pomocı udalostı, ktere jsou vzdy klonovany, pamet’ je realokovanaa obsah zkopırovan v jadre (vıce viz sekce 3.2.2).

3.7.9 Registrovane parametry

Pro usnadnenı prace s promennymi umoznuje jadro registrovat temerlibovolny parametr. Dıky centralnı sprave parametru je mozne cıst a menithodnoty registrovanych parametru ze vsech castı VRUTu a modulu. Spravuparametru ma na starosti trıda Environment v jadru a poskytuje nekolikmetod pro praci s parametry, nicmene vetsina operacı (z modulu vsechny) seprovadı prostrednictvım udalostı. Registrovany parametr sestava ze trı castı- jmeno, hodnota a vychozı hodnota. Jmeno parametru ma specialnı formatpro jednoznacnou identifikaci - vlastnık.nazev.instance. Vlastnıkem muze bytjadro s hodnotou kernel nebo modul, v tom prıpade je hodnotou jmeno mod-ulu, nazev je oznacenı parametru (vetsinou prımo jmeno promenne v kodu)a instance je upresnenı parametru, aby bylo mozne spravovat zvlast’ parame-try ruznych instancı tehoz modulu. Rozhranı spravce umoznuje pro vetsinuoperacı pouzitı specialnıch znaku ? a * pro expanzi, takze naprıklad nenınutne vyplnovat instanci ve jmene parametru a operace bude aplikovana navsechny instance daneho modulu. Hodnoty vsech registrovanych parametrujsou uchovavany ve forme retezcu znaku, v teto forme jsou take prejımanypro operace nad nimi.


Pro jednodussı praci se pro identifikaci parametru pouzıva trıda Pa-rameterIdentificator, ktera predstavuje zmınene trojdılne jmeno parametrua poskytuje nektere pomocne metody. Z jadra lze zcela bezpecne pouzıvatprımo metody trıdy Environment pro operace nad parametry, u modulu jetreba pouzıt udalosti. Pro registraci parametru z modulu bylo definovanopomocne makro REGISTER PARAM, pri registraci je zaroven nastavenparametr a jeho vychozı hodnota na hodnotu poskytnutou jako argument.Pro nastavenı parametru z modulu slouzı makra SET PARAM a SET DEFAULT PARAM,ale je treba si uvedomit, ze zmena hodnoty se projevı az po zpracovanıudalosti v jadre. Prıklad registrace parametru:

///Vytvorenı identifikatoru - zpravidla byva clenem trıdy modulu///Alternativnı konstruktor identifikatoru pro pouzitı z moduluParameter::ParameterIdentificator parID(GetName(), wxT("par"), GetID());REGISTER_PARAM(myParamID, wxT("123"));

...

///Zmena hodnotySET_PARAM(myParamID, wxT("456"));///O pozadavku na zmenu hodnoty je informovano jadro,///ale zmena v tomto mıste zatım nemusela byt provedena!

Takto registrovany parametr je zcela samoucelny, vlastne se jen ve spravciparametru u prıslusneho vlastnıka objevil novy se jmenem myParam, alechybı jakakoliv zpetna vazba. Kazda zmena registrovaneho parametru vyvolaudalost EVT PARAM SET, takze na ni stacı jen prıslusne reagovat podobnejako u jakychkoliv jinych udalostı (viz sekce 3.2). Kazdy modul je auto-maticky registrovan pro prıjem EVT PARAM SET a navıc existuje seriemaker pro jednoduchou aktualizaci zvolene promenne pri zmene. Prıkladzpracovanı udalosti pro zmenu parametru typu integer pomocı makra UP-DATE PARAM FROM EVENT INT:

class MyModule : public ManipulatorModule{

...

virtual void processEvent(wxCommandEvent & evt){

ManipulatorModule::processEvent(evt);switch (evt.GetEventType()){

case Event::EVT_PARAM_SET:UPDATE_PARAM_FROM_EVENT_INT(myParamID, myParam, evt);

3.7. MODULY 67

break;default:

break;}

}

...};

Dalo by se rıci, ze promenna myParam zde figuruje jako vyrovnavacıpamet’, ktera uchovava hodnotu pro rychly prıstup v ramci modulu. Castymschematem byva, ze prave vedle identifikatoru parametru existuje lokalnıpromenna (lokalnı ve smyslu trıdy modulu) v prıslusnem datovem typu aodrazı veskere zmeny.

Dalsı moznosti nastavenı registrovanych parametru

Krome jiz popsaneho programoveho existujı dalsı dva zpusoby upravyregistrovanych parametru. Oba jsou aplikovatelne uzivatelem za chodu beznutnosti zasahu do kodu. Prvnım z nich je prıkaz konzole nebo skriptu set-param a getparam s argumentem v podobe trojdılneho jmena parametru aprıpadne novou hodnotou.

///Zapnutı vykreslenı BVH pro instanci 0 zobrazovacıho modulusetparam RenderGL.drawBVH.0 1renderscene 0

///Vypnutı vykreslenı BVH pro vsechny instance zobrazovacıho modulusetparam RenderGL.drawBVH 0

///Vypis reg.parametru a hodnot vsech vlastnıku zacınajıcıch pısmenem ’k’getparam k*///Vypis reg.parametru obsahujıcıch slovo ’event’ vsech vlastnıkugetparam *.*event*

Pri blizsım pohledu na prvnı prıkazy muze vyvstat otazka, co se stane,pokud zobrazovacı modul RenderGL zatım nenı vytvoren a vznikne az druhymprıkazem. V takovem prıpade je parametr zaregistrovan a aplikovan az privytvorenı modulu odpovıdajıcıho jmena, tımto zpusobem tedy lze nastavithodnoty dopredu jeste pred vlastnım vytvorenım modulu. Nicmene je trebadavat pozor na preklepy apod., aplikace nema moznost nijak reagovat prispatnem zadanı, protoze nezna dopredu nazvy modulu a jejich parametru.Parametry aplikovane na modul po vytvorenı jsou vzdy vypsany v logu.

Dıky teto vlastnosti muze existovat i druhy zpusob zadavanı - pri spoustenıVRUTu jako argument prıkazove radky. Kazdy takovy argument musı zacınat


symboly -D a parametr musı byt popsan plnym nazvem bez nahrazovacıchznamenek nasledovany rovnıtkem a hodnotou:

vrut.exe -DRenderGL.drawBVH=1 -Dkernel.evtsPerIteration=256

Hodnoty nastavene z prıkazove radky pri spustenı jsou automatickypokladany za vychozı, stejne tak hodnoty nastavene z konzole u parametru,ktere nebyly nalezeny a byly registrovany pro budoucı pouzitı.

Priorita pri nastavenı

Pokud pri registraci parametru nenı definovana cast oznacujıcı instanci,je parametr oznacen jako tzv. predef a jeho hodnota bude aplikovana naparametr kazdeho noveho modulu s odpovıdajıcım nazvem. Shrnutı a serazenızpusobu nastavenı parametru od nejnizsı priority:

• Hodnota pri volanı metody pro registraci parametru

• Argument na prıkazove radce pri spustenı

• Argument na prıkazove radce pri spustenı - pro konkretnı instanci

• Nastavenı prıkazem konzole ci ze skriptu

Uvolnenı modulu zrusı vsechny jeho registrovane parametry, vyjimkoujsou predef parametry, ktere zustavajı po celou dobu behu aplikace.

Registrovane parametry v GUI

Moznost pridat ovladacı prvky pro registrovane parametry do grafickehouzivatelskeho rozhranı zasadne zjednodusuje praci s parametry z uzivatelskehohlediska. Pro zobrazenı parametru v GUI stacı pouzıt odpovıdajıcı makroa nahradit jım puvodnı REGISTER PARAM, protoze makra pro registracido GUI zahrnujı zaroven klasickou registraci parametru:

///K registraci potrebujeme opet identifikatorParameter::ParameterIdentificator parID(GetName(), wxT("par"), GetID());///Pro tento parametr vytvorıme v GUI dvouhodnotovy checkbox///s vychozı hodnotou nepravdaREGISTER_PARAM_GUI_CHECKBOX(myBoolParamID, wxT("0"));

///Druhy parametr bude celocıselnyParameter::ParameterIdentificator parID2(GetName(), wxT("par2"), GetID());///Ovladacı prvek slider ma navıc limity minimum a maximum,///ktere se jednoduse zadavajı makru jako argumentyREGISTER_PARAM_GUI_SLIDER(myParamID, wxT("123"), 0, 1000);

3.7. MODULY 69

O vse ostatnı vcetne synchronizace hodnot se postara trıda GUIEnvi-ronment (viz sekce 3.6.5). Ovladacı prvky se radı do zalozek vzdy danehovlastnıka dane instance viz obr. 3.12. Parametry lze do GUI pridavat nebonaopak skryt take za chodu pomocı prıkazu konzole nebo skriptu showparamnebo udalostı EVT GUI PARAM SHOW s prepınacem urcujıcım, zda majıt o zobrazenı nebo skrytı. Skrytı je ale povoleno pouze pro celou zalozku ane pro jednotlive ovladacı prvky parametru. Parametru je mozne zcela zrusitregistraci bez moznosti opetovneho zobrazenı udalostı EVT PARAM GUIUNREGISTER.

TabulkaTabulku je mozne vytvorit pomocı makra:

REGISTER_PARAM_GUI_TABLE(paramId, pName, definition, pDescription)

Parametr definition musı byt promenna typu wxArrayString, popis ob-sahu je v tabulce 3.4.

Pocet Obsah Poznamka1 hlavicka ve tvaru cols - pocet sloupcu

"cols,rows,colLabSize,rowLabSize" rows - pocet radkucolLabSize - vyska popisu sloupcurowLabSize - sırka popisu radku

cols popisy sloupcu pouze je-li colLabSize > 0rows popisy radku pouze je-li rowLabSize > 0

cols ∗ rovs definice bunek ve tvaru viz tabulka 3.5"definicetypu,hodnota"

Tabulka 3.4: Definice tabulky

definicetypu Typ bunky Prıklad0 TextBox - ctenı i zapis "0,red color"1 TextBox - pouze ctenı "1,50.45"2 CheckBox "2,1"

3;moznosti ComboBox "3;A;B;C;D,B"

Tabulka 3.5: Definice typu bunky

Je-li potreba zmenit tabulku je mozne makro REGISTER_PARAM_GUI_TABLEvolat opakovane. Vzdy je nutne poslat kompletnı definici tabulky, je ovsemmozne menit cokoliv (pocet radku, sloupcu, popisy, definice i hodnoty bunek).

Zpracovanı zmen v tabulce usnadnuje makro

UPDATE_PARAM_FROM_EVENT_TABLE(paramId, col, row, target, event)


Prıklad: Hlavicka ”7, 2, 20, 40” definuje tabulku se 7 sloupci, 2 radky,vyskou popisu sloupcu 20 pixelu a sırkou popisu radku 40 pixelu.

Poznamka: Tabulka je pouzita v mnoha modulech (Cluster, Track-ing, TrackingManipulator, MaterialEditor a MaterialAssign), ktere mohouposlouzit jako ukazky pouzitı.

3.7.10 kernel

Obrazek 3.12: Bitmapovy obrazek.

Samotne jadro ma nekolik parametru, ktere mohou ovlivnit jeho chovanı.Pozor: Nemente parametry jadra pokud si nejste jisti.cloneSceneData - Zkopırovat data predavana moduly pred pouzitım do kon-textu jadra. Zapnutı snizuje rychlost.evtsPerIteration - Udava pocet zprav, ktere jadro zpracuje naraz.evtCheckInterval - V prıpade, ze je fronta zprav prazdna, netestuje se staledokola aby se zbytecne nezatezoval system, ale jenom v danem intervalu.logSyncEveryMsg - Zpravy systemu jsou ukladany na disk. Tato volba umoznısynchronizaci souboru po vypisu kazde zpravy. Zapnutı snizuje rychlost.

3.7.11 Implementace konkretnıch typu modulu

Module - zakladnı modul

Ze zakladnıho modulu vychazejı vsechny podporovane typy modulu (viz3.13). Obsahuje implementaci hlavnı smycky a metod zpracovanı udalostı,ktere jsou popsany v sekci 3.7.2. Prestoze predstavuje pouze nutny zakladkazdeho modulu, je dobre vyuzitelny pro operace, ktere nejsou tolik svazanys jadrem. Vytvorenı a spustenı zakladnıho modulu je mozne pouze pomocıprıkazu konzole runmodule nebo udalostı EVT MODULE RUN.

Povinne metody k pretızenı:

• virtual wxString GetDesc() constVracı popis modulu, poskytovane funkce atd.

Uzitecne metody k pretızenı:

3.7. MODULY 71

Obrazek 3.13: Hierarchie trıd modulu

• virtual void run()Metoda je volana v kazde iteraci hlavnı smycky. Frekvence volanı zavisına casovem limitu (viz sekce 3.7.4) a frekvenci prıjımanı udalostı.Metoda ma spıse doplnujıcı charakter pro specialnı pozadavky, alepro vetsinu modulu je vyhodnejsı reakce na udalosti.

• virtual void processEvent(wxCommandEvent & evt)Tuto metodu vyuzije temer kazdy modul. Jde o mısto, kudy prochazıvsechny udalosti zaslane modulu a kde se rozhoduje o reakcıch na ne.Prıkladem muze byt aktualizace registrovaneho parametru pri prijetıprıslusne udalosti.

SceneModule - modul sceny

Modul odvozeny od zakladnıho, pritom by se tento typ dal povazovat vpodstate take za zakladnı. Vetsina modulu pristupuje nejakym zpusobemke scene a vsechny typy modulu krome modulu jadra jsou odvozeny od to-hoto. Krome vlastnostı zakladnıho modulu je mu navıc pridelen hned povytvorenı prıstup ke spravci scen a zaregistrovan parametr sceneID s ne-platnou vychozı hodnotou. Modul ma tedy po prirazenı spravne hodnotysceneID identifikator sceny a prıpadne i prımy prıstup k nı:

Scene * scene = GetSceneMgr()->GetScene(sceneID);

Tento typ modulu je vhodny, pokud nenı treba vetsı navaznost s jadrem,ale je potreba prıstup ke scene nebo alespon prirazenı identifikatoru. Pro


vytvorenı a spustenı modulu platı stejna omezenı jako pro zakladnı modul.Neposkytuje zadne dalsı metody k pretızenı.

IOModule - modul pro import a export

IOModule je modul odvozeny od modulu sceny je v nekolika aspektechzvlastnı. Import a export jsou jednorazove akce, a prestoze modul ma vlastnıvlakno a system udalostı stejny s ostatnımi, po vetsinu doby behu aplikacespı. Jeho chvıle prichazı v momente zaslanı udalosti pozadujıcı import neboexport sceny, po dokoncenı akce ale uz nenı nijak dale vyuzit. Jeho provazanıs jadrem je spıse vyssı, alespon co se aktivace tyce. Jedine, co je treba udelatpro korektnı funkci modulu tohoto typu, je pretızenı dvou metod pro importa export, o vse ostatnı se stara jadro a system implementovany uz v zakladnıforme tohoto modulu.


• virtual wxString GetSupportedExts() constVracı seznam podporovanych formatu v podobe prıpon oddelenychmezerami.

• virtual bool ImportScene(const wxString & fname, SCENE ID sceneID,const wxString & rootName)Nacte soubor a vlozı do sceny hierarchii a data na urcene mısto.

• virtual bool ExportScene(const wxString & fname, const Scene * scene)Ulozı celou scenu do souboru.

Pomocnou metodou poskytovanou modulem je GetInputStream, kteraotevre soubor a vratı proud dat pripraveny ke zpracovanı, v prıpade potrebyautomaticky dekomprimuje archıv (pouze prvnı soubor v archıvu). Infor-mace potrebne k prıstupu a vybudovanı sceny jsou popsane v sekci 3.4.Jelikoz import a export sceny muze byt casove velmi narocny, je vıce nezvhodne pravidelne kontrolovat pozadavek na ukoncenı modulu pomocı Tes-tExit a zrusit akci v prıpade pozitivnıho vysledku. Po uspesnem importu bymel modul poslat oznamenı v podobe udalosti EVT IO SCENE IMPORT DONE.

Pokud jsou pro import sceny pouzity udalosti (bez prımeho prıstupu dosceny), je nutne alokovane instance trıd reprezentujıcı jednotliva data scenyposlat jadru ve forme udalostı. Standardnı postup zpracovanı udalosti s datypopsany v sekci 3.2.2 zahrnuje realokaci vsech dat, coz znamena zdrzenıceleho importu. Proto moduly pro import a export sceny tvorı vyjimku,data sceny poslana v ramci importu se neklonujı. Aby data zustala platna,instance modulu musı byt alokovany po celou dobu behu aplikace (viz sekceo sdılenı pameti modulu v jadru 3.7.8). Klonovanı dat scen je mozne zpetzapnout nastavenım registrovaneho parametru jadra cloneSceneData.

3.7. MODULY 73

RenderModule - zobrazovacı modul

Dalsım modulem s prıstupem ke scene je zobrazovacı modul. Jde omodul, ktery je nejprovazanejsı s jadrem. Navıc hlavnı funkce modulu, vlastnızobrazenı sceny, nebezı ve vlakne modulu, ale ve vlakne hlavnım. Prıstupke GUI a k OpenGL kontextu nenı povolen z jineho nez hlavnıho vlakna,vıce o zobrazovacım systemu je v sekci 3.3. V zobrazovacım modulu je nutnepretızit dve metody, obe jsou volany prımo jadrem s korektne nastavenymOpenGL kontextem.


• virtual void Draw()Provede potrebna volanı funkcı OpenGL a vykreslı scenu do zadnıhobufferu.

• virtual void Deinitialize()Provede dealokaci vsech grafickych dat, pro ktere je treba volanı OpenGLfunkcı a prıstup k OpenGL kontextu.

Pri vykreslovanı je vetsinou potreba pouzıvat rozhranı BVH dane sceny.Strom obalek je vzdy pred volanım Draw metody aktualizovan a nenı pov-oleno aktualizovat jej z modulu. Duvodem je mozna alokace pameti, kteraby byla ztracena pri uvolnenı modulu (viz sekce 3.7.8). Krome zmınenychdvou metod ma zobrazovacı modul navıc registrovany parametr pro identi-fikator pridelene kamery, jejız hodnoty jsou nutne pro nastavenı pohledu nascenu.

Zajımavostı jadra VRUTu je zobrazovanı sceny uz pri jejım nacıtanı.Nenı jednoduche docılit kyzeneho efektu plynuleho narustanı sceny do finalnıpodoby, prinejmensım je treba zajistit spravne vykreslovanı dynamicky semenıcı sceny a upravovat prubezne kameru tak, aby zachytila celou scenu.Napomocne by mohly byt udalosti EVT RENDER CACHE START, kteraznacı probıhajıcı import, a EVT RENDER CACHE STOP znacıcı dokoncenıa zpracovanı importu - scena je ve finalnı podobe.

ManipulatorModule - manipulator

Modul manipulator je opet odvozen od modulu sceny, aby mohl manip-ulovat prirazeny objekt sceny. Krome identifikatoru sceny ma navıc identi-fikator objektu v podobe registrovaneho parametru. Zvlastnostı manipulatoruoproti ostatnım typum modulu je zpracovanı udalostı ze standardnıch vs-tupnıch zarızenı, vıce v sekci 3.7.6. Proto je pro spravne reakce na udalostipotreba krome zakladnı processEvent pretızit dalsı dve metody, jednu proklavesnici a druhou pro mys.



• virtual void processKeyEvent(wxKeyEvent & evt)Zpracovava udalosti klavesnice.

• virtual void processMouseEvent(wxMouseEvent & evt)Zpracovava udalosti mysi.

CameraManipulator - manipulator kameryRozsırenı manipulatoru pro ovladanı kamery, automatizuje nektere funkcetypicke pro kameru. Pridava registrovany parametr s identifikatorem oknapro filtraci vstupnıch udalostı pouze pro dane zobrazovacı okno. Pri zavrenıokna je modul kamery uvolnen na vlastnı zadost. Specialitou je nastavenıkamery pro zobrazenı cele sceny po dokoncenı importu sceny.

KernelModule - modul jadra

Modul jadra je odvozen od zakladnıho modulu a ma zcela vyhradnıpostavenı. Predevsım jde o plny prıstup k jadru a vsem jeho castem, ktery znej dela vhodny nastroj k sofistikovanejsım operacım s aplikacı, mocny, alenebezpecny nastroj. Dalsı specialitou modulu jadra je metoda kernelRun.


• virtual void kernelRun()Metoda je volana v kazde iteraci hlavnı smycky jadra a tedy v hlavnımvlakne aplikace.

Nicmene modul jadra nenı dale nijak s jadrem provazan a zije si svymvlastnım zivotem, pro aktivaci modulu platı stejna pravidla jako pro zakladnımodul.

3.8 Zakladnı moduly

Hlavnı aplikace bez jakychkoliv modulu nema prakticky zadne vyuzitı,proto byly v ramci projektu implementovany zakladnı moduly pro splnenıpozadavku ze zadanı. Zakladnı balık modulu obsahuje modul pro import aexport formatu FHS, zobrazenı sceny a manipulaci s kamerou.

Vlastnı vykreslenı probıha v hlavnım vlakne a modul prımo pristupujek datum sceny. Pro efektivnejsı vykreslenı je vyuzita hierarchie obalek sorezanım pohledovym jehlanem a dva mody zobrazenı geometrie, prvnı pouzıvadisplay list a druhy Vertex Buffer Object. VBO predstavuje efektivnı zpusobprenosu velkych dat na graficky hardware, nicmene v prıpade velkeho mnozstvıobjektu s minimalnım rozsahem trojuhelnıkove sıte muze byt vyhodnejsıpouzitı display listu (vıce o obou zpusobech viz [?]). Modul podporujepruhlednost s razenım pruhlednych objektu podle jejich hloubky pri vykreslovanı,nicmene razenı probıha pouze na urovni celych objektu, ne trojuhelnıku.

Modul poskytuje moznost ovlivnit vystup pomocı nekolika registrovanychparametru. Lze naprıklad zapnout zobrazenı obalek z BVH, drateny model,

3.9. MODULY STUDENTU 75

zapnout/vypnout osvetlenı nebo prepınat mod vykreslenı mezi display listya VBO.

Prubezne zobrazenı importovane sceny

Zajımavostı VRUT je moznost zobrazenı prave probıhajıcıho importusceny. Pro aktivaci je treba zacıt import modulem pracujıcım ve vlastnımvlakne a hned po vytvorenı prazdne sceny spustit modul pro jejı zobrazenı,toho lze docılit lehce napr. posloupnostı prıkazu importscene a renderscenes prıslusnymi argumenty ve skriptu.

Temer vsechna odpovednost za spravne zobrazenı lezı prave na zobra-zovacım modulu a je treba podotknout, ze korektnı zobrazenı behem im-portu predstavuje nemalou zatez navıc. Zobrazovacı modul prijıma udalostio zmenach ve scene a vytvarı display listy nebo VBO pro jednotlive ge-ometrie. Behem importu pribyvajı uzly a menı se jejich parametry, napr.prirazene materialy a geometrie. Zobrazovacı modul musı smazat a znovuvytvorit prıpadny puvodnı display list nebo VBO pro takto zmeneny uzel.

Krome zajımaveho efektu vyobrazenı prubehu nacıtanı umoznuje tatovlastnost normalne pracovat s aplikacı a dokonce i s torzem nacıtane sceny,zatımco importnı modul zpracovava data (vyhodne zvlaste pri nahravanıdat z pomalejsı sıte apod.). Vysledek prımo zavisı na hodnote maximalnıhopoctu zpracovanych udalostı v centralnım spravci udalostı v jadru (viz sekce3.2.1), nızka hodnota znamena prekreslenı po malem poctu zmen a naopak.Pouzity hardware hraje take dulezitou roli, zvlaste co se poctu procesoru(popr. jader procesoru) tyce.

3.9 Moduly studentu

Vzhledem k delsı dobe vyvoje projektu v ramci teto diplomove pracebylo ucineno rozhodnutı vyzkouset VRUT jako spojovacı clanek mezi skoloua spolecnostı Skoda Auto, coz byl jeden z hlavnıch duvodu pro vznik pro-jektu. Spoluprace probıhala ze strany Skoda Auto zadanım nekolika ukolu,ktere mely byt provedeny studenty formou semestralnıch pracı do predmetuAplikace pocıtacove grafiky v podobe samostatnych modulu do VRUT. Bylozadano celkem sest semestralnıch pracı, z nichz pet bylo studenty zvoleno arelativne uspesne zpracovano.

3.9.1 IOVRML (autori Hana Truskova a Michael Smutny)

Importnı a exportnı modul pro graficky format VRML[97] (Virtual Real-ity Modeling Language). Format je svou obsahlostı srovnatelny s formatemFHS, alespon co se popisu sceny tyce, jinak ho znacne prevysuje naprıkladvlastnostmi pro interakci se scenou, jejichz import do VRUT by byl znacne


komplikovany, a zatım nenı podporovan. Omezenı ze strany jadra a reprezen-tace sceny se podobne jako u FHS tyka nekterych typu uzlu - billboard, ruzneurovne detailu a jine specializovane uzly.

3.9.2 (autor Milan Stezka)

Modul typu manipulator kamery by mel zcela nahradit zakladnı modulCameraManipulator (viz sekce ??), prebıra vsechny jeho vlastnosti a doplnujeje o moznosti vyberu z nekolika dalsıch profilu pro ovladanı. Profily kopırujıovladanı existujıcıch grafickych aplikacı (Catia, DeltaGen, VD2, Maya, Cor-tona a dalsı). Omezenı ze strany jadra predstavuje nemoznost jednoduseprımo do zobrazovacıho okna pridat graficke ovladacı prvky do overlayvrstvy, takze musely byt nahrazeny standardnımi prvky z GUI pro reg-istrovane parametry.

3.9.3 Tracking a TrackingManipulator (autor Radek Bien)

Dvojice modulu, ktere jsou typickou ukazkou komunikace mezi modulypomocı udalostı bez nutnosti vyraznejsı vzajmene zavislosti. Ukolem moduluje zavest do VRUT podporu pro sledovacı (trackovacı) zarızenı a umoznitpomocı nej ovladat prvky sceny.

Trackovacı zarızenı je schopno zaznamenavat svou pozici a natocenı vprostoru a informaci v realnem case posılat v podobe sıt’ovych UDP paketu.Modul Tracking je odvozen od zakladnıho typu modulu a nema tedy zadnouspecialnı navaznost na jadro. Jeho ukolem je prıjımat sıt’ove pakety s infor-macı o poloze, aplikovat filtr a v podobe VRUT udalosti ji poslat jadru.Trackovacı system obsluhuje zpravidla vıce trackovacıch zarızenı, ktere jsourozliseny identifikatorem.

Druhy modul TracknigManipulator je standardnım manipulatorem reagujıcımna udalosti vyslane Tracking modulem. Modul obsahuje tabulku, ktera po-dle identifikatoru prirazuje jednotlivym trackovacım zarızenım uzel sceny kmanipulaci.

Komunikace je znazornena na obrazku 3.14, ktery byl prevzat z prezen-tace Radka Biena. Vzhledem k potrebe posılat vetsı mnozstvı dat v kazdeudalosti, byl novy typ tracking udalosti zarazen do seznamu VRUT udalostıv jadru z duvodu korektnı spravy alokovane pameti v udalostech (vıce vizsekce 3.2.2).

3.9.4 CollisionDetection (autor Filip Krystl)

Modul odvozeny od modulu sceny, tedy zatım bez jakekohokoliv hlubsıhopropojenı s jadrem, ma za ukol sledovat transformace vybranych uzlu scenys geometriı a testovat jejich vzajemnou polohu. V prıpade kolize je vyslana

3.9. MODULY STUDENTU 77

Obrazek 3.14: Ukazka z prezentace modulu Tracking Radka Biena

udalost s blizsımi informacemi o kolidujıcıch objektech. Modul umı navıc for-mou udalosti provest zpetnou transformaci, aby objekty zustaly v nekolidujıcıpoloze.

Informace o kolizi zaslana v udalosti vyzaduje opet specialnı strukturu,kterou musı znat jadro pro korektnı spravu alokovane pameti stejne jako uTracking modulu (vıce viz sekce 3.2.2).

Omezenı ze strany jadra vyvstava v prıpade zpetne transformace donekolidujıcı polohy. Modul odchytava udalosti o transformacıch, ktere uzbyly ve scene aplikovany, a provedenı zpetne transformace prichazı nutneaz nasledne. Dusledkem je obcasne vykreslenı objektu v kolidujıcı poloze.Resenı vyzaduje obecne vetsı moznosti synchronizace udalostı navzajemspolu s vıce urovnemi priorit, prıpadne moznost udalosti vetovat.

Dalsım omezenım je zatım chybejıcı podpora pro vıce typu BVH postavenychnad scenou. CollisionDetection vyzaduje jiny zpusob delenı sceny a vytvarıobalky na urovni trojuhelnıku a ne celych objektu. Dıky sledovanı zmen vescene nenı velky problem postavit vlastnı BVH prımo v modulu, ale taktopostaveny BVH nenı prıstupny odjinud.

3.9.5 Scripting (autori Jakub Zelenka a Vojtech Sedlacek)

Specialnı modul neodpovıdajıcı zadnemu konkretnımu dostupnemu typu,presto vyzaduje znacne propojenı s jadrem, proto je odvozen od modulu


jadra (viz sekce 3.7.11). Ukolem modulu je poskytnout uzivateli znacne vetsımoznosti pri psanı skriptu pro VRUT a doplnit tak nebo zcela nahraditstavajıcı prıkazovou konzoli. Pro skriptovanı byl zvolen Java Script jakoztodostatecne obecny a rozsıreny programovacı jazyk.

Modul vyuzıva jak vlastnı, tak hlavnı vlakno pro svoji cinnost a umoznujetım do jiste mıry nezavisly chod skriptu. Jednım z hlavnıch duvodu prosofistikovanejsı skriptovacı jazyk byla podpora animacı, jednoduchy animacnıskript by mohl vypadat naprıklad takto:

//Vypıse vsechny uzly s geometriıvar nodes = scene.GetNodeIDs();for (var i = 0; i < nodes.length; i++){

var node = scene.GetNode(nodes[i]);if (node && node.GetType() == Node.GEOMETRY)

log("Geometry Node: " + node.GetID())}

nodeID = 8;

var m = new Matrix( 1, 0, 0, 0,0, 1, 0, 0,0, 0, 1, 0,0, 0, 0, 1 );

scene.SetTransformation(nodeID, m)

log("Start animace");var steps = 120;var angle = 360 / steps;var trans = -0.5;var scale = 0.99;for (var i = 0, tAbs = 0; i < steps; i++, tAbs+=trans){

if (i == steps / 2){

trans = -trans;scale = 2 - scale;

}scene.Translate(nodeID, trans, 0, trans);scene.Rotate(nodeID, angle, 1, 0, 0);scene.Scale(nodeID, scale, scale, scale)

sleep(30);

3.10. STRUCNY PREHLED MODULU 79

}log("Konec animace");

Pro vlastnı zpracovanı skriptu je pouzit nastroj SpiderMonkey, ktery sicevytvarı zavislost modulu na dalsıch knihovnach, ale vyrazne zjednodusuje aautomatizuje nektere kroky interpretace skriptu. Modul je zatım v experi-mentalnı fazi a bude vyzadovat jeste nekolik modifikacı, nejspıse i na stranejadra. V soucasne dobe poskytuje funkce pro vetsinu operacı nad scenou asouvisejıcımi objekty.

3.10 Strucny prehled modulu

Podrobna dokumentace k modulum je prozatım v samostatnych sou-borech.

3.10.1 IO moduly

VRUT podporuje ctenı z archivu podporovanych wxWidgets, ve verzi2.8.10 jsou to ZIP a GZ. Ukladanı do archivu nenı podporovane. Vsechnymoduly ukladajı pouze data, textury nesjou preulozeny.IOFHS - Format: FHS - aplikace VD2 od VRCOMIOCSB - Format: CSB - aplikace CosmoPlayer od SGI, DeltaGen a RTT adalsıIOSTL - Format: STL (ascii i binarnı)IOOBJ - Format: OBJIOVRML - Format: VRML 2.0 (tj. prıpona WRL, i komprimovane soubory)IOAC3D - Formaty: AC, ACC - hra TORCSIORDF - Format: RDF - aplikace AdamsIODOF - Format: DOF - hra RacerIOIMAGE - Formaty: BMP, PNG, JPG, JPEG, GIF, PCX, PNM, TIF,TIFF, TGA, XPM, ICO, CUR, ANI, RGB, DDS (vsechny typy textur pod-porovane VRUTem)

3.10.2 Podpora HW

Tracking - Podpora zarızenı od firmy A.R.T.C3Dconnexion - Vyzaduje ovladac od firmy 3Dconnexion, vsechna pod-porovana zarızenı danym ovladacem (SpaceMouse, SpaceExplorer,SpacePilot,...)Cluster - Podpora vıcesegmentove a stereo projekce. (Vyzaduje multicast.)CarHW - Podpora specialnıho HW pro snımanı volantu a pedalu.

3.10.3 Uprava sceny

Optimize - Ruzne optimalizace grafu sceny, materialu a geometriı.MaterialEditor - Editace materialu.


MaterialAssign - Pouzitı knihoven materialu.SeatSticher - Vytvarenı svu.Terrain - Vytvarenı a uprava geometrie terenu.

3.10.4 Interakce

Scripting - Podpora JavaScriptu.CollisionDetecton - Vypocet kolizı.TrackingManipulator - Navazanı vystupu z modulu Tracking a C3Dconnexionna uzly ve scene.SimulaceJizdy - Simulace rızenı vozu.

3.10.5 Renderery

RenderGL - Zakladnı OpenGL renderer.CHcRenderer - OpenGL renderer pouzıvajı HW dotazy zastınenı a metoduCHC.RayTracer - Podpora raytracingu.RayTracerGL - Kombinace OpenGL a raytracingu.Shadow maps - Renderer generujıcı stınove mapy.ssaoRenderer - Renderer pouzıvajıcı stıny.ssdoRenderer - Renderer pouzıvajıcı stıny.CombineRenderer - renderer poskytujıcı obecnou podporu pro vıcepruchodoverenderovanı.RenderOwnThread - experimentalnı renderer s renderovanım ve vlastnımvlakne.

3.10.6 Literatura

[3] Dokumetnace ke knihovnam OpenGL. http://www.opengl.org/dokumentation/.[5] OpenSceneGraph. http://www.openscenegraph.org.[6] OpenSG. http://www.opensg.org.[7] Princip Copy On Write. http://en.wikipedia.org/wiki/Copy-on-write.[8] Prehled spravy udalostı ve wxWidgest. http://docs.wxwidgets.org/trunk/overview eventhandling.html[11] wxWidgets. http://www.wxWidgets.org/.[12] F. Carucci. Inside geometry instancing. In GPU Gems 2, pages 47-68.Addison-Wesley Professional, 2005.[13] Daniel Sykora, Josef Jelınek. Efficient view frustum culling. In CESCG2002, 2002.[14] W. Engel. Programming Vertex and Pixel Shaders. Charles River Me-dia, 1st edition, 2004.[15] J. Zara, B. Benes, J. Sochor, P. Felkel. Modernı pocıtacova grafika.Computer Press s.r.o, Brno, 2nd edition, 2005. In Czech.[16] D. Picco. Frustum Culling, 2003. http://www.flipcode.com/articles/article frustumculling.shtml.[17] D. B. Tom McReynolds. Advanced Graphics Programming Using OpenGL.

3.10. STRUCNY PREHLED MODULU 81

Elsevier, 2005.[18] Ulf Assarsson, Thomas Moeller. Optimized view frustum culling algo-rithms for bounding boxes. In Journal of Graphics Tools, volume 5, pages9-22. A. K. Peters, Ltd, 2000.[19] V. Havran, R. Herzog, H.-P. Seidel. On the fast construction of spatialhierarchies for ray tracing. In IEEE Symposium on Interactive Ray Tracing,pages 71-80, 2006.


Kapitola 4

Seznam vnitrnıch udalostıVRUT

Aktualnı popis vsech zprav je v souboru events.h.

• EVT ALLSpecialnı typ udalosti, s jejız prihlasenım k odberu bude odberateldostavat vsechny typy udalostı

• EVT EXITZadost k ukoncenı hlavnı smycky modulu nebo k ukoncenı aplikace,kdyz je zaslana jadru

• EVT LOGVypsat zpravu do logu, na vyber je nekolik urovnı od informativnı pofatalnı chybu

• EVT LOG SETNastavenı spravce log zprav (pro moduly)

• EVT LOG LEVEL SETNastavenı urovne logovanı, nizsı urovne budou ignorovany

• EVT PARAM SET DOZmenit hodnotu registrovaneho parametru

• EVT PARAM SETOznamenı, ze registrovany parametr byl zmenen

• EVT PARAM REGISTERZaregistrovat parametr

• EVT PARAM UNREGISTERZrusit registraci parametru

83

84 KAPITOLA 4. SEZNAM VNITRNICH UDALOSTI VRUT

• EVT PARAM GUIREGISTERZaregistrovat a zobrazit parametr v GUI

• EVT PARAM GUIUNREGISTERSkryt skupinu parametru (vzdy vsechny parametry daneho vlastnıka)v GUI

• EVT INPUT MOUSEPouze pro ucely prihlasenı k odberu udalostı spojenych se vstupem zmysi(odberatelum se pak posılajı wxMouseEvent)

• EVT INPUT KEYPouze pro ucely prihlasenı k odberu udalostı spojenych se vstupemz klavesnice (odberatelum se pak posılajı wxKeyEvent)

• EVT INPUT TRACKINGUdalost s udaji o vstupu z trackovacıho vstupnıho zarızenı

• EVT MODULE PREFERZaradit modul na prvnı pozici v seznamu preferovanych

• EVT MODULE FORBIDZakazat dalsı vytvarenı modulu

• EVT MODULE RELEASEUvolnit modul (ExtraLong obsahuje ID modulu ke smazanı, zpravidlato byva zaroven odesılatel)

• EVT MODULE RUNVytvorit instanci modulu a spustit jeho vlakno, modul si dale zijevlastnım zivotem

• EVT SCENE RAY PICKVyber objektu/bodu ve scene

• EVT SCENE COLLISIONOznamenı, ze doslo ke kolizi objektu ve scene

• EVT SCENE IMAGE ADDNahrat texturu ze souboru

• EVT SCENE IMAGE ADDEDOznamenı, ze textura byla nahrana ze souboru

• EVT SCENE MATERIAL ADDPridat material do sceny

85

• EVT SCENE MATERIAL ADDEDOznamenı, ze material byl pridan do sceny nebo byl zmenen

• EVT SCENE GEOMETRY ADDPridat geometrii do sceny

• EVT SCENE GEOMETRY ADDEDOznamenı, ze geometrie byla pridana do sceny nebo byla zmenena

• EVT SCENE NODE COPYZkopırovat uzel sceny a vsechny potomky z jednoho mısta sceny najine (kopırovane uzly jsou prejmenovany)

• EVT SCENE NODE MOVEPresunout uzel sceny a vsechny potomky z jednoho mısta grafu scenyna jine

• EVT SCENE NODE MOVEDOznamenı, ze uzel sceny a vsichni jeho potomci byly presunuti z jed-noho mısta grafu sceny na jine

• EVT SCENE NODE INSERTPridat uzel do sceny pod rodice (rodic muze byt definovan dvemazpusoby)

• EVT SCENE NODE INSERTEDOznamenı, ze uzel byl pridan do sceny

• EVT SCENE NODE REMOVEOdebrat uzel ze sceny a smazat (uzel muze byt definovan dvemazpusoby)

• EVT SCENE NODE REMOVEDOznamenı, ze uzel byl odebran ze sceny

• EVT SCENE NODE NAME SETZmenit jmeno uzlu (uzel muze byt definovan dvema zpusoby)

• EVT SCENE NODE NAME CHANGEDOznamenı, ze uzel byl prejmenovan

• EVT SCENE NODE TRANSFORM SETNastavit (prepsat) transformacnı matici uzlu (uzel muze byt definovandvema zpusoby)

• EVT SCENE NODE TRANSFORMTransformovat uzel (vynasobit se stavajıcı maticı) (uzel muze byt defi-novan dvema zpusoby)


• EVT SCENE NODE TRANSLATE ABSNastavit (prepsat) translaci uzlu (uzel muze byt definovan dvemazpusoby)

• EVT SCENE NODE TRANSFORMEDOznamenı, ze transformace uzlu byla zmenena

• EVT SCENE NODE GEOMETRY SETPriradit uzlu geometrii, geometrie musı byt predtım pridana do stejnesceny jako uzel (uzel muze byt definovan dvema zpusoby)

• EVT SCENE NODE GEOMETRY CHANGEDOznamenı, ze uzlu byla prirazena geometrie nebo byla zmenena

• EVT SCENE NODE MATERIAL SETPriradit uzlu material, material musı byt predtım pridan do stejnesceny jako uzel (uzel muze byt definovan dvema zpusoby)

• EVT SCENE NODE MATERIAL CHANGEDOznamenı, ze uzlu byl prirazen material nebo byl zmenen

• EVT SCENE NODE LIGHT SETPriradit uzlu svetlo (uzel muze byt definovan dvema zpusoby)

• EVT SCENE NODE LIGHT CHANGEDOznamenı, ze uzlu bylo prirazeno svetlo nebo bylo zmeneno

• EVT SCENE CAM FITNastavit kameru, aby zabrala celou scenu (pouze presun kamery bezzmeny natocenı)

• EVT SCENE CAM FIT NEAR FARNemenı transformaci kamery, pouze hodnoty blızke a vzdalene rovinyorezanı tak, aby byla obsazena cela scena

• EVT SCENE CAM RESETVIEWNastavit kameru, aby zabrala celou scenu (presun kamery a otocenı dopuvodnı polohy)

• EVT SCENE CAM PROJECTION SETNastavit parametry kamery (kamera muze byt definovana dvema zpusoby)

• EVT SCENE CAM PROJECTION CHANGEDOznamenı, ze projekcnı matice kamery se zmenila

• EVT SCENE GRAPHVIZUlozit GraphViz soubory s grafy sceny a BVH (nutna GraphViz pod-pora)

87

• EVT SCENE DUMPUlozit textovy soubor s vypisem sceny

• EVT SCENE BVH UPDATEDoplnit BVH o nove vlozene uzly sceny s geometriı. Nemusı nutneaktualizovat obalky jednotlivych uzlu BVH

• EVT SCENE BVH UPDATEDOznamenı, ze BVH bylo doplneno o nove vlozene uzly sceny s ge-ometriı. Udalost je zaslana pouze jako odpoved’ na EVT SCENE BVH UPDATE

• EVT SCENE DUMPUlozit textovy soubor s vypisem sceny

• EVT IO SCENE IMPORTNahrat scenu ze souboru

• EVT IO SCENE IMPORT DOZprava pro IOModule, aby zacal zpracovavat soubor (NEPOUZIVAT,pro import je urcena udalost EVT IO SCENE IMPORT)

• EVT IO SCENE EXPORTUlozit scenu do souboru

• EVT IO SCENE IMPORT DONEOznamenı, ze import sceny byl dokoncen

• EVT RENDER SCENEZobrazit scenu v novem okne

• EVT RENDER WIN CREATEDOznamenı, ze zobrazovacı okno bylo vytvoreno

• EVT RENDER WIN CLOSEDOznamenı, ze zobrazovacı okno bylo zavreno

• EVT RENDER UPDATEPrekreslit obsah zobrazovacıho okna

• EVT RENDER CACHE STARTZacıt zpracovavat data sceny v zobrazovacım modulu pri nacıtanı azobrazovanı zaroven

• EVT RENDER CACHE STOPZastavit zpracovanı dat sceny v zobrazovacım modulu pri nacıtanı azobrazovanı zaroven

• EVT RENDER FRAMERATENovy udaj o snımcıch za vterinu


• EVT RENDER FULLSCREEN TOGGLEPrepnout zobrazenı zobrazovacıho okna pres celou obrazovku (zmenastavu)

• EVT RENDER FULLSCREEN SETZapnout/vypnout zobrazenı zobrazovacıho okna pres celou obrazovku

• EVT GUI PANE SHOWSkryt nebo zobrazit panel v hlavnım okne

• EVT GUI PARAM SHOWSkryt celou zalozku s parametry daneho vlastnıka nebo zobrazit parametrv GUI, pokud byl registrovan

Kapitola 5

Podpora Unicode

VRUT samotny podporuje plne Unicode. Problem nastava na strane IOmodulu, vetsina formatu podporuje pouze ASCII, proto je doporucene pronazvy geometriı, materialu, textur a prıpadnych externıch souboru pouzıvatpouze ASCII znaky.

89

90 KAPITOLA 5. PODPORA UNICODE

Kapitola 6

Instalace wxWidgets

6.1 Microsoft Windows

• Stahnete si poslednı verzi wxMSW ze http://www.wxwidgets.org/downloads/

• Nainstalujte

• Nastavte promennou prostredı WXWIN na cestu k wxWidgets, kamjste je nainstalovali, napr. C:/wxWidgets-2.8.9 viz obr. 6.1, 6.2 a 6.3

Obrazek 6.1: Nastavenı promenne prostredı

91

92 KAPITOLA 6. INSTALACE WXWIDGETS

• Nynı je treba zmenit nektere vlastnosti pred kompilacı wxWidgets

• Editujte $WXWIN/include/wx/msw/setup.h a nastavte nasledujıcı kon-stanty na uvedene hodnoty:

– #define WXWIN COMPATIBILITY 2 6 0

– #define wxUSE UNICODE 1

– #define wxUSE GLCANVAS 1

– #define wxUSE GRID 1

– #define wxUSE STD IOSTREAM 1 - pokud chcete pri testovanıvysledek presmerovat do logu

– popr. dalsı podle vlastnı potreby

• Otevrete projekt $WXWIN/build/msw/wx.dsw v MS Visual Studio

• Proved’te konverzi v prıpade pouzitı novejsı verze Visual Studio

• Pokud potrebujete podporu komprese Deflate pro TIFF, pridejte ZIP SUPPORTdo Preprocessor Definitions u projektu wxtiff (platı pro verzi 2.8.10, vnovejsıch jiz muze byt problem opraven)

• Pokud budete kompilovat VRUT v 64bit, proved’te nasledujıcı:

– zkopırujte cely adresar do adresare se stejnym jmenem, pouze nakonci pridejte ” 64bit”

– z menu zvolte Build / Configuration Manager

– z Active solution platform vyberte polozku <New...>

– vytvorte x64 platformu podle obr. 6.4

– zavrete Configuration Manager

• Z menu zvolte Build/Batch Build

• Serad’te konfigurace podle Solution Config

• Vyberte vsechny Unicode Debug|Win32 (x64) a Unicode Release|Win32(x64)

• Build

• V prıpade x64 se mohou objevit varovanı typovych konverzı

• Pokud nastanou problemy, navstivte http://wiki.wxwidgets.org/Microsoft Visual C++ Guide

• Pred kompilacı VRUTu je treba restart Visual Studia (prıpadne kon-zole) pro aktivaci WXWIN promenne

6.2. LINUX 93

6.2 Linux

Vetsina distribucı ma wxWidgets v repozitari, prıpadne pro ni existujebalık. Pokud chcete vytvorit knihovny ze zdrojovych kodu (napr. kvuli jinekonfiguraci), postupujte takto:

• Stahnete poslednı verzi wxGTK z http://www.wxwidgets.org/downloads/

• Extrahujte obsah archıvu do libovolneho adresare

• V nem vytvorte adresare pro nastavenı jednotlivych konfiguracı

cd /path/to/wxGTKmkdir buildgtkdmkdir buildgtk

• Prejdete do adresare s debug konfiguracı a vytvorte skript builddbg.sh

cd buildgtkdvim builddbg.sh

• Do skriptu vlozte (prıkaz do jednoho radku):

#!/bin/sh../configure --enable-gui --enable-optimise --enable-debug--enable-debug_flag --enable-debug_info --enable-debug_gdb--enable-mem_tracing --enable-unicode --with-gtk --with-opengl--enable-compat26 && echo "Will ’make’ in 30 seconds" && sleep 30&& make && make install && make clean

• Pro kompilaci budete potrebovat balıcky (nazvy se mohou lisit podledistribuce)

– build-essential

– libgtk2.0-dev

– freeglut3-dev

• Spust’te skript s administratorskymi pravy

chmod u+x builddbg.shsudo ./builddbg.sh


• Prejdete do adresare s release konfiguracı a vytvorte skript build.sh

cd ../buildgtkvim build.sh

• Do skriptu vlozte (prıkaz do jednoho radku):

#!/bin/sh../configure --enable-gui --enable-optimise --enable-unicode--with-gtk --with-opengl && echo "Will ’make’ in 30 seconds"&& sleep 30 && make&& make install && make clean

• Spust’te skript s administratorskymi pravy

chmod u+x build.shsudo ./build.sh

• Overte kompilaci

wx-config --version#mel by ukazat verzi, kterou jste stahli a zkompilovaliwx-config --list#mel by vypsat release jako default verzi a debug jako alternativu

• Pro jistotu aktualizujte vazbu na dynamicke knihovny

sudo ldconfig

Standardne se pro kompilator pouzıva jako argument ‘wx-config –cxxflags‘,pro linker ‘wx-config –libs‘. V prıpade problemu navstivte http://wiki.wxwidgets.org/Compiling and getting started.

6.2. LINUX 95




6.2. LINUX 97

Obrazek 6.4: Vytvorenı 64bit projektu wxWidgets


Kapitola 7

Zdrojove soubory VRUT

• Navstivte http://subversion.tigris.org/

– Windows - stahnete binarky (napr. SlikSVN k dispozici v 32bit i64bit verzi - pozn. pri instalaci zvolte kompletnı instalaci)

– Linux - apt-get install subversion pro Debian systemy nebo podlepokynu na webu

Moznosti checkoutu:

• Prıkazem z konzole

svn co http://cggcvs.felk.cvut.cz/svn/vrut

• SmartSVN klient s GUI

– stahnete a nainstalujte SmartSVN (zdarma pro Windows i Linux)z http://www.syntevo.com/smartsvn/download.html

– nastavte cestu k SVN binarkam (jen Windows)

– pokud jste vyzvani, zvolte, ze uz mate repozitare nastaveny

– pokud nenabıdne hned po startu, zvolte z menu Project / CheckOut...

– vyberte Manage, Add a pridejte profil podle obr. 7.1

– nebo zadejte prımo URL http://cggcvs.felk.cvut.cz/svn/vrut

– v dalsı zalozce vyberte trunk z hlavnı vetve viz obr. 7.2

– dale vyberte cılovy adresar, ulozte projekt a proved’te checkout

99

100 KAPITOLA 7. ZDROJOVE SOUBORY VRUT

7.1 Dokumentace

Soucastı repozitare je konfiguracnı soubor Doxyfile, dıky kteremu lze vy-generovat aktualnı dokumentaci v podobe HTML stranek pomocı programuDoxygen (k dispozici pro Windows i Linux).

7.1. DOKUMENTACE 101

Obrazek 7.1: Nastavenı SVN profilu ve SmartSVN

102 KAPITOLA 7. ZDROJOVE SOUBORY VRUT

Obrazek 7.2: Nastavenı SVN profilu ve SmartSVN

Kapitola 8

Novy modul

Nejdrıve je treba zvolit si typ modulu, ktery je nejvhodnejsı pro novymodul. Repozitar obsahuje nekolik sablon pro vetsinu typu:

• general - zakladnı typ modulu

• scene - modul sceny

• io - modul pro import a export

• render - zobrazovacı modul

• manip - typ manipulator

8.1 Prıprava

• Zvolte si typ modulu

• Vytvorte novy adresar v adresari urcenem pro moduly, zvolte jmenoshodne s nazvem modulu

• Prekopırujte obsah adresare s prıslusnou sablonou do vytvorenehoadresare

• Prejmenujte vsechny soubory na nazev modulu

• Editujte vsechny soubory a nahrad’te vsechny vyskyty nazvu sablony(napr. general) nazvem modulu

Pokud jste dodrzeli adresarovou strukturu z repozitare, vas modul bymel jıt zkompilovat a byt plne funkcnı pri pouzitı ve VRUTu. Svuj novyprojekt pridejte do hlavnı solution (v prıpade Visual Studio) a workspace(pro CodeBlocks), abyste mohli debugovat celou aplikaci a aby se vas novymodul stal soucastı VRUTu.

103

104 KAPITOLA 8. NOVY MODUL

8.2 Doporucenı

• Pouzıvejte stejny format hlavicky pro vsechny zdrojove soubory podlesablony modulu.

• Nepouzıvejte mad’arskou notaci, pojmenovavejte stylem strıdanı malycha velkych znaku, napr. isSceneInitialized.

• Naopak nazvy vsech souboru a adresaru delejte pouze malymi pısmeny.

• Verejne metody trıd by mely zacınat velkym pısmenem a privatnı nebochranene malym.

• Verejne metody pouzıvejte pouze, pokud je to nutne. U modulu bystemeli mıt prakticky vsechny nove metody chranene, protoze nemohoubyt zadnym zpusobem volany odjinud.

• Nezapomınejte na const modifikatory a predavanı promennych od-kazem.

• Vzdy kontrolujte navratove hodnoty a logujte chybove hlasky.

• Pred kazdym commitem do SVN proved’te update repozitare a zkon-trolujte, ktere soubory budou modifikovany.

• Nemodifikujte zadne soubory hlavnı aplikace, pokud nemate vyslovnesvolenı.

Piste komentare k deklaracım kazde promenne a metode, v anglickemjazyce a formatu pro Doxygen alespon v zakladnı forme:

///Check \c foo, do something with \c foo1 and \c foo2///\param[in] foo Input param///\param[in,out] foo1 Input param and filled with something///\param[out] foo2 Filled with something///\return \c true if successful, \c false otherwisebool IsOk(int foo, int * foo1, int * foo2);

Kapitola 9

Uzivatelska prırucka

Antonın Mısek, [email protected]. unora 2010

9.1 Instalace a spustenı VRUTu

VRUT nenı potreba instalovat.

9.1.1 Struktura VRUTu

vrut.exe - hlavnı aplikaceautoexec.cfg - konfiguracnı skript spusteny pri startumodules/ - slozka s moduly, prımo v nı jsou nektere modulymodules/io - slozka s moduly pro export a importmodules/manip - slozka s moduly pro ovladanı kamerymodules/render - slozka s moduly pro renderingdoc - slozka s dokumentacı

9.1.2 Spustenı aplikace

Pri spustenı aplikace probehnou nasledujıcı kroky:Provede se skript autoexec.cfg v adresari VRUTu.Zpracujı se parametry prıkazove radky nastavujıcı promenne VRUTu.Zpracujı se ostatnı parametry prıkazove radky (v poradı uvedenem na prıkazoveradce), predpoklada se, ze se jedna o cesty k souborum. Pokud ma souborprıponu CFG je povazovan za skript, jinak je pouzıvan za datovy soubor aVRUT se jej pokusı nacıst a zobrazit.

105

106 KAPITOLA 9. UZIVATELSKA PRIRUCKA

Kapitola 10

Stereoskopie

Bc. Michal Lukac, [email protected]

16.12.2009

10.1 Zadanı ulohy

Proved’te rozbor definice kamer pro stereskopicke zobrazovanı na vıceprojekcnıch sten v prostredı CAVE. Implementujte vypocet pohledovycha projekcnıch matic techto kamer pro system VRUT. Implementace budevyuzıvat jednoduchy geometricky model projekcnıch sten prostredı CAVE.

10.2 Uvod

10.2.1 Motivace a popis problemu

V prumyslove praxi se virtualnı realita casto provozuje na stereoskopickemHW. V systemu VRUT vsak tato funkcnost doposud chybela a bylo ji trebadoplnit. Konkretne slo o podporu pro zobrazovacı techniky vyuzıvane veSkoda Auto, tedy CAVE a PowerWall. Provoz na techto zarızenıch vyzadujepodporu stereoskopickeho zobrazovanı, podporu synchronnıho zobrazovanına vıce zobrazovacıch plochach a tracking perspektivy.

V souladu s pozadavky zadavatele byla tato funkcnost implementovanaprımo do jadra. Duvodem k tomuto postupu bylo, ze zejmena pouzitı nes-tandardnıch projekcnıch matic nemelo v jadru systemu podporu a take to,ze byl ze strany zadavatele kladen duraz na synchronnost zobrazovanı, kterase (dıky modulu Cluster) v jadre zajistı snaz nez v modulu.

Dle instrukcı zadavatele byla implementace samotneho zobrazovanı nadramec teto prace.

107

108 KAPITOLA 10. STEREOSKOPIE

10.2.2 Souvisejıcı prace

Pri zpracovanı teto ulohy jsem vychazel z obecneho postupu pro track-ovanou stereoskopii tak, jak jej popsal ve sve disertacnı praci ing. MichalKoutek pro ucely zarızenı Responsive Workbench [2]. Jadrem prace bylazejmena implementace tohoto postupu.

10.3 Navrh resenı

Jak jiz bylo receno, tato uloha obsahovala tri vyznamne casti. Prvnı znich bylo vytvorenı podpory pro stereoskopicke zobrazovanı implementacıobecne perspektivy. Druhou byla implementace kamerovych konfiguracı jakpro ucely podpory stereoskopie, tak pro ucely synchronizace perspektivy naPowerwall. Poslednı castı pak bylo vytvorenı aparatu pro upravu perspektivypodle trackingu.

10.3.1 Obecna perspektiva

V systemu VRUT byly projekcnı matice reseny tak, ze byly ulozenyprımo v grafu sceny v uzlu kamery. Tento postup pro vetsinu ostatnıchaplikacı dava smysl, ale pro stereoskopicke zobrazovanı bylo problematickezejmena to, ze projekcnı matici nebylo mozne prımo nastavit a bylo treba kjejı uprave vyuzıvat funkci sceny, ktera vytvorı FOV perspektivu.

Abychom dosahli stereoskopie, musıme ale uvazit to, ze i kdyz je po-zorovatel prımo na stredove ose platna, jeho oci jsou posunute mırne dostran. Prostym posunutım pocatku kamery adekvatne do stran by bylomozne dosahnout iluze stereoskopie, avsak toto by byla pouze iluze. Pokud sitotiz predstavıme, jak vypadajı pohledove objemy pro obe oci 10.1, vidıme,ze uz se nejedna o osove soumerne jehlany, ktere by bylo mozne zadat pohle-dovym uhlem.

Prace ing. Koutka [2] podava navod, jak vytvorit perspektivu pro po-zorovacı bod v libovolne poloze vuci zobrazovacımu zarızenı, jejım zaklademje vsak obecne perspektivnı matice slozena s translacı. Implementace obecneperspektivnı matice je popsana naprıklad v manualu OpenGL [1] pod funkcıglFrustum.

Funkcnost kamery jsem tedy rozsıril o novy typ perspektivy, ktera sezadava jednak fyzickymi rozmery zobrazovacıho zarızenı, druhak pak pozicıpozorovatele (ci presneji, konkretnıho oka pozorovatele) v lokalnıch souradnicıchzobrazovacıho zarızenı, kde souradny system je pravotocivy a definovany po-dle konvencı OpenGL.

10.3.2 Kamerove konfigurace

Podle pranı zadavatele byl rozsah prace mırne rozsıren tak, aby mohlVRUT podporovat i praci na zarızenı Powerwall. Toto zarızenı se sklada

10.3. NAVRH RESENI 109

Obrazek 10.1: 2D nacrt pohledovych objemu pri stereoskopii.

ze ctyr platen, ktera na sebe navazujı a tvorı tak jednu velkou zobrazovacıplochu, pricemz je treba, aby na sebe obrazy na jednotlivych platnech presnenavazovaly. Zaroven musı byt zobrazovanı synchronnı, tj. je treba, aby secely obraz transformoval najednou.

Resenım tohoto problemu je tzv. technika letajicıho koberce. Do grafusceny v nı vkladame pro kazde zobrazovacı zarızenı, ktere je soucastı konfigu-race, samostatnou kameru pod spolecneho rodice 10.2. Manipulace kamerouse pak dosahuje transformacı prave toho spolecneho rodice. Pohledove mat-ice jednotlivych kamer jsou pak jednoznacne dany v nejakem lokalnım souradnicovemsystemu. Navaznosti obrazu dosahujeme tak, ze pouzijeme obecnou perspek-tivu, v nız majı vsechny kamery spolecnou pozici pozorovatele (v souradnicıchkonfigurace – je treba ji transformovat lokalnı pohledovou transformacı nezji pouzijeme pro aktualizaci perspektivy).

Pohledova matice kamery je zadana fyzickou pozicı zobrazovacıho zarızenıve zvolenem souradnicovem systemu. Pro ucely perspektivy je dulezite, abypozice pozorovatele byla definovana v tomtez systemu souradnic – pohle-dova matice pak slouzı jednak pro finalnı transformaci obrazu do souradniczarızenı, druhak pak pro transformaci pozice pozorovatele do lokalnıch souradnic,ktere jsou predany pro vytvorenı projekcnı matice.

Technika letajıcıho koberce je velmi flexibilnı a teoreticky umoznujedefinovat zcela libovolnou konfiguraci (tj. libovolne orientovana a libovolneumıstena zobrazovacı zarızenı) slozenou z obdelnıkovych platen.

10.3.3 Tracking perspektivy

Za ucelem zachovanı imerse je nutne, aby iluze stereoskopie zustavalaperfektnı i tehdy, pokud pozorovatel opustı svou pocatecnı pozici. Pouzıvajıse proto systemy pro tracking, kde se sleduje poloha a orientace hlavy po-zorovatele uvnitr zobrazovacı konfigurace, a prıslusne se upravujı projekcnı


Obrazek 10.2: Ilustrace techniky letajıcıho koberce.

matice. Po implementaci kamerovych konfiguracı je toto vlastne trivialnıuloha – stacı pouze umet za behu upravovat pohledovy bod pro vsechnykamery konfigurace.

10.4 Implementace

Implementace zahrnovala predevsım implementaci noveho typu perspek-tivy do trıdy Camera, prıslusnych nastavujıcıch metod do trıdy Scene, im-plementaci techniky letajıcıho koberce do trıdy Scene a vytvorenı novychudalostı a jejıch zpracovanı.

10.4.1 Trıda Camera

Trıda Camera nove obsahuje promennou indikujıcı typ projekce (hod-noty jsou zadavany dle enum Camera::PROJECTION TYPE). Lze nastavitbud’ klasickou centrovanou (FOV) perspektivu, nebo perspektivu obecnou.Nastavenı obecne metody probıha skrz trıdu Scene metodou SetPerspec-tiveParams, ktera se chova podobne jako nastavenı klasicke perspektivy.Dulezitym rozdılem ale je, ze vyska a sırka nereprezentujı rozmery view-portu, ale fyzicke rozmery zobrazovacıho zarızenı.

Zaroven se u kamery nastavuje indikace, ktere oko kamera reprezentuje(zadano dle enum Camera::EYE TYPE). Tuto hodnotu vyuzıva zejmenatrıda Scene. Krome leveho a praveho oka je mozne nastavit neutralnı, strednıoko.

10.5. MANUAL 111

10.4.2 Trıda Scene

Ve trıde Scene byly pridany metody pro praci s novym typem per-spektivy. Jedna se jednak o kompletnı nastavovanı (metodou SetPerspec-tiveParams), druhak pak ciste o update pozice pozorovatele (SetPerspec-tiveOffset). Metody jsou soucastı verejneho rozhranı, ale dıky kamerovymkonfiguracım by v praxi nemelo byt nutne je volat prımo.

Do souboru scene.h byla zaroven pridana trıda FlyingCarpet, ktera reprezen-tuje ”letajıcı koberec“, tj. konfiguraci kamer. Seznam kobercu ve scene jeveden v konkretnı instanci sceny a vytvarı se tak, ze se pro danou scenunastavı vybrany uzel jako koren teto konfigurace. Vsichni jeho bezprostrednıpotomci, kterı jsou zaroven kamerami, jsou pak povazovani za soucast kon-figurace a prıslusne se aktualizujı jejich projekcnı matice.

Letajıcı koberec muze byt bud’ trackovany nebo netrackovany. Pokud jetrackovany, je navazan na konkretnı objekt trackingu, pokud ne, je pozicepozorovatele pevne dana (ale lze ji zmenit udalostı). Rozchod ocı je ulozenv instanci konfigurace a je spolecny pro vsechny jejı kamery.

U trackovaneho letajıcıho koberce se krome pozice pozorovatele odecıtatake jeho orientace, aby bylo mozne vypocıtat, kterym smerem se posouvapohledovy pocatek pro leve, resp. prave oko. U netrackovanych kobercu seto resı tak, ze se oci posouvajı vzdy podle roviny platna.

10.4.3 Ruzne

Krome nastavujıcıch udalostı popsanych v manualove sekci byla do souboru3dmath.h pridana nova metoda na tvorbu matice. Metoda Matrix::SetupTrackedCameravytvorı pohledovou matici pro kameru zadanou zobrazovacı plochou v souradnicıchtrackingu. Matice je tvorena podobne jako v gluCreateLookAt, ale zadavase minimalnım (tj. levym dolnım) a maximalnım (tj. pravym hornım) bo-dem platna a up vectorem platna (tj. vektor lezıcı v rovine platna kolmy khorizontalnı hrane).

10.5 Manual

10.5.1 Ovladanı

Pro vytvorenı jednoducheho stereo zobrazenı je treba zalozit jednoduchyletajıcı koberec. Jeho korenem muze byt Assembly uzel nebo Camera, dulezitaje u nej pouze transformacnı matice. Pro stereo je treba vytvorit dve kameryse stejnou pohledovou maticı. Tu vytvorıte metodou Matrix::SetupTrackedCamera,ktere zadate jako argumenty pozici leveho dolnıho rohu platna, pravehohornıho rohu platna a up vector platna. Tyto udaje by mely byt v souradnicıchtrackingu (pro trackovane stereo) nebo v libovolnych pevne zvolenych souradnıcıchodpovıdajıcıch fyzickemu prostoru.


Kameram je pak potreba nastavit obecnou perspektivu pomocı udalostiEVT SCENE CAM SET STEREO. V nı je treba take indikovat, ktere ”oko“ktera kamera reprezentuje (podle tohoto udaje se pak bude prıslusne auto-maticky upravovat offset pozorovatele). Pokud pouzıvame zobrazovacı modul,ktery si uklada rozmery viewportu do kamery, je treba je nastavit pred nas-tavenım perspektivy.

Kamery vlozıme do sceny jako potomky uzlu, ktery chceme mıt jakokoren konfigurace. Nasledne vlozenım udalosti EVT SCENE REGISTER CARPETprohlasıme tento uzel za koren konfigurace a nastavıme parametry konfigu-race (zejmena rozchod ocı a prıpadne ID tracking objektu reprezentujıcıhopozorovatele).

Za behu pak muzeme pomocı udalosti EVT SCENE SET EYE SEPARATIONupravit separaci ocı pro vsechny kamery konfigurace, u netrackovanych kon-figuracı muzeme udalostı EVT SCENE SET OBSERVER POSITION up-ravit pozici pozorovatele pro danou konfiguraci. Udalostı EVT SCENE UNREGISTER CARPETmuzeme konfiguraci zrusit (zadne uzly se ze sceny neodstranı, pouze seprestane s updaty konfigurace a zahodı se jejı data).

Parovanı kamer s prıslusnymi zobrazovacımi moduly, potazmo zobrazo-vacımi zarızenımi, je starost toho, kdo je vytvarı.

10.5.2 Udalosti

Nove vytvorene udalosti vyplyvajı jednak z uprav v kamere, druhak vescene.

EVT SCENE CAM SET STEREO nastavı prıslusnou kameru na obec-nou perspektivu. Pouzitı teto udalosti vyvola udalost EVT SCENE CAM PROJECTION CHANGED.

EVT SCENE REGISTER CARPET zaregistruje dany uzel jako korenletajıcıho koberce. Pri tvorbe udalosti se nastavuje separace ocı a urcuje se,zda konfigurace bude trackovana (prıpadne kterym objektem).

EVT SCENE UNREGISTER CARPET zrusı registraci letajıcıho koberce.Neodstranujı se zadne uzly, pouze se zahodı obecne nastavenı konfigurace aprestane se s updaty kamer.

EVT SCENE SET EYE SEPARATION nastavı u dane konfigurace novouhodnotu separace ocı.

EVT SCENE SET OBSERVER POSITION upravı u dane konfiguraceperspektivu podle nove pozice pozorovatele.

10.6 Zaver

Jadro VRUTu nynı obsahuje plnou podporu jak pro jednoduchou stere-oskopii, tak pro stereoskopicke konfigurace vcetne trackingu. Zadanı (tedypozadavek na vypocet pohledovych a projekcnıch matic) bylo splneno, bohuzelje vsak implementovana funkcnost pouze velmi obtızne testovatelna, dokudnebudou dokonceny soucasti umoznujıcı korektnı praci na vıce strojıch.

Literatura

[1] OpenGL 2.1 Reference Pages. http://www.opengl.org/sdk/docs/man/.

[2] M. Koutek. Scientific Visualization in Virtual Reality: Interaction Tech-niques and Application Development. PhD thesis, Technische Univer-siteit Delft, 2003.

113

114 LITERATURA

Kapitola 11

Pruvodce programatora

Antonın Mısek, [email protected]. prosince 2009

11.1 Co to je

Tato kapitola ma za cıl zdokumentovat pozadavky kladene na prispevateleVRUTu a poskytnout jim pomoc v otazkach tykajıcıch se praktickeho pro-gramovanı.

11.2 Hodnocenı

11.2.1 Hodnocenı zaverecne zpravy

U studentu pracujıcıch na VRUTu v ramci semestralnıch, rocnıkovychnebo diplomovych pracı provadı hodnocenı prıslusna katedra dle svych vlastnıchzvyklostı.

U ostatnıch prispevatelu hodnotı zaverecnou praci zadavatel.Zadavatelum doporucuji pozadovat zaverecne prace v cestine i anglictine,

prıpadne jenom anglictine, ve forme podobne clankum v odborne literature.Format by se mel byt nynı jednotny tak, aby bylo mozne generovat

kompletnı dokumentaci pro VRUT se vsemi moduly pomocı LATEXu.

11.2.2 Hodnocenı zdrojoveho kodu

Doxygen dokumentace a komentare

Povinnym jazykem je anglictina.Dokumentace musı popisovat vsechny parametry metod.Komentare a dokumentace musı byt v dostatecnem rozsahu nutnem pro

zakladnı pochopenı funkcnosti.Doxygen by nemel vypisovat zadne chyby.

115

116 KAPITOLA 11. PRUVODCE PROGRAMATORA

Zdrojovy kod

Prozatım nebyly explicitne stanoveny pozadavky na format zdrojovehokodu (pojmenovavanı trıd, metod a promennych, ...), ale je potreba dodrzetstyl pouzity v jadru.

Pro odsazovanı se zasadne pouzıvajı tabulatory, s formatovanım muzepomoci castecne funkce MSVS Format Selection (Ctrl+K, Ctrl+F).

Nedoporucuji psanı vıce prıkazu na jeden radek, nedoporucuji psat kazdyparametr metody na zvlastnı radek.

Doporucuji radky do 180 znaku.Nutna je podpora Windows 32 bit, Windows 64 bit, Linux 32 bit a Linux

64 bit.Krome specialnıch prıpadu (vzdy je nutny explicitnı souhlas) nenı dov-

oleno pouzıvat prıkazy specificke pro nejakou platformu.Krome specialnıch prıpadu (vzdy je nutny explicitnı souhlas) nenı dov-

oleno pouzıvat cizı knihovny.K prekladu musı stacit zakladnı vyvojove nastroje (na Windows MSVC,

na Linuxu GCC+make).Kod nesmı obsahovat chyby ani varovanı (pro MSVC pouzijte parametr

/WX, pro GCC -Werror)Velmi nedoporucuji pouzıvat globanı promenne a klıcove slovo static.Zasadne se musı pouzıvat desetinna tecka (vyjımkou mohou byt logovacı

vypisy).

Funkcnost

Funkcnost je hodnocena podle konkretnıho zadanı, v prıpade nejasnostıdoporucuji vcasnou konzultaci s vedoucım prace ci zadavatelem.

Resenı musı byt funkcnı na vsech podporovanych platformach. Na Win-dows ocenım funkcnı makefile.win (pouzıvany ve vrut AM.sln).

Resenı musı zvladnout vsechny typy dat a byt dostatecne rychle i porozsahla data.

Automaticke testy a testy kvality

V soucasne chvıli jsou automaticke testy a testy kvality doporucene, alenevyzadovane.Poznamka 1: Automaticke testy jsou testy vychazejıcı z metodiky extremnıhoprogramovanı s nazvem Programovanı rızene testy, kterou osobne nedo-porucuji, nicmene automaticke testy samotne jsou velmi uzitecne a pomahajıudrzovat kod ve funkcnım stavu i pri vetsıch zmenach. Jedna se jednoduchetesty funkcnosti napsane pro kazdou metodu.Poznamka 2: Testy kvality jsou kompletnı testy vsech metod a veskerefunkcnosti, mely by pokryt vsechny mozne kombinace parametru metod.Poznamka 3: Ve VRUTu je castecne pripraveno pouzitı CppUnit.

11.3. POPIS JADRA 117

11.3 Popis jadra

V teto casti je popis nekterych zakladnıch konceptu pro praci s jadrem,zvlaste takovych ktere se zmenily oproti puvodnı diplomove praci.

11.3.1 Jak vytvorit novy uzel ve scene

GeometryNode *node = new GeometryNode(name);NODE_ID nodeId = (GetSceneMgr()->GetScene(sceneID))->GetNewNodeID();node->SetID(nodeId);wxCommandEvent ev(Event::GET_EVT_SCENE_NODE_INSERT(sceneID, node, rootID));PostToKernel(ev);

Detaily: Kazdy uzel ve scene ma jedinecne ID, pro generovanı ID slouzımetoda GetNewNodeID. Uzel pri vkladanı do sceny nemusı mıt prirazenoID, potom jadro automaticky vygeneruje nove ID. Ovsem v takovem prıpadevolajıcı toto ID nezna a nemuze jej dale pouzıt (naprıklad na vlozenı po-tomku, prirazenı materialu, atd.). Dokud uzel nenı vlozeny ve scene je moznejej libovolne menit prımo metodami uzlu. Po vlozenı uzlu do sceny prebırazodpovednost za uzel scena a je nutne pouzıt pro zmenu uzlu metody sceny.

11.3.2 Jak zmenit geometrii nebo material

RCU - read-copy-update

GeometryTriangles *geoTri = (GeometryTriangles*)geom->Clone();//zmenyscene->AddGeometry(geoTri);

Detaily: Pred jakoukoliv zmenou geometrie si geometrii/material nejdrıvzkopırujte metodou Clone, zmeny delejte na kopii a kopii pak poslete dojadra.

11.3.3 Je jadro thread-safe?

Castecne. Nektere casti jsou osetreny plne (vkladanı noveho uzlu, trans-formace kamery, ...), jine casti v podstate vubec ne (zmeny, mazanı).

11.4 Popis vrut AM.sln, * AM.proj, makefile.win,atd.

V teto casti je popis projektovych souboru a makefile.


11.4.1 Jak vytvorit * AM.vcproj pro novy modul

Zkopırovat z nejakeho existujıcıho modulu, prejmenovat a pomocı tex-toveho editoru (napr. Notepad) nahradit stare jmeno novym. Seznam *.cpp a*.h souboru lze pak upravit ve Visual Studiu. Pozor je nutne take zkopırovata upravit makefile.win.Detaily: Kopırovanı a uprava je jednodussı nez vytvarenı noveho pomocıVisual Studia, protoze je potreba nastavit podporu pro 32 i 64 bitu a cestypro vystupnı soubory.

11.4.2 Jak vytvorit makefile.win pro novy modul

Zkopırovat z nejakeho existujıcıho modulu a upravit.Detaily: Promenna BASEDIR musı ukazovat do zakladnıho adresare VRUTu(v nemz jsou adresare core, modules, documentation, atd.)

Promenna OUT musı ukazovat do adresare v nemz ma byt zkompilovanymodul (napr. $(BASEDIR)\bin\modules\render pro renderovacı modul).

Promenna MODULE musı obsahovat nazev modulu (podle nı bude nazvanvysledny binarnı soubor).

Promenna OBJS musı obsahovat seznam souboru nutnych pro sestavenımodulu.

Volitelna promenna SPECCFLAGS muze obsahovat parametry kom-pilatoru specificke pro dany modul.

Volitelna promenna SPECLFLAGS muze obsahovat parametry linkeruspecificke pro dany modul (napr. dodatecne knihovny).

Volitelna promenna SPECOBJS muze obsahovat seznam souboru potrebnychpro modul, ale takovych, ktere se namajı linkovat s vyslednou knihovnou.Muze se jednat naprıklad o shadery, obrazky a jine zdroje. Uzivatel ovsemmusı doplnit pravidla pro zpracovanı sam (napr. zkopırovanı do adresarebin).

11.4.3 Jak zajistit, aby se novy modul prekladal spolecne sprojektem

Ve Visual Studiu otevrıt vrut AM.sln a pridat projekt (Add→Existingproject). Vypnout preklad modulu pres Build→Configuration manager provsechny kombinace 32/64, Debug/Release. V makefile.win pridat radek dofinal a clean pro dany modul.

11.4.4 Jak vytvorit makefile.debian pro novy modul

Makefile na Linuxu jsou velmi podobne jako na Windows, rozdıl je pouzev syntaxi prıkazu (lomıtko mısto zpetneho lomıtka, ...), parametrech kom-pilatoru a linkeru a nazvech knihoven.

11.5. POZNAMKY K PROGRAMOVACIM TECHNIKAM 119

11.4.5 Kompilace trva prılis dlouho, kompilace zabere prılismnoho pameti, apod.

Kompilaci modulu, ktere nepotrebujete muzete zakomentovat.Na Windows probıha kompilace modulu paralelne. Pokud mate jenom

jedno jadro, nebo malo pameti (mene nez ∼1.5GB) muzete paralelismusvypnout pomocı parametru /WAIT u prıkazu start.

Na Linuxu probıha kompilace modulu sekvencne. Pokud mate vıce jadera dost pameti muzete paralelismus zapnout pridanım & na konec radkuspoustejıcıch makefile modulu.Pozor: Takoveto zmeny v makefilech neukladejte do SVN bez konzultace.

11.4.6 Projekt nelze zkompilovat

Jedna-li se o modul, ktery nepotrebujete, zakomentujte jej v hlavnımsoboru makefile.

11.5 Poznamky k programovacım technikam

V teto casti se nachazı rozbor castych chyb ve zdrojovem kodu a popistechnik zvysujıcıch kvalitu a rychlost aplikace.

11.5.1 Proc je lepsı pouzıt referenci nez odkaz?

Kratce: Reference netrpı problemem dereference neplatneho ukazatele.Detaily: V nekterych prıpadech je u vstupnıch parametru metody nutnepouzıt ukazatel (napr. Vector3 *vec), v jinych prıpadech se muzeme rozhod-nout mezi ukazatelem a referencı (napr. Vector3 &vec). Doporucuji vzdyvolit referenci, protoze u nı provadı kontrolu existence kompilator, kdezto uodkazu je to v rezii programatora. Pri pouzitı odkazu by se vzdy mela testo-vat jeho platnost, doporucuji v takovych prıpadech priradit NULL ihned pridefinici promenne a pak na vstupu metody testovat (if (vec) ...).

11.5.2 Optimalizace rychlosti

Pokud je Vas kod pomaly doporucuji pouzıt profilovacı nastroje (naprıkladpro Linux Oprofile, pro Windows AMD Codeanalyst). Tyto nastroje Vamukazı mısta, kde aplikace stravı nejvıc casu. K interpretaci vysledku jepotreba pristupovat opatrne, v nekterych prıpadech jsou zatızeny systemat-ickou chybou. Naprıklad v Debug verzi je mnoho casu straveno v STL trıdach(napr. std::vector) a mnoho metod ci celych trıd je v jadre ve formatu inline,takze se cas muze stravit jinde nez ukazuje vysledek merenı.

Pri optimalizaci zacnete metodami, ktere stravı nejvıc casu, praktickynama cenu optimalizovat metody, ktere zaberou mene nez 1% casu.


Ve vysledku muze nastat nekolik situacı:1. Podstatna cast je stravena ve Vasem kodu: dukladne si prohlednete danoumetodu a prozkoumejte co vsechno dela, jake dalsı metody vola a jak casto,jestli nemuzete preskupenım cyklu snızit pocet volanı dalsıch metod, jestlinemuzete nektere operace presunout vne cyklu. Nekdy pomuze zavedenıdocasnych pomocnych struktur, dıky nimz se zmensı slozitost algoritmu(naprıklad setrıdenım posloupnosti zvysıte rychlost vyhledavanı) na ukorvyssıho vyuzitı pameti.2. Podstatna cast je stravena v jadre:a) Pokuste se omezit volanı jadra. Vyhnete se situacım jako naprıklad vlozitdo stromu dılu 1000000 novych dılu a ihned potom polovinu smazat, mıstoznovupouzitı materialu vytvaret nove identicke materialy, mısto znovupouzitıgeometrie ji duplikovat, apod.b) Pokuste se identifikovat problematicke mısto v jadre a navrhnete resenı.c) Pripravte jednoduchy testovacı prıklad, na kterem bude mozne problemtestovat a pozadejte o pomoc nekoho zkusenejsıho.

11.5.3 Uniky pameti a dalsı chyby

K detekci uniku pameti slouzı dva typy nastroju. Prvnı skupina provadıstatickou kotrolu kodu (napr. cppcheck) a tyto nastroje umı vetsinou i dalsıtypy kontrol, druha skupina detekuje uniky pameti za behu aplikace (napr.na Linuxu Valgrind, na Windows MSVS). Projekt vrut AM.sln je nastaventak, aby v Debug modu uniky pameti hlasil. Bohuzel se jedna o hlasenı bezpresne lokace mısta (pokud nekdo zna postup jak dosahnout lepsıch hlasenı,budu rad za pomoc s konfiguracı!), proto je vetsinou obtızne presne mıstouniku najıt.

Obecny postup hledanı chyb ma dva zakladnı kroky:1. Minimalizace testu: najdete test, ktery unik pameti zpusobı vzdy a pak sejej snazte co nejvıc zjednodusit, naprıklad spustenım co mozna nejmensıhopoctu modulu, zmensenım dat (napr. umazanı casti VRML souboru), atd.2. Minimalizace kodove cesty: zakomentujte kod ktery pravdepodobne zpusobujeunik (nebo jej preskocte posunutım ukazatele aktualnı pozice v debug modu)a postupne zakomentujte dalsı casti nebo naopak odkomentujte az se Vampodarı problem najıt.

11.5.4 Proc nenı vhodne pouzıvat wxStringTokenizer, wxString::ToDouble,wxString::Format(wxT(”%f”), val) a dalsı veci z wxWid-gets?

Kratce: Zpusobujı problemy s desetinnou teckou/carkou.Spravne resenı: Pouzıt TextParser a TextWriter.Detaily: wxString je velmi silna trıda implementujıcı vse co je v std::stringa navıc s podporou ruznych kodovanı a Unicode. Bohuzel v prubehu vyvoje

11.5. POZNAMKY K PROGRAMOVACIM TECHNIKAM 121

VRUTu zpusobila nekolik vaznych a tezko nalezitelnych chyb. Implementaceje take docela pomala, takze trıda vubec nenı vhodna na parsery textovychsouboru (wxTextInputStream je asi 100-krat pomalejsı nez TextParser). Priprevodu desetinneho cısla na retezec je potreba dbat na pouzitı desetinnetecky, coz trıdy TextParser a TextWriter zarucujı.

11.5.5 Co je spatne na konstrukci: Vector3 vec2 = Vector3(vec1);?

Kratce: Vıcemene esteticka chyba.Spravne resenı: Vector3 vec3(vec1);Detaily: Jedna se o velmi rozsırenou konstrukci vyskytujıcı se v ruznych vari-antach (napr. Vector3 vec2 = vec1+vec3;), ktera ovsem nema zadny vliv nafunkcnost. Pri globalnı zmene v jadru pro Vector2, Vector3, Vector4 a Ma-trix bylo zrychlenı na hranici meritelnosti (pod 0,5%).Puvodnı konstrukce znamena pro kompilator: 1. zavolej konstruktor Vec-tor3() pro vec2, 2. zavolej kopırovacı konstruktor Vector3(vec1), 3. zavolejoperator prirazenı.Spravna konstrukce znamena pro kompilator: 1. zavolej kopırovacı konstruk-tor Vector3(vec1) pro vec2.


Kapitola 12

Modul C3Dconnexion

Antonın Mısek, [email protected]. brezna 2010

12.1 Co to je

Jedna se o modul pro podporu 3Dconnexion zarızenı (SpaceMouse, Space-Explorer, SpacePilot,...).

12.2 Ovladanı

Modul pouzıva stejny typ zpravy jako Flystick z modulu tracking. Pokudbude pouzıvan spolecne s A.R.T. trackingem (nebo jinym modulem pouzıvajıcıstejny typ eventu), je potreba nastavit nekoliznı hodnotu do registrovanepromenne trackingBodyID, prednastavena je hodnota 0. Cinnost modulu lzezapnout/vypnout pomocı promenne enabled. Styl navigace je prednastavenna mod ovladanı kamery a lze nastavit promenou cameraMode. Vystup lzena kameru napojit pomocı modulu trackingmanipulator, je potreba spravnezadat sceneID, sceneNodeID (ID kamery, lze vycıst z modulu Navigation),deviceID (stejna hodnota jako trackingBodyID) a transformationMode nahodnotu USE RELATIVE CAMERA.

12.3 Instalace

Modul vyuzıva standardnı ovladac 3Dconnexion.

12.3.1 Windows

Modul cyklicky testuje zmeny, cetnost testovanı je dana promennoumodulu eventTimeout. Standardnı hodnota 1000 (tj. 1 vterina) je prılis

123

124 KAPITOLA 12. MODUL C3DCONNEXION

velka. Doporucena hodnota (vyctena z prıkladu od 3Dconnexion) je 25. Hod-notu lze nastavit prıkazem z konzole:setparam C3Dconnexion.eventTimeout 25nebo v souboru autoexec.cfg (pred spoustenım modulu):setparam C3Dconnexion.eventTimeout 25 true

12.3.2 Linux

V okamziku spustenı modulu musı byt ovladac spusteny. Pro prijımanızprav o tlacıtkach je nutne nakonfigurovat ovladac, tak aby prıslusna tlacıtkamela funkci ”button <cıslo>”.

12.4 Popis implementace

Implementace se zasadne lisı pro Windows a Linux, protoze ovladac3Dconnexion poskytuje na kazde platform jine rozhrannı.

12.4.1 Windows

Stav zarızenı je kontrolovan v metode modulu run, ktera je periodickyvolana. Perioda testovanı stavu je tedy zavisla na stanovenı promenne mod-ulu eventTimeout. Ke komunikaci je vyuzito rozhrannı COM, implementacepouzıva trıdu wxAutomationObject.

12.4.2 Linux

Zmeny na zarızenı jsou posılany jako zpravy systemu X11, pro jejichprijımanı je vytvoreno skryte okno a zpravy jsou prijımany blokujıcı metodouXNextEvent v pomocnem vlaknu.

Kapitola 13

Modul AdamsToDG

Antonın Mısek, [email protected]. listopadu 2009

13.1 Co to je

Jedna se o modul pro konverzi animacı z aplikace Adams do DeltaGenu.

125

126 KAPITOLA 13. MODUL ADAMSTODG

Kapitola 14

Modul CameraManipulator

Vaclav Kyba2008

14.1 Co to je

Jedna se o navigacnı modul pro ovladanı sceny mysı a klavesnicı. Jezastaraly, jeho nahrada je modul Navigation.

127

128 KAPITOLA 14. MODUL CAMERAMANIPULATOR

Kapitola 15

Modul Cluster


15.1 Co to je

Jedna se o modul pro podporu clusteru, hlavne pro vıcesegmentove pro-jekce jako je naprıklad pasivnı stereo pomocı dvou projektoru nebo CAVE.

15.2 Detaily implementace

Server i klienti pouzıvajı stejny modul. Komunikace probıha pomocı mul-ticastu s pouzitım UDP packetu. Modul pouzıva dve vlakna, jedno vlaknoobstarava pouze nızkourovnovou sıt’ovou komunikaci a druhe vlakno zajist’ujezapis a zpracovanı prijateho obsahu.Trıda MulticastSocket slouzı pro sıt’ovou komunikaci. Obsahuje frontu zpravk odeslanı, frontu prijatych zprav a nekolik pomocnych metod pro zapisa ctenı do techto front. Pokud je fronta zprav pro odeslanı prazdna jsouodchozı data odeslana okamzite, pokud jsou ve fronte pripraveny packetycekajıcı na odeslanı, tak jsou data retezena.Hlavnı trıda modulu je Cluster, ktera obsahuje zpracovanı eventu z jadra aumı je preposılat klientum a umoznuje take jednorazovou distribuci sceny.Trıda PacketParser slouzı pro prijımanı packetu, konvertuje je na eventy aposıla jadru.Modul take zajist’uje vytvorenı uvletajıcıch kobercu podle konfigurace ulozenev souboru ClusterConfig.xml, spravne prirazenı kamer klientum a nastavenınekterych parametru letajıcıch kobercu (vzdalenosti near, far a vzdalenostocı). Na klientech se prepına aktivne zobrazena scena podle masteru.Modul umoznuje i interaktivnı posılanı prıkazu interpretru klientum.

129

130 KAPITOLA 15. MODUL CLUSTER

15.3 Navod na pouzitı

15.3.1 Jednorazova synchronizace sceny

Pomocı ComboBoxu sceneID vyberte pozadovanou scenu a pak tlacıtkemsendScene prenesete scenu na klienty. Jedna se o puvodnı experimentalı im-plementaci, ktera je sice funkcnı, ale v soucastnosti nevyvıjena. V budoucnubude mozna vyuzita pro synchronizaci klientu pro sceny importovane predspustenım modulu Cluster.

15.3.2 Prubezna aktualizace klientu

Zapına se CheckBoxem distributeEvents (na masteru). Prijate eventyjsou preposılany klientum.Tento system umoznuje synchronizaci kamery, ale vyzaduje aby byly klientispusteni a distribuce eventu zapnuta pred importem sceny. Je mozne spustitklienty az pozdeji a provest uvodnı synchronizaci pomocı tlacıtka sendScene,ale jedna se o velmi malo testovanou moznost (viz take predchozı odstavec).V soucastnosti jsou zachytavany informacnı eventy o provedenı operacejadrem (naprıklad EVT SCENE NODE INSERTED) a jsou pro klienty kon-vertovany na prıkazove eventy (EVT SCENE NODE INSERT).

15.3.3 ConfigurationTable

Tabulka konfiguracı zobrazuje vsechny definovane konfigurace zobrazenıa umoznuje vybrat, ktere konfigurace se pouzijı pri dalsım prıkazu render-scene. Konfigurace jsou ulozeny v konfiguracnım souboru ClusterConfig.xml(dalsı informace jsou v kapitole Stereoskopie).

15.3.4 CarpetsTable

Tabulka letajıcıch kobercu zobrazuje vsechny definovane letajıcı koberceve vsech scenach a umoznuje menit vzdalenost ocı a vzdalenosti orezovychrovin near a far.

15.4 Problemy a chyby

Predpoklada se, ze vsechny packety prijdou ve spravnem poradı. Pokudse nejaky packet ztratı, klienti nejsou schopni navazat komunikaci znovu.Pokud narazıte na ztracejıcı se packety nebo naopak nızkou rychlost komu-nikace zkontrolujte sıt’ (Majı master i klienti stejne rychlou sıt’ - doporucenaje 1Gb? Jsou vsichni na jednom switchi? Jaky dalsı provoz na sıti probıha?).Dale prozkoumejte metodu MulticastSocket::Entry a prıpadne upravte hod-notu Sleep (jedna se o ad hoc resenı...).Rendering u klientu nenı nijak synchronizovan.

15.5. VZDALENA SPRAVA KLIENTU 131

15.5 Vzdalena sprava klientu

Pro vzdalenou spravu klientu je na Linuxu mozne nakonfigurovat prıstupze serveru pomocı ssh bez hesla a pak pripravit startovacı skript. Je takemozne kopırovat instalaci bud’ pomocı sdıleneho adresare na masteru nebopomocı scp.Na Windows je mozne pouzıt pro vzdaleny prıstup PSTools (http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx), ktere jsou obdobou ssh. Lze take nastavitsdıleny adresar pro instalaci, nebo naopak nasdılet disky klientu serveru.

15.5.1 Ukazka pouzitı PSTools

Pro urychlenı skriptu je pouzit prıkaz ”start”, ktery spustı prıkaz vnovem okne a skript muze pokracovat dal bez cekanı na dokoncenı prıkazu.

Spustenı klientu

Soubor: runVRUT64 Rev887.batstart <cesta master> \psexec.exe \\ <nazev klienta 1> -u uzivatel -p heslo-i 0 -d -w ”<cesta klient>””<cesta klient> \vrut.exe”start <cesta master> \psexec.exe \\ <nazev klienta 2> -u uzivatel -p heslo-i 0 -d -w ”<cesta klient>””<cesta klient> \vrut.exe”

Vynucene ukoncenı klientu

Soubor: killVRUT.batstart <cesta master> \pskill.exe \\ <nazev klienta 1> -u uzivatel -p heslovrut.exestart <cesta master> \pskill.exe \\ <nazev klienta 2> -u uzivatel -p heslovrut.exe

Instalace VRUTu na klienty

Z duvodu paralelizace a omezenı ”kopırovanı kodu”je instalace rozdelenana dve casti. Je potreba vytvorit samorozbalujıcı se archiv s VRUTemspustitelny z prıkazove radky.Soubor: installVRUT64.batcopy <cesta master> \%2.exe ”<cesta master> \psexec.exe %1 -u uzivatel-p heslo -i 0 -w ”<cesta klient>””<cesta klient> \%2.exe”copy <cesta master> \autoexec.cfg ”%1<cesta klient> \%2”rem Tady mohou byt kopie dalsıch souboru nebo dalsı prıpravne akcedel ”%1<cesta klient> \%2.exe”


installVRUT64 Rev887.batstart cmd /c installVRUT64.bat \\ <nazev klienta 1> VRUT64 Rev887start cmd /c installVRUT64.bat \\ <nazev klienta 2> VRUT64 Rev887

Smazanı VRUTu z klientu

Soubor: removeVRUT64 Rev887.batstart cmd /C rmdir /Q /S ”\\ <nazev klienta 1> \ <cesta>”start cmd /C rmdir /Q /S ”\\ <nazev klienta 2> \ <cesta>”

15.6 Konfigurace projekce

<ClusterConfig><Powerwall>

<skdatwvt2001><LeftBottom>-1, 0, -1</LeftBottom><RightUp>0, 1, -1</RightUp><Up>0, 1, 0</Up><WidthPixels>400</WidthPixels><HeightPixels>400</HeightPixels><Width>1</Width><Height>1</Height><EyeType>0</EyeType><Offset>0, 0, 0</Offset>

</skdatwvt2001><skdatwvt2002>

<LeftBottom>0, 0, -1</LeftBottom><RightUp>1, 1, -1</RightUp><Up>0, 1, 0</Up><WidthPixels>400</WidthPixels><HeightPixels>400</HeightPixels><Width>1</Width><Height>1</Height><EyeType>0</EyeType><Offset>0, 0, 0</Offset>


<LeftBottom>-1, -1, -1</LeftBottom><RightUp>0, 0, -1</RightUp><Up>0, 1, 0</Up><WidthPixels>400</WidthPixels>

15.6. KONFIGURACE PROJEKCE 133

<HeightPixels>400</HeightPixels><Width>1</Width><Height>1</Height><EyeType>0</EyeType><Offset>0, 0, 0</Offset>


<LeftBottom>0, -1, -1</LeftBottom><RightUp>1, 0, -1</RightUp><Up>0, 1, 0</Up><WidthPixels>400</WidthPixels><HeightPixels>400</HeightPixels><Width>1</Width><Height>1</Height><EyeType>0</EyeType><Offset>0, 0, 0</Offset>

</skdatwvt2004></Powerwall>

</ClusterConfig>


Kapitola 16

Modul IOAC3D


16.1 Co to je

Jedna se o IO modul pro import a export formatu AC a ACC.

16.2 Formaty AC a ACC

Jedna se o formaty pouzıvane naprıklad hrou TORCS pro zavodnı tratea auta. Modul byl napsan castecne podle specifikace nalezene na internetu,castecne studiem existujıcıch souboru a castecne studiem zdrojoveho koduhry TORCS.

16.3 Omezenı s specifika implementace

Nenı podporovan multitexturing, vzdy je pouzita jenom prvnı textura aprvnı texturovacı souradnice.

135

136 KAPITOLA 16. MODUL IOAC3D

Kapitola 17

Modul IOCSB


17.1 Co to je

Jedna se o IO modul pro import a export formatu CSB.

17.2 Format CSB

Jedna se o format navrzeny firmou SGI a puvodne pouzıvany aplikacıCosmo Player. V soucasnosti jej vyuzıvajı nektere komercnı aplikace (napr.DeltaGen). Modul byl napsan s pouzitım zdrojoveho kodu SGI Performeru.

17.3 Omezenı s specifika implementace

17.3.1 Import

- jsou podporovany pouze trojuhelnıkove casti geometrie, NURBS jsoupreskakovany- soubory generovane DeltaGenem majı na konci souboru binarnı cast, vektere jsou ulozeny materialy, tuto cast se prozatım nepodarilo desifrovat,takze materialy oznacene v DeltaGenu ”High quality look”se nenactou spravne- pokud je nejaka cast stromu znovu pouzita pomocı reference, je ve VRUTuzkopırovana- nelze otevırat vıc souboru soucasne, je to patrne zpusobeno sdılenım globalnıchpromennych mezi ruznymi instancemi DLL

137

138 KAPITOLA 17. MODUL IOCSB

17.3.2 Export

- v tuto chvıli funguje export materialu a uzlu a zjednoduseny export ge-ometrie, scenu je mozne znovu nacıst, ale DeltaGen nektere sceny nepovazujeza korektnı

Kapitola 18

Modul IODOF


18.1 Co to je

Jedna se o IO modul pro import a export formatu DOF.

18.2 Format DOF

Jedna se o format hry Racer (www.race.nl), modul byl napsan podlespecifikace na strankach vyrobce http://racer.nl/dof.htm

18.2.1 Omezenı formatu

- nepodporuje geometrie s poctem vrcholu vetsım nez 65536- neumoznuje ukladat hierarchii sceny- neumoznuje ukladat transformace

18.3 Omezenı a specifika implementace

18.3.1 Import

- je podporovano ctenı samostatnych souboru DOF a celych scen defi-novanych v geometry.ini- ctenı geometry.ini je velmi jednoduche, nemusı byt spravne (nenı popisjeho presne syntaxe)- nijak nenı vyuzito className z MHDR (nenı popis k cemu slouzı)- nenı implementovano creationFlags z MCFL (patrne zastarale)- nijak nenı vyuzito MUVW (ve vsech testovanych souborech jsou stejnehodnoty, takze je to asi nevyuzıvane)

139

140 KAPITOLA 18. MODUL IODOF

- je vyuzita pouze prvnı textura (ve vsech testovanych souborech byla pouzejedna)- nenı implementovano MSUB (je asi nevyuzıvane)- nenı implementovano VCOL (nepodporovane na strane VRUTu)- nenı implementovano BRST (s nejvetsı pravdepodobnostı nenı potreba nastrane VRUTu)

18.3.2 Export

- className v MHDR je vzdy prazdne- creationFlags v MCFL je vzdy 0- vsechny polozky v MUVW jsou vzdy 0- VCOL se neuklada- BRST je vzdy prazdne- geometrie s poctem vrcholu vetsım nez 65536 jsou preskoceny- cela scena je ulozena jako jeden DOF soubor

Kapitola 19

Modul IOFHS

Vaclav KybaAntonın Mısek, [email protected]. listopadu 2009

19.1 Co to je

Jedna se o IO modul pro import a export formatu FHS.

19.2 Format FHS

Jedna se o format aplikace VD2. Modul byl napsan castecne podle speci-fikace, ktera je soucastı dokumentace, ale bohuzel nenı uplna a je zastarala,a castecne studiem konkretnıch souboru generovanych aplikacı VD2.


19.3.1 Import

- je podporovana vetsina bezne pouzıvanych prvku poslednıch verzı formatu,nepodporovane elementy jsou popsany ve zdrojovem kodu

19.3.2 Export

- DEPTHFUNC je vzdy 203, jine hodnoty zpusobujı problemy na straneVD2- format UID je libovolny retezec, spravne ma byt hexadecimalnı cıslo

141

142 KAPITOLA 19. MODUL IOFHS

Kapitola 20

Modul IOImage


20.1 Co to je

Jedna se o IO modul pro import a export obrazku BMP, PNG, JPG,JPEG, GIF, PCX, PNM, TIF, TIFF, TGA, IFF, XPM, ICO, CUR, ANI,RGB. Podpora jednotlivych formatu je zavisla na implementaci wxWid-gets s vyjımkou RGB, ktera je soucastı VRUtu. Modul vytvorı obdelnık orozmerech obrazku a obrazek namapuje jako texturu.

143

144 KAPITOLA 20. MODUL IOIMAGE

Kapitola 21

Modul IOOBJ


21.1 Co to je

Jedna se o IO modul pro import a export formatu OBJ.

21.2 Format OBJ

Jedna se o format podporovany ryznymi aplikacemi. Modul byl napsanpodle specifikace.


21.3.1 Import

- implementace je neuplna a mozna obsahuje chyby, jsou podporovanypouze trojuhelnıkove geometrie, nejsou podporovany NURBS krivky a plochyani materialy

145

146 KAPITOLA 21. MODUL IOOBJ

Kapitola 22

Modul IORDF


22.1 Co to je

Jedna se o IO modul pro import a export formatu RDF.

22.2 Format RDF

Jedna se o format pouzıvany aplikacı Adams (http://www.mscsoftware.com/products/adams.cfm)pro silnice.

22.2.1 Omezenı formatu

- nepodporuje materialy- neumoznuje ukladat hierarchii sceny- neumoznuje ukladat transformace (pouze posunutı)- neumoznuje ukladat normaly ani texturove souradnice


22.3.1 Import

- import byl vytvoren na zaklade jedineho ukazkoveho souboru

22.3.2 Export

- export byl vytvoren tak, aby jej bylo mozne zpet nacıst a aby se conejvıc podobal vzoru

147

148 KAPITOLA 22. MODUL IORDF

Kapitola 23

Modul IOSTL


23.1 Co to je

Jedna se o IO modul pro import a export formatu STL.

23.2 Format STL

Jedna se o velmi rozsıreny 3D format, ktery ovsem podporuje pouzetrojuhelnıky. Nepodporuje strukturu sceny ani materialy. Implementace vnekterych aplikacıch umoznujı ulozit i definici materialu, ovsem toto rozsırenıspecifikace nenı oficialnı a tımto modulem nepodporovane. Modul byl napsancastecne podle specifikace.


23.3.1 Import

- jsou podporovany jak ASCII tak binarnı soubory

149

150 KAPITOLA 23. MODUL IOSTL

Kapitola 24

Modul MaterialAssign


24.1 Co to je

Jedna se o modul umoznujıcı pouzıt knihovnu materialu. Materialy vescene budou nahrazeny podle prevodnı tabulky za materialy z knihovny.

24.2 Popis ovladanı

24.2.1 sceneID

Materialy se budou nahrazovat v teto scene.

24.2.2 materialLibrarySceneID

Scena s knihovnou materialu.

24.2.3 tableFile

Soubor definujıcı nahrazovacı pravidla. Pravidlo sestava ze dvou polozek,prvnı je maska jmena materialu ve scene a druha je maska jmena v knihovne.Je mozne pouzıt vsechny moznosti poskytovane wxString:Matches (napr. *)

24.2.4 load

Nahraje tabulku prevodnıch pravidel z disku.

24.2.5 save

Ulozı tabulku prevodnıch pravidel na disk.

151

152 KAPITOLA 24. MODUL MATERIALASSIGN

24.2.6 assignMaterials

Provede nahrazenı materialu. Prochazı vsechny materialy ve scene a prinalezenı prvnıho pravidla ktere tento material splnuje zkusı najıt v kni-hovne prıslusny material. Material si zachovava nazev a UID, menı se pouzevlastnosti (nedochazı ke slucovanı materialu). Materialy, ktere nevyhovujızadnemu pravidlu zustanou beze zmeny.

24.2.7 simulateAssigning

Simuluje nahrazovanı materialu, tj. provadı stejny postup jako pri nahra-zovanı, ale pouze vypisuje do logu detaily co by se stalo.

Kapitola 25

Modul MaterialEditor


25.1 Co to je

Jedna se o modul umoznujıcı editaci materialu.

25.2 Popis ovladanı

25.2.1 sceneID

Materialy se budou editovat v teto scene.

153

154 KAPITOLA 25. MODUL MATERIALEDITOR

Kapitola 26

Modul Optimize


26.1 Co to je

Jedna se o modul pro upravu scen. Vsechny operace v jistem smysluotimalizujı scenu, prıpadne odstranujı problemy vznikajıcı pri importu aexportu.

26.2 Popis metod

26.2.1 SceneID

Vsechny zmeny se dejı se scenou definovanou tımto parametrem.

26.2.2 nameMask

Nektere operace mohou pracovat jenom s nektrymi uzly, tento parametrumoznuje provest vyber uzlu pomocı jmena. Je mozne pouzıt carku prozadanı vıce masek jmena. Je mozne pouzıt vsechny moznosti poskytovanewxString:Matches (napr.*).

26.2.3 delete

Smaze vsechny uzly vyhovujıcı nameMask. Uzly ASSEMBLY budousmazany rekurzıvne i se svym obsahem.

26.2.4 simplifyStructure

Smaze vsechny uzly vyhovujıcı nameMask. Uzly ASSEMBLY budousmazany rekurzıvne i se svym obsahem.

155

156 KAPITOLA 26. MODUL OPTIMIZE

26.2.5 removeUnesedMaterials

Smaze vsechny materialy, ktere nejsou pouzite v zadnem uzlu.

26.2.6 unifyMaterials

Spojı vsechny materialy, ktere se lisı jenomjmenem a UID.

26.2.7 unifyVertices

Ve vsech geometriıch se pokusı spojit vrcholy, ktere majı stejne souradnice,normalu i texturovacı souradnice.

26.2.8 removeUnesedGeometries

Smaze vsechny geometrie, ktere nejsou pouzite v zadnem uzlu.

26.2.9 mergePrimitives

Ve vsech geometriıch se pokusı spojit jednotlive typy primitiv. Jedna seo TRI LIST, LINES, POINTS a QUADS. Pokud ma TRI FAN nebo POLY-GON ctyri vrcholy, pokusı je spojit s QUADS. Pozor: soucasna implementaceautomatickeho vypoctu normal muze zpusobit zmeny ve vzhledu sveny pospojenı primitiv.

26.2.10 deleteNormals

Smaze normaly ve vsech uzlech vyhovujıcıch nameMask.

26.2.11 deleteTexCoords

Smaze texturovacı souradnice ve vsech uzlech vyhovujıcıch nameMask.

26.2.12 removeLODs

Smaze vsechny LOD krome prvnıho.

26.2.13 stripe

Konvertuje LINES a LINE STRIP na LINE STRIP. V soucasne chvılipouzıva jednoduchy algoritmus, ktery nemusı v nekterych prıpadech davatnejlepsı mozne resenı, za to ma v podstate linearnı slozitost. Pred stripovanımje vhodne pouzıt unifyVertices.

26.3. NAVOD NA OPTIMALIZACI SCENY IMPORTOVANE Z CSB157

26.2.14 statistics

Vypıse detaily o scene (pocty uzlu, vrcholu, trojuhelnıku, materialu, tex-tur, atd.)

26.3 Navod na optimalizaci sceny importovane zCSB

VD2 pri ctenı formatu CSB vytvarı nekdy geometrie dvakrat, druhakopie je DeltaGenem pouzita pro predpocıtane stıny a nazev koncı ” shadow”.Vsechny takove uzly smazeme. (IOCSB uzly * shadow maze automaticky.)setparam Optimize.nameMask * shadowsetparam Optimize.delete 1

Struktura sceny obsahuje mnozstvı prazdnych uzlu a uzlu s jedinnym po-tomkem s generovanymi jmeny (tedy se jmeny, ktera nemajı zadny zvlastnısmysl). Takove uzly smazeme a jejich potomky presuneme na jejich uroven.Na zaver provedeme par standardnıch operacı (sjednocenı materialu, smazanınepouzitych materialu, sjednocenı vrcholu a primitiv).VRUT podporuje vkladanı vıceradkovych bloku, stacı tedy oznact nasledujıcıradky, zkopırovat (Ctrl+C), nastavit spravne ID sceny, kliknout do konzole(smazat pokud v nı neco je) a vlozit (Ctrl+V).

setparam Optimize.nameMask ”DeltaGen*,*FACE*,xFAC*, *CP*,Geometry,TRM SRF*,group*,node transform,node group,node shape,B-S SURF*,Surface*,tmp node group”setparam Optimize.simplifyStructure 1setparam Optimize.removeUnesedMaterials 1setparam Optimize.unifyMaterials 1setparam Optimize.mergePrimitives 1setparam Optimize.unifyVertices 1

158 KAPITOLA 26. MODUL OPTIMIZE

Kapitola 27

Modul RenderGL

Vaclav KybaAntonın Mısek, [email protected]. listopadu 2009

27.1 Co to je

Jedna se o zakladnı zobrazovacı modul VRUTu.

159

160 KAPITOLA 27. MODUL RENDERGL

Kapitola 28

Modul SeatStitcher


28.1 Co to je

Jedna se o modul pro vytvarenı svu (napr. na sedackach). K cinnostipotrebuje scenu s krivkami podel svu a scenu s modelem stehu. Prochazıscenu s krivkami svu a vklada podel nı jednotlive svy.

28.2 Detaily implementace

Pro LINES vytvarı svy zvlast’ pro kazdou usecku. Pro LINE STRIPvytvarı navazujıcı svy.Poslednı sev je vzdy zkraceny, tak aby byl presne do konce dane usecky/stripu,coz vytvarı nestejnomerne svy zvlaste je-li cela krivka popsana pomocı LINES.Doporucene resenı je prevest LINES na LINE STRIP.Pokud sev prochazı mezi geometriemi s otocenymi normalami jsou mıstokrızku vlozeny rovnobezne stehy.

28.2.1 computeNormal

Pokud scena obsahuje trojuhelnıkovou geometrii, tak najde nejblizsı trojuhelnıkke stredu kazdeho stehu a jeho normalu pouzije pro otocenı stehu podelneosy. Umoznuje tak pouzıt stehy, ktere nejsou rotacnı.

28.2.2 Direct

Jedna se o jednoduchy typ svu, sledujıcı presne danou krivku.

161

162 KAPITOLA 28. MODUL SEATSTITCHER

28.2.3 Perpendicular

Jedna se o jednoduchy typ svu, kolmy k vodıcı krivce.

28.2.4 Cross

Jedna se o krivkovy typ svu. Ke sve cinnosti potrebuje trojuhelnıkovougeometrii pro vypocet normaly. Postupuje podobne jako Simple, ale mıstojednoho stehu lezıcıho na vodıcı krivce vklada dva stehy ve tvaru krızku.

28.3 Navod na pouzitı

- Pripravit geometrii krivek, spojit vsechny geometrie do jedine.- Pouzıt metody unifyVertices a stripe modulu Optimize.- V modulu SeatStitcher vybrat sceneID (sceny s krivkami) a stitchSceneID(scena s geometriı svu), nastavit typ svu, nastavit vypocet normal a spustitstitch.

Kapitola 29

Modul Terrain


29.1 Co to je

Jedna se o experimentalnı modul pro podporu modelovanı krajiny.

163

164 KAPITOLA 29. MODUL TERRAIN

Kapitola 30

Multipass rendering forVRUT

Milan Stezka, [email protected]

16/12/2008

30.1 Task Assignment

Extend the existing VRUT rendering module base class to perform mul-tipass rendering. Study the possibilities of combining the resulting imageusing several independent rendering modules.

30.2 Introduction

Virtual Reality Universal Toolkit is an application designed for interac-tive visualization and manipulation of 3D environments. It is developed bythe company Skoda Auto in cooperation with CTU (Czech Technical Uni-versity). VRUT is designed as a modular application. Application consists oftwo main parts: the kernel and its surrounding modules. The kernel providesthe essential functionality. Modules perform other extended tasks. Modulesare realized as dynamically linked libraries. Modules communicate with thekernel only through predefined events. This assignment spans both fields.Both kernel and modules had to be modified and created, respectively.

30.2.1 Motivation and Problem Overview

So far, the rendering output of VRUT was realized only by the Ren-derGL module. This is a module based on the OpenGL library (VRUT’sgraphics library of choice) and it performs several basic, realtime graphicscalculations like difuse and specular lighting, texturing and transparency.

165

166 KAPITOLA 30. MULTIPASS RENDERING FOR VRUT

Lately, more render modules were developed, which are calculating moreadvanced computer graphics effects, like dynamic shadows and screen spaceambient occlusion. To combine the visual results of these renderers, newfuncionality in the VRUT had to be implemented and that is the task ofthis project. In a more broad view, this project will support the divide andconquer paradigm, because it will allow VRUT to have many renderers per-forming relatively simple tasks instead of a single ”uber”renderer. Anotherreason is the fact that the complexity of many advanced computer graphicseffects surpasses the possibilities of current mainstream graphics hardware.The instruction limit for custom GPU programs is the limiting factor. Theonly solution is to divide the effect into multiple render passes, which is thesubject this project facilitates.

30.2.2 Related work

Multipass rendering is not a theoretically demanding field of study. Infact, it is more of a practical OpenGL programming exercise. Before theproject was implemented, a brief study of related works was conducted,which revealed some lectures related to the subject. A search performedthrough the CVUT Information Resource Gateway, 360 Search meta searchengine has found [?] which is probably the most relevant article to the sub-ject and confirms author’s expectations about the technologies required toimplement multipass rendering. Author’s previous experience with multipassrendering is based on the work with ATI’s Rendermonkey, which is a pro-gram for designing OpenGL/DirectX shader based effects. This is reflectedin the used terminology.

30.3 Proposed Solution

First of all, it is mandatory to create support for other render targets.By default, OpenGL output is directed to frame buffer. But further access tothe render output is required. Reading back the frame buffer is slow. Currentgraphics hardware allows for an effective render output reuse through therender to texture (RTT) mechanism. OpenGL implements this as FrameBuffer Objects (FBO). Once it is possible to render to frame buffer ob-jects, it is needed to share textures (because frame buffer objects consistof so-called texture attachments) between OpenGL contexts. Every rendermodule has associated its own window, therefore each render module has itsown OpenGL context. OpenGL resources are not shared between contextsby default. Special OpenGL context initialization is needed to enable thisbehavior. Once the OpenGL resources are shared, and one module which isdesignated as a combiner module, knows the render target texture attach-ments of combined modules, it is needed to actually combine the outputsof renderers. This is done using a GLSL shader program. Combine renderer

30.4. IMPLEMENTATION 167

draws just a screen aligned, texture mapped quad. Multiple texture units areused to fetch texels from the combined renderer’s FBO color attachments.These texels are combined by a user specified fragment combine operation.The screen-aligned quad then shows the resulting multi-pass rendered image.

30.4 Implementation

30.4.1 Kernel

In this section, i will try to describe the main modifications and additionsto the source code which had to be done to make this work. The biggestmodifications in the kernel are in the RenderModule class. Other big mod-ifications is the inclusion of a new VRUT command called addrenderpass.This change has affected quite a few source files. Another major changestook place in the RenderManager class. Central concept of multipass ren-dering is the class RenderTarget. Every render module now has a membervariable of this type. RenderTarget class determines the target for renderer’soutput. Currently, only two target types are supported: frame buffer (nor-mal on screen rendering) and frame buffer objects (RTT). Render modulewhich wants to take advantage of off-screen rendering, has to perform fewinitialization steps. It has to create frame buffer attachments and set the ren-der target to FBO. This is done through RenderTarget’s public methods.RenderTarget performs basic attachment management. It allows for creat-ing, deleting and sharing attachments. Specific details will be provided laterin the User Manual section. Another interesting class is RenderPass. Thisclass was created later in the developmnet process, around the RenderTargetclass (RenderTarget is a member variable of a RenderPass). It provides somemeta information for RenderTarget, like the name of a fragment combinefunction, render pass enabled/disabled state and so on. The RenderModuleclass contains one instance of a RenderTarget class and a vector of Ren-derPass instances. This reflects the fact, that a render module has a singlerender target but it can combine outputs of many other renderers. Any ren-der module can become a render combiner module. New method had to beadded to the RenderManager class, which is called RenderPass. The name isa bit misleading, but i wanted to stay coherent with current naming schemeas it is just a counterpart to the RenderScene method. These methods justload the render modules and create a window for them, they actually havenothing to do with actual rendering. They sould be renamed accordingly.RenderPass method had to be created, because window creation for a ren-derer which wants to be part of a render pass chain has to be handled a bitdifferent (context sharing, render pass attaching and so on). Another minorchange to the RenderManager class is in the RenderUpdate method. Thecombiner modules are now rendered last to retain a correct drawing order.


30.4.2 Modules

Sample implementations of modules taking advantage of multipass ren-dering has been provided, to make it easier for developers to use the newkernel features correctly. The most important module which was created,is the CombineRenderer module. This module surpasses the definition of amere ”sample”. It is a ”production quality”module which can be readily usedto combine outputs of other renderers. It boasts dynamic GLSL source codegeneration to make the combine effects as fast as possible. Other two mod-ules which were developed are just a simple render modules which can bepart of a render pass chain. LightRenderer performs a simple diffuse lightingand TextureRenderer performs texture mapping. These modules were cre-ated just for the purpose of not being dependent on other render moduleswhich are currently under development. But still, they contain few lines ofcode which shows how to set up an offscreen render target correctly.

30.5 Results

Result of this project is a code base in VRUT’s core which makes mul-tipass rendering possible and allows for (hopefully) painless extensions tomore advanced multipass rendering features. Code was designed to mini-mally disrupt the current VRUT code and to incur minimal code changesto existing render modules.

30.6 User Manual

In this section, I am describing steps required to develop a render modulewhich will be part of a multipass rendering chain. First of all, it is needed toadd attachments to the FBO in the render module initialization, anywhereafter the GLEW library initialization. Please note that you should makeOpenGL calls only when correct rendering context is active, otherwise youwill probably get runtime errors resulting in calling a function at address0x0. Following code adds attachments to the FBO. It does so only whenthe module is part of a render pass chain and when the attachments arenot alerady created. Color and depth attachments created with followingparameters are known to work on ATI hardware and should work on othergraphics hardware as well. Other parameter settings are of course also al-lowed, as long as the status returned after adding the last attachment isFRAMEBUFFER COMPLETE.

if (renderTargetMapMember && !renderTarget.GetAttachmentOfType(GL_COLOR_ATTACHMENT0_EXT))

{

renderTarget.AddAttachment(RenderTarget::AttachmentParams(

windowWidth,

windowHeight,

GL_RGB8,

GL_COLOR_ATTACHMENT0_EXT,

GL_RGB,

GL_UNSIGNED_BYTE));

renderTarget.AddAttachment(RenderTarget::AttachmentParams(

30.6. USER MANUAL 169

Obrazek 30.1: Result of combining the LightRenderer and TextureRendererwith an average combine function

windowWidth,

windowHeight,

GL_DEPTH_COMPONENT,

GL_DEPTH_ATTACHMENT_EXT,

GL_DEPTH_COMPONENT,

GL_UNSIGNED_BYTE));

}

Next, it is needed to add

RenderModule::Draw();

into the module’s Draw method. The RenderModule class Draw methodhandles situations when the rendering window is resized (FBO attachmentsalso get resized). Finally, it is necessary to tell VRUT which renderer will bethe combine renderer and which renderers will create the individual passes.This is done using the VRUT’s command system. Following command se-quence sets the CombineRenderer as a preferred render module, the com-mand renderscene calls the RenderScene method (briefly described in theImplementation section) and most importantly, the addrenderpass sets upthe multipass rendering. The first addrenderpass attaches and loads the tex-turerenderer module as a render pass to the 0 instance of the CombineRen-


derer module. Last parameter tells which combine function will be used tocombine the fragments. Second addrenderpass command does the same, butfor the lightrenderer module.

usemodule combinerendererrenderscene 0addrenderpass CombineRenderer.0 texturerenderer usebaddrenderpass CombineRenderer.0 lightrenderer average

The combine functions are defined in the combine renderer’s shader direc-tory, in the blendFunctions.fs file. User can freely modify this file as longas it stays a valid GLSL source file. It is convenient to put this commandsequence in the autoexec.cfg file.

30.6.1 Module Parameters

The combiner module registers two parameters for each render pass.They are both registered as GUI parameters. They are named usePassi andblendFunctioni, where i is the position in the multipass render chain. Thenames are pretty self explanatory. usePass set to ”0”and ”1”disables andenables the pass respectively (it unloads or reloads the renderer). blend-Function is a string parameter telling which combine function will be used.

30.6.2 Module Controls

The combiner has GUI controls which are bound to parameters describedin the Module Parameters section. It should be noted, that each renderpass has a combine function specified. It tells how the output of a currentrenderer will be combined with an output of a previous renderer. This createsa singularity for the first renderer. Fragments in this renderer are combinedwith a zero vector vec4(0,0,0,0). Usually, the combine function of the firstrenderer is set to the ”useb”function.

30.6.3 Module Events

The only change regarding the event processing is the render module con-nection to the EVT SCENE CAM PROJECTION CHANGED event. Thisallows the renderers to change the size of render targets when the win-dow size changes. Pass renderers need to include the RenderModule::Draw()method in their Draw methods to react to this event.

30.7 Conclusion

Elementary multi-pass rendering has been implemented in the VRUTapplication. Further practice will show if the developed code framework will

30.7. CONCLUSION 171

be sufficient to handle day to day tasks. In case it is not, it sould be quitean easy task to extend it, as the multi-pass rendering code is designed withextensibility in mind.


Literatura

[1] OpenGL 2.1 Reference Pages. http://www.opengl.org/sdk/docs/man/.

[2] M. Koutek. Scientific Visualization in Virtual Reality: Interaction Tech-niques and Application Development. PhD thesis, Technische Univer-siteit Delft, 2003.

173

174 LITERATURA

Kapitola 31

Modul SceneGraph

Antonın Mısek, [email protected]. cervna 2010

31.1 Co to je

Jedna se o modul pro upravu scen.

31.2 Popis metod

31.2.1 SceneID

Vsechny zmeny se dejı se scenou definovanou tımto parametrem.

175

Date post:	15-Nov-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

VRUT V aclav Kyba, Anton n M sek a dal s

Documents