Proseminar Computergrafik: Retained Mode: Open Inventor, VRML ...

Proseminar Computergrafik:
Retained Mode: Open Inventor, VRML, Java3D
von
Detlef Köntges, MatNr: 0407155

Inhaltsverzeichnis
Einleitung 00
1 Open Inventor 01
1.1 Open Inventor Architektur 01
1.2 Szenegraph 02
1.3 Inventor Objekte 03
1.4 Event 03
1.5 Manipulatoren 03
1.6 Dateiformat 04
1.7 Komponenten 04
2 VRML 06
2.1 Geschichte 06
2.2 Anwendung 06
2.3 Szenegraph 08
2.4 Knoten und Felder 09
2.5 Sensoren und Ereignisse in VRML 10
2.6 Objekterweiterung 11
2.7 Java und Javascript 12
2.8 Wiedergabe von VRML 13
2.9 X3D 13
3 Java3D 13
3.1 Szenegraph 13
3.2 View-Teilbaum 15
3.3 Ereignisse und Interaktion 15
4 Retained Mode: Vergleich Open Inventor, VRML, Java3D 15
Literaturverzeichnis 18

Einleitung
Open Inventor, VRML und Java 3D sind 3D-Grafiksysteme, die es dem Entwickler ermöglichen, auf
einfache Art und Weise dreidimensionale Objekte zu erstellen und zu manipulieren. Ein älteres System
zur Grafikerstellung ist Open GL. Open GL bietet eine plattformunabhängige Software-Schnittstelle
zur Grafik-Hardware an.
Der Kern von Open GL besteht aus ca. 200 Funktionen, die nur zum Rendern von Grafik dienen. Die
plattformspezifischen Funktionen sind in anderen Bibliotheken enthalten. Durch diese Struktur ist ein
Programm, das für Open GL geschrieben wurde, auf den unterschiedlichsten Systemen lauffähig.
Open GL kann als eine low-level API aber nur Linien, Punkte und Polygone beschreiben. Komplexere
dreidimensionale Objekte müssen durch den Programmierer aus diesen Primitiven zusammengesetzt
werden. Auch die Verwaltung der 3D-Objekte liegt in der Verantwortung des Programmierers. Von
Vorteil ist dieser Weg bei der Lösungsoptimierung für ein spezifisches Problem, d.h. mit Open GL
steht dem Entwickler ein Höchstmaß an Flexibilität zur Verfügung, aber mit dem Nachteil des hohen
Programmieraufwands.
Grafiksysteme wie Open Inventor, VRML und Java 3D haben eine höheren Abstraktionsgrad und entsprechen
eher dem heutigen objektorientierten Ansatz. Sie nutzen die Open GL als Grundlage zur
Darstellung ihrer 3D-Objekte. Sie gestatten es dem Programmierer, auf einfachere Weise eine 3D-
Grafik zu erstellen, als dies mit Open GL möglich wäre.
Während Open GL im Immediate Mode arbeitet, können Open Inventor, VRML und Java3D den Retained
Mode verwenden. Dieses Renderingmodell beruht auf einer Szenegraphstruktur. Diese Form
des Rendering hat Vorteile, birgt aber auch einige Nachteile. Der Retained Mode wird von allen drei
high-level-Grafiksystemen unterschiedlich angegangen. Diese Ausarbeitung wird einen kleinen Einblick
in die einzelnen Programme liefern und ihre Interpretationen des Retained Mode miteinander
vergleichen.
00

1 Open Inventor
1.1 Open Inventor Architektur
Der Open Inventor wurde ursprünglich in einer C++ Version von Silicon Graphics Inc. (SGI) entwickelt
und vertrieben. Etwas später hat die Firma TGS eine Portierung nach JAVA vorgenommen.
Die auch von der SGI entwickelte Open GL wird vom Open Inventor als Rendering Maschine genutzt.
Von Open Inventor werden komplexe, graphische Objekte (Kugeln, Kegel, Quader usw.) zur Verfügung
gestellt, die aus den Primitiven der Open GL zusammengesetzt sind. Die Systemarchitektur
von Open Inventor wird im folgenden Schaubild verdeutlicht.
Abbildung 1 Systemarchitektur des Open Inventor
Der Open Inventor basiert auf dem Betriebssystem und Open GL. Er umfasst eine Reihe von Komponenten
die eine Erstellung und Verwaltung von 3D-Objekten ermöglichen. Neben den „Node Kits“ und
den Manipulatoren spielt die „Scene Database“ eine wichtige Rolle. Sie verwaltet den Scene-graphen,
auf den im weiteren genauer eingegangen wird. Auf diese Kern-API setzten wiederum einige
Komponenten auf. In der Komponentenbibliothek sind ein Szeneviewer und Editoren für Materialeigenschaften
und Beleuchtung enthalten.
01

1.2 Szenegraph
Open GL funktioniert auf dem Prinzip einer Zustandsmaschine, infolgedessen können
Transformationen und Attribute nur eine Zustand einnehmen. Diese Eigenschaft hat der Open
Inventor geerbt und das beeinflusst die Abarbeitung des Szenegraphen.
Der Szenegraph ist ein azyklischer, gerichteter Graph, in dem eine 3D-Szene gespeichert wird. Er ermöglicht
es die Position und die Orientierung von 3D-Objekten zueinander festzulegen. Die Struktur
eines solchen Graphen entspricht der eines Baumes, wobei die Knoten des Baumes die Elemente der
3D-Szene sind. Sämtliche Bestandteile einer Szene sind in den Knoten festgehalten. Neben den 3D-
Objekten werden auch Transformation, Licht, Kamera und Attribute (Textur ,Farbe ,...) in Knotenform
eingefügt. In der folgenden Abbildung ist ein einfacher Beispielgraph dargestellt.
Abbildung 2 Beispiel für Szenegraph des Open Inventor
Der Szenegraph wird zeilenweise und von links nach rechts durchlaufen, wobei jeder Knoten seine
Nachfolger beeinflusst. Im Beispielgraph wird von der Wurzel ausgehend die Betrachterposition und
die Beleuchtung des Autos bestimmt. Dann werden Farbe und Position festgelegt, die sich auf den
Knoten mit der geometrischen Beschreibung der Karosserie auswirken. Ein weiterer Knoten ändert
dann das Attribut Farbe für seine nachfolgenden Knoten, d.h. das Rad wird schwarz und erscheint
bedingt durch die Transformationsknoten an vier verschiedenen Positionen.
Beim durchlaufen (auch traversieren) der einzelnen Knoten wird ein Zustand („traversal state“) mitgeführt.
Dieser entspricht bildlich gesprochen einem Lesekopf, der den Baum durchläuft und ihn in
Open GL-Anweisungen übersetzt, welche dann vom System weiter verarbeitet werden und schließlich
auf dem Bildschirm in Form der 3D-Szene erscheinen.
02

