Auf der FMX 2O14 haben wir die Gunst der Stunde genutzt und uns mit Ken Museth unterhalten, dem Chef der R&D-Abteilung für VFX bei Dreamworks Animation und Erfinder von OpenVDB.
BD: Hallo Ken, derzeit arbeitest du bei Dreamworks Animation. Was genau machst du dort, an welchen Projekten arbeitest du und wie sieht deine Beteiligung an OpenVDB aus?
Ken Museth: Ich arbeite seit 2009 bei Dreamworks Animation in der Gegend um Los Angeles. Ich bin der Leiter der Abteilung Forschung und Entwicklung für VFX und leitender Ingenieur. Ich leite ein Team von Forschern, die Werkzeuge für die Erstellung von Animationen entwickeln. Ich bin aber auch selbst ein Entwickler. Wie ich an VDB beteiligt bin? Nun, ich habe VDB im Jahr 2009 erfunden und die Ergebnisse publiziert. Seither wurde es Stück für Stück verbessert und 2011 wurde es zur Siggraph, der weltgrößten Konferenz für Computergrafik, veröffentlicht. Meine Gruppe arbeitet hauptsächlich daran, OpenVDB instand zu halten, zu verbessern und in regelmäßigen Abständen neue Versionen herauszubringen.
BD: Aus der Sicht eines normalen Nutzers – was kann man erwarten, wenn eine Applikation OpenVDB unterstützt?
Ken Museth: Lass uns das im Kontext der Art von Volumen betrachten, die seit vielen Jahren genutzt werden, auch in Software von Drittanbietern. Das sind normalerweise sogenannte "dichte Gitter" respektive "Dense Grids". Dabei hat der Nutzer eine Art Schachtel und die Effekte sind darauf beschränkt. Außerhalb der Schachtel finden keine Simulation und kein Rendering statt. Die Größe der Schachtel hat starken Einfluss auf die Menge an Speicher, die der Computer dafür braucht. Je mehr man die Auflösung der Schachtel vergrößert, desto mehr Voxel finden sich darin. Voxel bezeichnen Pixel mit drei statt zwei Dimensionen. Das Problem ist also, dass diese Dense Grids eine große Menge an Speicher benötigen. Was VDB erlaubt, ist, diese Schachtel weg zu werfen. Es erlaubt dir, Informationen auf eine Art und Weise zu speichern, die sehr kompakt ist.
Für den Endbenutzer bedeutet dies höhere Auflösung und mehr Details bei Simulationen wie Rauch, Feuer oder Wasser. Für viele volumetrische Anwendungen, besonders wenn sie dünn besetzt sind, ist VDB eine sehr gute Option. Seit 2012 ist OpenVDB in Houdini integriert. Wer Version 12.5 oder höher von Houdini einsetzt, verwendet intern OpenVDB.
Die meisten Effekte, die in der VFX-Abteilung erstellt werden, nutzen auf die eine oder andere Weise Volumen. Wir haben typische volumetrische Effekte wie animierten Staub, Rauch, Wasser, Feuer und sogar die Zerstörung von Objekten. Viele Effekte, die von außen gar nicht danach aussehen, können Volumen beinhalten. Dazu zählen Rigid Body Dynamics und, wie schon erwähnt, die Zerstörung von Objekten. Volumen lassen sich dazu nutzen, um zu verhindern, dass sich Objekte überschneiden. Dazu zählen Techniken zur volumetrischen Kollisionserkennung und -auflösung. Ein anderes Beispiel sind Rendering-Applikationen, die ebenfalls an vielen Stellen Volumen einsetzen. Die VFX-Abteilung benötigt also Volumen in vielen Bereichen.
BD: OpenVDB wird von zahlreichen Software-Herstellern unterstützt...
Ken Museth: Arnold hat OpenVDB-Unterstützung über ein Plugin hinzugefügt, es kann auch in Pixars Renderman eingesetzt werden. Realflow verwendet intern OpenVDB. Es wird von vielen Programmen eingesetzt. Das war einer der Hauptgründe, warum Dreamsworks VDB als Open Source herausbrachte: damit Fremdfirmen es für uns in ihre Produkte integrieren. Das gibt uns mehr Zeit für andere Entwicklungen. Man glaubt es nicht, wie viel Zeit wir normalerweise damit verbringen, Werkzeuge in unsere Pipeline zu integrieren. Dazu gehören die Entwicklung von Benutzeroberflächen, spezielle Skripte und andere Arten von Support-Arbeiten. Diese Aufgaben benötigen sehr viel Zeit. Indem andere Firmen diese Arbeit machen, können wir andere Entwicklungsaufgaben übernehmen, wie zum Beispiel OpenVDB voran zu bringen. Dadurch, dass SideFX OpenVDB in Houdini integriert hat und nicht wir, ist bei uns zum Beispiel sehr viel Zeit frei geworden, die wir sogleich für die weitere Entwicklung genutzt haben.
BD: Das ist einer der Vorteile, ein Produkt als Open Source herauszubringen. Gibt es auch Nachteile?
Ken Museth: Einer der Nachteile ist, dass es viel Zeit braucht. Wir verbringen viel Zeit damit, die Softwarequellen zu verwalten, Build-Systeme zu pflegen, Dokumentation zu schreiben et cetera.
Es gibt auch einiges an Druck aus der Open-Source-Gemeinschaft. Wir bekommen häufig Anfragen nach neuen Funktionen. Eine häufig gestellt Frage ist zum Beispiel: „Warum unterstützt ihr kein Windows?“. Solche Anfragen muss man immer damit vergleichen, was Dreamworks eigentlich will. Wir setzen überhaupt kein Windows ein, sondern nutzen Linux-Maschinen. Also haben wir auch kein Interesse daran, Windows als Plattform zu unterstützen. In diesem Fall hatten wir aber Glück, da SideFX Windows unterstützt und sie sich darum kümmern. Mit diesem Druck umzugehen sowie die viele Zeit, die dafür draufgeht, sind für uns zwei der größten Nachteile an einem Open-Source-Modell. Aber die werden von den Vorteilen mehr als ausgeglichen.
Der größte ist, wie bereits erwähnt, dass OpenVDB an allerlei Stellen eingesetzt wird, wir uns aber nicht um die Integration in all diese Werkzeuge kümmern müssen und unsere Zeit besser für andere Entwicklungsaufgaben verwenden können.
Ein anderer Vorteil liegt in der Natur von Open Source an sich. Es ist einfach ein sehr guter Weg, um mit anderen Filmstudios und Leuten aus dem akademischen Bereich zusammenzuarbeiten. Wir haben da ein Stück Software ohne Probleme und Hürden mit geistigem Eigentum, das jeder nutzen und an dem jeder mitarbeiten kann. Manchmal nehmen Forschungsgruppen an Universitäten OpenVDB als Grundlage für ihre Forschungsarbeiten und manche ihrer Ideen und Resultate können zurück in OpenVBD fließen.
BD: Der Ingenieur eines anderen Open-Source-Projekts aus dem VFX-Umfeld sagte, dass Open Source nicht wirklich billiger sei als herkömmliche Inhouse-Entwicklung, aber auch nicht teurer. Was ist dein Bauchgefühl?
Ken Museth: Da würde ich ihm zustimmen, es ist nicht teurer. Aber viel wichtiger: Es hebt die Qualität! Der Code wird so einfach viel besser, als wenn man nur für sich selbst entwickelt. Du teilst ihn mit der gesamten Welt, jeder kann ihn sich ansehen. Das ist ein riesiger Ansporn, die Qualität sowohl des Quellcodes als auch der Dokumentation so gut wie nur möglich zu halten. Und das zahlt sich später aus, denn es ist viel einfacher, ein Projekt instand zu halten, das gut dokumentiert ist und eine saubere API hat.
BD: Das ist genau das, was uns Larry Gritz gesagt hat, als er mit uns über seine Erfahrungen mit der Öffnung des Open-Shading-Language-Projekts gesprochen hat. Er hat auch noch angemerkt, dass die Veröffentlichung als Open Source die Entwickler vor ein Publikum stelle. Ist das eher gut oder eher schlecht, wenn man deswegen viele E-Mails bekommt?
Ken Museth: Genau so sieht es aus! Aber um ehrlich zu sein: Als wir das Projekt angefangen haben, wussten wir gar nicht, worauf wir uns da einlassen. Es war eine Art Überraschung für uns, aber eine wirklich gute. Wir haben Entwickler bei Dreamworks, die haben sich unseren Code angesehen und meinten, das wäre das sauberste Stück Software, das sie im gesamten Studio je zu Gesicht bekommen hätten. Und das ist genau das, was wir erreichen wollten.
BD: Bekommt ihr ansonsten auch viel Lob oder eher Kritik?
Ken Museth: Ich denke, eines der größten Probleme mit OpenVDB ist, dass es sehr viel „Template Metaprogramming“ nutzt. Es ist gut dokumentiert, aber wenn man diese Art des Programmierens nicht gewohnt ist, wird die Einarbeitung in den Quellcode ziemlich schwierig. Und wenn man dann noch bedenkt, dass VDB an sich, also die Datenstruktur, auch ein wenig kompliziert ist, verwundert es nicht, dass wir nur von recht wenigen Leuten Beiträge zum Kern der Bibliothek bekommen haben. Ich glaube, das liegt daran, dass die Interna einfach ein wenig einschüchternd sein können. Es ist nicht einfach anzufangen und mit der Datenstruktur zu arbeiten. Die meisten Beiträge, die wir bekommen haben, sind Werkzeuge, die auf der Datenstruktur aufsetzen, was natürlich auch sehr nützlich ist.
BD: War es schwierig, OpenVDB als Open Source zu veröffentlichen?
Ken Museth: Mit Sicherheit! OpenVDB war das erste und bisher einzige Open-Source-Projekt von Dreamworks Animation. Es hat fast zwei Jahre gedauert, um die Erlaubnis zu erhalten. Die meisten Leute haben uns sehr unterstützt, sodass wir mit diesem Projekt zu keinem Zeitpunkt an die Wand gefahren sind. Aber die Rechtsabteilung hat sehr lange gebraucht, bis sie ihr Okay gab. Die Unterstützung durch Drittanbieter war das wichtigste Verkaufsargument. Die Tatsache, dass wir von SideFX unterstützt wurden, hat auch sehr geholfen.
BD: SideFX war von Anfang an dabei?
Ken Museth: Ja, wir haben eng mit Entwicklern von SideFX zusammen gearbeitet. Sie haben sich den Code angesehen und Änderungsvorschläge unterbreitet.
BD: Welche Software von Drittanbietern sollte deiner Meinung nach OpenVDB einsetzen?
Ken Museth: Wir würden OpenVDB zum Beispiel gerne in Maya und Blender sehen. Das sind die beiden wichtigsten Drittanbieter-Projekte, in denen wir uns OpenVDB wünschen. Wir haben eine grundsätzliche Unterstützung für Maya, da haben wir sogar ein paar Nodes veröffentlicht. Aber bei uns wird Maya nur wenig für volumetrische Effekte eingesetzt, darum wünschen wir uns, dass jemand aus der Open-Source-Gemeinschaft die Integration in Maya übernimmt.
BD: Plant ihr GPU-Unterstützung?
Ken Museth: Das ist eine sehr gute Idee. Wir haben das noch nicht und es ist auch nicht so ganz klar, wie wir das erreichen können. OpenVDB ist stark für normale Prozessoren optimiert und Grafikkarten haben eine komplett andere Architektur. Es ist keine leichte Aufgabe, aber es wäre auf jeden Fall ein sehr interessanter Weg, den wir da gehen würden. Wir stehen bereits in Kontakt mit nVidia. Dort wurde uns zurückgemeldet, dass sie erste Erfolge mit der Portierung auf Cuda haben. Ich vermute aber, dass wir einige Änderungen durchführen müssten. Wir haben inhouse einen GPU-basierten Renderer, der grundsätzlich mit OpenVDB umgehen kann. Aber der wandelt es einfach nur in eine herkömmliche
Gitterstruktur um, bevor die Daten in den Speicher der Grafikkarte geladen werden.
Die kurze Antwort ist: GPU-Unterstützung ist etwas, das wir uns näher ansehen wollen.
BD: Welche anderen Pläne habt ihr? Vielleicht eine Datenstruktur zum Speichern von Partikeln?
Ken Museth: Ja, Partikeldaten sind ein großes Problem, an dem wir derzeit arbeiten. Während der Arbeiten am kommenden „Drachenzähmen leicht gemacht 2“ standen wir häufiger vor dem Problem, riesige Mengen an Partikeldaten in VDBs zu konvertieren. Wir reden hier von Bereichen von bis zu 300 Millionen Partikeln. Da haben wir gemerkt, dass unsere existierenden Werkzeuge einfach nicht ausreichen. Also haben wir angefangen nach Wegen zu suchen, die Partikelinformationen in den selben Baumstrukturen zu speichern, in denen normalerweise die VDB-Daten abgelegt werden. Damit konnten wir einige Erfolge vorweisen. Wir hoffen, dieses Jahr im Sommer zur Siggraph OpenVDB 3.0 vorstellen zu können. Das Speichern von Partikeldaten wäre ein Teil davon. Es handelt sich hierbei auch um ein interessantes Projekt, da es das erste Mal ist, dass wir eine offizielle Kooperation mit einem anderen Studio eingehen. Ein Forscher von Double Negative wird zu uns kommen und mit uns daran arbeiten. Wir denken aber auch an Level of Detail (LoD). Wir suchen nach Wegen, unterschiedliche Auflösungen der Volumendaten zu speichern, damit ein Renderer anhand des Kamera-Abstands leicht die richtige Auflösung aussuchen kann.
Wir wollen auch Werkzeuge zur Modellierung von Wolken haben und arbeiten an Out-of-Core-Loading. Dann wird nicht das gesamte Volumen beim Rendern geladen. Vielmehr soll OpenVDB das dynamische Nachladen managen, wenn Strahlen von der Kamera unterschiedliche Bereiche in der Szene treffen und nur diese Bereiche laden.
BD: Bist du der Ansicht, dass Rendern auf der GPU in Hinblick auf die Speichervoraussetzungen überhaupt brauchbar sein wird?
Ken Museth: Die Volumen, mit denen wir hantieren, haben normalerweise kaum mehr als ein paar Gigabytes. So lange die Grafikkarte so viel RAM hat, sollte es möglich sein.
BD: Und wie sieht es mit verteiltem Rendern über das Netzwerk aus?
Ken Museth: Darüber haben wir nachgedacht, aber das ist nichts, was wir bei Dreamworks normalerweise machen. Wir haben natürlich eine Renderfarm, aber jeder Node bekommt eine vollständige Kopie der Szene. Ich denke, OpenVDB könnte diese Form des Renderns gut handhaben, da es ein „Tile Grid“ ist. Die Blattknoten könnten auf viele verschiedene Computer verteilt werden. Ich habe gehört, dass es ein Studio gibt, das diese Idee tatsächlich verfolgt, und zwar für Flüssigkeitssimulationen. Es hat bestätigt, dass es funktioniert.
BD: Gibt es noch andere Projekte bei Dreamworks, von denen du denkst, dass eine Veröffentlichung als Open Source Vorteile bringen könnte?
Ken Museth: Wir haben damals über einige Projekte gesprochen, aber ich denke da ist nichts weiter in der Pipeline. Wir hatten uns auch überlegt, vor OpenVDB ein anderes Projekt als Testballon zu veröffentlichen. Momentan weiß ich aber von keinem Open Source-Projekt, das ansteht. Ich wäre aber nicht überrascht, wenn doch eines herauskommt, wenn man bedenkt, was für einen Erfolg wir mit OpenVDB hatten.
Dieses Interview erschien im Magazin Digital Production, Ausgabe 1405. Den zugehörigen Artikel zu OpenVDB finden Sie hier auf BlenderDiplom. Herunterladen können Sie Artikel und Interview hier im PDF-Format.