VRML/X3D (Virtual Reality Modeling Language) unter Unix/Linux: 3D-Welten im WWW

Todsünden bei der Herstellung von Echtzeit 3D-Modellen

Die meisten 3D-Modeller sind entweder für CAD/CAM Arbeiten (Computer Aided Manufakturing also computerunterstützte Konstruktion und Fertigung) oder für Offline-Rendering-Verfahren (z.B. scanline rendering, Raytracing, Radiosity usw.) gebaut worden.

Beim Arbeiten mit CAD/CAM orientierten Programmen steht die Weiterverarbeitung an einer automatisierten Maschine (zum Beispiel einer Drehbank) im Vordergrund. Deswegen werden Daten normalerweise so abgespeichert, dass das entsprechende Modell auf hunderstel Millimeter genau hergestellt werden kann. Faktoren wie Dateigrösse oder die bildliche Darstellbarkeit dieser Daten sind hier nicht entscheidend.

Bei Offline-Rendering-Verfahren wird als Ergebnis einer Animation ein Videoclip berechnet. Der Unterschied, ob für die Berechnung eines Bilds zwei Minuten oder zehn Minuten gebraucht werden, ist hier nicht entscheidend.

Da VRML97 ein Echtzeit-Rendering-Verfahren benutzt, muss hier ein Bild mindestens in einer 1/8 Sekunde geliefert werden, damit eine Animation noch einen flüssigen Eindruck vermittelt (gehobene Ansprüche fordern 1/25 Sekunde pro Bild).
Die Regeln für Echtzeit-Rendering gelten nicht nur für VRML97, sondern auch für alle anderen VR-Programme, die auf Echtzeit-Visualisierungssoftware wie Java3D, OpenGL und seine Ableger Inventor, Iris Performer, plib usw. fussen.

Folgende Todsünden sollte man vermeiden:

Anzahl der Polygone zu hoch
Viel zu wenig Abstand zwischen Wänden
Viel zu viele Lichter

Todsünde 1: Anzahl der Polygone zu hoch

Bei Echtzeit-Rendering-Verfahren hängt die Zahl der Polygone einer noch flüssig darstellbaren Animation stark von der Graphikhardware ab. Als groben Anhaltspunkt kann man sagen, dass ein Rechner ohne 3D-Graphikkarte ungefähr wenige Tausend Polygone flüssig darstellen kann.
Ein aktueller Aldi-PC wird häufig mit einer 3D-Graphikkarte verkauft, die eine weit höhere 3D-Leistung ermöglicht.

Viele 3D-Modeller liefern per default sehr hohe Polygonzahlen, so dass zum Beispiel eine einfache Kugel aus Tausende von Polygonen aufgebaut ist.

Es ist zwar möglich, die Polygonzahl mit Hilfe von Software nachträglich zu reduzieren, aber das Ergebnis leidet in der Regel darunter.

Es ist auf jeden Fall vorzuziehen, die Polygonzahl schon im 3D-Modeller gering zu halten.

Geringe Polygonzahlen führen zu Problemen:

das 3D-Modell erscheint kantig
es fehlt an Oberflächenstruktur
die gewünschten Objekte sind mit niedrigen Polygonzahlen gar nicht modellierbar

Echtzeit-Rendering-Verfahren stellen für diese Probleme Lösungsmöglichkeiten zur Verfügung.

Sichtbare Kanten auf einem 3D-Modell sind nichts anderes als Übergänge zwischen verschiedenen Reflektionsrichtungen. Eine Reflektionsrichtung kann nach der bekannten Formel "Einfallswinkel gleich Ausfallswinkel" auch über Normalenvektoren dargestellt werden.

Üblicherweise steht so ein Normalenvektor immer senkrecht auf einer Fläche.
Bei einem aus Einzelflächen aufgebauten Körper können die Normalenvektoren auf den Eckpunkten angeordnet werden.

Verbiegt man jetzt benachbarte Normalenvektoren

so, dass sie übereinstimmen, verschwindet die sichtbare Kante.

In VRML kann dieses Glattbügeln von Normalenvektoren auf zwei verschiedene Arten erzeugt werden.
Erstens, indem die Normalenvektoren in einem Modeller berechnet und im VRML-File abgespeichert werden.
Zweitens, indem sie zur Laufzeit abhängig vom Winkel zwischen zwei Flächen berechnet werden. Einige Screenshots des VRML-Editors dune zeigen, was passiert, wenn dieser Winkel verändert wird.