Eine spezielle Form der Gruppenknoten ist der Separator. Beim Eintritt in den Separator-Teilbaum
wird der aktuelle Zustand gespeichert und nach Verlassen wiederhergestellt. Dabei wird verhindert,
dass Veränderungen von Attributen im Teilbaum sich auf den Rest des Szenegraphen übertragen. Im
Falle des Wurzelknotens wird nach dem Rendering der 3D-Szene der Ausgangszustand wieder
eingesetzt.
Wie das obige Beispiel zeigt, können Knoten mehrfach verwendet werden. Bei der Verknüpfung
zweier Knoten muss beachtet werden das kein Zyklus entsteht, so dass ein Knoten keine Referenz
besitzt, die über seine Kindknoten auf ihn zurück verweist. Richtig angewendet kann diese Technik
jedoch Rechzeit und Hauptspeicher sparen helfen.
1.3 Inventor Objekte
Open Inventor als Klassenbibliothek für objektorientierte Sprachen kann mittels Vererbung erweitert
werden. Diese Erweiterung von bestehenden Knoten durch Ableiten ermöglichen dem Programmierer
hohe Flexibilität und die gewohnte Übersichtlichkeit objektorientierter Programmiersprachen. Open
Inventor stellt verschiedene Grundtypen von Objekten zur Verfügung. Die Basistypen werden durch
ein „Sb“ gekennzeichnet und umfassen neben Farbe oder einfachen geometrische Strukturen
(Zylinder, Ebenen, Vektoren, ...)viele andere 3D-Grundstrukturen. Eine weitere Gruppe stellen die
Szene-Objekte dar, in der alle Knoten, Felder, Pfade, Aktionen und Events enthalten sind. Die
Elemente dieser Gruppe sind durch ein „So“ (SceneObjekt) gekennzeichnet.
Aus diesen Objekttypen kann der Programmierer entsprechend seiner Vorstellung ein 3D-Objekt
erstellen und es nach Belieben wiederverwenden.
1.4 Event
Der Inventor bietet eine Reihe von Möglichkeiten zur Selektion und Manipulation von Objekten. In
einer bestehenden Szene können etwa durch anklicken einfache Transformationen an einem Objekt
durchgeführt werden. Mit einem solchen Event wird eine erneute Traversierung des Szenegraphen
ausgelöst. Jedes Objekt im Graphen kann nun prüfen, ob der Mausklick innerhalb seiner Koordinaten
auf dem Bildschirm liegt. Ist dies der Fall, wird der Event verarbeitet und gegebenenfalls werden alle
weiteren Events an dieses Objekt weitergeleitet. Den Nutzen einer solchen Verarbeitungsstruktur
haben zum Beispiel „Handle“-Obiekte. Durch einmaliges Anklicken werden alle weiteren Mausevents
an diesen Objekttyp weitergeleitet, ohne die aufwendige Traversierung des Szenegraphen.
Events werden auf diese Art und Weise direkt und sehr schnell verarbeitet, kombiniert mit der
Funktionalität des Szenegraphen.
Ein anderer Weg ist die Definition eigener Objekte mit Call-Back-Methoden. Sind sie registriert,
werden sie bei Auftreten eines Events aufgerufen.
1.5 Manipulatoren
Die Manipulatoren sind eine Ableitung der Transformationsknoten. Sie haben eine Reihe von Kindern
in Form von Handl-Objekten. Manipulatoren sind, wenn sie im Szenegraphen integriert werden, in der
Lage Events aufzunehmen und zu verarbeiten. Visuell repräsentieren sie sich in Form kleiner Kugeln,
Linien oder Kegel. Klickt man eines dieser Manipulatorobjekte an und hält es mit der Maus fest, so
sind durch ziehen direkte Veränderungen an dem zugehörigen Objekt möglich. Der Anwender kann
die Szene intuitiv mit Manipulatoren verändern.
Der mitgelieferte Szeneviewer ermöglicht sogar eine direkte Manipulation ohne solche Knoten, da er
normale Transformationsknoten durch Manipulatoren ersetzen kann und umgekehrt.
03

1.6 Dateiformat
Der Inventor bietet Funktionen, um ganze Szenegraphen oder Teile davon in einer Datei zu speichern
und wieder auszulesen. Fügt man dem Wurzelknoten zum Beispiel die Aktion „SoWriteAction“ hinzu,
so wird der Graph automatisch in der angegebenen Datei gespeichert. Dabei kann zwischen Binär-
und ASCII-Format gewählt werden. Die Textform einer solchen Datei wird in dem folgenden Beispiel
gezeigt.
#Inventor V2.0 ascii
Separator {
DirectionalLigth{}
Cube {
width 1
height 2
depth 3
}
}
Der Kopf beschreibt die genaue Version des Formats. Der Graph beginnt mit einem Separatorknoten
in der Wurzel. Die Schachtelung der Knoten entspricht der Baumstruktur des Szenegraphen. Zu
jedem Knoten wird eine Liste von Feldern gespeichert, die von den Default-Werten des Knotentyps
abweichen.
1.7 Komponenten
Zur Erleichterung der Entwicklungsarbeit stellt der Inventor eine Reihe von Komponenten zur
Verfügung. Neben dem Szeneviewer stehen auch verschiedene Editoren zur Auswahl. Von diesen
Tools können wieder Subklassen gebildet werden um eigene spezifische Anwendungen zu erstellen.
Die folgenden Bilder zeigen den Viewer und einige Editoren.
Abbildung 3 Viewer für Open Inventor
04

Abbildung 4
Abbildung 5
05

