next up previous contents
Nächste Seite: Interaktion mit dem Betrachter Aufwärts: 3D-Beschreibungssprachen Vorherige Seite: Geschichte der dreidimensionalen Darstellung   Inhalt


VRML vs. X3D

Ein Unterschied zwischen VRML und X3D ist die veränderte Syntax, die durch die jeweilige Spezifikation genau definiert wird [Web2003a]. In einer VRML-Szene werden die verschiedenen Objekte durch sogenannte Knoten dargestellt. Eingeteilt werden die Knoten in Blatt- und Gruppenknoten, wobei letztere beliebige Knoten zusammenfassen können. Manipulationen an einem Gruppenknoten wirken sich auf alle untergeordneten Kindknoten aus. Blattknoten können zudem in grafische und nicht grafische Knoten unterteilt werden, die dann noch weiter gegliedert werden können. Geometrieknoten, mit denen sich einfache geometrische Objekte, wie z.B. eine Kugel, definieren lassen, sind Teil der grafischen Knoten. Durch sie werden die Objeke einer Szene definiert [Sch1998].
Die Eigenschaften eines Knotens lassen sich über seine Datenfelder festlegen. Jedes Datenfeld ist von einem bestimmten Datentyp, der genau festlegt, welche Werte dem Feld zugewiesen werden können. So können z.B. einfache Strings (SFString), dreidimensionale Vektoren für Fließkommazahlen (SFVec3f) oder sogar weitere Knoten (SFNode) den Feldern zugewiesen werden. Knoten können mittels der Anweisung DEF Namen zugewiesen werden, wodurch sie in der Szene referenzierbar werden. Das spielt u.a bei dem Routing-Konzept, das im weiteren Verlauf des Kapitels vorgestellt wird, eine Rolle (Abschnitt 5.3.1).
Die hierarchische Struktur einer 3D-Szene wird als Szenegraph bezeichnet. Sie kommt durch die Verschachtelung der verschiedenen Knoten und dadurch, daß Knoten Datenfeldern zugeordnet werden können, zustande. Der daraus resultierende Graph ist gerichtet und azyklisch.

Beispiel einer einfachen Kugel in VRML
Transform {
    translation 3 0 0
    children [
        Shape {
            geometry Sphere {
                radius 2
            }
            appearance Appearance {
                material Material {
                    diffuseColor 1 0 0
                }
            }
        }
    ]
}

Im Quellcode 5.1 ist eine Szene zu sehen, in der eine rote Kugel dargestellt wird. Durch das translation-Feld des Transform-Knoten wird sie im Weltkoordinatensystem an die Position (3/0/0) plaziert. Die Verschiebung wirkt sich auf alle untergeordneten Knoten aus, in diesem Fall nur auf den Shape-Knoten. Dessen Feldern geometry und appearance sind die Knoten Sphere und Appearance zugeordnet, wobei dem letzteren noch der Material-Knoten untergeordnet ist. Die endgültige Darstellungsform wird über die Datenfelder radius, das den Radius der Kugel festlegt, und diffuseColor, das die Farbe bestimmt, gesteuert. Der dazugehörige Szenegraph ist in Abbildung 5.1 zu sehen.

Abbildung 5.1: Szenegraph des Beispiels aus Quellcode 5.1
\resizebox*{0.4\textwidth}{!}{\includegraphics{pics/szenegraph}}

Dieselbe Szene ist im Quellcode 5.2 als X3D-Dokument abgebildet. Jeder Knoten wird hier als Element dargestellt und die meisten Datenfelder werden als Attribute übernommen. Datenfelder, denen man zuvor Knoten zuweisen konnte, fallen jedoch weg, da die entsprechenden Knoten als Elemente im Inhaltsbereich abgelegt werden. In diesem Beispiel ist ebenfalls dem Transform-Element das Shape-Element untergeordnet, dem wiederum die Elemente Sphere und Appearance untergeordnet sind. Dem Appearance-Element ist dann nochmals das Material-Element untergeordnet. Über die Attribute radius und diffuseColor werden dann noch die entsprechenden Werte zugewiesen.

Beispiel einer einfachen Kugel in X3D
<Transform translation="3 0 0">
    <Shape>
        <Sphere radius="2"/>
        <Appearance>
            <Material diffuseColor="1 0 0"/>
        </Appearance>
    </Shape>
</Transform>

Jeder VRML-Knoten wird als Element in X3D übernommen. Bei einigen Elementen hat sich jedoch der Aufbau insofern verändert, daß die Datenfelder, denen zuvor Knoten zugewiesen wurden, wegfallen. Zudem sind einige Elemente dazugekommen, mit denen man z.B. zweidimensionale Objekte anlegen oder Tastatureingaben verwerteten kann. Eine X3D-Szene, in der diese Elemente nicht verwendet werden, ist abwärtskompatibel zu VRML und läßt sich somit in eine VRML-Szene konvertieren. Die umgekehrte Konvertierung ist immer möglich. Obwohl die Objekte eines XML-Formates als Elemente bezeichnet werden, wird in X3D an der VRML-spezifischen Bezeichnung festgehalten. Elemente werden also weiterhin als Knoten und Attribute weiter als Datenfelder bezeichnet. Durch das XML-Format wird lediglich die Syntax verändert, wodurch X3D-Dokumente eine bessere Lesbarkeit besitzen. Denn gerade bei tiefen Verschachtelungen war es in VRML-Dokumenten nicht immer einfach, zusammengehörende Klammerpaare eindeutig zu identifizieren. Das XML-basierte Format hat aber noch einen weiteren praktischen Vorteil. Ob die Syntax eines VRML-Dokumentes korrekt ist, konnte bisher erst bei der richtigen Darstellung in einem Browser erkannt werden. Bei einem X3D-Dokument läßt sich das sofort überprüfen, indem das Dokument mit der entsprechenden DTD oder dem entsprechenden Schema validiert wird. Die wesentliche Änderung ist jedoch der unterschiedliche Aufbau beider Sprachen. X3D ist im Gegensatz zu VRML modular aufgebaut. Die ganze Spezifikation ist dabei in sogenannte Profile unterteilt, die sich in Komplexität und Funktionalität unterscheiden. Insgesamt wird zwischen sechs Profilen unterschieden.

  1. Core Profile Minimale Datei-Informationen, wobei die verwendeten Komponenten explizit angegeben werden müssen
  2. Interchange Profile Minimale Implementation, erlaubt beschränkten Lichteinsatz, jedoch keine Interaktion
  3. Interactive Profile Erweiterte Implementation, die eingeschränkte Interakion erlaubt
  4. MPEG-4 interactive Profile Entspricht dem MPEG-4 Standard
  5. Immersive Profile Entspricht dem VRML Standard
  6. Full Profile Volle Implementation der X3D Spezifikation