Für Echtzeit-Rendering-Verfahren wie VRML97 wird der schwer fassbare Begriff des "Low-Polygon 3D Modellers" interessant.
Low-Polygon-Modeller werden zur Zeit vor allem bei der Erstellung von Echtzeit 3D Spielen verwendet.
Während Spötter sagen, dass sich typische Low-Polygon-Modeller vor allem durch ihre Langsamkeit herausheben (so dass 3D Modelle mit sehr vielen Flächen gar nicht erstellt werden können), kann man einige typische Eigenschaften festhalten:

Es stehen leistungsfähige Operationen zum Arbeiten mit einzelnen Flächen/Eckpunkten zur Verfügung.
Jedes später exportierte Polygon wird im Programm auch angezeigt.
Im Programm kann das Modell "normalen-glattgebügelt" betrachtet werden.
Die entsprechenden Flächennormalen können später in das Dateiformat exportiert werden.

Das Fehlen einer Oberflächenstruktur kann einfach dadurch ausgeglichen werden, dass man das Bild ("Textur") einer Oberflächenstruktur auf das 3D-Modell legt.
Hier ein Beispiel einer glatten Kugel, auf die das Bild einer sandigen Struktur aufgemappt wird.

Der VRML97-Standard, das Mitte der neunziger Jahre entstanden ist, erlaubt es nicht, mehrere Texturen zu überlagern (ausser man berechnet in einem Script-Knoten eine neue Textur aus mehreren anderen).
Viele Verfahren, die inzwischen von moderner 3D-Hardware gut unterstützt werden und auf Texturberechnungen beruhen (Bump-Map (eine Textur wird als Höhenwert interpretiert und wirft Schatten), Environment-Map (ein Bild der statischen Umgebung wird auf ein Objekt gelegt) oder Mip-Map (eine Art Switch-Knoten mehrerer Texturen)), bleiben deshalb aussen vor. In den neuen VRML200x und X3D-Standards gibt es Vorschläge für (Mehrfachtextur-) Erweiterungen.

Texturen haben allerdings einen kleinen Pferdefuss.
Geht man nahe an eine Textur heran, erkennt man eine blockartige Struktur, es sind die vergrösserten einzelnen Bildpunkte (Pixel).

Als Faustregel gilt, dass dieser Effekt auf jeden Fall vermieden wird, wenn die Grösse einer Textur so gross ist, wie der entsprechende Bildausschnitt.
Dabei sollte man beachten, dass aufgrund einer Einschränkung in OpenGL die Grösse der Texturen 2^n mal 2^n sein sollte (das gilt besonders für Movietexturen). Sonst kann es vorkommen, dass Texturen auf diese Grösse umgerechnet werden, was Zeit kostet und die Qualität beeinträchtigt.
Ausserdem gibt es bei älterer 3D-Graphikhardware Einschränkungen bei der maximal möglichen Texturgrösse (zum Beispiel 256x256 bei der Voodoo II).

Legt man eine ca. 1024x1024 Punkte grosse Bildschirmauflösung zugrunde (für ein Objekt, das den Bildschirm gerade ausfüllt), erreicht man leicht Datenmengen im Megabytebereich.
Zum Einen müssen diese Datenmengen bei einem Web3D-Verfahren erst mal über das Netzwerk. Obwohl hier Kompressionsbildformate wie zum Beispiel jpeg zum Einsatz kommen, bleiben die zu übertragenden Datenmengen unerfreulich gross.
Zum Anderen besitzen die meisten modernen 3D-Graphikkarten eigenen Speicher für Texturen. Reicht dieser Texturspeicher nicht mehr aus, verringert sich die Darstellungsgeschwindigkeit drastisch, zum Beispiel ruckeln dann timergesteuerten Animationen in VRML sehr stark.
Die meisten modernen 3D-Graphikkarten für Desktoprechner haben zwar 32 MB Texturspeicher und mehr, allerdings sind auch noch ältere Graphikkarten mit z.B. nur acht, vier oder einem Megabyte Texturspeicher im Gebrauch. Während 3D-Graphikkarten für Computerspiele schon immer möglichst viel Texturspeicher besassen, gibt es (ältere) 3D-Graphikkarten für den CAD Profieinsatz mit hoher Polygonleistung, die aber mit wenig oder sogar gar keinem Texturspeicher ausgestattet sind. Dabei kann der Prozessor durch die Texturberechnung sehr stark belastet werden.