2 VRML
2.1 Geschichte
Auf der ersten internationalen Konferenz über das World Wide Web in Genf (Mai 1994) wurde eine
Sitzung zum Thema „Virtual Reality Markup Language“ abgehalten. Dort wurden die Vorstellungen
über einen plattform-unabhängigen 3D-Standard geformt und der Begriff VRML geprägt. Später ist
das Wort Markup durch Modelling ersetzt worden. Die Grundlage des Kerns von VRML wurde das
Dateiformat des Open Inventors, nachdem Silicon Graphics Inc. (SGI) einen Teil des Dateiformates
freigab, und bereits auf der zweiten WWW-Konferenz (Oktober 1994) konnte man VRML 1.0
präsentieren. Weitere Diskussionen fanden auf der Tagung SIGGRAPH 95 statt. Ausgehend von
dieser Messe wurde der Aufruf an alle Interessenten gestellt, an der Weiterentwicklung mitzuarbeiten.
Um die Vorschläge aus dem Internet zu sammeln und zu artikulieren, gründete sich zwei Wochen
nach der Tagung die „VRML Architecture Group“, kurz VAG. Aus der VAG hat sich inzwischen das
WEB3D-Konsortium gebildet. Nach der Entwicklung von VRML 1.0 begannen Planungen für die 1.1
Version, welche aber von dem öffentlichen Aufruf der VAG im Jahr 1996 überholt wurden. Demnach
sollten Vorschläge für VRML 2.0 eingereicht werden. Nach einer Abstimmung im Internet wurde der
Vorschlag der SGI ausgewählt, der unter der Bezeichnung „Moving Worlds“ bekannt ist. Auf der
SIGGRAPH 96 wurde dann VRML 2.0 vorgestellt. Nach weiteren Bemühungen wurde VRML auch als
ISO - und IEC-Standard genehmigt und dann in VRML97 umbenannt.
VRML 2.0 ist im wesentlichen ein Dateiformat zur Beschreibung von 3D-Szenen. Neben den Objekten
werden auch Bilder, Töne und sogar Filme, die zu Darstellung einer 3D-Szene hilfreich sind,
verwendbar. Es können Wechselwirkungen und Veränderungen zwischen Objekten beschrieben
werden. Der Inhalt einer VRML-Datei besteht aus lesbarem Text, wobei unterschiedliche Zeichensätze
Verwendung finden. Mit VRML 1.0 wurde nur ASCII unterstützt, jedoch mit VRML 2.0 ist auch der
Standard „Universal Coded Character Set Transformation Format“ (kurz UTF-8) verwendbar. Die erste
Zeile einer VRML-Datei enthält wie Open Inventor die Versionsbezeichnung und den verwendeten
Zeichensatz. Bei VRML entspricht dies einer Codierung der Form:
#VRML V2.0 utf8
Das Zeichen „#“ hat die Funktion, einen Kommentar einzuleiten. Bei sehr umfangreichen 3D-Szenen
kann diese Form der Codierung zu sehr großen Dateien führen. Um den Speicherbedarf zu senken,
stehen verschiedene Optionen zur Auswahl. Neben Dateien die in GZIP verpackt werden, steht auch
die Konvertierung in Binärdateien zu Verfügung. Einige VRML-Browser können diese Formate direkt
verarbeiten.
2.2 Anwendung
Das Internet als weltweites Informationssystem stellt primär Hypertextdokumente bereit. Die
Verknüpfung dieser Texte mit Grafik, Sound und Video machen das Internet zum hypermedialen
Informationssystem. Um das System nutzen zu können, werden verschiedene Browser eingesetzt. Sie
ermöglichen durch ihre Erweiterbarkeit die Integration von Programmen, die verschiedene
Dateiformate erst für den Anwender verwendbar machen. Zu solchen als „Plug-ins“ oder „ActiveX
Controls“ bezeichneten Erweiterungen zählen auch VRML-Viewer. Natürlich existieren auch
eigenständige Viewer. Ein solch ausgestatteter Internet-Browser kann ein Dokument im VRML-Format
wiedergeben, welches von einem Internet-Server bereitgestellt wird.
Mit VRML können sowohl einfache 3D-Objekte als auch komplexe 3D-Szenen beschrieben werden.
Zum Teil dienen VRML-Formate dazu, ganze 3D-Welten zu erschaffen. Eine Beispiel aus dem
Internet bietet die folgende Grafik.
06

Abbildung 6 von immersive SIM engineering
So dargestellte Objekte können von jedem Internetteilnehmer betrachtet werden. Dieser benötigt
lediglich einen VRML-Browser für die Darstellung. Eine Firma kann so über das Internet eine breite
Kundschaft ansprechen und ihr Produkt vorstellen, selbst wenn das Objekt real noch nicht existiert.
Vorstellbar sind auch Architektur-Projekte, die im Internet nach Finanzierung suchen. Das Gebäude
kann mittels VRML in einer 3D-Darstellung angeboten werden. Jeder hat die Möglichkeit, sich bereits
ein Bild von dem Gebäude zu machen, bevor auch nur ein Stein gesetzt wurde. Man kann von seinem
Büro aus über den Internet-Browser schnell und kostengünstig mehrere Projekte betrachten.
Eine weitere Einsatzmöglichkeit ist bei der Nutzung einer Datenbank gegeben. Durch eine virtuelle
Nachbildung einer Bibliothek realisiert, könnten einzelne Bücher Links auf Datenpakete enthalten.
Neben der kommerziellen Nutzung haben auch andere Bereiche ein Interesse an VRML. In der
Forschung ist die 3D-Darstellung von Molekülen sehr verbreitet. Einige interessante Darstellungen
geben folgende Bilder wieder.
Abbildung 7 Moleküle: Kristallgitter, H20, Ethanol
Die Darstellungsfähigkeit und Funktionalität eines VRML-Browsers ermöglicht die Manipulation der
Szene durch Drehen und Bewegen der Betrachterposition in jeden beliebigen Standpunkt und erzeugt
so ein 3D-Gefühl für den Anwender.
07

