97
Masterarbeit Entwicklung und Einbindung von 3D-Grafikanimationen in ein Car-Multimedia-Framework Tsz Kwong YUNG Matrikel-Nr.: 702251 Datum: 08.10.2005 Fachhochschule Darmstadt Fachbereich Informatik Referent: Prof. Dr. Joachim Wietzke Korreferent: Prof. Dr. Thomas Horsch

Masterarbeit Entwicklung und Einbindung von 3D ... · Listing 3 OpenGL Code in (a) Java/JOGL, (b) C/OpenGL.....49 Listing 4 JOGL „HelloWorld“-Programm

Embed Size (px)

Citation preview

Masterarbeit

Entwicklung und Einbindung von 3D-Grafikanimationen in ein

Car-Multimedia-Framework

Tsz Kwong YUNG Matrikel-Nr.: 702251

Datum: 08.10.2005

Fachhochschule Darmstadt Fachbereich Informatik Referent: Prof. Dr. Joachim Wietzke Korreferent: Prof. Dr. Thomas Horsch

2

Inhaltsverzeichnis

1 Einleitung .................................................................................................. 7

1.1 Motivation .......................................................................................................... 7

1.2 Aufgabenstellung ............................................................................................... 7

2 HMI mit 3D-GUI ...................................................................................... 9

2.1 Grundlagen ......................................................................................................... 9

2.1.1 Automotive Framework Integration............................................................... 9

2.1.2 OpenGL........................................................................................................ 14

2.1.2.1 OpenGL Konventionen ............................................................................ 16

2.1.2.2 Programmstruktur..................................................................................... 17

2.1.2.3 Grafik-Primitive: Lines, Polygon…......................................................... 18

2.1.2.4 Vertex Array............................................................................................. 18

2.1.2.5 Koordinatensystem und Transformation.................................................. 19

2.1.2.6 Modell- und View-Transformation .......................................................... 21

2.1.2.7 Projektion Transformation ....................................................................... 22

2.1.2.8 Texture Mapping ...................................................................................... 24

2.2 Implementierung .............................................................................................. 25

2.2.1 Mesa ............................................................................................................. 26

2.2.2 OpenGL Photon Anbindung.........................................................................27

2.2.3 3D GUI......................................................................................................... 30

2.3 Diskussion ........................................................................................................ 31

3 Geländedarstellung..................................................................................33

3.1 Grundlagen ....................................................................................................... 33

3.1.1 Der SOAR (Stateless One-pass Adaptive Refinement) Algorithmus .......... 35

3.2 Implementierung .............................................................................................. 38

3.2.1 Funktionsbeschreibung................................................................................. 39

3.2.2 Probleme bei der Implementierung.............................................................. 42

3.3 Evaluierung und Diskussion............................................................................. 43

4 OpenGL Java-Binding ............................................................................47

4.1 Grundlage ......................................................................................................... 48

4.1.1 JOGL ............................................................................................................ 48

4.1.1.1 Native-Anbindung.................................................................................... 51

4.1.2 JAVA3D....................................................................................................... 55

3

4.1.2.1 Native-Anbindung.................................................................................... 61

4.1.3 SWTOGL ..................................................................................................... 63

4.1.3.1 Native-Anbindung.................................................................................... 64

4.1.4 JNI und NIO................................................................................................. 67

4.2 Implementierung .............................................................................................. 73

4.3 Evaluierung und Diskussion............................................................................. 78

5 3D-Modelle und Fisheye View...............................................................80

5.1 Grundlagen ....................................................................................................... 80

5.1.1 3D-Formate .................................................................................................. 80

5.1.1.1 Das OBJ-Format....................................................................................... 82

5.1.1.2 Das 3DS-Format....................................................................................... 82

5.1.2 Fisheye View................................................................................................ 83

5.2 Implementierung .............................................................................................. 87

5.3 Diskussion ........................................................................................................ 88

6 Zusammenfassung und Ausblick ............................................................91

Literatur ...............................................................................................................93

Anhang A: Technische Daten der Target-Hardware...........................................95

Selbständigkeitserklärung ...................................................................................97

4

Abbildungsverzeichnis Abbildung 1 Automotive Framework Architektur. Quelle [Wie05]........................................ 10

Abbildung 2 Aufbau der HMI-Komponente............................................................................ 11

Abbildung 3 Raw-Widget mit Photon GUI-Builder ................................................................ 12

Abbildung 4 Integration von 3D-GUI mit Grafik-Widget ....................................................... 12

Abbildung 5 (a) Die einzelne Layer. (b) Die Überlagerung der Layer. (c) Das Ergebnis. ...... 13

Abbildung 6 Framework Integration Multi-Layer-Technik..................................................... 14

Abbildung 7 OpenGL Namenskonvention............................................................................... 16

Abbildung 8 Geometrische Objekte......................................................................................... 18

Abbildung 9 Würfel mit acht Eckpunkte ................................................................................. 19

Abbildung 10 Das OpenGL Koordinatensystem ..................................................................... 20

Abbildung 11 Transformationsstufen....................................................................................... 20

Abbildung 12 (a) Translation, (b) Rotation und (c) Skalierung............................................... 21

Abbildung 13 View-Transformation........................................................................................ 22

Abbildung 14 Orthografische Projektion ................................................................................. 23

Abbildung 15 Perspektivische Projektion. (a) glFrustum() , (a) gluPerspective() 24

Abbildung 16 Texture-mapping ............................................................................................... 24

Abbildung 17 (a) GUI in der normalen Stellung. (b) GUI in der aufgeklappten Stellung....... 31

Abbildung 18 Darstellung eines Geländes mit einem quadratischen Dreieck-Gitter .............. 33

Abbildung 19 (a) Darstellung als vollständiges Gitter. (b) Darstellung mit LOD.................. 34

Abbildung 20 Quadtree Hierarchie .......................................................................................... 34

Abbildung 21 Höhenunterschied zwischen Original-Punkt und der approximierten Stelle

(weißer Punkt). ......................................................................................................................... 35

Abbildung 22 Longest edge bisection...................................................................................... 35

Abbildung 23 Rekursive Verfeinerung .................................................................................... 36

Abbildung 24 Schematischer Ablauf des Verfeinerungsalgorithmus...................................... 37

Abbildung 25 Für die Geländedarstellung: (a) Textur. (b) Heightmap....................................38

Abbildung 26 Ablaufdiagramm des Gelände-Darstellungsprogramms................................... 39

Abbildung 27 Blick auf das Gelände mit einem Symbol für die Navigation und ................... 42

Abbildung 28 Screenshot aus unterschiedlichen Winkeln....................................................... 42

Abbildung 29 Fehlerhaft dargestelltes Gelände ....................................................................... 43

Abbildung 30 Vektorisierte Strasse auf einem Gelände-Gitter. Die neu entstandenen Punkte

sind in blau gekennzeichnet. .................................................................................................... 45

Abbildung 31 Klassendiagramm der wichtigsten JOGL Klasse..............................................50

5

Abbildung 32 Sequenz-Diagramm beim Aufruf der Methode GLCanvas.reshape()............... 53

Abbildung 33 Klassendiagramm GLContext Hierarchie ......................................................... 53

Abbildung 34 Aufbau eines Szenen-Graphen in Java3D aus [Sun01]..................................... 57

Abbildung 35 Hierarchie der wichtigsten Szenen-Graphen-Klassen....................................... 58

Abbildung 36 Beispiel HelloUniverse Szenen-Graph ............................................................. 59

Abbildung 37 Screenshot Java3D-Beispielanwendung ........................................................... 61

Abbildung 38 Sequenz-Diagramm beim Erzeugen des GLContext Objektes ......................... 65

Abbildung 39 Namenskonvention der Native-Funktion bei JNI .............................................68

Abbildung 40 Vordefinierte C-Typen auf Java-Objekte.......................................................... 69

Abbildung 41 Klassen-Hierarchie von Java-NIO-Buffer. Quelle [Hit02]. .............................. 71

Abbildung 42 Schematische Aufbau eines Buffer-Objektes. Quelle [Hit02]. ......................... 71

Abbildung 43 Klassendiagramm SWT Widget........................................................................ 73

Abbildung 44 Sequenz-Diagramm beim Instantiieren des GLContext Objektes .................... 74

Abbildung 45 Sequenz-Diagramm CreateContext................................................................... 75

Abbildung 46 Gears Demo in Java mit SWTOGL .................................................................. 78

Abbildung 47 Schematische Darstellung des 3DS-Formats .................................................... 83

Abbildung 48 (a) Eine klassische Fisheye-Projektion. (b) Eine normale 2D-Karte Darstellung.

.................................................................................................................................................. 84

Abbildung 49 Hervorhebung durch 3D-Fisheye Zoom bei der Visualisierung ....................... 84

Abbildung 50 (a) Objekte/Häuser auf der Ebene. .................................................................... 85

Abbildung 51 Winkel θ und φ in Beziehung zu Punkt p ......................................................... 86

Abbildung 52 Herleitung der Projektion von p nach p’ bei φ = 90° oder 270° ....................... 86

Abbildung 53 Bestimmung von θ und φ .................................................................................. 87

Abbildung 54 Ein gerendertes POI Objekt. ............................................................................. 88

Abbildung 55 Stadt-Modell als normale Perspektivendarstellung........................................... 88

Abbildung 56 Stadt-Modell in Fisheye-View aus verschiedenen Blick-Richtung .................. 89

Abbildung 57 Darstellung einer künstlichen 3D-Straßen-Szene ............................................. 90

Abbildung 58 Fotografische Abbildung der Target-Hardware ................................................ 95

Abbildung 59 Schematische Darstellung der Hardware. Quelle [ICM04]. ............................. 96

6

Tabellenverzeichnis Tabelle 1 Gegenüberstellung der Applikationsgröße mit und ohne 3D-Grafik ....................... 32

Tabelle 2 Messergebnisse bei einem 256x256 Gitter............................................................... 44

Tabelle 3 Messergebnisse bei einem 512x512 Gitter............................................................... 44

Tabelle 4 Zuordnung der Java- und OpenGL-Datentypen....................................................... 49

Tabelle 5 Zuordnung der Java- und C-Datentypen .................................................................. 69

Tabelle 6 Messergebnisse Gears-Demo mit Java/SWTOGL und C auf dem Target............... 79

Tabelle 7 Technische Daten der Target-Hardware. Quelle [ICM04]....................................... 95

Listingverzeichnis Listing 1 Ein OpenGL Beispielprogramm ............................................................................... 17

Listing 2 Implementierung der glICM Funktionen .................................................................. 30

Listing 3 OpenGL Code in (a) Java/JOGL, (b) C/OpenGL ..................................................... 49

Listing 4 JOGL „HelloWorld“-Programm............................................................................... 51

Listing 5 Code-Beispiele (a) Java/SWTOGL, (b) C/GLX...................................................... 63

7

1 Einleitung

1.1 Motivation Echtzeit-3D-Computergrafik ist längst kein Privileg mehr der Highend-Workstation oder der Spielkonsolen. Sei es auf dem PC oder im Bereich der Unterhaltungselektronik, überall sind 3D-Grafik garnierte Applikationen zu sehen. Deshalb ist es nicht verwunderlich, dass immer mehr Hersteller im Automobilbereich1 ihre Produkte mit 3D-Applikationen ausstatten. 3D-basierte Infotainment- und Navigationssysteme sind entweder in der Planung oder bereits etabliert. Derartige Systeme gehören nicht nur zum aktuellen Trend, sondern sie werden oft vom Kunden als Innovation angesehen. Vor der Realisierung eines solchen Systems sind allerdings viele Fragen zu klären, die die technische Umsetzung betreffen, wie z.B.: • Welche 3D-Bibliothek2 kann eingesetzt werden? • Wie ist der Verbrauch von Speicher- und CPU-Kapazitäten? • Können bestehende 3D-Programme portiert werden? • Wie kann eine 3D-Bedienoberfläche/-Anwendung in ein bestehendes Automotive-

Framework integriert werden? • Welche Programmiersprache kann eingesetzt werden? • Und wie ist das „Look-and-Feel“ einer solchen Anwendung?

1.2 Aufgabenstellung Anhand von ausgewählten Themen sollen Einsatzmöglichkeit, Durchführbarkeit und Portierbarkeit von Echtzeit 3D-Applikationen auf einer Automotive-Embedded-Hardware untersucht werden. Die Aufgaben sind im Einzelnen folgende: • HMI (Human Machine Interface) mit 3D GUI (Graphical User Interface)

Eine mit 3D-Grafik animierte Benutzeroberfläche3 soll prototypisch implementiert werden. Neben dem Demonstrieren des „Look-and-Feel“ soll hier insbesondere der einwandfreie Einsatz von OpenGL sowie die Einbindung in ein Automotive-Framework auf dem Target4 untersucht werden.

• Geländedarstellung

Für echte 3D-Navigation ist eine Kartendarstellung mit Geländeinformationen unabdingbar. Daher soll hier ein geeignetes Verfahren zur Geländevisualisierung auf dem Target portiert werden. Ziel ist es, die Durchführbarkeit und die Portierbarkeit eines solchen Algorithmus auf dem Target zu untersuchen und die Problemgrösse zu erfassen.

• OpenGL Java-Binding

Im Rahmen dieser Untersuchung soll eine geeignete freiverfügbare5 OpenGL Java-Binding-Implementierung auf dem Target unter QNX portiert werden. Es soll der

1 engl. automotive 2 engl. library 3 engl. GUI (Graphical User Interface) 4 siehe Anhang A 5 engl. Open Source

8

Frage nachgegangen werden, inwieweit die Entwicklung von 3D-Applikation auf Java-Basis auf dem Target möglich und sinnvoll ist.

• 3D-Modelle und Fisheye-View

Eine weitere wichtige Anwendung im 3D-Bereich ist die Visualisierung von 3D-Modellen. Ein prototypischer 3D-Viewer ist bei dieser Untersuchung zu entwickeln. Der Viewer soll ein 3D-Modell aus einem gängigen 3D-Dateiformat einlesen und mit OpenGL auf dem Target darstellen. Diese Modelle können sowohl einzelne Gebäude als auch eine ganze Stadt beinhalten. Als zusätzliche Funktion soll das Programm ein eingelesenes 3D-Stadt-Modell mit einer „Fisheye-Projektion“ visualisieren. Ziel dieser Untersuchung ist die Realisierbarkeit eines 3D-Viewers sowie die Durchführbarkeit von Echtzeit-Berechnung von visuellen Effekten mit umfangreicheren 3D-Modellen zu evaluieren.

Als 3D-Library soll OpenGL eingesetzt werden. Die Anwendungen sollen auf der im Multimedia-Labor der FH-Darmstadt installierten Target-Hardware prototypisch implementiert werden. Technische Daten des Targetsystems sind im Anhang A angeführt.

9

2 HMI mit 3D-GUI Will man heutzutage eine Anwendung mit 3D-Grafik Unterstützung im Desktop-Bereich entwickeln, so ist die Entscheidung für die geeignete 3D-Library sowie auf das GUI-Framework relativ einfach zu treffen. Je nach Hardware, Betriebssystem, Programmiersprache und finanziellen Rahmenbedingungen findet man hier schnell das passende Produkt. Für Embedded-Anwendungen trifft diese Situation nicht zu. Selbstverständlich existieren auch hier eine Fülle von guten Produkten, aber die Anforderungen und Eigenschaften der eingesetzten Hard- und Software sind sehr speziell und sehr verschieden, sodass man nicht nach einem „Einheitsrezept“ vorgehen kann. Außerdem ist ein ausgefeiltes GUI-Framework für einfache Anwendungen, wie z.B. zur Steuerung von Waschmaschinen, nicht unbedingt erforderlich sind, auch wenn es bereits solche Produkte mit voll grafikfähigem Display, vergleichbar mit einem Navigationssystem, auf dem Markt gibt. Im Rahmen einer prototypischen Implementierung einer mit 3D-Grafik animierten GUI soll in dieser Ausarbeitung untersucht werden, wie sich die Integration von 3D-Grafik in ein GUI- und Automotive-Framework realisieren lässt. In Kapitel 2.1.1 wird zunächst auf mögliche Vorgehensweisen und Techniken für die Realisierung einer 3D-GUI sowie die Integration der GUI bzw. HMI in ein Automotive-Framework eingegangen. Dabei werden grundlegende Konzepte der Software-Architektur erörtert. Einen Überblick zu den Grundlagen von OpenGL wird schließlich in Kapitel 2.1.2 gegeben. Im Implementierungsteil (Kapitel 2.2) wird die prototypische Realisierung vorgestellt. Auf die konkrete Target-Portierung der OpenGL-Library und die Anbindung von OpenGL zum QNX-Window-System Photon wird in diesem Abschnitt ebenfalls eingegangen.

2.1 Grundlagen

2.1.1 Automotive Framework Integration In einem modernen Auto werden Geräte im Infotainmentbereich über den MOST-Bus (Media Oriented System Transport6) angeschlossen. Die Steuerung des gesamten Systems erfolgt über ein Softwaresystem, welches in der Regel auf der Headunit betrieben wird. Das klassische Software-Design im Embedded-Bereich beschränkt sich auf das Strukturieren der Funktionalitäten in Unterprogrammen und auf das Aufteilen der Aufgaben in statische Schichten und Module. Ein Multi-Tasking/-Processing fähiges Betriebsystem ist je nach Einsatzgebiet nicht immer vorhanden. Zur Laufzeit befindet sich die Steuerungssoftware allein im System und hat jederzeit die volle Kontrolle. Diese einfache Vorgehensweise ist für ein modernes Infotainmentsystem zwar auch möglich, aber längst nicht optimal. Um die Geräte und den Kommunikationsbus besser abstrahieren zu können, ist eine modernere Architektur erforderlich. Abbildung 1 zeigt die schematische Darstellung einer Software-Architektur für Automotive-Systeme7.

6 vgl. [MOST01] 7 vgl. [Wie05]

10

Abbildung 1 Automotive Framework Architektur. Quell e [Wie05] Die Architektur wird durch ein Framework8 geregelt. Logische und physikalische Geräte werden in Software-Komponenten gekapselt und zur Laufzeit als eigenständiger Thread oder Prozess in das Gesamtsystem integriert. Die Kommunikation zwischen Komponenten erfolgt über Austausch von Nachrichten9. Events werden in der Regel asynchron verarbeitet und in Shared-Memory-Queues abgelegt. Jede Komponente verfügt über eigene Queues (Intern-, Extern- und System-Queue) und einen Dispatcher für den Empfang und die Verarbeitung von Events. Neben den Geräte-Komponenten (Tuner, CD usw.), die jeweils ein logisches oder physikalisches Gerät repräsentieren, gibt es weitere Komponenten wie z.B. die Admin-Komponente, die spezifische Aufgaben im System erledigen. Eine zentrale Rolle spielt dabei die Main-Dispatcher-Komponente. Hier erfolgt nämlich die Steuerung des MOST-Treibers. Wie bereits oben erwähnt, werden die Geräte physikalisch über den MOST-Bus angeschlossen. Zum Ansteuern eines Gerätes werden MOST-Events gemäß dem MOST-Protokoll über den MOST-Treiber zum Gerät gesendet. Auch ankommende Daten von den Geräten sind über den MOST-Treiber zu empfangen. Außerdem ist diese Komponente auch für die interne Kommunikation zuständig. Alle internen Events werden zunächst zum Main-Dispatcher gesendet und von dort aus zum Empfänger weiter geleitet.

8 Die genaue Definition und Aufgabe von einem Framework ist in [Wie05] ausführlich beschrieben. 9 engl. Events

11

Für die grafische Darstellung der Bedienoberfläche sowie Bearbeitung der Benutzer-Interaktion ist die HMI-Komponente zuständig. Diese Komponente besteht aus zwei logischen Schichten10. Die GUI-Schicht und die „Main Desktop Manager“-Schicht (siehe Abbildung 2). Aufgabe der GUI-Schicht ist die Darstellung der grafischen Bedien-Elemente sowie das Anzeigen von Meldungen und Informationen. Der Main-Desktop-Manager kümmert sich um das Event-Handling, also die Kommunikation mit anderen Komponenten, und steuert je nach Kontext und Zustand die Ausgabe der GUI. Benutzer-Eingaben werden in der Regel als Event gekapselt, vom Main-Dispatcher an die HMI weitergeleitet und vom Main-Desktop-Manager ausgewertet.

Abbildung 2 Aufbau der HMI-Komponente Die Anbindung von 3D-Animationen erfolgt logischerweise in der GUI-Schicht. Die GUI kann mit verschiedenen Techniken realisiert werden. Einige Möglichkeiten werden nachfolgend vorgestellt: • Window-System und Widget-Toolkit

Die klassische Art und Weise eine GUI zu erstellen ist die Verwendung eines Window-Systems und der dazu passenden Widget-Toolkit-Library. Bei den meisten Toolkits sind in der Regel komfortable GUI-Builder verfügbar. Damit kann man in kürzester Zeit eine GUI per visuellen Editor zusammenstellen und den entsprechenden Programmcode generieren. Soll die Anwendung vollständig in das GUI-Framework integriert werden, so kann man je nach Ablauflogik Callback-Funktionen den einzelnen Bedienelementen (Button, Slider) zuweisen. Diese Callback-Funktionen werden bei einer Aktivierung des GUI-Elements („anklicken“ eines Buttons) entsprechend aufgerufen. Eine derartige Integration setzt aber voraus, dass die Eingabegeräte (Touchscreen-Display, Commander) auch in das Betriebssystem integriert sein müssen, damit das Event-Handling des GUI-Framework funktioniert. Im Embedded-Bereich ist das jedoch aus diversen Gründen nicht immer möglich. Bei einem Touchscreen-Display ist die Integration noch relativ einfach, das Drücken auf dem Display kann direkt als eine Interaktion mit x- und y-Koordinaten an das GUI-Event-Framework weitergeleitet werden. Bei einem komplexen Eingabegerät, etwa dem Commander eines modernen InCar-Multimedia-Systems, ist eine einfache Zuordnung nicht mehr möglich. Für die Darstellung von 3D-Grafik werden von den Toolkit-Libraries spezielle Grafik- oder Raw-Widget zur Verfügung gestellt. Die von der 3D-Engine gerenderte Grafik kann durch entsprechende Funktionen auf diesen Widgets angezeigt werden. Abbildung 3 zeigt ein Beispiel mit QNX-Photon.

10 Die „Virtuelle GUI“ nach [Wie05], die die tatsächliche GUI softwaretechnisch abstrahiert, wird hier nicht behandelt.

12

Abbildung 3 Raw-Widget mit Photon GUI-Builder

Für die Animation kann beispielsweise die Timer-Funktion des GUI-Frameworks verwendet werden. D.h. es wird jeweils nach einem festgelegten Zeit-Intervall eine Callback-Funktion aufgerufen, die ein neues Bild rendert und anzeigt. Alternativ kann die 3D-Engine auch in einer Schleife explizit aufgerufen werden. In diesem Fall ist die Ausführung der GUI getrennt als ein separater Thread zu empfehlen, damit die HMI nicht unnötig durch das Rendern der Grafik geblockt wird. Eine mögliche Integration in ein Automotive Framework ist schematisch in Abbildung 4 dargestellt.

Main Desktop ManagerDisp.

GUI Thread

HMI Prozess

Main Thread

LoopGUI

Events

Abbildung 4 Integration von 3D-GUI mit Grafik-Widge t Die GUI-Schicht wird als getrennter Thread ausgeführt und ist für die grafische Darstellung und Animation der Bedienoberfläche zuständig und übernimmt auch die Initialisierung des Window-Systems. So kann sich der Main-Desktop-Manager auf das Framework-Event-Handling und die Steuerung der Ablauflogik konzentrieren. Der Vorteil dieser Methode ist die einfache Integration in die bestehende GUI. 3D-Grafik-Animationen können dadurch auch mit High-Level-Widgets wie z. B. Browser oder Text-Editor kombiniert werden. Der Nachteil ist die im Vergleich zu anderen Methoden schlechtere Performance.

