Integration von 3D-Visualisierungstechniken in 2D-Grafiksystemen

Bachelorarbeit im Rahmen des Studiengangs
Scientific Programming
Fachhochschule Aachen, Campus Jülich
Fachbereich 9 – Medizintechnik und Technomathematik
Integration von 3D-Visualisierungstechniken
in 2D-Grafiksystemen
Jülich, den 15. August 2012
Florian Rhiem

Erklärung
Diese Arbeit ist von mir selbstständig angefertigt und verfasst. Es sind keine anderen
als die angegebenen Quellen und Hilfsmittel verwendet worden.
Sie wurde im Peter Grünberg Institut/Jülich Centre for Neutron Science – Technische
und Administrative Infrastruktur – Wissenschaftliche IT-Systeme der Forschungszentrum
Jülich GmbH konzipiert.
Unterschrift
Diese Arbeit wurde betreut von:
1. Prüfer: Prof. Dr. rer. nat. Karl Ziemons
2. Prüfer: Josef Heinen

Wissenschaftler am Peter Grünberg Institut/Jülich Centre for Neutron Science untersuchen
in Experimenten und Simulationen Form und Dynamik von Materialen wie
Polymeren, Zusammenlagerungen großer Moleküle und biologischen Zellen sowie die
elektronischen Eigenschaften von Festkörpern. Für die Präsentation der in diesem
Zusammenhang anfallenden Forschungsergebnisse in Vorträgen und Verö entlichungen
werden häufig Darstellungen von Kristall- und Molekülstrukturen in höchster
Qualität benötigt.
Basierend auf der in einer Seminararbeit erstellten O screen Rendering-Bibliothek
(GLor) zur Integration OpenGL-basierter 3D-Grafiken in 2D-Grafikwerkzeuge und
Anwendungsschnittstellen soll die dafür entwickelte Schnittstelle im Rahmen dieser
Bachelorarbeit erweitert und in vorhandene Visualisierungsprogramme integriert werden.
Dabei ist zunächst ein Verfahren zu entwickeln, welches die Möglichkeiten konventioneller
2D-Grafik und interaktiver 3D-Systeme vereint.
Anschließend ist dieses Verfahren in zwei Programmsystemen konkret umzusetzen:
Zum einen soll die am PGI/JCNS entwickelte GR-Visualisierungbibliothek um
die neuen 3D-Funktionen erweitert werden, zum anderen soll eine Anwendung zur
Darstellung von Molekülstrukturen (Moldyn) refaktoriert und um die Möglichkeit
der Visualisierung von Elektronenspins erweitert werden. Im Zuge dieser Umstellung
sollen die Ausgabemöglichkeiten der Bibliothek zudem um interaktiv nutzbare
3D-Anzeigefenster und alternative Ausgabeformate, wie JavaScript-basierte WebGL-
Skripte oder Szenenbeschreibungen für ein Raytracing-Programm (POV-Ray), ergänzt
werden.

Inhaltsverzeichnis
1. Motivation 1
2. Grundlagen 2
2.1. 2D-Grafiksysteme ............................. 2
2.1.1. Das Graphische Kernsystem und die GR-Bibliothek ...... 2
2.2. 3D-Visualisierungstechniken ....................... 3
2.2.1. Szenen im dreidimensionalen Raum ............... 3
2.2.2. OpenGL .............................. 4
2.2.3. HMTL5/JavaScript und WebGL ................. 4
2.2.4. Persistence of Vision Raytracer (POV-Ray) .......... 5
3. Realisierung 7
3.1. Konzept der Bibliothek .......................... 7
3.1.1. Die Bibliothek GR3 in der Grafikinfrastruktur ......... 7
3.1.2. Entwurf der Schnittstelle ..................... 9
3.1.2.1. Allgemeine Funktionen ................. 9
3.1.2.2. Szenenbeschreibungsfunktionen ............ 9
3.1.2.3. Funktionen zum Zeichnen und Export der Szene ... 9
3.2. Statische Ausgabe der Szene ....................... 12
3.2.1. POV-Ray Szenenbeschreibung .................. 12
3.2.2. Rasterisierung in OpenGL .................... 16
3.2.2.1. Der OpenGL-Kontext ................. 16
3.2.2.2. Rendering mit Framebu er Objekten ......... 18
3.2.2.3. Erstellung von Rastergrafiken mit OpenGL ..... 18
3.2.2.4. Erstellung von Grafiken in hohen Auflösungen .... 21
3.2.2.5. Kantenglättung mit Supersampling Antialiasing ... 22
3.2.3. HTML5-Dokument mit einem interaktiven WebGL-Canvas .. 24
3.3. Grafikanzeige zur Laufzeit ........................ 27
3.3.1. Zeichnen von Pixmaps mit der GR-Bibliothek ......... 28
3.3.2. Integration in OpenGL-Anwendungen .............. 29
3.4. Erstellung einer Anbindung für Python ................. 29
4. Ergebnisse 31
4.1. Benutzung der Schnittstelle ....................... 31
4.1.1. Ein einfaches Beispiel: Visualisierung dreier Kugeln ...... 31
4.1.2. Ein komplexes Beispiel: Eine Funktion als 3D-Fläche ..... 33
i

Inhaltsverzeichnis
4.2. Moldyn – Ein Anwendungsbeispiel ................... 35
4.2.1. Erstellung und Verwaltung des Anzeigefensters ......... 37
4.2.2. Aufbau einer Szene aus den Moleküldaten ........... 38
4.2.3. Darstellung der Moleküle zur Laufzeit .............. 41
4.2.4. Export in Ausgabedateien .................... 43
4.2.5. Zusammenfassung der Integration von GR3 in MolDyn .... 44
4.3. Verwendung des Python-Wrappers ................... 45
5. Ausblick 46
Literaturverzeichnis 48
Anhang 51
A. Funktionsreferenz 53
A.1. Allgemeine Funktionen .......................... 53
A.2. Szenenbeschreibungsfunktionen ..................... 54
A.3. Export- und Zeichenfunktionen ..................... 60
B. Codebeispiele 63
B.1. Visualisierung dreier Kugeln ....................... 63
B.2. Eine Funktion als 3D-Fläche ....................... 64
ii

Abbildungsverzeichnis
2.1. Prinzip eines Raytracers ......................... 6
3.1. GR3 in der Grafikinfrastruktur ..................... 8
3.2. Vereinfachte Darstellung der verschiedenen Ausgabemöglichkeiten .. 10
3.3. Die von POV-Ray gerenderte Szene ................... 14
3.4. Erstellung einer Rastergrafik mit GR3 und POV-Ray ......... 15
3.5. Die OpenGL Core Profile Pipeline[17, S. 11][15, S. 7] .......... 17
3.6. Die winkelabhängige Intensität des reflektierten Lichts nach dem Lambert’schen
Kosinusgesetz ......................... 19
3.7. Skizze eines symmetrischen Pyramidenstumpfes mit Unterteilungen
(Schnitt entlang der y-z-Ebene) ..................... 21
3.8. Supersampling Antialiasing ....................... 23
3.9. Eine mit WebGL dargestellte Szene ................... 25
3.10. Das Koordinatensystem des Browsers (schwarz), das aktuelle Koordinatensystem
der Kamera (rot), die Änderung der Mausposition und
die daraus berechnete Rotationsachse (blau) .............. 26
3.11. Zeichenbereich von gr3_drawimage im Anwendungsfenster ...... 27
3.12. GKS-Fenster (X11-Treiber) mit 2D- und 3D-Inhalten ......... 28
4.1. Die erzeugte Grafik ............................ 32
4.2. Die Funktion f(x, y) = sin( 4
9x2 )+ y2
für x, y œ [≠5; 5] ......... 9
4.3. Ein Ge-Sb-Te-Phasenwechselmaterial in Moldyn (ohne GR3) .....
35
36
4.4. Ein Punkt (r,„,◊) in Kugelkoordinaten ................. 41
4.5. Ein Ge-Sb-Te-Phasenwechselmaterial in Moldyn (mit GR3) ...... 43
iii

Listingverzeichnis
iv
3.1. Funktionen zum Setzen der Qualität und Export in eine Datei .... 10
3.2. Funktion zum Auslesen einer Pixmap .................. 10
3.3. Zwei mögliche Signaturen einer Funktion zum Zeichnen in ein beliebiges
Ziel mit beliebigen Optionen ....................... 11
3.4. Funktion zum Zeichnen in ein beliebiges Ziel mit festgelegten Optionen 12
3.5. Eine Szenenbeschreibungsdatei für POV-Ray (Teil 1) ......... 12
3.6. Eine Szenenbeschreibungsdatei für POV-Ray (Teil 2, gekürzt) .... 13
3.7. Ein Beispiel für einen mesh-Block .................... 14
3.8. Verwenden eines bestehenden OpenGL-Kontextes mit CGL, GLX und
WGL .................................... 16
3.9. Ein GLSL 1.2 Vertex-Shader für eine Lambert’sche Oberfläche (di use
Beleuchtung) ............................... 19
3.10. Ein GLSL 1.2 Fragment-Shader ..................... 20
3.11. Vertex Bu er Objekte in C ........................ 24
3.12. Vertex Bu er Objekte in JavaScript ................... 24
3.13. IDL-Beschreibung 6 des canvas-Elements ................ 24
3.14. Funktion zum Zeichnen in ein beliebiges Ziel mit festgelegten Optionen 27
3.15. Funktion zum Zeichnen einer Rastergrafik mit GR ........... 28
3.16. Python-Wrapper für gr3_setquality mit ctypes ........... 30
4.1. Initialisierung und Freigabe von GR3 .................. 31
4.2. Setzen von globalen Eigenschaften .................... 32
4.3. Hinzufügen von Kugeln zur Szene .................... 32
4.4. Exportieren der Szene in eine PNG-Datei ................
4.5. f(x, y),
32
ˆf ˆf
, , eine Funktion zur Normalisierung von Vektoren und
ˆx ˆy
eine Funktion zur Transformation der Intervalle [0; 100] für x und [0;10]
für y auf [-5;5] ............................... 33
4.6. Darstellung einer Funktion als Dreiecksgitter .............. 34
4.7. Exportieren der Szene in ein HTML5-Dokument ............ 35
4.8. Erstellen des Anzeigefensters und Setzen der Callback-Funktionen .. 37
4.9. Hinzufügen der Atome zur Szene .................... 38
4.10. Hinzufügen der Atombindungen zur Szene (Teil 1) ........... 40
4.11. Hinzufügen der Atombindungen zur Szene (Teil 2) ........... 40
4.12. Umrechnen des Koordinatensystems der Kamera ............ 42
4.13. Zeichnen der Szene ............................ 42
4.14. Export der Szene in eine Datei ...................... 44

Listingverzeichnis
4.15. Beispiel 1 in Python ........................... 45
B.1. Darstellung von drei Kugeln mit GR3 .................. 63
B.2. 3D-Plot der Funktion f(x, y) =cos(0.66x) · sin(0.2y) ......... 65
v

1. Motivation
Ein perspektivisch gezeichnetes Bild, eine Animation am Computerbildschirm, ein
Film im 3D-Kino, ein Hologramm: die 3D-Visualisierung hat viele Formen und die
Schnittmenge liegt in den Inhalten, die dargestellt werden können. Dabei ist die
Spannweite der verschiedenen Inhalte – von Mess- oder Simulationsdaten bis zu präzisen
Entwürfen von Maschinenteilen – genau so groß, wie die Möglichkeiten ihrer
Darstellung. Die Visualisierung von dreidimensionalen Inhalten macht diese meist
einfacher verständlich.
An einem normalen Arbeitsplatzrechner kann man heute verschiedene solche Darstellungen
erzeugen: Statische Rastergrafiken auf der einen und aus vielen Einzelbildern
bestehende, dynamische und interaktive Inhalte auf der anderen Seite. Auch
Vektorgrafiken oder genormte Szenenbeschreibungen, die zur Anzeige erst in Rastergrafiken
umgewandelt werden müssen, sind möglich. Um dies zu erreichen gibt es
Programme und Bibliotheken, die verschiedene Ansätze verfolgen um eine bestimmte
Form der Ausgabe zu erzeugen. Die Schnittstellen sind dabei meist sehr komplex
gestaltet, um die Ausgabe den eigenen Wünschen entsprechend genau anpassen zu
können oder die Performance zu erhöhen.
Mit dieser hohen Komplexität können zwar zunehmend realistischere Grafiken in
Echtzeit erstellt werden, doch die Benutzung dieser Systeme setzt eine zeitintensive
Einarbeitung voraus und sie sind üblicherweise auf wenige Ausgabemedien spezialisiert.
Im wissenschaftlichen Umfeld ist es allerdings oft das Ziel, die Daten zu
visualisieren ohne Fotorealismus anzustreben. Deshalb ist eine einfache Schnittstelle
sinnvoller, die verschiedene Möglichkeiten der Ausgabe bietet.
Das Ziel dieser Arbeit ist daher die Entwicklung einer Bibliothek, die mit einer einheitlichen,
einfach gestalteten Schnittstelle die Möglichkeit bietet, dreidimensionale
Inhalte zu visualisieren und die so erzeugten 3D-Grafiken in mehreren Ausgabeformaten
zu exportieren. Sie soll insbesondere in 2D-Grafiksysteme integrierbar sein, so
dass bestehende Anwendungen um statische oder dynamische 3D-Grafiken erweitert
werden können.
1

2. Grundlagen
2.1. 2D-Grafiksysteme
2.1.1. Das Graphische Kernsystem und die GR-Bibliothek
Das Graphische Kernsystem (GKS) ist eine standardisierte Schnittstelle für die Erstellung
von 2D-Vektorgrafiken. Durch die Abstraktion der Ausgabemedien und eine
auf grafische Primitiven eingeschränkte Funktionalität bietet das GKS die Möglichkeit
Zeichenbefehle unabhängig von der späteren Anzeige zu gestalten und dennoch
eine sehr hohe Qualität zu erzielen. Die vom GKS unterstützten grafischen Primitiven
sind[1][3, Abschnitt 2.1]:
• Linienzüge (Polylines)
• Symbole, z. B. Kreise oder Sterne (Polymarker)
• Einfarbig gefüllte oder schra erte Flächen (Fill Area)
• Schrift (Text)
• Farbmatrizen (Cell Array)
Im Gegensatz zu einigen anderen funktionalen ISO-Standards gibt es zum GKS keine
o zielle Referenzimplementierung. Statt dessen gibt es mehrere Implementierungen,
in welchen die Plattformunabhängigkeit über zwei verschiedene Schichten realisiert
wird. Eine obere Schicht ist vollkommen plattformunabhängig und erfüllt die vom
Standard vorgegebene Schnittstelle. Diese gibt über eine zweite, implementierungsabhängige
Schnittstelle die Zeichenbefehle an ein oder mehrere logische Gerätetreiber
weiter. Ein solcher Treiber realisiert die geräteabhängigen Zeichenoperationen für ein
Ausgabemedium, eine sogenannte GKS-Workstation 1 [1].
Solche Gerätetreiber gibt es für sehr verschiedene Arten der Anzeige, wie beispielsweise
für verschiedene Toolkits für grafische Benutzeroberflächen (z. B. Qt4), als Web
Frontend, aber auch für Dateiformate wie Scalable Vector Graphics (SVG) oder das
Portable Document Format (PDF).
Da das GKS nur grundlegende Möglichkeiten der Grafik definiert, wie beispielsweise
Linien oder Texte, wurden darauf aufbauende Systeme entwickelt. Die im ehemaligen
Institut für Festkörperforschung 2 entwickelte GR-Bibliothek ermöglicht auch die
2
1 Dieses Konzept wird auch device-independent device-dependent genannt.
2 Heute: Peter Grünberg Institut (PGI) und Jülich Centre for Neutron Science (JCNS)

2.2. 3D-Visualisierungstechniken
Erstellung komplexer grafischer Elemente und wird in Visualisierungs- und Analyseanwendungen
eingesetzt.
Zu der erweiterten Funktionalität von GR zählen unter anderem:
• Transformationen
• Koordinatenachsen und -gitter
• Fehlerbalken
• Spline-Funktionen
Intern verwendet GR nur die Anweisungen des GKS, daher werden weder Qualität
noch Ausgabearten eingeschränkt. Die GR-Bibliothek ist in der Programmiersprache
C geschrieben, neben der C Schnittstelle kann sie allerdings auch aus anderen
Programmiersprachen wie Python oder Fortran verwendet werden.
2.2. 3D-Visualisierungstechniken
Da im Rahmen dieser Arbeit 3D-Grafiken in 2D-Grafiksysteme wie das GKS integriert
werden sollen, werden in diesem Abschnitt einige Ansätze und Techniken zur 3D-
Visualisierung vorgestellt. So wie im Bereich der 2D-Grafik zwischen Vektorgrafiken
und Rastergrafiken unterschieden werden kann, gibt es im Bereich der 3D-Grafik eine
ähnliche Unterscheidung: Neben dreidimensionalen Vektorgrafiken, in welchen Körper
durch ihre Oberflächen beschrieben werden können, gibt es auch Volumengrafiken, die
gitterförmig im Raum angeordneten Punkten eine Dichte oder ähnliches zuordnen.
Diese Arbeit beschäftigt sich ausschließlich mit der Visualisierung von Vektorgrafiken.
2.2.1. Szenen im dreidimensionalen Raum
Mit den im Folgenden vorgestellten Visualisierungstechniken sollen 3D-Szenen darstellbar
werden. Die Beschreibung dieser Szenen durch den Anwendungsentwickler
wird den Hauptteil seiner Interaktion mit der Bibliothek darstellen. Daher soll geklärt
werden, woraus eine solche Szene besteht. Der in dieser Arbeit verwendete Begri der
„Szene“ beschreibt:
1. eine Konstellation von Objekten im dreidimensionalen Raum,
2. den sichtbaren Ausschnitt des Raums und
3. die Beleuchtung der Objekte.
Dabei haben Objekte verschiedene Eigenschaften, nämlich Position, Orientierung, sowie
die Form, Normalen und Farbe der Oberfläche.
3