Aufgrund der Plattformunabhängigkeit bietet sich VRML für die Realisierung virtueller Welten im
Internet an, in denen sich viele Menschen in Form von Avataren repräsentieren, begegnen und
austauschen können.
VRML bietet durch seine Einfachheit auch Personen ohne Programmierkenntnissen die Möglichkeit
zur Erstellung virtueller 3D-Welten.
2.3 Szenegraph
Wie bereits erwähnt hat VRML das Dateiformat von Open Inventor übernommen. VMRL verwendet
ebenfalls die Struktur des Szenegraphen mit Knoten und Feldern. Der wichtigste Unterschied liegt in
der Traversierung des Graphen. Während Open Inventor einen fest vorgeschriebenen Durchlauf hat,
ist in der Spezifikation von VRML jedoch keine Traversierung vorgesehen. Man kann aber davon ausgehen,
dass viele VRML-Browser eine ähnliche Traversierung wie Open Inventor vornehmen. Bedingt
durch eine fehlende Vorschrift für eine Traversierung müssen für jedes Objekt die Eigenschaften neu
gesetzt werden bzw. mit den Standardwerten besetzt werden.
In der Baumstruktur werden im Vergleich zu Open Inventor die Eigenschaften mehr gekapselt. Die
folgende Darstellung zeigt einen Szenegraphen, wie er von VRML genutzt wird. Die Eigenschaften
einer Kugel sind in diesem Beispiel in einem Teilbaum zusammengefasst. Weiterhin wird die
Wiederverwendung eines Objektes durch eine „USE“-Anweisung dargestellt, worauf im folgenden
noch genauer eingegangen wird.
Abbildung 8 Szenegraph von VRML
08

2.4 Knoten und Felder
Knoten beschreiben in VRML die 3D-Objekte, wobei sich die Knoten in Gruppenknoten oder Blattknoten
unterteilen lassen. Erstere können wiederum Gruppenknoten oder Blattknoten als Kinder in
beliebiger Anzahl enthalten. Blattknoten können zwar keine Kinderknoten aber untergeordnete Knoten
besitzen, zu denen Knoten wie Materialeigenschaft oder die geometrischen Knoten gehören. So wäre
ein Knoten für einen Quader vom Typ „Box“, und seine Knoten für Oberflächeneigenschaft vom Typ
Material. Die untergeordneten Knoten können nicht als eigenständige Blattknoten verwendet werden.
Ein Knoten besteht aus einem oder mehreren Feldern, die den Zustand des Knotens beschreiben. So
würde einen Knoten, der mit dem Knotentyp „Sphere“ vereinbart wurde, eine Kugel ergeben. Mit dem
folgendem Programmcode entsteht dabei eine Kugel mit dem Radius 2.
Sphere { radius 2 }
Felder werden in geschweifte Klammern eingeschlossen, und im Falle von mehreren Eigenschaften
werden die Felder untereinander geschrieben. Die Feldtypen sind wie in Open Inventor einfache
Basistypen, zum Beispiel Vektoren, boolesche Werte u.a..
Die Wiederverwendung von Knoten in Open Inventor ist auch in VRML übernommen worden. Um
einen Knoten erneut zu nutzen, muss er mit DEF benannt und an anderer Stelle mit USE und seinem
Namen wieder angesprochen werden. Es wird dabei keine Kopie sondern eine Referenz angelegt.
Im anschließenden Programm wird eine Pyramide beschrieben. Mit diesem relativ einfachen Beispiel
werden die Struktur einer VRML-Datei und die Anwendung einiger Knoten deutlich.
#VRML V2.0 utf8
Transform { # lokales Koordinatensystem für alle
children [ # Kindknoten
DirectionalLight{}, # Lichtstrahlen parallel und eine Richtung
Shape { # Knoten zur Beschreibung sichtbarer Objekte
geometry IndexedFaceSet { # Knoten um Polygone zu beschreiben
coord Coordinate { # Knoten der Eckpunkte der Polygone enthält
point [
1 0 0 # Punkt 0
0 0 1 # Punkt 1
-1 0 0 # Punkt 3
0 0 -1 # Punkt 4
0 1.5 0 # Punkt 5
]
}
coordIndex [ # Vereinbarung der Polygone,
0,1,2,3,0,-1, # Grundfläche
1,0,4,1,-1, # Seite aus Punkt 1, Punkt 0 usw.
2,1,4,2,-1, # Seite, Wert -1 trennt die einzelnen Polygone
3,2,4,3,-1, # Seite
0,3,4,0,-1 # Seite
]
}
appearance Appearance { # Knoten beschreibt das Aussehen
material Material { # Knoten für Materialeigenschaft (Werte 0-1)
diffuseColor 0.1 0.1 0.1 # Farbe in RGB für Reflexion, helles grau
shininess 0.6 # Glanzwert
specularColor 0.8 0.8 0.8 # Reflexionskoeffizient für Spiegelung
transparency 0.5 # Transmissionskoeffizient für Transparenz
}}}]}
Background { # Knoten für Hintergrundeigenschaften
skyColor [ 1 1 1 ] # Farbe des Himmels in RGB. weiß
}
09

Das Ergebnis dieser Programmzeilen wird im nächsten Bild gezeigt.
2.5 Sensoren und Ereignisse in VRML
Abbildung 9
Ereignisse dienen in VRML der Kommunikation der Knoten untereinander. Die Knoten besitzen dazu
spezielle Felder, die das Ereignis aufnehmen oder abschicken können. Durch ROUTE werden zwei
Knoten über die entsprechenden Felder verbunden.
Die gesamte Interaktion wird komplett über Sensoren gesteuert, die in VRML eingebaute Konstrukte
für Animation und Interaktion sind. Sensorenknoten erzeugen Ereignisse, welche die Animation oder
Interaktion steuern. Diese Knoten werden mit sogenannten Interpolatoren verbunden, die vom
Entwickler vorher festgelegte Zwischenwerte enthalten. Diese vorgefertigte Variante reicht für einfache
Animationen aus, komplexere Abläufe sind jedoch nur mit Hilfe von Scriptknoten oder über EAI
realisierbar. Der Scriptknoten nimmt dabei die Position des Interpolator-Knotens ein. Sobald der
Sensorknoten ein Ereignis sendet, berechnet der Scriptknoten den neuen Wert und reicht ihn zum
Beispiel an einen Knoten weiter, der ein geometrisches Objekt beschreibt. Dies kann dann zur
Veränderung der Größe oder Farbe des Objektes führen, es kann aber auch eine Animation mit
nichtlinearer Berechnung von Positionswerten generiert werden.
VRML bietet verschiedene Sensoren an, um Ereignisse zu erzeugen. Neben einem „TimeSensor“ gibt
es Sensoren, die auf die Auswahl eines Objektes mit der Maus reagieren. Dabei unterscheidet man
Sensorentypen für Auswahl (TouchSensor, Anchor) und Objektinteraktion (CylinderSensor, Plane-
Sensor und SphereSensor). Weitere Funktionalität muss dann wiederum über Scriptknoten geregelt
werden.
Ein einfaches Beispiel für einen Sensor zeigt das folgende Programm.
10

