Fast jede große Render Engine, die auf Path Tracing basiert – dazu gehören z.B. Arnold und Cycles –, unterstützt inzwischen auch die Open Shading Language (OSL – Artikel in DP 04:18) für die Definition von Shadern und prozeduralen Materialien. Bei Image Engine wird OSL aber für deutlich mehr als den ursprünglichen Einsatzzweck verwendet, z.B. für Compositing, die Generierung von Volumen via OpenVBD oder zur prozeduralen Modellierung und Animation.
Image Engine arbeitet dabei nicht im stillen Kämmerlein. Vielmehr kann man die so entstandenen Werkzeuge direkt im Look-Dev-Progamm Gaffer ausprobieren. Die Software wurde in einigen großen Hollywood-Produktionen wie „Thor: Ragnarok“ oder „Fantastische Tierwesen: Grindelwalds Verbrechen“ eingesetzt, ist Open Source und kann für Linux sowie Mac OS heruntergeladen werden.
Nicht noch eine Sprache
Aber wie kam Image Engine auf die Idee, OSL für so viele Anwendungsbereiche einzusetzen, wenn es doch im Kern eine Shader-Sprache ist? Mit der gleichen Idee haben auch die Entwickler von Blender bereits gespielt, und das aus dem gleichen Hauptgrund: nicht zu viele Sprachen ins Paket lassen. Bei Blender ist der Gedanke, OSL für Compositing einzusetzen, da es bereits in Cycles unterstützt wird und Blender-Nutzer keine weitere Programmiersprache erlernen müssen. Bisher wurde der Plan noch nicht umgesetzt, bei Image Engine hingegen ist man schon viel weiter gegangen.
C++, Python, OSL
Im Kern ist Gaffer in C++ geschrieben, für das Interface und als allgemeine Skriptsprache wird Python verwendet. Für das Shading wird zudem OSL unterstützt. Nun war aber die Frage, welche Sprache man für Dinge wie prozedurale Modellierung und Animation sowie Compositing verwenden sollte. Für Ersteres hätte sich z.B. SeExpr von Disney angeboten, für Letzteres OpenFX. Beides hat in der VFX-Branche eine gewisse Verbreitung. Aber es wären auch gleich zwei neue Sprachen hinzugekommen, die Team-Mitglieder hätten erlernen müssten. Und es hätte die Kommunikation über Team-Grenzen hinweg schwieriger gemacht, da eben nicht jeder alle diese Sprachen beherrscht.
Diverse Fliegen mit einer Klappe
OSL hingegen war für all diese Einsatzgebiete prinzipiell ebenfalls geeignet, es mussten nur geringe Anpassungen vorgenommen werden, die von Image Engine übrigens Upstream in das OSL-Projekt eingepflegt wurden. Sprich auch in anderen Programmen kann jetzt der Einsatz von OSL ausgeweitet werden, das Fundament dafür wurde schon errichtet. Dank OSL schlägt man bei Image Engine mehrere Fliegen mit einer Klappe, und Mitarbeiter fast aller Departments können ihre kleinen Helferlein nun mit der gleichen Sprache realisieren. Dabei kam es durchaus schon vor, dass Features, die auf der To-do-Liste von Gaffer standen und eigentlich low-level über C++implementiert werden sollten, von Mitarbeitern via OSL erstellt wurden. Ein Beispiel dafür ist Camera Frustum Culling, das Objekte, die sich nicht im Sichtfeld der Kamera befinden, automatisch ausblendet. Realisiert wurde es mittels 12 Zeilen OSL-Code während einer Produktion und arbeitet dabei ausreichend performant.
Kein Ersatz für Python?
Lediglich im Bereich Skripting wird OSL bei Image Engine noch nicht wie erwartet angenommen, und das obwohl die Performance deutlich besser ist. Python hat mit seiner großen Auswahl an Paketen und Modulen z.B. für den Zugriff auf Dateien und Datenbanken allerdings auch einige handfeste Vorteile, die in OSL wohl nicht so schnell Einzug halten werden.
Fazit
Image Engine hat gezeigt, dass OSL für mehr als nur Shading eingesetzt werden kann. Die Implementierung in Gaffer ist Open Source und damit für jedermann nutz- und einsehbar. Vielleicht folgen ja weitere Studios und Programme diesem Beispiel, was OSL einen zweiten Frühling bescheren könnte. Man munkelt zudem, dass Gaffer bald auf Windows portiert werden wird.
Dieser Artikel erschien im Magazin Digital Production, Ausgabe 1904.