13

• Multi-Layer Unterstützt die Grafik-Hardware Multi-Layer Technik, so kann die GUI auch entsprechend ausgelegt werden. Beispielsweise kann ein Layer im Hintergrund eine 3D-Navigationskarte darstellen, während im Vordergrund die 2D-Bedienknöpfe angezeigt werden. Abbildung 5 zeigt das Konzept schematisch. Die einzelnen Layer der Beispiel-GUI sind in Abbildung 5(a) abgebildet. Diese können wie in Abbildung 5(b) hardwaremäßig aufeinander gelegt werden. Abbildung 5(c) zeigt das für den Anwender sichtbare Ergebnis.

(a)

(b)

(c)

Abbildung 5 (a) Die einzelne Layer. (b) Die Überlagerung der Layer. (c) Das Ergebnis.

Die 2D Elemente können dabei mit einem klassischen GUI-Toolkit erstellt und angezeigt werden. Der bei der Überlagerung sichtbare Bereich des Vordergrund-Layers wird als transparent markiert. Die 3D-Karte im Hintergrund-Layer kann mit der OpenGL-Engine unabhängig von den anderen Layern gerendert werden. Eine mögliche Integration in das Framework zeigt Abbildung 6. Bei diesem Modell bietet sich an für jede Layer einen separaten Thread einzusetzen. Die Steuerung der gesamten GUI über alle Layer hinweg wird wie bereits erwähnt vom Main-Desktop-Manager übernommen.

14

GUI-2D

Main Desktop ManagerDisp.

GUI Thread

HMI Prozess

GUI-3DGUI-Info

Main Thread

Loop

Events

Abbildung 6 Framework Integration Multi-Layer-Techn ik

Das Verfahren bietet einige Vorteile gegenüber anderen Verfahren. Zum einen wird eine modulare GUI-Entwicklung besser unterstützt. Zum anderen ist eine bessere Performance zu erzielen; bei der Aktualisierung der 3D-Karte beispielsweise müssen die anderen Layer nicht erneut gerendert werden. Der Nachteil bei dieser Methode ist, dass die Steuerung im Desktop-Manager komplexer wird.

• 3D im Direct-Mode

Obwohl OpenGL als 3D-Engine eingesetzt wird, kann man diese Library auch hervorragend für das 2D-Rendering benutzen. Die Idee bei diesem Modell ist, die 2D-Bedienelemente mit der 3D-Szene zusammen in OpenGL zu erzeugen und zu rendern. Dadurch ist es möglich, auf das Window-System zu verzichten; die Grafikausgabe kann direkt zum Grafiktreiber weitergeleitet werden. Diese Vorgehensweise wird überwiegend bei der Spieleprogrammierung verwendet. Die Integration in das Framework erfolgt wie beim oben genannten ersten Modell. Das Rendern im Direct-Mode bringt in erster Linie Performance-Vorteile. Nachteile sind dagegen die aufwendigen Programmierungen, da OpenGL standardmäßig keine (2D/3D) Widget-Library bietet.

2.1.2 OpenGL Im Bereich der 3D-Computergrafik hat sich OpenGL in den letzten Jahren als Industrie-Standard durchgesetzt. OpenGL (Open Graphics Library) wurde von der Firma SGI (Silicon Graphics) entwickelt und 1992 der Öffentlichkeit vorgestellt. Die aktuelle Version vom Stand September 2004 ist 2.0. Das Entwicklungsziel war eine effiziente, plattformunabhängige und einfach benutzbare API für 2D- und 3D-Grafik bereit zu stellen. Wesentliche Eigenschaften von OpenGL zusätzlich zu den gängigen 2D-Grafik-APIs sind:

• Transparenz und Alpha-Blending

Objekte und Farben können als transparent dargestellt werden. Realisiert wird es durch eine zusätzliche Farbinformation im Alpha-Kanal, d.h. eine Farbe wird durch vier Werte (rot, grün, blau und alpha) beschrieben. Der Alpha-Wert gibt den Grad der Transparenz an.

15

• Anti-Aliasing

Bei der Darstellung von schräg verlaufender Linien und Kurven entstehen unter normalen Umständen sog. Treppen-Effekte. Bei Anti-Aliasing wird die Farbe der umliegenden Punkte so angepasst, dass diese Linien insgesamt weicher erscheinen.

• 3D-Projektion

3D-Szenen können sowohl in Perspektiven als auch in orthogonalen Ansichten dargestellt werden. Bei der Perspektivenansicht erscheinen entfernte Objekte mit zunehmender Entfernung kleiner. Bei der orthogonalen Projektion werden Objekte wie bei einer CAD-Zeichnung ohne räumliche Verzerrung dargestellt.

• Texturen

2D-Bilder können als Oberfläche auf Polygone projiziert werden. Verändert sich die Größe der Polygone, so wird die erforderliche Anpassung der Textur-Größe automatisch durchgeführt.

• Licht- und Schatten-Effekte

Vielfältige Licht- und Schatten-Effekte sind mit OpenGL realisierbar. Eigenschaften wie Lichtquellen, Materialien und Beleuchtungsmodelle können beliebig eingestellt werden.

• Nebel und atmosphärische Effekte

Durch Nebel und atmosphärische Effekte können sehr realitätsnahe Grafiken erstellt werden.

OpenGL setzt sich aus drei Hauptkomponenten zusammen: • OpenGL Library

Die OpenGL Library (z.B. GL.a unter Linux) enthält alle Implementierungen der Basis-Funktionen. Alle Basis-Funktionen beginnen mit dem Präfix „gl“. OpenGL-Befehle sind leistungsfähige, aber primitive, Rendering-Funktionen. Komplexe 3D- Modelle müssen durch eine Menge von einfachen geometrischen Objekten, wie Punkte, Linien und Polygone, aufgebaut werden.

• OpenGL Utility Library

Die GLU Library (z.B. GLU.a unter Linux) enthält eine Menge von Hilfsfunktionen, um komplexere 3D-Objekte wie Ellipsoide oder Splines zu erstellen. Nach der OpenGL-Konvention erhalten alle GLU-Funktionen den Präfix „glu“.

• Plattform/Window-System abhängige Library

Da OpenGL plattformunabhängig ist, wird für die Darstellung der gerenderten Grafik eine Plattform- und Window-System abhängige Library verwendet. Die wichtigsten sind:

o GLX: Für Unix / X-Window-Systeme o WGL: Für Microsoft Windows o GlPh: Für QNX-Photon

16

Außerdem existieren noch weitere Plattform- und Window-System unabhängigen Toolkits, die mit OpenGL zusammenarbeiten. Die bekanntesten sind:

o GLUT: Das OpenGL Utility Toolkit [GLUT] ist eine Open-Source Library

und wird oft in der Literatur als Beispiel verwendet.

o SDL: Die Simple DirectMedia Layer Library [SDL] ist ebenfalls Open-Source, wird überwiegend bei Computerspiele eingesetzt.

Im Folgenden werden einige Grundbegriffe von OpenGL erläutert, die für das Verständnis dieser Ausarbeitung wichtig sind. Eine umfassende Erläuterung dieses Kontexts ist in der weiterführenden Literatur [Shr04] verfasst.

2.1.2.1 OpenGL Konventionen Die Benennung der Funktionen und Konstanten bei OpenGL erfolgt über bestimmten Konventionen. Diese sind in Abbildung 7 zusammengefasst dargestellt.

glVertex3fx(...)

Wenn v, Vektor oder Array Version

Anzahl der Komponenten (2,3 oder 4)

Prefix für OpenGL-Befehle

Funktionsname

Suffix OpenGL-Typ Daten-Typ

f GLfloat 4-byte float

d GLdouble 8-byte float

b GLbyte signed 1-byte integer

s GLshort signed 2-byte integer

i GLint signed 4-byte integer

ub GLubyte unsigned 1-byte integer

us GLushortunsigned 2-byte integer

uI GLuint unsigned 4-byte integer

GLenum

GLbitfield

Abbildung 7 OpenGL Namenskonvention

Zum Beispiel setzt sich die Funktion glVertex3f() aus den folgenden Argumenten zusammen:

- Präfix: gl - Name: Vertex - Anzahl der Komponenten: 3 - OpenGL Typ der Operanden: f

Konstanten beginnen bei OpenGL immer mit dem Präfix „GL_“ und werden immer in großen Buchstaben geschrieben, z.B. GL_POINTS.

17