#VRML V2.0 utf8
DEF Licht PointLight{ # definiert eine Punktlichtquelle
location 0 0 2 # Positionsfeld, 3D-Vektor
on FALSE
}
Transform{
children [
Shape{
geometry Box {} # ein Würfel
appearance Appearance {
material Material {
diffuseColor 0 0 1 # Farbe blau
}
}
}
DEF Schalter TouchSensor {} # Schalterdefinition und damit
] # mehrfachverwendbar
}
ROUTE Schalter.isActive TO Licht.on # Anweisung Würfel angeklickt dann
# Licht an
Das Beispiel beschreibt eine Szene mit einem blauen Würfel und einer Lichtquelle. Wenn der Würfel
angeklickt wird, aktiviert der Sensor über die ROUTE-Anweisung das Licht. Nach dem der Würfel losgelassen
wird, ändert sich der Zustand der Lichtquelle wieder auf den Ausgangswert.
2.6 Objekterweiterung
Abbildung 10 als Graustufenbild, Sensorenbeispiel für Werte TRUE und FALSE
Um in VRML Knotentypen zu erweitern, werden sogenannte Prototypen definiert. Sie enthalten eine
eigenständige Szene auf Basis der bestehenden Knotentypen, Routen oder anderer Prototypen. Sie
können eine Schnittstelle nach außen besitzen, über die der Prototyp angepasst werden kann. Das
folgende Beispiel enthält einen solchen Prototypen
11

#VRML V2.0 utf8
PROTO Beispielform [ # Definition Prototyp
exposedField SFVec3f trans 0 0 0 # SingleField, besitzt nur einen
# Wert
exposedField SFColor color .2 .2 .2 # MultipleField, mehrere Werte
# besitzen
exposedField SFNode form NULL # geometrischer Knoten leer bis
] # zum Aufruf
{
Transform {
translation IS trans # Position beliebig an
children [ # Aufrufstelle zu vereinbaren
Shape {
geometry IS form
appearance Appearance {
material Material {
diffuseColor IS color
}
}
}
]
}
}
Beispielform { # Erzeugung eines Objektes
color 0 0 1
trans 3 –3 0
form Box {}
}
Durch externe Prototypen kann sogar über die Dateigrenzen hinweg ein Szenegraph einer anderen
Datei genutzt werden. Da VRML keine Programmiersprache sondern nur ein Dateiformat darstellt, ist
die Vererbung nicht möglich. Eigenschaften oder Verhaltensweisen eines Prototyps können nicht
direkt von anderen Prototypen weiterverwendet werden.
2.7 Java und Javascript
Wie bereits erwähnt sind Knoten verfügbar, die ein Script enthalten, d.h. der Knoten kann ein compiliertes
Programm nutzen. Solche Scriptknoten können zur Lösung verschiedener Aufgaben genutzt
werden. Die Kommunikation mit Servern über TCP/IP-Protokolle kann durch Scriptknoten erfolgen,
oder es werden weitere Szenen geladen und in die gegebene Szenen eingefügt. Diese Knoten
können Werte von Zuständen speichern oder umfangreiche Berechnungen durchführen, unter
anderem aber auch Ereignisse empfangen, verarbeiten und wieder versenden. Scriptknoten
kommunizieren über bestimmte Felder mit VRML und können so den Szenegraphen direkt
manipulieren. Nachteil ist die steigende Unübersichtlichkeit bei wachsender Scriptknotenzahl.
Ein weiteres Konzept, um VRML zu manipulieren, ist „External Authoring Interface“ (kurz EAI). Durch
EAI lässt sich VRML umfassend erweitern. Durch eine definierte Schnittstelle kann ein Applet den
Szenegraphen verändern oder durch Registrieren einer Callback-Methode Ereignisse der VRML-Welt
empfangen. Mit dieser Erweiterung ist die Erschaffung von virtuellen Multiuserwelten im Internet erst
möglich. Während VRML die 3D-Szene darstellt, stellt ein Java-Applet die Netzwerkfunktionalität
bereit.
12