Kapitel 2. Grundlagen
2.2.2. OpenGL
Die Open Graphics Library (OpenGL) ist die Spezifikation einer Software-Schnittstelle
zur Grafikhardware[16, Abschnitt 1.2]. Die Grafikhardware wird so weit abstrahiert,
dass eine allgemeine, plattformunabhängige Schnittstelle genutzt werden
kann. Diese Abstraktionsebene ist noch immer hardwarenah genug, um ein e zientes
Erzeugen von 3D-Grafiken in Echtzeit zu erreichen.
OpenGL-Implementierungen sind auf den meisten Arbeitsplatzrechnern vorhanden.
Unter Microsoft Windows ist allerdings die Installation eines (proprietären) Grafikkartentreibers
sehr wichtig, da die ansonsten auf diesem System vorhandene Implementierung
nur der Version 1.1 des OpenGL-Standards entspricht 3 . Falls keine Hardwarebeschleunigung
vorhanden ist, können sogenannte Software-Renderer, rein auf
dem Hauptprozessor arbeitende OpenGL-Implementierungen, genutzt werden. Diese
sind natürlich deutlich weniger leistungsfähig als Implementierungen, welche eine
Grafikkarte verwenden.
Die OpenGL-API bietet zwei verschiedene Ansätze zum „Zeichnen“:
• Die traditionelle Methode ist die Fixed Function Pipeline, in der man die Art
der Projektion, Beleuchtung, etc. durch Variablen kontrolliert. Wie die einzelnen
Schritte, von einer aus Primitiven (Punkt, Linie, Dreieck) bestehenden Eingabe
zur fertigen Grafik, ablaufen, ist dabei fest im Treiber implementiert.
• Bei dem „modernen“ Ansatz wird eine Shader-basierte Pipeline verwendet, d. h.
ein Teil der Schritte (z. B. Transformation oder Einfärben von Pixeln) wird
durch kleine, vom Anwendungsentwickler geschriebene Programme, die sogenannten
Shader-Programme, auf der Grafikhardware ausgeführt.
Die Erzeugung von Grafiken erfolgt in OpenGL nach dem Prinzip der Rasterisierung,
d. h. die Objekte der Szene werden als eine Art Vektorgrafik an die Implementierung
übergeben und dort in eine Rastergrafik umgewandelt. Dabei wird mit einem Tiefenpu
er, einem Speicherbereich in dem für jeden Pixel ein Tiefenwert gespeichert
wird, sicher gestellt, dass im dreidimensionalen Raum näher an der Kamera liegende
Punkte weiter entfernte Punkte verdecken.
Die Spezifikation wird durch ein Non-Profit-Industriekonsortium von Mitgliedern
wie Nvidia, AMD und Intel, der Khronos Group[5], verwaltet und weiter entwickelt.
Die aktuelle Version wird auf der Webseite http://www.opengl.org/registry/ verö
entlicht.
2.2.3. HMTL5/JavaScript und WebGL
Eine noch relativ neue Entwicklung im Bereich der 3D-Visualisierung ist die WebGL-
API. Der ebenfalls von der Khronos Group entwickelte Web-Standard ermöglicht
ein plattformunabhängiges, hardwarebeschleunigtes Rendern von 3D-Grafik im Webbrowser.
Das auf OpenGL ES 2.0 basierende WebGL stellt einen sehr großen Teil
4
3 Version 1.1 wurde 1997 verö entlicht; aktuell sind die Versionen 3.3 und 4.3

2.2. 3D-Visualisierungstechniken
der Funktionalität von OpenGL über eine JavaScript-Schnittstelle zur Verfügung, sodass
auch komplizierte, interaktive 3D-Grafiken in eine Webseite eingebunden werden
können.
Bis zu dieser Erweiterung des Browserumfangs um eine 3D-Grafik-API konnte
über Umwege, beispielsweise mit JOGL über das Java Plug-In, 3D-Grafik erstellt
werden. Die Benutzung von WebGL kann jedoch direkt als Teil der Webseite erfolgen
und benötigt somit keine zusätzlichen Plug-Ins oder externe Bibliotheken[6].
Mit Hilfe des Event-Systems von JavaScript können diese 3D-Grafiken auf Benutzereingaben,
wie Mausbewegungen oder -klicks, reagieren. Einer solchen Webseite
liegt die Beschreibungssprache HTML5 zu Grunde, eine neue Version der Hypertext
Markup Language, die Webanwendungsentwicklern unter anderem zusätzliche
Multimedia-Schnittstellen 4 zur Verfügung stellt. Die Entwicklung und Standardisierung
von HTML5 bei der WHATWG 5 und dem W3C 6 ist zum aktuellen Zeitpunkt
noch nicht abgeschlossen. Der aktuelle Stand der Spezifikation von HTML5 wird unter
http://www.w3.org/TR/html5/ verö entlicht.
Da mehrere Browser 7 bereits HTML5 und WebGL unterstützen, würde ein HTML-
Dokument als Ausgabe die Möglichkeit darstellen, die zu visualisierende Szene als eine
Art „interaktiven Screenshot“ im World Wide Web zu verö entlichen, den Dritte
betrachten können ohne sich ein zusätzliches Programm zu installieren.
2.2.4. Persistence of Vision Raytracer (POV-Ray)
Einen vollkommen anderen Ansatz zur Erzeugung von Rastergrafiken aus 3D-Inhalten
verfolgen sogenannte Raytracingverfahren (siehe Abbildung 2.1). Anstelle der hardwarebeschleunigten
Rasterisierung wird beim Raytracing, zu deutsch (Licht-)„Strahlverfolgung“,
die Farbe jedes Pixels bestimmt, in dem der Weg, dem ein Lichtstrahl
von einer Lichtquelle hätte folgen müssen um dieses Pixel zu erreichen, nachverfolgt
wird. Dabei wird der Weg vom Pixel, beziehungsweise der Kamera, aus so lange verfolgt,
bis der Strahl eine Objektoberfläche schneidet. Von diesem Punkt aus werden,
abhängig von verschiedenen Materialeigenschaften der Oberfläche, ein oder mehrere
Lichtstrahlen unter Berücksichtigung von Reflektion, Refraktion und sonstigen optischen
Phänomenen verfolgt.
Dieser Ansatz ermöglicht einen hohen Grad an Realismus, da Schatten, Lichtbrechung
und Spiegelungen sehr gut dargestellt werden können, während Rasterisierer
wie OpenGL diese E ekte nur aufwändig simulieren können. Da Raytracer meist nicht
hardwarebeschleunigt sind, sondern allein auf dem Hauptprozessor arbeiten und die
rekursive Verfolgung der Lichtstrahlen aufwendig ist, dauert das Erstellen eines einzelnen
Bildes jedoch auch deutlich länger als ein vergleichbares Bild in OpenGL.
Raytracingverfahren eignen sich daher besonders zur Erzeugung von Einzelbildern,
nicht jedoch für Animationen in Echtzeit.
4 z. B. Audio und Video [4, Abschnitt 4.8]
5 Web Hypertext Application Technology Working Group
6 World Wide Web Consortium
7 z. B. Mozilla Firefox und Google Chrome [11]
5

Kapitel 2. Grundlagen
Kamera
Strahlen
Schnittpunkt
Lichtquelle
Objekte
Abbildung 2.1.: Prinzip eines Raytracers
Der Persistence of Vision Raytracer (POV-Ray) erzeugt Grafiken mit Raytracing
und kann damit sehr realitätsnahe Resultate erzielen. Als Eingabe erhält er eine
Szenenbeschreibung in der POV-Ray eigenen Szenenbeschreibungssprache POV-Ray
SDL 8 . Diese Beschreibung enthält die Informationen über
• Objekte in der Szene,
• die Kameraeinstellung,
• vorhandene Lichtquellen und
• eventuell weitere Einstellungen[12, Abschnitt 2.2].
Durch einen Export der aktuellen Szene in die SDL und ein anschließendes Rendering
mit POV-Ray kann die Bibliothek somit hochwertige Grafiken erstellen.
6
8 scene description language

3. Realisierung
3.1. Konzept der Bibliothek
Im Rahmen der Realisierung soll nun zuerst die gewünschte Funktionalität der Bibliothek
genauer beschrieben werden. Die Bibliothek soll eine einheitliche, von den zur
Verfügung stehenden Ausgabeformaten unabhängige Schnittstelle bieten. Die Schnittstelle
soll dabei möglichst klein und einfach benutzbar sein, sodass ein Anwender sie
nach einer kurzen Einarbeitungszeit nutzen kann.
Ein erster Schritt dazu, ist die Einschränkung der darstellbaren Inhalte. Der Fokus
der Bibliothek liegt auf abstrahierten Szenen, nicht auf Fotorealismus. Die Bibliothek
soll sich auf eingefärbte Objekte aus Dreiecksgittern beschränken, Objekte mit
Texturen sollen nicht darstellbar sein. Die Beleuchtung der Szene soll durch eine einzelne
Lichtquelle erfolgen. Schattenwurf, Spiegelungen und Ähnliches müssen nicht
dargestellt werden können.
Die Bibliothek soll plattformunabhängig sein, das bedeutet konkret, dass sie unter
den Betriebssystemen Microsoft Windows, Apple Mac OS X und GNU/Linux-
Distributionen funktionieren und auf weitere Systeme portierbar sein soll. Als Programmiersprache
wird daher C verwendet, allerdings soll die Schnittstelle so geschrieben
sein, dass sie auch aus anderen Sprachen benutzbar ist. Dies soll am Beispiel einer
Python-Anbindung umgesetzt werden.
Die Bibliothek wird im folgenden GR3 genannt, in Anlehnung an die GR-Bibliothek
und die Darstellung von dreidimensionalen Inhalten.
3.1.1. Die Bibliothek GR3 in der Grafikinfrastruktur
Die zur Erstellung der Grafiken verwendeten Programme und Bibliotheken sollen von
GR3 abstrahiert werden, so dass der Anwendungsentwickler nur eine einzige Schnittstelle
beherrschen muss, um Grafiken zu erstellen. Neben GR3 kann er natürlich auch
andere Bibliotheken, wie GUI-Toolkits, GKS/GR oder OpenGL selbst, nutzen.
Mit OpenGL oder POV-Ray können aus den dreidimensionalen Szenen zweidimensionale
Rastergrafiken erzeugt werden. Diese stellen eine gute Möglichkeit zur Integration
der Bibliothek in 2D-Grafiksysteme dar. Solche Pixmaps können in den meisten
GUI-Toolkits, aber auch im Graphischen Kernsystem angezeigt werden. Wenn der
Anwendungsentwickler mit der Bibliothek arbeitet, ist es sinnvoll das Anzeigen der
Rastergrafik direkt anzubieten, um die Benutzung zu erleichtern. Im Rahmen dieser
Arbeit soll eine derartige Integration für GKS/GR erfolgen.
7

Kapitel 3. Realisierung
Dieser Ansatz hat jedoch den Nachteil, dass bei jeder Veränderung der Szene, die
dargestellt werden soll, eine neue Pixmap erstellt und an die Anwendung übergeben
werden muss. Falls OpenGL zum Erstellen der Grafik benutzt wird, muss diese also
aus dem Grafikkartenspeicher in den Hauptspeicher, und dann, falls sie in einem
OpenGL-Fenster dargestellt wird, wieder zurück in den Grafikkartenspeicher kopiert
werden. Dieser Umweg sorgt bei interaktiven Anwendungen für deutliche Verzögerungen.
Statt dessen sollte die Bibliothek, wenn OpenGL zum Darstellen genutzt wird,
die Szene auch in das bestehende OpenGL-Fenster zeichnen können.
GR
POV-Ray
Generator
POV-Ray
GKS
O screen
Rendering
Anwendung
GR3
Direktes
Rendering
JavaScript
Generator
Browser
WebGL
OpenGL & WGL/CGL/GLX
Abbildung 3.1.: GR3 in der Grafikinfrastruktur
...
GLUT Qt
Das Schichtendiagramm (Abb. 3.1) verdeutlicht die Einbettung der Bibliothek in
der Grafikinfrastruktur: Die Anwendung interagiert zur Erstellung von Grafiken primär
mit GR3, andere Schnittstellen können parallel dazu genutzt werden. Unter der
einheitlichen GR3-Schnittstelle liegen Module für die einzelnen Ausgabemethoden:
Funktionen, um mit OpenGL Rastergrafiken zu erzeugen, und Generatoren für POV-
Ray Szenenbeschreibungen sowie HTML5/JavaScript-Dateien, die WebGL nutzen.
Außerdem kann die Szene direkt in einem bestehenden OpenGL-Zeichenbereich gerendert
werden. Die Szenenbeschreibungen können mit POV-Ray in Rastergrafiken
umgewandelt werden und zusammen mit den mit OpenGL erstellten Rastergrafiken
können diese dann an die GR-Bibliothek zur Darstellung mit GKS übergeben werden.
Die HTML-Dateien können in einem Browser betrachtet werden, dieser verwendet zur
Darstellung eine WebGL-Implementierung, welche u. U. wieder auf OpenGL zurückgreift.
8

3.1.2. Entwurf der Schnittstelle
3.1. Konzept der Bibliothek
Die Schnittstelle von GR3 ist stark an die in einer früheren Arbeit vorgestellte GLor-
API 1 [15] angelehnt. Die Funktionen sind dabei in mehrere Kategorien aufgeteilt.
3.1.2.1. Allgemeine Funktionen
Es gibt Funktionen zum Initialisieren und Terminieren der Bibliothek. Außerdem
werden Hilfsfunktionen benötigt, wie beispielsweise eine Funktion um Fehlercodes in
Fehlernamen umzusetzen.
3.1.2.2. Szenenbeschreibungsfunktionen
Die meisten Funktionen der API dienen dazu, die Szene zu beschreiben. Zum einen
gibt es Funktionen zum Erstellen, Zeichnen und Löschen von Dreiecksgittern, zum
anderen können die Eigenschaften der Kamera und der Beleuchtung gesetzt werden.
Um die Benutzung zu erleichtern gibt es außerdem Funktionen zum Zeichnen von
Kugeln, Kegeln und Zylindern.
Diesen Funktionen steht innerhalb der Bibliothek eine Szenenverwaltung gegenüber,
in welcher die Dreiecksgitter, Zeichenaufrufe und globale Eigenschaften gespeichert
sind.
3.1.2.3. Funktionen zum Zeichnen und Export der Szene
Während die GLor-API nur eine einzelne Funktion zum Erzeugen und Auslesen einer
Pixmap hatte, sind in dieser Kategorie nun weitere Funktionen nötig. Speziell müssen
drei verschiedene Aktionen ausgeführt werden können:
• Die Szene in verschiedene Dateiformate exportieren
• Eine Pixmap an die Anwendung zurückgeben
• Die Szene mit GKS/GR oder OpenGL in einem Fenster der Anwendung darstellen
In Abbildung 3.2 sind die verschiedenen Wege der Szene von der Anwendung zu
einer der Ausgabemöglichkeiten vereinfacht dargestellt. Diese drei Aufgaben lassen
sich durch jeweils entsprechende Funktionen erfüllen. Die grundsätzliche Qualität der
erzeugten Grafiken, also beispielsweise ob die Grafik über OpenGL oder POV-Ray
erzeugt werden soll, oder ob Kantenglättung verwendet werden soll, kann in einer
weiteren, davon getrennten Funktion angegeben werden. Der Export in Dateien lässt
sich allgemein durch eine Funktion lösen, welche den Namen der Zieldatei und die gewünschte
Auflösung (für den Fall einer Rastergrafik) erhält. Anhand der verwendeten
Dateiendung kann erkannt werden, welches Exportformat verwendet werden soll; der
Nutzer muss dieses nicht explizit auswählen.
1 OpenGL o screen renderer
9