2.1.2.2 Programmstruktur Anhand eines einfachen Beispiels soll die Struktur eines OpenGL Programm gezeigt werden. Display *display = NULL; Window window; XVisualInfo *visualInfo = NULL; GLXContext glxContext; void main() { // X11-Code display = XOpenDisplay( NULL ); visualInfo = glXChooseVisual( display, DefaultScr een(display), ...); window = XCreateWindow( pDisplay, ...); XMapWindow( display, window ); // GLX-Code glxContext = glXCreateContext( display, visualInf o, NULL, GL_TRUE ); glXMakeCurrent( display, window, glxContext ); // OpenGL-Init-Code glClearColor( 0.0f, 0.0f, 0.0f, 1.0f ); glMatrixMode(GL_PROJECTION); glLoadIdentity(); glOrtho(-1.0f, 1.0f, 1.0f, 5.0f, 0.0f); glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); // 3D-Objekt-Code glColor3f(1.0f, 0.3f, 0.3f); glBegin(GL_QUADS); glVertex3f(0.25f, 0.25f, 0.0f); glVertex3f(0.75f, 0.25f, 0.0f); glVertex3f(0.75f, 0.75f, 0.0f); glVertex3f(0.25f, 0.75f, 0.0f); glEnd(); // GLX-SwapBuffer glXSwapBuffers( display, window ); ... }

Listing 1 Ein OpenGL Beispielprogramm Für die X11 Anbindung verwendet das Beispielprogramm GLX. Die wesentlichen Schritte sind: • Window-System initialisieren (X11-Code)

Mit den Funktionen XOpenDisplay() und XCreateWindow() wird ein Fenster unter X11 initialisiert.

• OpenGL-Context aus dem Window-System-Context erstellen (GLX-Code)

Der Handler bzw. Context des erstellten Fensters wird mit den Funktionen glXCreateContext() und glXMakeCurrent() an OpenGL übergeben. Damit wird die gerenderte Grafik auf diesem Fenster ausgegeben.

• OpenGL Grundeinstellung durchführen (OpenGL-Init-Code)

18

Grundeinstellungen, wie z.B. Projektionsmodus glOrtho () oder Hintergrundfarbe glClearColor() werden getätigt.

• 3D-Objekt erstellen (3D-Objekt-Code)

Beliebige Grafik-Objekte können an dieser Stelle mit den entsprechenden OpenGL-Funktionen erstellt werden. Ein geometrisches Objekt, z.B. GL_QUADS, wird durch eine Menge von Punkten (Vertices) beschrieben. Ein Punkt wird im OpenGL 3D-Raum wiederum durch die Funktion glVertex() definiert.

• Das gerenderte Ergebnis darstellen (GLX-SwapBuffer)

Das Ergebnis wird mit der Funktion glXSwapBuffers() auf dem Fenster gezeigt. In der Regel verwendet man bei OpenGL für das Rendering den Double-Buffer-Modus, d.h. das Rendering erfolgt zunächst auf dem Back-Buffer und erst nach Fertigstellung wird der Buffer umgeschaltet und damit sichtbar gemacht. Damit ist ein flüssiger Framewechsel möglich. Wird dagegen der Single-Buffer-Modus verwendet, so genügt ein glFlush() Aufruf um das Ergebnis anzuzeigen.

Es ist zu beachten, dass OpenGL eine State-Machine ist. D.h. die Zustände bzw. getätigten Einstellungen, z.B. die Hintergrundfarbe, bleiben so lange gültig bis zur nächsten Änderung.

2.1.2.3 Grafik-Primitive: Lines, Polygon… Wie bereits in Listing 1 gezeigt, erfolgt die Spezifikation eines geometrischen Objektes mit Hilfe des Funktionspaares glBegin() und glEnd() . D.h. alle Vertices innerhalb der glBeginn() und glEnd() Klammer gehören zu diesem Objekt. In der Funktion glBeginn() ist der Typ des geometrischen Objektes einzutragen. Es gibt zehn primitive Grafik-Typen in OpenGL. Diese sind in Abbildung 8 angeführt.

V0 V1 V2

V3 V4 V5

GL_POINTS GL_LINES

V0

V1V2 V3

V4

V5

V6

V7

V0

V1V2

V3

V4

V5

GL_LINE_STRIP

V0

V1V2

V3V4

GL_LINE_LOOP

V1

V2 V3

V4

GL_TRIANGLES

V0

V5

V0 V1 V2

V3V4

V5

GL_TRIANGLE_STRIP

V0

V1V2

V3V4

GL_TRIANGLE_FAN GL_QUADS

V0

V1 V2

V3V4

V5 V6

V7GL_QUADS_STRIPS

V1 V2

V3

V4

V5

V6

V7V0

V0V1

V2

V3V4

GL_POLYGON

Abbildung 8 Geometrische Objekte

2.1.2.4 Vertex Array Ein Vertex Array wird benutzt, um die Anzahl der Aufrufe von OpenGL-Befehlen zum Erstellen eines 3D-Objektes zu minimieren. Zum Beispiel benötigt das Programm in Listing 1 zum Zeichnen eines Viereckes sechs Aufrufe. Je einen Aufruf für glBegin() und glEnd() bzw. vier für die Vertex-Definitionen. Bei komplexeren Objekten steigt die Anzahl der OpenGL-Aufrufe entsprechend an. Ein weiteres Problem ist die redundante Angabe von gemeinsam genutzten Vertices. Das Problem wird im folgenden Beispiel erläutert: Der Würfel in Abbildung 9 soll z.B. gerendert werden.

19

0 1

2 3

4 5

6 7

Abbildung 9 Würfel mit acht Eckpunkte

Ein Würfel kann durch acht Eckpunkte und sechs Flächen beschrieben werden. Da OpenGL keinen Würfel als 3D-Objekt kennt, muss dieser durch einfache geometrische Objekte zusammengesetzt werden. Verwendet man dafür als Grafik-Primitive ein Viereck (GL_QUADS), so werden sechs GL_QUADS Objekte mit je vier Vertices benötigt. Das sind insgesamt 24 glVertex() -Aufrufe. Die Summe der Aufrufe ist nicht effizient. Die Lösung dieses Problem ist ein Vertex-Array. Dabei werden die Koordinaten der Vertices eines 3D-Objektes in einem Array gespeichert und mit einem einzigen Befehl an OpenGL weitergeleitet. Darüber hinaus können auf gemeinsam genutzte Vertices mit Hilfe von Index-Listen zugegriffen werden. Das folgende Beispiel zeigt die Verwendung eines Vertex-Arrays. static GLfloat myVertices[] = { 0.25f, 0.25f, 0.0f, 0.75f, 0.25f, 0.0f, 0.75f, 0.75f, 0.0f, 0.25f, 0.75f, 0.0f }; static Glubyte triangleIndices[] = { 0, 1, 2 }; glEnableClientState(GL_VERTEX_ARRAY); glVertexPointer(3, GL_FLOAT, 0, myVertices); glDrawElements(GL_TRIANGLES, 3, GL_UNSIGNED_BYTE, t riangleIndices); Beispiel mit Vertex Array, ein Dreieck wird gezeichnet Als erstes muss das Array mit der Funktion glEnableClientState() aktiviert werden. Dann wird das Array mit glVertexPointer() an OpenGL übergeben. Schließlich wird das Objekt durch ein Vertex-Index-Array dereferenziert und mit der Funktion glDrawElements() gerendert. In der Praxis ist die Verwendung von Vertex-Array bei komplexeren 3D-Objekte unabdingbar.

2.1.2.5 Koordinatensystem und Transformation OpenGL verwendet ein 3-dimensionales Euklidisches Koordinatensystem. Die Ausrichtungen der x, y und z-Achsen ist in Abbildung 10 abgebildet.

20

+y

-y

-x +x

+z

-z

Abbildung 10 Das OpenGL Koordinatensystem

Ein 3D-Objekt wird durch seine Vertices spezifiziert. Für die Visualisierung muss das 3D-Objekt zunächst im Koordinatensystem positioniert werden. Anschließend sind eine Reihe von weiteren Transformationen bis zum fertigen Ergebnis notwendig. Abbildung 11 zeigt die erforderlichen Transformationsstufen.

Abbildung 11 Transformationsstufen • Modell-View Transformation

In dieser Stufe wird das 3D-Objekt im 3D-Raum auf die richtige Position (Translation, Rotation) gebracht. Außerdem wird die Kamera-Position eingestellt.

• Projektions-Transformation

Je nach Projektionsmodus (perspektivisch oder orthogonal) und je nach Parameter werden die Koordinaten entsprechend transformiert.

• Normierung und Viewport Transformation

Zum Schluss werden die Koordinaten in die Ausgabegeräte spezifische Koordination transformiert.

3D-Transformationen werden in der Computergrafik durch Matrix-Multiplikation realisiert. Eine Transformationsmatrix ist eine 4 x 4 Matrix. Bei der Transformation werden die Koordinaten eines jeden Punktes in der 3D-Welt mit dieser Matrix multipliziert. Matrix-Multiplikation in OpenGL wird immer auf den Matrix-Stack angewendet, d.h. die als Operand übergebene Transformationsmatrix wird mit der „aktuellen“ (Top of Stack) Matrix

21

multipliziert. Das Ergebnis davon bleibt als aktuelle Matrix auf dem Stack. Wenn also C die aktuelle Matrix und M die Transformationsmatrix ist, dann ist das Ergebnis nach der Multiplikation immer C·M. OpenGL bietet folgende Funktionen für die Matrix-Multiplikation an. • glLoadMatrixf(const GLfloat *M)

Eine 4 x 4 Matrix wird als die aktuelle Matrix geladen.

• glLoadIdentity(GLvoid)

Die Einheitsmatrix wird geladen, die Einheitsmatrix wird zum Initialisieren benötigt.

• glMultMatrix(const GLfloat *M)

Die eigentliche Multiplikationsfunktion. Die als Parameter übergegebene Matrix wird mit der Aktuellen Matrix multipliziert.

• glPushMatrix(GLvoid), glPopMatrix(GLvoid)

Matrizen auf dem Matrix-Stack werden mit glPushMatrix() eine Stufe nach unten verschoben und mit glPopMatrix() aus dem Stack gelöscht.

Diese Funktionen beziehen sich immer auf den aktuell ausgewählten Matrix-Modus. Der Matrix-Modus kann mit der Funktion glMatrixMode() eingestellt werden. Mögliche Werte sind: GL_MODELVIEW, GL_PROJECTION und GL_TEXTURE.

2.1.2.6 Modell- und View-Transformation • Modell Transformation

Translation, Rotation und Skalierung von 3D-Objekten sind grundlegende Operationen bei der Modell-Transformation (siehe Abbildung 12).

+y

+x

+z

+y

+x

+z

+y

+x

+z

(a) (b) (c)

Abbildung 12 (a) Translation, (b) Rotation und (c) Skalierung

Bei OpenGL sind folgende Funktionen vorgesehen:

o glTranslate() o glRotate() o glScale()

• View Transformation

Der Ansichtspunkt (View Point) oder die Kamera-Position werden mit der Funktion

22

gluLookAt( eyeX, eyeY, eyeZ, centerX, centerY, centerZ, upX, upY, upZ)

eingestellt. Dabei spezifizieren die eye* Parameter die Position der Kamera und die center* Parameter den Mittelpunkt auf den die Kamera gerichtet ist. Die up* Parameter geben den sog. Up-Vektor an, also die „Orientierung“ des Ansichtspunktes (siehe Abbildung 13)

Abbildung 13 View-Transformation

2.1.2.7 Projektion Transformation Nach der Modell-View-Transformation sind alle Punkte der 3D-Objekte an der richtigen Position im 3D-Raum. Für die Darstellung auf einem 2D-Display müssen die Punkte jedoch entsprechend der Projektionsregeln erneut transformiert werden. In OpenGL sind zwei Projektionstransformationen möglich: die orthogonale (parallel-) und die perspektivische Transformation. • Orthogonale Projektion

In der orthogonalen Projektion werden alle Punkte durch parallele Strahlen auf die Projektionsfläche abgebildet. Die Größen und Winkel der Objekte bleiben konstant, unabhängig von der Entfernung der Kamera. Diese Projektionsart wird vor allem bei CAD-Systemen verwendet. Eine orthogonale Projektion kann in OpenGL mit der folgenden Funktion eingestellt werden:

glOrtho( left, right, bottom, top, near, far )

Die Bedeutung der Parameter ist in Abbildung 14 dargestellt. Für eine 2D-Darstellung mit OpenGL kann ebenso die Funktion glOrth2D() verwendet werden.

23

far

near

right

bottom

top

left

Abbildung 14 Orthografische Projektion • Perspektivische Projektion

Objekte erscheinen bei der perspektivischen Projektion zunehmend kleiner, je weiter sie von der Kamera entfernt sind. Die perspektivische Projektion kann in OpenGL auf zwei Arten definiert werden.

o glFrustum( left, right, bottom, top, near, far)

o gluPerspective( fovy, aspect, near, far)

Die Parameter der beiden Funktionen sind in Abbildung 15 dargestellt. Der Parameter fovy ist der vertikale (y- / z-Achse) Blickwinkel mit einem Wertebereich von 0° bis 180°. Der Parameter aspect ist das Verhältnis zwischen dem horizontalen und vertikalen Blickwinkel.

24

bottom

top

rightleft

near far

h

Aspect=w/h

w

near farfovy θ

(a) (b)

Abbildung 15 Perspektivische Projektion. (a) glFrustum(), (a) gluPerspective()

2.1.2.8 Texture Mapping Mit Texture-Mapping kann man eine Textur als Oberfläche für ein grafisches Objekt zuweisen. Eine Textur ist in der Regel ein zwei dimensionales Bild11. Ein Datenelement in der Textur wird Texel genannt. Das Prinzip des Texture-Mappings ist in Abbildung 16 gezeigt.

p1 p2

p3p4

t1 t2

t3t4 3D Objekt

Texture-Image

Abbildung 16 Texture-mapping

Jeder Punkt des 3D-Objektes bekommt als zusätzliche Information die Koordinaten des Texels zugeordnet. Dabei beziehen sich die Texel-Koordinaten immer auf das aktuelle Textur-Objekt. Die benötigte Funktion glTextCoord2f() wird wie folgt in Verbindung mit glVertex3f() verwendet.

11 engl. image

25

glBegin(GL_QUADS); glTextCoord2f(0.0f, 0.0f); glVertex3f(0.25f, 0. 25f, 0.0f); glTextCoord2f(1.0f, 0.0f); glVertex3f(0.75f, 0. 25f, 0.0f); glTextCoord2f(1.0f, 1.0f); glVertex3f(0.75f, 0. 75f, 0.0f); glTextCoord2f(0.0f, 1.0f); glVertex3f(0.25f, 0. 75f, 0.0f); glEnd(); Beispiel mit glTextCoord

Eine moderne 3D-Grafikkarte verwendet eine spezielle Texture-Engine und einen Texture-Speicher, um das Rendering zu beschleunigen. Es ist nicht sinnvoll Texturen bei jedem Frame an die 3D-Engine zu schicken. Texturen werden daher in OpenGL als Textur-Objekte verwaltet und je nach Implementierung im Video-Speicher abgelegt. Ein 3D-Objekt kann ein Textur-Objekt über ein von OpenGL generiertes Index (Name) referenzieren. Das folgende Beispiel zeigt diesen Mechanismus. glGenTextures(1, &texName); glBindTexture(GL_TEXTURE_2D, texName); glTexParameteri(GL_TEXTURE_2D, ...); glTexImage2D(GL_TEXTURE_2D, 0, GL_RAGBA, width, h igh, 0, GL_RGBA, GL_UNSIGNED_BYTE, myImag e); ... glBindTexture(GL_TEXTURE_2D, texName); glBegin(GL_QUADS); glTextCoord2f(0.0f, 0.0f); glVertex3f(0.25f, 0. 25f, 0.0f); ... glEnd(); Beispiel mit glGenTextures Mit der Funktion glGenTextures() wird ein freier Index für ein neues Textur-Objekt ermittelt und mit glBindTexture () initialisiert. Weitere Eigenschaften können mit der Funktion glTexParameteri () eingestellt werden. Die Funktion glTexImage2D () lädt schließlich das Image zu dem Textur-Objekt. Ein mit glBindTexture () aktiviertes Textur-Objekt hat bis zum erneuten Aufruf Gültigkeit für alle folgenden Objekt-Definitionen.

2.2 Implementierung Für die Entwicklung von 3D-Appliaktionen mit OpenGL bietet die Firma QNX ein 3D-Graphic Technology Development Kit (TDK)12 an. Das Paket enthält neben den Basis OpenGL-Libraries auch ein Framework für die QNX-Photon-Anbindung13. Ausserdem werden für einige unterstützte Grafik-Chipsätze OpenGL-Treiber mit Hardwarebeschleunigung zur Verfügung gestellt. Für die Implementierung der Aufgabe stand das TDK nicht zur Verfügung, was jedoch keine negativen Auswirkungen auf die angestrebten Untersuchungen hatte. Eine hardwarebeschleunigte OpenGL-Implementierung für den im Target verwendeten Grafik-Chip Lynx3DM von Silicon Motion14 war ohnehin nicht verfügbar, obwohl der Chip

12 vgl. [QNX3D] 13 Details zum GLPh-Framework sind in [Photon04] beschrieben. 14 vgl. [SMLynx]

26

hardwareseitige 3D-Beschleunigungsfunktionen kennt. Des Weiteren existiert eine Open-Source OpenGL-Implementierung namens Mesa15, die 3D-Rendering auf Softwarebasis anbietet. Die Mesa-Libraries sind feste Bestandteile der gängigen Linux-Distribution und somit bei fast allen Linux-Rechnern ohne spezielle 3D-Grafikkarte im Einsatz. Aus diesen Gründen wurde entschieden für die Durchführung der vorliegenden Arbeit die Mesa-Libraries auf QNX-X86 und QNX-SH4 zu portieren. Details über die Portierung sind in Kapitel 2.2.1 beschrieben. Ein weiteres Problem ist das fehlende GLPh-Framework. Schließlich muss die gerenderte Grafik auch angezeigt werden. Die fehlende Verbindung zum Window-System Photon musste daher selbst entwickelt werden. Diese wurde prototypisch implementiert und ist in Kapitel 2.2.2 aufgeführt. Die für Demonstrationszwecke zu entwickelnde 3D-GUI wird in Kapitel 2.2.3 beschrieben.

2.2.1 Mesa Für die Portierung auf QNX wurde die Mesa-Library in der Version 6.0 benutzt. Folgende Änderungen sind dafür nötig gewesen: • Das Buildscript ./Make-config # QNX V4 & Watcom Compiler #qnx: # $(MAKE) $(MFLAGS) -f Makefile.X11 targets \ # "GL_LIB = libGL.a" \ # "GLU_LIB = libGLU.a" \ # "GLUT_LIB = libglut.a" \ # "GLW_LIB = libGLw.a" \ # "OSMESA_LIB = libOSMesa.a" \ # "CC = qcc" \ # "CFLAGS = -O" \ # "APP_LIB_DEPS = -L/usr/X11/lib -lX11 -lm" qnx: $(MAKE) $(MFLAGS) -f Makefile.X11 targets \ "GL_LIB = libGL.a" \ "GLU_LIB = libGLU.a" \ "GLUT_LIB = libglut.a" \ "GLW_LIB = libGLw.a" \ "OSMESA_LIB = libOSMesa.a" \ "CC = qcc" \ "CFLAGS = -O -Y_ecpp-ne -I/usr/X11R6/include - \ DDEFAULT_SOFTWARE_DEPTH_BITS=31" \ "APP_LIB_DEPS = -L/usr/X11R6/lib -lglut -lGLU -lG L -lX11 -lm" Änderungen in der Datei Make-config • Das Shellscript ./bin/mklib 'QNX')

15 vgl. [Mesa]

27

LIBNAME="lib${LIBNAME}.a" echo "mklib: Making QNX library: " ${LIBNAME} ar -ruv ${LIBNAME} ${OBJECTS} FINAL_LIBS=${LIBNAME} ;; Änderungen in der Datei ./bin/mklib Da es keine offizielle QNX-Photon Unterstützung von Mesa gibt, wird die Library als eine Unix-Variante erstellt. Hierbei ist das Problem, dass Mesa bei einem Unix-Build die C-Header-Dateien von X11 benötigt. Diese Header-Dateien können, falls nicht bereits vorhanden, aus dem Open-Source XFree86-Distribution für QNX nachträglich installiert werden. Alternativ kann die Mesa-Library auch als Offscreen-Version „gebaut“ werden. In diesem Fall sind die X11-Header nicht mehr erforderlich. Für die SH4-Offscreen-Version sind folgende Änderungen nötig. qnx: $(MAKE) $(MFLAGS) -f Makefile.X11 targets \ "GL_LIB = libGL.so" \ "GLU_LIB = libGLU.so" \ "GLUT_LIB = libglut.so" \ "GLW_LIB = libGLw.so" \ "OSMESA_LIB = libOSMesa.so" \ "CC = qcc" \ "CFLAGS = -O -Y_ecpp-ne -DDEFAULT_SOFTWARE_DEPTH_ BITS=31 \ -Vgcc_ntoshle" \ "APP_LIB_DEPS = -lGLU -lGL -lm" Änderungen in der Datei Make-config für OS-Mesa und SH4

2.2.2 OpenGL Photon Anbindung Die Library für die OpenGL-X-Window Anbindung, GLX, verwendet für die Darstellung einer von OpenGL gerenderten Grafik drei Funktionen (vgl. Listing 1): • CreateContext • MakeCurrent • SwapBuffer Für die Problemlösung ist es nahe liegend, aus dem Sourcecode von GLX die entsprechenden Funktionen zu extrahieren und zu portieren. Ein Blick in den Sourcecode von Mesa sowie in die GLX Library zeigt jedoch, dass die Implementierung recht komplex und umfangreich ist. Eine Portierung in einem vernünftigen Zeitrahmen war daher nicht möglich. Alternativ kann man die Offscreen-Version von Mesa verwenden. Die Idee dabei ist anstatt die Grafik direkt auf einem Ausgabefenster anzuzeigen, das Ergebnis im Offscreen-Modus in einen Image-Buffer zu rendern. Dieser Buffer wird anschließend über normale Photon-Funktionen auf dem Bildschirm angezeigt. Diese Methode ist sicherlich nicht besonders effizient, aber portabler und einfacher zu realisieren. Für die Implementierung des Prototyps wurde daher diese Methode verwendet. Liegt eine Grafik in einem Image-Buffer vor, so gibt es mehrere Möglichkeiten die Grafik auf einem QNX-Photon Fenster anzuzeigen.

28

• Label-Widget

Die einfachste Möglichkeit, ein Image auf einem Photon-Fenster anzuzeigen, ist die Verwendung einees Label-Widget mit einem Image als Inhalt. Solch ein Widget kann mit dem Photon-GUI-Builder erstellt werden. Im Programm wird eine neue Image-Struktur mit dem Inhalt der gerenderten Grafik dem Label-Widget zugewiesen. Der folgende Code zeigt ein Beispiel.

PhImage_t *img; img = PhCreateImage(NULL,width,height,Pg_IMAGE_DIRE CT_8888,NULL,0,0); ... img->image = (char*) myOpenGLBuffer; PtSetResource( ABW_3Dlabel, Pt_ARG_LABEL_IMAGE, img , 0); PtFlush(); ... Label-Widget Beispiel • Memory und Shared Memory Blit16

Bei dieser Methode wird die Funktion PgDrawImage verwendet. Im Gegensatz zu der ersten Methode wird das Image nicht über die Widget-Library, sondern direkt zum Photon-Window-Manager geschickt. Ein Image kann beispielsweise wie folgt angezeigt werden:

unsigned short *image; // 16 bit RGB565 Data ... image = (unsigned short*) malloc(width * height * 2 ); ... PhPoint_t pos = {0, 0}; PhDim_t size = {width, height}; PgDrawImage(image, 0, &pos, &size, pitch, 0); pgFlush(); Memory Blit Beispiel

Unter QNX läuft das Window-System und die Applikation in unterschiedlichen Prozessen. Für die Anzeige muss das Image daher komplett von der Applikation zum Window-System/Grafik-Treiber in Form von Messages übertragen werden. Um eine bessere Performance zu erzielen, bietet Photon u.a. die Funktion PgDrawImagemx() an, die Shared-Memory als Image-Buffer verwendet, Dadurch entfällt die zeitaufwendige Übertragung der Image-Daten. Ein Shared-Memory-Buffer kann mit der Funktion PgShmemCreate() erstellt werden, Details dazu siehe [Photon].

unsigned short *image; // 16 bit RGB565 Data ... image = (unsigned short*) PgShmemCreate(width * hei ght * 2, NULL); ... PhPoint_t pos = {0, 0}; PhDim_t size = {width, height}; PgDrawImagemx(image, 0, &pos, &size, pitch, 0); pgFlush();

16 vgl . [Feh04]

29

Shared Memory Blit Beispiel mit PdDrawImagemx

Prinzipiell wird das Image immer noch zum Window-Manager kopiert. Der Vorteil ist allerdings, dass das Kopieren des Images aus dem Shared-Memory schneller vonstatten geht. Zu beachten ist dabei, dass der Shared-Memory nach der Benutzung wieder freigegeben wird, um „Shared-Memory-Leak“ zu vermeiden. Die aktuell im System belegten Shared-Memories sind im Device-Verzeichnis /dev/shmem zu sehen.

• Video Memory Blit

Eine weitere Methode um die Performace zu steigen, ist die Verwendung von Video-Speicher als Image-Buffer. Dadurch entfällt der externe Kopier-Vorgang des Image-Buffers. Der folgende Code zeigt die benötigten Funktionen.

unsigned short *image; // 16 bit RGB565 Data PdOffscreenContext_t *ctx; ... ctx = PdCreateOffscreenContext(0, width, height, Pg _OSC_MEM_PAGE_ALIGN); image = PdGetOffscreenContextPtr(ctx); ... PhRect_t rect = { {0, 0}, {width, height} }; PgContextBlit(ctx, &rect, NULL, &rect); pgFlush(); Video Memory Blit Beispiel

Die Verwendung von Video-Speicher hat jedoch einige Einschränkungen. Zum Beispiel ist der Video-Speicher in der Regel auf einer relativ kleine Größe beschränkt. Eine Art „virtueller Video-Speicher“ um den Speicher zu vergrößern existiert nicht. Außerdem ist das Anlegen bzw. Initialisieren von Video-Speicher sehr zeitaufwendig.

• Video Memory Blit im Direct-Mode

Eine weitere, wenn auch nur minimale Performance-Steigerung kann durch die Grafik-Ausgabe im Direct-Mode erzielt werden.

unsigned short *image; // 16 bit RGB565 Data PdOffscreenContext_t *ctx; ... PdDirectContext_t *direct_ctx; direct_ctx = PdCreateDirectContext(); PdDirectStart(direct_ctx); ... ctx = PdCreateOffscreenContext(0, width, height, Pg _OSC_MEM_PAGE_ALIGN); image = PdGetOffscreenContextPtr(ctx); ... PhRect_t rect = { {0, 0}, {width, height} }; PgContextBlit(ctx, &rect, NULL, &rect); pgFlush(); Direct-Mode Beispiel

Der Window-Manager wird in diesem Fall deaktiviert und das Anwendungsprogramm hat die alleinige Kontrolle über den Grafik-Device. Die

30

Konsequenz davon ist, dass die Maus sowie alle vom Window-Manager verwalteten Eingabe-Geräte ebenfalls deaktiviert werden.

Für die Implementierung der glICM-Funktionen wurden die letzten beiden Methoden gewählt. Die Auswahl von Direct-Mode erfolgt über ein Parameter beim Aufruf der createContext () Funktion. Listing 2 zeigt ein Auszug davon. ... int glICMCreateContext(int width, int height, int d irectMode) { ... // Start Direct Mode if (directMode) { // Create the direct context direct_context = PdCreateDirectContext(); PdDirectStart(direct_context); } else { glICMInitPhotonWindow(); } ... // Create the offscreen context buff=PdCreateOffscreenContext(0, screenWidth, scr eenHeight+1, Pg_OSC_MEM_PAGE_ALIGN | Pg_OSC_MEM_2D_WRITABLE) ; ... OSMesaBuffer = (unsigned char *) PdGetOffscreenCo ntextPtr(buff); glICMOSMesaInit(); return; } int glICMOSMesaInit(void) { OSMesaCtx = OSMesaCreateContextExt( OSMESA_RGB_56 5, 8, 8, 8, NULL ); ... } int glICMMakeCurrent() { if (!OSMesaMakeCurrent( OSMesaCtx, OSMesaBuffer, GL_UNSIGNED_SHORT_5_6_5, screenWidth, scre enHeight )) { printf("OSMesaMakeCurrent failed!\n"); return 0; } return 1; } void glICMSwapBuffer(void) { glICMSwapImage(OSMesaBuffer, screenHeight, screen Width, 2); PgContextBlit(buff,&rect, NULL, &rect); PgFlush(); }

Listing 2 Implementierung der glICM Funktionen

2.2.3 3D GUI Als Animation soll eine aufklappbare Bedientafel realisiert werden. Nach dem Aufklappen soll eine Instrumententafel erscheinen. Abbildung 17 zeigt den schematischen Aufbau.

31

+y

+z

+x +x-x

+z

+y

(a) (b)

Abbildung 17 (a) GUI in der normalen Stellung. (b) GUI in der aufgeklappten Stellung

Die Bedien- und Instrumententafel werden in OpenGL als GL_QUAD mit jeweils vier Punkten definiert und mit den dazugehörigen Texturen überzogen.

2.3 Diskussion Die implementierte GUI ist eine einfache OpenGL-Anwendung und zeigt praktische Beispiele der OpenGL-Programmierung. Das definierte Ziel, eine 3D-GUI mit OpenGL zum Demonstrationszweck zu entwickeln und in ein Automotive-Framework zu integrieren, wurde erreicht. Die erfolgreiche Portierung von Mesa war ausschließlich auf Anpassungen des Buildscripts beschränkt. Das zeigt, dass der C-Code von Mesa plattformunabhängig geschrieben wurde. Auch die ausgereifte Cross-Compile-Technologie von QNX / GNU wird hier eindrucksvoll bestätigt. Zwischen der x86 und SH4 Version wurden selbst bei einer derart komplexen Library keine Unterschiede festgestellt. Die selbstentwickelte glICM-Funktion hat nur prototypischen Charakter und dient hier lediglich als Ersatz für das fehlende GlPh-Framework. Durch diese Realisierung wurden gute Einblicke in das Window-System Photon gewonnen. Die im Target eingesetzte Grafik-Chip, ein Silicon Motion Lynx3DM, ist hardwareseitig bereits mit multimedia- und 3D-Beschleunigungsfunktionen ausgestattet. Leider ist eine hardwarebeschleunigte OpenGL-Implementierung nur als kommerzielle Individuallösung erhältlich. Ein Blick in deren Datenblätter lassen interessante Möglichkeiten vermuten. Eine Gegenüberstellung der Applikationsgröße mit und ohne 3D-Grafik zeigt Tabelle 1. Auf dem Target beträgt der Mehrverbauch an Speicher etwa 1,8 MB.

32

Mit statisch gelinken

Mesa-Libraries Ohne 3D-Grafik

SH4 3,7 MB 1,9 MB SH4 mit Debug-Option 6,8 MB 5,0 MB X86 3,5 MB 1,9 MB X86 mit Debug-Option 7,1 MB 5,7 MB

Tabelle 1 Gegenüberstellung der Applikationsgröße mit und ohne 3D-Grafik

Die in diesem Kaptitel portierten und implementierten OpenGL-Funktionen dienen als Basis für die Untersuchungen in den Kapiteln 3, 4 und 5. Insbesondere in Kapitel 3 wird eine komplexerer OpenGL-Anwendung, die die 3D-Engine wesentlich mehr belastet, auf das Target portiert und untersucht.

33

3 Geländedarstellung Haupteinsatzgebiet von Echtzeit 3D-Grafik in einem InCar-Multimedia-System ist die Darstellung von Navigationskarten. Bisherige Systemen haben meistens einen 3D-Modus, der jedoch nur 2D-Karten in einer Perspektivendarstellung anzeigt. Das liegt einerseits daran, dass das kommerziell verfügbare Kartenmaterial nur als 2D-Information vorliegt, andererseits hat die Grafikfähigkeit der Hardware Grenzen. Eine Perspektiven-2D-Darstellung trägt zwar zu einer besserer Orientierung des Benutzers bei, jedoch erhöht sich der Informationsgewinn für ihn, wenn die Straßenkarte in einem 3D-Gelände integriert visualisiert wird. Im Rahmen dieser Arbeit soll daher ein geeigneter Gelände-Visualisierungsalgorithmus prototypisch auf dem Target implementiert werden. Ziel der Untersuchung ist zu evaluieren, inwieweit ein solches Visualisierungsverfahren, das in der Regel für High-End-Workstation konzipiert ist, auf dem Target angewendet werden kann. In Kapitel 3.1 wird zunächst auf die Probleme und Grundlagen der Gelände-Visualisierung eingegangen. Die Implementierung des Verfahrens wird in Kapitel 3.2 erläutert. Die Ergebnisse der Evaluierung werden schließlich in Kapitel 3.3 zusammengefasst und diskutiert.

3.1 Grundlagen Als Beispiel wird ein Gelände mit der Größe von 100.000m x 100.000m, das in 1m Auflösung dargestellt werden soll, betrachtet. Die Höhendaten liegen, wie im Bereich der Gelände-Visualisierung üblich, in einer sog. Heightmap vor. Eine Heightmap ist ein zweidimensionales Array, in dem die Höhendaten als Wert gespeichert sind. Dabei entsprechen die Indizes den x und y Koordinaten des Geländes. Die einfachste Möglichkeit, das Gelände darzustellen, ist ein quadratisches Dreieck-Gitter aufzubauen (Abbildung 18).

Abbildung 18 Darstellung eines Geländes mit einem quadratischen Dreieck-Gitter

Zwei Probleme treten bei diesem Beispiel auf. Erstens, das Gitter ist mit einer Größe von ca. 120GB17 ziemlich groß. Zweitens, für die Darstellung des Geländes werden ca. 20 Milliarden18 Dreiecke benötigt, die dann von der 3D-Engine gerendert werden.

17 100.000 · 100.000 · 3 Punkte · 4 Byte für Float-Variable pro Punkt 18 Formel: (n -2)2 · 2 mit n = Anzahl der Punkte

34

Für das erste Problem hilft nur, eine niedrigere Auflösung zu nehmen. Ein 1k x 1k Gitter ist für die heutige Hardware eine gängige Größe. Das zweite Problem kann durch den Einsatz von einem LOD (Level of Detail) Algorithmus effektiv gelöst werden. Das Grundprinzip eines LOD Algorithmus ist, das Originalgelände (repräsentiert durch eine Heightmap oder eine vergleichbare Struktur) durch ein entsprechend vereinfachtes Gitter zu approximieren. Das generierte Gitter soll dabei so wenig Punkte/Dreiecke wie nötig enthalten und gleichzeitig so viele Details wie möglich darstellen. Abbildung 19 zeigt den Idealfall; eine ebene Fläche kann durch einige wenige Dreiecke dargestellt werden.

(a) (b)

Abbildung 19 (a) Darstellung als vollständiges Gitter. (b) Darstellung mit LOD LOD Verfahren werden in zwei Gruppen eingeteilt: diskrete und kontinuierliche LOD Verfahren. Diskrete Verfahren arbeiten mit einer festen Anzahl von statischen Modellen/Gittern mit unterschiedlichen Auflösungen. Werden zur Laufzeit mehr Details gefordert, so wird das Gitter mit der nächst höheren Auflösung eingeblendet. Solche Verfahren kommen meistens zum Einsatz, wenn LOD auf 3D-Objekte angewendet werden. Für die Darstellung von Flächen und Geländen sind die CLOD (continuous LOD) Verfahren besser geeignet. Bei CLOD gibt es keine festen Detailstufen, die Detaillierung des Gitters wird dynamisch generiert. Eine typische Vorgehensweise ist die Darstellung des Gitters als Quadtree, um darauf eine rekursive Verfeinerung auf die einzelnen Teil-Quadranten des Gitters vorzunehmen (siehe Abbildung 20).

Abbildung 20 Quadtree Hierarchie

Um zu entscheiden, ob ein betroffener Quadrant weiter verfeinert wird, wird ein sog. „Vertex Interpolation Error“19 berechnet. Überschreitet der Vertex-Interpolation-Error einen bestimmten Schwellenwert, so wird dieser Quadrant rekursiv verfeinert. Je nach Algorithmus werden für den Vertex-Interpolation-Error unterschiedliche Aspekte berücksichtigt. Im einfachsten Fall ist es der Höhenunterschied des Punktes zwischen den einzelnen Detail-Levels (siehe Abbildung 21). Auch die Entfernung des Punktes zum Betrachter wird häufig in die Berechnung einbezogen; je weiter die Punkte entfernt liegen, desto weniger Details sind erforderlich.

19 vgl [Ulr00]

35

Abbildung 21 Höhenunterschied zwischen Original-Punkt und der approximierten Stelle (weißer Punkt). Für eine flüssige Animation, wie etwa bei einem Flugsimulator, ist eine Frame-Rate von mindesten 25 Frames pro Sekunde erforderlich. Um solche Anforderung zu erfüllen, arbeiten die meisten LOD-Verfahren mit einem dynamischen Schwellenwert für den Vertex- Interpolation-Error. Diese Fehlerschranke steuert direkt den Detaillierungsgrad der Darstellung. Dauert die Berechnung von einem Frame zu lange, so kann man für den nächsten Frame die Detaillierung verringern. Damit ist eine ruckfreie Animation gewährleistet.

3.1.1 Der SOAR (Stateless One-pass Adaptive Refinement) Algorithmus Für die Evaluierung wurde eine auf dem SOAR-Algorithmus basierte Implementierung auf dem Target adaptiert. Das SOAR-Verfahren wurde von Peter Lindstrom und Valerio Pascucci an der Lawrence Livermore National Laboratory20 entwickelt und zählt zu den am häufigsten eingesetzten LOD-Verfahren. Im Gegensatz zu anderen vergleichbaren Verfahren wird bei SOAR das Gitter für jeden Frame komplett neu generiert. Das Kernstück des Verfahrens ist der Verfeinerungs-(Refinement)Algorithmus. Dieser basiert auf der „longest edge bisection“, wobei ein Dreieck beim Verfeinern mittig durch seine Hypotenuse in zwei gleich große, rechtwinklige Teil-Dreiecke aufgeteilt wird (Abbildung 22).

Abbildung 22 Longest edge bisection

Diese Teilung wird sehr häufig bei LOD-Verfahren angewendet und hat zwei entscheidende Vorteile. Erstens, die Teilung kann völlig lokal und unabhängig vom gesamten Gitter durchgeführt werden. Zweitens, die durch die Teilung entstandenen Punkte ergeben sich wieder zu einem Quadrat; das Texture-Mapping beim Rendern wird dadurch vereinfacht. Ausgangpunkt der Verfeinerung ist ein Gitter mit vier Dreiecken bestehend aus den vier Eckpunkten und einem Mittelpunkt (siehe Abbildung 23a), welches die gesamte Geländefläche repräsentiert. Ausgehend von dieser Stufe wird das Gitter rekursiv per Edge- Bisection in kleineren Dreiecken aufgeteilt (Abbildung 23b,c). Die Eckpunkte der so entstandenen Dreiecke werden als neue Punkte in das Gitter aufgenommen. Die Entscheidung über die Teilung/Verfeinerung eines Teil-Quadranten erfolgt, wie bereits erwähnt, über die

20 vgl. [Lin01]

36

Auswertung des Vertex-Interpolation-Errors. Eine ausführliche Darstellung des Verfahrens ist in [Lin01] beschrieben.

(a) (b) (c)

Abbildung 23 Rekursive Verfeinerung Eine Besonderheit der eingesetzten Implementierung ist, dass die Heightmap-Daten direkt als Vertex-Array (Array von 3D-Koordinaten) an OpenGL mit der Funktion glArrayPointer() übergeben werden. Das Aufnehmen eines neuen Punktes bei der Verfeinerung in dem generierten Gitter bedeutet einfach das Hinzufügen des Indizes dieses Punktes in die Index-Liste. Diese Liste wird dann zum Rendern des Geländes an OpenGL übergeben21. Damit ist eine Speicherung der Gitterpunkte etwa in Form von Quadtree nicht mehr erforderlich. Der Ablauf des Verfeinerungsalgorithmus ist in Abbildung 24 schematisch dargestellt.

21 vgl. Kapitel 2.1.2

37

Abbildung 24 Schematischer Ablauf des Verfeinerungsalgorithmus

Die Schritte sind folgendermaßen: • Starten der Verfeinerung mit einem Gitter wie in Abbildung 23a. • In der Verfeinerungsfunktion wird zuerst der Vertex-Interpolation-Error des

Mittelpunktes r, siehe (1), ermittelt. Ist der Error kleiner als der Schwellenwert, dann ist eine Verfeinerung nicht erforderlich; die Rekursion kann abgebrochen werden.

• Beginn der Verfeinerung. • Ist eine Verfeinerung am Punkt p1 erforderlich? D.h. Fehler am Punkt p1 >

Schwellwert. • Ist eine Verfeinerung am Punkt p2 erforderlich (3)?

• Wenn ja, Quadrant A rekursiv verfeinern (4). Nach der Verfeinerung können hier zwei Fälle entstehen:

• Wenn Quadrant A verfeinert wurde, dann sind alle darin enthaltenen Punkte bereits in das Gitter aufgenommen (5). Keine weitere Aktion ist erforderlich.

38

• Wurde aber die Verfeinerung nicht durchgeführt, weil der Fehler zu klein ist, so ist es auf jeden Fall sicher, dass der Quadrant A, wie in (6) dargestellt, gerendert wird.

• Ist Verfeinierung am Punkt p3 erforderlich (7)? • Quadrant B rekursiv verfeinern (11). Nach der Verfeinerung können

hier zwei Fälle entstehen ...

• Wenn am Punkt p2 nicht verfeinert wird (3), dann erfolgt die Abbildung der Dreiecke wie in (10). • Verfeinerung am Punkt p3 ...

• Am Punkt p1 wird nicht verfeinert. D.h. die Darstellung erfolgt wie in (8).

• Fortfahren mit der Prüfung am Punkt p2...(9) Es gibt somit insgesamt 16 Fall-Unterscheidungen für das Verfeinern eines Quadranten.

3.2 Implementierung Die als Basis herangezogene Experiment-Implementierung liegt als lauffähiges C/C++-Programm unter Windows vor. Für die Anbindung von OpenGL an das Window-System wurde SDL eingesetzt. Die Heightmap liegt in der Auflösung von 1025 x 1025 in BMP Format vor. Eine Texture-Grafik für das Gelände mit einer Auflösung von 1024 x 1024 (siehe Abbildung 25) sowie Bilder für den Hintergrund (Skybox) sind ebenfalls vorhanden. Eine Skybox ist ein überdimensionierter Würfel, welcher mit sechs vordefinierten Texturen um die gesamten 3D-Szene herum gezeichnet wird und bildet damit einen nahtlosen Panoramahintergrund für die 3D-Szene.

(a) (b)

Abbildung 25 Für die Geländedarstellung: (a) Textur. (b) Heightmap Bei der Portierung eines OpenGL Programm auf das Target-System ist grundsätzlich zu beachten: • Sicherstellen, dass der Code unter QNX syntaktisch und vor allem inhaltlich korrekt

arbeitet. • Die Window-System abhängigen Funktionen auf QNX-Photon umstellen. In diesem

Fall sind es die Funktionen aus der SDL-Library, die nicht auf dem Target verfügbar sind. Diese Funktionen sind durch die in Kapitel 2.2.2 entwickelten Funktionen zu ersetzen.

39

Abbildung 26 zeigt den Ablauf des Programms in der Initialisierungsphase (a) und in der Renderingsphase (b).

soa

drawTerrain()

refineTerrain()

calculateTree()

OpenGL

glDrawElements()

soar

initOpenGL()

loadTexture()

loadHeightMap()

processTerrain()

init() display()

drawSkybox()

glVertex3f()

(a) Initialisierungsphase (b) Darstellungsphase

rekursiver Aufruf

Abbildung 26 Ablaufdiagramm des Gelände-Darstellungsprogramms

3.2.1 Funktionsbeschreibung Im Folgenden werden die wichtigsten Funktionen beschrieben. • Funktionen display(void)

ist die Haupt-Display-Funktion, hier werden die „draw“-Funktionen für Skybox, Terrain usw. der Reihe nach aufgerufen.

• Funktionen drawTerrain(void)

Hier wird zuerst die Funktion refineTerrain() zum Generieren des Gitters aufgerufen. Das Ergebnis wird in dem Array guiTerrainIndexList gespeichert. Die zu zeichnenden Dreiecke werden jeweils durch drei Einträge (drei Eckpunkte) aus diesem Array dargestellt. Ein Element dieses Arrays enthält nicht die

40

Koordinaten eines Punktes, sondern einen Index auf das eigentliche Vertex-Array. Mit dem OpenGL-Befehl

glDrawElements(GL_TRIANGLES, iNmbPrimitiveNodes,

GL_UNSIGNED_INT, guiTerrainIndexList);

wird das Gitter schließlich gerendert. Durch das Flag GL_TRIANGLES wird OpenGL mitgeteilt, dass es sich hier um Dreiecke handelt. Die Anzahl der Dreiecke wird in dem Variable iNmbPrimitiveNodes gespeichert.

• Funktionen refineTerrain(void)

Die Verfeinerungsfunktion calculateTree() wird hier mit den Initialwerten gestartet. Für cI ist der Initialwert der Mittelpunkt des gesamten Geländes.

• Funktionen calculateTree(int cI, int deltaX, int deltaY)

Der bereits erläuterte Verfeinerungsalgorithmus ist hier implementiert. Dabei ist cI

der Index des Mittelpunktes R, deltaX und deltaY der Index-Offset bis zum Mittelpunkt der Teil-Quadranten. Durch das Programmieren der 16 Fallunterscheidungen ist diese Funktion ziemlich groß und unübersichtlich geraten.

• Funktionen preprocessTerrain(void)

Die für die Fehler-Ermittlung zum Teil benötigten Daten werden hier in der Initialisierungsphase einmalig vorgerechnet und in den folgenden Arrays

float *fErrorMatrix; float *fRadiiMatrix;

abgespeichert.

• Funktionen loadHeihtMap(void)

In dieser Funktion wird das Heightmap eingelesen. Die zum Lesen der BMP-Datei verwendete SDL-Funktion SDL_LoadBMP wurde durch eine selbst entwickelte Version ersetzt (SDL war auf dem Target-System nicht verfügbar). Nach dem Einlesen der Daten werden Speicher für die globalen Arrays

GLfloat *gfTerrainVertexList; GLfloat *gfTerrainColorList; GLfloat *gfTerrainTexCoordList;

reserviert. Das Array gfTerrainVertexList enthält die x, y und z Koordinaten des Originalgitters. Während die y Werte direkt aus dem Heighmap abgegriffen werden können, muss für die x und z Werte eine Skalierung mit einem konstanten Faktor TERRAIN_SCALE_FLAT durchgeführt werden. Das Array gfTerrainColorList bekommt die Farbinformation zugewiesen und wird sichtbar wenn das Texture-Mapping ausgeschaltet ist. Im Array gfTerrainTexCoordList sind schließlich die 2D-Koordinaten für das Texture-Mapping gespeichert22.

• Funktionen loadTextures(void)

22 vgl. Kapitel 2.1.2.8

41

Die Bilder für die Textures werden hier eingelesen (txtImg[]) und mit den folgenden OpenGL Befehlen aktiviert.

glTexImage2D(GL_TEXTURE_2D, ... GL_RGBA, GL_UNSIGNED_BYTE, txtImg[run1]->pixels ); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTE R, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTE R, GL_LINEAR);

• Funktionen drawSkybox(void)

Die Panorama-Hintergrundbilder werden hiermit gezeichnet. Eine Skybox wird in OpenGL als ein Würfel um das darzustellende Objekt (hier das Gelände) herum modelliert. Die Hintergrundbilder werden als Texture auf die sechs Innenseite des Würfels projiziert. Die Skybox dient hier nur der besseren Optik und kann optional abgeschaltet werden.

• Funktionen main()

Im Hauptprogramm kann schließlich ein Flug oder eine Fahrt durch das Gelände simuliert werden. Dabei werden in einer Schleife die Koordinaten der Kamera-Position frameweise verändert. Eine typische Steuerung sieht wie folgt aus.

for(i=0; i<15; i++) { moveCamera(0.0, 0.0, -10.0, 0.0, 0.0, 0.0);

display(); glICMSwapBuffer();

}

void moveCamera(float X, float Y, float Z, float angle_X, float angle_Y, float angle_Z) {

sCamera.angle_X += angle_X; sCamera.angle_Y += angle_Y; sCamera.angle_Z += angle_Z; sCamera.coord_X_fly += X; sCamera.coord_Y_fly += Y; sCamera.coord_Z_fly += Z; } display() { ... glMatrixMode(GL_PROJECTION); glLoadIdentity();

gluPerspective(90.0f, ratio, 0.1f, 100000.0f); // Rotete and translate the View glRotatef(sCamera.angle_X, 1.0f, 0.0f, 0.0f); glRotatef(sCamera.angle_Y, 0.0f, 1.0f, 0.0f); glRotatef(sCamera.angle_Z, 0.0f, 0.0f, 1.0f); glTranslatef(-sCamera.coord_X_fly, -sCamera.coord_Y _fly,

sCamera.coord_Z_fly); ... }