2.8 Wiedergabe von VRML
Da VRML kein eigenständiges Programm ist, sondern nur ein Dateiformat, sind sogenannte Viewer
erforderlich, die dieses Format auswerten und darstellen können. Es existieren mehrere Lösungen zur
Darstellung von VRML-Dateien. So gibt es neben externen Viewern und eigenständigen VRML-Browsern
auch Programmerweiterungen für Internet-Browser. Eine weiterer Weg ist die Regelung der Darstellung
über ein Java-Applet.
Ein externer Viewer stellt ein Programm dar, das von einem Internet-Browser bei Bedarf aufgerufen
werden kann, wird aber unabhängig vom Internet-Browser installiert. Die Erweiterungen für Internet-
Browser werden von einigen Anbietern im Internet frei angeboten. Einige Internetseiten von
Herstellern solcher Programme sind im Linkverzeichnis dieser Arbeit angegeben.
Jeder dieser Viewer ermöglicht dem Anwender durch verschiedene Werkzeuge eine komfortable
Betrachtungsmöglichkeit seiner Szene. Mit Hilfe der Maus kann die Szene gedreht, verschoben und
zum Teil sogar inhaltlich verändert werden.
VRML-Builder ermöglichen hingegen neben der Funktionalität eines Viewers, die Szene selbst zu
erstellen und zu manipulieren, wobei eine interessantere Variante darin besteht, eine Szene mit 3D-
Modellierungsprogramm oder CAD-Programm zu erstellen und sie anschließend in VRML zu konvertieren.
2.9 X3D
Der aktuelle Stand der VRML-Entwicklung ist X3D (Extensible 3D). Die neue Variante ist der
Nachfolger von VRML97, welche sich nicht wie erhofft im Internet durchsetzten konnte und noch
einige Mängel aufwies. So wird eine Datei in unterschiedlich VRML-Viewern teilweise unterschiedlich
dargestellt. Ein weiterer Aspekt ist das Fehlen eines Binärformats, um eine VRML-Datei komprimieren
zu können. Solche und andere Gründe führten zur Weiterentwicklung von VRML, in der auch auf XML
zurückgegriffen wurde, um zukünftig die Szenen zu beschreiben.
3 Java3D
Java3D ist ein Klassenbibliothek für Java, um in Applets oder Applikationen 3D-Grafik zu verwenden.
Wie auch in Open Inventor und VRML können einzelne Objekte oder ganze virtuelle Welten
erschaffen werden. Bei der Entwicklung von Java3D wurde auf bereits bestehende Konzepte von low-
und high-level Grafiksystemen zurückgegriffen. Dabei wurde auch die Nutzung von 3D-Peripherie-
Geräten berücksichtigt. Java3D stellt damit eine sehr mächtige Klasse zur Verfügung, die es auf
einfache Art und Weise ermöglicht, 3D-Grafik zu erstellen. Es werden vom Anwender keine
umfassenden Kenntnisse über dreidimensionale Grafik vorrausgesetzt, wie es bei Open GL der Fall
ist. Die Entwicklung von Java3D begann 1996 in einer Gruppe von Firmen mit dem Zweck, eine
plattformübergreifende und effiziente API zu entwerfen. Die Unternehmen Intel, Sun und SGI sahen
das Haupteinsatzgebiet in der Realisierung von Internet-Visualisierungs-Anwendungen. Nach
eineinhalb Jahren wurde die erste endgültige Spezifikation vorgestellt.
3.1 Szenegraph
Der Szenegraph von Java3D ist wie auch in VRML und Open Inventor ein azyklischer, gerichteter
Graph. Jedoch gibt es einige Unterschiede im Aufbau des Graphen.
Die Knoten sind Java Objekte, die in der Baumstruktur angeordnet sind. Solch ein Graph oder
mehrere dieser Strukturen können einem sogenannten virtuellen Universum hinzugefügt werden. Die
Anordnung der Knoten bestimmt, wie und wo ein 3D-Objekt dargestellt wird, oder wie der Benutzer mit
ihnen interagieren kann. Eine Verbindung zwischen zwei Knoten stellt dabei immer eine Vater-Kind-
Beziehung dar, d.h. der Zustand eines Kindknoten definiert sich durch die Knoten auf direktem Pfad
zwischen Kind und der Wurzel, während etwa in Open Inventor ein Knoten links oben alle Knoten
rechts unterhalb seiner Position beeinflussen kann.
13

Es können in Java3D Teilgraphen wiederverwendet werden, was die Implementierung etwas
erleichtert. Ein Weg ist, dass sich verschiedene Szenegraphen einen gemeinsamen Unterbaum teilen,
oder ein großer Teil der Knotenstruktur wird geklont, und nur Texturen und Geometrien werden gemeinsam
genutzt, wobei Veränderungen an allen gemeinsam benutzten Bestandteilen entsprechend
alle beteiligten Szenegraphen beeinflussen. Da keine zwei Referenzen auf einen Knoten verweisen
können, wird die Wiederverwendung ganzer Teilbäume mit speziellen Linkknoten ermöglicht. Der in
der folgende Darstellung gezeigte Szenegraph ist eine einfache Variante einer Szenegraphstruktur,
wie sie Java3D vorkommt.
Abbildung 11 Beispiel eines Szenegraph von Java3D
Die Objekte (Knoten) lassen sich in Java3D in drei Gruppen einteilen. Die erste Gruppe bilden Knoten,
die dem Szenegraphen übergeordnet sind, in einer zweiten sind alle Knoten enthalten, die für
Darstellung, Positionierung und Interaktion verwendet werden. Eine dritte umfasst die Elemente, die
den Betrachter der virtuellen Welt beschreiben. Die wichtigsten Knoten werden in der folgenden
Aufzählung kurz erklärt.
VirtualUniverse: Dieser Knoten stellt die Wurzel eines Szenegraphen in Java3D dar, welche der
Strukturierung der einzelnen Teilgraphen dient. Kinder des VirtualUniverse-Knotens müssen immer
Locale-Knoten sein. Es ist möglich, in einer Anwendung mehr als ein virtuelles Universum zu
definieren, sie sind jedoch völlig unabhängig voneinander, d.h. es ist keine Interaktion zwischen
beiden möglich.
Locale: Mit diesem Objekt können Teilgraphen innerhalb eines virtuellen Universums zugeordnet
werden. Ein „Locale“ kann ein Universum mit sehr großen räumlichen Ausdehnungen erschaffen. Ihm
werden alle anderen Objekte zugeordnet. Ihre Position wird nur mit Gleitkommazahlen relativ zu dem
zugehörigem „Locale“ angeben.
SceneGraphObject: Dies ist die Basisklasse für die eigentlichen Szenegraphkomponenten, während
„Locale“ und „VirtualUniverse“ keine Subklassen dieses Typs sind. Szenegraphobjekte werden zu
einem Graphen zusammengesetzt und mittels eines Locale-Knoten in ein virtuelles Universum
eingebunden. Die Basisklassen werden von den Klassen „Node“ und „NodeComponet“ erweitert.
Node: Node dient als Basisklasse für alle Java3D-Knoten. Diese werden in Blattknoten und Gruppenknoten
unterteilt. Gruppenknoten können je nach Typ ihre Kinder auf spezielle Art und Weise gruppieren.
Blattknoten können keine Kindknoten besitzen. Sie repräsentieren die Objekte, die Java3D
wirklich darstellt, welche neben geometrischen Objekten auch Licht oder Ton sein können.
14