Man kann recht schnell auf das Problem stossen, dass die gewünschten Objekte mit niedrigen Polygonzahlen gar nicht modellierbar sind.

Die einfachste Art der Optimierung von Polygonen ist, momentan nicht benötigte Polygone gar nicht erst darzustellen.
Es kann während einer Animation oder Interaktion vorkommen, dass 3D-Objekte zeitweise überhaupt nicht dargestellt werden müssen. Man könnte auf die Idee kommen, dieses Objekt innerhalb eines anderen Objekts zu verstecken. Trotzdem müsste bei der Darstellung zeitaufwendig überprüft werden, welche Flächen verdeckt sind und welche nicht. Stattdessen sollte man in dieser Situation das nicht benötigte Objekt mit Hilfe eines Switch-Knotens abschalten.

Mit Switch-Knoten kann man auch programmgesteuert zwischen verschiedenen Objekten umschalten.
Dies kann man dazu nutzen, angepasst an die Graphikhardware detaillierte oder vereinfachte 3D-Objekte zu präsentieren, da es möglich ist, in einem Script-Knoten die aktuelle Graphikperformance (über »Browser.getCurrentFrameRate«) zu messen.

Eine Variation dieses Verfahrens nennt sich »Level of Detail«.
Dabei werden Objekte (z.B. gegen eine stark vereinfachte Versionen) automatisch ausgetauscht, wenn der Betrachter einen bestimmten Abstand überschritten hat.
Beispielsweise benötigt eine überzeugende Darstellung eines Baums leicht Tausende von Polygonen. Damit wäre eine Allee von Bäumen ein Ding der Unmöglichkeit. Allerdings sind bei so einer Allee nicht alle Bäume gleichzeitig aus dem gleichen Abstand sichtbar. Aus der Ferne betracht werden aber weit weniger Polygone für eine überzeugende Darstellung benötigt.

Die Polygonzahlen sind hier:
1: 2744 Polygone
2: 1326 Polygone
3: 451 Polygone
4: 74 Polygone
5: 23 Polygone

Die Polygonzahlen sind hier:
3: 2744 Polygone
4: 1326 Polygone
5: 451 Polygone

Moderne Echtzeit-Rendering Methoden, die noch nicht Teil des VRML97-Standard sein können, versuchen sogar eine stufenlose Vereinfachung beim Level of Detail.
Wenn man keine stufenlose Vereinfachung beim Level of Detail hat, sollte man darauf achten, dass der Übergang nicht allzu deutlich abläuft. Im Beispiel wird dies für die vier am weitesten entfernten Objekte deutlich, da hier zu viele Polygone eingespart wurden.

Will man dagegen statt einer Allee einen Wald implementieren, hilft der Level of Detail nicht entscheidend weiter.
Die Lösung liegt im sogenannten »Billboard«. Hier dreht sich ein 3D-Modell immer so, dass nur seine Schokoladenseite sichbar ist. Die Orientierung lässt sich entweder (wie im folgenden Beispiel) an der Kameraorientierung oder drehbar an einer Achse ausrichten.
Im Beispiel sieht einen das Froschgesicht immer an, egal wie man herumnavigiert.

Ohne diesen Billboardeffekt sieht man dagegen sehr schnell, dass beim Froschgesicht die Rückseite eingespart wurde

Damit hat man zwar ungefähr die Hälfte der Polygone eingespart, für das Waldproblem, wäre das nicht ausreichend. Also geht man einen Schritt weiter.

Hier wurde das ganze Objekt durch ein Polygon mit einer teilweisen durchsichtigen Textur ersetzt.
Im Beispiel

ergibt sich eine gesamte Polygonzahl von 34.

Allerdings ist ein Billbord nicht immer so einfach einsetzbar. Eine Blick von oben auf einen Billboard-Wald würde entweder (bei Kameraorientierung) die Bäume flach auf den Boden legen, oder (bei Orientierung entlang einer Achse) den Trick verraten.

Trotzdem werden Billboards häufig eingesetzt.

Eine weitere Optimierungsmöglichkeit ergibt sich, indem man die Macrofähigkeiten von VRML97 (DEF/USE,PROTO) zu Hilfe nimmt, um gleichartige Objekte (wie die Bäume in einem Wald) zu implementieren. Damit kann der VRML-Browser den Rechenaufwand zusätzlich reduzieren.