C-Code für die Kamera-Steuerung

42

Die folgende Abbildungen zeigen die Ergebnisse des implementierten Programms.

Abbildung 27 Blick auf das Gelände mit einem Symbol für die Navigation und

einer eingezeichneten virtuellen Strasse.

(a) (b)

Abbildung 28 Screenshot aus unterschiedlichen Winkeln. Mit Texturen und Skybox. (b) Als Gittermodell

3.2.2 Probleme bei der Implementierung Eine Portierung verläuft selten ohne Probleme. Insgesamt ist es schwierig bei einem derart komplexen Algorithmus den Überblick zu behalten. Stößt man auf einen Fehler, so stellt sich als erstes die Frage, welche Komponente diesen Fehler verursacht hat. Die Mesa-Library ist zwar ausgereift, hat aber offiziell keine QNX-Unterstützung. Die selbstentwickelten glICM –Funktionen ist auch eine mögliche Fehlerquelle, ebenso der LOD-Algorithmus, der hier nur in einer experimentellen Form vorliegt. Selbst wenn alles auf einem X86-basierten QNX-Rechner fehlerfrei läuft, muss das Programm noch auf dem Target getestet werden. Auch hier treten oft Probleme auf. Das Fehlen von bestimmten Runtime-Libraries beispielsweise ist noch einfach zu beheben.

43

Komplizierter ist es, wenn sich die Grafikhardware anders als auf einem X86-PC verhält. Im Folgenden wird auf einige dieser Probleme eingegangen. • Einlesen des Heightmap

Auch wenn ein Heighmap in einem Bild-Format vorliegt (.BMP), ist das nicht mit der Existenz eines Bildes gleichzusetzen. Auf der Suche nach der passenden Gittergröße werden Heightmaps mit Hilfe eines Zeichenprogramms vergrößert, verkleinert oder bearbeitet. Hat man beim Abspeichern ein anderes Format oder eine andere Farbauflösung (Graustufe, RGB, RGBA, 16, 24, 32 Bit) aus Versehen gewählt, entstehen „verfälschte“ Landschaften.

• Falsche Skalierung des Geländes

Das in Abbildung 29 gezeigte Bild war das erste sichtbare Ergebnis. Lange wurde gerätselt, ob das nun ein Gelände ist oder doch nur ein zufälliges Bit-Muster im Framebuffer. Nach einer langen Debug-Session hat sich herausgestellt, dass die Skalierung auf der X-Achse bei diesem Bild verstellt war.

Abbildung 29 Fehlerhaft dargestelltes Gelände

• Verhalten der Target-Grafikhardware

Auf dem Target muss der Offscreen-Context23 im Direct-Mode mindestens um eine Pixel-Zeile größer als der Image-Buffer definiert werden. D.h. bei einer Image-Buffer-Größe von 320 x 96 Pixel muss der Offscreen-Context mit 320 x 97 Pixel initialisiert werden. Dieses Verhalten ist auf der QNX-X86 Plattform nicht zu beobachten. Die Ursache dafür ist bisher unbekannt.

3.3 Evaluierung und Diskussion Um die Leistungsfähigkeit des Algorithmus zu überprüfen, wurden einige Tests durchgeführt. • Laufzeitverhalten

Die Laufzeiten bezüglich der Größe des Gitters und des eingestellten Fehlers werden bei diesem Test gemessen. Dabei wird das Gelände 30 mal gerendet und jeweils der Mittelwert für Frames pro Sekunden (FPS), Anzahl der benötigten Dreiecke (Triangles) und Anzahl der verfeinerten Quadranten (Nodes) gebildet. Die Kamera wird mittig im Gelände positioniert und bei jedem Frame um 5 Grad nach links gedreht. Diese Messung wird jeweils für den Fehler 8, 16, 32 und 64 durchgeführt. Die Ergebnisse für ein 256x256 Gitter sind in Tabelle 2 und für ein 512x512 Gitter in Tabelle 3 aufgeführt.

23 Vgl. Kapitel 2.2.2

44

Tabelle 2 Messergebnisse bei einem 256x256 Gitter

Tabelle 3 Messergebnisse bei einem 512x512 Gitter

Die Ergebnisse zeigen, dass durch das Erhöhen der Fehler-Schranke die Anzahl der Dreiecke und Rekursionen verringert und gleichzeitig die Frame-Rate erhöht wird. Das war zu erwarten. Der Performance-Gewinn an Frame-Rate fällt aber verhältnismäßig gering aus. Vergleicht man in Tabelle 3 die Werte aus der ersten und vierten Zeile, so stellt man Folgendes fest: Obwohl das System 63% weniger Dreiecke zu rendern hat, ist die Frame-Rate nur um 14% gestiegen. D.h. die Grafik-Ausgabe auf dem Display verursacht prinzipiell eine hohe Grundlast.

• Speicherverbrauch

Der Speicherverbrauch des Algorithmus ist nicht von der Laufzeit-Komplexität (Anzahl der Rekursionen und Verfeinerungsstufen) abhängig. Daher kann eine Abschätzung analytisch erfolgen. Bei einer n x n Gitter werden benötigt:

// xyz pro vertex VertexList: (n+1)*(n+1)*3 * sizeof(GLfloat)

// rgb pro vertex ColorList: (n+1)*(n+1)*3 * sizeof(GLfloat)

// uv pro vertex TexCoordList: (n+1)*(n+1)*2 * sizeof(GLfloat)

// 1 pro vertex ErrorMatrix: (n+1)*(n+1) * sizeof(float)

// 1 pro vertex RadiiMatrix: (n+1)*(n+1) * sizeof(float)

// max Quads * 2 * 3, (2 tri pro quad, 3 vertices p ro tri) IndexList: n*n*2*3 * sizeof(GLuint)

Zusammengefasst ergibt sich:

Gitter: 256 x 256 Error FPS Triangles Nodes

8 4,274 1647 508 16 4,295 1055 326 32 4,407 824 255 64 4,467 630 197

Gitter: 512 x 512 Error FPS Triangles Nodes

8 3,863 2056 644 16 4,087 1396 438 32 4,278 1007 313 64 4,377 761 235

45

= ( 10 · (n + 1)2 + 6 · n2 ) · sizeof(float) = ( 16 · n2 + 20 · n + 10 ) · sizeof(float)

Der Speicherbedarf beträgt bei einer Float-Variable-Größe von 4 Byte:

Gitter-Größe 512 x 512 ≈ 16 MB. Gitter-Größe 1024 x 1024 ≈ 67 MB .

Ein Test mit einem 1024x1024 Gitter auf dem Target ist daher aufgrund von Speicherproblemen gescheitert.

Zusammenfassend lässt sich sagen, dass das Programm erfolgreich auf dem Target portiert wurde und zufrieden stellend arbeitet. Die Ergebnisse bestätigen die eingangs erwähnte Notwendigkeit des LOD-Verfahrens. Die Feineinstellung der Detaillierungsgenauigkeit durch den Vertex-Interpolation-Error führt zu den erwarteten Veränderungen der zu verarbeiteten Dreiecke. Diese tragen allerdings nicht entscheidend zum Gesamtergebnis bei, da die Grafik-Ausgabe auf dem Bildschirm verhältnismäßig lang dauert. Ein vollwertiges 3D-Navigationssystem lässt sich dadurch aber noch nicht realisieren. Soll eine 2D-Strassenkarte (3D-Strassenkarte sind im Moment noch nicht erhältlich) auf einem derartig gerenderten Gelände abgebildet werden, so treten einige Probleme auf. Abbildung 30 zeigt eine vektorisierte Strasse auf einem Geländegitter. Hier wird deutlich, dass neue Punkte auf dem Gelände entstehen. Die Höhe (y-Koordinaten in OpenGL) an diesen Punkten lässt sich bei einem statischen Gitter noch verhältnismäßig einfach mathematisch bestimmen. Aber bei einem dynamischen LOD-Verfahren ändert sich die Geometrie des Gitters ständig. Außerdem müssen die neuen Punkte in dem Verfeinerungsalgorithmus berücksichtigt werden.

Vektorisierte Strasse

Neue Punkte

Abbildung 30 Vektorisierte Strasse auf einem Gelände-Gitter. Die neu entstandenen Punkte sind in blau

gekennzeichnet. Generell müssen 3D-Objekte, wie Städte und Gebäude bei der Visualisierung berücksichtigt werden. Bei zunehmender Anzahl und Komplexität von Objekten ist der Einsatz von Szenen-Graphen sinnvoll und erforderlich. Ob diese Techniken auf dem Target anwendbar sind, ist allerdings ungeklärt.

46

Diese und einige andere Probleme müssen noch untersucht werden. Geeignete oder spezialisierte Algorithmen sind zu evaluieren oder müssen noch entwickelt werden.

47

4 OpenGL Java-Binding Bisherige Systeme im Automotive-Bereich werden in der Regel in C/C++ entwickelt. Mit zunehmender Leistungsfähigkeit der eingesetzten Hardware hat die Programmiersprache Java auch im Embedded-Bereich Einzug gehalten. So schreiben manche Automobil-Hersteller beispielsweise vor, dass die HMI komplett in Java zu entwickeln ist. Es existieren einige OpenGL Java-Binding Implementierungen; sie sind aber bisher nur auf Windows- und Unix-Plattformen verfügbar. Für die Evaluierung auf der SH4-QNX Plattform ist daher eine Portierung erforderlich. Die wichtigsten OpenGL Java-Binding sind: • JOGL 24 (JSR25 231)

JOGL wurde ursprünglich von Ken Russel und Chris Kline entwickelt und im August 2003 veröffentlich. Die Firma Sun und SGI haben durch eine Zusammenarbeit JOGL als die offizielle Referenz-Implementierung für den Standard JSR231 aufgenommen. Bis zu endgültiger Verabschiedung von JSR231 wird JOGL wohl als quasi Standard angesehen.

• Java3D26 (JSR 189)

Java3D ist sei Jahren die von SUN offiziell favorisierte 3D-API. Im Gegensatz zu anderen „Eins zu Eins“ OpenGL-Binding bietet Java3D ein vollständig objektorientiertes Programmiermodell für 3D-Objekte mit umfangreichen High-Level Funktionen. Seit 2004 ist Java3D Open-Source, damit ist unklar, ob SUN die Entwicklung wie bisher weiter vorantreiben wird.

• SWT Experimental OpenGL Plug-in (SWTOGL)27

Speziell für das Java GUI-Framework SWT wurde dieses OpenGL-Binding als Unterprojekt der Entwicklungsumgebung Eclipse entwickelt. SWTOGL ist sowohl als Eclipse-Plugin als auch für den Standalone-Einsatz konzipiert. Der Entwicklungsstand wird aber noch als experimentell eingestuft.

Weitere Implementierungen wie LWJGL (Lightweight Java Game Library), JavaGL, GL4Java (OpenGL for Java Technology) und Magician haben sich aufgrund unterschiedlicher Probleme nicht durchgesetzt. Hinzu kommt, dass diese Implementierungen teilweise nicht frei verfügbar sind oder nicht weiter entwickelt werden. Im Bereich Java und 3D-Grafik gibt es daneben noch einige interessanten Alternativen, wie z.B. Java Bindings for OpenGL ES (JSR 239), Mobile 3D Graphics API for J2ME (JSR 184), die allerdings in der vorliegenden Arbeit aus Zeitgründen nicht behandelt wurden. In Kapitel 4.1 werden die Prinzipien und Techniken der einzelnen Java-Binding-Implementierungen sowie die Grundlage der Java-Native-Schnittstelle JNI erläutert. Insbesondere zwischen JOGL und Java3D gibt es große konzeptionellen Unterschiede. Die konkrete Portierung der ausgesuchten Java-Binding, SWTOGL, wird in Kapitel 4.2 beschrieben. Die Evaluierungsergebnisse werden in Kapitel 4.3 zusammenfassend aufgeführt und diskutiert.

24 vgl [JOGL] 25 JSR Java Specification Request, vgl [JCP] 26 vgl [Java3D] 27 vgl [SWTOGL]

48

4.1 Grundlage Vereinfacht ausgedrückt muss man für ein OpenGL Java-Binding nichts anderes tun, als eine Wrapper-Klasse in Java zu schreiben, die die C-Funktionen von OpenGL eins zu eins abbilden. Auf den ersten Blick eine einfache Aufgabe; Native-Libraries kann man von Java heraus über die JNI-API aufrufen. Nun stellt sich aber die Frage, wohin mit dem gerenderten Bild? Die Grafik-Ausgabe soll logischerweise wieder auf einem Fenster (Canvas, Widget) der Java-Anwendung erscheinen. Das bedeutet, dass das Java-Binding die Verbindung zwischen dem zugrunde liegenden Java-GUI-Framework und dem plattformabhängigen Window-System herstellen muss. Bekannte Java-GUI-Frameworks sind: • AWT (Abstract Window Toolkit)