NodeComponent: Knotenkomponenten können nicht wie normale Knoten eine Vater-Kind-Beziehung
eingehen, sondern dienen der genaueren Definition der Knoten, von denen sie referenziert werden.
Während Knoten nur ein Elternteil besitzen können, kann eine Knotenkomponente von mehreren
Knoten angesprochen werden.
3.2 View-Teilbaum
Eine Neuerung, die mit Java3D umgesetzt wurde, findet man im View-Modell. Mit dem neuen Modell
kann die Szene des selben Szenegraphen entsprechend dem Ausgabegerät gerendert werden. Selbst
wenn sich die Ausgabegräte physikalisch stark unterscheiden, ist die richtige Darstellung möglich.
Diese Vielseitigkeit wird erreicht über die Trennung von virtueller und physikalischer Welt. Java3D
definiert einen Zusammenhang zwischen diesen beiden Welten, der bestimmt, wie der User Objekte in
der virtuellen Welt manipulieren kann, und wie Aktivitäten der virtuellen Objekte die Darstellung der
Szene für den User verändern. Der Benutzer existiert dabei in beiden Welten. Er hat eine Position und
eine Orientierung in der virtuellen Welt. Ebenso haben er und seine Ausgabengeräte eine Position
und Orientierung in der realen Welt.
Der Szenegraph repräsentiert dieses Modell in einem speziellen Teilbaum. Der ViewPlatform-Knoten
ist ein Bestandteil dieses Teilgraphen. In ihm sind Position, Orientierung und Skalierung des Betrachters
in einer 3D-Szene festgehalten.
3.3 Ereignisse und Interaktion
Die zentrale Klasse für die Realisierung von Interaktion, Animation und Kollisionserkennung ist die
Behavior-Klasse. Die Behavior-Knoten werden „wach“, sobald ein bestimmtes Ereignis eintritt. Diese
verändern dann mit einer speziellen Methode den Szenegraphen oder ermitteln z.B. selektierte
Objekte. Ereignisse, die durch den Benutzer ausgelöst wurden, der Ablauf einer gewissen Zeitspanne
und andere Kriterien dienen als Aufwachkriterien.
Die Behavior-Klasse unterstützt des weiteren die Auswahl von Objekten. Dies geschieht über die Definition
eines eigenen Behavior-Objekts, das sich für den Empfang von einfachen Fenster-Events registriert.
Mit Hilfe der Methode processStimulus() kann dann das ausgewählte Objekt ermittelt werden. Da
es auch möglich ist, den Pfad des Objekts vom Locale bis zu seiner Position zu bestimmen, kann
nach dem Auswählen auch seine Position und Orientierung in der virtuellen Welt verändert werden. Es
existieren auch drei vorgefertigte „Picking“-Klassen, die dem Entwickler die Arbeit mit der Auswahl von
Objekten sehr vereinfachen.
4 Retained Mode: Vergleich Open Inventor, VRML, Java3D
Das Rendering ist ein optische Auswertung eines dreidimensionalen Modells. Es gibt verschiedene
Renderingmodi mit entsprechend unterschiedlichen Modellen als Grundlage. Der Immediate Mode
zum sofortigen Zeichnen wird von Open GL angeboten. Der Retained Mode setzt die Szenegraphstruktur
voraus, in dem aber alle Objekte modifiziert werden können. Wesentlicher Unterschied der
beiden Modi liegt in der Übersicht über die 3D-Szene. Dabei ist der Überblick des Programmierers genauso
von Bedeutung wie der des Systems. Dies äußert sich in der Flexibilität bei der Darstellung und
Manipulation der 3D-Szene und in der Ausführungsgeschwindigkeit. Das System ist in der Lage, die
Teile des Szenegraphen, die sich nicht ändern, beizubehalten und die Neuberechnung auf die
veränderten Teilbäume zu beschränken.
15

