Derzeit wird die VFX-Welt mit zahlreichen Akronymen von Open-Source-Projekten der großen Hollywood-Studios überhäuft. Ein Beispiel ist OpenVDB von Dreamworks. Es steckt in Houdini und ein paar anderen Programmen und hat irgendetwas mit Volumen zu tun. Aber was genau kann man erwarten, wenn ein Progamm OpenVDB unterstützt?
Digital Production klärt auf und hat sich mit dem Chefentwickler Ken Museth auf der FMX 2014 in Stuttgart über die Technik und die Vor- und Nachteile des Open Source-Ansatzes unterhalten.
Eine fast leere Schachtel und die Unendlichkeit
Rauch- und Feuersimulationen nutzen normalerweise eine sogenannte Domain. Darin finden die Berechnungen statt und dort werden später die Volumen-Daten in sogenannten Voxeln- das sind dreidimensionale Pixel- gespeichert. Man muss sich das wie eine Schachtel vorstellen, in der die Simulation respektive später deren Ergebnis steckt. Dabei gibt es aber zwei Probleme: Zum einen ist die Domain endlich. Manche Programme begegnen diesem Problem, indem die Domain bei Bedarf größer und kleiner gemacht wird. Das andere Problem besteht darin, dass in den meisten Fällen weite Bereiche der Domain leer bleiben. Eine runde Rauchsäule wird eine eckige Domain im besten Fall zu 75 Prozent ausfüllen. Weht ein laues Lüftchen und die Rauchsäule ist dadurch ein wenig gebogen, ist weniger als die Hälfte der Domain ausgefüllt, und je nach Biegung der Rauchsäule reduziert der Effekt den „Füllstand“ schnell auf unter 10 Prozent. Oder nehmen wir als Beispiel eine runde Explosion in einer würfelförmigen Domain. Der Optimalfall wären hier 52 Prozent, aber das ist ja optimal und nicht real. Normalerweise wären auch in diesem Anwendungsfall weite Bereiche der Domain leer. Sprich: In der Schachtel ist eigentlich fast nichts drin- aber warum ist das ein Problem?
Den langen Weg umsonst gegangen
Erstens ist das ein Speicher-Problem. Auch wenn die Daten auf der Festplatte komprimiert gespeichert werden- im Arbeitsspeicher sind sie dann nicht mehr komprimiert und jede Zelle der Domain braucht Platz, auch die leeren Zellen. Ein 2D-Vergleich würde ein Bild mit fast ausschließlich schwarzen Pixeln und ein paar spärlich verteilten Objekten zeigen. Wenn man es unkomprimiert speichert, braucht dieses Bild genauso viel Platz wie ein detailliertes Foto mit der gleichen Auflösung.
Es gibt aber noch einen weitaus gravierenderen Nachteil, wenn man mit spärlich besetzen Voxel-Daten auf die traditionelle Art arbeitet, nämlich beim Rendern. Moderne Path-Tracer arbeiten mit Strahlen, die in eine Szene geschickt werden. Trifft ein Strahl auf eine Oberfläche, wird eine Berechnung durchgeführt. Bei Volumen ist das nicht so einfach. Hier trifft der Strahl auf eine Domain und erfährt, dass alles, was folgt, Volumen ist, bis die Domain zu Ende ist. Also dringt der Strahl in das Volumen ein. Nachdem er einen bestimmten Weg zurückgelegt hat, wird vereinfacht gesagt nachgesehen, ob an der Stelle zum Beispiel Rauch ist. In einem solchen Fall wird berechnet, ob der Strahl abgelenkt oder auf irgendeine Weise verändert wird oder einfach nur weiter eindringt. Gesetzt den Fall, dass ein Strahl eine Domain durchschritten hat, ohne dabei je auf Rauch gestoßen zu sein, dann ist er den ganzen Weg umsonst gegangen. Bis dahin hat er aber möglicherweise hunderte Lookup-Operationen durchgeführt. Verschwendete Rechenzeit. Und die Person vor dem Bildschirm ärgert sich vermutlich, weil das Rendern so lange dauert.
OpenVDB schlägt beide Fliegen mit einer Klappe, indem eine Datenstruktur genutzt wird, die man sich vereinfacht als Baum aus Micro-Domains vorstellen kann. Dieser kann beliebig groß werden und hinterlässt einen deutlich kleineren Fußabdruck im Speicher. In Bereichen, in denen kein Rauch ist, kommen Raytracing-Strahlen gar nicht erst auf die Idee, dass dort überhaupt welcher sein könnte. Es verwundert also nicht, dass ausgerechnet die Pathtracing-Engine Arnold zum Rendern von Volumen auf OpenVDB zurück greift.
Kurz: OpenVDB ermöglicht größere Simulationen bei höherer Auflösung, die schneller gerendert werden können.
Compositing-Toolbox für Volumen-Daten
OpenVDB ist aber nicht nur eine sehr effiziente Datenstruktur, sondern bringt auch eine Reihe von Werkzeugen mit, um diese Daten zu bearbeiten. Beispiele sind hier der berühmte Gaußsche Weichzeichner, Dilade und Erode, Boolsche Operationen und diverse Operationen zum Mischen von Volumen. Einfach gesagt: OpenVDB erlaubt Compositing mit Volumen-Daten. Mit seinem Node-basierten Bedienkonzept war Houdini natürlich prädestiniert dafür, OpenVDB von Anfang an zu integrieren.
Ein Mesher und Konvertierwerkzeuge sind auch mit von der Partie. Der Nutzer bekommt dadurch zum Beispiel die Möglichkeit an die Hand, eine partikelbasierte Flüssigkeitssimulation in ein VDB-Set zu konvertieren, diese dann mit den diversen Compositing-Werkzeugen zu bearbeiten und zu guter Letzt mit einem Mesh zu überziehen. Das erlaubt eine große Freiheit, das Aussehen der Flüssigkeit zu beinflussen, ohne immer wieder neu simulieren zu müssen.
Auch Meshes können mit OpenVDB zu Volumen konvertiert werden. Das Ergebnis kann dann zum Beispiel für volumetrisches Fracturing verwendet und danach zurück konvertiert werden. Das ist aber noch nicht alles. OpenVDB liefert zum Beispiel auch Werkzeuge zum Sculpten von Volumen, was sich beispielsweise für die Erstellung von Wolkenformationen nutzen lässt.
- Bild Zerstörung-
In welchen Tools steckt OpenVDB?
Insgesamt ist das Projekt sehr groß. Durch die Open-Source-Natur steht es jedem Hersteller frei, es in seine eigenen Programme zu integrieren, doch das erfordert einiges an Arbeit. Perfekt eingebunden ist OpenVDB nur in Houdini. Arnold nutzt es zum schnellen Rendern von Volumen-Effekten via Plugin, auch Pixars Renderman kann mit OpenVDB umgehen. Teile von OpenVDB finden sich in Realflow wieder. Für Maya hat Dreamworks einige Nodes für die Arbeit mit OpenVDB publiziert und in Blender wird seit Mitte letzten Jahres an der Integration von OpenVDB gearbeitet. Die Ergebnisse sind aber noch nicht in den Hauptzweig eingeflossen.
Dieser Artikel erschien im Magazin Digital Production, Ausgabe 1405. Herunterladen können Sie ihn hier als PDF. Darüber hinaus gibt es noch ein Interview mit Ken Museth, dem Chefentwickler bei Dreamworks Animation und Erfinder von OpenVDB.