Sobald Sie sich mit dem Gedanken tragen, Ihre virtuelle Umgebung auf dem World Wide Web zu veröffentlichen, sollten Sie den VRML-Code für diesen Zweck entsprechend optimieren. Hierbei gilt es vor allem zwei Faktoren zu berücksichtigen. Aufgrund des ansteigenden Datenverkehrs leidet das WWW an einer zunehmenden Überlastung, die sich in langen Transport- und damit Wartezeiten für den User ausdrückt. Um diese gering zu halten, sollten die Dateigrößen möglichst klein ausfallen, der Code demnach entsprechend effizient gestaltet sein. Auf der Client-Seite ist zusätzlich die Leistungsstärke der möglichen eingesetzten Rechnersysteme zu berücksichtigen. Eine mit vielen Details auf einer Grafikworkstation entworfene 3D-Szene kann sich leicht als zu komplex für das Rendering auf einem durchschnittlichen PC erweisen. Obwohl die meisten VRML-Viewer Optionen zur Erhöhung der Darstellungsgeschwindigkeit auf Kosten der -qualität anbieten, sollte die Frustrationsschwelle beim Cybernauten nicht durch zu lange Download-Zeiten und stockende Bewegungen in der virtuellen Umgebung überschritten werden.
n Die Optimierung einer VRML-Datei beginnt schon beim Entwurf der 3D-Szene. Oftmals lassen sich die zu übermittelnden Informationen bereits mit Andeutungen der realen Pendants vermitteln, ohne dabei zu sehr in die Details gehen zu müssen. Zur örtlichen Bestimmung relevanter Gebäude in einem Ortsinformationssystem reicht es beispielsweise aus, die umliegenden Gebäude lediglich als Quader darzustellen. Entsprechend finden sich für alle nur denkbaren Anwendungszusammenhänge Analogien, die aufgrund einfacherer Modellierungen sowohl die Lauf- als auch die Ladezeiten der Szene optimieren. Wurde ein passendes Modell mit Hilfe eines 3D-Modellierungsprogramms entwikkelt, sollte die typischerweise großzügige Verwendung von Polygonen auf ein akzeptables Minimum reduziert werden. Spezielle Modellierprogramme für 3D-Echtzeitgrafik - wie SGI's CosmoWorld - bieten für diesen Zweck sogenannte Polygon-Reduzierer an, mit denen sich die Polygon-Dichte einer 3D-Szene nachträglich beliebig verändern läßt.
Letztendlich lassen sich VRML-Dateien auch komprimieren und damit für den Transport über das WWW auf ein Minimum reduzieren. Die mit der Extension .wrl.gz gekennzeichneten GZIP-Dateien müssen auf dem Client-Rechner entpackt werden, bevor sie vom VRML-Viewer dargestellt werden können. Bei den meisten Viewern vollzieht sich das Entpacken und Laden automatisch, so daß die komprimierten VRML-Dateien ohne jeglichen Zusatzaufwand vom Cybernauten aufgerufen werden können.
Da es sich bei VRML um eine auf die Ansprüche des WWW ausgerichtete 3D-Beschreibungssprache handelt, bietet VRML - neben den zuvor genannten, allgemeinen Möglichkeiten - spezielle Verfahren zur Optimierung der Lauf- und Ladezeiten von virtuellen Welten an. Obwohl diese auf den klassischen Methoden der 3D-Echtzeitgrafik und Virtuellen Realität beruhen, gewinnen sie gerade im Zusammenhang mit den beschriebenen Umständen im WWW einen zusätzlichen Nutzen in bezug auf nicht-optimale Übertragungs- und Renderingzeiten. Ehemals zur möglichst realistischen Darstellung unter optimalen Bedingungen in High-end-VR-Systemen entwickelt, gewähren die optimierenden Verfahren in der Welt von VRML eine Mindestperformance auch auf Low-end-Rechnern.
Sie haben bereits eine wichtige Methode zur Reduzierung des Datenvolumens bei gleichbleibender Informationsdichte kennengelernt. Durch den Einsatz von Texturen lassen sich detaillierte Informationen vermitteln, ohne daß diese mit viel Aufwand modelliert, übertragen und gerendert werden müssen. Im folgenden stellen wir drei weitere Verfahren vor, die in unterschiedlicher Weise das Lauf- und Ladezeitverhalten von VRML-Dateien verbessern können.
Instanziierung mit DEF und USE |
Innerhalb einer VRML-Datei kann beliebig oft auf ein Objekt referenziert werden, wobei man von Instanziierung spricht. Dieses Verfahren hat den Vorteil, daß ein Objekt nur ein einziges Mal im Quellcode beschrieben werden muß, um dann mehrfach in einer Szene eingesetzt werden zu können. Soll beispielsweise der heimische Ortsgemeindesaal der Weltöffentlichkeit in VRML präsentiert werden, muß nunmehr lediglich einer der 50 Stühle beschrieben und über das Netz transportiert werden, auf den dann 49mal referenziert wird. Hierbei müssen die ,,Kopien" nicht zwangsläufig identisch sein, sondern können sowohl in Form als auch in Farbe und Material vom Basisobjekt abweichen. Das Referenz-Stuhlmodell läßt sich demnach unterschiedlich dimensionieren und mit variierenden Bezügen ausstatten.
In VRML setzt die Referenzierung auf ein Objekt dessen Bezeichnung mit der Anweisung DEF voraus. Auf den mit einem Namen initialisierten Knoten kann dann mittels der Anweisung USE beliebig oft referenziert werden. Sämtliche Veränderungen des Basis-Knotens - beispielsweise durch dynamische Verfahren - wirken sich folglich auf alle abgeleiteten Knoten aus. Andererseits kann ein abgeleiteter Knoten durch die Eigenschaften des jeweiligen Elternknotens in Form und Oberflächeneigenschaft individuell verändert werden. So lassen sich die Kindknoten des Knotens Transform bei der Referenzierung über das Feld scale verformen und über das Feld appearance verändern.
Für unser Kirchhofbeispiel bedeutet dies, daß wir die Kopie des zweiten Baums nicht mehr per Inline über das WWW transportieren müssen, sondern innerhalb der Basisdatei auf den ersten Baum referenzieren können. Der folgende Ausschnitt zeigt den veränderten Code gegenüber Datei ,,in_basis.wrl".
Listing 8.6
#VRML V2.0 utf8
# Datei USE.WRL: Instanziierung mit DEF und USE
...
DEF Baum Transform { # Baum
translation 3 -0.8 3
children [
Inline { # Initialisierung
url "in_baum.wrl"
bboxCenter 0 0.4 0
bboxSize 1 1 1
}
]}
DEF Baum_2 Transform { # Baum_2
translation 4 -0.7 2
scale 1 1.5 1
children USE Baum # Instanziierung
}
]} # Group
Um die Referenzierung des ersten Baums nicht der Translation im Elternknoten Transform zu unterwerfen, wurde die Initialisierung von Baum erst auf der Ebene des einzubindenden Objekts vorgenommen. Da bei der Instanziierung keine exakte Kopie erzeugt werden soll, wird das mittels USE erzeugte Objekt - wie in der ursprünglichen Datei - entsprechend skaliert.
Billboards |
Unter einem Billboard n versteht man in VRML einen Gruppenknoten, der sein lokales Koordinatensystem permanent insofern anpaßt, daß die untergeordneten Objekte auf den Betrachter der 3D-Szene ausgerichtet sind. Bewegt sich der Cybernaut um eines der untergeordneten Objekte, dreht sich dieses in einer synchronen Bewegung mit. Objekte lassen sich dann sinnvoll in Form von Billboards umsetzen, wenn sich deren Seitenansichten gleichen bzw. ohnehin identisch sind. Dies ist beispielsweise bei Bäumen oder Laternen der Fall, sofern sich der Betrachter auf einer Ebene um diese Objekte herum bewegt (siehe Abbildung 8.6). Häufig werden im Zusammenhang mit Billboards Texturen verwendet, die eine zweidimensionale Ansicht zeigen. Wird diese auf ein Polygon aufgebracht, das sich mit dem Betrachter bewegt, entsteht der Eindruck eines dreidimensionalen Körpers, der von allen Seiten gleich aussieht. Mit diesem Verfahren läßt sich der Einsatz von Geometrien - beispielsweise bei der Erzeugung eines Waldes aus vielen Einzelbäumen - erheblich reduzieren.
Im Knoten Billboard lassen sich über das Feld axisOfRotation eine oder mehrere Achsen für die Drehbewegung der untergeordneten Objekte festlegen. In der Regel wird die Default-Einstellung 0 1 0 beibehalten, d.h. eine Drehung um die Y-Achse, die mit der auf einer Ebene ausgerichteten Bewegung des Cybernauten harmoniert. Prinzipiell läßt sich jedoch eine Ausrichtung um alle Achsen erreichen, so daß beispielsweise ein texturiertes Polygon aus jeder möglichen Perspektive in Aufsicht erscheint. Diese als Screen-alignment bezeichnete, spezielle Einstellung des Billboards wird über den Wert 0 0 0 erreicht und eignet sich beispielsweise für die Darstellung eines Firmenlogos oder ähnlichem.
Wie Sie wahrscheinlich schon vermutet haben, wenden wir uns erneut den Bäumen der Kirchhofszene zu, um den Einsatz von Billboards zu demonstrieren. Anstelle des aus einer Kugel, einem Kegel und einer Textur zusammengesetzten Baumes verwendet Datei ,,billbord.wrl" lediglich eine teilweise transparente Textur ,,baum.gif", die auf einem als Billboard dienenden viereckigen Polygon aufgebracht wird. Trotz des resultierenden höheren Realismus können der Quellcode und die darzustellenden Geometrien somit erneut reduziert werden.
Listing 8.7
#VRML V2.0 utf8
# Datei BILLBORD.WRL: Baeume als Billboards
...
DEF Baum Transform { # Baum
translation 3 -0.5 3
children [
DEF Baum Billboard { # Billboard - Anfang
axisOfRotation 0 1 0
children [
Shape {
appearance Appearance {
texture ImageTexture {
url "baum.gif"
repeatS FALSE repeatT FALSE
}}
geometry Box { size 1 1 0 }
}
]} # Billboard - Ende
]}
DEF Baum_2 Transform { # Baum_2
translation 4 -0.25 2
scale 1 1.5 1
children USE Baum # Instanziierung
}
]} # Group
Auch auf den als Billboard initialisierten Baum kann mittels USE referenziert werden, so daß sich dieser in gewohnter Weise kopieren und in Baum_2 verändern läßt. Abbildung 8.6 zeigt die Datei ,,billbord.wrl" im VRML-Viewer, wobei der Einsatz der Billboards erst bei der Bewegung durch die virtuelle Umgebung richtig zur Geltung kommt.
Level-of-Detail |
n Beim Einsatz von Level-of-Detail (kurz LOD) steht die Optimierung der Darstellungsperformance auf dem Client-Rechner im Vordergrund. Statt einer einzigen Version enthält eine VRML-Datei mehrere, unterschiedlich detaillierte Versionen desselben Objekts, die jeweils stellvertretend in Abhängigkeit von ihrer Distanz zur Betrachterposition dargestellt werden.
Abbildung 8.7 verdeutlicht
dieses typischerweise im Bereich der Virtuellen Realität angewendete Prinzip anhand des bekannten
Kirchengebäudes. Befindet sich der Cybernaut in unmittelbarer
Nähe zur Kirche, so daß diese einen großen Bereich des
Bildschirms ausfüllt, kann ein entsprechend hoher Anteil der zur
Verfügung stehenden Rechenressourcen für deren Rendering
aufgewendet werden. In diesem Fall wird das texturierte Modell mit dem
höchsten Detaillierungsgrad (LOD_1) dargestellt. Bei einer mittleren
Entfernung zum Betrachter können aufgrund der entsprechend
reduzierten Anzahl von zur Verfügung stehenden Bildschirmpixel
einige der Details ohnehin nicht mehr adäquat dargestellt bzw. vom
Cybernauten erkannt werden, so daß eine zeitaufwendige Berechnung
derselben nicht lohnt. Als Folge wird das detaillierte Modell mit einer
einfacheren Version - der nichttexturierten Kirche (LOD_2) -
ausgetauscht, wobei wichtige Ressourcen zur Berechnung anderer Objekte
freigegeben werden. Entfernt sich der Betrachter noch weiter, so
daß die Kirche auf dem Bildschirm immer kleiner wird, lassen sich
beliebig viele weitere LODs einfügen (LOD_3). Sämtliche
Objekt-Versionen sollten bei diesem Vorgang ungefähr denselben
Ausmaßen entsprechen, so daß sich der Wechsel möglichst
unmerklich gestaltet.
Abbildung 8.7
Verschiedene LODs desselben Objekts
In der Regel werden die verschiedenen Distanzen vom Worldbuilder vorgegeben und dienen dem VRML-Viewer als Grundlage für die Auswahl eines LODs. Je nach Implementierung des Viewers werden die Distanzen jedoch lediglich als Richtwerte behandelt. In diesem Fall hängt die Auswahl eines LODs in erster Linie von der allgemeinen Performance des Systems ab. Sinkt die Rendering-Rate (Frames-per-Second) unter ein bestimmtes Niveau, d.h. ist die Anzahl der pro Sekunde bewältigten Neuberechnungen einer Szenenansicht so gering, daß keine akzeptablen Bewegungsübergänge mehr gewährleistet sind, greift der Viewer automatisch auf weniger detaillierte LODs zurück, um die Komplexität der zu berechnenden Szene zugunsten der Darstellungsgeschwindigkeit zu reduzieren.
Die unterschiedlich detaillierten Objekt-Versionen werden im Feld level des Knotens LOD aufgeführt, wobei eine feste Reihenfolge vom höchsten bis zum niedrigsten Detaillierungsgrad einzuhalten ist. Über das Feld range wird jedem LOD ein Distanzbereich zugeordnet, innerhalb dessen es als darzustellendes Objekt aktiv ist. Soll zur Berechnung der Distanz eine vom Mittelpunkt der LODs abweichende Position herangezogen werden, läßt sich diese im Feld center angeben.
Zur Verdeutlichung der LOD-Funktionsweise verwendet das folgende Listing die in Abbildung 8.7 gezeigten, unterschiedlich detaillierten Versionen des Kirchengebäudes. Wie im Dateinamen ,,in_lod.wrl" angedeutet, läßt sich die Datei in gewohnter Weise per Inline in die gesamte Kirchhofszene integrieren.
Listing 8.8
#VRML V2.0 utf8
# Datei IN_LOD.WRL: Level-of-Detail der Kirche
Group {
children [
LOD {
range [ 20, 40 ]
level [
DEF LOD_1 Group { # LOD_1
children [
...
DEF LOD_2 Group { # LOD_2
children [
...
DEF LOD_3 Group { # LOD_3
children [
...
]} # LOD
]} # Group
Im Knoten LOD der Datei ,,in_lod.wrl" wird über das Feld range ein Distanzwertebereich festgelegt, der für die Darstellung des Kirchengebäudes folgendes besagt: Ist die Distanz zwischen Cybernaut und Objekt kleiner als Wert 0 (20), dann zeige Objekt 0 (LOD_1); ist die Distanz größer als Wert 0 und kleiner als Wert 1 (40), dann zeige Objekt 1 (LOD_2); ist die Distanz größer als Wert 1, dann zeige Objekt 2 (LOD_3).
Aus der Zuordnung der Wertebereiche zu den LODs ergeben sich folgende Abhängigkeiten, die vom Worldbuilder berücksichtigt werden müssen. Die Anzahl der im Feld range anzugebenden Werte ist immer um eins geringer als die Anzahl der im Feld level aufgeführten LODs. Die einzige Ausnahme von dieser Regel sollte der völlige Verzicht auf die Angabe von Distanzwerten sein, um damit dem Viewer zu signalisieren, daß alleine aufgrund der Performancesituation aus den LODs auszuwählen ist. Für die Reihenfolge der LODs gilt, daß diese mit der detailliertesten Version beginnen und mit der einfachsten enden. Entsprechend steigen die korrespondierenden positiven Distanzwerte im Feld range an.
n Der Einsatz des LOD-Verfahrens sollte beim Worldbuilding wohlüberlegt sein. Erst wenn sich der Vorteil mehrerer Objekt-Versionen als groß genug erweist, sollte der Nachteil aufwendigerer Modellierung und längerer Übertragungszeiten in Kauf genommen werden. Neben der Größe der VRML-Datei ist auch die räumliche Ausdehnung der 3D-Szene bei den Überlegungen für einen sinnvollen LOD-Einsatz miteinzubeziehen. Liegen sämtliche Objekte einer Szene in unmittelbarer Nähe zueinander, eignet sich ein Wechsel zwischen LODs weniger als bei Szenen, in denen die Objekte über weite Distanzen verteilt sind. Insofern erweist sich der Einsatz von LODs in unserer Kirchturmszene nur bedingt als sinnvoll, da das Entfernen des Cybernauten von der Kirche dem Entfernen von der gesamten Szene gleichkommt. Läge die Kirche dagegen im Süden einer virtuellen Stadt, könnte sie beim Betrachten eines im Norden gelegenen anderen Gebäudes durchaus lediglich als LOD dritter Stufe erscheinen.