Kapitel 3. Realisierung
HTML5/JavaScript-
Dokument
JavaScript
Generator
.html
.pov
Anwendung
Szenenverwaltung
POV-Ray
Generator
POV-Ray
OpenGL-
Funktionen
OpenGL
jpeglib libpng Anwendung GR
.jpeg
Szene
Szenenbeschreibung
Export in eine Datei
.png
Rastergrafik
Pixmap
auslesen
Fenster der
Anwendung
Zeichnen in GKS/GR
oder OpenGL
Abbildung 3.2.: Vereinfachte Darstellung der verschiedenen Ausgabemöglichkeiten
Die Signaturen dieser beiden Funktionen können in C wie folgt aussehen:
1 int gr3_setquality(int quality);
2 int gr3_export( const char filename , int width , int height) ;
Listing 3.1: Funktionen zum Setzen der Qualität und Export in eine Datei
Das Auslesen (und dadurch impliziert auch das Erstellen) einer Pixmap benötigt
ebenfalls die gewünschte Auflösung. Anstelle des Dateinamens muss das Ziel für die
Pixmap ein Speicherbereich sein. Eine Zusatzinformation, welche die Arbeit mit unterschiedlichen
Toolkits für den Benutzer deutlich erleichtern kann, ist eine Angabe
ob die Pixmap neben Rot, Grün und Blau auch den Alpha-Wert eines jeden Pixels,
also dessen Deckkraft, enthalten soll. Eine mögliche Funktionssignatur wäre dann die
folgende:
1 int gr3_getimage( int width , int height , int use_alpha , char pixels);
10
Listing 3.2: Funktion zum Auslesen einer Pixmap

3.1. Konzept der Bibliothek
Die letzte Funktion, das Zeichnen in einen bestehenden Zeichenbereich, benötigt eine
weitere Überlegung über zukünftige Anwendungsfälle. Die Bibliothek soll grundsätzlich
um Unterstützung von beliebigen GUI-Toolkits und ähnlichen Bibliotheken erweiterbar
sein und bezüglich der parallelen Verwendbarkeit mehrerer solcher Systeme
soll sie keinen limitierenden Faktor darstellen. Falls eine Anwendung also gleichzeitig
mit z. B. wxWidgets, OpenGL, DirectX und GKS/GR arbeitet, darf das Konzept von
GR3 dem nicht im Wege stehen. In einer solchen Situation muss zum einen entschieden
werden, welche Zeichenfläche das Ziel darstellt und zum anderen ob und welche
Parameter übergeben werden.
Listing 3.3 zeigt zwei Möglichkeiten dies zu realisieren:
1 int drawimage( int drawing_target , . . . ) ;
2
3 //oder :
4 typedef struct {
5 char name ;
6 void value ;
7 } option_t ;
8 const option_t LAST_OPTION = {NULL, NULL};
9
10 int drawimage( int drawing_target , const option_t options) ;
Listing 3.3: Zwei mögliche Signaturen einer Funktion zum Zeichnen in ein beliebiges
Ziel mit beliebigen Optionen
Während die erste Variante für den Benutzer grundsätzlich eine einfache Benutzung
darstellt, haben variadische Funktionen mehrere Nachteile: Die Portierung in andere
Sprachen könnte schwieriger sein als die Portierung einer normalen Funktion, je
nachdem inwieweit sie in der Zielsprache unterstützt werden. Benutzungsfehler, wie
das Verwenden eines falschen Datentyps, das Vergessen einer eventuell nötigen Markierung
des Endes der Argumentenliste oder das Übergeben überzähliger Argumente,
führen nicht zu Kompilierungsfehlern, sondern zu nicht vorhersehbarem Laufzeitverhalten.
Dies reicht von einem sofortigem Abbruch des Programms auf Grund eines
Speicherzugri sfehlers bis zu scheinbar korrektem Verhalten. Außerdem ist die
Schnittstelle einer variadischen Funktion nicht klar durch den Code selbst definiert,
sodass der Anwendungsentwickler deutlich stärker auf die Dokumentation angewiesen
ist: Die Schnittstelle ist weniger intuitiv.
Der zweite Ansatz verwendet eine Datenstruktur, um ein Name-Wert-Paar für jede
Option in einer null-terminierten Liste anzugeben. Dadurch ist die Schnittstelle zwar
klar definiert, jedoch leidet die Benutzbarkeit und Fehler in der Benutzung führen
eventuell zu ähnlich unvorhersehbaren Problemen wie die Verwendung einer variadischen
Funktion.
Ein dritter Ansatz wäre die Erweiterung der Schnittstelle mit einer Funktion pro
Zeichenbereich. In der Verwendung wäre diese Variante klar vorteilhaft, da für jede
Drittbibliothek genau die benötigten Optionen definiert sind, jedoch wird dadurch
ein großer Nachteil der beiden vorangegangenen Ansätze klar: Grundsätzlich ist die
Funktion nur dafür da, die Szene in einem beliebigen Zeichenbereich darzustellen.
11

Kapitel 3. Realisierung
Die Initialisierung dieses Zeichenbereichs oder eine Kopplung zwischen diesem und
GR3 sind eigentlich nicht Teil dieser Aufgabe. Übernimmt man diese Aufgaben durch
sehr weitgehende Funktionsparameter wird das (auf Funktionen erweiterte) Prinzip
der einen Verantwortlichkeit 2 verletzt. Übernimmt man sie durch eine Erweiterung
der Schnittstelle, wird die Wiederverwendbarkeit des Codes eingeschränkt und die
Schnittstelle wird eventuell unnötig groß. Der eigentliche Ort dafür ist eine separate
Initialisierungsmethode, beziehungsweise es sollte möglichst vermieden werden, dass
eine solche Kopplung zwischen GR3 und dem Zeichenbereich überhaupt notwendig
wird.
Daher wurde dies in GR3 so realisiert, dass die Auflösung der Szene (für den Fall,
dass sie in eine Rastergrafik umgewandelt werden muss) und das Zielrechteck im
Zeichenbereich an die Funktion übergeben werden. Außerdem erhält sie noch eine
Ganzzahl anhand der die Art des Zeichenbereichs festgelegt werden kann. Weitere
Parameter, wie beispielsweise ein Zeiger auf einen speziellen Zeichenbereich, könnten
über die Initialisierungsfunktion oder Umgebungsvariablen übergeben werden. Dies
ist jedoch im Rahmen dieser Arbeit nicht nötig gewesen, da für das Zeichnen, sowohl
in ein OpenGL-Fenster als auch in ein GKS-Fenster, eine bessere Realisierung der
Auswahl möglich war: GR3 rendert die Szene im aktuellen OpenGL-Kontext, beziehungsweise
in der aktuellen GKS-Workstation.
1 #define GR3_DRAWABLE_OPENGL 1
2 #define GR3_DRAWABLE_GKS 2
3 int gr3_drawimage( float xmin , float xmax , float ymin , float ymax ,
4 int width , int height , int drawable_type) ;
Listing 3.4: Funktion zum Zeichnen in ein beliebiges Ziel mit festgelegten Optionen
3.2. Statische Ausgabe der Szene
3.2.1. POV-Ray Szenenbeschreibung
Die Ausgabe als POV-Ray Szenenbeschreibung entspricht von den im Folgenden vorgestellten
Möglichkeiten am deutlichsten dem Konzept der Szene, welches die Bibliothek
verwendet. Eine Szenenbeschreibungsdatei besteht dabei aus zwei Abschnitten:
Aus globalen Eigenschaften und Objekten in der Szene. Das folgende Beispiel zeigt
eine einfache POV-Ray Szenenbeschreibung und die daraus erstellte Grafik:
1 camera {
2 up
3 right
4 location
5 look_at
6 sky
7 angle 45.000000
8 }
2 Das single responsibility principle besagt, dass eine Komponente eines Softwaresystems nur genau
eine Verantwortlichkeit haben sollte[9, Abschnitt 3.1].
12

9 light_source {
3.2. Statische Ausgabe der Szene
10 color rgb
11 }
12 background {
13 color rgb
14 }
Listing 3.5: Eine Szenenbeschreibungsdatei für POV-Ray (Teil 1)
Der erste Abschnitt besteht in diesem Beispiel wiederum aus drei kleineren Blöcken.
In den Zeilen 1 bis 8 werden in einem camera-Block die Eigenschaften der metaphorischen
„Kamera“ beschrieben:
• Die Ausrichtung des Koordinatenverhältnisses (up- und right-Vektor)
• Das Seitenverhältnis der erzeugten Rastergrafik (aspect = ||right||
||up|| )
• Position der Kamera (location)
• Fokuspunkt (look_at)
• Ein Richtungsvektor, der im Koordinatensystem nach oben zeigt (oft up-Vektor
genannt, hier ist es jedoch sky-Vektor)
• Der vertikale Sichtfeldwinkel (angle)
Anschließend folgt die Beschreibung einer Lichtquelle. In diesem Beispiel handelt es
sich um eine einfache, punktförmige, di use Lichtquelle, die weißes Licht aussendet.
Dies entspricht der Art Beleuchtung, die GR3 realisieren können soll. Als letzte globale
Eigenschaft wurde ein weißer Hintergrund gesetzt.
Danach folgen die Objekte der Szene. In diesem Beispiel sind es der Einfachheit halber
Kugeln und Zylinder, es können jedoch beliebige Dreiecksgitter angegeben werden
und – dies ist eine Besonderheit von POV-Ray – andere, mathematisch beschreibbare
Objekte, wie beispielsweise Isoflächen[12, Abschnitt 2.4.4] oder Ausschnitte der
Julia-Menge[12, Abschnitt 2.4.1.6].
15 sphere {
16 , 0.300000
17 texture {
18 pigment { color rgb }
19 }
20 }
21 [. . . ]
39 cylinder {
40 ,
41 , 0.050000
42 texture {
43 pigment { color rgb }
44 }
45 }
Listing 3.6: Eine Szenenbeschreibungsdatei für POV-Ray (Teil 2, gekürzt)
13

Kapitel 3. Realisierung
Abbildung 3.3.: Die von POV-Ray gerenderte Szene
Die globalen Eigenschaften ergeben sich direkt aus den Eigenschaften, welche GR3
benötigt und die über Funktionen gesetzt werden müssen. Um den zweiten Teil zu erzeugen
kann die Liste der zu zeichnenden Objekte durchlaufen werden. Anhand einer
zusätzlichen Eigenschaft kann für jedes Dreiecksgitter gespeichert werden, ob es sich
um normale, vom Anwendungsentwickler erstellte Dreiecksgitter handelt, oder um die
drei von der Bibliothek zusätzlich unterstützten Körper: Kugel, Kegel und Zylinder.
Falls es sich um einen von diesen Körpern handelt, wird in der POV-Ray Szenenbeschreibung
kein Dreiecksgitter gespeichert, sondern der entsprechende Körper, sodass
diese glatten Körper ohne Dreiecks-„Facetten“ erscheinen.
Um anstatt eines vordefinierten Körpers ein Dreiecksgitter zu erzeugen, kann in
der POV-Ray Szenenbeschreibungssprache ein mesh-Block verwendet werden, der
eine Liste von Dreiecken enthält. Dreiecke, deren Beleuchtung anhand eines Normalenvektors
für jeden der drei Ortsvektoren berechnet wird, werden mit einem
smooth_triangle-Block realisiert.
1 mesh {
2 #local tex = texture { pigment { color rgb } }
3 smooth_triangle {
4 , ,
5 , ,
6 ,
7 texture { tex }
8 }
9 [. . . ]
10 }
Listing 3.7: Ein Beispiel für einen mesh-Block
In diesem Beispiel ist außerdem die Verwendung von Variablen gezeigt: Für jedes
Dreieck muss eine Farbe angegeben werden. Diese muss als Texturobjekt definiert
sein, daher wird in der zweiten Zeile eine lokale Variable tex als texture-Block definiert
und in Zeile 7 im smooth_triangle-Block verwendet.
14

3.2. Statische Ausgabe der Szene
Um die Position und Orientierung des Körpers in die POV-Ray Szene einzubeziehen,
wird eine 4 ◊ 4-Transformationsmatrix M definiert, deren linke obere 3 ◊ 3-
Untermatrix eine Basistransformation in ein Orthonormalsystem entsprechend der
gewünschten Ausrichtung erwirkt. Die Orts- und Normalenvektoren der Eckpunkte
im Körper werden um eine vierte Dimension w erweitert, wobei allen Ortsvektoren
w =1und allen Normalenvektoren w =0zugeordnet wird. Durch die vierte Spalte
der Matrix können die Ortsvektoren zusätzlich noch verschoben werden, sodass der
Körper die gewünschte Position erhält.
mit:
Q
rightx c
M = c righty c
a rightz up ˜ x
up ˜ y
up ˜ z
forwardx
forwardy
forwardz
positionx positiony positionz R
d
b
0 0 0 1
position ·
= gewünschte Position
forward ·
= gewünschte Ausrichtung (nach vorne)
up ·
= gewünschte Ausrichtung (nach oben)
left = forward ◊ up
up ˜ = left ◊ forward
right = ≠left
Wie in Abbildung 3.2 dargestellt, soll neben dem Export der Szenenbeschreibung in
eine Datei auch die Erstellung einer Rastergrafik mit POV-Ray möglich sein. Das
folgende Diagramm zeigt dafür den Weg der Daten:
Anwendung
Szene
Szenenverwaltung
libpng
Szene
POV-Ray
Generator
szene.png
szene.pov
Pixmap
Rastergrafikexport
Pixmap
POV-Ray
GR
jpeglib
libpng
Anwendung
Abbildung 3.4.: Erstellung einer Rastergrafik mit GR3 und POV-Ray
15

Kapitel 3. Realisierung
Die Ausgabe des Generators wird dazu in eine temporäre Datei geschrieben, von
POV-Ray verarbeitet und das Ergebnis wird mit Hilfe der libpng eingelesen. Die so
erhaltene Pixmap kann anschließend von einer der verschiedenen Exportfunktionen
weiterverarbeitet werden.
3.2.2. Rasterisierung in OpenGL
3.2.2.1. Der OpenGL-Kontext
Um OpenGL-Funktionen zu verwenden, muss ein OpenGL-Kontext aktiv sein. Dieser
enthält unter anderem Informationen darüber, welche OpenGL-Version verwendet
wird und wo der Framebu er liegt. Jedoch ist nicht festgelegt, wie dieser aufgebaut
ist. Die Spezifikation lässt dies o en, da die Erstellung dieses Kontextes nicht Teil
von OpenGL selbst ist, sondern durch andere Bibliotheken, die eine Schicht zwischen
OpenGL und dem Betriebssystem bilden, erfolgt[16, S. 7]. Unter Apple Mac OS X
stellt Core OpenGL (CGL) diese Schicht dar; unter Linux, beziehungsweise immer
wenn das X Window System verwendet wird, sind es die OpenGL Extensions to
the X Window System (GLX) und unter Microsoft Windows sind es die Windows
Extensions to OpenGL (WGL).
Für die Bibliothek gibt es bezüglich des OpenGL-Kontextes zwei mögliche Fälle:
Entweder existiert bereits ein Kontext, oder er muss erst erstellt werden. Falls bereits
ein Kontext existiert, soll die Bibliothek diesen verwenden. Dazu gibt es in jeder
der drei APIs eine passende Funktion, die den Kontext zurückliefert. In CGL muss
zusätzlich der Referenzzähler des Kontextes erhöht werden, um zu registrieren, dass
die Bibliothek ihn ebenfalls nutzt und eine Referenz dazu hält.
1 // CGL:
2 CGLContextObj ctx = CGLGetCurrentContext () ;
3 if (ctx != NULL) {
4 // increase reference count for ctx
5 CGLRetainContext( ctx ) ;
6 }
7
10
8 // GLX:
9 GLXContext context = glXGetCurrentContext () ;
11 // WGL:
12 HGLRC g l r c = w g l G e t C u r r e n t C o n t e x t ( ) ;
Listing 3.8: Verwenden eines bestehenden OpenGL-Kontextes mit CGL, GLX und
WGL
Liefern diese Methoden NULL, gibt es keinen aktuellen Kontext und die Bibliothek ist
selber dafür verantworlich einen solchen zu erstellen. In diesem Fall wird auf die Funktionen
zur Erstellung eines O screen Rendering Kontext aus GLor zurückgegri en.
Diese werden in [15, Abschnitt 3.1.1] erläutert.
16

3.2. Statische Ausgabe der Szene
Pixel data Vertex data
Pixel operations
Rasterization
Fragment shader
Raster operations
Framebu↵er
Vertex shader
Primitive assembly
Geometry shader
Abbildung 3.5.: Die OpenGL Core Profile Pipeline[17, S. 11][15, S. 7]
17