AWT ist das erste Java-GUI-Framework von SUN und ist fester Bestandteil der Java-Foundation-Classes (JFC). Für die Darstellung der GUI-Komponenten (Widgets) werden jeweils die Window-System eigenen Komponenten verwendet. Für den Zugriff auf die nativen Window-System-Elemente dienen sog. Peer-Codes, d.h. zu jeder Widget-Klasse existiert auch eine entsprechende Native-Peer-Funktion, die das entsprechende Window-System-Widget ansteuert. Jede Java-Runtime-Environment-Distribution (JRE) einer bestimmten Plattform enthält jeweils einen Satz von Window-System abhängigen Peer-Libraries. Da nicht alle Plattformen den gleichen Umfang an GUI-Elementen besitzt, bildet AWT nur eine gemeinsame Basis der unterstützten Plattformen ab. Aus diesem Grund werden moderne Java-Applikation nur ganz selten AWT als GUI-Framework verwenden.

• Swing

Seit Java 1.2 (1998) ist Swing zusätzlich zu AWT als GUI-Framework verfügbar. Bei Swing werden die GUI-Elemente selbst in Java gerendert und sind somit nicht von Window-System abhängig. Das Ergebnis ist ein einheitliches „Look and Feel“ auf allen Plattformen. Das Framework selbst ist modular und objektorientiert aufgebaut. Als reine Java-Implementierung sind Swing-Applikationen in der Regel langsamer als AWT oder SWT.

• SWT (Standard Widget Toolkit)

SWT wurde ursprünglich von IBM entwickelt und ist inzwischen zusammen mit dem Eclipse-Projekt als Open-Source freigegeben. Ziel der Entwicklung ist es einen effizienten Zugriff auf plattformabhängige Widget-Funktionalitäten durch eine plattformunabhängige API zu ermöglichen. Wie bei AWT werden bei SWT auch die Window-System spezifischen GUI-Komponenten verwendet. Der Zugriff auf die Native-GUI-Funktionen erfolgt über JNI. Für jede unterstützte Plattform werden jeweils spezifischen Java- und C-Funktionen implementiert, dadurch ist eine optimale Umsetzung möglich. Gegenüber AWT gilt SWT als umfangreicher und leistungsfähiger. Die Virtual-Machine J9 von IBM verwendet SWT als Basis GUI-Framework; so bauen sich bei J9 die AWT Klassen auf SWT auf, um damit die für die Zertifizierung erforderliche AWT Klassen-Kompatibilität zu erreichen.

In den folgenden Abschnitten werden die Konzepte der anfangs erwähnten Java-Bindings näher erläutert.

4.1.1 JOGL JOGL, aktuell in der Version 1.1, ist eine auf AWT und Swing basierte OpenGL Java-Binding und bietet Unterstützung von OpenGL bis zu der aktuellen Version 2.0. Eine Java-

49

VM in der Version 1.4 (oder höher) wird von JOGL strikt vorausgesetzt. Vom Konzept her entspricht JOGL einer Eins-zu-Eins-Abbildung der Native-OpenGL-Funktionen. Zusätzlich werden Klassen für die Anbindung an das AWT-Event-Konzept zur Verfügung gestellt. Die Namenskonventionen der OpenGL-Funktionen28 werden auch in JOGL beibehalten, obwohl das Problem bei einer objektorientierten Programmiersprache durch Überladen der Funktionen mit unterschiedlichen Signaturen gelöst werden kann. Um Plattformunabhängigkeit zu erreichen, verwendet OpenGL eigene Datentypen. Das ist bei Java nicht erforderlich. Deshalb werden bei JOGL nur die vorgegebene Java-Standardtypen wie in Tabelle 4 aufgelistet benutzt.

Java-Typ OpenGL-Type Größe in Bit byte GLbyte 8 short GLshort 16 int GLint 32 float GLfloat 32 double GLdouble 64

Tabelle 4 Zuordnung der Java- und OpenGL-Datentypen Das Beispiel in Listing 3 zeigt den Unterschied zu einem C-Programm.

(a) Java Code (b) C Code public void draw() { gl.glClear( GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); gl.glColor3f(1.0f, 0.3f, 0.3f); gl.glBegin(GL.GL_QUADS); gl.glVertex3f(0.2f, 0.2f, 0.0f); gl.glVertex3f(0.7f, 0.2f, 0.0f); gl.glVertex3f(0.7f, 0.7f, 0.0f); gl.glVertex3f(0.2f, 0.7f, 0.0f); gl.glEnd(); }

void draw() { glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glColor3f(1.0f, 0.3f, 0.3f); glBegin(GL_QUADS); glVertex3f(0.25f, 0.25f, 0.0f); glVertex3f(0.75f, 0.25f, 0.0f); glVertex3f(0.75f, 0.75f, 0.0f); glVertex3f(0.25f, 0.75f, 0.0f); glEnd(); }

Listing 3 OpenGL Code in (a) Java/JOGL, (b) C/OpenGL

Die wichtigsten Klassen der JOGL-API sind GL bzw. GLU. Diese Klassen sind die zentralen Wrapper-Klassen der Native-OpenGL-Funktionen. Diese Klassen sind als Interface ausgelegt und werden durch plattformabhängige Implementierungen ergänzt. Sämtliche OpenGL-Funktionen werden in den beiden Implementierungsklassen als native deklariert. In der aktuelle JOGL Version ist die GLU-Funktionalitäten komplett als Java-Klassen ausgeführt, die aber per Einstellung auf die „gewrappte“ Native-Version umgeschaltet werden kann. Eine Besonderheit von JOGL ist, dass die Sourcecodes (Java und C) zum Großteil durch ein eigens entwickeltes Tool zur Buildzeit generiert werden. Bei der Generierung werden die Header-Dateien der auf dem System installierten OpenGL-Libraries gescannt und die Codes entsprechend erstellt. Damit ist eine optimale OpenGL-Unterstützung gewährleistet. Abbildung 31 zeigt die Beziehung der wichtigsten Klassen von JOGL.

28 vgl. Kapitel 2.1.1

50

GLCanvas

Canvas

GLJpanel

JPanel DrawableFactory

«interface»

Drawable

«interface»

GL

«interface»

GLU

X11GLImpl

myGLEventListener

«interface»

GLEventListener

GLCapabilities

<<has>>

<<use>>

<<use>>

X11GLUImpl

<<use>>

<<create>>

Abbildung 31 Klassendiagramm der wichtigsten JOGL Klasse

Weitere Basisklassen sind GLCanvas, GLJpanel , GLCapabilities , GLDrawableFactory , GLDrawable und GLEventListener . Die Klasse GLCanvas ist eine Spezialisierung der AWT-Klasse Canvas und repräsentiert einen Grafik-Ausgabebereich mit garantierter Hardware-Beschleunigungsunterstützung. Durch die Vererbung bleibt das AWT-Event-Konzept vollständig erhalten. Die Klasse GLJpanel ist die Swing-Version davon, die zwar Swing-Kompatibilität bietet, jedoch Performance-Nachteile bringt. Beide Klassen implementieren das Interface GLDrawable und können mit der Klasse GLDrawableFactory instantiiert werden. Ein Objekt der Klasse GLCapabilities kann dabei als Parameter übergeben werden. Damit werden Grundeinstellungen wie Farbtiefe oder Anzahl der Framebuffer von OpenGL konfiguriert. Das Listing 4 zeigt ein lauffähiges Beispielprogramm. import java.awt.*; import java.awt.event.*; import net.java.games.jogl.*; public class HelloWorld { public static void main(String[] args) { Frame frame = new Frame("Hello World"); GLCanvas canvas = GLDrawableFactory.getFactory().createGLCanvas (new GLCapabilities()); canvas.addGLEventListener(new MyRenderer()); frame.add(canvas); frame.setSize(300, 300); canvas.display(); frame.show(); } static class MyRenderer implements GLEventListene r { public void init(GLDrawable drawable) { GL gl = drawable.getGL();

51

gl.glMatrixMode(gl.GL_PROJECTION); gl.glLoadIdentity(); gl.glOrtho(0.0, 1.0, 0.0, 1.0, -1.0, 1.0); } public void display(GLDrawable drawable) { GL gl = drawable.getGL(); gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEP TH_BUFFER_BIT); gl.glColor3f(1.0f, 0.3f, 0.3f); gl.glBegin(GL.GL_QUADS); gl.glVertex3f(0.25f, 0.25f, 0.0f); gl.glVertex3f(0.75f, 0.25f, 0.0f); gl.glVertex3f(0.75f, 0.75f, 0.0f); gl.glVertex3f(0.25f, 0.75f, 0.0f); gl.glEnd(); gl.glFlush(); } public void displayChanged(GLDrawable drawable, boolean modeChanged, boolean deviceChange d) { } public void reshape(GLDrawable drawable, int x, int y, int width, int height) { } } }

Listing 4 JOGL „HelloWorld“-Programm In diesem Beispiel ist das Event-Konzept deutlich erkennbar. Das Objekt MyRenderer implementiert die Interface-Klasse GLEventListener und wird an dem Event-Listener des GLCanvas Objektes übergeben.

canvas.addGLEventListener(new MyRenderer()); Je nach Event und Situation werden die entsprechende Methode init () , display() , reshape() und displayChanged() aufgerufen. JOGL bietet keine Unterstützung für die High-Level 3D-Programmierung. Soll eine Anwendung objektorientiert modelliert werden, so ist es Aufgabe des Entwicklers, das System entsprechend zu gestalten.

4.1.1.1 Native-Anbindung Von höherer Bedeutung für die Portierung und Performance ist die Art und Weise, wie OpenGL Native angebunden wird. Die Funktion glColor3f() ist beispielsweise wie folgt implementiert. package net.java.games.jogl.impl.x11 public class X11GLImpl implements GL { ... native public void glColor3f(float red, float gre en, float blue); JNIEXPORT void JNICALL Java_net_java_games_jogl_impl_x11_X11GLImpl_glColor 3f( JNIEnv *env, jobject _unused, jfloat red, jfloat green, jfloat blue) {

52

glColor3f((GLfloat) red, (GLfloat) green, (GLfl oat) blue); } Java- und C-Code aus X11GLImpl.java und X11GLImpl_JNI.c Bei dieser einfachen Funktion können die Parameter ohne Umwandlung direkt von jfloat auf GLfloat „gecastet“ und weiter verwendet werden. Komplexe Anwendungen wie die in Kaptitel 3 vorgestellte Geländevisualisierung arbeiten aus Performance-Gründen mit Vertex-Array29. Eine effiziente Implementierung der entsprechenden Funktionen ist daher für eine gute Gesamt-Performance unerlässlich. Die folgenden Code-Fragmente zeigen die Implementierung der Funktion glVertexPointer . public void glVertexPointer(int size, int type, int stride, java.nio.Bu ffer ptr) { if (!BufferFactory.isDirect(ptr)) throw new GLException("Argument \"ptr\" was not a direct buffer"); glVertexPointer0(size, type, stride, ptr); } native private static void glVertexPointer0(int siz e, int type, int stride, java.n io.Buffer ptr); JNIEXPORT void JNICALL Java_net_java_games_jogl_impl_x11_X11GLImpl_glVerte xPointer0( JNIEnv *env, jobject _unused, jint size, jint type, jint stride, jobject ptr) { GLvoid * _ptr3 = NULL; if (ptr != NULL) { _ptr3 = (GLvoid *) (*env)->GetDirectBufferAddre ss(env, ptr); } else { _ptr3 = NULL; } glVertexPointer((GLint) size, (GLenum) type, (GLs izei) stride, (GLvoid *) _ptr3); } Java- und C-Code aus X11GLImpl.java und X11GLImpl_JNI.c Hier ist zu erkennen, dass JOGL mit dem seit J2SE 1.4 eingeführten NIO (Native IO)30 Konzept arbeitet. Das Vertex-Array java.nio.Buffer ptr wird auf der Java-Seite als Direct-Buffer deklariert und an die korrespondierte C-Funktion übergeben. Die C-Funktion leitet diesen Pointer direkt an OpenGL als GLvoid „gecastet“ weiter. OpenGL hat damit ohne Zeitverzögerung den vollen Zugriff auf das gesamte Array. Die Anbindung von OpenGL an AWT soll exemplarisch auf einer X-Window/Linux-Plattform gezeigt werden. Abbildung 32 zeigt den Ablauf beim Aufruf der Methode reshap(). Ein Objekt der Klasse GLCanvas hat u.a. ein GLContex Objekt, in diesem Fall eine konkrete X11-Implementierung X11OnscreenGLContext . In dieser Klasse sind alle Window-System/Plattform abhängige Funktionen gekapselt (siehe Abbildung 33).

29 vgl. Kapitel 2.1.1 30 vgl. Kapitel 4.1.4

53

Abbildung 32 Sequenz-Diagramm beim Aufruf der Methode GLCanvas.reshape()

GLContext

X11GLContext WindowsGLContext

X11OffscreenGLContextX11OnscreenGLContext

...

... ...

Abbildung 33 Klassendiagramm GLContext Hierarchie

Wie bereits in Kapitel 2.1.2 erläutert, benötigt OpenGL für die Initialisierung einen Grafik-Context, damit OpenGL das fertig gerenderte Bild anzeigen kann. Das geschieht bei GLX mit der Funktion glXMakeCurrent(Display* display, XID drawable, GLX Context ctx). Die benötigten Parameter display und drawable müssen aus dem AWT Grafik-Context abgeleitet werden. Diese können entweder aus der GraphicDevice -Klasse abgefragt werden31

31 vgl. Kapitel 4.1.2.1

54

oder native wie bei JOGL praktiziert über die AWT-C API. Diese Abfrage wird bei JOGL in der Klasse JAWT realisiert. Die Methode GetDrawingSurface zeigt die Funktionsweise. Der Parameter target ist dabei ein Objekt der AWT Component- Klasse. public JAWT_DrawingSurface GetDrawingSurface(java.l ang.Object target) { ByteBuffer _res; _res = GetDrawingSurface0(getBuffer(), target); if (_res == null) return null; return new JAWT_DrawingSurface(_res.order(ByteOrd er.nativeOrder())); } native private java.nio.ByteBuffer GetDrawingSurfac e0(

java.nio.Buffer jthis0, java.lang.Object target); #include <jawt.h> ... JNIEXPORT jobject JNICALL Java_net_java_games_jogl_impl_JAWT_GetDrawingSurfac e0(

JNIEnv *env, jobject _unused, jobject jthis0, jobje ct target) { JAWT * this0 = NULL; JAWT_DrawingSurface * _res; if (jthis0 != NULL) { this0 = (JAWT *) (*env)->GetDirectBufferAddre ss(env, jthis0); } else { this0 = NULL; } _res = this0->GetDrawingSurface(env, (jobject) ta rget); if (_res == NULL) return NULL; return (*env)->NewDirectByteBuffer(env, _res, 24) ; } Java- und C-Code aus JAWT.java und JAWT_JNI.c Das JAWT-Objekt wird hier mit der Funktion (*env)->GetDirectBufferAddress() ermittelt. Anschließend wird die Funktion GetDrawingSurface() aufgerufen, um einen Zeiger auf die JAWT_DrawingSurface Struktur zu bekommen. Interessant ist hier zu sehen, dass diese Struktur mit der Funktion NewDirectByteBuffer in Direct-ByteBuffer umgewandelt und zurückgeliefert wird32. Als Direct-ByteBuffer wird diese Struktur nicht mehr vom Garbage-Collector beeinflusst, wodurch ein konstant schneller Zugriff gewährleistet wird.

In der Methode lockSurface des X11OnscreenContext Objektes werden für die X11 wichtigen Informationen wie display, drawable und visualID aus dem JAWT_DrawingSurface Objekt extrahiert. Anschließend werden diese Informationen als Parameter von der Methode makeCurrent() an die Wrapper-Klasse GLX.glXMakeCurrent () weitergeleitet.

32 vgl. Kapitel 4.1.4

55

private boolean lockSurface() throws GLException { ... ds = getJAWT().GetDrawingSurface(component); ... dsi = ds.GetDrawingSurfaceInfo(); ... x11dsi = (JAWT_X11DrawingSurfaceInfo) dsi.platfor mInfo(); display = x11dsi.display(); drawable = x11dsi.drawable(); visualID = x11dsi.visualID(); ... } protected synchronized boolean makeCurrent(Runnable initAction) throws GLException { ... if (!lockSurface()) { return false; } ... if (!GLX.glXMakeCurrent(display, (int) drawable, context)) { throw new GLException("Error making context cur rent"); } ... } Java -Code aus X11OnscreenContext.java Die Methode GLX.glXMakeCurrent() wird Java- und C-seitig wie folgt implementiert: native static public boolean glXMakeCurrent( long dpy, long drawable, long ctx); JNIEXPORT jboolean JNICALL Java_net_java_games_jogl_impl_x11_GLX_glXMakeCurren t( JNIEnv *env, jclass _unused, jlong dpy, jlong d rawable, jlong ctx) { Bool _res; _res = glXMakeCurrent((Display *) (intptr_t) dpy, (XID) (intptr_t) drawable, (GLXContext) ( intptr_t) ctx); return _res; } Java- und C-Code aus GLX.java und GLX_JNI.c

4.1.2 JAVA3D Java3D bietet eine vollständig objektorientierte Klassenbibliothek um 3D-Applikationen zu erstellen. Dabei werden die 3D-Objekte als sog. Szenen-Graph dargestellt. Ziel der Entwicklung ist High-Level-Konzepte eines Szenen-Graphen basierten Systems mit einer Low-Level-3D-Engine wie OpenGL zu kombinieren. Die API bietet vielfältige Möglichkeiten zum Erstellen und Manipulieren von 3D- und Szenen-Graph-Objekten. Loader-Klassen zum Einlesen von 3D Objekten in den gängigsten Formaten (VRML, 3DS, usw.) sind ebenfalls

56

vorhanden. Aktuell liegt Java3D in der Version 1.4 vor. Eine JVM in der Version 1.4 wird vorausgesetzt. Die Funktionalitäten von Java3D sind in drei Packages aufgeteilt: • Java3D-Core Classes (javax.media.j3d)

Basis Klassen von Java3D, um das „virtual universe“ aufzubauen und zu bearbeiten.

• Mathematik Klassen für (javax.vecmath) Mathematik-Klassen für Vektoren, Matrizen und sonstige 3D Berechnungen.

• Utility-Klassen (com.sun.j3d.utils) Die Utility-Klassen bieten zusätzliche Hilfsfunktionen, beispielsweise für das Einlesen von 3D Objekte oder eine vereinfachte Handhabung des Szenen-Graphen Objektes (z.B. SimpleUniverse).

Das zentrale Konstrukt in Java3D ist der Szenen-Graph33. Eine 3D-Welt wird als eine Baum-Struktur in einem sog. Virtual Universe dargestellt. 3D-(Szenen-Graph)-Objekte in diesem 3D-Raum werden als Knoten in diesem Baum angehängt. Die Kanten dieses Baumes repräsentieren Beziehungen zwischen den Knoten. Zwei Arten von Beziehungen sind definiert: • Vater-Kind-Beziehung (Parent-Child-Relationship)

Die Knoten-Objekte Virtual Universe, Locale, Group und Leaf stehen in einer Vater-Kind-Beziehung zueinander. D.h. die Hierarchie der Knoten wird durch diese Art von Beziehung festgelegt.

• Referenz-Beziehung (Reference-Relationship) Knoten-Objekte von Typ Node Component und „Weitere Objekte“ (vgl. weiter unten) werden von den anderen Knoten-Objekten referenziert und stehen somit in einer Referenz-Beziehung zu denen.

Ein Vater-Knoten kann viele Kind-Knoten haben, umgekehrt darf aber ein Kind-Knoten nur einen Vater-Knoten haben. Außerdem sind Zyklen nicht erlaubt. Jeder Szene-Graph entspricht somit einen Directed Acyclic Graph (DAG). Abbildung 34 zeigt den Aufbau eines Szenen-Graphen in Java3D.

33 engl. scene graph

57

BG BG

TG

TG

TG

VS

Appearance

View Canvas3D Screen3D

Physical

Body

Physical

Env.

Leaf

(ViewPlatform)

Group (TransformGroup)

Group (BranchGroup)

Locale

VirtualUniverse

View branch graphContent branch graph

NodeComponent

Leaf

(Shape3D)

Parent-Child link

Reference

Abbildung 34 Aufbau eines Szenen-Graphen in Java3D aus [Sun01]

Die Klassen des Szenen-Graphen sind: • Virtual Universe

Das Virtual Universe ist die Wurzel des gesamten Szenen-Graphen und enthält Locale-Objekte als Kind-Knoten. Eine typische Java3D-Applikation hat normalerweise nur ein Virtual Universe. Bei einem sehr großen Virtual Universe kann der Szenen-Graph in unterschiedlichen Locale aufgeteilt werden.

• Locale

In einem Locale-Objekt sind u.a. die „High-Resolution-Coordinates“ des Teil-Baumes definiert. Die Position der 3D-Objekte innerhalb des Teil-Szenen-Graphen sind immer relativ zu der Koordinaten des Locale-Objektes definiert.

• Group

Objekte der Klasse Group werden an dem Locale Objekt als Kind-Konten zugeordnet und repräsentieren Teilbäume im Szenen-Graph-Modell. Es sind zwei Group-Typen definiert: TransformGroup und BranchGroup. TransformGroup ist für die Positionierung der 3D-Objekte im Raum zuständig. BranchGroup enthält Referenzen auf weitere Objekte (Group oder Leaf). Es gibt unterschiedliche Typen von Teil-Graphen, die jeweils mit einem Group-Objekt eingeleitet wird. Der „Content Branch Graph“ repräsentiert den Inhalt wie z.B. Geometrie des 3D-Objektes und der „View Branch Graph“ enthält die Ansichtsparameter.

• Leaf

Leaf-Objekte bilden die Blatt-Knoten des Baumes. Sie referenzieren die 3D-Elemente, die gerendert werden sollen.

58

• Node Component

NodeComponent und dessen Subklassen Appearance und Geometry enthalten letztendlich Darstellungsattribute, wie Geometrie und Lichtverhältnisse.

• Weitere Objekte

Weitere Objekte sind Canvas3D -, Screen3D - und View -Objekte. Sie sind alle für die Ausgabe der Grafik zuständig.

Abbildung 35 zeigt die Hierarchie der wichtigsten Klassen.

SceneGraphObject

Node

Group

Leaf

NodeComponent

BranchGroup

TransformGroup

SharedGroup

Shape3D

ViewPlatform

Behavior

Apperance

Geometry

Material

Texture

...

...

...

Canvas3D

Abbildung 35 Hierarchie der wichtigsten Szenen-Graphen-Klassen

Anhand eines aus [Sun01] modifizierten HelloUniverse-Beispiels soll gezeigt werden, wie die Programmierung konkret aussieht. Dabei soll der Szenen-Graph aus Abbildung 36 implementiert werden.

59

Abbildung 36 Beispiel HelloUniverse Szenen-Graph

Um das Beispiel möglichst einfach zu halten, wird die Utility-Klasse SimpleUniverse zum Erzeugen des Szenen-Graphen verwendet. Der Vorteil von SimpleUniverse ist, dass der komplette „View Branch Graph“ Teilbaum automatisch erzeugt wird34. Damit kann der Entwickler sich auf die Inhalte des Teilbaums „Content Branch Graph“ konzentrieren. public HelloMyUniverse() { SimpleUniverse simpleUniverse = null; setLayout(new BorderLayout()); GraphicsConfiguration config = SimpleUniverse.getPreferredConfiguration(); Canvas3D canvas3D = new Canvas3D(config); add("Center", canvas3D); simpleUniverse = new SimpleUniverse(canvas3D); simpleUniverse.getViewingPlatform().setNominalVie wingTransform(); BranchGroup sceneCube = createCubeSceneGraph(); BranchGroup sceneText = createTextSceneGraph(); simpleUniverse.addBranchGraph(sceneCube); simpleUniverse.addBranchGraph(sceneText); } public static void main(String[] args) { MainFrame frame = new MainFrame(new HelloMyUniver se(), 600, 400); } Hauptprogramm von HelloMyUniverse

34 vgl. Abbildung 36

60