Der vorangegangene Teil der Arbeit zeigt bereits, welche Unterschiede die einzelnen Grafiksysteme
bei der Verwaltung und Manipulation von 3D-Szenen haben. Die Open GL hat dagegen keine vergleichbare
Struktur wie den Szenegraphen, sondern bietet in erster Linie den Immediate Mode, der
keine einschränkenden Datentypen und Verwaltungsstrukturen verlangt. Das hat zur Folge, dass der
Programmcode selbst bei einfachen dreidimensionalen Strukturen sehr komplex werden kann. Es
können in Open GL sehr viele variable Datenstrukturen verwendet werden, und der Entwickler hat
volle Kontrolle über das Rendering. Jedoch hat diese Flexibilität ihren Preis in Form eines hohen Programmieraufwands
und der Voraussetzung umfangreichen Wissens über Open GL auf der Seite des
Entwicklers. Die Hersteller haben Open GL gerade unter einer solchen Zielsetzung entwickelt und
Open GL als erweiterbare Grundlage für andere 3D-Grafiksysteme geplant. Open Inventor, VRML und
Java3D verwenden Open GL als Renderingmaschine. Sie ermöglichen durch eine abstraktere
Umgebung die einfache Erstellung und Manipulation von 3D-Szenen. Basierend auf der Szenegraphstruktur
kann der Entwickler schneller und einfacher eine virtuelle Welt erschaffen und greift dabei auf
eine fertige Ereignisbehandlung oder vorgegebene geometrische Objekte zurück.
Im Modell, das vom Retained Mode vorausgesetzt wird, liegen wesentliche Unterschiede der drei Grafiksysteme.
Diese beginnen mit der Auswertung des Szenegraphen, die Open Inventor von links oben
beginnend nach rechts unten durchführt. Der Zustand, der dabei mitgeführt wird, ändert sich von
Knoten zu Knoten. Diese Abhängigkeit der Nachfolgerknoten von ihrem Vorgänger ist in VRML nur
teilweise übernommen worden. Da die Traversierung in einem VRML-Szenegraphen nicht strikt
vorgeschrieben ist, sind die Abhängigkeiten zwischen den Knoten nicht so stark wie in Open Inventor.
In VRML werden Eigenschaften für ein Objekt gekapselt, d.h. einer geometrischen Struktur werden
ihre Eigenschaften in den Kinderknoten zugeordnet, während in Open Inventor eine Eigenschaft durch
den Vorgänger bestimmt wird. Der Java3D-Renderer kann dagegen den Szenegraphen in beliebiger
Reihenfolge durchlaufen oder ihn auch parallel verarbeiten, was erst die Eigenschaften einer
objektorientierten Programmiersprache ermöglichen.
In VRML und Open Inventor ist es Knoten erlaubt, mehrere Elternteile zu besitzen, wodurch die
Wiederverwendung von Knoten oder ganzen Teilbäumen erleichtert wird. Die einzige Einschränkung
besteht darin, dass kein Zyklus im Szenegraphen auftreten darf. Java3D benötigt für die Mehrfachreferenzierung
einen speziellen Linkknoten.
Eine Struktur, wie sie der Retained Mode voraussetzt, ist unerlässlich bei der Erstellung von Animationen.
Der Szenegraph kann das Rendern einer Animationsszene effizienter gestalten. Außerdem
wird durch die Anordnung der Knoten im Graphen die Lage der 3D-Objekte zueinander beschrieben.
Somit werden Kollisionserkennung und die Zuordnung von Ereignissen an bestimmte Objekte möglich.
Für gewöhnlich nehmen Animationen viel Rechenzeit in Anspruch. Mit steigender Zahl von Animationen
steigt auch die Gefahr, dass sie nicht mehr flüssig dargestellt werden können. Da sich der
Betrachter jedoch an einem bestimmten Punkt in der Szene befindet, stellt sich die Frage, welche Animation
wirklich berechnet werden muss, und wie detailgetreu weit entfernte Objekte sein müssen.
Somit ist entscheidend, wo sich der Betrachter befindet und welche Orientierung er hat. Java3D bietet
das Behavior-Konzept an, welches es ermöglicht, je nach Betrachterposition oder Orientierung
bestimmte Bereiche in Ruhezustand zu versetzen. Dies verschafft dem Anwender eine einfach
anzuwendende Möglichkeit, die Zahl der Animationen, die tatsächlich berechnet werden, zu
minimieren. VRML bietet dem Entwickler zwei spezielle Knoten an, um nicht benötigte Bereiche und
Animationen abzuschalten. Der Sensor ProximitySensor sendet Ereignisse, wenn der Betrachter
einen bestimmten Bereich betritt, ein weiterer Sensor sendet Ereignisse aus, wenn ein quaderförmiger
Bereich in das Sichtfeld kommt (VisbilitySensor). Verbunden mit einem Interpolator kann das Ereignis
das Ab- und Anschalten einer Animation auslösen. Damit ermöglicht die Szenegraphstruktur die
Bereitstellung einer einfach anzuwendenden und effektiven Steuerung von Animation.
Durch die Abgrenzung von 3D-Darstellern, die in der Struktur des Szenegraphen vorgenommen wird,
ist die Selektion von Objekten im Retained Mode recht einfach umzusetzen. Wie bereits beschrieben
haben alle drei Grafiksysteme mehr oder weniger abstrakte Lösungen für dieses Problem.
16

Manchmal ist es notwendig, auf das zugrundeliegende Renderingsystem zurückzugehen. Der Eingriff
in den Renderingprozess wird im Retained Mode der drei Grafiksysteme sehr unterschiedlich gehandhabt.
In Open Inventor ist es erlaubt, die Darstellung des Szenegraphen mit Open GL-Anweisungen
zu vermischen. Da für Java3D und VRML das zugrundeliegende Renderingsystem nicht unbedingt
Open GL ist, können sie keinen Rückgriff vornehmen. Die Portabilität der Systeme stand bei ihrer Entwicklung
im Vordergrund, damit auch andere Grafikpakete wie DirectX als Renderingmaschinen
genutzt werden können. Java3D bietet jedoch auch einen Immediate Mode, in dem die
Szenegraphstruktur verlassen werden kann. Die Klasse GraphicsContext3D wird verwendet, um eine
Szene im Immediate Mode unter Java3D zu realisieren. Diese Klasse ist wie Open GL eine Zustandsmaschine.
Es gibt zwei verschiedene Möglichkeiten, den Immediate Mode umzusetzen. Im Pure
Immediate Mode wird nur noch ein minimaler Szenegraph verwendet, und der Anwender ist
vollständig für das Rendering verantwortlich. Die Verwaltung liegt vollständig in den Händen des
Entwicklers, er kann aber die Java 3D-Objekte und Attribute nutzen. Das Mixed Mode Rendering ist
eine Zwischenstufe des Immediate Mode und des Retained Mode. In ihm läuft der Renderer
automatisch und stellt den Szenegraphen dar. Die Applikation muss von der Klasse Canvas3D
abgeleitet werden, kann dann aber an mehreren vordefinierten Stellen durch Überschreiben
bestimmter Methoden Immediate Mode Objekte darstellen. Ein weiter Renderingmodus ist der
Compiled Retained Mode, welcher ermöglicht, dass ein Teil des Szenegraphen kompiliert wird. Damit
ist Java3D in der Lage, intern Optimierungen vorzunehmen. Dadurch erhält man zwar eine erhöhte
Ausführungsgeschwindigkeit, was jedoch zu Lasten der Flexibilität geht.
17

Literaturverzeichnis
[1] Hans-Lothar Hase,
„Dynamische virtuelle Welten mit VRML 2.0“
Heidelberg: dpunkt, Verlag für digitale Technologie, 1. Auflage 1997
ISBN 3-920993-63-2,
[2] http://www.th.physik.uni-frankfurt.de/~maruhn/html/inventor.html
Bildbeispiel für Open Inventor
[3] http://www.cs.fsu.edu/~grant/projects/3dgrapher/images/mateditor.jpg
Bildbeispiel für MaterialEditor
[4] http://vlado.fmf.uni-lj.si/vrml/dsi.96/defengl.htm
Beispiele für VRML
[5] http://emsh.calarts.edu/~mathart/sw/objView/thicken.html
[6] http://www.uni-koeln.de/ew-fak/Chemie/VRML_Beispiele.htm
[7] http://www.web3d.org/
[8] http://www.blaxxun.com/
Viewer für die VRML-Beispiele
[9] www.sun.com
[10] www.tgs.com
[11] www.j3d.org
[12] http://www.debacher.de/vrml/
[13] http://www.immersive-sim.de/, Abbildung 6
18