Kapitel 3. Realisierung
3.2.2.2. Rendering mit Framebu er Objekten
Um das Rendering von dem verwendeten OpenGL-Zeichenbereichs unabhängig zu
machen, und hiermit sowohl O screen Rendering als auch Rendering in existierenden
Fenstern zu ermöglichen, arbeiten die im folgenden Abschnitt beschriebenen Methoden
zur Rasterisierung auf Framebu er Objekten. Dies hat im Falle eines bereits
existierenden OpenGL-Kontextes die Vorteile, dass der Standard-Framebu er nicht
manipuliert wird und der verwendete Framebu er so stets eine feste Größe hat. Weiterführende
Informationen zur Erstellung und Verwendung von Framebu er Objekten
sind in [15, Abschnitt 3.1.2] zu finden.
3.2.2.3. Erstellung von Rastergrafiken mit OpenGL
OpenGL ist von Konzepten wie einer Szene unabhängig. Im Gegensatz zu Raytracern
wie POV-Ray stehen bei OpenGL keine „Lichtstrahlen“ im Vordergrund, sondern die
einzelnen geometrischen Primitiven. Vereinfacht gesagt, wird für jedes Dreieck bestimmt,
welche Pixel es im Bild einnimmt, und diese werden, wenn sie nicht bereits
durch näher an der Kamera liegende Primitiven gesetzt wurden, den Eigenschaften
des Dreiecks gemäß eingefärbt. Die Interpretation dieser Dreiecke als Oberflächen
dreidimensionaler Körper ist dem Nutzer von OpenGL überlassen. Dieser wird dennoch
dabei unterstützt, Gruppen von Dreiecken als zusammenhängende Körper zu
betrachten, da es Funktionen gibt, welche auf mehreren Dreiecken arbeiten (z. B.
transformieren oder zeichnen). Diese werden dazu verwendet, die einzelnen Körper
der Szene zu beschreiben und zu zeichnen.
Wie einleitend beschrieben, gibt es zwei Varianten der OpenGL-Rasterisierungs-
Pipeline. Im Folgenden wird beschrieben, wie die Shader-basierte Pipeline (siehe Abbildung
3.5) genutzt wurde, um eine Rastergrafik zu erzeugen. Die realisierte Funktionalität
ist mit der Fixed-Function-Pipeline ebenfalls umsetzbar und wurde aus
Gründen der Abwärtskompatibilität auch als Teil von GR3 implementiert.
Die mit den Funktionen der Szenenverwaltung erstellten Dreiecksgitter werden in
OpenGL als Vertex Bu er Objekte behandelt. Dies sind Bereiche des Grafikkartenspeichers,
in welche die Daten der einzelnen Vertices geschrieben werden. Für jeden
Vertex müssen dessen Position, Oberflächennormale und Farbe gespeichert werden.
Sie werden als float gespeichert, sodass ein Vertex insgesamt 36 Byte Speicher benötigt.
Die Vertices eines solchen Vertex Bu er Objektes werden durch einen Aufruf der
Funktion glDrawArrays zur Eingabe der Pipeline. Dort werden sie (unter anderem)
durch den Vertex-Shader bearbeitet, und die einzelnen Pixel können dann im
Fragment-Shader eingefärbt werden.
Bei der Berechnung der Farbe eines jeden Pixels wird davon ausgegangen, dass die
Oberfläche ideal di us ist, das heißt, dass sie das einfallende Licht in alle Richtungen
gleichmäßig streut. Für solche Oberflächen gilt das Lambert’sche Gesetz, welches die
Intensität des reflektierten Lichts abhängig vom Winkel zwischen den einfallenden
Lichtstrahlen und der Oberflächennormalen beschreibt (s. Abb. 3.6). Für diesen Win-
18

3.2. Statische Ausgabe der Szene
kel ◊ ist die winkelabhängige Intensität I(◊) proportional zu cos(◊) [17, S. 243][21].
I(✓) ·~r
Imax · ~n
✓
Lambert’sche Fläche
Abbildung 3.6.: Die winkelabhängige Intensität des reflektierten Lichts nach dem
Lambert’schen Kosinusgesetz
Für den normalisierten Richtungsvektor zur Lichtquelle ˛r, die Oberflächennormale ˛n
und einen Farbvektor ˛c (RGB-Werte) ergibt sich dann die Formel:
˛cpixel = ˛csurface · I(◊)
= ˛csurface · cos(◊)
= ˛csurface · (˛r · ˛n)
˛˜cpixel = abs(˛cpixel)
Anhand von ˛˜cpixel kann somit die Pixelfarbe ohne Berücksichtigung von Vor- und
Rückseite gesetzt werden. Außerdem müssen noch Skalierungen und andere Transformationen
durchgeführt werden: zum einen auf die Position des Vertex, zum anderen
auch auf die Normale, da diese sich im selben Koordinatensystem befinden muss wie
der Vektor ˛r, um obige Rechnung durchzuführen. Im Gegensatz zu der Position sollte
die Normale jedoch nicht skaliert werden; daher wird vorausgesetzt, dass die Transformationsmatrizen
orthonormal sind.
Das folgende Listing zeigt, wie die beschriebenen Rechnungen in der OpenGL Shading
Language realisiert werden können:
1 #version 120
2 uniform mat4 ProjectionMatrix ;
3 uniform mat4 ViewMatrix ;
4 uniform mat4 ModelMatrix ;
19

Kapitel 3. Realisierung
5 uniform vec3 LightDirection ;
6 uniform vec3 Scales ;
7 attribute vec3 in_Vertex ;
8 attribute vec3 in_Normal ;
9 attribute vec3 in_Color ;
10 varying vec4 Color ;
11
12 void main( void) {
13 vec4 Position = ViewMatrix ModelMatrix ( vec4(Scales in_Vertex ,1) ) ;
14 gl_Position=ProjectionMatrix Position ;
15 vec3 Normal = vec3(ViewMatrix ModelMatrix vec4(in_Normal,0)).xyz;
16 Color = vec4(in_Color ,1) ;
17 float diffuse = Normal.z;
18 if (dot(LightDirection ,LightDirection) > 0.001) {
19 diffuse = dot(normalize(LightDirection),Normal);
20 }
21 diffuse = abs(diffuse);
22 Color . rgb = diffuse Color . rgb ;
23 }
Listing 3.9: Ein GLSL 1.2 Vertex-Shader für eine Lambert’sche Oberfläche (di use
Beleuchtung)
Zum Verständnis muss gesagt werden, dass das Produkt zweier Vektoren in der GLSL
standardmäßig das elementweise Produkt ist. Das Skalarprodukt ist in der (überladenen)
Funktion dot(v,u) realisiert. Als uniform deklarierte Variablen sind zur
Laufzeit des Shader-Programms Konstanten, attribute Variablen sind per-Vertex
Eingaben und varying Variablen sind per-Vertex Ausgaben des Vertex-Shaders (und
per-Fragment Eingaben des Fragment-Shaders) 3 . Durch die zusätzliche Abfrage ob
˛r ·˛r = ||˛r|| 2 ∫ 0 ist, wird sichergestellt, dass die Richtung zur Lichtquelle nicht auf
den Nullvektor gesetzt wurde. Ist dies jedoch der Fall, dann wird stattdessen der
Absolutbetrag der z-Komponente des Normalenvektors als Intensität verwendet. Dies
entspricht einer Lichtquelle hinter der Kamera.
Der zugehörige Fragment-Shader muss die varying Variable Color nur noch für den
jeweiligen Pixel, beziehungsweise das jeweilige Fragment, setzen. Dabei wird implizit
bilinear interpoliert, damit die per-Vertex berechneten Farben gleichmäßig ineinander
übergehen.
1 #version 120
2 varying vec4 Color ;
3 void main( void) {
4 gl_FragColor=Color ;
5 }
Listing 3.10: Ein GLSL 1.2 Fragment-Shader
3 Ab GLSL 1.3 wurden attribute und varying durch die besser verständlichen in und out ersetzt.
Aus Gründen der Kompatibilität wurde allerdings die GLSL Version 1.2 verwendet, denn diese
ist begleitend zu OpenGL 2.1 spezifiziert worden.
20

3.2.2.4. Erstellung von Grafiken in hohen Auflösungen
3.2. Statische Ausgabe der Szene
Um sehr hochauflösende Grafiken mit OpenGL erstellen zu können, müssen mehrere
limitierende Faktoren betrachtet werden. Zum einen stellt der zur Verfügung stehende
Grafikspeicher eine physikalische Obergrenze für die maximale Auflösung der
erzeugten Grafiken dar, zum anderen gibt es seitens der OpenGL-Implementierung
eine Obergrenze für die Viewport-Dimensionen, also für die Auflösung der Grafik. In
[15, S. 21-23] wurde ein Verfahren vorgestellt, mit dem die Limitierung durch Aufteilen
der Grafik in Teilbilder umgangen werden kann. Dazu wurde im Rahmen der
Bibliothek GLor die OpenGL Viewport-Transformation genutzt. In einigen OpenGL-
Implementierungen sind die maximalen Viewport-Dimensionen u. U. jedoch kleiner
als die gewünschte Auflösung.
Daher wurde ein alternatives Verfahren entwickelt, welche auf demselben Ansatz
der Zerlegung in Teilbilder aufbaut, diese aber nicht mit Hilfe der Viewport-Transformation
realisiert. Statt dessen arbeitet dieses Verfahren mit einer Projektionsmatrix,
welche stets nur einen Teil des eigentlichen Sichtbereichs in die normalisierten Gerätekoordinaten
transformiert.
Üblicherweise wird ein symmetrischer Pyramidenstumpf (s. Abb. 3.7) als Sichtbereich
verwendet 4 , um eine perspektivische Projektion zu erreichen.
y
top
bottom
–
2
–
near far
Abbildung 3.7.: Skizze eines symmetrischen Pyramidenstumpfes mit Unterteilungen
(Schnitt entlang der y-z-Ebene)
Folgendes ist eine Projektionsmatrix für einen solchen Pyramidenstumpf[19]:
Q
c
PMsymm = c
a
f
aspect
0
0
0
f
0
0
0
0
0
far+near
0 0
near≠far
≠1
far·near 2 · near≠far
0
R
d
b
mit f = cotan( –
2 )
und aspect = widthimage
heightimage 4 Das viewing frustum, so wie es mit der Funktion gluPerspective erzeugt werden kann.
z
21

Kapitel 3. Realisierung
Dabei handelt es sich um eine vereinfachte Form der Projektionsmatrix für einen
allgemeinen Pyramidenstumpf[18]:
Q
2
c
PMallg = c
a
near
right≠left
0
0
0
near 2top≠bottom 0
right+left
right≠left
top+bottom
top≠bottom
far+near
near≠far
0
0
2 · far·near
near≠far
R
d
b
0 0 ≠1 0
Falls es sich um einen symmetrischen Pyramidenstumpf handelt, lassen sich die Eingangsgrößen
dieser Matrix anhand einer Skizze auf einen Winkel –, welcher das vertikale
Sichtfeld beschreibt, das Seitenverhältnis und die Distanzen zwischen dem Ursprung
und der nahen, beziehungsweise der fernen Clipping-Ebene (near und far)
reduzieren.
Die Zusammenhänge top(= ≠bottom) =near · tan( – ) und (begründet durch das
2
Seitenverhältnis) right(= ≠left) =top · widthimage/heightimage sind in Abbildung 3.7 erkennbar.
Durch Einsetzen und Vereinfachen ergibt sich so wieder die Matrix PMsymm.
Um den für das Gesamtbild gewünschten symmetrischen Pyramidenstumpf in die
für die Teilbilder nötigen Teilstücke zu zerteilen, kann mit Hilfe einer linearen Transformation
zwischen top und bottom in der Vertikalen, so wie zwischen left und right
in der Horizontalen, eine Zerlegung vorgenommen werden, und für jedes Teilstück
können neue Werte für top, bottom, left und right errechnet werden (t, b, l und r).
Das Teilbild (x, y) hat in diesem Fall die (Viewport-)Dimensionen widthpart und
heightpart für die gilt:
widthpart = min(widthframebu er, widthimage ≠ x · widthframebu er)
height part = min(height framebu er, height image ≠ y · height framebu er)
Dann berechnen sich t, b, l und r als:
l = left +(right ≠ left) · x · widthframebu er
widthimage
r = left +(right ≠ left) · x · widthframebu er + widthpart
widthimage
b = bottom +(top ≠ bottom) · y · height framebu er
height image
t = bottom +(top ≠ bottom) · y · height framebu er + height part
height image
Diese Werte werden dann in die Formel für PMallg eingesetzt um die für das Teilbild
(x, y) zu verwendende Projektionsmatrix zu erhalten.
3.2.2.5. Kantenglättung mit Supersampling Antialiasing
Eine Vektorgrafik kann zumindest theoretisch beliebig genau sein, während eine Rastergrafik
nur eine feste Anzahl an Pixeln mit einer bestimmten Auswahl an Farben zur
22

3.2. Statische Ausgabe der Szene
Verfügung hat, um etwas darzustellen. Daher kommt es bei der Rasterisierung speziell
an kontrastreichen Kanten zu unerwünschten E ekten. Die Pixel, durch welche
die Kante verläuft, sind Flächen, doch im Rahmen der Rasterisierung werden sie als
Punkte angenähert, für die ein Farbwert bestimmt wird. Diese sogenannten Samples
liegen entweder auf der einen Seite der Kante, oder der anderen und entsprechend
wird die gesamte Fläche des Pixels eingefärbt. Wie in Abbildung 3.8 zu sehen wird
die eigentlich geradlinige Kante in (a) zu einer Art „Treppe“ in (b).
Um solche Quantisierungse ekte zu verhindern, gibt es verschiedene Kantenglättungsalgorithmen.
Einer davon ist das Supersampling Antialiasing, bei dem für jedes
Pixel nicht ein einzelnes Sample, sondern mehrere verwendet werden. Die für diese
Sample berechneten Farbwerte in (c) werden gemittelt und dadurch wird die Kante
geglättet, was in (d) durch Graustufen erkennbar ist.
Dieser einfach zu realisierende Algorithmus erzielt gute Ergebnisse, jedoch dauert
die Erstellung eines Bildes damit deutlich länger, da zum einen ein vielfach größeres
Bild erzeugt werden muss, weshalb die Rasterisierung auch ein Vielfaches länger
dauert, und zum anderen zur Erstellung der endgültigen Grafik die Mittelung für
jeden Pixel zusätzlich nötig ist. Diese ist im Rahmen dieser Arbeit nur auf der CPU
realisiert worden.
Es gibt Alternativen zu diesem Algorithmus, die kein starres Gitter verwenden,
sondern stattdessen die Samples nach Mustern anordnen, welche unter Umständen
bessere Ergebnisse, beziehungsweise ähnliche Ergebnisse mit weniger Samples erreichen,
oder die nur im Bereich der Kanten eine Glättung anwenden. Die Anwendung
solcher Algorithmen stellt eine mögliche Erweiterung dar.
(a) Vektorgrafik (b) 16x16 Pixel, ohne SSAA
(c) 32x32 Pixel, ohne SSAA (d) 16x16 Pixel, mit 2x-SSAA
Abbildung 3.8.: Bild (d) verwendet Informationen aus Bild (c), daher kann der Farbwert
jedes Pixels aus vier statt nur einem Sample berechnet werden.
Daher werden neben Schwarz und Weiß auch drei Grauwerte zur Darstellung
der Kante verwendet und die Quantisierungse ekte, die in
Bild (b) zu sehen sind, werden abgeschwächt.
23

Kapitel 3. Realisierung
3.2.3. HTML5-Dokument mit einem interaktiven WebGL-Canvas
Die Ausgabe eines HTML5-Dokuments stellt eine Mischung aus statischer und dynamischer
Ausgabe dar, denn es handelt sich um eine Art interaktiven Screenshot.
Mit allen nötigen Informationen ausgestattet, kann das erstellte Dokument später
in einem Browser geö net und betrachtet werden, wobei der Blickwinkel nicht fest
vorgegeben ist, sondern durch den Nutzer verändert werden kann.
WebGL ist in der Benutzung durch den Entwickler sehr ähnlich zum modernen,
Shader-basierten OpenGL. Der größte Unterschied ist die Zielsprache, denn während
die OpenGL-Schnittstelle auf C basiert, wurde WebGL für JavaScript entworfen. Wie
die folgenden Code-Ausschnitte zeigen, sind die e ektiven Unterschiede dank der fast
identischen API jedoch gering:
1 GLuint vbo ;
2 glGenBuffers(1,&vbo) ;
3 glBindBuffer(GL_ARRAY_BUFFER, vbo) ;
Listing 3.11: Vertex Bu er Objekte in C
1 var vbo = gl . createBuffer () ;
2 gl . bindBuffer(gl .ARRAY_BUFFER, vbo) ;
Listing 3.12: Vertex Bu er Objekte in JavaScript
Ein deutlicher Unterschied liegt in der Erstellung des OpenGL, bzw. WebGL Kontext.
Im Rahmen der Erweiterung der Hypertext Markup Language um multimediale
Inhalte wurde unter anderem das canvas-Element 5 in den Standard aufgenommen.
Dieses Element stellt eine Zeichenfläche im HTML5-Dokument dar, die mit JavaScript
für 2D- oder 3D-Grafiken verwendet werden kann. Das Element selbst ist dabei
in [4, Abschnitt 4.8.11] wie folgt definiert:
1 interface HTMLCanvasElement : HTMLElement {
2 attribute unsigned long width ;
3 attribute unsigned long height ;
4
5 DOMString toDataURL( optional DOMString type , any ... args);
6 void toBlob( FileCallback? _callback , optional DOMString type , any ...
args) ;
7
8 object? getContext(DOMString contextId , any ... args);
9 };
Listing 3.13: IDL-Beschreibung 6 des canvas-Elements
Daran ist erkennbar, dass das canvas-Element selber keine Zeichenoperationen anbietet,
sondern nur zwei Methoden zum Auslesen der Bilddaten und die Methode
5 Das Wort canvas ist englisch für „Leinwand“ und wird in der GUI-Programmierung oft für Zei-
chenbereiche verwendet.
6 Interface Description Language
24