public BranchGroup createCubeSceneGraph() { BranchGroup objRoot = new BranchGroup(); ColorCube colorCube = new ColorCube(0.4); Transform3D xRotation = new Transform3D(); Transform3D yRotation = new Transform3D(); xRotation.rotX(Math.PI/4.0d); yRotation.rotY(Math.PI/5.0d); xRotation.mul(yRotation); TransformGroup objRotation = new TransformGroup(x Rotation); objRoot.addChild(objRotation); objRotation.addChild(colorCube); objRoot.compile(); return objRoot; } public BranchGroup createTextSceneGraph() { BranchGroup objRoot = new BranchGroup(); Text2D text2D = new Text2D("Hello Universe", new Color3f(0.2f, 0.2f, 1.0f), "Helvetica", 40, 0); Transform3D translation = new Transform3D(); translation.setTranslation(new Vector3d(-0.5, 0.1 , 0.5)); TransformGroup objTranslation = new TransformGrou p(translation); objRoot.addChild(objTranslation); objTranslation.addChild(text2D); objRoot.compile(); return objRoot; } Methode zum Erstellen der Teil-Szenen-Graphen Im Konstruktor der Klasse HelloMyUniverse() wird das Canvas3D Objekt mit einer Default-Konfiguration erzeugt. Das Canvas3D-Objekt stellt hier den Kontext für die Grafikausgabe dar. Mit dem Canvas3D-Objekt als Parameter wird anschließend das SimpleUniverse Objekt, den eigentlichen Szenen-Graphen, erstellt. Ab hier kann man die zwei Teil-Bäume (Content-Branch-Graph), wie in Abbildung 36 dargestellt, dem Szenen-Graph mit der Methode addBranchGraph() hinzufügen. Diese BranchGroup- Objekte werden in den Methoden createCubeSceneGraph() und createTextSceneGraph() erzeugt. Das BranchGroup-

Objekt von der Methode createCubeSceneGraph enthält einen Würfel (ColorCube ) sowie entsprechende Transformationsobjekte (TransformGroup mit Rotationen auf der X- und Y-Achse). Die Methode createTextSceneGraph() liefert dagegen ein BranchGroup- Objekt mit einem Text-Objekt (Text2D ) inklusive einer einfachen Translation als Knoten zurück. Das Ergebnis des Beispielprogramms ist in Abbildung 37 abgebildet.

61

Abbildung 37 Screenshot Java3D-Beispielanwendung

4.1.2.1 Native-Anbindung Bei Java3D ist es aufgrund der höheren Komplexität insgesamt schwierig, die Native-Anbindung zu bewerten. Dennoch findet man bei der Analyse der Sourcecodes einige bekannte Muster, die auf eine effiziente Implementierung schließen. • GeometrieArray

Ein Objekt der Klasse GeometrieArray sowie Objekte der Subklassen enthalten Geometrie-Daten von 3D-Objekten. Der Sourcecode zeigt, dass diese Klasse für die Speicherung der Vertex-Koordinaten die Klasse J3DBuffer verwendet. Wie das folgende Code-Fragment zeigt, benutzt J3DBuffer für die eigentliche Datenhaltung NIO-Buffer.

public class J3DBuffer { ... private java.nio.Buffer originalBuffer = null; ...

public J3DBuffer(java.nio.Buffer buffer) { ... setBuffer(buffer); } } Java-Code aus javax.media.j3d.J3DBuffer.java

Die Methode execute der GeometryArray Klasse wird aufgerufen, um u.a. die verschiedene Vertex-Arrays an OpenGL zu übergeben. Die Übergabe geschieht per JNI, wie es der nächste Programmabschnitt zeigt.

