OpenShadingLangage
Release: OSL v1.13.11.0
Bienvenue dans Open Shading Language !
Open Shading Language (OSL) est un langage petit mais riche pour l'ombrage programmable dans les moteurs de rendu avancés et d'autres applications, idéal pour décrire les matériaux, les lumières, le déplacement et la génération de motifs.
OSL a été initialement développé par Sony Pictures Imageworks pour être utilisé dans son moteur de rendu interne utilisé pour l'animation de longs métrages et les effets visuels, publié en open source afin qu'il puisse être utilisé par d'autres studios d'effets visuels et d'animation et par des fournisseurs de logiciels de rendu. Il s'agit désormais du langage d'ombrage standard de facto pour les effets visuels et les fonctionnalités d'animation, utilisé dans toute l'industrie dans de nombreux moteurs de rendu commerciaux et propriétaires de studio. Pour cette raison, les travaux sur OSL ont reçu un Oscar pour la réussite technique en 2017.
OSL est robuste et éprouvé en production, et a été utilisé dans des films aussi divers que « The Amazing Spider-Man », « Hotel Transylvania », « Edge of Tomorrow », « Ant Man », « Finding Dory » et bien d'autres. La prise en charge d'OSL est présente dans la plupart des principaux moteurs de rendu utilisés pour les travaux d'effets visuels et d'animation haut de gamme. Pour une liste complète des films et produits, voir la filmographie.
Le code OSL est distribué sous la licence « New/3-clause BSD » et la documentation sous la licence internationale Creative Commons Attribution 4.0. En bref, vous êtes libre d'utiliser OSL dans vos propres applications, qu'elles soient gratuites ou commerciales, ouvertes ou propriétaires, ainsi que de modifier le code et la documentation OSL à votre guise, à condition de conserver les mentions de droits d'auteur originales telles que décrites dans la licence.
OSL a une syntaxe similaire à celle du C, ainsi qu'à d'autres langages d'ombrage. Cependant, il est spécialement conçu pour les algorithmes de rendu avancés et possède des fonctionnalités telles que les fermetures de radiance, les BSDF et le traçage de rayons différé comme concepts de première classe.
OSL possède plusieurs caractéristiques uniques que l'on ne retrouve pas dans d'autres langages d'ombrage (certainement pas toutes ensemble). Voici certaines choses que vous constaterez différentes dans OSL par rapport à d’autres langues :
Les shaders de surface et de volume calculent les fermetures d'éclat, pas les couleurs finales.
Les shaders de surface et de volume d'OSL calculent une description symbolique explicite, appelée « clôture », de la façon dont une surface ou un volume diffuse la lumière, en unités de radiance. Ces fermetures de radiance peuvent être évaluées dans des directions particulières, échantillonnées pour trouver des directions importantes, ou enregistrées pour une évaluation et une réévaluation ultérieures. Cette nouvelle approche est idéale pour un moteur de rendu physique prenant en charge le lancer de rayons et l’éclairage global.
En revanche, d’autres langages d’ombrage calculent généralement simplement une couleur de surface visible depuis une direction particulière. Ces anciens shaders sont des « boîtes noires » avec lesquelles un moteur de rendu ne peut pas faire grand-chose mais les exécuter pour trouver cette seule information (par exemple, il n'existe aucun moyen efficace de découvrir à partir d'elles quelles directions il est important d'échantillonner). De plus, les unités physiques des lumières et des surfaces sont souvent sous-spécifiées, ce qui rend très difficile de garantir que les shaders se comportent physiquement correctement.
Les shaders de surface et de volume ne bouclent pas sur les lumières et ne projettent pas de rayons.
Il n'y a pas de « boucles de lumière » ni de rayons d'éclairage explicitement tracés dans les shaders de surface OSL. Au lieu de cela, les shaders de surface calculent une fermeture de radiance décrivant comment la surface diffuse la lumière, et une partie du moteur de rendu appelée « intégrateur » évalue les fermetures pour un ensemble particulier de sources de lumière et détermine dans quelles directions les rayons doivent être tracés. Les effets qui nécessiteraient normalement un traçage de rayons explicite, tels que la réflexion et la réfraction, font simplement partie de la fermeture de radiance et ressemblent à n'importe quel autre BSDF.
Les avantages de cette approche incluent le fait que l'intégration et l'échantillonnage peuvent être regroupés ou réorganisés pour augmenter la cohérence des rayons ; un « budget de rayons » peut être alloué pour échantillonner de manière optimale le BSDF ; les fermetures peuvent être utilisées pour le traçage de rayons bidirectionnel ou le transport léger Metropolis ; et les fermetures peuvent être rapidement réévaluées avec un nouvel éclairage sans avoir à réexécuter les shaders.
Les shaders de surface et de lumière sont la même chose.
OSL n'a pas de type distinct de shader pour les sources lumineuses. Les lumières sont simplement des surfaces émissives, et toutes les lumières sont des lumières de zone.
La transparence n’est qu’un autre type d’éclairage.
Vous n'avez pas besoin de définir explicitement les variables de transparence/opacité dans le shader. La transparence n'est qu'une autre façon pour la lumière d'interagir avec une surface et est incluse dans la fermeture de radiance principale calculée par un shader de surface.
Les sorties du moteur de rendu (AOV) peuvent être spécifiées à l'aide d'« expressions de chemin lumineux ».
Parfois, il est souhaitable de produire des images contenant des composants d'éclairage individuels tels que des lumières spéculaires, diffuses, de réflexion, individuelles, etc. Dans d'autres langages, cela est généralement réalisé en ajoutant une pléthore de « variables de sortie » aux shaders qui collectent ces quantités individuelles.
Les shaders OSL n'ont pas besoin d'être encombrés de code ou de variables de sortie pour y parvenir. Au lieu de cela, il existe une notation basée sur des expressions régulières pour décrire quels chemins de lumière doivent contribuer à quelles sorties. Tout cela est fait du côté du moteur de rendu (bien que pris en charge par l'implémentation OSL). Si vous désirez une nouvelle sortie, il n'est pas du tout nécessaire de modifier les shaders ; il vous suffit d'indiquer au moteur de rendu la nouvelle expression du chemin lumineux.
Les shaders sont organisés en réseaux.
Les shaders OSL ne sont pas monolithiques, mais peuvent plutôt être organisés en réseaux de shaders (parfois appelés groupe de shaders, graphe ou DAG), les sorties nommées de certains nœuds étant connectées aux entrées nommées d'autres nœuds du réseau. Ces connexions peuvent être effectuées dynamiquement au moment du rendu et n'affectent pas la compilation des nœuds de shader individuels. De plus, les nœuds individuels sont évalués paresseusement, uniquement lorsque leurs sorties sont "extraites" des nœuds ultérieurs qui en dépendent (les rédacteurs de shaders peuvent rester parfaitement ignorants de ces détails et écrire des shaders comme si tout était évalué normalement).
Dérivés arbitraires sans grilles ni points d'ombrage supplémentaires.
Dans OSL, vous pouvez prendre des dérivées de n'importe quelle quantité calculée dans un shader, utiliser des quantités arbitraires comme coordonnées de texture et vous attendre à un filtrage correct. Cela ne nécessite pas que les points ombrés soient disposés dans une grille rectangulaire, ou qu'ils aient une connectivité particulière, ou que des « points supplémentaires » soient ombrés. En effet, les dérivées ne sont pas calculées par différences finies avec des points voisins, mais plutôt par « différenciation automatique », calculant des dérivées partielles pour les variables qui conduisent aux dérivées, sans aucune intervention requise de la part du rédacteur du shader.
OSL optimise de manière agressive au moment du rendu
OSL utilise le framework de compilateur LLVM pour traduire les réseaux de shaders en code machine à la volée (juste à temps, ou "JIT") et, ce faisant, optimise fortement les shaders et les réseaux avec une connaissance complète des paramètres de shader et d'autres valeurs d'exécution qui ne pourraient pas être utilisées. étaient connus lorsque les shaders étaient compilés à partir du code source. En conséquence, nous constatons que nos réseaux d'ombrage OSL s'exécutent 25 % plus rapidement que les shaders équivalents créés à la main en C ! (C'est ainsi que fonctionnaient nos anciens shaders dans notre moteur de rendu.)
La distribution open source OSL se compose des composants suivants :
oslc, un compilateur autonome qui traduit le code source OSL en un code intermédiaire de type assembly (sous forme de fichiers .oso).
liboslc, une bibliothèque qui implémente la classe OSLCompiler, qui contient les entrailles du compilateur de shader, au cas où quelqu'un aurait besoin de l'intégrer dans d'autres applications et ne souhaiterait pas que le compilateur soit un exécutable distinct.
liboslquery, une bibliothèque qui implémente la classe OSLQuery, qui permet aux applications d'interroger des informations sur les shaders compilés, y compris une liste complète de ses paramètres, leurs types et toutes les métadonnées qui leur sont associées.
oslinfo, un programme en ligne de commande qui utilise liboslquery pour imprimer sur la console toutes les informations pertinentes sur un shader et ses paramètres.
liboslexec, une bibliothèque qui implémente la classe ShadingSystem, qui permet d'exécuter des shaders compilés dans une application. Actuellement, il utilise LLVM pour compiler JIT le bytecode du shader en instructions x86.
testshade, un programme qui vous permet d'exécuter un shader (ou un réseau de shaders connecté) sur un tableau rectangulaire de points et d'enregistrer n'importe laquelle de ses sorties sous forme d'images. Cela permet de vérifier les shaders (et le système d'ombrage) sans avoir besoin d'être intégré dans un moteur de rendu entièrement fonctionnel, et constitue la base de la plupart de nos vérifications de suite de tests. Avec testrender, testshade est un bon exemple de la façon d'appeler les bibliothèques OSL.
testrender, un petit moteur de rendu de lancer de rayons qui utilise OSL pour l'ombrage. Les fonctionnalités sont très minimes (seules les sphères sont autorisées pour le moment) et aucune attention n'a été portée aux performances, mais cela montre comment les bibliothèques OSL peuvent être intégrées dans un moteur de rendu fonctionnel, quelles interfaces le moteur de rendu doit fournir et comment les BSDF/ les fermetures de radiance doivent être évaluées et intégrées (y compris avec un échantillonnage d’importance multiple).
Quelques exemples de shaders.
Documentation - comprenant à ce stade la spécification du langage OSL (utile pour les rédacteurs de shaders), mais à l'avenir, elle comportera une documentation détaillée sur la façon d'intégrer les bibliothèques OSL dans les moteurs de rendu.
Cette liste ne contient que des films ou des produits dont l'utilisation OSL est déclarée ou peut être déduite de sources publiques, ou qu'il nous a été dit que nous pouvions les répertorier ici. Si un projet utilisant OSL est manquant et que ce n'est pas un secret, envoyez simplement un e-mail au chef de projet OSL ou soumettez un PR avec des modifications à ce fichier.
(Dans l'ordre approximatif d'ajout du support OSL)
(Ici, nous entendons par « œuvre significative » un long métrage sorti en salles ou sur une grande plateforme de streaming, une série télévisée/en streaming comportant beaucoup d'effets visuels ou d'animation, ou des courts métrages qui ont remporté ou ont été nominés pour des prix majeurs.)
Veuillez lire le fichier INSTALL.md pour obtenir des instructions détaillées sur la façon de créer et d'installer OSL.
La spécification du langage OSL peut être trouvée dans src/doc/osl-lingualspec.pdf (dans une distribution source) ou dans le fichier share/doc/OSL/osl-lingualspec.pdf d'une distribution binaire installée.
Documentation OSL expérimentale sur ReadTheDocs Ce sera la future documentation. Il est probablement aussi complet que le PDF, mais il nécessite une relecture, donc le PDF est toujours considéré comme la source faisant autorité pour le moment. Mais bientôt, l’ancienne spécification PDF sera obsolète au profit de cette documentation en ligne.
Il existe également une version PDF.
Pour ceux qui souhaitent apprendre à programmer des shaders dans OSL, il existe le cours OSL Shaders for RenderMan du Siggraph 2022 Educator's Forum, qui utilise RenderMan dans les exemples et les documents supplémentaires, mais qui concerne principalement l'écriture de shaders dans OSL.
Il est préférable de poser des questions simples "Comment puis-je...", "J'ai des problèmes" ou "Est-ce un bug" sur la liste de diffusion des développeurs osl-dev. C’est là que la plupart des gens le verront et seront potentiellement en mesure de répondre rapidement à votre question (plus qu’un « problème » GH).
Les bogues, les problèmes de construction et les vulnérabilités découvertes dont vous êtes relativement certain qu'il s'agit d'un problème légitime dans le code et pour lesquels vous pouvez donner des instructions claires sur la façon de reproduire doivent être signalés comme des problèmes.
Si vous pensez avoir trouvé une vulnérabilité potentielle dans OSL, veuillez la signaler de manière confidentielle en envoyant un e-mail aux administrateurs du projet à [email protected].
Si tout autre problème nécessite une confidentialité qui exclut une question ou un problème public, vous pouvez contacter l'administrateur du projet en privé à [email protected].
OSL accueille favorablement les contributions au code, et près de 50 personnes l'ont fait au fil des ans. Nous acceptons les contributions de code via le mécanisme habituel de demande de tirage (PR) GitHub. Veuillez consulter CONTRIBUER pour des instructions détaillées.
Page GitHub OSL
Lisez ou abonnez-vous à la liste de diffusion de développement OSL
PDF le plus récent de la spécification du langage OSL
Page d'accueil OSL
La direction actuelle du projet est documentée dans le dossier de gouvernance.
De nombreuses personnes ont apporté des fonctionnalités, des corrections de bugs et d'autres modifications à OSL au fil des ans : Steve Agland, Shane Ambler, Martijn Berger, Farchad Bidgolirad, Nicholas Bishop, Curtis Black, Rasmus Bonnedal, Solomon Boulos, Stefan Bruens, Stefan Büttner, Matthaus 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. (Classé par ordre alphabétique ; si nous avons omis quelqu'un, c'est par inadvertance, veuillez nous le faire savoir.)
Nous ne pouvons exprimer suffisamment de gratitude aux responsables de Sony Pictures Imageworks qui ont permis à ce projet de se poursuivre, l'ont soutenu de tout cœur et nous ont permis de divulguer la source, en particulier Rob Bredow, Brian Keeney, Barbara Ford, René Limberger, Erik Strauss et Mike. Gué.
Un grand merci également à l'équipe de crack shading de SPI, ainsi qu'aux courageux TD et CG lookdev prêts à utiliser OSL dans leurs émissions. Ils nous ont servi de cobayes, d’inspiration, de testeurs et d’une fantastique source de commentaires. Et bien sûr, les nombreux ingénieurs, TD et artistes d'ailleurs qui ont intégré OSL dans leurs produits et pipelines, en particulier les premiers preneurs de risques de Chaos Group, Double Negative, Pixar, DNA, Isotropix et Animal Logic. Merci et nous espérons avoir répondu à vos besoins.
OSL n’a pas été développé de manière isolée. Nous avons une dette envers les individus et les studios qui ont patiemment lu les premières versions de la spécification du langage et nous ont donné des commentaires très utiles et des idées supplémentaires, ainsi qu'aux contributions et commentaires continus de ses développeurs et utilisateurs actuels d'autres studios d'effets visuels et d'animation.
L'implémentation OSL dépend de plusieurs autres packages open source, tous avec des licences compatibles :
La documentation d'OSL intègre des parties de Markdeep (c) 2015-2016, Morgan McGuire et highlight.js (c) 2006, Ivan Sagalaev, tous deux distribués sous licences BSD.
