Open-GL vs. Direct3D

Universität Koblenz–Landau
Fachbereich Informatik
Open-GL vs. Direct3D
Marco Thum
Matrikelnummer 9720895
Seminar Computergraphik
betreut von Prof. Dr.-Ing. H. Giesen
Wintersemester 2000/2001
Vortrag vom 11. April 2001
INHALTSVERZEICHNIS
2
Inhaltsverzeichnis
1
Einleitung
2
OpenGL
2.1 Funktionaliät . . . . .
2.2 Architektur . . . . . .
2.3 Renderingtechnik . . .
2.3.1 Bilddarstellung
3
4
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
. 5
. 6
. 9
. 10
Direct3D
3.1 Funktionalität . . . . . .
3.2 Architektur . . . . . . .
3.2.1 Immediate Mode
3.2.2 Retained Mode .
3.3 Renderingtechnik . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
12
13
14
15
Vergleich beider Schnittstellen
4.1 Funktionalität . . . . . . .
4.2 Architektur . . . . . . . .
4.3 Renderingtechnik . . . . .
4.4 Tabellarischer Vergleich .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
17
17
5
Resümee
18
6
Aussichten
19
7
Quellen im Internet
21
ABBILDUNGSVERZEICHNIS
3
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
OpenGL und zusätzliche Bibliotheken [10] . . . . .
Aufteilung des Framebuffers [10] . . . . . . . . . . .
Resultat des Codefragments (mit Fenstersystem) [10]
Renderingablauf in OpenGL [13] . . . . . . . . . . .
Bufferswapping [10] . . . . . . . . . . . . . . . . .
HAL & HEL [15] . . . . . . . . . . . . . . . . . . .
Architektur des Direct3D-Device . . . . . . . . . . .
Renderingpipeline in DirectX . . . . . . . . . . . . .
Übersicht zu Leistungen von 3D-Graphikkarten [16]
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
8
9
10
11
13
14
15
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
8
12
13
13
17
Tabellenverzeichnis
1
2
3
4
5
6
Befehlsfunktionen von OpenGL nach [1] .
Nomenklatur von OpenGL . . . . . . . .
DirectX7-Komponenten . . . . . . . . . .
Objekttypen in DirectDraw und Direct3D
Interfacetypen in Direct3D . . . . . . . .
OpenGL vs. Direct3D . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
1 EINLEITUNG
1 Einleitung
Spätestens seitdem Personal Computer neben staatlichen Einrichtungen und wissenschaftlichen Instituten Einzug in Haushalte und Kinderstuben genommen haben, dehnt sich ihr
Nutzungsbereich ständig aus. Im gleichen Verhältnis steigen auch die Ansprüche an Hard
-und Software. Inbesondere im 3D-Bereich hat sich der Markt in den 90er Jahren rapide entwickelt. Doch auch wenn derzeitige 3D-Hardware der softwareseitigen Berechnung
von großen Polygonlandschaften schon sehr viel Arbeit abnehmen kann, so sind die Grenzen solange noch nicht erreicht, bis photorealistische Welten in Echtzeit gerendert werden
können. Nun gibt es am Anfang einer jeden Entwicklung immer eine Basis, auf die aufgebaut wird. Diese Basis bilden in unserem Falle die beiden Graphikschnittstellen OpenGL
und Direct3D.
Als Graphikschnittstelle bezeichnet man ein Softwaremodul, dass nicht vorhandene
Graphikhardware zur Implementierung komplexer 3D-Szenen in 2D-Format am Bildschirm
emuliert, sich somit also zwischen Hard -und Software klinkt.
Ende der 80er Jahre hatte die auf den Bau von graphikberechnenden Servern spezialisierte Firma Silicon Graphics eine Schnittstelle namens IrisGL1 für ihre eigene Hardware
entwickelt. OpenGL als weiterentwickelte Form von IrisGL wurde später durch ein Konsortium namens ”Architecture Review Board” (ARB) implementiert. Namhafte Hersteller
wie IBM, DEC, Intel und Microsoft sind hier vertreten und zeichnen sich bis dato für Definition, Weiterentwicklung und Herausgabe offizieller Dokumente zum Standard OpenGL
aus. Von Fremdherstellern entwickelte Variationen müssen einer Konformitätsprüfung, die
auf Richtlinien der ARB basieren, unterzogen werden, um legitimiert zu sein. Trotz dieser Auflagen definiert sich OpenGL als sozusagen herstellerneutrale und damit frei verfügund erweiterbare Schnittstelle. Seine Einbindung in den Consumer-Markt hat OpenGL im
Jahre 1993 erfahren, als es von Microsoft in Windows NT implementiert wurde.
Während OpenGL als plattformunabhängiges Modul auf nahezu jedem beliebigen Betriebssystem lief und immer noch läuft, entstand im Frühjahr 1995 im Hause Microsoft
eine eigene Multimedia-Schnittstelle, die auf die speziellen Eigenschaften ihrer WindowsPlattformen ausgerichtet ist: DirectX. Die Intention des Redmonder Unternehmens war
es, zum einen die Entwickler für den Umstieg von der DOS-Ebene zur Win32-API zu
gewinnen, und zum anderen die Industrie bei der Umstellung auf ein 32Bit-System zu
neuen Innovationen zu bewegen. Den Entwicklern gab man ein umfangreiches Software
Development Kit (SDK)2 mit. Im Gegensatz zu OpenGL besitzt DirectX mehr als eine
Graphikschnittstelle, die hier in ihrer Version zur Emulierung von 2D-Graphiken DirectDraw genannt wird. Im Laufe seiner Weiterentwicklung wurden mehr und mehr Peripheriegeräte und ihre softwareseitige Unterstützung in DirectX integriert. Erst im Herbst 1996
wurde Direct3D als fester Bestandteil von DirectX und als Modul zur Emulierung von
3D-Objekten integriert.
Ziel dieser Seminararbeit war es, die verschiedenen Eigenschaften beider Graphikschnittstellen hinsichtlich Funktionalität, Architektur und Renderingtechnik vorzustellen
und im Anschluss zu vergleichen. Auf Grund dessen, dass sich Befehlsstrukturen und Programmiertechniken als sehr umfangreich zu beschreiben herausstellen, soll an dieser Stelle
nur kurz auf Syntax und Semantik eingegangen werden.
Nicht alle in der Literaturliste aufgeführeten Quellen wurden für die Seminararbeit herangezogen, vielmehr sollen sie zur Vertiefung des Themas anregen.
1 Das ”GL” steht hierbei für ”Graphics Library”, folglich eine Bibliothek von Befehlen und Algorithmen zum
Umgang mit graphisch beschreibbaren Objekten und Formen.
2 Eigentlich: Gamers Development Kit (GDK), da DirectX hauptsächlich für die Entwicklung von Spielen und
Multimedianwendungen gedacht war
5
2 OpenGL
2.1 Funktionaliät
Im eigentlichen Sinne ist OpenGL ein Application Programming Interface (API) zur Modellierung graphisch primitiver Objekte. Diese Objekte sind zwar nur zweidimensional,
doch sind die 13 darstellbaren Primitva mittels Darstellungslisten zu verknüpften, dreidimensionalen Objekten ausbaufähig. Diese Methode bezeichnet man als prozedurales Modell, genauer gesagt beschreibt OpenGL aber nicht das Aussehen eines Objekts, sondern
nur, wie es bearbeitet werden soll[1].
Seine Plattformunabhängigkeit verdankt OpenGL dem einfachen Aufbau der Befehlsbibliothek. Weder spezifische Programmierkenntnisse, noch ein spezielles Fenstersystem
werden verlangt. Die Bibliotheken sind auf jedes System portierbar und meistens auch
schon im Betriebssytemkernel verankert.
Da OpenGL an sich nur einfache graphische Objekte beschreiben kann, existieren Zusatzbibliotheken zur Erweiterung seines Befehlssatzes:
• OpenInventor
– Klassenbibliothek für den hierarchischen Aufbau von Szenen
– ereignisgesteuerte Interaktion sowie persistente Speicherung grafischer Objekte im ASCII oder Binärformat
• GLX
– Bibliothek zur Einbettung von OpenGL in das X-Windows-System (unter UNIX)
• WGL
– auch ”wiggle” genannt
– dient zur Einbettung von OpenGL unter Windows
• GLU
– ”OpenGL Utility Library”, z.B. für Matrizen, Orientierungspunkte, Projektionen, Polygonzerlegung, Oberflächenrendering
– erzeugt auch die angesprochenen Darstellungslisten
• GLUT
– ”OpenGL Utility Toolkit”; fensterunabhängig
Wie die verschiedenen Bibliotheken miteinander agieren, zeigt eine Übersicht in Abb.
1.
Weiterhin existieren von Graphikhardwareherstellern speziell optimierte Implementationen von OpenGL. Darüberhinaus sind reine Software-Emulationen vorhanden, wie etwa
die MESA-Bibliothek3 oder spezifische Betriebssystemsimplementationen.
Welche Befehlsfunktionen OpenGL innehat, zeigt Tabelle 1.
3 (http://www.mesa3d.org)
2 OPENGL
6
Abbildung 1: OpenGL und zusätzliche Bibliotheken [10]
2.2 Architektur
Um größere Szenen in relativ akzeptabler Zeit berechnen zu können, ist OpenGL auf eine
Client-Server-Architektur ausgelegt. Über ein Netzwerk wird die Anwendung oder die Anfrage an die Renderapplikation vom Client aus gestartet, der Server interpretiert dann im
folgenden die zu berechnenden Operationen. Realisiert wird dies über die Implementation
eines Fensterssystems. Intern führt OpenGL die Befehle in der vorgegebenen Reihenfolge
ihres Aufrufs aus. Dies bedeutet, dass graphische Primitiva wie Dreiecke erst vollständig
dargestellt werden, bevor weitere Aufrufe ausgeführt werden und sich das Objekt in detailliertere Form wie einen Würfel verwandelt. Dabei arbeitet OpenGL als Zustandsautomat
in folgenden Schritten [1]:
1. Ausgabe graphischer Primitive in den Bildspeicher
2. Interner Zustand bestimmt durch den Modus der Darstellung (aktueller Status der
Befehlsverarbeitung)
3. Veränderung des Status durch Befehle, dennoch keine Ausgabe des bisher gezeichneten
Die Zustandsbeschreibung erfolgt durch die Vergabe von Werten an Variablen, die in
einem Stack gespeichert werden. Ist die komplette Berechnung erfolgt, wird der Stack
ausgelesen und die Objekte gezeichnet. Die stetige Berechnung von gesamten Objekten
sorgt für deren einfachere Reproduzierbarkeit.
Hinsichtlich Hardwareanforderungen arbeitet OpenGL einerseits unabhängig von verwendeter Hardware, was bedeutet, dass es einfach von System zu System zu portieren ist,
andererseits unter Ausnutzung vorhandener Ressourcen, intensiv vor allem des Speichers.
Die minimale Speichermenge, die OpenGL fordert, ergibt sich aus folgender Gleichung:
32
640
∗ 480} ∗( |{z}
| {z
P ixel
F arbtief e
+
1
|{z}
z−Buf f er
+
1
|{z}
Stencil−Buf f er
+
4
|{z}
)Bit = 1, 4592M Byte
Akkumulationsbuf f er
OpenGL legt in einem reservierten Bereich einen Framebuffer an, in dem alle nötigen
Informationen zur Darstellung des Bildschirmbereiches gespeichert werden. Dabei wird
direkt auf vorhandene Graphikhardware zugegriffen, anstatt auf die Reserven des Hauptspeichers. Abb.2 zeigt eine grobe Aufteilung des Framebuffers.
Im Einzelnen ist der Framebuffer folgendermaßen aufgeteilt:
• Farbspeicher (Color Buffer)
2.2 Architektur
7
Befehlsgruppe
Modellierung und Darstellungslisten
Transformation
Beleuchtung und Schattierung
Clipping
Scankonvertierung
Pixeloperationen
Texturen
Framebufferoperationen
Evaluatoren
Selektion und Feedback
Steuerung und Statusabfragen
Mögliche Anwendung
Definition von Eckpunkten und
Rechtecken; Aufbau, Löschen und
Ausführen von Darstellungslisten
Festlegen von Transformationen
und Viewing; Manipulation der aktuellen Matrix
Festlegen von Farben, Lichtquellen und Materialien; Definition von
Echtfarbe- und Indexmodus; Wahl
des Beleuchtungsmodells, der Art
der Schattierung und von Nebel
Festlegung zusätzlicher Clipebenen
Wahl des Konvertierungsmodus,
von Füllmustern und Ausdehnungen, Definition von Bitmaps
Lesen, Schreiben und Kopieren von
Bildschirm- und Speicherauszügen
als Pixelmap
Definition und Mapping von einund zweidimensionalen Texturen
Steuerung der Fragmenttests, der
Auswahl von Framebufferebenen
und Maskierung der Einträge
Definition und Generierung von
Koordinaten,
Texturkoordinaten und Farben mit Hilfe von
Bezierkurven und -flächen
Kontrolle der Selektions- und Feedbackmechanismen
Aktivieren, Deaktivieren und Erfragen der Darstellungsmodi, Fehlerbehandlung und Abfrage der Statusvariablen
Tabelle 1: Befehlsfunktionen von OpenGL nach [1]
• Bildmaskenspeicher (Stencil Buffer)
• Tiefenspeicher (Depth Buffer)
• Sammelspeicher (Accumulation Buffer)
• Hilfsspeicher (Auxiliary Buffer)
Die Daten des darzustellenden Szenenauschnitts werden in ihrer kleinsten berechenbaren Einheit gespeichert: in Pixeln. Pixeldaten werden mit Farbe, Adresse und Texturkoordinaten hinterlegt. Jene ”Operationen am Fragment”[1] erleichtern jede weitergehende
Berechnung, da komplexe Objekte niemals komplett berechnet werden. Trotz dieser wirtschaftlichen Aufteilung des Speichers und der effizienten Berechnung der Bilddaten gilt
durchgängig der Leitsatz: Je besser die Hardware, desto besser die Performance.
Da sich OpenGL nur um die Interna der Graphikberechnung kümmert, also nur um
die Objekte selbst, werden die restlichen Aufgaben der Betriebssystem-API überlassen.
2 OPENGL
8
Abbildung 2: Aufteilung des Framebuffers [10]
Dazu gehören die Organisation der Buffer, die Darstellung des Bildspeichers, γ-Korrektur,
Funktionalitäten der Peripherie (Maus . . . ) etc.
Nun besteht die Frage, wie OpenGL in eigene Programme integriert werden kann. Eigentlich ist die Antwort schon gegeben. Der Entwickler muss die Header-Dateien von
OpenGL und seinen Zusatzbibliotheken einbinden, den Rest erledigt das Betriebssystem.
Wichtig zu wissen ist aber, wie Befehle aufgerufen und Variablen angesprochen werden
können. Hierzu eine kleine Übersicht zur Nomenklatur in Tabelle 2.
Konstanten
Datentypen
Methoden
Varianten für Zusatzbiblitheken
GL TRUE, GL FALSE
GLboolean
glMatrixMode()
glu..., wgl....
Tabelle 2: Nomenklatur von OpenGL
Um sich OpenGL in Aktion vorstellen zu können, folgt an dieser Stelle ein simples
Codebeispiel [10]:
glDisable(GL DEPTH TEST);
glClearColor(0.0,0.0,0.0,1.0); // setze Hintergrund
glClear(GL COLOR BUFFER BIT); // lösche Hintergrund
glMatrixMode(GL PROJECTION); // Projektionstransformationsmodus
glLoadIdentity(); // Rücksetzen auf Identität
glOrtho(0.0,1.0, 0.0,1.0, -1.0,1.0); // Orthogonalprojektion
glMatrixMode(GL MODELVIEW); // Geometrietransformationsmodus
glColor3f(0.0, 1.0, 0.0); // Malfarbe auf Grün setzen
glBegin(GL POLYGON); // Beginn Primitiv
glVertex2f(0.25,0.25); // 1. Ecke
2.3 Renderingtechnik
glVertex2f(0.75,0.25); // 2.
glVertex2f(0.75,0.75); // 3.
glVertex2f(0.25,0.75); // 4.
glEnd(); // Ende Primitiv
glFlush(); // Ausgabepipeline
9
Ecke
Ecke
Ecke
synchronisieren
SwapBuffers(m pDC->GetSafeHdc()); // Win32-spezifisch:
Buffer-Swap
Abbildung 3: Resultat des Codefragments (mit Fenstersystem) [10]
2.3 Renderingtechnik
Allgemein gesagt erstellt OpenGL ausgehend von der Geometrie der Szene eine gerenderte
Darstellung im Framebuffer, der dann auf den Bildschirm wiedergegeben wird. Jede Szene
besteht aus
Vertexdaten: die Geometrie der Szene, also die Punkte, Normalenvektoren, Linien, Polygone, Spline-Kurven und Flächen
Pixeldaten: Texturen für die Oberflächen, Schablonenmasken
Darstellungslisten: Darstellungslisten sind speziell für OpenGL vorbereitete Listen mit
Geometrie- und Texturdaten, die eine deutlich schnellere Bearbeitung ermöglichen
Diese Daten werden in verschiedenen Stufen verarbeitet. Zuerst werden darzustellende
Objekte aus Primitiva modelliert. Ein Teil derer wird anschließend zu Objekten höherer
Komplexität durch mehrfache Verwendung in unterschiedlich transformierten Zuständen
zusammengefasst. Im Anschluß werden die Objekte durch Transformation in der (virtuellen) Welt (Szene) plaziert. Sichtbarkeit und Perspektive werden durch eine gedachte
Kamera samt ihrer spezifischen Eigenschaften festgelegt. Um nicht sichtbare Flächen zu
entfernen, werden Verdeckungsrechnungen durchgeführt. Das Verfahren wird Back-FaceCulling genannt. Im nächsten Schritt wird die Szene mit festgelegten Lichtquellen beleuchtet und die daraus resultierende, farbig schattierte Darstellung der Objekte berechnet.
2 OPENGL
10
Während der nun folgenden Rasterisierung (Scankonvertierung) der Objekte und Diskretisierung der Farben wird deren visuellen Nebeneffekten durch Antialiasing, Dithering und
γ-Korrektur entgegengewirkt.
Abbildung 4: Renderingablauf in OpenGL [13]
Der Prozess des Renderns in OpenGL kann aber noch weiter spezifiziert werden. Wie
schon beschrieben, durchlaufen mehrere Vertices die Rendering-Pipeline und definieren
dabei zusammenhängend ein Primitiv, welches später in Fragmente4 rasterisiert und in den
Bildspeicher geschrieben wird. Doch können auch Funktionen die Eigenschaften der Primitive beschreiben. Hierbei werden Koordinaten und Farben auf der Basis von parametrisierten Kurven und Flächen beschrieben. Die Umwandlung in die benötigten Eckpunkte erfolgt dann durch Evaluatoren. Diese Eckpunkte werden abgespeichert und mittels Darstellungslisten wieder aufgerufen und in die Pipeline zurück geschickt. Dieser Vorgang wird
als Caching5 bezeichnet. Nach der Rasterisierung können dann erweiternde Berechnungen
von Textur, Nebel oder z-Buffer-Test erfolgen. Bemerkenswert ist dabei die Tatsache, dass
OpenGL auf Interaktion angewiesen ist. So kann der Fluss der Pipeline unterbrochen und
damit die Abarbeitung vorher definierter Befehle durch Kommandos wie glFlush oder
glFinish erzwungen werden. Die Befehle innerhalb der durch die Kommandos festgelegten Struktur werden als ein Gesamtobjekt identifiziert. Grob gesagt besitzt OpenGL also
drei Darstellungsmodi6:
• Selektion (Speicherung von Bezeichnungen)
• Rückkopplung7 (Speicherung von Objekten)
• Rendering
2.3.1 Bilddarstellung
Bekannt ist, dass OpenGL den Framebuffer verwendet, um Bildinhalte darzustellen. Um
aber z.B. Flackern bei Animationen, deren Flüssigkeit vom Prozessortakt und der Komplexität der Szene abhängig ist, zu verhindern, wird die Technik des Double Buffering
verwandt.
4 Pixel
mit Zusatzinformationen
Kap.3.2.2
6 rendering modes
7 feedback mode
5 vgl.
2.3 Renderingtechnik
11
Abbildung 5: Bufferswapping [10]
Unter der Verwendung zweier Farbpuffer wird Frame8 für Frame das folgende Bild im
Hintergrund aufgebaut (Back Buffer). Davon unabhängig ist das gerade sichtbare Bild auf
dem Bildschirm und im Front Buffer. Ist ein Bild im Back Buffer neu aufgebaut worden,
tauschen die beiden Puffer ihre Daten, und der Bildschirm erhält seinen neuen Inhalt aus
dem Front Buffer (Buffer Swapping).
8 einzelne
Szenendarstellung ohne Animation
3 DIRECT3D
12
3 Direct3D
Seit seiner Entstehung 1995 hat sich DirectX auf dem Endverbrauchermarkt zu einer fast
unverzichtbaren Multimedia-Schnittstelle entwickelt. Mittlerweile hat DirectX als ”Code
zwischen Software und Hardware”[2] die Rolle eines kleinen Betriebssystems übernommen. Microsoft ist inzwischen sogar damit beschäftigt, Lösungen für das Internet und eine
Integration in das Windows-Fensterssystem zu realisieren.
Derzeit besteht DirectX aus den Komponenten:
DirectDraw
Direct3D
DirectSound
DirectMusic
DirectPlay
DirectInput
DirectSetup
Methoden zur Darstellung von 2D-Grafiken
Methoden zur Generierung von 3D-Grafiken auf Basis von DirectDraw
Ermöglicht den Zugriff auf alle Soundfunktionen des Betriebssystems
Emuliert Midi-Instrumente
Regelt die Netzwerkkommunikation bei der Entwicklung von
Multiplayer-Spielen
Ermöglicht die Unterstützung von Eingabegeräten
Überprüft DirectX-Komponenten im Betriebssystem und installiert
nach Bedarf Updates
Tabelle 3: DirectX7-Komponenten
Im direkten Vergleich zu OpenGL steht nun Direct3D, welches ähnliche Funktionen
zur Verfügung stellt.
3.1 Funktionalität
Direct3D steht in enger Zusammenarbeit mit DirectDraw. Letzteres ist dafür verantworlich, graphische Primitive wie in OpenGL aufzubauen, die Direct3D benötigt, um 3DEffekte zu emulieren. Wie OpenGL besitzt Software über die beiden Komponenten direkten Zugriff auf den Graphikspeicher. Diese Option bleibt dem GDI9 von Windows vorbehalten.
Die Intention Microsoft’s, DirectX als eine Schnittstelle zwischen Softwareentwicklern
und Hardwareherstellern zu etablieren, gelingt dadurch, dass Entwickler in einer hardwareunabhängigen Umgebung arbeiten können. Man kann also Applikationen entwerfen, ohne die tatsächliche Hardwareausstattung zukünftiger Anwender zu kennen. Realisiert wird
dies mittels des ”Hardware Abstraction Layer” (HAL). Hierfür stellen Hardwarehersteller (software-)technische Informationen zu ihren Produkten zur Verfügung. Alle Features
von DirectX können auf diese Weise ausgenutzt werden. Auf Seiten des Anwenders kann,
um bestimmte Charakteristiken in der Peripherie festzustellen, kann eine Abfrage gestartet
werden. Sollte von der Applikation geforderte Hardware vorhanden sein, wird diese von
DirectX direkt angesteuert, ansonsten wird sie durch den ”Hardware Emulation Layer”
(HEL) emuliert.
3.2 Architektur
Zur Programmierung stellt Direct3D zwei verschiedene Modi bereit:
Immediate Mode : API auf reduziertem Niveau, durch die Entwickler ihre Applikationen
auf Windows-Systeme adaptieren können; hardwareunabhängige Programmierung,
aber dennoch Nutzung von beschleunigender Hardware; eigene 3D-Engine10 erforderlich
9 Graphic
Device Interface
zur Integration von 3D-Funktionen
10 Programmcode
3.2 Architektur
13
Abbildung 6: HAL & HEL [15]
Retained Mode : API auf hohem Niveau, durch die dem Entwickler eine schnelle Entwicklungszeit garantiert wird; Einbindung von Szenenhierarchien und Animationen
möglich
3.2.1 Immediate Mode
Im Gegensatz zu OpenGL kommt Direct3D nicht mit eigenständigen Objekten aus. Daher
baut Direct3D auf DirectDraw auf und bedient sich dessen zweidimensionaler Strukturen.
So sind die zu rendernden Flächen - wie etwa Vorder- und Rückseiten eines Objekts oder
Flächen im z-Buffer - DirectDraw-Gebilde. Zudem bearbeitet Direct3D die Modellierung
einer Szene nicht prozedural wie OpenGL, sondern arbeitet objektorientiert. Die jeder
Szene zu Grunde gelegten Objekttypen sind in Tabelle 4 aufgelistet.
DirectDraw Object
DirectDrawSurface Object
Direct3DDevice Object
Direct3DVertexBuffer Object
Tabelle 4: Objekttypen in DirectDraw und Direct3D
Hauptsächlich arbeitet Direct3D aber mit den sogenannten COM-Schnittstellen11 . Diese Interfaces sind mit jenen aus JAVA und C++ vergleichbar. Sie stellen in Programmfragmenten Methoden bereit, die aber keine Daten liefern. In der folgenden Tabelle 5 sind die
zumeist verwendeten Schnittstellen kurz vorgestellt.
IDirect3D
IDirect3DDevice
IDirect3DVertexBuffer
Grundschnittstelle, um andere Schnittstellen zu erreichen
3D-Objekt zur Programmierung von grafischen Primitiven
Schnittstelle, die Listen von Eckpunkten verwaltet
Tabelle 5: Interfacetypen in Direct3D
Da das DirectX-Entwicklungspaket ständig aktualisiert wird, muss seitens der Softwareentwickler gewährleistet werden, dass ihre Applikation neue Funktionalitäten auto11 Common
Object Models
3 DIRECT3D
14
matisch verwendet. Zur Initialisierung wird daher ein Pointer auf ein IDirect3D-Interface
gesetzt, die Hauptschnittstelle, von denen alle anderen Komponenten ”erben”12 .
Ein Direct3D-Device ist die Komponente, die später gerendert wird. Es fasst die angefallenen Daten zusammen und speichert sie. Im Folgenden durchwandert jedes Device
verschiedene Stufen der Verarbeitung, die in Abb. ?? skizziert sind, bis schließlich die
gesamte Szene in eine DirectDraw-Oberfläche (Surface) umgewandelt worden ist.
Abbildung 7: Architektur des Direct3D-Device
3.2.2 Retained Mode
Zu Zeiten, wo 3D-Graphikhardware noch zu teuer und in ihrer Performance und Funktionsvielfalt zu unausgereift war, erlaubte der Retained Mode von Direct3D die Programmierung einer vollständigen 3D-Umgebung, ohne eigene Algorithmen zur Erzeugung und
Beschleunigung implementieren zu müssen. Inzwischen wird der in Version 6.0 bestehende
Modus aber nicht mehr weiterentwickelt, da zum einen die Hardware effizienter geworden
und somit vollständig softwaregesteuertes Rendern nur noch selten nötig ist, und zum anderen die Entwickler ausgereiftere Algorithmen implementieren als die langsameren des
Retained Mode.
Um den Aufbau von Szenen zu beschreiben, werden Szenengraphen in selbige eingebettet. Diese enthalten Frames13 als Grundeinheit, an welche Geflechte14 aus Polygonen,
Lichtquellen und Kamerastandpunkten15 gebunden sind.
Wie auch der Immediate Mode arbeitet dieser mit Objekten und Interfaces. Das Interface IDirect3DRMObject gilt hierbei als übergeordnete Managment- und Erzeugerklasse
für alle anfallenden Objekte einer Szene. Von hier aus werden den Objekten Methoden
bereitgestellt für
• Devices
• Viewports
• Picking und Transforming
• Frames
• Lokale Transformationen
12 Methoden
und Attribute, die hier vereinbart sind, können auch alle anderen Klassen verwenden
unsichtbarer Punkt im 3D-Raum
14 Meshes
15 Viewports
13 leerer,
3.3 Renderingtechnik
15
3.3 Renderingtechnik
Direct3D bearbeitet die Daten einer Szene in drei verschiedenen aufeinanderfolgenden Stufen ab. Die Eingabedaten, die die Schnittstelle zu allererst und unbedingt benötigt, sind Vertices, also Eckpunkte von Polygonen. Jene Daten wandern dann durch das Transformationsmodul, welches die Eigenschaften der Szene festlegt. Die Koordinaten der Polygoneckpunkte werden in das Weltkoordinatensystem der Szene interpretiert. Danach werden die
Kameraposition und -perspektive festgelegt und danach wird eine Projektionstransformation durchgeführt, in welcher der Szene eine Tiefenwirkung beigebracht und die Objekte
im Bezug auf die Distanz zum Betrachter positioniert werden. Die bis hierhin berechneten Daten werden dann geclippt und das Ergebnis durch den Rasterisierer geschickt. Bei
der Rasterisierung werden geometrische und pixelspezifische Daten in Fragmente zerlegt.
Jedes Fragmentstück entspricht dabei einem Pixel im Framebuffer.
Abbildung 8: Renderingpipeline in DirectX
4 VERGLEICH BEIDER SCHNITTSTELLEN
16
4 Vergleich beider Schnittstellen
4.1 Funktionalität
Sowohl OpenGL als auch Direct3D16 beherrschen grundlegende Funktionen zur Erzeugung
von Objekten im zwei- und dreidimensionalen Raum. Während OpenGL aber lediglich Befehle zur Erzeugung von zweidimensionalen Fragmenten bereitstellt, die dann einzeln zu
einem dreidimensionalen Konstrukt verbunden werden, besitzt Direct3D direkte Methoden zur Erzeugung dreidimensionaler Effekte. Trotzdem bedarf es der Vorberechnung von
zweidimensionalen Strukturen durch die Komponente DirectDraw. OpenGL hat aber als
nicht ständig aktualisierte und nahezu ”openSource-ähnliche” Schnittstelle im Laufe der
Jahre einige zusätzliche Bibliotheken erhalten, die den Funktionsumfang ausbauen.
Historisch gesehen war OpenGL lange vor Direct3D auf dem Markt. Und obwohl es
nicht in dem Maße wie das Microsoft-Produkt kontinuierlich und proportional zur Hardware weiterentwickelt wird, arbeiten die meisten Entwickler hauptsächlich mit dieser Schnittstelle, da es zum einen einfacher zu handhaben und zu implementieren ist, und zum anderen
nicht auf allerneuste Graphikhardware angewiesen ist. Es arbeitet hauptsächlich mit Prozessor und Arbeitsspeicher. Zudem ist die Performance - gemessen an der Geschwindigkeit
beim Aufbau von dreidimensionalen Szenen - besser. Demgegenüber stellt das mittlerweile
in Version 8 verfügbare Direct3D cirka dreivierteljährlich neue Funktionen bereit, die die
Graphikhardware direkt ansprechen und ausnutzen. Problematisch ist aber, dass die Hardware auch vorhanden sein muss, da ansonsten der Softwarerenderer einsetzt und sowohl
Qualität als auch Performance einbrechen, obwohl die Funktionen skalierbar sind. Diese
Emulierung von Graphikkartenfeatures hingegegen beherrscht OpenGL nicht, dies muss
die 3D-Engine der Applikation übernehmen.
Hinsichtlich des Umgangs mit Szenendaten hat es OpenGL schwer. Es besitzt keine
Ein- und Ausgabefunktionalitäten zur Speicherung von Daten über die Laufzeit hinaus.
Objekte müssen stets neu gerendert werden, wenn sie benötigt werden. DirectX hingegen
besitzt ein eigenes Dateiformat zur Speicherung von Daten. Darüberhinaus stellt OpenGL
keine Funktionen bereit [7]
• zur Kommunikation mit der graphischen Benutzeroberfläche des Betriebssystems
• zum Drucken
• zum Laden externer Szenenbeschreibungen oder Geometrien
• zum Verwalten und Erstellen einer Objekthierarchie für die Szene
• zur Generierung von Objekten wie Kugeln oder Tori, die nicht aus Polygonen erstellt
werden müssen.
In DirectX sind jene Funktionen implementiert und werden darüberhinaus durch zusätzliche Module zum Umgang mit sämtlicher Peripherie ergänzt, sozusagen ist es eine einheitliche Schnittstelle für unterschiedliche Anwendungszwecke. Leider ist das Paket an Windowsplattformen gebunden und nicht für andere Betriebssysteme verfügbar. Diesen Vorteil
hat sich OpenGL verschafft. Es ist nicht nur auf beinahe allen gängigen Systemen bereits
fest implementiert, sondern wird teilweise auch von Graphikhardware und dessen Treibern
direkt unterstützt.
Trotz des umfangreicheren Funktionspakets von DirectX, ist OpenGL anwendungsnäher.
Die Header-Dateien mit der Verknüpfung zu sämtlichen notwendigen Bibliotheken muss
nur zusätzlich im Programm angegeben werden. Zur Entwicklung mit DirectX ist aber
ein separates Paket nötig, dass umfangreiche Bibliotheken, Beispiele und Dokumentationen beinhaltet. Um Programme mit DirectX-Funktionen auszuführen, ist aber lediglich ein
wesentlich minimierteres Paket von Nöten.
16 inklusive
seiner Basiskomponente DirectDraw
4.2 Architektur
17
4.2 Architektur
Der wohl wichtigste Unterschied bei der Programmierung ist, dass OpenGL prozedural
und Direct3D objektorientiert arbeitet. Beide Methoden haben ihre Vor- und Nachteile,
gleichen sich aber im wesentlichen aus. So können Objekte bei OpenGL viel übersichtlicher und konsistenter erstellt werden, DirectX speichert objektspezifische Daten auch als
Attribute dieses Objekts ab und sind demnach nur durch separaten Aufruf verfügbar. Zudem können einmal angefallene Daten persistent gespeichert werden, was natürlich deren
Wiederverwendbarkeit erleichtert. Das objektorientierte Programmieren und die ständig
wachsende Funktionsvielfalt von DirectX verkompliziert aber den Einstieg. Es sind wesentlich mehr Schritte nötig, um ein einfaches, akzeptables Ergebnis zu erhalten. OpenGL’s
Modell hingegen kann sehr schnell implementiert werden, ohne dass größere Kenntnisse
der API erforderlich sind.
Auffällig ist, dass OpenGL seit seiner Entwicklung zwar nicht viele Neuerungen erfahren hat, dennoch immer noch noch auf dem Stand der Zeit ist. DirectX respektive
Direct3D als jüngere Schnittstelle wurde vielfach umstrukturiert und erweitert, gleichsam
mit dem Entwicklungsstand der Hardware. Da die Graphikchips viele Renderingtechniken übernommen haben und Entwickler demnach hardwareorientierter arbeiten können, ist
inzwischen auch der Retainded Mode, mit dem einstmals komplette 3D-Engines erstellt
wurden, veraltet. Demnach ist OpenGL viel unabhängiger und bedarf nicht so intensiver
Pflege.
4.3 Renderingtechnik
Im Wesentlichen unterscheiden sich die Rendermethoden der beiden Schnittstellen nicht.
Auf eine bestimme Menge an groben Polygondaten werden Transformationen, Beleuchtungsund Texturoperationen angewandt, die schließlich rasterisiert und zuletzt im Graphikspeicher abgelegt werden. Seitens Direct3D können die Daten aber umfangreicher manipuliert
werden, in OpenGL muss dies die Engine des Entwicklers übernehmen.
4.4 Tabellarischer Vergleich
Vorteile
OpenGL
hardware- und systemunabhängig
anwendungsnäher als Direct3D
schnelle Performance durch prozedurale Objektgenerierung
einfache Programmierung
Nachteile
keine Kommunikation mit GUI
keine Ein- und Ausgabefunktionalität
keine Szenenhierarchie
keine Emulation von neuen Grafikkartenfeatures
Probleme mit nicht-polygonalen
Objekten
Direct3D
multidimensionale
Schnittstelle
durch Einbindung in DirectX
eigenes Dateiformat
im Retained Mode Aufbau einer
Szenenhierachie
Softwareemulation von Hardwarefeatures
auf
Windowsplattformen
beschränkt
im Retained Mode component calling overhead
Überlastung durch COM-Objekte
Performanceeinbußen durch Emulation und Zugriffe auf Registry
Tabelle 6: OpenGL vs. Direct3D
5 RESÜMEE
18
5 Resümee
In dieser Seminararbeit galt es nicht, eine einzelne Schnittstelle als die herausragendste
herauszustellen, sondern vielmehr Unterschiede, Vorzüge und Nachteile kenntlich zu machen, sowie ihre Funktionalität vorzustellen. Dennoch soll an dieser Stelle festgemacht
werden, welche Schnittstelle sich zu welchem Zweck am besten eignet und welches die
ausschlaggebenden Kriterien dafür sind.
Aus der Perspektive des Entwicklers ist diejenige Schnittstelle die erste Wahl, die
in Kombination mit aktueller Graphikhardware die beste Performance erbringt und zugleich einfach zu handhaben ist. Zudem muss abgeschätzt werden, auf welchen Systemen die Software zum Einsatz kommen soll. Direct3D ist hier auf Windows-Plattformen
beschränkt, OpenGL auf allen Systemen anwendbar. Wird OpenGL hardwaremäßig unterstützt, erhält man auch auf ”langsameren”17 Systemen gute Resultate, Direct3D hingegen benötigt bei anspruchsvoller Software immer auch schnelle Hardware, besonders dann,
wenn bestimmte Funktionen emuliert werden müssen. Hinsichtlich der Handhabbarkeit ist
die Struktur von OpenGL eindeutig leichtgängiger als die von Direct3D, nicht zuletzt, weil
es zu OpenGL mehr einschlägige anerkannte Literatur gibt. Schließlich muss der Entwickler Prioritäten setzen und daran die Wahl der Schnittstelle festmachen.
Wissenschaftlich betrachtet, ist OpenGL die eindeutig priorisierte Schnittstelle bei Erstellung und Rendering von dreidimensionalen Umgebungen, denn Direct3D ist zum einen
sehr undurchsichtig und zum anderen rein kommerzieller Natur. OpenGL genießt daher
auch einen sehr hohen Stellenwert bei der Diskussion um die Einbindung von computergraphischen Erkenntnissen, sowie in Bildung und Lehre.
Anzumerken ist noch, dass frei zugängliche Literatur nur für OpenGL ausreichend
vorhanden ist, seien es Tutorien, Grundlagen oder komplette Beschreibungen. Da die
Schnittstelle bereits seit längerer Zeit existiert, finden sich vor allem im Internet viele Quellen. Auch haben sich inzwischen einige ”Standardwerke” (u.a.[3],[4],[5],[8],[14],[12]) hervorgehoben. Standardliteratur zu Direct3D hingegen existiert kaum, denn das zugeörige
DirectX-Paket wird ständig weiterentwickelt und bildet selten eine Grundlage für wissenschaftliche Untersuchungen. Leider existiert auch kein Konsortium, dass gewisse Normierungen vornimmt und die Schnittstelle standarisiert.
17 abhängig
von den Anforderungen der Software
19
6 Aussichten
Grundsätzlich muss man erst den Markt für die beiden Schnittstellen analysieren, um herauszufinden, welche Zukunft ihnen bevorsteht. Obwohl OpenGL bereits fest in Betriebssysteme und in Treiber und Komponenten von Graphikkarten integriert ist, selbst aber nicht
stark weiterentwickelt wird, bleiben die Anforderungen und somit der Markt beständig.
Die Grundlage zur Generierung dreidimensionaler Objekte ist vorhanden und muss nicht
zwangsweise ausgebaut werden, da Softwareentwickler (insbes. Spieleentwickler) und
Hardwarehersteller eigene Unternehmungen hierzu anstreben. Neuere Graphikkartengenerationen wie PowerVR’s Kyro II, NVidias Geforce3 oder ATI’s Radeon II integrieren Techniken wie ”Truform”18, ”Tile Based Rendering”19, ”Trilineare Filterung” oder ”Mipmaps”
und bieten teilweise eine T&L-Komponente20, die dem Renderingvorgang der Schnittstelle
bei der Verarbeitung von Transformations- und Beleuchtungsaufgaben behilflich ist. Ihre
Effizienz ermittelt man hierbei mittels Frameraten21 in Benchmarks bzw. Spielen. Insbesondere bei der Spieleentwicklung, bei der sehr hohe Datenmengen anfallen, kommen
diese Techniken zum Einsatz. Desweiteren versuchen die Hersteller, neuere Direct3DTechnologien seitens der Hardware selbst und auch der Treiber zu unterstützen, um somit
einerseits die Technolgien ausreizend verwendbar zu machen und andererseits die Entwickler auf ihre Seite zu bringen.
Abbildung 9: Übersicht zu Leistungen von 3D-Graphikkarten [16]
Von diesen Entwicklungen fast unbeeindruckt zeigt sich der Markt für die professionellen Anwender, die spezielle Karten zum Rendern mit professioneller Software wie AutoCAD, 3D Studio MAX oder dergleichen benötigen22. Fast ausschließlich wird mit OpenGL
gerendert, die Treiber der Hardware sind hierauf spezialisiert. Auch werden Hardware und
Treiber genaustens auf die anzuwendende Software abgestimmt, Zusatzbibliotheken wie
OpenInventor von OpenGL mit integriert und zusätzliche Techniken wie ”Overlay unified
18 von ATI entwickelt; Erhöhung der Polygonanzahl, um Objekten abgerundete Formen zu geben; in DirectX8
als ”High-Order-Surfaces” eingeführt[17]
19 Verfahren zur Reduzierung von Speicherzugriffen
20 Transform & Lightning
21 Bildaufbau pro Sekunde
22 allgemein: ”Digital Content Creation”
20
6 AUSSICHTEN
Backbuffer” oder ”Realtime Fog/Blending” integriert. Direct3D hat in diesem Bereich
nicht sehr viel Einfluss, denn es ist hier langsamer als OpenGL und bedarf softwareseitig
mehr Pflege.
Ein Ende der Neuentwicklungen ist lange nicht in Sicht. Inzwischen wechseln Generation und Leistung in dieser Branche schneller als die Taktraten im Prozessorbereich.
Das Ziel wird es ständig sein, Szenen und Animationen noch schneller, plastischer und
photorealistischer zu rendern.
Zuletzt sei bemerkt, dass OpenGL und Direct3D ”nur” Schnittstellen sind, die dem
Entwickler viel Arbeit abnehmen können und den Zugriff auf die Hardware erleichtern.
Eigentliche Algorithmen zur Erstellung und Beschleunigung von Grafiken sowie die Nutzung von Techniken, die Schnittstellen und Hardware noch nicht besitzen, müssen aber
selbst implementiert werden. Da sich OpenGL und Direct3D inzwischen auf dem Markt
durchgesetzt haben, haben es Neuentwicklungen schwer. Zwischenzeitlich hatte der Graphikkartenhersteller 3DFX seine auf eigene Karten (VooDoo) zugeschnittene Schnittstelle
Glide auf dem Markt, wegen schlechtem Absatz sich aber nicht weiterentwickelt hat.
21
7 Quellen im Internet
• Benchmarks
– FOGCITY (TIRTANIUM) D3D/OPEN GL by Michael Tirtasana
∗ http://viswiz.gmd.de/ mic/prog3d.html
– 3DMark 2001
∗ http://www.madonion.com
• Offizielles
– Microsoft DirectX: Platform SDK, Overview & Documentation
∗ http://msdn.microsoft.com/library
– OpenGL Extension Specifications
∗ http://oss.sgi.com/projects/ogl-sample/registry/
– Silicon Graphics Homepage
∗ http://www.sgi.com/
– Silicon Graphics/OpenGL WWW Center
∗ http://www.sgi.com/Technology/openGL/
– Offizielle Ressourcen zu OpenGL
∗ http://www.opengl.org
• Tutorials
– Jackie Neider, Tom Davis & Mason Woo, OpenGL Programming Guide or
”The Red Book”, Addison-Wesley, 1993
∗ http://arctic.eng.iastate.edu:88/SGI Developer/OpenGL PG
– Jeff ’NeHe’ Molofee, Nehe Productions OpenGL Tutorials
∗ http://nehe.gamedev.net
• Sonstiges
– Philip Kaufmann, PE OpenGL Extensions
∗ http://www.t-online.de/home/Phil.Kaufmann/main.htm
– Informationen zu 3D-Beschleunigern
∗ http://www.cs.columbia.edu/ bm/3dcards/3d-cards1.html
22
LITERATUR
Literatur
[1] Ute Claussen, Programmieren mit OpenGL - 3D-Grafik und Bildverarbeitung,
Springer-Verlag, 1997
[2] Rob Glidden, Graphics Programming with Direct3D - Techniques and Concepts,
Addison-Wesley Developers Press, 1997
[3] Mark J. Kilgard, All About OpenGL Extensions,including specifications
for some significant OpenGL extensions, Papersheet, NVIDIA Corporation,
http://reality.sgi.com/employees/mjk asd/home.html
[4] Mark J. Kilgard, OpenGL Programming for the X Window System, Addison-Wesley,
http://reality.sgi.com/employees/mjk asd/home.html
[5] Mark J. Kilgard,
The OpenGL Utility Toolkit(GLUT)Programming
Interface
API
Version
3,
Silicon
Graphics,
Inc.,
1996,
http://reality.sgi.com/employees/mjk asd/home.html
[6] The OpenGL Machine, The OpenGL graphics system diagram, Version 1.1, Silicon
Graphics, Inc., 1996
[7] Jens-Peer Kuska, Graphik-Programmierung mit OpenGL, Juli 2000
[8] Mark J. Kilgard, The OpenGL Utility Toolkit(GLUT)Programming Interface API
Version 3, Silicon Graphics, Inc., 1996
[9] NVIDIA Corporation, NVIDIA OpenGL Extension Specifications, 2000
[10] Dr. Jürgen Döllner, Einführung in die Computergraphik, hier: Kapitel 2: Graphikprogrammierung mit OpenGL, Universität Münster, WS 2000/2001, [email protected]
[11] Dave Horne, DirectX8 Graphics Overview, Technical Developer Relations, NVidia
Corporation
[12] Richard S. Wright & Michael Sweet, OpenGL SuperBible
[13] Mark Segal & Kurt Akeley, The OpenGL Graphics System: A Specifcation (Version
1.2.1), Silicon Graphics, 1999
[14] Jackie
Neider,
Tom
Davis
&
Mason
Woo,
OpenGL
Programming Guide
or
”The
Red
Book”,
Addison-Wesley,
1993
http://arctic.eng.iastate.edu:88/SGI Developer/OpenGL PG
[15] Matthias Merz, Seminararbeit ”Spieleprogrammierung”, betreut von den
Professoren Prof. Kaufmann u. Prof. Scheer, FH Gießen Friedberg, 1999,
http://www.hausarbeiten.de/archiv/informatik/infospiele/info-spiele.shtml
[16] Manfred Bertuch: 3D-Flaschenhälse, aus: c’t, Magazin für Computertechnik, Heise
Verlag, 12/2001, S.160
[17] c’t, Magazin für Computertechnik, Heise Verlag, 09/2001, S.32