VRML97 exportieren mit formZ v 4.0.3 Windows

Dieses Dokument beschreibt einige Kniffe um mit dem 3D Modeller/CAD Werkzeug "formZ v 4.0.3 Windows 2000 Intel"
Dateien im VRML97 (Virtual Reality Modelling Language, "HTML für 3D", "OpenGL für Doofe) Format zu exportieren.

Warum ist dabei ist dabei die Versionsnummer so wichtig ?
Vieles an diesem Dokument beschreibt zum grossen Teil Workarounds um Probleme, die man im weiteren Sinne als Programmfehler ansehen kann.

Eine angenehme Eigenschaft von Programmfehlern ist, dass sie auf lange Sicht verschwinden 8-)

Eine unangenehme Eigenschaft von Programmfehlern ist, dass ihre Behebung häufig neue, bisher bisher nicht bekannte Programmfehler aufreisst 8-(

Aus diesem Grund kann man nicht unbedingt davon ausgehen, dass anderen Programmversionen von formZ ein ähnliches Verhalten zeigen.
Dieses Dokument ist also nicht als "so muss es sein" zu verstehen, sondern als "so hat das mal getan".

Exportprobleme bei durchbrochenen Flächen

Eine durchbrochene Fläche (mathematisch exakt: kein "einfach zusammenhängendes Gebiet") kann bei einigen Operation beim Modellieren in formZ entstehen, zum Beispiel beim boolschen Modellieren, bei dem Volumenkörper voneinander abgezogen werden. So kann man zum Beispiel 2 verschiedene Quader modellieren

und voneinander abziehen

so dass eine durchbrochene Fläche einsteht.
Wird dieses Objekt "ganz Normal" nach VRML exportiert (bei den Optionen muss "VRML Options Version v2.0" für VRML97 angewählt werden)

so sind beim Preview in einem VRML-Browser wie zum Beispiel Cortona in der Regel keine Probleme zu sehen.

Beim Betrachten mit dem graphischen VRML97 editor white_dune zeigen sich dagegen Probleme.

Ein Umfärben der einzelnen Flächen des Objekts zeigt, dass die durchbrochene Fläche wirklich als einzelne Fläche exportiert wurde.

Man kann sich jetzt fragen, ob die exportierte VRML fehlerhaft ist (immerhin zeigt auch der VRML-Browser cosmoplayer Probleme und im Abschnitt 4.6.3.4 (Shape hint fields) des VRML ISO Standard Dokuments steht: "Non-planar and self-intersecting polygons may produce undefined results even if the convex field is FALSE.") aber der 3D Preview von white_dune (Version 0.27) ist seinerseits nicht besonders vertrauenswürdig.
Weit wichtiger ist die Tatsache, dass der VRML Broswer "cover/covise" für Mehrwandprojektionssysteme (das eigentliche Zielsystem für die VRML Dateien des Kurses) unter dem selben Problemen leidet (jedenfalls in den gebräuchlichen Versionen von Winter 2004).
Zur Lösung des Problems müssen bei den VRML Exportoptionen die Schalter "Subdivice Concave Faces" und "Triangulate Faces" eingeschalten werden und im "Triangulate Options" der Schalter "Strict Planarity Test" aktiviert werden.

Danach funktioniert auch der Preview in white_dune bzw. cosmoplayerund ein Umfärben der Einzelflächen zeigt, dass jetzt die durchbrochene Fläche in mehrere Flächen zerteilt wurde.


Exportprobleme beim Versuch, vorberechnete Texturen zu exportieren

Eines der stärksten Features von FormZ beim Export von VRML ist die Möglichkeit Texturen auf den Objekten mit Hilfe des Radiosity Renderers von FormZ herzustellen.
Texturen nennt man zweidimensionale Bilder, die man auf 3D Objekte klebt, um Struktur vorzutäuschen.
Bei Echtzeit-3D-Verfahren wie VRML (und damit auch bei anderen VR-Verfahren bzw. 3D-Spielen) muss mindestens innerhalb von einer 18-tel bis 25-tel Sekunde ein Bild erzeugt werden, da sonst beim freien Navigieren innerhalb der Szene alles zu ruckeln anfangen würde.
Zum Vergleich kann für die Berechnung eines Einzelbildes ("rendern") eines mit FormZ hergestellten Films mehrere Minuten (oder sogar Stunden) aufgewendet werden, ohne dass das irgendwelche Auswirkungen auf das Endprodukt hat ("Offlinerendering").
Während bei Echtzeit-3D-Verfahren 8 einfache Echtzeit-Lichtquellen die absolute Obergrenze bei bezahlbaren Graphikkarten sind, werden bei Radiosity Render ("Abstrahlungsbildberechnung") Verfahren auch indirekte Lichtquellen berücksichtigt.
Ein Beispiel für eine indirekte Lichtquelle ist eine weisse Wand, die zweifellos Licht zurückwirft. Ein weiteres Beispiel ist der Mond, der lediglich von der Sonne beleuchtet wird, aber nicht selber leuchtet.
Da die Welt, in der wir leben, voll von indirekten Lichtquellen ist, kann man sich vorstellen, dass die Beleuchtungsberechnung beim Echtzeit-3D-Verfahren keine Ergebnisse von der selben Qualität erzeugen kann, wie ein Radiosity Render Verfahren.
Der Plan ist also, 3D Objekte mit Bildern zu bekleben, die mit Hilfe eines Radiosity Render Verfahrens vorberechnet wurden und die Echtzeit-Lichtquellen nur dort expliziet einzusetzen, wo sie absolut notwendig sind (zum Beispiel um das Flackern einer Kerze vorzutäuschen oder wenn eine Fackel durch eine dunkle Höhle bewegt wird).
FormZ ist in der Lage, diese Vorberechnung von Texturen durchzuführen, allerdings stösst man dabei auf ein ernstzunehmendes Problem:
FormZ (4.03 für Windows) zerlegt dazu alle Objekte in ebene Einzelflächen.

Ein gewöbtes Objekt wie zu Beispiel dieser Torus ("Donut") wird dabei in extrem viele Einzelflächen zerlegt,

deswegen führt ein Versuch VRML97 mit "Textures: Rendered" zu exportieren

zu solchen Datenmengen, dass sich diverse Werkzeuge leicht daran verschlucken können.
Versucht man zum Beispiel, das erzeugte 3D-Objekt mit white_dune zu öffnen, erscheint die Anwendung im Taskmanager wie abgestürtzt

Ein genauerer Blick zeigt allerdings, dass white_dune lediglich versucht, diese Datenmengen zu laden und dabei kein Ende findet.

Auf diese Weise kommt man in der Regel nicht weiter.

Der neue Plan muss also sein, die Texturvorberechnung lediglich für umfangreiche, ebene Flächen durchzuführen, da dies die Einschränkungen umgeht und diese Flächen ohne Textur beim Echtzeitrendern besonders langweilig/unnatürlich aussehen.
Dazu gibt es eine Option "Only Render Picked Objects or Faces", im Notfall kopiert man die FormZ Datei und löscht jeweils alle unpassenden Flächen.
Bei einem Modell eines Hauses sind also die ebenen Hauswände gute Kandidaten für die Texturvorberechnung, während zum Beispiel für Fensterrahmen (besonders für gewöbte Fensterrahmen) weniger problematische Texturierungsverfahren (zum Beispiel "Textures: wrapped" oder "Textures: off" und Texturierung mit einem VRML Werkzeug) eingesetzt werden sollten.
Bei einer gewölbten Dachfläche müsste man Konzessionen eingehen.
Mit Hilfe des Meshreducers in FormZ könnte man die Anzahl der Einzelflächen auf ein erträgliches Mass zurechtstutzen.

Vor dem VRML-Export mit formZ ist es sowieso eine gute Idee, über die Benutzung des Meshreducers nachzudenken, da die Anzahl der von den Werkzeugen noch verkraftbaren Einzelflächen (Polygonzahl) prinzipell beschränkt ist. Die harte Grenze der maximalen Polygonzahl gibt die verwendete Graphikkarte des Zielsystems vor. Ist das Zielsystem ein Bürorechner ohne 3D Beschleundigung in der Graphikkarte, liegt die harte Grenze bei einigen 1000 Polygonen. Für cover/covise im Vier-Wand-Projektionssystem gilt zur Zeit als Faustregel, dass Welten mit 50000 Polygonen noch verkraftet werden.

Für den Torus des Beispiels muss man ebenfalls den Meshreducer benutzen:

Das Ergebnis lässt sich mit folgenden Optionen exportieren:

Diese Optionen gelten nur für "formZ v 4.0.3 Windows", mit anderen Optionen (oder anderen Programmversionen) können sich alle Arten von Fehler zeigen.
Zum Beispiel:

Wenn der Export funktioniert hat, werden die Texturen benutzt (hier "tex11814") und die Punkte der Einzelflächen sind nicht alle gleich Null.

Man sieht auch, dass die Festlegung der Eckpunkte (coordIndex) ist nicht leer ist

Betrachtet man das Objekt, so fällt auf, dass in der Nähe des hinteren Teils der Bohrung durch den Torus (und an der Unterseite) die Farben dunkler sind. Das sind die Auswirkungen der vorgerechneten Beleuchtung. Dieser Effekt ändert sich auch dann nicht, wenn man ein Echtzeitlicht in der Nähe dieser Stelle bewegt.

Mit Hilfe einiger Texturtrümmer und Nachbearbeitung von Hand lässt sich zeigen, dass eine Zerlegung in Einzelflächen ist nicht unbedingt notwendig wäre. Eine bessere Exportfunktion bräuchte nur wenige Flächen und müsste die Texturkoordinaten anpassen.

Allerdings ist die Berechnung der Texturkoordinaten im Allgemeinen (zum Beispiel bei einem Objekt mit Bohrungen wie dem Torus) ausserordentlich schwierig...
Es lässt sich auch zeigen, dass die exportierten Texturen nicht an allen Stellen perfekt aufeinanderpassen

Das hängt vermutlich mit den Meshreducer zusammen....

Veröffentlicht unter der GNU GENERAL PUBLIC LICENSE Version 2