3.2. Statische Ausgabe der Szene
getContext. Wenn der Parameter contextId den Wert „webgl“, bzw. „experimentalwebgl“[11]
hat, und der Browser WebGL unterstützt, wird ein WebGL Kontext erstellt.
Dieser Kontext hat Gegenstücke zu den aus OpenGL bekannten Funktionen
und Konstanten als Methoden und Attribute.
Um eine Szene zu exportieren muss daher ein HTML5-Dokument mit einem canvas-
Element und dem zur Darstellung der Szene nötigen JavaScript Code erstellt werden.
Dieser Code muss als erstes den WebGL Kontext erstellen, dann die Shader-
Programme laden, kompilieren und linken, und als letztes die Daten der Szene verarbeiten.
Die Shader-Programme für WebGL sind ebenfalls in GLSL geschrieben, sodass
diese aus der Implementierung für OpenGL (Listings 3.9 und 3.10) übernommen
werden können. Da die GLSL-Variante für OpenGL ES 2.0 verwendet wird, muss allerdings
noch eine Angabe über die Genauigkeit von floating point Zahlen hinzugefügt
werden[20, Abschnitt 4.5].
Um die Szene in JavaScript zu repräsentieren, werden zwei Array-Variablen angelegt.
Eine davon enthält die Daten der Dreiecksgitter, eine andere enthält deren
Positionen, Orientierungen und Farben. Mit der ersten der beiden Variablen werden
beim Laden der Seite Vertex Bu er Objekte erstellt, die andere Variable wird zum
Zeichnen durchlaufen.
Abbildung 3.9.: Eine mit WebGL dargestellte Szene
25

Kapitel 3. Realisierung
Um dem Anwender zu ermöglichen die Szene aus mehr als einer Perspektive zu betrachten,
wird das Event-System von JavaScript verwendet. Die Bewegungen der
Maus werden über das mousemove-Event verfolgt, und die „Kamera“ wird entsprechend
bewegt. Ein Problem, welches sich dabei stellt, ist die Auswahl eines geeigneten
Verfahrens für die Positionsveränderung der Kamera abhängig von der Mausbewegung.
Ein ideales Verfahren ermöglicht dem Benutzer die Auswahl eines Objektes im
dreidimensionalen Raum durch einen Maustastendruck, und bei anschließender Bewegung
des Mauszeigers über der Zeichenfläche sollte dieses Objekt dem Mauszeiger
folgen. Auf diesem Weg sollte die Szene aus allen Richtungen betrachtbar sein, eine
einfache Verschiebung wäre also nicht ausreichend.
Es müssen weitere Eigenschaften festgelegt werden, um eine solche Kamerabewegung
realisieren zu können. Es soll keine tatsächliche Auswahl von Objekten innerhalb
der Szene realisiert werden, damit der Nutzer dasselbe Bewegungsverhalten der
Kamera auch bei einem Klick auf eine freie Fläche feststellt. Weiterhin sollen keine
Verschiebungen des Fokuspunkts der Kamera verwendet werden.
Abbildung 3.10.: Das Koordinatensystem des Browsers (schwarz), das aktuelle Koordinatensystem
der Kamera (rot), die Änderung der Mausposition
und die daraus berechnete Rotationsachse (blau)
Diese Anforderungen können erfüllt werden, indem das jeweils aktuelle Koordinatensystem
um eine von der Richtung der Mausbewegung abhängige Rotationsachse
um einen von der Länge der Mausbewegung abhängigen Winkel rotiert wird. Sei
( x, y) T die Änderung der Mausposition, und ( ˛ right, ˛up, forward) ˛ die Orthonormalbasis
des aktuellen Koordinatensystems, so berechnet sich die Rotationsachse axis ˛
als:
Q
R
26
axis
˛˜
c
= c
a
˛
axis =
up x right x
up y right y
up z right z
˛˜
axis
|| ˛˜
axis||
d
b ·
Q
a x
y
R
b

3.3. Grafikanzeige zur Laufzeit
Diese Rechnung ergibt sich daraus, dass ein zweidimensionales Orthonormalsystem
in der Ebene des Bildschirms die Basis ( ˛ right, ≠ ˛up) hat, denn im Browser zeigt die
y-Achse nach unten und der Ursprung liegt in der oberen linken Ecke. Der Vektor
( x, y) T , der eine Bewegung um die gesuchte Rotationsachse darstellt, sollte
senkrecht auf dieser stehen. Der Vektor (≠ y, x) T in diesem System erfüllt diese
Bedingung. Durch eine Basistransformation erhält man aus diesem den Vektor axis. ˛
Wird nun ein von der Länge des Vektors ( x, y) T abhängiger Winkel – gewählt,
kann das aktuelle Koordinatensystem nach jeder Mausbewegung rotiert werden. Dies
geschieht durch Multiplikation der Basisvektoren mit einer Rotationsmatrix A und
der Verwendung einer aus diesen Basisvektoren berechnetes View-Matrix.
Dabei gilt:
mit:
A =
Q
c
a
x 2 · (1 ≠ c)+c x· y · (1 ≠ c) ≠ z · s x· z · (1 ≠ c)+y · s
x · y · (1 ≠ c)+z · s y 2 · (1 ≠ c)+c y· z · (1 ≠ c) ≠ x · s
x · z · (1 ≠ c) ≠ y · s y· z · (1 ≠ c)+x · s z 2 · (1 ≠ c)+c
(x, y, z) T = ˛
axis, s = sin(–) und c =cos(–)
3.3. Grafikanzeige zur Laufzeit
Wie in Abschnitt 3.1.2 begründet, soll die folgende Funktionssignatur zur Darstellung
der Szene zur Laufzeit verwendet werden:
1 int gr3_drawimage( float xmin , float xmax , float ymin , float ymax ,
2 int width , int height , int drawable_type) ;
Listing 3.14: Funktion zum Zeichnen in ein beliebiges Ziel mit festgelegten Optionen
ymax
ymin
xmin
height
width
xmax
Abbildung 3.11.: Zeichenbereich von gr3_drawimage im Anwendungsfenster
R
d
b
27

Kapitel 3. Realisierung
Anhand des drawable_type-Parameters kann unterschieden werden, mit welchem
Verfahren gezeichnet werden soll. Die anderen Parameter geben die Position der Grafik
im Zeichenbereich des jeweiligen Toolkits o. Ä., und die gewünschte Auflösung
im Fall einer Rastergrafik. Im Rahmen dieser Arbeit wurde dies in zwei Systemen
implementiert: Zum einen in GKS/GR, zum anderen in OpenGL.
3.3.1. Zeichnen von Pixmaps mit der GR-Bibliothek
Die Integration von GR3 in GR kann als Zeichnen einer Pixmap realisiert werden.
Das Graphische Kernsystem unterstützt Rastergrafiken nur in Form einer Farbmatrix,
Cell Array genannt[3]. Die GR-Bibliothek bietet eine darauf aufbauende Funktion für
allgemeine Rastergrafiken:
1 int gr_drawimage( float xmin , float xmax , float ymin , float ymax ,
2 int width , int height , int pixels);
Listing 3.15: Funktion zum Zeichnen einer Rastergrafik mit GR
Unter Verwendung dieser Funktion kann gr3_drawimage als eine Kombination aus
gr3_getimage und gr_drawimage realisiert wurden, d. h. es wird eine Rastergrafik
erstellt und die GR3-Implementierung übernimmt die Darstellung im GKS.
Da GR sicherstellt, dass das GKS initialisiert wird, kann diese Funktion ohne Vorbedingungen
genutzt werden. Falls die Anwendung selbst das GKS oder GR verwendet
und initialisiert, zeichnet GR3 in dieselbe GKS-Workstation, ansonsten wird durch
GR automatische eine neue Workstation geö net.
28
Abbildung 3.12.: GKS-Fenster (X11-Treiber) mit 2D- und 3D-Inhalten

3.3.2. Integration in OpenGL-Anwendungen
3.4. Erstellung einer Anbindung für Python
Bei der Implementierung der Funktion gr3_drawimage für OpenGL, gibt es zwei
Möglichkeiten die Szene darzustellen:
1. Zeichnen einer Rastergrafik als 2D-Inhalt im dreidimensionalen Raum (Billboarding),
oder
2. Zeichnen der Szenen als 3D-Objekte, unter Beibehaltung der Tiefeninformationen.
Der erste Ansatz erlaubt das Einbinden von mit Raytracing erstellten Rastergrafiken
oder Antialiasing, jedoch gehen die Tiefeninformationen verloren. Behält man diese
bei, können weitere 2D- oder 3D-Objekte in die Szene eingefügt werden, nicht nur
davor oder dahinter. Da es beispielsweise gewünscht sein könnte Beschriftungen an
einzelne Objekte in einer Szene anzufügen, ohne das diese „über“ der gesamten Szenen
liegen, fiel die Entscheidung zu der zweiten Variante.
Die Parameter width und height werden in diesem Fall ignoriert – die Auflösung
der erzeugten Grafik richtet sich nach der Größe des Fensters und der anderen Parameter,
entsprechend der Abbildung auf der vorherigen Seite.
Wie in Abschnitt 3.2.2 auf Seite 16 beschrieben, kann der aktuelle OpenGL-Kontext
verwendet werden und anstelle eines Framebu er Objektes kann in den Standard-
Framebu er gerendert werden. Alle sonstigen Funktionen zum Zeichnen mit OpenGL
sind vom Zielbereich unabhängig.
3.4. Erstellung einer Anbindung für Python
Wie in Abschnitt 3.1 angeführt, war die Möglichkeit die Schnittstelle aus einer anderen
Sprache heraus zu verwenden ebenfalls ein Kriterium beim Entwurf des Konzeptes.
Parallel zur Entwicklung der Bibliothek GR3 wurde daher mit gr3.py eine Anbindung
für die Programmiersprache Python entworfen. Dabei handelt es sich um ein Python-
Modul, welches eine GR3 ähnliche Schnittstelle anbietet und diese durch Verwendung
der entsprechenden Bibliotheksfunktionen erfüllt.
Zur Erstellung einer solchen Anbindung gibt es zwei Ansätze:
1. Python-Modul in Python mit ctypes
2. Python-Extension in C
Das Modul ctypes ist Teil der Python Standardbibliothek und ermöglicht die Verwendung
dynamischer Bibliotheken wie GR3 aus Python. Es erlaubt dabei das Laden der
Bibliothek und das Aufrufen von solchen, beispielsweise in C geschriebenen Funktionen.
Außerdem werden dem Entwickler Hilfen für die Verwendung von C-Datentypen
gegeben, um die Argumente entsprechen zu konvertieren 7 , Rückgabewerte zu verarbeiten
und mit Zeigern zu arbeiten.[2, Abschnitt 25.1]
7 Ein Python str ist beispielsweise nicht vollständig zu einem char * aus C kompatibel.
29

Kapitel 3. Realisierung
Eine Python-Extension ist eine in C geschriebene Erweiterung zu Python. Aus Python
wie ein normales Modul benutzbar, kann eine Extension auf den vollen Funktionsumfang
von C zurückgreifen, inklusive der Verwendung von Bibliotheken wie GR3.
Dabei muss die Python API 8 zum Arbeiten mit Python-Datentypen und zur internen
Beschreibung des späteren Moduls genutzt werden.[2, Abschnitt 25.2]
Die einfache Benutzung von ctypes zur Erstellung eines Wrappers, also eines Moduls
welches nur Python-Funktionen und Datentypen auf GR3, beziehungsweise C
abbildet, führte zur Entscheidung den erstgenannten Lösungsansatz zu verfolgen. Als
Beispiel für den Wrapper dient im folgenden Listing die Funktion gr3_setquality.
Die globale Variable _gr3 ist ein Handle der Bibliothek, über welches auf die Funktionen
zugegri en werden kann. Der Ganzzahl-Parameter quality wird automatisch
in einen C int umgewandelt. Die Fehlerbehandlung, die in C über Rückgabewerte
erfolgt, kann in Python mit Exceptions vereinfacht werden.
1 def setquality(quality):
2 global _gr3
3 err = _gr3. gr3_setquality(quality)
4 if err :
5 raise GR3_Exception( err )
Listing 3.16: Python-Wrapper für gr3_setquality mit ctypes
8 Die Python API ist eine Programmierschnittstelle, welche die Arbeit mit Python-Objekten aus C
30
heraus ermöglicht[14].

4. Ergebnisse
Die Bibliothek GR3 ist fertig implementiert und wurde im Rahmen des in Abschnitt
4.2 vorgestellten Projekts bereits verwendet. Dabei hat sich gezeigt, dass der Programmcode
deutlich vereinfacht wird und im Umfang abnimmt (ca. 20% weniger
Code nach dem Umstieg auf GR3), während ohne Zusatzaufwand die Unterstützung
für HTML5-Dokumente als Ausgabe hinzugefügt werden konnte. Die verschiedenen
Ausgabemöglichkeiten wurden abstrahiert und durch die Verwendung der in [15] vorgestellten
Techniken ist die Bibliothek plattformunabhängig.
In diesem Kapitel soll zum einen exemplarisch die Benutzung der GR3-Schnittstelle
demonstriert werden und zum anderen wird die Integration der GR3 Funktionalität
in eine komplexe, interaktive Anwendung vorgestellt. Eine vollständige Funktionsreferenz
ist im Anhang A.3 zu finden. Die zwei im folgenden Abschnitt erläuterten
Beispiele sind in Anhang B.2 vollständig aufgeführt.
4.1. Benutzung der Schnittstelle
4.1.1. Ein einfaches Beispiel: Visualisierung dreier Kugeln
Das im Folgenden vorgestellte Beispielprogramm zeigt die grundlegende Benutzung
von GR3 in C. Als erstes steht das Grundgerüst des Programms: Einbinden der
Header-Datei gr3.h, die Initialisierung und die Freigabe von GR3. Während des Aufrufs
von gr3_init wird ein OpenGL-Kontext und ein Framebu er Objekt erstellt.
Diese werden beim Auruf von gr3_terminate wieder freigegeben.
1 #include
2 #include
3
4 int main( void) {
5 int init_attrs [] = {GR3_IA_END_OF_LIST};
6 int err = gr3_init(init_attrs);
7 if (err) {
8 fprintf(stderr ," Failed to initialize GR3: %s \n" ,
gr3_geterrorstring(err));
9 return 1;
10 }
11 / ... /
28 gr3_terminate () ;
29 return 0;
30 }
Listing 4.1: Initialisierung und Freigabe von GR3
31

Kapitel 4. Ergebnisse
Soll eine Szene beschrieben werden, müssen deren globalen Eigenschaften gesetzt werden.
Die Eigenschaften der Kamera müssen in jedem Programm festgelegt werden.
Wird die Hintergrundfarbe nicht festgelegt, wird Schwarz (0, 0, 0, 1) verwendet. In
diesem Beispiel wird stattdessen ein transparenter Hintergrund verwendet.
11 / Hintergrundfarbe : Rot , Grün , Blau , Alpha /
12 gr3_setbackgroundcolor (0 , 0, 0, 0) ;
13 / Projektionsparameter : vertikales Sichtfeld in Grad , Nah≠ und
14 Fern≠Clipping≠Abstand /
15 gr3_setcameraprojectionparameters(45, 1, 100) ;
16 / Kameraposition , Fokuspunkt , up≠Vektor /
17 gr3_cameralookat (0 ,0 ,3 , 0 ,0 ,0 , 0 ,1 ,0) ;
Listing 4.2: Setzen von globalen Eigenschaften
Nun müssen die Objekte der Szene beschrieben werden. Für Kugeln, Zylinder und
Kegel stehen Hilfsfunktionen zur Verfügung, welche das Zeichnen dieser Körper erleichtern.
Dabei müssen die Anzahl der zu zeichnenden Objekte und mehrere Eigenschaften
(z. B. Positionen, Farben und Radien) als Parameter angegeben werden. Drei
Kugeln lassen sich beispielsweise wie folgt zur Szene hinzufügen:
18 {
19 float positions [] = {≠2,0,0, 0,0,0, 2,0,0};
20 float colors [] = {1,0,0, 0,1,0, 0,0,1};
21 float radii [] = {1,1,1};
22 gr3_drawspheremesh (3 , positions , colors , radii ) ;
23 }
Listing 4.3: Hinzufügen von Kugeln zur Szene
Abschließend kann die Szene angezeigt oder exportiert werden. Der folgende Code exportiert
die Szene mit der Auflößung 3000◊1000 in eine png-Datei unter Verwendung
von OpenGL mit vierfachem Supersampling Antialiasing.
24 gr3_setquality(GR3_QUALITY_OPENGL_4X_SSAA) ;
25 gr3_export(" image . png" ,3000,1000) ;
Listing 4.4: Exportieren der Szene in eine PNG-Datei
Abbildung 4.1 zeigt die Ausgabe dieses Programms:
32
Abbildung 4.1.: Die erzeugte Grafik