Todsünde 2: Viel zu wenig Abstand zwischen Wänden

Bei der Berechnung einer 3D-Szene (»rendern«) taucht häufig die Fragestellung "welches Objekt ist vor oder hinter einem anderen Objekt" auf. Aufgrund von Rechenungenauigkeiten kann es vorkommen, dass diese Berechnung bei zuwenig Abstand zwischen zwei Wänden zu merkwürdigen Ergebnissen führt.

Dieser Effekt ist absolut unberechenbar, da er nicht nur von der verwendeten Software, sondern auch von der verwendeten 3D-Graphikkarte abhängen kann.
Bei dünnen geschlossenen Körpern kann es im Prinzip vorkommen, dass die Rückfläche wegen diesen Rechenungenauigkeiten "durchscheint". Bei dünnen einfachen Körpern ("Primitive", zum Beispiel einem Quader) kann dieser Effekt übrigens in VRML97 nicht auftreten, da deren Wände einseitig definiert sind, das heisst von hinten/innen betrachtet durchsichtig sind. Bei dünnen aus Einzelflächen zusammengesetzten Körpern ist deshalb anzuraten, ebenfalls Einseitigkeit einzuschalten.

Das Feld "ccw" (Counter Clock Wise) erlaubt es zusätzlich, festzulegen, welche Flächenseite sichtbar ist.

Todsünde 3: Viel zu viele Lichter

Da auch eine matte weisse Wand viel Licht zurückstrahlen kann, leben wir in einer Welt, die angefüllt ist mit direkten und indirekten Lichtquellen.

Die Simulation solcher natürlichen Beleuchtungsverhältnisse ist allerdings sehr rechenaufwendig und daher ganz klar eine Angelegenheit von Offline-Rendering-Verfahren wie Raytracing oder Radiosity.
In Echtzeit-Rendering-Verfahren muss auf diese Berechnung verzichtet werden, an Stelle der "echten" (spiegelnden) Reflektion steht der einfache Glanz, der als Materialeigentschaft den 3D-Objekten zugeordnet ist (»specularColor«).
Der VRML97-Standard kennt übrigens noch kein Environment-Mapping, bei dem ein statisches Bild der Umgebung auf ein sich bewegendes Objekt gelegt wird, um Spiegelung vorzutäuschen.

Dieser Screenshot einer Standard VRML97-Welt zeigt keine Spiegelung. Zum Beispiel müsste sich der Pinguin in den glänzenden Säulen spiegeln. Statt einem Pinguin über einer spiegelnden Fläche sieht man hier einen Pinguin, eine halbtransparente Fläche und einen spiegelverkehrten Pinguin.
Die Tatsache, dass bei Echtzeit-Rendering-Verfahren kein Licht von Objekten zurückgeworfen wird, verführt dazu, zu viele Lichtquellen in eine Szenerie einzubauen.
Beim Film "Toystory II" (Pixar/Disney) wurde für viele Szenen ein Offline-Rendering-Verfahren benutzt, das keine "echten" (spiegelnden) Reflektionen kennt.
Um eine realistische Beleuchtung zu erreichen, wurden deshalb in einigen Szenen mehr als 180 Lichtquellen benutzt.
Die Tatsache, dass Pixar/Disney zu dieser Zeit den schnellsten nichtstaatlichen Parallelrechner der Welt besass, macht deutlich, dass an eine Berechnung solcher Szenen in Echtzeit noch nicht zu denken ist.
Der VRML97-Standard (und auch der OpenGL Standard) fordert, dass ein Browser nur 8 Lichter darstellen muss, selten unterstützt auch aktuelle 3D-Hardware mehr.
Lichter sind also ein sehr kostbares Gut, die man effektiv einsetzen sollte.
Deswegen sollte man keine Lichter für etwas verschwenden, das auch sich auch ohne Lichter implementieren lässt.
Die Implementierung räumlich ausgedehnter Lichtquellen ist auch für die Offline-Rendering-Verfahren keine leichte Aufgabe.
Um einen ungefähr ähnlichen Effekt zu erreichen, wurde in VRML97 die sogenannte "emissiveColor" als Materialeigenschaft den 3D-Objekten zugeordnet. Schaltet man in einem typischen Raytracer alle Lichter ab, ist alles schwarz. Anders in VRML97. Hier sind weiterhin alle Objekte zu sehen, deren "emissiveColor" nicht schwarz ist. Der beabsichtigte Eindruck ist, vorzuspiegeln, diese Objekte würden von innen glühen.
Gleiche Szene mit

