Willkommen bei Open Shading Language!
Open Shading Language (OSL) ist eine kleine, aber umfangreiche Sprache für programmierbare Schattierungen in fortgeschrittenen Renderern und anderen Anwendungen, ideal zur Beschreibung von Materialien, Lichtern, Verschiebungen und Mustergenerierung.
OSL wurde ursprünglich von Sony Pictures Imageworks für den Einsatz in seinem hauseigenen Renderer für Spielfilmanimationen und visuelle Effekte entwickelt und als Open Source veröffentlicht, sodass es von anderen Studios für visuelle Effekte und Animationen sowie Anbietern von Rendering-Software verwendet werden konnte. Mittlerweile ist es die De-facto-Standard-Shading-Sprache für VFX und animierte Features, die branchenweit in vielen kommerziellen und studioeigenen Renderern verwendet wird. Aus diesem Grund wurde die Arbeit an OSL 2017 mit einem Oscar für technische Leistung ausgezeichnet.
OSL ist robust und produktionserprobt und wurde in so unterschiedlichen Filmen wie „The Amazing Spider-Man“, „Hotel Transylvania“, „Edge of Tomorrow“, „Ant Man“, „Findet Dory“ und vielen mehr eingesetzt. OSL-Unterstützung ist in den meisten führenden Renderern enthalten, die für High-End-VFX- und Animationsarbeiten verwendet werden. Eine vollständige Liste der Filme und Produkte finden Sie in der Filmografie.
Der OSL-Code wird unter der „New/3-clause BSD“-Lizenz und die Dokumentation unter der Creative Commons Attribution 4.0 International License vertrieben. Kurz gesagt, es steht Ihnen frei, OSL in Ihren eigenen Anwendungen zu verwenden, unabhängig davon, ob diese kostenlos oder kommerziell, offen oder proprietär sind, und den OSL-Code und die Dokumentation nach Ihren Wünschen zu ändern, vorausgesetzt, Sie behalten die ursprünglichen Urheberrechtshinweise bei, wie in beschrieben die Lizenz.
OSL hat eine ähnliche Syntax wie C sowie andere Schattierungssprachen. Es ist jedoch speziell für fortgeschrittene Rendering-Algorithmen konzipiert und verfügt über Funktionen wie Radiance-Closures, BSDFs und Deferred Raytracing als erstklassige Konzepte.
OSL weist mehrere einzigartige Merkmale auf, die in anderen Schattierungssprachen nicht zu finden sind (sicherlich nicht alle zusammen). Hier sind einige Dinge, die Sie in OSL im Vergleich zu anderen Sprachen unterscheiden werden:
Oberflächen- und Volumen-Shader berechnen Strahlungsabschlüsse, keine endgültigen Farben.
Die Oberflächen- und Volumen-Shader von OSL berechnen eine explizite symbolische Beschreibung, einen sogenannten „Abschluss“, der Art und Weise, wie eine Oberfläche oder ein Volumen Licht streut, in Strahlungseinheiten. Diese Strahlungsabschlüsse können in bestimmten Richtungen ausgewertet, zur Ermittlung wichtiger Richtungen abgetastet oder zur späteren Auswertung und Neuauswertung gespeichert werden. Dieser neue Ansatz ist ideal für einen physikalisch-basierten Renderer, der Raytracing und globale Beleuchtung unterstützt.
Im Gegensatz dazu berechnen andere Schattierungssprachen normalerweise nur eine Oberflächenfarbe, die aus einer bestimmten Richtung sichtbar ist. Diese alten Shader sind „Black Boxes“, mit denen ein Renderer nur wenig anfangen kann, außer sie auszuführen, um diese eine Information zu finden (es gibt beispielsweise keine effektive Möglichkeit, anhand dieser zu ermitteln, welche Richtungen für die Abtastung wichtig sind). Darüber hinaus sind die physikalischen Einheiten von Lichtern und Oberflächen oft unzureichend spezifiziert, was es sehr schwierig macht, sicherzustellen, dass sich Shader physikalisch korrekt verhalten.
Oberflächen- und Volumen-Shader durchlaufen keine Schleifen über Lichter und schießen keine Strahlen ab.
In OSL-Oberflächenshadern gibt es keine „Lichtschleifen“ oder explizit verfolgten Beleuchtungsstrahlen. Stattdessen berechnen Oberflächen-Shader einen Strahldichteabschluss, der beschreibt, wie die Oberfläche Licht streut, und ein Teil des Renderers, der als „Integrator“ bezeichnet wird, wertet die Abschlüsse für einen bestimmten Satz von Lichtquellen aus und bestimmt, in welche Richtungen Strahlen verfolgt werden sollen. Effekte, die normalerweise eine explizite Strahlverfolgung erfordern würden, wie z. B. Reflexion und Brechung, sind einfach Teil des Radiance-Abschlusses und sehen wie jedes andere BSDF aus.
Zu den Vorteilen dieses Ansatzes gehört, dass Integration und Probenahme stapelweise oder neu angeordnet werden können, um die Strahlenkohärenz zu erhöhen; Es kann ein „Strahlenbudget“ zugewiesen werden, um die BSDF optimal abzutasten. Die Verschlüsse können für bidirektionale Raytracing- oder Metropolis-Lichttransporte verwendet werden. und die Abschlüsse können mit neuer Beleuchtung schnell neu bewertet werden, ohne dass die Shader erneut ausgeführt werden müssen.
Oberflächen- und Licht-Shader sind dasselbe.
OSL verfügt über keinen separaten Shader für Lichtquellen. Lichter sind einfach emittierende Oberflächen, und alle Lichter sind Flächenlichter.
Transparenz ist nur eine andere Art der Beleuchtung.
Sie müssen im Shader keine Transparenz-/Deckkraftvariablen festlegen. Transparenz ist nur eine weitere Möglichkeit für Licht, mit einer Oberfläche zu interagieren, und ist im Hauptstrahlungsabschluss enthalten, der von einem Oberflächen-Shader berechnet wird.
Renderer-Ausgaben (AOVs) können mithilfe von „Lichtpfadausdrücken“ angegeben werden.
Manchmal ist es wünschenswert, Bilder auszugeben, die einzelne Beleuchtungskomponenten wie Spiegellicht, diffuses Licht, Reflexion, einzelne Lichter usw. enthalten. In anderen Sprachen wird dies normalerweise durch Hinzufügen einer Vielzahl von „Ausgabevariablen“ zu den Shadern erreicht, die diese einzelnen Mengen sammeln.
Um dies zu erreichen, müssen OSL-Shader nicht mit Code oder Ausgabevariablen überladen werden. Stattdessen gibt es eine auf regulären Ausdrücken basierende Notation zur Beschreibung, welche Lichtpfade zu welchen Ausgaben beitragen sollen. Dies geschieht alles auf der Renderer-Seite (obwohl dies von der OSL-Implementierung unterstützt wird). Wenn Sie eine neue Ausgabe wünschen, müssen Sie die Shader überhaupt nicht ändern; Sie müssen dem Renderer lediglich den neuen Lichtpfadausdruck mitteilen.
Shader sind in Netzwerken organisiert.
OSL-Shader sind nicht monolithisch, sondern können in Shader-Netzwerken (manchmal auch Shader-Gruppe, Graph oder DAG genannt) organisiert werden, wobei benannte Ausgänge einiger Knoten mit benannten Eingängen anderer Knoten innerhalb des Netzwerks verbunden sind. Diese Verbindungen können dynamisch zur Renderzeit erfolgen und haben keinen Einfluss auf die Kompilierung einzelner Shader-Knoten. Darüber hinaus werden die einzelnen Knoten nur langsam ausgewertet, wenn ihre Ausgaben von den späteren Knoten, die von ihnen abhängen, „abgerufen“ werden (Shader-Autoren sind sich dieser Details möglicherweise glücklicherweise nicht bewusst und schreiben Shader, als ob alles normal ausgewertet würde).
Beliebige Ableitungen ohne Gitter oder zusätzliche Schattierungspunkte.
In OSL können Sie Ableitungen jeder berechneten Größe in einem Shader vornehmen und beliebige Mengen als Texturkoordinaten verwenden und eine korrekte Filterung erwarten. Dies erfordert nicht, dass schattierte Punkte in einem rechteckigen Raster angeordnet sind oder eine besondere Konnektivität aufweisen oder dass „zusätzliche Punkte“ schattiert werden. Dies liegt daran, dass Ableitungen nicht durch endliche Differenzen mit benachbarten Punkten berechnet werden, sondern durch „automatische Differenzierung“, bei der partielle Differentiale für die Variablen berechnet werden, die zu Ableitungen führen, ohne dass der Shader-Autor eingreifen muss.
OSL optimiert aggressiv zur Renderzeit
OSL verwendet das LLVM-Compiler-Framework, um Shader-Netzwerke im Handumdrehen (just in time oder „JIT“) in Maschinencode zu übersetzen und optimiert dabei Shader und Netzwerke stark, wobei die Shader-Parameter und andere Laufzeitwerte vollständig bekannt sind, was nicht möglich war waren bekannt, als die Shader aus dem Quellcode kompiliert wurden. Infolgedessen sehen wir, dass unsere OSL-Shading-Netzwerke 25 % schneller ausgeführt werden als die entsprechenden, in C handgefertigten Shader! (So funktionierten unsere alten Shader in unserem Renderer.)
Die OSL-Open-Source-Distribution besteht aus folgenden Komponenten:
oslc, ein eigenständiger Compiler, der OSL-Quellcode in einen assemblyähnlichen Zwischencode (in Form von .oso-Dateien) übersetzt.
liboslc, eine Bibliothek, die die OSLCompiler-Klasse implementiert, die den Kern des Shader-Compilers enthält, für den Fall, dass jemand ihn in andere Anwendungen einbetten muss und nicht möchte, dass der Compiler eine separate ausführbare Datei ist.
liboslquery, eine Bibliothek, die die OSLQuery-Klasse implementiert, die es Anwendungen ermöglicht, Informationen über kompilierte Shader abzufragen, einschließlich einer vollständigen Liste ihrer Parameter, ihrer Typen und aller damit verbundenen Metadaten.
oslinfo, ein Befehlszeilenprogramm, das liboslquery verwendet, um alle relevanten Informationen über einen Shader und seine Parameter auf der Konsole auszugeben.
liboslexec, eine Bibliothek, die die ShadingSystem-Klasse implementiert, die die Ausführung kompilierter Shader innerhalb einer Anwendung ermöglicht. Derzeit wird LLVM zum JIT-Kompilieren des Shader-Bytecodes in x86-Anweisungen verwendet.
testshade, ein Programm, mit dem Sie einen Shader (oder ein verbundenes Shader-Netzwerk) auf einem rechteckigen Array von Punkten ausführen und alle seine Ausgaben als Bilder speichern können. Dies ermöglicht die Verifizierung von Shadern (und des Schattierungssystems), ohne dass diese in einen voll funktionsfähigen Renderer integriert werden müssen, und ist die Grundlage für die meisten unserer Testsuite-Verifizierungen. Zusammen mit testrender ist testshade ein gutes Beispiel für den Aufruf der OSL-Bibliotheken.
testrender, ein kleiner Raytracing-Renderer, der OSL für die Schattierung verwendet. Die Features sind sehr minimal (zu diesem Zeitpunkt sind nur Sphären erlaubt) und es wurde kein Augenmerk auf die Leistung gelegt, aber es zeigt, wie die OSL-Bibliotheken in einen funktionierenden Renderer integriert werden können, welche Schnittstellen der Renderer bereitstellen muss und wie die BSDFs/ Strahlungsabschlüsse sollten ausgewertet und integriert werden (auch mit Stichproben mit mehreren Wichtigkeiten).
Ein paar Beispiel-Shader.
Dokumentation – besteht derzeit aus der OSL-Sprachspezifikation (nützlich für Shader-Autoren), wird aber in Zukunft eine detaillierte Dokumentation zur Integration der OSL-Bibliotheken in Renderer enthalten.
Diese Liste enthält nur Filme oder Produkte, deren OSL-Nutzung angegeben ist oder aus öffentlichen Quellen abgeleitet werden kann oder von denen uns mitgeteilt wurde, dass sie hier aufgeführt werden dürfen. Wenn ein OSL-verwendendes Projekt fehlt und es kein Geheimnis ist, senden Sie einfach eine E-Mail an den OSL-Projektleiter oder senden Sie eine PR mit Änderungen an dieser Datei.
(In ungefährer Reihenfolge des Hinzufügens der OSL-Unterstützung)
(Hier verstehen wir unter „bedeutender Arbeit“ einen Spielfilm, der im Kino oder auf einer großen Streaming-Plattform veröffentlicht wird, eine TV-/Streaming-Serie, die stark mit visuellen Effekten oder Animationen ausgestattet ist, oder Kurzfilme, die große Preise gewonnen oder dafür nominiert wurden.)
Detaillierte Anweisungen zum Erstellen und Installieren von OSL finden Sie in der Datei INSTALL.md.
Die OSL-Sprachspezifikation finden Sie unter src/doc/osl-lingualspec.pdf (in einer Quelldistribution) oder in der Datei share/doc/OSL/osl-lingualspec.pdf einer installierten Binärdistribution.
Experimentelle OSL-Dokumentation auf ReadTheDocs Dies wird die zukünftige Dokumentation sein. Es ist wahrscheinlich genauso vollständig wie das PDF, muss aber noch Korrektur gelesen werden, sodass das PDF vorerst immer noch als maßgebliche Quelle gilt. Aber irgendwann wird die alte PDF-Spezifikation zugunsten dieser Online-Dokumentation veraltet sein.
Es gibt auch eine PDF-Version.
Für diejenigen, die lernen möchten, wie man Shader in OSL programmiert, gibt es den Siggraph 2022 Educator's Forum OSL Shaders for RenderMan-Kurs, der RenderMan in den Beispielen und ergänzenden Materialien verwendet, sich aber hauptsächlich mit dem Schreiben von Shader in OSL befasst.
Einfache Fragen wie „Wie kann ich ...“, „Ich habe Probleme“ oder „Ist das ein Fehler?“ werden am besten auf der Entwickler-Mailliste von osl-dev gestellt. Dort werden es die meisten Leute sehen und Ihre Frage möglicherweise schnell beantworten können (mehr als ein GH-„Problem“).
Fehler, Build-Probleme und entdeckte Schwachstellen, von denen Sie relativ sicher sind, dass es sich um ein legitimes Problem im Code handelt und für die Sie klare Anweisungen zur Reproduktion geben können, sollten als Probleme gemeldet werden.
Wenn Sie glauben, eine potenzielle Sicherheitslücke in OSL gefunden zu haben, melden Sie dies bitte vertraulich, indem Sie eine E-Mail an die Projektadministratoren unter [email protected] senden.
Wenn ein anderes Problem Vertraulichkeit erfordert, das eine öffentliche Frage oder ein öffentliches Problem ausschließt, können Sie den Projektadministrator privat unter [email protected] kontaktieren.
OSL begrüßt Codebeiträge, und im Laufe der Jahre haben fast 50 Personen dies getan. Wir nehmen Codebeiträge über den üblichen Pull-Request-Mechanismus (PR) von GitHub entgegen. Detaillierte Anweisungen finden Sie unter BEITRAG.
OSL GitHub-Seite
Lesen oder abonnieren Sie die OSL-Entwicklungs-Mailliste
Aktuelles PDF der OSL-Sprachspezifikation
OSL-Homepage
Die aktuelle Projektleitung wird in der Governance-Datei dokumentiert.
Viele Menschen haben im Laufe der Jahre Funktionen, Fehlerbehebungen und andere Änderungen an OSL beigesteuert: Steve Agland, Shane Ambler, Martijn Berger, Farchad Bidgolirad, Nicholas Bishop, Curtis Black, Rasmus Bonnedal, Solomon Boulos, Stefan Bruens, Stefan Büttner, Matthäus G . Chajdas, Clark Chen, Mehdi Chinoune, Alejandro Conty, Damien Courtois, Dieter De Baets, Thomas Dinges, Daniel Dresser, Mads Drøschler, Peter Ellerington, Luke Emrose, Louis Feng, Mark Final, Henri Fousse, Stephen Friedman, Syoyo Fujita, Tim Grant, Larry Gritz, Nicolas Guiard, Euan Haahr, Derek Haase, Sven-Hendrik Haase, John Haddon, Niklas Harrysson, Daniel Heckenberg, Chris Hellmuth, Adrien Herubel, Dan Horák, Thiago Ize, Matt Johnson, Ronan Keryell, Chris Kulla, Elvic Liang, Max Liani, Adam Martinez, John Mertic, Bastien Montagne, Steena Monteiro, Patrick Mours, Alexis Oblet, Erich Ocean, Mikko Ohtamaa, Jino Park, Alexei Pawlow, Mitch Prater, Jay Reynolds, Declan Russell, Benoit Ruiz, Patrick Scheibe, Alex Schworer, Jonathan Scruggs, Sergey Sharybin, Mark Sisson, Sandip Shukla, Cliff Stein, Stephan Steinbach, Luya Tshimbalanga, Esteban Tovagliari, Brecht Van Lommel, Thibault Vergne, Alexander von Knorring, Aidan Welch, Alex Wells, Roman Zulak. (Alphabetisch aufgelistet; wenn wir jemanden ausgelassen haben, ist das versehentlich, teilen Sie uns das bitte mit.)
Wir können den Managern von Sony Pictures Imageworks, die die Fortsetzung dieses Projekts ermöglichten, es voll und ganz unterstützten und uns erlaubten, die Quelle freizugeben, gar nicht genug Dank aussprechen, insbesondere Rob Bredow, Brian Keeney, Barbara Ford, Rene Limberger, Erik Strauss und Mike Ford.
Ein großer Dank geht auch an das Crack-Shading-Team von SPI und die mutigen Lookdev-TDs und CG-Supers, die bereit sind, OSL in ihren Shows zu verwenden. Sie dienten uns als Versuchskaninchen, Inspiration, Tester und eine fantastische Quelle für Feedback. Und natürlich die vielen Ingenieure, TDs und Künstler anderswo, die OSL in ihre Produkte und Pipelines integriert haben, insbesondere die frühen Risikoträger bei Chaos Group, Double Negative, Pixar, DNA, Isotropix und Animal Logic. Vielen Dank und wir hoffen, dass wir auf Ihre Bedürfnisse eingegangen sind.
OSL wurde nicht isoliert entwickelt. Unser Dank gilt den Einzelpersonen und Studios, die die ersten Entwürfe der Sprachspezifikation geduldig gelesen und uns sehr hilfreiches Feedback und zusätzliche Ideen gegeben haben, sowie den fortlaufenden Beiträgen und Rückmeldungen der aktuellen Entwickler und Benutzer in anderen VFX- und Animationsstudios.
Die OSL-Implementierung hängt von mehreren anderen Open-Source-Paketen ab, alle mit kompatiblen Lizenzen:
Die Dokumentation von OSL enthält Teile von Markdeep (c) 2015-2016, Morgan McGuire, und highlights.js (c) 2006, Ivan Sagalaev, die beide unter BSD-Lizenzen vertrieben werden.