4.1. Benutzung der Schnittstelle
4.1.2. Ein komplexes Beispiel: Eine Funktion als 3D-Fläche
Als zweites Beispiel soll eine Funktion f(x, y) :R 2 æ R dargestellt werden. Dazu
muss ein Dreiecksgitter erstellt werden. Für die Funktion:
gilt:
f(x, y) = sin( 4
9 x2 )+ y2
9
Q
Òf (x, y) = a
ˆf
ˆx
ˆf
ˆy
R
Q
b = a
cos( 4
9 x2 ) · 8
9 x
2
9 y
Bildet man daraus eine Fläche im R3 , um diese darzustellen, ist der Normalenvektor
jedes Punkts:
˛n(x, y) = ˛ñ(x, y)
||˛ñ(x, y)|| mit Q R
c
˛ñ(x, y) = c
a
d
b
R
b
≠ ˆf
ˆx
≠ ˆf
ˆy
1
Dies sind alle Informationen, die zur Darstellung benötigt werden. Diese Funktionen
werden entsprechend als C Funktionen implementiert, sodass sie im Rahmen der
Visualisierung verwendet werden können.
5 float f(float x, float y) {
6 return sin(x x/2.25) + y y/9.0;
7 }
8
9 float dfdx( float x, float y) {
10 return cos(x x/2.25) 2 x/2.25;
11 }
12
13 float dfdy( float x, float y) {
14 return 2 y/9.0;
15 }
16
17 float normalize( float vec) {
18 float tmp = 0 ;
19 int i;
20 for (i = 0; i < 3; i++) tmp += vec[i] vec [ i ];
21 tmp = s q r t (tmp) ;
22 for (i = 0; i < 3; i++) vec[i]/=tmp;
23 return vec ;
24 }
25
26 void transform( int x, int y, float new_x , float new_y) {
27 new_x = ( x≠50) /10.0;
28 new_y = ( y≠5) ;
29 }
Listing 4.5: f(x, y), ˆf
ˆx
ˆf
, , eine Funktion zur Normalisierung von Vektoren und eine
ˆy
Funktion zur Transformation der Intervalle [0; 100] für x und [0;10] für y
auf [-5;5]
33

Kapitel 4. Ergebnisse
Ein großer Teil des im vorherigen Beispiel gezeigten Codes kann identisch übernommen
werden. Der entscheidende Unterschied liegt in den Objekten der Szene. Anstelle
der drei Kugeln in Listing 4.3 muss ein allgemeines Dreiecksgitter erstellt und zur
Szene hinzugefügt werden.
Dazu müssen die Ortsvektoren, Normalen und Farbwerte der Oberfläche berechnet
werden. In diesem Beispiel wird ein 100 ◊ 10-Rechtecksgitter verwendet, bei dem
jedes Rechteck aus zwei Dreiecken zusammengesetzt wird (also in der Summe 6000
Eckpunkte). Diese Eckpunkte werden auf das Intervall [-5;5] transformiert, es werden
f(x, y) und ˛n (x, y) berechnet und in zusammenhängende Speicherbereiche geschrieben.
Anschließend werden diese an die Funktion gr3_createmesh übergeben: Ein
neues Dreiecksgitter wird definiert. Anhand der int-Variablen mesh, deren Adresse
ebenfalls an gr3_createmesh übergeben und von der Funktion gesetzt wird, kann dieses
Dreiecksgitter verwendet werden. Nachdem das Dreiecksgitter mit der Funktion
gr3_drawmesh zur Szene hinzugefügt wurde, kann es mit gr3_deletemesh gelöscht
werden. Durch einen Referenzzähler wird dabei sichergestellt, dass die internen Daten
erst dann tatsächlich freigegeben werden, wenn das Gitter nicht mehr Teil der Szene
ist, z. B. nach einen Aufruf von gr3_clear.
38 int mesh ;
39 int i, x, y;
40 int dx [ 6 ] = {0 ,1 ,1 ,0 ,1 ,0};
41 int dy [ 6 ] = {0 ,0 ,1 ,0 ,1 ,1};
42 float mesh_vertices [1000 6 3];
43 float mesh_normals [1000 6 3];
44 float mesh_colors [1000 6 3];
45 float positions [3] = {0,0,0};
46 float directions [3] = {0,0,1};
47 float ups [3] = {0 ,1 ,0};
48 float colors [3] = {1,1,1};
49 float scales [3] = {1,1,1};
50 for (x = 0; x < 100; x++) {
51 for (y = 0; y < 10; y++) {
52 for (i = 0; i < 6; i++) {
53 int ix = x+dx[ i ];
54 int iy = y+dy[ i ];
55 float fx , fy ;
56 transform(ix , iy ,&fx,&fy) ;
57 mesh_vertices [(y 100+x) 6 3+ i 3+0] = fx ;
58 mesh_vertices [(y 100+x) 6 3+ i 3+1] = fy ;
59 mesh_vertices [(y 100+x) 6 3+ i 3+2] = f (fx , fy ) ;
60
61 mesh_normals [( y 100+x) 6 3+ i 3+0] = ≠dfdx(fx , fy ) ;
62 mesh_normals [( y 100+x) 6 3+ i 3+1] = ≠dfdy(fx , fy ) ;
63 mesh_normals [( y 100+x) 6 3+ i 3+2] = 1;
64 normalize(mesh_normals+(y 100+x) 6 3+ i 3+0) ;
65
66 mesh_colors [(y 100+x) 6 3+ i 3+0] = 1;
67 mesh_colors [(y 100+x) 6 3+ i 3+1] = 1;
68 mesh_colors [(y 100+x) 6 3+ i 3+2] = 1;
34

69 }
70 }
71 }
4.2. Moldyn – Ein Anwendungsbeispiel
72 gr3_createmesh(&mesh , 1000 6, mesh_vertices , mesh_normals,
mesh_colors) ;
73 gr3_drawmesh(mesh ,1 , positions , directions , ups , colors , scales ) ;
74 gr3_deletemesh(mesh) ;
Listing 4.6: Darstellung einer Funktion als Dreiecksgitter
Abbildung 4.2.: Die Funktion f(x, y) = sin( 4
9x2 )+ y2
9
für x, y œ [≠5; 5]
Abbildung 4.2 zeigt die Ausgabe als Rastergrafik – exportiert durch den Code aus
Listing 4.4. Ist eine alternative Ausgabe gewünscht, beispielsweise ein HTML5-Dokument,
reicht es die Parameter der Funktion gr3_export anzupassen:
1 gr3_export(" graph . html" ,800,800) ;
Listing 4.7: Exportieren der Szene in ein HTML5-Dokument
4.2. Moldyn – Ein Anwendungsbeispiel
Moldyn ist eine Anwendung zur Visualisierung von Molekülen im balls-and-sticks-
Stil 1 . Seit Ende der 80er Jahre von Josef Heinen im Institut für Festkörperforschung
1 Atome werden als Kugeln (balls) und Atombindungen als Zylinder (sticks) dargestellt (siehe Ab-
bildung 4.3).
35

Kapitel 4. Ergebnisse
entwickelt, unterstützt das Programm mittlerweile mehrere Ein- und Ausgabeformate
und ist ein nützliches Werkzeug für die Wissenschaftler des Instituts.
Abbildung 4.3.: Ein Ge-Sb-Te-Phasenwechselmaterial in Moldyn (ohne GR3)
Das Programm ist in der Programmiersprache C geschrieben und verwendete 2D-
Zeichenbefehle aus X11, um dreidimensionale Grafiken darzustellen. Um Microsoft
Windows zu unterstützen wurde im Jahr 2000 die Verwendung von GDI 2 als Alternative
zu X11 hinzugefügt. Im Jahr 2008 wurde Moldyn im Rahmen einer Bachelorarbeit
von Alexander Peters[13] so umgeschrieben, dass OpenGL statt X11 und GDI
für die dynamische Anzeige zur Laufzeit verwendet wird. Einzelne Bilder können beispielsweise
mit POV-Ray oder GLor erzeugt werden. Um zeitliche Veränderungen
der Moleküle zu zeigen, können aber auch ganze Bilderserien ausgegeben werden, die
dann zu Videos encodiert werden.
Es musste bisher redundanter Visualisierungscode für jedes gewünschte Ausgabeformat
verwendet werden. Dies soll durch den Umstieg auf GR3 nicht mehr nötig sein
und gleichzeitig soll das aus ca. 2700 Zeilen Code bestehende Programm in mehrere
Module aus thematisch zusammengehörenden Funktionen gegliedert werden. Da es
sich um „gewachsene Software“ mit über 20 Jahren Entwicklung handelt, in denen
2 Graphics Device Interface
36