und ohne Beleuchtung.

Eine andere mögliche Quelle für Lichtspareffekte sind Texturen. Im folgenden Beispiel

wirkt das Billboard einer ebenen Fläche mit einem mit Povray (ein im Unix/Linux-Bereich weit verbreitetes Offline-Rendering-Programm) berechneten Bild aufgrund der Beleuchtungseffekte fast plastischer als 3D-Objekt neben ihm. Sechs ebenfalls mit Povray berechnete Einzelbilder bilden hier den Hintergrund (diese Art von Bildern werden übrigens beim Environment-Mapping eingesetzt).
Eine weitere Lichtsparmassnahme besteht darin, Lichter nur auf bestimmte Körper (im gleichen Zweig des Szenengraph) wirken zu lassen.
Dadurch vermeidet man viele Lichtquellen aufstellen zu müssen, um einen unregelmässigen Körper in einer unbeleuchteten Umgebung auszuleuchten.

In diesem Bild liegen drei Kugeln mit gleichen Materialeigenschaften in einer Reihe. Da nur 2 Kugeln im gleichen Zweig des Szenengraphen wie die Lichtquelle liegt, werden nur diese Kugeln beleuchtet.

Zu Licht gehört auch Schatten. In unserer von direkten und indirekten Lichtquellen beleuchteten Welt treten Schatten meist mit "weichen" Rändern auf. Die Berechnung solcher weichen Schatten ist wiederrum eine Aufgabe von Offline-Rendering-Verfahren. Echtzeit-Rendering-Verfahren ermöglichen zwar inzwischen die Berechnung von "harten" Schlagschatten einer Lichtquelle mit Unterstütung von 3D-Hardware, allerdings ist dies nicht in den VRML97-Standard eingeflossen.

Dieser Screenshot einer Standard VRML97-Welt zeigt keinen "harten" Schattenwurf. Es befindet sich keine Lichtquelle über dem Pinguin, die Lichtquelle ist an der Stelle der Kamera. Statt einem Pinguin und seinen Schatten auf einer Fläche sieht man hier einen Pinguin, eine halbtransparente Fläche und einen spiegelverkehrten, komplett schwarzen Pinguin.
Anstelle von Schatten tritt in VRML die Schattierung. Abgerundete Objekte wirken deshalb oft "schöner" als kantige. Die Position des Lichts hat grosse Auswirkung auf die Schattierungen. Kommt das Licht wie hier

aus Richtung der Kamera ("Headlight"), werden die sichtbaren Flächen voll beleuchtet, es zeigen sich wenig Schattierungen. Einzeln im Raum positioniertes Licht (hier ein Punktlicht) wirken oft attraktiver.

Allerdings kann es hier passieren, dass der Betrachter durch Navigation in eine Lage gerät, bei der, wie im folgenden Beispiel,

diese Lichtquellen verdeckt sind. Um dieses Problem zu vermindern und um Geometriedaten ohne Beleuchtungsinformation einfach darstellen zu können, hat man sich beim VRML97-Standard dafür entschlossen, das Headlight in der Kamera per default einzuschalten. Um dieses Headlight abzuschalten, benötigt man einen »Navigationinfo«-Knoten.
Viele VRML-Browser bieten zusätzlich dazu die Möglichkeit, das Headlight abzuschalten.

Ausblick

Für Echtzeit-Rendering-Verfahren ist die 3D-Unterstützung der Graphikkarte entscheidend. Seit geraumer Zeit kann man einen Trend der Graphikkartenhersteller beobachten, Effekte zu implementieren/vorzutäuschen, die man bisher nur bei Offline-Rendering-Verfahren erwarten würde.
Dazu zählen das Vorzutäuschen von Spiegelung, indem ein statisches Bild der Umgebung auf ein Objekt gelegt wird, "weich gespülte" harte Schatten, sogar Lichtbrechungseffekte und anderes.

weiter: Schwächen/Vorurteile gegen VRML

Veröffentlicht unter der GNU GENERAL PUBLIC LICENSE Version 2
TUX Daten (abgeleitet) von "A QUEST FOR HERRING" by Steve Baker (GPL)