05.08.2013 Aufrufe

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

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

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

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!