4.2. Moldyn – Ein Anwendungsbeispiel
meist kleine Änderungen gemacht wurden, bestand der erste Schritt darin, den Code
in mehrere Dateien aufzuteilen, die inhaltlich jeweils einen Teilbereich der Funktionalität
abdecken. Dabei wurde der Fokus auf die Trennung der Visualisierung vom
Rest der Anwendung gelegt.
moldyn.c Der größte Teil der Funktionalität ist in dieser Datei geblieben: Interpretation
der Programmparameter, Einlesen und Analyse von Eingabedateien und
Steuerung der Anwendung. (ca. 1050 Zeilen)
moldyn_graphics.c Die im Rahmen der Visualisierung anfallenden Aufgaben sind
in dieser Datei gelöst: Die Erzeugung von Ausgabedateien und die Anzeige zur
Laufzeit in einem Anzeigefenster. (ca. 1000 Zeilen)
moldyn_element_information.c Informationen über die chemischen Elemente, also
deren Namen und anzuzeigende Farben und Atomradien, sind in dieser Datei
in Form von globalen Variablen gespeichert.
moldyn_utilities.c Diese Datei enthält Hilfsfunktionen, wie eine Logging-Funktion
und die Ausgabe der Benutzungshinweise. (ca.70 Zeilen)
4.2.1. Erstellung und Verwaltung des Anzeigefensters
Das Anzeigefenster von Moldyn wird mit GLUT, dem OpenGL Utility Toolkit, erstellt.
GLUT wurde von Mark J. Kilgard entwickelt und bietet eine plattformunabhängige
Schnittstelle zum Fenstersystem des jeweiligen Betriebssystems, um Fenster mit einer
OpenGL-Zeichenfläche zu erzeugen und sowohl Maus- als auch Tastatureingaben zu
behandeln. GLUT steht unter einer proprietären Lizenz, die keine Redistribution gestattet,
jedoch gibt es auch freie Implementierungen der Schnittstelle, wie freeglut 3 ,
sodass eine GLUT-Implementierung auf fast allen Systemen installiert ist, auf denen
auch OpenGL zur Verfügung steht. Die Verwendung von GLUT wurde im Rahmen der
Umstellung auf GR3 beibehalten, da GLUT alle Anforderungen von Moldyn erfüllt.
Die Ereignisbehandlung in GLUT verläuft durch Callback-Funktionen, das heißt
GLUT wird mitgeteilt, welche Funktionen bestimmte Ereignisse behandeln sollen.
Diese werden beim Eintritt des Ereignisses aufgerufen. Der Code-Ausschnitt in Listing
4.8 zeigt die Funktion, welche GLUT initialisiert (Zeile 2 bis 8), ein Anzeigefenster
erstellt (Zeile 9 bis 12) und anschließend die Callback-Funktionen setzt (Zeile 14 bis
20).
1 static void moldyn_init_glut( int argcp , char argv , const char
window_name) {
2 int i = 0;
3 if (argcp == NULL || argv == NULL) {
4 argcp = &i ;
5 argv = NULL;
6 }
3 http://freeglut.sourceforge.net/
37

Kapitel 4. Ergebnisse
7 glutInit(argcp , argv);
8 glutInitDisplayMode(GLUT_RGBA | GLUT_ALPHA | GLUT_DOUBLE |
GLUT_DEPTH) ;
9 glutInitWindowSize(window_width , window_height) ;
10 glutInitWindowPosition(600, 400) ;
11 glutCreateWindow(window_name) ;
12 glutDisplayFunc(moldyn_display_callback) ;
13 glutReshapeFunc( reshape ) ;
14 glutMouseFunc(mouse) ;
15 glutMotionFunc(motion) ;
16 glutKeyboardFunc(keyboard) ;
17 glutSpecialFunc(specialKey) ;
18 }
Listing 4.8: Erstellen des Anzeigefensters und Setzen der Callback-Funktionen
Nach dem Aufrufen dieser Funktion kann GR3 wie in den vorherigen Beispielen initialisiert
werden, dabei wird dann allerdings kein OpenGL-Kontext mehr erzeugt, sondern
der Kontext des Anzeigefensters verwendet. Ist die Initialisierung abgeschlossen,
wird die Funktion glutMainLoop aufgerufen und damit die Kontrolle der Anwendungen
an GLUT übergeben.
4.2.2. Aufbau einer Szene aus den Moleküldaten
Die Moleküle sind als Kugeln und Zylinder dargestellt, das heißt allein die in GR3
vorgefertigten Körper reichen aus, um die Szene zu beschreiben. Die Datenstrukturen
der Atompositionen sind (wie in Fortran üblich) als drei Arrays x, y und z, die jeweils
eine Komponente der Vektoren enthielten, gespeichert gewesen. Die bereits existierende
GLor-Zeichenfunktion hat neue Speicherbereiche angelegt und die Informationen
so umkopiert, dass sie im für GLor passenden Format vorlagen. Stattdessen wurden
nun die anderen Funktionen so angepasst, dass sie mit einem Array von Vektoren
arbeiten. Dadurch können die Atompositionen direkt an GR3 übergeben werden.
Abhängig von einer Option (colors) können entweder die bestehenden Farbinformationen
verwendet werden, oder es muss ein Array erstellt und mit Weiß (1, 1, 1)
gefüllt werden.
Bevor die Atome zur Szene hinzugefügt werden, wird mit der Funktion gr3_clear
die aktuelle Szene gelöscht. Außerdem ist es wichtig, dass die Speicherbereiche, deren
Adressen an die Funktionen von GR3 übergeben werden, weiter von der Anwendung
verwaltet werden und nicht von der Bibliothek. Daher müssen diese, falls sie dynamisch
angelegt wurden, wie in Zeile 15 des folgenden Beispiels freigegeben werden.
1 gr3_clear () ;
2 if (num_atoms > 0) {
3 if (colors) {
4 gr3_drawspheremesh(num_atoms, atom_positions , atom_colors ,
atom_radii) ;
5 } else {
38

4.2. Moldyn – Ein Anwendungsbeispiel
6 float atom_color_replacement = ( float )malloc(num_atoms
sizeof( float) 3) ;
7 if (!atom_color_replacement) {
8 moldyn_error(" Failed to allocate memory for
atom_color_replacement . " );
9 } else {
10 int i;
11 for (i = 0; i < num_atoms 3; i++) {
12 atom_color_replacement [ i ] = 1.0 f ;
13 }
14 gr3_drawspheremesh(num_atoms, atom_positions ,
atom_color_replacement , atom_radii) ;
15 free(atom_color_replacement);
16 }
17 }
18 }
Listing 4.9: Hinzufügen der Atome zur Szene
Ob zwischen zwei Atomen eine Bindung (bond) besteht, wird im Rahmen der Analyse
der Eingangsdaten in einer Adjazenzmatrix gespeichert. Bevor die Bindungen als
Zylinder zur Szene hinzugefügt werden können, müssen deren Daten daher in eine
entsprechende Form gebracht werden.
Für eine Bindung zwischen zwei Atomen an den Positionen ˛ai und ˛aj gilt:
• Position:
• Richtung:
˛
position = ˛ai
˛
direction = ˛aj-˛ai
• Länge: length = || ˛
direction||
• Radius: radius = const.
• Farbe: ˛
color = const.
Bevor diese Informationen zugeordnet werden können, muss allerdings zuerst die Anzahl
der Bindungen bestimmt und genügend Speicher dynamisch angelegt werden:
19 int i, j, k;
20 int num_bonds = 0 ;
21 float bond_positions ;
22 float bond_directions ;
23 float bond_colors ;
24 float bond_radii ;
25 float bond_lengths ;
26
27 for (i = 0; i < num_atoms; i++) {
28 if (atom_numbers[ i ] == 0)
29 continue ;
39

Kapitel 4. Ergebnisse
30 for (j = i + 1; j < num_atoms; j++) {
31 if (atom_numbers[ j ] && atom_adjacency_matrix[ i num_atoms+j
]) {
32 num_bonds++;
33 }
34 }
35 }
36
37 bond_positions = ( float ) malloc( sizeof( float) 3 num_bonds) ;
38 bond_directions = ( float ) malloc( sizeof( float) 3 num_bonds) ;
39 bond_colors = ( float ) malloc( sizeof( float) 3 num_bonds) ;
40 bond_radii = ( float ) malloc( sizeof( float) num_bonds) ;
41 bond_lengths = ( float ) malloc( sizeof( float) num_bonds) ;
Listing 4.10: Hinzufügen der Atombindungen zur Szene (Teil 1)
Anschließend können die angelegten Speicherbereiche mit den Informationen gefüllt,
an die Funktion gr3_drawcylindermesh übergeben und wieder freigegeben werden:
42 for (i = 0, j = 0, k = 0; i < num_atoms; i++) {
43 if (atom_numbers[ i ] == 0) {
44 continue ;
45 }
46 for (j = i + 1; j < num_atoms; j++) {
47 if (atom_numbers[ j ] && atom_adjacency_matrix[ i num_atoms+j
]) {
48 double vx , vy , vz ;
49 bond_positions [3 k+0] = atom_positions [3 i+0];
50 bond_positions [3 k+1] = atom_positions [3 i+1];
51 bond_positions [3 k+2] = atom_positions [3 i+2];
52
53 vx = atom_positions [3 j+0] ≠ atom_positions [3 i+0];
54 vy = atom_positions [3 j+1] ≠ atom_positions [3 i+1];
55 vz = atom_positions [3 j+2] ≠ atom_positions [3 i+2];
56
57 bond_directions [3 k+0] = vx;
58 bond_directions [3 k+1] = vy;
59 bond_directions [3 k+2] = vz ;
60
61 bond_lengths [k] = sqrt (vx vx + vy vy + vz vz) ;
62
63 bond_radii [k] = cyl_rad ;
64
65 bond_colors [3 k+0] = 1;
66 bond_colors [3 k+1] = 1;
67 bond_colors [3 k+2] = 1;
68 k++;
69 }
70 }
71 }
72 gr3_drawcylindermesh(num_bonds, bond_positions , bond_directions ,
bond_colors , bond_radii , bond_lengths) ;
40

73 free(bond_positions);
74 free(bond_directions);
75 free(bond_colors);
76 free(bond_radii);
77 free(bond_lengths);
4.2. Moldyn – Ein Anwendungsbeispiel
Listing 4.11: Hinzufügen der Atombindungen zur Szene (Teil 2)
4.2.3. Darstellung der Moleküle zur Laufzeit
Wann immer das Anzeigefenster neu gezeichnet werden muss, wird eine Callback-
Funktion aufgerufen (siehe Zeile 14 in Listing 4.8). Dies kann zwei Gründe haben:
1. Teilbereiche des Fensters sind durch Überlagerung durch andere Fenster oder
Ähnliches ungültig geworden und die Anwendung wird vom Fenstersystem darüber
informiert. GLUT ruft in diesem Fall automatisch die Callback-Funktion
auf.
2. Durch Nutzereingaben o. Ä. hat sich der darzustellende Inhalt geändert, beispielsweise
soll die Kamera bewegt werden. In diesem Fall muss, aus der für die
Änderung zuständigen Funktion, die Funktion glutPostRedisplay aufgerufen
werden, welche nach Abarbeiten der anstehenden Eingaben ein Neuzeichnen
auslöst.
3 /2⇡
0⇡
✓
r
(r, ,✓)
1⇡
1 /2⇡
Abbildung 4.4.: Ein Punkt (r,„,◊) in Kugelkoordinaten
41

Kapitel 4. Ergebnisse
Innerhalb der mit glutDisplayFunc gesetzten Callback-Funktion kann die Funktion
gr3_drawimage verwendet werden, dazu müssen jedoch die aktuellen Kameraeigenschaften
gesetzt werden.
Moldyn nutzt ein sehr einfaches Rotationsmodell, welches mit Kugelkoordinaten
arbeitet. Dabei liegt die Kamera auf einem Punkt, welcher auf der Oberfläche einer
Kugel positioniert ist. Die Position wird dabei als Radius der Kugel (r), Azimutwinkel
„ 4 und Polarwinkel ◊ 5 ausgedrückt. Diese Angaben müssen in das Kameramodell
von GR3 umgerechnet werden.
1 double x, y, z, fx , fy , fz , ux, uy, uz;
2 double c1 = cos ( torad(≠ rotation));
3 double s1 = sin (torad(≠ rotation));
4 double c2 = cos ( torad(≠ tilt));
5 double s2 = sin (torad(≠ tilt));
6 / Kamera≠Position : /
7 x = ≠c1 xeye + s1 zeye ;
8 y = s1 s2 xeye ≠ c2 yeye + s2 c1 zeye ;
9 z = ≠c2 s1 xeye ≠ s2 yeye ≠ c2 c1 zeye ;
10 / forward≠Vektor : /
11 fx = x + s1 ;
12 fy = y + s2 c1 ;
13 fz = z ≠ c2 c1 ;
14 / up≠Vektor : /
15 ux = 0;
16 uy = c2 ;
17 uz = s2 ;
18
19 gr3_cameralookat(x, y, z , fx , fy , fz , ux, uy, uz) ;
Listing 4.12: Umrechnen des Koordinatensystems der Kamera
Anschließend kann durch einen Aufruf von gr3_drawimage mit dem drawable_type
GR3_DRAWABLE_OPENGL die Grafik ins Anzeigefenster gezeichnet werden.
In Moldyn sollen zusätzlich zu den Molekülen auch weitere Darstellungselemente,
wie beispielsweise Atombeschriftungen, angezeigt werden. Diese können mit GR3 nicht
dargestellt werden, jedoch erlaubt die in Abschnitt 3.3.2 beschriebene Vorgehensweise
eine Integration dieser Elemente in die angezeigte Szene. Durch die im Tiefenpu er
enthaltenen Informationen werden nach dem Aufruf von gr3_drawimage in die Szene
eingefügte Objekte korrekt vor bzw. hinter bereits gezeichneten Körpern angezeigt.
1 gr3_drawimage (0 , window_width ,
2 0, window_height,
3 window_width , window_height ,
4 GR3_DRAWABLE_OPENGL) ;
Listing 4.13: Zeichnen der Szene
Wenn das Zeichnen abgeschlossen ist, kann mit der Funktion glutSwapBuffers das
Anzeigefenster aktualisiert werden. Üblicherweise wird nicht direkt auf der Oberfläche
4 in Moldyn rotation genannt
5 in Moldyn tilt genannt
42

4.2. Moldyn – Ein Anwendungsbeispiel
des Fensters gezeichnet, sondern auf einem zweiten Framebu er. Durch die Funktion
glutSwapBuffers werden Vordergrund- und Hintergrund-Bu er ausgetauscht (swap).
Durch dieses als Double Bu ering bezeichnete Vorgehen wird ein Flackern während
des Neuzeichnens verhindert. Außerdem gibt es plattformabhängige Funktionen, die es
dem Anwendungsentwickler erlauben diesen Austauschprozess mit der Anzeige eines
Frames auf dem Monitor zu synchronisieren (vertical sync), um tearing, ein Darstellungsfehler,
der das angezeigte Bild in eine aktuelle und eine alte Hälfte zerteilt, zu
verhindern.
Abbildung 4.5.: Ein Ge-Sb-Te-Phasenwechselmaterial in Moldyn (mit GR3)
4.2.4. Export in Ausgabedateien
Die Namen der Ausgabedateien von Moldyn haben das Format:
.
43

Kapitel 4. Ergebnisse
In Dateien, welche Moleküle bzw. Atome zu mehr als einem Zeitpunkt enthalten,
sind diese als Blöcke angeordnet. Eine PNG-Grafik für den ersten Block einer Datei
Molecule.xyz hieße dementsprechend Molecule0001.png.
Grundsätzlich gesehen könnte direkt die Funktion gr3_export zur Ausgabe der
Szene in eine Datei verwendet werden. Um die dynamische Erstellung des Dateinamens
zentral zu lösen, wurde jedoch die Funktion moldyn_export_ implementiert.
Sie setzt den gewünschten Dateinamen in einem bestehenden char-Array zusammen
und ruft die Funktion gr3_export auf, welche die Szene entsprechend exportiert.
Dadurch wird das Speichern einer Grafik deutlich vereinfacht.
1 static void moldyn_export_( int type , int width , int height) {
2 int err ;
3 char cp ;
4 char extension ;
5
6 switch (type) {
7 case MOLDYN_EXPORT_TO_JPEG:
8 extension = " jpg" ;
9 break ;
10 case MOLDYN_EXPORT_TO_PNG:
11 extension = " png" ;
12 break ;
13 case MOLDYN_EXPORT_TO_POV:
14 extension = " pov" ;
15 break ;
16 case MOLDYN_EXPORT_TO_HTML:
17 extension = " html" ;
18 break ;
19 }
20
21 sprintf(path , "%s%4d.%s " , name, current_cycle , extension) ;
22 for (cp = path; cp ; cp++) {
23 if ( cp == ’ ’ ) {
24 cp = ’ 0 ’ ;
25 }
26 }
27
28 err = gr3_export(path , width , height);
29 moldyn_log(path) ;
30 if (err) {
31 moldyn_error( gr3_geterrorstring ( err ) ) ;
32 }
33 }
Listing 4.14: Export der Szene in eine Datei
4.2.5. Zusammenfassung der Integration von GR3 in MolDyn
An der Umstellung von einzelnen Visualisierungslösungen zu GR3 hat sich gezeigt,
dass das Konzept der Bibliothek aufgegangen ist. Es konnte eine große Menge re-
44

4.3. Verwendung des Python-Wrappers
dundanten Codes entfernt und so die Wartbarkeit des Programms vereinfacht werden.
Auch die Kombination aus der mit GR3 beschriebenen Szene und zusätzlichen,
mit OpenGL dargestellten Inhalten hat dadurch, dass der Tiefenbu er des Standard-
Framebu ers verwendet wurde, ohne Probleme funktioniert.
Eine Funktionalität, welche aus Sicht des Anwendungsentwicklers erstrebenswert
wäre, ist die Möglichkeit Linien und Texte in GR3 darzustellen, da diese Elemente in
der aktuellen Situation nachträglich in das Anzeigefenster eingefügt werden müssen
und nicht oder nur sehr umständlich in andere Ausgaben eingefügt werden können.
4.3. Verwendung des Python-Wrappers
Das erste Beispiel aus 4.1.1 (vollständig in Listing B.1 auf Seite 63 zu finden) kann
in Python mit wenigen Codeänderungen umgesetzt werden. Die Verwendung des
Python-Moduls erfolgt dabei ähnlich zur Benutzung der Bibliothek in C. Allerdings
gibt es mehrere Unterschiede:
• Das Präfix gr3_, dass in C verwendet wurde, wird durch gr3. ersetzt, da die
Funktionen im Namensraum des Moduls liegen.
• Anstelle von Arrays können Python-Datenstrukturen wie Listen, Tupel und
auch verschachtelte Kombinationen daraus verwendet werden. Dabei greift der
Wrapper auf die e zienten, n-dimensionalen Datenstrukturen des Moduls numpy
(http://numpy.scipy.org/) zurück; diese werden daher auch unterstützt.
• Die Fehlerbehandlung ist über die Exception-Klasse GR3_Exception realisiert.
1 import gr3
2
3 try :
4 gr3 . init ()
5 gr3 . setbackgroundcolor (0 ,0 ,0 ,0)
6 gr3 . setcameraprojectionparameters (6 , 1, 100)
7 gr3 . cameralookat (0 ,0 ,20 , 0 ,0 ,0 , 0 ,1 ,0)
8 positions = [(≠2,0,0), (0,0,0), (2,0,0)]
9 colors = [(1 ,0 ,0) , (0,1,0) , (0,0,1) ]
10 radii = [1 ,1 ,1]
11 gr3 . drawspheremesh(3 , positions , colors , radii )
12 gr3 . setquality (gr3 .GR3_Quality.GR3_QUALITY_OPENGL_4X_SSAA)
13 gr3 . export(" image . png" ,3000,1000)
14 gr3 . terminate ()
15 except gr3 .GR3_Exception as e:
16 print "GR3 error : " , gr3 . geterrorstring (e)
Listing 4.15: Beispiel 1 in Python
45

5. Ausblick
Wie in Abschnitt 4.2.5 bereits angeführt, wäre eine Erweiterung von GR3 um bestimmte
Elemente, wie Punkte, Linien und im dreidimensionalen Raum positionierbaren
Text, sinnvoll. Ein denkbarer Ansatz zur Integration von Texten wäre es, allgemein
2D-Rastergrafiken in eine Szene zu integrieren, welche entweder stets zum
Betrachter (Billboarding) gerichtet oder fest im Raum positioniert und ausgerichtet
sind.
In Abschnitt 2.2 wurde erwähnt, dass es neben den von GR3 visualisierten Vektorgrafiken
in Form von Dreiecksgittern auch Volumengrafiken gibt. Um eine solche
Volumengrafik zu visualisieren, wird oft ein Schwellwert verwendet, um Isoflächen zu
bilden, welche als Gittermodell darstellbar sind. Die Integration eines Algorithmus zur
Erzeugung von Dreiecksgittern aus Voxeldaten in die Bibliothek, wäre ein denkbarer
Schritt, um dies zu vereinfachen. Der marching cubes Algorithmus wäre ein möglicher
Ansatz hierfür.
Eine weitere sinnvolle Erweiterung stellt die Integration anderer Kantenglättungsalgorithmen
dar. Supersampling Antialiasing (SSAA) liefert zwar gute Ergebnisse,
jedoch kostet die Erzeugung eines Bildes unter Verwendung des Algorithmus deutlich
mehr Zeit. Zum einen könnte der momentan auf der CPU erledigte Teil des
Algorithmus auf die Grafikkarte verschoben werden, zum anderen gibt es mit Multisampling
Antialiasing (MSAA) einen sehr ähnlichen Algorithmus, welcher direkt bei
der Erstellung der Grafik auf der Grafikkarte angewendet werden könnte (mit einem
Multisampling Framebu er Objekt).
Da eine leicht zu erlernende Schnittstelle ein wichtiges Ziel dieser Arbeit war, bleibt
es außerdem abzuwarten, wie die Rückmeldungen zukünftiger Anwender von GR3
ausfallen werden.
46

Literaturverzeichnis
[1] Bechlars, Jörg ; Buhtz, Rainer: GKS in der Praxis. Springer-Verlag, 1986. –
ISBN 978–3–540–16139–2
[2] Ernesti, Jonannes ; Kaiser, Peter:Python 3 – Das umfassende Handbuch. 2.
aktualisierte Auflage. Galileo Computing, 2009. – ISBN 978–3–8362–1412–4
[3] Heimbach, Ingo: Entwicklung eines logischen GKS Gerätetreibers für die
wxWidgets-Klassenbibliothek. Dezember2011
[4] Hickson, Ian: HTML5. http://www.w3.org/TR/2012/WD-html5-20120329/,
Abruf: 13. Juni 2012
[5] Khronos Group: About The Khronos Group. http://www.khronos.org/
about/, Abruf: 14. Juni 2012
[6] Khronos Group: WebGL – OpenGL ES 2.0 for the Web. http://www.
khronos.org/webgl/, Abruf: 13. Juni 2012
[7] Khronos Group: WebGL Specification. http://www.khronos.org/registry/
webgl/specs/latest/, Abruf: 13. Juni 2012
[8] Kilgard, Mark J.: The OpenGL Utility Toolkit (GLUT) Programming Interface,
API Version 3. http://www.opengl.org/resources/libraries/glut/glut-
3.spec.ps, Abruf: 10. Juli 2012
[9] Lahres, Bernhard ; Rayman, Gregor: Objektorientierte Programmierung. 2.,
aktualisierte und erweiterte Auflage. Galileo Computing, 2009. – ISBN 978–3–
8362–1401–8
[10] Microsoft Corporation: wglGetCurrentContext function (Windows). http:
//msdn.microsoft.com/en-us/library/dd374383, Abruf: 11. Juni 2012
[11] Mozilla Developer Network: WebGL - MDN. https://developer.
mozilla.org/en/WebGL, Abruf: 13. Juni 2012
[12] Persistence of Vision Raytracer Pty. Ltd.: POV-Ray: Documentation.
http://www.povray.org/documentation/, Abruf: 11. Juni 2012
[13] Peters, Alexander: Visualisierung von Daten aus Soft Matter Simulationen.
Oktober 2008
48

Literaturverzeichnis
[14] Python Software Foundation: Python/C API Reference Manual – Introduction.
http://docs.python.org/c-api/intro.html, Abruf: 19. Juli 2012
[15] Rhiem, Florian: Integration OpenGL-basierter Visualisierungs-Techniken in 2D-
Grafiksystemen. Dezember2011
[16] Segal, Mark;Akeley, Kurt: The OpenGL ® Graphics System: A Specification,
Version 4.2 (Core Profile) - April 27, 2012. http://www.opengl.org/
registry/doc/glspec42.core.20120427.pdf, Abruf: 14. Juni 2012
[17] Shreiner, Dave: OpenGL Programming Guide, Seventh Edition. Addison-
Wesley, 2010. – ISBN 978–0–321–55262–8
[18] Silicon Graphics, Inc.: OpenGL 2.1 Reference Pages – glFrustum. http://
www.opengl.org/sdk/docs/man/xhtml/glFrustum.xml, Abruf: 11. Juni 2012
[19] Silicon Graphics, Inc.: OpenGL 2.1 Reference Pages – gluPerspective. http:
//www.opengl.org/sdk/docs/man/xhtml/gluPerspective.xml, Abruf: 11. Juni
2012
[20] Simpson, Robert J. ; Kessenich, John: The OpenGL ® ES Shading Language
- May 12, 2009. http://www.khronos.org/registry/gles/specs/2.0/GLSL_
ES_Specification_1.0.17.pdf, Abruf: 6. Juli 2012
[21] Wikipedia: Lambert’s cosine law. http://en.wikipedia.org/wiki/Lambert%
27s_cosine_law, Abruf: 27. Juni 2012
49

Anhang

A. Funktionsreferenz
Der Rückgabewert von Funktionen, welche einen int zurückgeben, ist ein Fehlercode.
Mit der Funktion gr3_geterrorstring kann dieser Fehlercode in einen String umgesetzt
werden. Ist kein Fehler aufgetreten wird 0 (GR3_ERROR_NONE) zurückgegeben.
A.1. Allgemeine Funktionen
gr3_init
Initialisiert die Bibliothek.
1 #define GR3_IA_END_OF_LIST 0
2 #define GR3_IA_FRAMEBUFFER_WIDTH 1
3 #define GR3_IA_FRAMEBUFFER_HEIGHT 2
4 int gr3_init(
5 int attrib_list
6 );
Parameter
attrib_list
Ein Zeiger auf ein int-Array. Dieser Array muss aus Paaren aus Attributname
und -wert bestehen und mit GR3_IA_END_OF_LIST abgeschlossen werden. Mit
den Attributen GR3_IA_FRAMEBUFFER_WIDTH und GR3_IA_FRAMEBUFFER_HEIGHT
können Breite und Höhe des verwendeten Framebu er Objektes gesetzt werden.
Standardmäßig wird für beides 512 verwendet.
gr3_terminate
Gibt die Bibliothek und von ihr verwendete Ressourcen frei.
1 void gr3_terminate () ;
gr3_getrenderpathstring
Gibt einen Zeiger auf eine Zeichenkette zurück, welche Informationen über den Rendervorgang
mit OpenGL liefert. Die Zeichenkette wird von der Bibliothek freigegeben.
1 const char gr3_getrenderpathstring () ;
53

Anhang A. Funktionsreferenz
gr3_geterrorstring
Gibt einen Zeiger auf eine Zeichenkette zurück, welche den Namen des angegebenen
Fehlercodes enthält. Die Zeichenkette wird von der Bibliothek freigegeben.
1 #define GR3_ERROR_NONE 0
2 #define GR3_ERROR_INVALID_VALUE 1
3 #define GR3_ERROR_INVALID_ATTRIBUTE 2
4 #define GR3_ERROR_INIT_FAILED 3
5 #define GR3_ERROR_OPENGL_ERR 4
6 #define GR3_ERROR_OUT_OF_MEM 5
7 #define GR3_ERROR_NOT_INITIALIZED 6
8 #define GR3_ERROR_CAMERA_NOT_INITIALIZED 7
9 #define GR3_ERROR_UNKNOWN_FILE_EXTENSION 8
10 #define GR3_ERROR_CANNOT_OPEN_FILE 9
11 #define GR3_ERROR_EXPORT 10
12 const char gr3_geterrorstring(
13 int error
14 );
Parameter
error
Ein Fehlercode
gr3_setlogcallback
Setzt die Callback-Funktion für Debug-Meldungen.
1 void gr3_setlogcallback(
2 void ( gr3_log_func)( const char log_message)
3 );
Parameter
gr3_log_func
Ein Zeiger auf die Logging-Callback-Funktion. Sie wird mit Debug-Meldungen
aus GR3 als log_message aufgerufen. Die übergebenen Zeichenketten werden
nach dem Aufruf von der Bibliothek freigegeben.
A.2. Szenenbeschreibungsfunktionen
gr3_clear
Löscht die aktuelle Szene.
1 int gr3_clear () ;
54

gr3_cameralookat
Setzt die Position und Ausrichtung der Kamera.
1 void gr3_cameralookat(
2 float camera_x , float camera_y , float camera_z ,
3 float center_x , float center_y , float center_z ,
4 float up_x , float up_y , float up_z
5 );
Parameter
camera_x, camera_y, camera_z
Die Position der Kamera
center_x, center_y, center_z
Der Fokuspunkt
up_x, up_y, up_z
Ein Vektor, der im Bild nach oben zeigen soll
gr3_setcameraprojectionparameters
Setzt die Projektionsparameter der Kamera.
1 int gr3_setcameraprojectionparameters(
2 float vertical_field_of_view ,
3 float zNear ,
4 float zFar
5 );
Parameter
vertical_field_of_view
Das vertikale Sichtfeld im Gradmaß
zNear
Die Distanz von der Kamera zur vorderen Clipping-Ebene
zFar
Die Distanz von der Kamera zur hinteren Clipping-Ebene
gr3_setlightdirection
A.2. Szenenbeschreibungsfunktionen
Setzt die Richtung der Beleuchtung. Falls die Funktion mit (0, 0, 0) aufgerufen wird,
wird die Blickrichtung der Kamera verwendet.
1 void gr3_setlightdirection(
2 float x, float y, float z
3 );
55

Anhang A. Funktionsreferenz
Parameter
x, y, z
Die Richtung des Lichts
gr3_setbackgroundcolor
Setzt die Hintergrundfarbe.
1 void gr3_setbackgroundcolor(
2 float red ,
3 float green ,
4 float blue ,
5 float alpha
6 );
Parameter
red, green, blue
Die Hintergrundfarbe
alpha
Die Alpha-Komponente des Hintergrunds (0 für transparent, 1 für blickdicht)
gr3_createmesh
Erstellt ein Dreiecksgitter.
1 int gr3_createmesh(
2 int mesh ,
3 int n,
4 const float vertices ,
5 const float normals ,
6 const float colors
7 );
Parameter
mesh
Ein Zeiger auf eine int-Variable, in welche die ID des Dreiecksgitters geschrieben
wird. Anhand dieser ID kann das Gitter anschließend identifiziert werden.
n
Die Anzahl der Eckpunkte
vertices
Ein Zeiger auf ein float-Array, welches die Ortsvektoren der Eckpunkte enthält
56

A.2. Szenenbeschreibungsfunktionen
normals
Ein Zeiger auf ein float-Array, welches die Normalenvektoren der Eckpunkte
enthält
colors
Ein Zeiger auf ein float-Array, welches die Farben der Eckpunkte enthält
gr3_drawmesh
Fügt ein mit gr3_createmesh erstelltes Dreiecksgitter ein- oder mehrmals zur Szene
hinzu.
1 void gr3_drawmesh(
2 int mesh ,
3 int n,
4 const float positions ,
5 const float directions ,
6 const float ups ,
7 const float colors ,
8 const float scales
9 );
Parameter
mesh
Die ID des zu zeichnenden Dreiecksgitters
n
Die Anzahl der zu zeichnenden Dreiecksgitter
positions
Ein Zeiger auf ein float-Array, welches die Positionen der Dreiecksgitter enthält
directions
Ein Zeiger auf ein float-Array, welches die Vorwärts-Vektoren der Dreiecksgitter
enthält
ups
Ein Zeiger auf ein float-Array, welches die Aufwärts-Vektoren der Dreiecksgitter
enthält
colors
Ein Zeiger auf ein float-Array, welches die Farben der Dreiecksgitter enthält
scales
Ein Zeiger auf ein float-Array, welches die Skalierungsvektoren der Dreiecksgitter
enthält
57

Anhang A. Funktionsreferenz
gr3_deletemesh
Gibt ein Dreiecksgitter zum Löschen frei.
1 void gr3_deletemesh(
2 int mesh
3 );
Parameter
mesh
Die ID des zu löschenden Dreiecksgitters
gr3_drawconemesh
Fügt einen oder mehrere Kegel zur Szene hinzu.
1 void gr3_drawconemesh(
2 int n,
3 const float positions ,
4 const float directions ,
5 const float colors ,
6 const float radii ,
7 const float lengths
8 );
Parameter
n
Die Anzahl der zu zeichnenden Kegel
positions
Ein Zeiger auf ein float-Array, welches die Positionen der Kegel enthält
directions
Ein Zeiger auf ein float-Array, welches die Vorwärts-Vektoren der Kegel enthält
colors
Ein Zeiger auf ein float-Array, welches die Farben der Kegel enthält
radii
Ein Zeiger auf ein float-Array, welches die Basisradien der Kegel enthält
lengths
Ein Zeiger auf ein float-Array, welches die Länge, bzw. Höhe der Kegel enthält
58

gr3_drawcylindermesh
Fügt einen oder mehrere Zylinder zur Szene hinzu.
1 void gr3_drawcylindermesh(
2 int n,
3 const float positions ,
4 const float directions ,
5 const float colors ,
6 const float radii ,
7 const float lengths
8 );
Parameter
n
Die Anzahl der zu zeichnenden Zylinder
A.2. Szenenbeschreibungsfunktionen
positions
Ein Zeiger auf ein float-Array, welches die Positionen der Zylinder enthält
directions
Ein Zeiger auf ein float-Array, welches die Vorwärts-Vektoren der Zylinder
enthält
colors
Ein Zeiger auf ein float-Array, welches die Farben der Zylinder enthält
radii
Ein Zeiger auf ein float-Array, welches die Radien der Zylinder enthält
lengths
Ein Zeiger auf ein float-Array, welches die Länge, bzw. Höhe der Zylinder
enthält
gr3_drawspheremesh
Fügt einen oder mehrere Kugeln zur Szene hinzu.
1 void gr3_drawspheremesh(
2 int n,
3 const float positions ,
4 const float colors ,
5 const float radii
6 );
59

Anhang A. Funktionsreferenz
Parameter
n
Die Anzahl der zu zeichnenden Kugeln
positions
Ein Zeiger auf ein float-Array, welches die Positionen der Kugeln enthält
colors
Ein Zeiger auf ein float-Array, welches die Farben der Kugeln enthält
radii
Ein Zeiger auf ein float-Array, welches die Radien der Kugeln enthält
A.3. Export- und Zeichenfunktionen
gr3_getimage
Erzeugt eine Grafik und schreibt sie in einen vom Anwendungsentwickler verwalteten
Speicherbereich.
1 int gr3_getimage(
2 int width ,
3 int height ,
4 int use_alpha ,
5 char pixels
6 );
Parameter
width
Die Breite der Grafik in Pixeln
height
Die Höhe der Grafik in Pixeln
use_alpha
Ein Flag, ob Transparenz verwendet werden soll: 0 für Nein, 1 für Ja
pixels
Der Speicherbereich, in welchen die Grafik geschrieben wird. Dieser Bereich
muss width · height · components Byte groß sein, wobei components gleich 4 ist,
falls Transparenz verwendet wird, oder 3, falls nicht.
60

gr3_drawimage
Zeichnet die Szene in einen Zeichenbereich.
1 #define GR3_DRAWABLE_OPENGL 1
2 #define GR3_DRAWABLE_GKS 2
3 int gr3_drawimage(
4 float xmin , float xmax ,
5 float ymin , float ymax ,
6 int width ,
7 int height ,
8 int drawable_type
9 );
Parameter
A.3. Export- und Zeichenfunktionen
xmin, xmax
Die minimale und maximale Position der Grafik auf der x-Achse
ymin, ymax
Die minimale und maximale Position der Grafik auf der y-Achse
height
Die Höhe der Grafik in Pixeln
width
Die Breite der Grafik in Pixeln
drawable_type
Die Art des Zeichenbereiches, welcher zur Darstellung verwendet werden soll
gr3_export
Schreibt die Grafik in eine Datei. Unterstützte Dateiformate sind PNG (.png), JPEG
(.jpg/.jpeg), POV-Ray SDL (.pov) und HTML5 (.html).
1 int gr3_export(
2 const char filename ,
3 int width ,
4 int height
5 );
Parameter
filename
Der Name der Ausgabedatei
width
Die Breite der Grafik in Pixeln
height
Die Höhe der Grafik in Pixeln
61

Anhang A. Funktionsreferenz
gr3_setquality
Setzt die Qualität der Grafikerzeugung. Dies entscheidet, ob OpenGL oder POV-Ray
und ob bzw. wie viel Kantenglättung verwendet werden soll.
1 #define GR3_QUALITY_OPENGL_NO_SSAA 0
2 #define GR3_QUALITY_OPENGL_2X_SSAA 2
3 #define GR3_QUALITY_OPENGL_4X_SSAA 4
4 #define GR3_QUALITY_OPENGL_8X_SSAA 8
5 #define GR3_QUALITY_OPENGL_16X_SSAA 16
6 #define GR3_QUALITY_POVRAY_NO_SSAA 1
7 #define GR3_QUALITY_POVRAY_2X_SSAA 3
8 #define GR3_QUALITY_POVRAY_4X_SSAA 5
9 #define GR3_QUALITY_POVRAY_8X_SSAA 9
10 #define GR3_QUALITY_POVRAY_16X_SSAA 17
11 int gr3_setquality(
12 int quality
13 );
Parameter
quality
Die gewünschte Qualitätsstufe
62

B. Codebeispiele
B.1. Visualisierung dreier Kugeln
Der folgende Quelltext wird in Abschnitt 4.1.1 erläutert und Abbildung 4.1 auf Seite
32 zeigt die Ergebnisgrafik.
1 #include
2 #include
3
4 int main( void) {
5 int init_attrs [] = {GR3_IA_END_OF_LIST};
6 int err = gr3_init(init_attrs);
7 if (err) {
8 fprintf(stderr ," Failed to initialize GR3: %s \n" ,
gr3_geterrorstring(err));
9 return 1;
10 }
11 / Hintergrundfarbe : Rot , Grün , Blau , Alpha /
12 gr3_setbackgroundcolor (0 , 0, 0, 0) ;
13 / Projektionsparameter : vertikales Sichtfeld in Grad , Nah≠ und
14 Fern≠Clipping≠Abstand /
15 gr3_setcameraprojectionparameters (6 , 1, 100) ;
16 / Kameraposition , Fokuspunkt , up≠Vektor /
17 gr3_cameralookat (0 ,0 ,20 , 0 ,0 ,0 , 0 ,1 ,0) ;
18 {
19 float positions [] = {≠2,0,0, 0,0,0, 2,0,0};
20 float colors [] = {1,0,0, 0,1,0, 0,0,1};
21 float radii [] = {1,1,1};
22 gr3_drawspheremesh (3 , positions , colors , radii ) ;
23 }
24 gr3_setquality(GR3_QUALITY_OPENGL_4X_SSAA) ;
25 gr3_export(" image . png" ,3000,1000) ;
26 gr3_terminate () ;
27 return 0;
28 }
Listing B.1: Darstellung von drei Kugeln mit GR3
63

Anhang B. Codebeispiele
B.2. Eine Funktion als 3D-Fläche
Eine Erläuterung des folgenden Quelltextes ist in Abschnitt 4.1.2 zu finden. Abbildung
4.2 auf Seite 35 zeigt die erzeugte Grafik.
1 #include
2 #include
3 #include
4
5 float f(int x, int y) {
6 return sin(x 0.66) cos(y 0.2) ;
7 }
8
9 float dfdx( int x, int y) {
10 return 0.66 cos (0.66 x) cos (0.2 y);
11 }
12
13 float dfdy( int x, int y) {
14 return ≠0.2 sin (0.66 x) sin (0.2 y);
15 }
16
17 float normalize( float vec) {
18 float tmp = 0 ;
19 int i;
20 for (i = 0; i < 3; i++) tmp += vec[i] vec [ i ];
21 tmp = s q r t (tmp) ;
22 for (i = 0; i < 3; i++) vec[i]/=tmp;
23 return vec ;
24 }
25
26 int main( void) {
27 int init_attrs [] = {GR3_IA_END_OF_LIST};
28 int err = gr3_init(init_attrs);
29 if (err) {
30 fprintf(stderr ," Failed to initialize GR3: %s \n" ,
gr3_geterrorstring(err));
31 return 1;
32 }
33 gr3_setbackgroundcolor (0 , 0, 0, 0) ;
34 gr3_setcameraprojectionparameters(45, 1, 100) ;
35 gr3_setlightdirection (0,0,1) ;
36 gr3_cameralookat(5,≠6,12, 5,5,0, 0,1,0);
37 {
38 int mesh ;
39 int i, x, y;
40 int dx [ 6 ] = {0 ,1 ,1 ,0 ,1 ,0};
41 int dy [ 6 ] = {0 ,0 ,1 ,0 ,1 ,1};
42 float mesh_vertices [100 6 3];
43 float mesh_normals [100 6 3];
44 float mesh_colors [100 6 3];
45 float positions [3] = {0,0,0};
46 float directions [3] = {0,0,1};
64

B.2. Eine Funktion als 3D-Fläche
47 float ups [3] = {0 ,1 ,0};
48 float colors [3] = {1,1,1};
49 float scales [3] = {1,1,1};
50 for (x = 0; x < 10; x++) {
51 for (y = 0; y < 10; y++) {
52 for (i = 0; i < 6; i++) {
53 int ix = x+dx[ i ];
54 int iy = y+dy[ i ];
55 mesh_vertices [(y 10+x) 6 3+ i 3+0] = ix ;
56 mesh_vertices [(y 10+x) 6 3+ i 3+1] = iy ;
57 mesh_vertices [(y 10+x) 6 3+ i 3+2] = f ( ix , iy ) ;
58
59 mesh_normals [( y 10+x) 6 3+ i 3+0] = ≠dfdx(ix , iy ) ;
60 mesh_normals [( y 10+x) 6 3+ i 3+1] = ≠dfdy(ix , iy ) ;
61 mesh_normals [( y 10+x) 6 3+ i 3+2] = 1;
62 normalize(mesh_normals+(y 10+x) 6 3+ i 3+0) ;
63
64 mesh_colors [(y 10+x) 6 3+ i 3+0] = 1;
65 mesh_colors [(y 10+x) 6 3+ i 3+1] = 1;
66 mesh_colors [(y 10+x) 6 3+ i 3+2] = 1;
67 }
68 }
69 }
70 gr3_createmesh(&mesh , 100 6, mesh_vertices , mesh_normals,
mesh_colors) ;
71 gr3_drawmesh(mesh ,1 , positions , directions , ups , colors , scales ) ;
72 gr3_deletemesh(mesh) ;
73 }
74 gr3_setquality(GR3_QUALITY_OPENGL_16X_SSAA) ;
75 gr3_export(" graph . png" , 3000, 1000) ;
76 gr3_terminate () ;
77 return 0;
78 }
Listing B.2: 3D-Plot der Funktion f(x, y) =cos(0.66x) · sin(0.2y)
65