abstract class GeometryArrayRetained extends Geomet ryRetained{ // Used for NIO buffer geometry J3DBuffer coordRefBuffer = null; FloatBufferWrapper floatBufferRefCoords = null; ...

void execute(...) { Object vcoord = null; vcoord = floatBufferRefCoords.getBufferAsObject() ;

62

... executeVABuffer(cv.ctx, this, ..., vcoord, ...); ... } JNIEXPORT void JNICALL Java_javax_media_j3d_GeometryArrayReta ined_executeVABuffer( JNIEnv *env, jobject obj, ..., jobject vcoords, ... ) { ... fverts= (jfloat *)(*(table->GetDirectBufferAddres s))(env, vcoords ); ... coordoff = 3 * initialCoordIndex; glVertexPointer(3, GL_FLOAT, 0, &(fverts[coordoff ])); ... } Java- und C-Code aus javax.media.j3d.GeometryArrayRetained.java bzw. …/native/d3d/ GeometryArrayRetained.cpp • Canvas3D

Das Konfigurieren der OpenGL-Engine erfolgt hauptsächlich in der Klasse Canvas3D. In der Methode createNewContext() wird beispielsweise den OpenGL-Context per JNI mit der glXCreateNewContext() Funktion erstellt. Hier sind die bekannte GLX-Funktionen gut zu erkennen.

native long createNewContext(long display, int wind ow, int vid, long fbConfig , long shareCtx, boolean isSharedCtx, boolean offScreen); JNIEXPORT jlong JNICALL Java_javax_media_j3d_Canvas3D_createN ewContext( JNIEnv *env, jobject obj, jlong display, jint window, jint vid, jlong fbConfigListPtr, jlong sharedCtxInfo, jboolean isSharedCtx, jboolean offScreen) { jlong gctx; jlong sharedCtx; ... ctx = glXCreateNewContext((Display *)display, f bConfigList[0], GLX_RGBA_TYPE, (GLXContext)sharedCtx, True); ... if (!glXMakeCurrent((Display *)display,

(GLXDrawable)window,(GLXContext)ctx)) { ... } ... } Java- und C-Code aus javax.media.j3d.Canvas3D.java bzw. …/native/ogl/Canvas3D.c

63

Im Gegensatz zu JOGL wird die JAWT-API bei Java3D nicht verwendet. Die für die GLX-Funktionen erforderlichen Parameter, wie display und screen35, werden aus der konkreten AWT –GraphicsDevice -Implementierungsklasse X11GraphicsDevice abgefragt. NativeScreenInfo(GraphicsDevice graphicsDevice) { // Open a new static display connection if one is not already opened getStaticDisplay(); // Get the screen number screen = ((X11GraphicsDevice)graphicsDevice).getS creen(); } Java-Code aus javax.media.j3d.NativeScreenInfo.java Interessant ist auch die Feststellung, dass Java3D für die Grafik-Ausgabe teilweise Xlib-Funktionen direkt verwendet. Der folgende Codeausschnitt zeigt ein Beispiel dafür. JNIEXPORT jlong JNICALL Java_javax_media_j3d_NativeScreenInfo_openDisplay( JNIEnv *env, jclass cls) { Display* dpy; dpy = XOpenDisplay(NULL); return (jlong)dpy; } C-Code aus .../native/ogl/NativeScreenInfo.c

4.1.3 SWTOGL Ähnlich wie bei JOGL ist SWTOGL ein klassisches Eins-zu-Eins-OpenGL-Binding. Das Konzept bezüglich Namenskonvention und Datentypen sind bei beiden Bindings fast gleich. Das Listing 5 zeigt eine Gegenüberstellung zwischen Java/SWTOGL und C/GLX.

(a) Java Code

(b) C Code

public void draw() { GL.glClear( GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); GL.glColor3f(1.0f, 0.3f, 0.3f); GL.glBegin(GL.GL_QUADS); gl.glVertex3f(0.2f, 0.2f, 0.0f); gl.glVertex3f(0.7f, 0.2f, 0.0f); gl.glVertex3f(0.7f, 0.7f, 0.0f); gl.glVertex3f(0.2f, 0.7f, 0.0f); GL.glEnd(); glContext.swapBuffers(); }

void draw() { glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glColor3f(1.0f, 0.3f, 0.3f); glBegin(GL.GL_QUADS); glVertex3f(0.25f, 0.25f, 0.0f); glVertex3f(0.75f, 0.25f, 0.0f); glVertex3f(0.75f, 0.75f, 0.0f); glVertex3f(0.25f, 0.75f, 0.0f); glEnd(); glXSwapBuffers(display, drawable); }

Listing 5 Code-Beispiele (a) Java/SWTOGL, (b) C/GLX

35 vgl. Kapitel 2.1.2.2

64

Die Basis-Klassen von SWTOGL sind GL, GLU und GLContext . Im Gegensatz zu JOGL werden die OpenGL Methode in der GL- und GLU Klassen als static final native

deklariert. Eine Applikation kann die gerenderte Grafik direkt durch den Aufruf der Methode swapBuffer() des GLContext -Objektes auf dem Bildschirm darstellen. Eine feste Integration in das Event-Framework, wie z.B. der GLEventListener von JOGL, ist nicht zwingend erforderlich. Diese einfache Vorgehensweise entspricht am ehesten der klassischen OpenGL-Programmierung, beispielsweise mit GLX.

4.1.3.1 Native-Anbindung Analog zu JOGL wird die Anbindung von OpenGL in diesem Kapitel anhand der Implementierung an einigen signifikanten Stellen näher erläutert. • Funktion glColor3f() public static final native void glColor3f ( float red, float green, float blue); JNIEXPORT void JNICALL GL_NATIVE(glColor3f) (JNIEnv *env, jclass that, jfloat arg0, jfloat arg 1, jfloat arg2) { GL_NATIVE_ENTER(env, that, glColor3f_FUNC); glColor3f(arg0, arg1, arg2); GL_NATIVE_EXIT(env, that, glColor3f_FUNC); } Java- und C-Code aus GL.java bzw. gl.c

Die verwendeten Makros sind wie folgt definiert (die Marcos GLU_NATIVE_ENTER

werden nur für Statistik-Zwecke benutzt und sind per Default ausgeschaltet): #define GL_NATIVE(func) Java_org_eclipse_swt_opengl _GL_##func extern int GLU_nativeFunctionCallCount[]; #define GLU_NATIVE_ENTER(env, that, func) GLU_nativeFunctionCallCount[func]++; #define GLU_NATIVE_EXIT(env, that, func) Macro Definition aus gl.h

Wie zu erwarten ist bei dieser einfachen Funktion kein Unterschied festzustellen. • Funktion glVertexPointer() : public static final native void glVertexPointer ( int size, int type, int stride, int[] pointer); JNIEXPORT void JNICALL GL_NATIVE(glVertexPointer) (JNIEnv *env, jclass that, jint arg0, jint arg1, jint arg2, jintArray arg3) { jint *lparg3=NULL;

65

GL_NATIVE_ENTER(env, that, glVertexPointer_FUNC); #ifdef JNI_VERSION_1_2 if (IS_JNI_1_2) { if (arg3) lparg3 = (*env)->GetPrimitiveArrayCri tical(env, arg3, NULL); } else #endif { if (arg3) lparg3 = (*env)->GetIntArrayElements( env, arg3, NULL); } glVertexPointer(arg0, arg1, arg2, lparg3); #ifdef JNI_VERSION_1_2 if (IS_JNI_1_2) { if (arg3) (*env)->ReleasePrimitiveArrayCritical (env, arg3, lparg3, 0); } else #endif { if (arg3) (*env)->ReleaseIntArrayElements(env, arg3, lparg3, 0); } GL_NATIVE_EXIT(env, that, glVertexPointer_FUNC); } Java- und C-Code aus GL.java bzw. gl.c

Hier ist deutlich zu erkennen, dass SWTOGL für die Native-Anbindung JNI bis zu Version 1.2 unterstützt. Das von JOGL eingesetzte NIO-Package findet hier keine Verwendung. Das ist gut für die Portierbarkeit, aber hinsichtlich der Geschwindigkeit nicht optimal.

• Anbindung SWT-OpenGL

Die Anbindung von SWT an OpenGL soll am Beispiel der GLContext -Klasse analysiert werden. Die Abbildung 38 verdeutlicht den Verlauf.

Abbildung 38 Sequenz-Diagramm beim Erzeugen des GLContext Objektes

66

Im Konstruktor der GLContext- Klasse sind die erforderlichen Schritte zum Erstellen des OpenGL-Context ersichtlich. Es wird zunächst ein SWT-Grafik-Context (gc ) mit der Methode drawable.internal_new_GC() erzeugt. Diese Methode des drawable -Objektes ist in diesem Fall in der Klasse Control definiert. Verfolgt man den Aufruf, so kann man feststellen, dass schließlich die C-Funktion gdk_gc_new() aufgerufen wird. gdk_gc_new() ist eine Funktion aus der GTK-Toolkit Library. GTK (Gimp Toolkit) ist ein weit verbreitetes Open-Source GUI-Framework. Die X-Window Implementierung von SWT basiert darauf. Die Klasse OS ist aus dem Standard-Package von SWT, in der plattformabhängige Native-Funktionen gekapselt sind.

Offensichtlich liefert die OS -Klasse standardmäßig nur den GTK-Grafik-Context zurück. Um die erforderlichen XLib-Parameter, wie xDisplay und info, für die Funktion glXCreateContext() zu ermitteln, wurde eine weitere Native-Klasse XGTK entwickelt. Die Methode XGTK.gdk_x11_gc_get_xdisplay() ruft die entsprechende GTK C-Funktion gdk_x11_gc_get_xdisplay() auf, um den X-Window-Handler xDisplay zu referenzieren.

public GLContext (Drawable drawable) { if (drawable == null) SWT.error (SWT.ERROR_NULL_A RGUMENT); this.drawable = drawable; data = new GCData (); gc = drawable.internal_new_GC (data); if (gc == 0) SWT.error (SWT.ERROR_NO_HANDLES); int xDisplay = XGTK.gdk_x11_gc_get_xdisplay (gc); int screen = XGTK.XDefaultScreen (xDisplay); ... handle = XGL.glXCreateContext (xDisplay, info, 0, false); } GLContext.java public int internal_new_GC (GCData data) { checkWidget (); int window = paintWindow (); if (window == 0) SWT.error (SWT.ERROR_NO_HANDLES) ; int gdkGC = OS.gdk_gc_new (window); if (gdkGC == 0) error (SWT.ERROR_NO_HANDLES); ... return gdkGC; } Control.java public static final native int _gdk_gc_new(int wind ow); JNIEXPORT jint JNICALL OS_NATIVE(_1gdk_1gc_1new) (JNIEnv *env, jclass that, jint arg0) { jint rc = 0; OS_NATIVE_ENTER(env, that, _1gdk_1gc_1new_FUNC);

67

rc = (jint)gdk_gc_new((GdkDrawable *)arg0); OS_NATIVE_EXIT(env, that, _1gdk_1gc_1new_FUNC); return rc; } OS.java und os.c public static final synchronized native int gdk_x11_gc_get_xdisplay(int gc); JNIEXPORT int JNICALL XGTK_NATIVE(gdk_1x11_1gc_1get _1xdisplay) (JNIEnv *env, jclass that, jint arg0) { jint rc; NATIVE_ENTER(env, that, "gdk_1x11_1gc_1get_1xdisp lay\n") rc = (jint)gdk_x11_gc_get_xdisplay((GdkGC *)arg0) ; NATIVE_EXIT(env, that, "gdk_1x11_1gc_1get_1xdispl ay\n") return rc; } XGTK.java und xgtk.c

4.1.4 JNI und NIO Im folgenden Abschnitt werden die grundlegende Technik und Funktionsweise von JNI und NIO hinsichtlich für OpenGL-Binding relevante Aspekte erläutert. Eine ausführliche Beschreibung befindet sich in [Sun02] und [Hit02]. Um von einem Java-Programm heraus Native-Library Funktionen aufzurufen, hat die Firma SUN das Java Native Interface (JNI) entwickelt. JNI stellt damit die Brücke zwischen der Native- und Java-Seite dar. Anhand eines Beispiels soll die Vorgehensweise verdeutlicht werden. Soll die statische Methode glColor3f () der Klasse GL im net.java.games.jogl Package als Native-Funktion realisiert werden, muss auf der Java-Seite die Methode als native deklariert werden. package net.java.games.jogl; public class GL { ... native public void glColor3f(float red, float gre en, float blue); Native Methode Definition in Java Dann muss eine C-Funktion als „Gegenstück“ entwickelt werden. Dabei sind die definierten Datentypen und Makros zu verwenden und die JNI-Namenkonventionen einzuhalten. Der Programmcode dazu sieht folgendermaßen aus: JNIEXPORT void JNICALL Java_net_java_games_jogl_GL_glColor3f( JNIEnv *env, jobject _this, jfloat red, jfloat gr een, jfloat blue) { glColor3f((GLfloat) red, (GLfloat) green, (GLfl oat) blue); } Native Methode Definition in C

68

Die Parameter JNIEnv *env und jobject _this sind bei JNI obligatorisch. JNIEnv *env

ist die Referenz auf die VM-Umgebung. Über diesen Pointer können weitere JNI-Funktionen aufgerufen werden. jobject _this repräsentiert das aufrufende Objekt selbst. Der Header dieser C-Funktion kann auch mit dem Java-Tool javah > javah –jni GL.java generiert werden. Die Makros JNIEXPORT und JNICALL sorgen für die nötige Portierbarkeit zwischen den Plattformen. Für die Benennung der C-Funktion gilt folgende Regel (Abbildung 39):

Java_ net_java_games_jogl_GL_ glColor3f+ +

Prefix, ist immer

Java_

Der voll-qualifizierte

Klassenname, getrennt durch _

statt .Methodename

Abbildung 39 Namenskonvention der Native-Funktion bei JNI Die erstellte C-Funktion wird anschließend kompiliert und ggf. mit anderen C-Objekt-Dateien zu einer Shared-Library zusammengefasst. Auf QNX kann eine Shared-Library namens libmylib.so beispielsweise wie folgt erzeugt werden. > cc –o libmylib.so –shared –lGL –lGLU –lm gl.o Vor der Benutzung der Native-Funktion muss die Shared-Library noch geladen werden. Dies geschieht mit der Methode System.loadLibrary () und soll typischerweise im static-

Block der Java-Klasse aufgerufen werden. package net.java.games.jogl; public class GL { static { System.loadLibrary(“mylib”); } ... native public void glColor3f(float red, float gre en, float blue); Beispiel zum Laden der externen Library mit der loadLibrary() Methode Im oben gezeigten Beispiel werden float Variablen als Parameter an die C-Funktion übergeben. Prinzipiell können alle Java-Primitive-Datentypen (Tabelle 5) sowie -Objekte (Abbildung 40) als Parameter und Return-Wert übergeben werden.

69

Java-Typ C-Type Grösse in Bit boolean jboolean 8, unsigned byte jbyte 8 char jchar 16 unsigned short jshort 16 int jint 32 long jlong 64 float jfloat 32 double Jdouble 64 void Void -

Tabelle 5 Zuordnung der Java- und C-Datentypen

jobject

jstring jarray jclass

jintArray – int arrays

jfloatArray – float arrays

jobjectArray – arrays of objects

...

...

Abbildung 40 Vordefinierte C-Typen auf Java-Objekte

Java-Objekte werden über „passed by reference“ übergeben. D.h. auf der Native-Seite wird ein Java-Objekt über einen Pointer referenziert. JNI hat dazu einige Pointer-Typen definiert (Abbildung 40). Obwohl es ausreichen würde, alle Java-Objekte über den jobject-Pointer zu referenzieren, sollen laut Konvention stattdessen die dazugehörigen Sub-Typen der Objekte verwendet werden. Bei einer typischen OpenGL-Applikation werden große Datenmengen in einem Vertex-Array abgespeichert und an die Native-OpenGL-Funktionen weitergeleitet. Es ist daher wichtig zu wissen, wie JNI Arrays verwaltet. Hierzu ein Beispiel mit einem Float-Array als Parameter: native public float sum(float[] aFloatArray); JNIEXPORT jfloat JNICALL Java_net_java_games_jogl_GL_sum( JNIEnv *env, jobject _this, jfloatArray aFloatArr ay) { ... } Java- und C-Code für ein Beispiel JNI Aufruf Der Zugriff auf die Java-Objekte erfolgt über Funktionen, die von JNI zur Verfügung gestellt werden. Auf ein Float-Array-Objekt kann beispielsweise wie folgt zugegriffen werden.

70

JNIEXPORT jfloat JNICALL Java_net_java_games_jogl_GL_sum( JNIEnv *env, jobject _this, jfloatArray aFloatArr ay) { int i; float sum = 0; jsize len = (*env)->GetArrayLength(env, aFloatArr ay); jfloat *arr = (*env)->GetFloatArrayElements(env, aFloatArray, 0); for (i=0; i<len; i++) { sum += arr[i]; } ... (*env)->ReleaseFloatArrayElements (env, aFloatArr ay, arr, 0); Return sum; } C-Code für ein Beispiel mit Array bei JNI Die Länge eines Arrays muss immer getrennt mit der Funktion GetArrayLength() ermittelt werden. Beim Aufruf der Funktion GetFloatArrayElements() wird das Array je nach JVM entweder als nicht verschiebbar markiert (pin) oder in einen nicht verschiebbaren Speicherbereich (Nonmoveable Memory) der JVM kopiert, damit der Speicher nicht vom Garbage-Collector zufällig während der Ausführung der Native-Funktion umorganisiert wird. Es ist daher wichtig, nach der Ausführung diesen Speicherbereich mit der Funktion ReleaseFloatArrayElements() wieder freizugeben. Die JVM kopiert dann das Array aus dem Nonmoveable Memory zurück und gibt den Speicherbereich frei. Bei nicht Beachtung dieser Regel kann es zu einem Memory-Leak und sogar zum Absturz der JVM führen. Insbesondere das Kopieren der Arrays, obwohl es im Speicher erfolgt, kann bei großen Datenmengen zu Performance-Verlust führen. Um hier Abhilfe zu schaffen, hat die Firma SUN mit Java 1.2 zwei neue Funktionen eingeführt: GetPrimitiveArrayCritical() und ReleasePrimitiveArrayCritical(). Die Semantik der beiden neuen Funktionen sind vergleichbar mit den bisherigen Get/ReleaseArrayElements() Funktionen. Wenn möglich liefert die JVM einen Pointer auf die „uncopied“ Version des Arrays, unabhängig davon, ob die JVM das „pinning“ (Festnageln) von Speicher unterstützt. Der Name „...Critical“ deutet aber schon an, dass die Verwendung dieser Funktion einige Einschränkungen hat. Um einen konsistenten Zugriff auf den Speicher zu gewährleisten, muss die JVM je nach Implementierung den Garbage-Collector vorübergehend abschalten oder sogar alle anderen Threads stoppen. D.h. der Code zwischen Get/ReleasePrimitiveArrayCritical() bildet eine Art „Critical-Region“. Die Ausführung der Code-Zeilen innerhalb dieser Critical-Region soll deshalb nicht zu lange dauern. Außerdem sind weitere JNI- und System-Calls, die zu Blockaden führen könnten, dringend zu vermeiden. Aufgrund dieser Problematik werden diese Funktionen eher als eine Not-Lösung für akute Performance-Probleme angesehen. Um Abhilfe zu schaffen, hat die Firma SUN mit der Einführung von Java 1.4 das neue NIO-Direkt-Buffer Konzept sowie entsprechende neue JNI-Funktionen eingeführt. Ein Direkt-Buffer repräsentiert einen von der Speicherverwaltung der JVM nicht betroffenen Speicherbereich. Dieser Speicherbereich kann sowohl innerhalb der JVM als auch außerhalb der JVM vom Native-Code erzeugt werden. Der Zugriff auf diesen Speicherbereich ist

71

sowohl auf der Java-Seite (gekapselt als Direct-Buffer-Objekt) als auch auf der Native-Seite transparent. So ist es beispielsweise möglich, Video-Memory oder Register-Mapping-Bereich eines Device-Controllers als Direct-Buffer zu deklarieren und nach Java zu exportieren. In Verbindung mit dem ebenfalls in NIO neu eingeführten Channel-Konzept ist es zum ersten mal möglich, hoch performante oder Hardware nahe Anwendungen mit Java zu realisieren. Die Klassen-Hierarchie des NIO-Buffers ist in Abbildung 41 dargestellt.

Abbildung 41 Klassen-Hierarchie von Java-NIO-Buffer. Quelle [Hit02]. Ein Buffer-Objekt ist ein Array von primitiven Datentypen und hat zusätzlich vier Eigenschaften: • Capacity

Die maximale Kapazität des Buffers wird beim Erzeugen des Buffer-Objektes festgelegt und kann nicht verändert werden.

• Limit

Das erste Element, das nicht gelesen oder geschrieben werden kann. • Position

Der Index des nächsten Elements, das gelesen oder geschrieben wird. Die Position wird automatisch beim Aufruf der relativen get() und put() Methoden aktualisiert.

• Mark

Eine Markierung der Index-Position: beim Aufruf der Methode mark() wird die Markierung auf die aktuelle Position gesetzt. Bei reset() dagegen wird die aktuelle Position auf den Wert der Markierung zurückgesetzt.

Abbildung 42 zeigt den schematischen Aufbau eines Buffer-Objektes.

Abbildung 42 Schematische Aufbau eines Buffer-Objektes. Quelle [Hit02].

72

Für den Zugriff und die Bearbeitung von Buffer-Objekten stehen effiziente Methoden zur Verfügung. Hardwarenahe Aspekte wie Byte-Order (Big- / Little-Endian) werden ebenfalls berücksichtigt. Ausführliche Beschreibungen zu dieser Thematik sind in [Hit02] beschrieben. Für schnelle I/O-Operationen oder für direkten Speicher-Zugriff ist der Direct-Buffer vorgesehen. Ein Direct-Buffer ist keine eigene Java-Klasse, sondern eine spezielle Form von ByteBuffer. Das folgende Beispiel zeigt einen typischen Ablauf. Public ByteBuffer getString() throws Exception { CharBuffer chars = CharBuffer.allocate(100); chars.put(“Hello World\n”); chars.put(“bye bye\n”); chars.flip(); Charset charset = Charset.forName(“US-ASCII”); ByteBuffer buffer = charset.newEncoder().encode(c hars); ByteBuffer directBuffer = ByteBuffer.allocateDire ct(buffer.limit()); directBuffer.put(buffer); return directBuffer; } ... Beispiel Direct ByteBuffer Es wird zunächst ein CharBuffer- Objekt erzeugt und mit Daten gefüllt. Mit der Methode flip() wird der Buffer auf die Übertragung vorbereitet. Dabei werden die internen Zeiger wie Limit und Position auf die richtigen Stellen gesetzt. Anschließend wird ein ByteBuffer- Objekt erzeugt, welches als Inhalt den ASCII-Code des CharBuffer -Objektes (Java-String enthält Unicode Zeichen) enthält. Das eigentliche Direct-Buffer Objekt wird mit ByteBuffer.allocateDirect() erzeugt und bekommt als Inhalt den ByteBuffer mit den ASCII-Zeichen. Das Direct-Buffer-Objekt kann nun beispielsweise über JNI direkt auf ein Low-Level-Device geschrieben werden. Wie bereits oben erwähnt, sind seit Java 1.4 folgende neue JNI Funktionen für das Handling mit Direct-Buffer hinzugekommen: • NewDirectByteBuffer()

Diese Funktion konstruiert ein Direct-Buffer-Objekt aus einem (evtl. außerhalb der JVM reservierten) Speicherbereich. Das Direct-Buffer Objekt wird in der Regel an die Jave-Seite für die Weiterverarbeitung zurückgeliefert.

• GetDirectBufferAddress()

Der Zugriff auf ein Direct-Buffer Objekt, das innerhalb der JVM erzeugt wurde, kann mit Hilfe dieser Funktion erfolgen.

• GetDirectBufferCapacity()

Die Größe des Direct-Buffer Objektes wird mit dieser Funktion ermittelt. Das folgende Beispiel zeigt, wie der Zugriff auf einen Direct-Buffer in JNI-Native-Code erfolgen kann. native private java.nio.ByteBuffer getBuffer(

java.nio.Buffer ptr);

73

JNIEXPORT jobject JNICALL example_Example_GetBuffer(

JNIEnv *env, jobject _unused, jobject ptr) { ... buffer = (*env)->GetDirectBufferAddress(env, ptr) ; ... return (*env)->NewDirectByteBuffer(env, mem, 100) ; } Beispiel JNI Funktionen für Direct ByteBuffer

4.2 Implementierung Auf dem Target liegt eine IBM J9 Java-Virtual-Machine in der Version 1.3 vor. D.h. das von JOGL eingesetzte NIO Package ist nicht vorhanden. Ein weiteres Problem ist die fehlende Native-AWT-Kompatibilität von IBM J9. Diese Kompatibilität wird bei der Zertifizierung nicht gefordert. Beide Faktoren zusammen führen dazu, dass eine Portierung von JOGL in einen vernünftigen Zeitrahmen ausgeschlossen ist. Des Weiteren ist SWTOGL auch für Java 1.3 ausgelegt und SWT ist auf QNX-Photon verfügbar. Aus diesen Gründen wurde für die Portierung SWTOGL ausgewählt. Wie bereits in Kapitel 4.1.3.1 gezeigt, besteht die Hauptaufgabe bei der Portierung darin, den Grafik-Context des SWT-Fensters zu ermitteln und an die Native-OpenGL-Funktionen weiterzuleiten. Analog wie bei der X-Window/GTK Version von SWT wird der Grafik-Context unter Photon durch entsprechende Methoden exportiert. Ein Blick in den Sourcecode von SWT-Photon verdeutlicht das Konzept. Der Grafik-Context wird von der Methode internal_new_GC der Interface-Klasse Drawable

zurückgeliefert. In der Klassenhierarchie der GUI-Komponente wird diese Methode von der Widget-Klasse Control implementiert:

Widget

+internal_new_GC ()

Control

+internal_new_GC ()

«interface»

Drawable

Abbildung 43 Klassendiagramm SWT Widget

74

aGLContext

new

aControl

internal_new_GC

OS

pgCreateGC

Photon Lib

pgCreateGC

Abbildung 44 Sequenz-Diagramm beim Instantiieren des GLContext Objektes

Die Klassen Control und OS sehen folgendermaßen aus: public int internal_new_GC (GCData data) { checkWidget(); int phGC = OS.PgCreateGC(0); if (phGC == 0) SWT.error(SWT.ERROR_NO_HANDLES); ... return phGC; } Control.java public static final native int PgCreateGC(int size) ; JNIEXPORT jint JNICALL OS_NATIVE(PgCreateGC) (JNIEnv *env, jclass that, jint arg0) { jint rc = 0; OS_NATIVE_ENTER(env, that, PgCreateGC_FUNC); rc = (jint)PgCreateGC(arg0); OS_NATIVE_EXIT(env, that, PgCreateGC_FUNC); return rc; } Java- und C-Code aus OS.java und os.c Aus den oben gezeigten Sourcecode-Teilen wird ersichtlich, dass der Photon-Grafik-Context von SWT fehlerfrei exportiert wird. Für eine prototypische Portierung sind mindesten drei Funktionen anzupassen: • CreateContext() • MakeCurrent() • SwapBuffers()

75

Es ist also eine neue Java-Klasse sowie die dazugehörige C-Library mit den drei Funktionen zu realisieren. Auf der Java-Seite wird dazu ein neues Package parallel zu der X11/GTK Version erstellt.

aGLContext

new

aControl

internal_new_GC

OS

pgCreateGC

Native Photon Lib

pgCreateGC

PhotonGL

glPhotonCreateContext

Native OSMesa Lib

createOSContext

Abbildung 45 Sequenz-Diagramm CreateContext

Die neue PhotonGL- Klasse sieht wie folgt aus: package org.eclipse.swt.opengl.internal.photon; import org.eclipse.swt.opengl.Library; public class PhotonGL { static { Library.loadLibrary("photonGL"); } public static final native int glPhotonCreateCont ext(int gc); public static final native boolean glPhotonMakeCu rrent(); public static final native void glPhotonSwapBuffe rs(); } PhotonGL.java Der äquivalente C-Code ist nachfolgend aufgelistet: JNIEXPORT jint JNICALL GL_NATIVE(glPhotonCreateCont ext) (JNIEnv *env, jclass that, jint gc) { DEBUG_CALL("glPhotonCreateContext\n") return glICMCreateContext(SCREEN_WIDTH_3D, SCREEN _HEIGHT_3D, 0, gc); } JNIEXPORT jboolean JNICALL GL_NATIVE(glPhotonMakeCu rrent) (JNIEnv *env, jclass that) {

76

DEBUG_CALL("glPhotonMakeCurrent \n") return glICMMakeCurrent(); } JNIEXPORT void JNICALL GL_NATIVE(glPhotonSwapBuffer s) (JNIEnv *env, jclass that) { DEBUG_CALL("glPhotonSwapBuffer \n") glICMSwapBuffer(); } PhotonGL.c Aus dem C-Code wird anschließend eine Shared-Library mit dem Name libphotonGL.so erstellt. Diese Shared-Library muss zur Laufzeit vom System auffindbar sein, z.B. durch Setzen der System-Variable LD_LIBRARY_PATH. In der Klasse GLContext sind die drei Methoden wie folgt implementiert36. public GLContext (Drawable drawable) { if (drawable == null) SWT.error (SWT.ERROR_NULL_A RGUMENT); this.drawable = drawable; data = new GCData (); gc = drawable.internal_new_GC (data); PhotonGL.glPhotonCreateContext(gc); }

public void setCurrent () { PhotonGL.glPhotonMakeCurrent(); } public void swapBuffers () { PhotonGL.glPhotonSwapBuffers(); } GLContext.java Die neuen Methoden sind völlig transparent und können von jedem SWTOGL-Programm ohne Code-Änderungen verwendet werden. Der folgende Code zeigt ein lauffähiges Beispiel. public class HelloWorld { private Canvas glCanvas; private GLContext context; public void run() { // init SWT Display display = new Display(); Shell shell = new Shell(display); shell.setLayout( new GridLayout()); shell.setLocation(1,1);

36 Die Klasse GLContext ist in der vorliegenden Version von SWTOGL nicht als Interface oder abstrakte Klasse ausgelegt, d.h. alle plattformabhängigen Codes werden hier fest kodiert. Für unterschiedliche Plattform werden entsprechend angepasste Versionen ausgeliefert.

77

GridData gridData = new GridData(); gridData.heightHint = 97; // hack gridData.widthHint = 320; gridData.verticalAlignment = GridData.BEGINNING ; glCanvas = new Canvas(shell, SWT.NONE); glCanvas.setLayout(new GridLayout()); glCanvas.setLayoutData(gridData); glCanvas.setSize(320, 96); // needed for window s shell.pack(); shell.open(); context = new GLContext(glCanvas); context.setCurrent(); GL.glMatrixMode(GL.GL_PROJECTION); GL.glLoadIdentity(); GL.glOrtho(0.0, 1.0, 0.0, 1.0, -1.0, 100.0); GL.glClearColor(0.7f, 0.7f, 0.7f, 0.7f); GL.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH _BUFFER_BIT); GL.glLoadIdentity(); GL.glBegin(GL.GL_POLYGON); GL.glVertex3f(0.25f, 0.25f, 0.0f); GL.glVertex3f(0.75f, 0.25f, 0.0f); GL.glVertex3f(0.75f, 0.75f, 0.0f); GL.glVertex3f(0.25f, 0.75f, 0.0f); GL.glEnd(); GL.glFlush(); context.swapBuffers(); while( !shell.isDisposed()) { } display.dispose(); } Beispiel Programm mit SWTOGL/Photon auf dem Target Zum Ausführen des Programms auf dem Target sind für unterschiedliche Komponenten einige Java- und C-Libraries erforderlich: • JRE

Die Basis-Klassen der Java Runtime Environment von J9 sind: o JclMax/classes.jar o runtime.jar o jface.jar

• SWT

Die Basis SWT-Klassen sind in den folgenden Libraries zusammengefasst: o Java: swt.jar o C: libswt-photon-3138.so

• SWTOGL

Das potierte OpenGL-Binding sowie die Shared-Libraries dazu sind hier zu finden: o Java: swtopengl.jar o C: libgl-photon.so o C: libphotonGL-photon.so

78

• OpenGL

Die OpenGL-Mesa-Libraries: o OSMesa.so o GL.so o GLU.so

• Anwendung

Die Java-Klassen der eigentlichen Anwendung: o Gears.class

All diese Libraries müssen zur Laufzeit von der JVM auffindbar sein. Ein möglicher JVM-Aufruf kann wie folgt aussehen: export JAVAROOT=/usr/qnx630/host/qnx6/x86/usr/qde/e clipse/jre/ export CLASSPATH=.:$JAVAROOT/lib/jclMax/classes.zip :\ $JAVAROOT/lib/eclipse/swt.jar:\ $JAVAROOT/lib/eclipse/jface.jar:\ $JAVAROOT/lib/eclipse/runtime.jar:\ /root/java/swt-opengl-photon/swtopengl.jar export LD_LIBRARY_PATH=$JAVAROOT/bin:\ /root/Mesa-6.0-OS/lib:/root/java/swt-opengl-photon $JAVAROOT/bin/j9 Gears Beispiel-Aufruf von Java-Gears-Demo

4.3 Evaluierung und Diskussion Um die Funktionsfähigkeit der durchgeführten Portierung zu prüfen, wurde die Java-Version des Gears-Demoprogramm aus dem JOGL-Beispiel für Tests auf dem Target adaptiert. Abbildung 46 zeigt einen Screenshot des lauffähigen Gears-Demoprogramms. Aus dem Blickwinkel der Grafikdarstellung ist kein Unterschied zu der C-Implementierung festzustellen.

Abbildung 46 Gears Demo in Java mit SWTOGL

Zur Beurteilung der Ergebnisse wurde ein einfacher Performance-Test durchgeführt, bei dem jeweils die Framerate (FPS) der Java-Version und einer C-Version auf dem Target gemessen wurde. Und zwar jeweils mit und ohne Bildschirm-Ausgabe. Tabelle 6 zeigt die Ergebnisse

79

FPS mit Java FPS mit C Mit Ausgabe 32 50 Ohne Ausgabe 44 59

Tabelle 6 Messergebnisse Gears-Demo mit Java/SWTOGL und C auf dem Target Im direkten Vergleich ist die Framerate der Java-Version erheblich schlechter. Ziel der Portierung war allerdings nicht primär die Performance zu beurteilen, sondern viel mehr einen Einblick über die Machbarkeit zu gewinnen. Die erfolgreich durchgeführte Portierung von SWTOGL bestätigt, dass die Entwicklung von 3D-Applikationen für das Target mit Java möglich ist. Eine fundierte Leistungsbewertung ist bei dem derzeitigen Software-Stand nicht möglich. Die schlechte Performance bei den durchgeführten Tests ist auf die noch nicht optimal implementierten OpenGL-Binding zurückzuführen. Für eine gute Gesamt-Performance sind folgende Punkte erforderlich: • eine leistungsfähige JVM, • ein effizientes Java-Binding und • eine (evtl. hardwarebeschleunigte) OpenGL-Library. Nur durch das optimale Zusammenwirken dieser Komponenten wird Java im Bereich 3D-Grafik auf Embedded-Systemen konkurrenzfähig sein. Die lange Startzeit der JVM beim Hochfahren des Systems ist ein Hauptargument gegen den Einsatz von Java im Automotive-Bereich. Dieser Nachteil fällt hier nicht so sehr ins Gewicht. Ein Navigationssystem, das 3D-Karte in Java rendert, muss nicht sofort beim Start verfügbar sein. Auch eine kleine Verzögerung bis zum Erscheinen des ersten Bildes kann durchaus akzeptiert werden. JOGL in Verbindung mit Java 1.4 stellt im Moment das beste OpenGL-Binding dar. Insbesondere der konsequente Einsatz von NIO-Buffer führt zur performanten Verarbeitung auch mit komplexen und großen 3D-Modellen. Sollte die IBM J9 endgültig in der Version 1.4 vorliegen, so ist es sicherlich eine interessante Aufgabe, JOGL auf die J9- / SWT-Plattform zu portieren. Der Aufwand dürfte sich in Grenzen halten, da die Sourcecodes zum Großteil durch intelligente Generator-Tools erstellt werden. SWTOGL ist ein schlankes OpenGL-Binding, welches noch in der Entwicklungsphase befindet und noch keine Produktions-Qualität erreicht hat. Gerade durch das einfache Design ist es für eine Portierung ideal geeignet. Fällt die Design-Entscheidung für einen objektorientierten Ansatz nach dem Szenen-Graph-Modell, so ist der Einsatz von Java3D aus softwaretechnischen Sicht die beste Alternative. Laufzeitzeitverhalten und Portierbarkeit auf dem Target müssen aber noch eingehender untersucht werden. Dank der Open-Source-Politik der oben evaluierten Produkte ist es möglich, Einblicke in die interne Funktionsweise zu gewinnen und eine erste Bewertung vorzunehmen. Das Analysieren des Sourcecodes war sehr lehrreich; es weckt Interesse auf weiterführende Untersuchungen.

80

5 3D-Modelle und Fisheye View Echtzeit-3D-Darstellung von POI-(Point of Interest)-Objekten oder z.B. eine Navigationsfahrt durch Städte mit realitätstreuer 3D-Darstellung der Umgebungsgebäude sind Funktionen, die die Navigationssysteme der nächsten Generation anbieten werden. Bereits heute sind einige Großstädte in Deutschland komplett digitalisiert. Auch die POI-Datenbank der Kartenzulieferfirmen wächst von Tag zu Tag. Für die Weiterverarbeitung werden die eingescannten Daten in 3D-Modellierungsprogramme importiert und in entsprechende Formaten abgespeichert. Ein Navigationssystem muss also in der Lage sein, 3D-Modelle aus der Datei zu lesen und zu visualisieren. 3D-Viewer sind im PC-Bereich für verschiedene 3D-Formate verfügbar. Ob sich allerdings ein solcher 3D-Viewer auch auf dem Target mit OpenGL realisieren lässt, ist noch ungeklärt. Im Rahmen dieser Arbeit soll daher ein 3D-Viewer implementiert werden, der sowohl kleinere POI-Objekte als auch größere 3D-Stadt-Modelle visualisieren kann. Als weiteres Feature soll eine Fisheye-View realisiert werden. Dabei soll ein 3D-Stadt-Modell ähnlich wie bei einem Globus auf eine Halb-Kugel projiziert werden.

5.1 Grundlagen

5.1.1 3D-Formate In den Kapitel 2, 3 und 4 wurden bereits mehrfach gezeigt, wie ein 3D-Objekt oder gar ein komplettes Gelände aus Vertices und Texturen mit einem OpenGL-Programm erzeugt wird. In der Praxis werden 3D-Objekte jedoch mit einem Modellierungsprogramm erstellt und anschließend in einer Datei eines bestimmten 3D-Formates abgespeichert. Sowohl ein einzelnes Objekt als auch eine komplette 3D-Szene können so wieder eingelesen und dargestellt werden. Wie in anderen Gebieten der Informatik existieren auch hier eine Menge von proprietären, wie offenen, 3D-Formate. Grundsätzlich gibt es verschiedene Möglichkeiten, 3D-Objekte zu beschreiben. Neben den von OpenGL verwendeten Gitter- und Flächen-Modellen, bei denen ein 3D-Objekt durch Kanten zwischen einzelnen Punkten sowie von Kanten eingeschlossene Flächen (Polygonzügen und –Flächen37) repräsentiert werden, gibt es noch weitere Modelle. Auch wenn diese alternativen Modelle nicht von den gängigen 3D-Modellierungstools verwendet werden, werden diese nachfolgend kurz erwähnt: • Punktwolke

Eine sehr einfache Form der Darstellung. Dabei werden 3D-Objekte durch eine Menge von einzelnen Punkten im Raum beschrieben. Es gibt keine Informationen über Kanten, Flächen oder Volumen des Objektes.

• Volumenmodell

Bei diesem Modell wird ein 3D-Objekt durch geometrische Körper beschrieben. Ein Objekt kann entweder aus einfachen Grund-Objekten wie Würfel, Kugel, Pyramide usw. oder aus komplexeren Grund-Objekten wie Freiformkörper oder Fraktale

37 vgl. Kapitel 2.1.2

81

zusammengesetzt werden. Bekannter Vertreter dieses Modells ist das Voxel-Modell. Dabei wird ein Objekt aus einer Menge von kleineren Objekten gleicher Größe (in der Regel Würfel) approximiert. Weitere Vertreter des Volumen-Modells sind beispielsweise Octree, Bintree oder CSG-Tree. Ausführliche Informationen darüber sind in [Wat02] verfasst.

Neben dem zugrunde gelegten Darstellungsmodell lassen sich 3D-Formate je nach Einsatzgebiet und Anforderungen in verschiedene Kategorien unterteilen. Die wichtigsten sind Folgende: • CAD/CAM Formate

CAD-Systeme werden typischerweise in der Konstruktion und Fertigung eingesetzt. Nicht die realistisch gerenderte Darstellung, sondern die präzise und detaillierte Beschreibung des Objektes steht hier im Vordergrund. Gängige Formate sind:

o DXF: Ein von der Firma Autodesk (AutoCAD) spezifiziertes Format zum Austausch von CAD-Daten.

o IGES: ANSI Standard

• Modellierung- und Animationsformate Im Gegensatz zu CAD-Formate enthalten Modellierungsformate zusätzlich zu den Objekt-Daten auch die komplette Beschreibung der Szene inklusiv Effekte, Lichter, Kamera-Einstellung usw. Einsatzgebiete von Modellierungsprogrammen reichen von High-End-Simulatoren über die Film-Industrie bis zu der Computerspiel-Branche. Beispiele dieses Formates sind:

o 3DS: Dieses Format wird von dem Modellierungstool 3D Studio der Firma Autodesk verwendet. Obwohl die Spezifikation nicht offen gelegt ist, wird das Format aufgrund der weiten Verbreitung des Programms sehr häufig als Austausch-Format eingesetzt.

o OBJ: Das Format von dem Programm Advance-Visualizer der Firma Alias Wavefront, in der Praxis auch als Austausch-Format sehr beliebt.

o MB: Das Format des High-End Modellierungsprogrammes Maya von Alias. o BLEND: Das Open-Source Modellierungsprogramm Blender erfreut sich

immer größerer Beliebtheit. Obwohl es durch die offene Architektur praktisch mit allen gängigen 3D-Formaten umgehen kann, hat das Programm auch ein eigenes Format.

o U3D: Das Universal-3D Format wurde von der ECMA als ECMA-363 standardisiert und dient als herstellerübergreifendes 3D-Austausch-Format.

• Internet-basierte Formate

Diese Formate wurden speziell für die Übertragung und Darstellung von 3D-Szenen über Internet entwickelt. Durch entsprechende Client-Programme oder Browser-Plug-In werden die übertragene 3D-Szene beim Anwender sichtbar. Aspekte wie Kompression oder Streaming werden bei diesen Formaten aufgrund der oft geringen Bandbreite des Netzes mitberücksichtigt. Typische Vertreter sind:

o WRL: Datei dieses Formates enthält Szenenbeschreibung gemäß der VRML Spezifikation. VRML (Virtual Reality Modeling Language) ist eine standardisierte (ISO/IEC 14772) Sprache zur Beschreibung interaktiver 3D-Szene.

o X3D: Das Nachfolger-Format von WRL, ist XML basiert und weist gegenüber WRL einige Verbesserungen auf.

82

In den folgenden Abschnitten wird der Aufbau für zwei häufig verwendete Formate (3DS und OBJ) der 3D-Modellierung näher erläutert.

5.1.1.1 Das OBJ-Format Das OBJ-Format des Modellierungsprogrammes Advanced Visualizer der Firma Wavefront ist ein ASCII Format und daher besonders als Austausch-Format geeignet. Die Spezifikation ist öffentlich zugänglich. Das Format unterstützt Linien, Polygone, Freiform-Kurven (z.B. Bezier, B-Spline) und Oberflächen. Linien und Polygone werden durch ihre Punkte beschrieben. Bei Kurven und Oberflächen dagegen sind es die Kontrollpunkte oder geometrische Parameter des jeweiligen Objektes. Daten werden zeilenweise interpretiert. Eine Zeile beginnt mit einem Schlüsselwort gefolgt von schlüsselwortabhängigen Attributen. Um beispielsweise ein Polygon zu definieren, werden zunächst die Eckpunkte mit dem Schlüsselwort v spezifiziert und anschließend die entstandene Fläche mit dem Schlüsselwort f angegeben. Dabei legen die Attribute von f die Reihenfolge der zuvor definierten Eckpunkte fest. Das folgende Beispiel beschreibt ein einfaches Dreieck. v 0.0 0.0 0.0 v 0.0 1.0 0.0 v 0.0 0.0 1.0 f 1 2 3

Farb- und Material-Informationen werden nicht in dem OBJ-Format definiert, sondern in einer externen Material-Library (Material Library File, *.MTL). Diese Material-Library kann mit dem Schlüsselwort mtllib geladen werden. Die Material-Library enthält Informationen wie Farbe, Material-Beschaffenheit oder Eigenschaften wie Transparenz und Lichtbrechung. In der OBJ-Datei kann ein Material mit dem Schlüsselwort usemtl referenziert werden. Alle folgenden Flächen bekommen dieses Material bis zum nächsten usemtl Befehl zugeordnet. Szene-Beschreibung ist in dem OBJ-Format nicht explizit vorgesehen. Es können allerdings Objekt-Gruppen und somit Hierarchien definiert werden.

5.1.1.2 Das 3DS-Format Ein sehr weit verbreitetes 3D-Format ist das 3DS von Autodesk 3D Studio. Die Spezifikation dieses Formats ist nicht offen gelegt. Es existieren jedoch einige inoffiziellen Beschreibungen zu dem Format. Im Gegensatz zum einfach aufgebauten OBJ-Format ist 3DS ein binäres Format und von der Struktur her etwas komplexer. 3DS-Dateien bestehen aus sog. Chunks (Blöcken). Jeder Chunk beginnt mit einer ID, die die Art der in diesem Chunk enthaltenen Daten festlegt. Darauf folgt die Länge des Chunks. Ein 3DS-Loader-Programm kann somit ein Chunk mit unbekannter ID ignorieren und einfach zum nächsten Chunk überspringen. Chunks sind in Hierarchie-Ebene eingeordnet. In dieser Hierarchie können die meisten Chunks nur an bestimmten Stellen vorkommen. Einige wenige Chunks dagegen, wie etwa Farbwerte, können an unterschiedlichen Positionen auftreten. Abbildung 47 zeigt den vereinfachten Aufbau schematisch.

83

Abbildung 47 Schematische Darstellung des 3DS-Formats

Der MAIN3DS38 Chunk leitet die Hierachie in der Datei ein. Die Konfigurationen des 3D Studio Desktops zum Zeitpunkt der Speicherung werden in den Chunks wie EDIT_CONFIGS1 oder EDIT_VIEW_P1 festgehalten. Material-Informationen stehen global in dem EDIT_MATERIAL Chunk und können von Polygon-Flächen individuell referenziert werden. Mehr von Bedeutung für einen 3DS-Viewer ist der EDIT_OBJECT Chunk. Hier sind sowohl die geometrischen Objekte als auch Objekte wie Licht und Kamera definiert. Geometrische Objekte werden in 3DS als Dreieck-Gitter (Triangle-Mesh) unter dem Chunk OBJ_TRIMESH gespeichert. Der Sub-Chunk TRI_VERTEXL beinhaltet die Anzahl der Punkte sowie deren Koordinaten des Triangle-Mesh Objektes. Die Oberflächen des Triangle-Mesh Objektes werden in dem Sub-Chunk TRI_FACEL1 definiert, dabei wird jede Polygon-Fläche durch 3 Punkte (Index auf TRI_VERTEXL) beschrieben. Die im EDIT_OBJECT Chunk definierten Objekte werden der Reihe nach hintereinander gespeichert. Die Strukturen und Hierarchien der gesamten 3D-Szene sind im KEYF3DS Chunk abgelegt. Dieser Chunk ist eigentlich für die Definition von sog. Keyframes (Schlüsselpositionen von Objekten für Animationen) vorgesehen und bietet aber auch Möglichkeiten, Objekt-Hierarchien zu definieren.

5.1.2 Fisheye View In der Computergrafik versteht man unter einer klassischen Fisheye View eine wie in Abbildung 48 (a) gezeigten Projektion. Diese Bilder entstehen entweder durch Aufnahme mit einer entsprechenden Kamera und Linse oder durch Nachbearbeitung mit einem Bildverarbeitungsprogramm.

38 Die Benennung der Chunks sind aus [Bou96] übernommen.

84

Abbildung 48 (a) Eine klassische Fisheye-Projektion. (b) Eine normale 2D-Karte Darstellung. (c) Vergrößerung mit einer Fisheye-Linse

Solche Visualisierungseffekte werden auch als eine Art Vergrößerungslinse (Fisheye-Linse) beispielsweise bei der Darstellung von Landkarten verwendet (siehe Abbildung 48 (b) (c)). Im 3D-Bereich wird diese Vergrößerungstechnik (3D-Fisheye Zoom nach [Raab96]), u.a. auch für die Visualisierung von medizinischen Daten eingesetzt.

Abbildung 49 Hervorhebung durch 3D-Fisheye Zoom bei der Visualisierung

von medizinischen Daten nach [Raab96] Überträgt man diese Darstellungseffekt auf eine 3D-Karte mit plastischen Häuser-Modellen, so entsteht eine interessante Perspektive. Zum Beispiel stehen Häuser auf einem kugelförmigen Grundriss wie auf der Erdkugel. In der Mittel der Kugel werden die Objekte vergrößert und mit mehr Details dargestellt als Objekte am Rande der Kugel. Eine mögliche Projektion dieser Art ist in Abbildung 50 als Schnitt dargestellt.

85

x

z

(a)

(b)

Abbildung 50 (a) Objekte/Häuser auf der Ebene.

(b) Projektion der Objekten/Häuser auf eine Kugelfläche. Die in der Literatur beschriebenen Verfahren von Fisheye-Projektionen beschränken sich meist auf die Vergrößerung von 2D-Bilder. Auch das in [Raab96] vorgestellte Verfahren lässt sich hierfür nur bedingt übertragen. Im Bereich der Kartografie existieren zwar eine Menge von Verfahren zum Thema Kugel-Projektion39. Sie behandeln jedoch den Umgekehrten Fall, nämlich die Projektion der Daten von der Kugeloberfläche (Erde) auf eine Ebene (Landkarte). Ausserdem sind diese Daten zwei dimensional. Die Grundlage für eine derartige Projektion kann aber auch aus einfachen geometrischen Überlegungen hergeleitet werden. Ein Punkt p(x, y, z) auf der Kugelfläche mit dem Radius r kann durch die Winkel θ und φ wie folgt ausgedrückt werden (siehe Abbildung 51).

x = r · sin θ · sin φ (1) y = r · sin θ · cos φ (0 ≤ θ ≤ π und 0 ≤ φ < 2π) z = r · cos θ

39 Vgl. [Sosna]

86

θ

φ

r

p(r, θ, φ)

270° 90°

180°

y

x

z

Abbildung 51 Winkel θ und φ in Beziehung zu Punkt p Um die Koordinaten von Punkt p’ auf der Kugelfläche nach (1) zu berechnen, müssen zunächst die Winkel θ und φ bestimmt werden. Der Punkt p aus der original Darstellung wird dabei auf die Ebene bei z=0 projiziert (siehe Abbildung 52). Ausgehend von dieser Position kann θ und φ ermittelt werden.

x

z

p

θ

p’x’

z’

rh r+z

x

z

Ebene bei z=0

Projizierte Stelle auf der

Ebene von p

Abbildung 52 Herleitung der Projektion von p nach p’ bei φ = 90° oder 270°

87

Abbildung 53 zeigt die geometrische Beziehung zwischen dem Punkt p und den Winkel θ und φ. Daraus lässt sich die Formel (2) konstruieren.

θ

h

z

φ

x

z y

x

y

p

p’

Abbildung 53 Bestimmung von θ und φ

θ = arctan( sqrt(x 2 + y2) / h) (2) φ = arctan( x / y )

Die Formel für die Koordinaten von Punkt p’(x’, y’, z’) auf der Kugeloberfläche kann aus (1) hergeleitet werden.

x’ = (r+z) · sin θ · sin φ (3) y’ = (r+z) · sin θ · cos φ z’ = ((r+z) · cos θ ) - h

Die Größe h und r können je nach gewünschtem Effekt (Krümmung und Verzerrung) angepasst werden. Dabei soll h logischerweise kleiner als r gewählt werden.

5.2 Implementierung Das für die Evaluierung zur Verfügung gestellte 3D-Stadt-Modell liegt in 3DS-Format vor. Es ist daher nahe liegend, ein 3DS-Viewer zu implementieren. Es existieren aufgrund der weiten Verbreitung dieses Formates einige Tutorials und Open-Source-Projekte im Internet. Das Beispielprogramm aus [GamTut] wurde als Basis der Implementierung herangezogen. Wie bereits im Kapitel 3.2 dargestellt, werden auch bei diesem Programm die SDL-Funktionen durch entsprechende glICM-Funktionen ersetzt. Wie bei der OpenGL-Programmierung üblich, teilt sich der Ablauf des Programms in zwei Phasen. In der Initialisierungsphase wird die 3DS-Datei eingelesen. In der Darstellungsphase

88

wird die 3D-Szene in einer Schleife abhängig von der Kamera-Einstellung gerendert und angezeigt. Das Kernstück des Programms ist die 3DS-Import-Funktion Import3DS() . Hier wird die 3DS-Datei gemäß der Formatbeschreibung in Kapitel 5.1.1.2 importiert. In der Funktion ProcessNextChunk() der Klasse CLoad3DS wird ein Chunk mit der Funktion ReadChunk() eingelesen. Je nach Chunk-Typ werden weitere Funktionen wie ProcessNextObjectChunk () oder ProcessNextMaterialChunk() rekuriv aufgerufen. Ist ein Objekt-Chunk gefunden, so werden die Vertex-Koordinaten dieses Objektes mit den Funktionen wie ReadVertices() oder ReadVertexIndices() eingelesen und in entsprechende Arrays abgespeichert. In der Darstellungsphase wird die Koordinaten-Transformation für die Fisheye-Projektion gemäß Formel (3) optional in der Funktion RenderScene() durchgeführt. Bei der Berechnung der Winkel φ sind die Vorzeichen der x- und y-Koordinaten zu beachten und Korrekturen ggf. vorzunehmen. Anschließend werden die Vertices mit der bekannten Funktion glVertexf() an OpenGL weitergeleitet und somit die 3D-Szene gerendet.

5.3 Diskussion Die mit dem Viewer eingelesenen und gerenderten POI-Objekte sind in Abbildung 54 dargestellt. Die Kenndaten der Objekten: (a) 437 Vertices, 336 Faces, 2 Objects. (b) 437 Vertices, 336 Faces, 2 Objects.

Abbildung 54 Ein gerendertes POI Objekt. Ein Screenshot des Stadt-Modells ist in Abbildung 55 zu sehen. Die Kenndaten des Objektes: 48859 Vertices, 55887 Faces, 2435 Objects. Im direkten Vergleich zum POI-Objekt machen sich die fehlenden Texturen des Stadt-Modells optisch bemerkbar.

Abbildung 55 Stadt-Modell als normale Perspektivendarstellung

89

Abbildung 56 zeigt das Stadt-Modell in Fisheye-View aus verschiedenen Blick-Richtungen. Hier sind an manchen Stellen Sprünge zu erkennen. Das liegt daran, weil die langen Linien in dem vorgelegten Modell nur durch einige wenige Stützpunkte modelliert wurden. Die später für die Produktion vorgesehenen Modelle werden mit mehr Punkten ausgestattet sein.

Abbildung 56 Stadt-Modell in Fisheye-View aus verschiedenen Blick-Richtung

Als Vergleich wurde ein kommerzielles Straßen-Modell40 mit dem Viewer auf einem X86 PC gerendert. Das Modell entspricht etwa den Szenen aus Computerspielen. Navigationssysteme der nächsten Generation könnten eine solche Ansicht darstellen. Das Rendern dieser Bilder nimmt aber erheblich mehr Zeit in Anspruch. Ohne Hardwarebeschleunigung ist eine solche Anwendung daher nicht realisierbar.

40 Quelle [TurboS]

90

Abbildung 57 Darstellung einer künstlichen 3D-Straßen-Szene

91

6 Zusammenfassung und Ausblick Ziel dieser Arbeit war anhand von ausgesuchten Themen die Möglichkeit der Integration von 3D-Grafik in einem Automotive-Embedded-System zu evaluieren. Dabei wurden in vier Kapiteln unterschiedliche Untersuchungen durchgeführt. In Kapitel 2 wurde eine mit 3D-Grafik animierten GUI zum Demonstrationszweck erörtert. Im Grundlagenteil dieses Kapitels wurden zunächst die Möglichkeiten der Integration von GUI mit 3D-Unterstützung in der HMI-Komponente sowie in das gesamte Automotive Framework diskutiert. Ausserdem wurde auf einige Basiskonzepte der OpenGL-Programmierung eingegangen, die auch im Rahmen dieser Arbeit eingesetzt wurden. Für die Realisierung der GUI wurde die Open-Source OpenGL-Implementierung Mesa auf dem Target portiert. Für die OpenGL-Anbindung zum QNX-Window-System Photon wurde eine eigene Entwicklung als Ersatz für das fehlende kommerzielle Produkt von QNX prototypisch implementiert. Die Ergebnisse bezüglich der Funktionalität waren sehr zufriedenstellend. Die Performance war dagegen, nicht zuletzt wegen der fehlenden Hardware-Beschleunigung, weniger überzeugend. Anzumerken bleibt, dass Performance-Optimierung kein Gegenstand dieser Arbeit ist und somit als Thema für ergänzende Ausarbeitungen vergeben werden könnte. Für solche Ausarbeitungen würde sogar eine neue Target-Hardware mit einem hardwarebeschleunigten 3D-Grafik-Chipsatz und mit der OpenGL-Library ausgestattet zur Verfügung stehen. Dadurch lassen sich zusammen mit der Multi-Layer-Technik interessante 3D-GUI und 3D-Anwendungen realisieren. Im Kapitel 3 wurde ein Algorithmus mit LOD-Unterstützung für die Darstellung von 3D-Geländen auf dem Target portiert. Das Ziel der Arbeit war, zu untersuchen, ob ein derartiges Verfahren, das normalerweise für High-End-Simulationen konzipiert ist, auch auf die verfügbare Target –Hardware mit beschränkten Ressourcen eingesetzt werden kann. Auch die Portierbarkeit eines komplexeren OpenGL-Programm sollte in diesem Rahmen gezeigt werden. Der eingesetzte SOAR-Algorithmus ist ein weit verbreitetes Verfahren. Varianten davon werden sowohl für Simulatoren in der Industrie als auch in Computerspielen verwendet. Im Grundlagenteil dieses Kapitels wurde kurz auf dieses Verfahren eingegangen. Für die Implementierung wurde ein auf dem Windows-Plattform lauffähiges OpenGL-Programm portiert. Die Portierung erfolgte weitest gehend problemlos, es waren hauptsächlich Code-Anpassungen in der Verbindungsschicht zu QNX-Photon erforderlich. Die eingesetzte Mesa-Library auf der SH4-Target-Plattform hat sich als sehr ausgereift erwiesen. Für die Evaluierung des Verfahrens wurden einige Tests durchgeführt. Die korrekte Arbeitsweise des LOD-Algorithmus konnte durch Einstellung der Parametern gezeigt werden. Weiterhin wurde gezeigt, dass Gittergröße von 512 x 512 Punkten derzeit die Obergrenze für das Target-System darstellt. Der implementierte Prototyp kann nur mit Geländen umgehen. Für ein richtiges 3D-Navigationssystem müssen noch Strassen, Landschaftslayer und weitere Objekte, wie z.B. Häuser oder gar Stadt-Modelle, die wiederum in unterschiedlichen Formaten vorliegen, integriert werden. Für den produktiven Einsatz sind daher alternative Algorithmen zu evaluieren.

92

OpenGL Java-Bindings wurden im Kapitel 4 behandelt. Dabei wurden drei Open-Source OpenGL Java-Binding bezüglich Konzeption und Native-Anbindung eingehend untersucht. Diese Produkte haben jeweils ihre Stärken und Schwächen. JOGL ist die Referenz-Implementierung von Sun und ist konzeptionell ein „Eins zu Eins“-Binding. Bezüglich der Performance ist JOGL zurzeit das beste Open-Source Java-Binding auf dem Markt. Java3D verfolgt dagegen ein High-Level-Ansatz, hier werden 3D-Objekte in einer virtuellen Welt nach dem Szenen-Graph-Modell abstrahiert. Java3D ist nicht so performant wie JOGL, bietet aber viel mehr High-Level-Funktionalitäten. SWTOGL schliesslich ist ein experimentelles Java-Binding für das SWT-GUI-Framework. Aufgrund der fehlenden AWT-Unterstützung bei der installierten Java Virtual Machine J9 wurde SWTOGL für die Portierung ausgewählt. Die Portierung konnte mit den in Kapitel 2 beschriebenen Funktionen für die Photon-Anbindung erfolgreich durchgeführt werden. Die einwandfreie Funktionalität konnte durch anschließende Tests nachgewiesen werden. Die Performance ist wie erwartet nicht zufriedenstellend. Hier sind sowohl auf Seite der Virtual Machine (J9 ist noch nicht in der Version 1.4 verfügbar) als auch auf Seite der OpenGL-Anbindung Verbesserungspotentiale gegeben. In Kapitel 5 wurde ein 3D-Viewer zum Visualisieren von 3D-Modellen auf dem Target portiert. Zusätzlich ist eine Fisheye-Projektion als Visualisierungseffekt implementiert. Ebenso wurde ein kurzer Überblick über die gängigen 3D-Formate gegeben. Ausserdem wurde die geometrische Herleitung der verwendeten Fisheye-Projektion dargestellt. Die Ergebnisse der Implementierung wurden anschließend gezeigt und diskutiert. Die vorliegende Arbeit zeigt, dass 3D-Grafik auf der getesteten Target-Hardware sowohl durchführbar als auch für einfache Anwendungen nutzbar ist. Benutzeroberflächen mit 3D-Animationen sind schon selbst mit einer 3D-Library auf Softwarebasis ohne Einschränkungen möglich. Die im Rahmen dieser Arbeit gewonnenen Erkenntnisse können als Basis bzw. als Einstieg für die Entwicklung zukünftiger 3D-Applikationen im Automotive-Embedded-Bereich herangezogen werden.

93

Literatur [Bou96] 3D-Studio File Format:

http://astronomy.swin.edu.au/~pbourke/dataformat/3ds/. Stand 01.09.2005 [Feh04] J. Fehr: Who Gives a Blit; QNX Technical Articles;

http://www.qnx.com/developers/articles/article_291_2.html. Stand 01.09.2005

[GamTut] Game Tutorials http://www.GameTutorials.com. Stand 01.09.2005 [GLUT] The OpenGL Utility Toolkit:

http://www.opengl.org/resources/libraries/glut.html. Stand 01.09.2005

[Hit02] R. Hitchens: Java NIO; 2002; O’Reilly [ICM04] S.Freitag: Projektbericht InCarMultimedia; Wintersemester 03/04; FH-

Darmstadt [J3DTut] Java3D Tutorial:

http://java.sun.com/developer/onlineTraining/java3d/index.html. Stand 01.09.2005

[Java3D] Java3D: https://java3d.dev.java.net/. Stand 01.09.2005 [JNITut] JNI Tutorial: http://java.sun.com/docs/books/tutorials/native1.1/. Stand

01.09.2005 [JOGL] JOGL: https://jogl.dev.java.net/. Stand 01.09.2005 [JCP] Java Community Process: http://www.jcp.org. Stand 01.09.2005 [Lin01] P. Lindstrom, V.Pascucci: Visualization of Large Terrains made Easy;

2001; Proceedings of IEEE Visualization 2001 [Mesa] Mesa 3D Library: http://www.mesa3d.org. Stand 01.09.2005 [MOST01] Multimedia and Control Networking Technology, Function Catalog MOST

Cooperation, V1.0; 2001 [Nis04] A.Nischwitz, P. Haberäcker: Masterkurs Computergrafik und

Bildverarbeitung; 2004; Vieweg Verlag [QNX3D] QNX: 3D Graphics Technology Development Kit:

http://www.qnx.com/products/tech_dev_kits/3d_graphics.html. Stand 01.09.2005

[Photon04] QNX: Photon microGUI for QNX Neutrino 6.3, Programmer’s Guide;

2004; QNX Software System Ltd

94

[Raab96] Andreas Raab, Michael Rüger: D-ZOOM: Interactive Visualization of

Structures and Relations in Complex Graphics; infix-Verlag; 1996 [SDL] Simple Directmedia Layer: http://www.libsdl.org. Stand 01.09.2005 [Shr04] D. Schreiner, M. Woo, J. Neider, T. Davis: OpenGL Programming Guide,

4rd edition; 2004; Addison-Wesley [SMLynx] Lynx3DM+ DataBook: Silicon Motion, Inc.

ftp://ftp.siliconmotion.com.tw/databooks/SM722_Rev08.pdf. Stand 01.09.2005

[Sosna] D. Sosner: Vorlesungskript Geoinformationssysteme I, Universität Leipzig;

http://www.informatik.uni-leipzig.de/~sosna/karten/netze.html. Stand 01.10.2005

[SWTOGL] SWT Experimental OpenGL Plug-in:

http://www.eclipse.org/swt/opengl/opengl.html. Stand 08.10.2005 [TurboS] Turbo Squid Inc:

http://www.turbosquid.com/FullPreview/Index.cfm/ID/168319/SID/250762/blFP/1; Stand 01.09.2005

[Ulr00] T. Ulrich: Continuous LOD Terrain Meshing Using Adaptive Quadtrees;

2000; Gamasutra; http://www.gamasutra.com/features/20000228/ulrich_01.htm. Stand 01.09.2005

[Wat02] A.Watt: 3D-Computergrafik; 2002; Pearson Studium [Wie05] J. Wietzke, M.T. Tran: Automotive Embedded System; 2005; Springer

Verlag

95

Anhang A: Technische Daten der Target-Hardware

Abbildung 58 Fotografische Abbildung der Target-Hardware CPU Hitachi SH4, 200 MHz Grafik-Chip Silicon Motion Lynx3DM RAM 32 MB Flash 32 MB ATAPI-Laufwerk 20 GB 2,5“ Harddisk, DVD Laufwerk Diaplay Farbdisplay, Auflösung 320 x 96 Pixel Schnittstelle 2 x Seriell, MOST und CAN Erweiterungsslot 1 x PCI, 1 x PCMCIA Netzwerk PCMCIA-Ethernet-Karte Angeschlossene Geräte GPS-Antenne, Tuner und Verstärker über MOST Stromanschluss 12V Stromaufnahme 4 A Betriebssystem QNX 6.3

Tabelle 7 Technische Daten der Target-Hardware. Quelle [ICM04].

96

Gateway-Box Head-Unit

Abbildung 59 Schematische Darstellung der Hardware. Quelle [ICM04].

97

Selbständigkeitserklärung

Ich versichere, dass ich die vorliegende Masterarbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. ____________________________________ Tsz Kwong Yung