Java3D API vs. VRML |
Abstrakt |
Grundlagen der Java3D API |
Konzept |
Vorteile |
Grafikprogrammierung und Java3D |
Grundlagen |
Punkte |
Manipulation von Punkten |
Anordnen von Objekten |
Darstellung |
Kamera |
Umsetzung in Java3D |
Java3D Baumstruktur |
Knotentypen |
Die Baumwurzel |
Group Nodes |
Leaf Nodes |
Darstellen von Objekten |
Definition von Objekten |
Shape3D Knoten |
Viewing Objects |
Interaktion |
Performance Überlegungen |
Behaviour Nodes |
VRML und Java3D |
Literaturverzeichnis |
Spezial:
Beipielprogramm (Teil 1 und Teil 2)
Mit dem Aufkommen immer bessere Hardware zur Darstellung von Echtzeit 3D-Welten steigt auch das Interesse an Software welche jene Fähigkeiten verwirklicht. Gerade im Zusammenhang mit dem Internet wünscht man sich „begehbare Welten" um so die Illusion vom Cyberspace zu perfektionieren.
Sowohl die Java3D API als auch VRML sind zur Darstellung dieser Welten geeignet. Java3D ist eine Bibliothek für die Programmiersprache Java. Sie stellt umfangreiche Befehle sowohl zur high- als auch low-level Grafikprogrammierung zur Verfügung. Dieser Aufsatz konzentriert sich auf die prinzipielle Leistungsfähigkeit der API und zieht am Ende einen Vergleich zu VRML.
Die Java3D API ist eine Bibliothek von Javaklassen zur Darstellung von 3D Welten. Dabei handelt es sich einerseits um geeignete Datenstrukturen, andererseits um Methoden zur Darstellung dieser Daten.
Das grundlegende Konzept dieser Implementierung ist es, die hardwarespezifischen Details durch ein generelles Interface zu überdecken. Dies ist vergleichbar mit ähnlichen Paketen wie z.B. OpenGL und Direkt3D. Interessanter weise basieren einige Implementationen von Java3D auf gerade diesen Vorgängern.
Java3D fügt sich nahtlos in das Gesamtkonzept von Java ein. Der große Vorteil dieser Programmiersprache ist eine größtmögliche Plattformunabhängigkeit. Diese wird auch im 3D Paket voll gewährleistet (auch wenn die tatsächliche Implementierung der Bibliothek relativ maschinennah ist). Plattformunabhängigkeit ist gerade in der Grafikprogrammierung ein relatives Novum, insbesondere da Grafiksoftware in der Regel sehr maschinennah programmiert war.
Sozusagen ergänzend hierzu bemüht sich die Implementierung auch um größtmögliche Flexibilität. So werden zum Beispiel viele File-Formate unterstützt.
Neben der lobenswerten Umsetzung der „Write once, run anywhere" Philosophie bietet die 3D API auch weitere Vorteile. Aufgrund ihrer Zugehörigkeit zur Java-Familie ist sie durchgehend objektorientiert. Obwohl sich Objektorientiertheit gerade bei der Graphikprogrammierung richtiggehend anbietet, wurde dieser Aspekt bei bisherigen Pakten wie z.B. OpenGL eher sekundär behandelt. Die Objektorientiertheit erleichtert Softwareentwicklung und -wartung enorm.
Nicht nur jedoch die Entwicklung wird mit Java3D einfacher - das Paket bietet auch eine beeindruckende Perfomance. Dies ist insbesondere dann bemerkenswert, wenn man bedenkt, daß Java zu den interpretierten Sprachen gehört und somit eher langsam ist.
Die Umsetzung von dreidimensionalen Körpern in für den Computer verwendbare Daten stellt eine einmalige Herausforderung dar. Sicherlich leuchtet es ein, daß für den Echtzeitbetrieb diese Datenmenge gering bleiben sollte und man daher gezwungen ist, verschiedene Vereinfachungen einzuführen.
Das gängigste Konzept stellt die Vereinfachung des Körpers zu Polygonen dar. Damit wird letztendlich jeder Körper durch sein facettiertes Abbild dargestellt. Der Vorteil ist, daß wir anstelle jedes Oberflächenpunktes nur noch die Eckpunkte, ihre Verbindungslinien sowie Füllinformation über die entstehenden Polygone speichern müssen.
Punkte werden über ihre homogenen Koordinaten gespeichert. Homogene Koordinaten bestehen aus den x, y und z Abständen zum Ursprung sowie einer 1, also z.B. (z,y,z,1). Die 1 erscheint auf den ersten Blick unnötig ist aber aufgrund der mathematischen Grundlagen auf die hier nicht näher eingegangen wird erforderlich.
Polygone sind eine geordnete Menge von Punkten, Körper eine Menge von Polygonen.
Die Position von Punkten (i.e. ihre Koordinaten) lassen sich durch Matrizenmultiplikationen verändern, wobei es für jede der gängigen Veränderungen (Streckung, Bewegung, Drehung usw.) eine spezielle Matrix gibt. Beispielsweise bewirkt folgende Matrix eine Streckung um den Faktor 2 vom Ursprung ausgehend:
Die Anordnung von Objekten erfolgt über eine Baumstruktur.
Die Idee hinter dieser Struktur ist einfach. Alle Objekte werden unabhängig relativ zum Ursprung definiert und dann über Matrizenmanipulation an ihren vorgesehenen Platz bewegt. Betrachtet man obigen Baum so kann man wenn man vom Objekt zum Ursprung geht genau sehen, welche Manipulationen an einem Objekt vorgenommen werden.
Damit haben wir eine komplette Datenstruktur zur Speicherung einer Dreidimensionalen Welt.
Die oben beschriebenen Daten müssen natürlich noch auf dem Bildschirm dargestellt werden. Dieser Vorgang ist als „Rendern" bekannt. Wir können zwar mit Hilfe unserer Baumstruktur leicht ermitteln wo genau unsere Punkte im Raum liegen, allerdings haben wir zum einen keinen dreidimensionalen Bildschirm und zum anderen wollen wir nicht nur Punkte sondern Polygone und somit Körper darstellen.
Die Umsetzung in das Zweidimensionale ist kein Problem - eine Projektion von höher- in niedrigerdimensionale Räume ist mathematisch einfach zu realisieren. Eine einfache (wenn auch unbefriedigende Technik) ist es, einfach die z-Koordinate wegzulassen. Diese Technik nennt man Parallelprojektion. Eine „realistische" 3D-Umsetzung ist nur geringfügig komplizierter. Das Füllen der Polygone ist etwas aufwendiger. Betrachten wir hierzu die folgende Abbildung:
Wie wir sehen, haben wir ein Polygon und eine punktförmige Lichtquelle (eine zugegebenermaßen unrealistische, jedoch durchaus notwendige Annahme). Die Lichtstrahlen treffen auf die Eckpunkte des Polygons auf und bilden dort einen Winkel mit dessen Normalen. Aus diesem Winkel sowie den Oberflächeneigenschaften des Polygons lassen sich die Farbwerte in den Eckpunkten berechnen. Nun können wir entlang der Kanten interpolieren. Um unsere Fläche zu füllen nutzen wir die Tatsache, daß die endgültige Darstellung im Grunde genommen nur eine Aneinanderreihung von Zeilen aus Bildpunkten ist. Wir betrachten die Farbwerte der Schnittpunkte mit einer Zeile und interpolieren entlang dieser Linie. Somit haben wir ein gefülltes Polygon.
Als kleine Randbemerkung sei erwähnt, daß wir die Normalen nicht unbedingt ausrechnen müssen sondern einfach mit dem Polygon abspeichern können. Das erlaubt die Verwendung von „falschen" Normalen, welche helfen können mittels der Schattierung die Illusion runder Oberflächen zu erzeugen.
Anfänglich befindet sich unsere Kamera (d.h. der Ausgangspunkt der Projektion) im Ursprung. Um interessantere Positionen einzunehmen müßten wir diesen Punkt mit Matrizenmultiplikationen bewegen. Dafür gibt es einen einfachen Trick - anstelle der Kamera bewegen wir alle Objekte in inverser Richtung. Der subjektive Eindruck ist, daß wir uns im Universum bewegt haben. Wie im richtigen Leben sind auch hier alle Ansichten relativ. Umsetzung in Java3D
Java3D basiert auf den im vorherigen Kapitel beschriebenen allgemeinen Grundlagen. Allerdings bietet die API ein Interface auf einem etwas höheren Level, d.h. eine direkte Matrizenmultiplikation ist unnötig (allerdings nicht unmöglich). Man erkennt allerdings noch gut die ursprüngliche Idee, wenn man sich z.B. die Datenstrukturen ansieht.
Ebenso wie in unserem allgemeinen Beispiel wird auch bei Java3D die Menge aller Objekte in einem Baum gespeichert. Allerdings verfügt dieser über etwas differenziertere Knoten.
Das nebenstehende Beispiel zeigt einen Baum mit den essentiellsten Knoten. Die Wurzel des Baumes ist das VirtualUniverse. Dieses Objekt referenziert den restlichen Baum. Alle anderen Knoten lassen sich in zwei Gruppen einteilen, welche wiederum Basisklassen für alle unsere Knoten darstellen; zum einen haben wir Group Knoten (in unserer Abbildung durch Kreise dargestellt), zum anderen Leaf Knoten (Dreiecke). Auf den ersten Blick mag es seltsam erscheinen, daß einer unserer Blattknoten wieder Kinder hat - tatsächlich sind diese jedoch keine Elemente des Baums sondern lediglich referenzierte Objekte, die nicht direkt zum Baum gehören. Auf diesen Spezialfall von Leaf-Nodes wird weiter unten nochmals eingegangen.
Das VirtualUniverse stellt, wie oben bereits erwähnt, die Baumwurzel dar. Allerdings schließen sich unsere Knoten nicht direkt an die Wurzel an, sondern an sogenannte Locales. Auch wenn dies auf den ersten Blick nicht intuitiv erscheinen mag gibt es dafür eine einfache Erklärung, die gleichzeitig einen der Schwachpunkte Javas illustriert - die Ungenauigkeit bei Fließkommazahlen! Da unsere Koordinaten in Fließkommazahlen angegeben werden tritt bei immer größerer Entfernung vom Ursprung eine immer größere Ungenauigkeit auf. Dadurch kann es zu unerwünschten Lücken zwischen Objekten und anderem Fehlverhalten der Darstellung kommen. Um dem entgegenzuwirken kann man räumlich nahe Objekte mittels einer Locale gruppieren. Wir haben also mehrere Ursprünge wenn man so will.
Die Group Knoten entsprechen ungefähr unseren Matrizenknoten aus unserem Eingangsbeispiel, allerdings verfügt die API zusätzlich über eine Vielzahl anderer Knoten, welche andere, fortgeschrittenere Aufgaben erfüllen. Die Tabelle gibt eine Übersicht über die wichtigsten.
Knoten |
Funktion |
|
Matrixtransformationen |
|
dynamische Subgraphenauswahl |
|
Instanzierung |
|
Detailstufe des Subgraphen |
|
Gruppierung von Objekten |
Der TransformGroup Knoten enthält eine Matrix (in Form eines Transform3D Knotens) und erlaubt indirekt alle denkbaren Matrixmanipulationen. Diese Manipulationen werden automatisch berechnet, der Anwender muß lediglich angeben, welche Art von Manipulation (z.B. Drehung um 90 Grad) auszuführen ist.
Beispiel (Knoten zur Skalierung um Faktor 2):
Transform3D Matrix = new Transform3D();
Matrix.setScale(2.0);
TransformGroup Knoten = new TransformGroup(Matrix);
Switch ist vor allem dann interessant, wenn es darum geht Objekte zu haben, welche sich im Zeitverlauf verändern sollen. Mittels diesem Knoten kann man auswählen, welcher seiner Subgraphen angezeigt werden soll.
Manchmal ist es wünschenswert, ein Objekt, welches man aus einfacheren zusammengesetzt hat, mehrmals zu verwenden. Um Coderedundanz zu vermeiden, benutzt man SharedGroup. Dieser Knoten definiert eine Instanz, welche dann mittels des Link Leaf -Knotens an beliebigen Stellen eingefügt werden kann. Hierbei ist wichtig, daß ein SharedGroup Knoten ausschließlich von Link und von sonst keinem anderen Knoten referenziert werden kann.
Der LOD (= Level of Detail) Knoten ist eine abstrakte Basisklasse zur Beschleunigung der Ausgabe. Es ist einleuchtend, daß Details von Objekten in großer Entfernung kam noch auszumachen sind. Daher wäre es Zwecks einer Einsparung an Rechenzeit doch durchaus sinnvoll diese Details auszublenden. Die Idee ist, daß man mehrere Subgraphen mit verschiedener Detailgenauigkeit definiert und LOD anhand seiner Kriterien den richtigen auswählen zu lassen. Im Grunde haben wir also einen automatisierten Switchknoten.
Der gängigste LOD Knoten ist DistanceLOD, der die Entscheidung anhand eines Arrays von ansteigenden Entfernungswerten trifft.
Der letzte Knoten der Tabelle ist BranchGroup. Er gestattet die Gruppierung von Objekten.
Die Leaf Knoten enthalten in der Regel die Beschreibung von Objekten, Kameras und Licht, auch wenn es einige Spezialfälle gibt die man nicht in dieser Kategorie vermuten würde. Die Tabelle gibt eine kleine Auswahl aus der Vielzahl der Möglichkeiten:
Knoten |
Funktion |
|
Hintergrund |
|
Java Code einbinden |
|
Fernnebel |
|
Instanz anzeigen |
|
Lichtquelle einfügen |
|
Körper einfügen |
|
Kamera einfügen |
Aufgrund ihrer Wichtigkeit werden Behaviour und Shape3D jeweils separat behandelt. Siehe dazu auch die Kapitel Darstellen von Objekten und Einbinden von Java Code. Die anderen Knoten werden im folgenden erklärt.
Background definiert den Hintergrund. Es kann sich hier um eine Farbe handeln, es können allerdings auch Bitmaps als Hintergrund genommen werden.
Ein beliebter Effekt bei 3D-Grafiken ist Fernnebel. Zum einen verleiht das langsame Verschwimmen von Gegenständen in der Ferne der Darstellung einen Illusion von Unendlichkeit, zum anderen kann man dank des Nebels weiter entfernte Objekte einfach ausblenden, was die Performance steigert. Java3D bietet diese Funktionalität durch den (abstrakten) Fog Knoten. Die verschiedenen abgeleiteten Klassen unterscheiden sich lediglich durch die Formel zur Berechnung des Nebels.
Link ist das Gegenstück zu dem bereits oben beschriebenen Definition (s. Group Nodes). Es erlaubt das Einfügen von vorher definierten Objektgruppen.
Licht ist ein wichtiger Aspekt bei der 3D Programmierung. Den meisten Programmen liegt das Phong Lighting Model zu Grunde. Dieses Modell (welches sehr wahrscheinlich auch in die Entwicklung von Java3D eingeflossen ist) vereinfacht insbesondere die indirekte Beleuchtung durch Streulicht (d.h. alle Lichtstrahlen welche so oft reflektiert wurden, daß ihnen keine Richtung mehr zugeordnet werden kann) sehr stark. AmbientLight Knoten enthalten die Einstellungen für diese Art der Beleuchtung. Andere Lichtquellen sind PointLight (eine punktförmige Lichtquelle, welche in alle Richtungen strahlt) und SpotLight (ein Scheinwerfer - das Licht fließt nur in eine Richtung).
Die ViewPlatform steht für unseren Standpunkt im Raum. Man könnte sie als Kamera bezeichnen. Die Platform ist mit den für die Darstellung verantwortlichen Objekten verknüpft (s. Darstellen von Objekten).Darstellen von Objekten
Im Folgenden überlegen wir uns, wie man prinzipiell ein Objekt darstellen kann. Dabei wir vor allem auf zwei zentrale Aspekte eingegangen - das Erzeugen eines Objekts in der 3D Welt und die Objekte zur Darstellung der Welt auf dem Bildschirm.
Um ein Objekt in unserer virtuellen Welt darzustellen gehen wir im Prinzip wie folgt vor:
Group Knoten. Dies wurde in den vorherigen Kapiteln bereits ausführlich beschrieben.
Der Shape3D Knoten ist ein Blattknoten zur Beschreibung von Objekten. Er verweist auf zwei andere Objekte (abgeleitet von NodeComponents), welche seine Eigenschaften beschreiben. Dabei handelt es sich um ein Geometry und ein Appearance Objekt.
Appearance beschreibt alle Renderinformationen des Knotens. Dazu gehören z.B. das Shading Model (d.h. die Technik mit der die Licht-Oberflächen Wechselwirkung zu darzustellender Farbe umgerechnet wird), die Liniendicke und Status der Polygone (gefüllt oder leer). Hierzu werden teilweise auch andere NodeComponent-Objekte referenziert. Eines der wichtigsten unter diesen ist mit Sicherheit Material, welches die Farbe des Objekts beschreibt. Da es sich allerdings um ein beleuchtetes Objekt handelt, reicht ein Farbwert keinesfalls aus. Vielmehr müssen wir die Farbe an Punkten ohne direkten Lichteinfall, mit Lichteinfall und im Punkt der Totalreflexion des Lichts angeben. Außerdem können wir noch eine Farbe für ein „Glühen" des Objekts angeben, auch wenn dieser Effekt nicht sonderlich realistisch wirkt und in den meisten Fällen auf schwarz (d.h. kein Glühen) gesetzt wird.
Geometry beschreibt die geometrischen Eigenschaften des Knoten, d.h. seine Form. Allerdings handelt es sich um eine abstrakte Klasse, welche eine Referenzierung der tatsächlichen Geometrie ermöglicht. Diese sind CompressedGeometry, Raster, Text3D und GeometryArray.
GeometryArrays existieren in verschiedener Form, haben aber gemeinsam, daß sie eine Ansammlung von Punkten sind, welche dann je nach Typ auf unterschiedliche Weise verbunden werden. Im Konstruktor kann man darüber hinaus noch einstellen, welche anderen Informationen im Objekt gespeichert sind (z.B. Normalen, Farben und/oder Texturkoordinaten). Beispielsweise werden beim TriangleStripArray immer drei Punkte als Dreieck interpretiert.
Es stehen darüber hinaus noch eine Menge anderer von den obigen Hauptgeometrien abgeleitete Klassen zur Verfügung, auf die allerdings in diesem Rahmen nicht eingegangen werden soll.
Beispiel (erzeugen eines einfachen Objekts):
/* Material */
Color3f Base = new Color3f(0.0f, 0.0f, 1.0f); // Objektfarbe
Color3f Emission = new Color3f(0.0f, 0.0f, 0.0f); // Kein Glühen (daher schwarz)
Color3f Highlight = new Color3f(0.8f, 0.8f, 1.0f); // heller Fleck durch
Direktreflexion
Material Shiny = new Material(Base, Base, Emission, Highlight);
Appearance A1 = new Appearance();
A1.setMaterial(Shiny);
/* Geometrie */
TriangleStripArray geom =
new TriangleStripArray(Anzahl,
GeometryArray.COORDINATES&GeometryArray.NORMALS,
Anzahlen); // Die Variablen seihen irgendwo anders definiert!
geom.setCoordinates(0, UnserDatenArray1, 0, Anzahl);
geom.setNormals(0, UnserDatenArray2, 0, Anzahl);
/* Last but not least unser eigentliches Objekt */
Shape3D Körper = new Shape3D(geom, Shiny);
DarüberliegenderKnoten.addChild(Körper); // einfügen in den Baum
Zur Darstellung der Welt auf dem Bildschirm dient das View Objekt. In ihm fließen alle Renderinformationen zusammen. Das View Objekt verfügt über Referenzen auf alle anderen für die Darstellung notwendigen Klassen.
Die Abbildung veranschaulicht diese Zusammenhänge. Die ViewPlatform liefert die Positionsinformationen zum Rendern. Canvas3D enthält alle Daten der Bildschirmanzeige und Screen3D die Spezifikationen des Bildschirms. PhysicalBody und PhysicalEnvironment enthalten Informationen für exotische Ein- und Ausgabegeräte wie zum Beispiel HMDs (Head Mounted Displays, auch „Cyberhelme" genannt).Interaktion
Natürlich bietet Java3D neben Klassen zur Darstellung und Speicherung von 3D Welten auch die Möglichkeit aufgrund von Ereignissen im virtuellen Raum Methoden aufzurufen. Anwendungen hierfür wären beispielsweise Animation oder Picking.
Zur Animation müssen wir immer wieder die Position von Objekten im Raum verändern, was einen wiederholten Aufruf des entsprechenden Codes verlangt. Unter Picking versteht man das Auswählen von Objekten in einer 3D Welt. Auch hierzu muß ständig eine Bedingung überwacht werden (i.e. ein Mausereignis).
Ein Problem hierbei ist allerdings die Performance. Je mehr Ereignisse ständig abgefragt werden müssen, um so langsamer wird die Ausführung des Programms. Da Grafik mit zu den zeitkritischsten Anwendungen gehört ist dieser Einwand durchaus gerechtfertigt. Glücklicherweise bietet auch hier Java3D eine intelligente Lösung an. Für jedes Ereignis wird ein bestimmter Bereich definiert - die Scheduling Region. Einzig und allein wenn sich diese Region mit dem Gesichtsfeld schneidet wird die Bedingung, welche das Ereignis auslösen kann, abgefragt.
Die oben beschriebene Funktionalität wird durch die Behaviour Knoten bereitgestellt. Ihre Funktionsweise wird durch folgende Abbildung illustriert:
Jeder Knoten definiert eine Scheduling Region, einen Zustand sowie eine Bedingung. Der Knoten ist nur aktiv, wenn die Scheduling Region sichtbar ist (d.h. die Schnittmenge zwischen Gesichtsfeld und der Region nicht leer ist). Ist der Knoten aktiv, so überprüft er die gegebene Bedingung und falls sie zutrifft wird der Stimulus ausgeführt. Der angegebene Code kann gegebenenfalls den Graphen manipulieren oder aber andere Aktionen ausführen.
Konkret bedeutet dies, daß wir ein Behaviour Objekt haben. Integraler Bestandteil sind die initialize und die processStimulus Methoden. Die Initialisierungsmethode wird aufgerufen, wenn das Objekt in den Baum eingeführt wird und sorgt für die richtige Einstellung der Instanzvariablen. processStimulus enthält den Code, der unter den oben beschriebenen Bedingungen ausgeführt wird. Dabei ist zu beachten, daß das Behaviour Objekt nur diejenigen Knoten verändern kann, die es referenziert.
Die zu überwachende Bedingung ist ein Objekt welches sich von der abstrakten Klasse WakeupCondition ableitet. Es gibt 14 verschiedene Klassen, sowie einige weitere zur Kombination mehrerer Bedingungen. Beispiele sind WakeUpOnElapsedTime und WakeUpOnAWTEvent. Die Bedingungen aller Behaviours werden in den behaviour scheduler von Java3D gehängt und ihr zugehöriges Behaviour (d.h. die eigene davon abgeleitete Klasse) aufgeweckt, sobald die Bedingung zutrifft. Die Bedingungsobjekte können später auch durch andere ersetzt werden (so kann man z.B. am Ende der processStimulus Methode die Kriterien für eine erneute Ausführung verändern).VRML und Java3D
Java ist eine Sprache die man nahezu sofort mit dem Internet verbindet. Aufgrund ihrer Plattformunabhängigkeit und der Fähigkeit im Browser lauffähige Applets zu erstellen, wird diese Sprache häufig in diesem Bereich angewendet.
Da die Java3D API lediglich eine Erweiterung des Java Grundpakets darstellt, liegt natürlich der Gedanke nahe, sie zur Implementation von netzgestützten 3D Welten einzusetzen. Nun stellt sich allerdings dann auch die Frage, inwieweit nicht VRML eine Konkurrenz darstellt. Die Virtual Reality Modelling Language, in gewisser Weise das graphische Pendant zu HTML, ist nämlich für genau diese Aufgabe konzipiert.
In diesem Zusammenhang ist zu bemerken, daß die beiden Produkte keinesfalls direkte Konkurrenten sind, vielmehr gibt es für beide sinnvolle Anwendungen und damit ein nahezu komplementäreres Verhalten.
Um beide Produkte zu vergleichen muß man sich erst einmal einen fundamentalen Unterschied vor Augen führen. Bei VRML handelt es sich um eine Beschreibungssprache, d.h. man kann eine 3D Welt statisch spezifizieren, in Grunde genommen haben wir also kein Programm sondern ein Datenfile.
Java3D dagegen ist eine Programmiersprache mit allen Vor- und Nachteilen. In den meisten Fällen befindet sich im Programm gar nicht die Szenenbeschreibung, sondern lediglich die Software zur Darstellung und Interaktion mit der Welt.
Dieser Unterschied wird durch folgendes Beispiel schön illustriert - man kann einen VRML-Browser in Java3D schreiben.
Für VRML spricht sicherlich, daß es sehr leicht zu erlernen ist. Dies ist auf den einfachen Aufbau zurückzuführen. In der Tat kann man mit der Modelling Langauge sehr schnell Resultate erzielen.
Ein weiterer Vorteil ist, daß zur Erstellung von VRML-Welten Generatorsoftware existiert. Dadurch wird die Erstellung nochmals vereinfacht.
Ganz anders dagegen ist Java3D. Als Zusatz zu einer vollständigen Programmiersprache gerade zu dem ohnehin schon komplizierten Bereich der Grafikprogrammierung, hat Java3D eine etwas ungünstigere Lernkurve. Der Vorteil ist allerdings die wesentlich größere Flexibilität. Gerade was Interaktion mit der 3D Welt betrifft kann man so ziemlich alles implementieren was das Herz begehrt, während man bei VRML auf die Dinge beschränkt ist welche der Browser unterstützt oder welche man über Skriptknoten eingefügt hat. Im Gegensatz zu VRML muß man allerdings Datensicherung vornehmen. Die 3D Welt ist flüchtig und muß in eine eigene Datei gespeichert werden.
Zusammenfassend ist zu sagen, daß bei einfachen statischen Anwendungen VRML sicherlich besser ist, je mehr Interaktion sich allerdings hinter der Welt verbirgt um so geeigneter wird Java3D.