Bausteine der Profile sind 24 mögliche Komponenten, in denen themenverwandte Knoten zusammengefaßt werden. Sie sind in der Tabelle 5.1 aufgelistet. Jede Komponente läßt sich durch eine Ebene genauer spezifizieren. Diese gibt an, in welchem Umfang die Knoten einer Komponente unterstützt werden. In einer Ebene kann z.B. der Wertebereich eines Datenfeldes eingeschränkt sein oder ein Feld ist dort gar nicht definiert. Am häufigsten ist jedoch der Fall, daß ganze Knoten undefiniert sind.

Tabelle 5.1: Komponenten in X3D
X3D-Komponenten
Core, Distribute interactive simulation, Environment effects, Environment sensor,
Event utilities, Geometry2D, Geometry3D, Geospatial, Grouping,
Humanoid animation, Interpolation, Key device sensor, Lightning,
Navigation, Networking, NURBS, Point device sensor, Rendering
Scripting, Shape, Sound, Text, Texturing, Time


Die Tabelle 5.2 stellt die Geometry3D-Komponente mit ihren jeweiligen Knoten in den verschiedenen Ebenen dar. In der ersten Ebene sind die Knoten definiert, mit denen die grundlegendsten geometrischen Objekte erzeugt werden können: Box, Cylinder, Cone, IndexedFaceSet und Sphere. Knoten, mit denen komplexere Objekte erzeugt werden können, werden in höheren Ebenen definiert. Kompliziertere Gitterobjekte werden mit dem Knoten ElevationGrid erzeugt, der erst in der zweiten Ebene definiert wird. Mit Hilfe des Knotens Extrusion lassen sich aus zweidimensionalen Geometrien dreidimensionale Objekte erzeugen. Dieser Knoten wird erst in der dritten Ebene definiert und steht daher in den darunterliegenden Ebenen nicht zur Verfügung.

Tabelle 5.2: Geometry3D-Komponente und deren Ebenen
Ebene enthaltene Knoten
1 Box, Cone, Cylinder, IndexedFaceSet, Sphere
2 alle Knoten der Ebene 1 zzgl. ElevationGrid
3 alle Knoten der Ebene 2 zzgl. Extrusion


Die Profile unterscheiden sich also darin, welche Komponenten sie in welcher Ebene unterstützen. Im Interchange-Profile z.B. ist die Geometry3D-Komponente in der ersten Ebene definiert, wohingegen das Interactive-Profile die zweite Ebene unterstützt. Der Knoten ElevationGrid kann somit im Interactive-Profile genutzt werden, wohingegen er im Interchange-Profile nicht definiert ist. Durch die Angabe des Profils im Wurzelelement X3D sind somit automatisch alle Knoten definiert, die man in der Szene verwenden kann. Eine Ausnahme bildet das Core-Profile, bei dem explizit alle verwendeten Komponenten zu Anfang der Datei aufgezählt werden müssen. Reicht der Sprachumfang eines Profils für die Darstellung einer bestimmten Szene nicht aus, können weitere Komponenten von Hand integriert werden. Neben der Definition des Sprachumfangs werden durch ein Profil auch allgemeine Einschränkungen, wie z.B. die Anzahl der Kindknoten eines Gruppenknotens und die Anzahl simultaner Lichtquellen, festgelegt. Bevor ein X3D-Dokument erstellt werden soll, muß also zunächst bestimmt werden, welche Komplexität die eigene 3D-Szene haben wird und was mit ihr realisiert werden soll. Der modulare Aufbau hat wesentliche Vorteile. Anders als bei VRML läßt sich X3D problemlos erweitern. Dadurch ist X3D auch für zukünftige Problemstellungen geeignet. Für spezielle Anwendungen lassen sich so eigene Module entwickeln, womit auf die individuellen Anforderungen einer Szene besser eingegegangen werden kann. Da man aber auch die ganze Spezifikation in kleinere Profile einteilt, kann man für jede Anwendung optimale Browser-Plug-Ins entwickeln, die sich je nach Profil im Laufzeitverhalten unterscheiden können [Eibl2001].
Ein Grund, warum sich VRML nicht durchgesetzt hat, ist die Tatsache, daß es kein Browser-Plug-In gibt, der die komplette Spezifikation implementiert hat. Unterschiedliche Browser können somit eine Szene anders darstellen. Dieses Problem sollte bei X3D aufgrund der Modularität nicht auftreten.
next up previous contents
Nächste Seite: Interaktion mit dem Betrachter Aufwärts: 3D-Beschreibungssprachen Vorherige Seite: Geschichte der dreidimensionalen Darstellung   Inhalt
Oliver Krone 2003-04-28