Hubbry Logo
Open Shading LanguageOpen Shading LanguageMain
Open search
Open Shading Language
Community hub
Open Shading Language
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Open Shading Language
Open Shading Language
Open Shading Language
View on Wikipedia
from Wikipedia
Open Shading Language (OSL)
DeveloperAcademy Software Foundation
Stable release
1.12.13.0 / 1 July 2023; 2 years ago (2023-07-01)[1]
Repository
TypeShading language
LicenseBSD license 3-clause
Websitegithub/OpenShadingLanguage

Open Shading Language (OSL) is a shading language developed by Sony Pictures Imageworks, a Canadian visual effects and computer animation studio headquartered in Vancouver, British Columbia and Montreal, Quebec, with an additional office on the Sony Pictures Studios lot in Culver City, California, a unit of Sony Pictures Entertainment's Motion Picture Group, which through an intermediate holding company called Sony Film Holding Inc., it is operated as a subsidiary of Sony Entertainment Inc., which is itself a subsidiary of the Japanese multinational technology and media conglomerate Sony Group Corporation, for use in its Arnold Renderer. It is also supported by Illumination Research's 3Delight renderer,[2] Otoy's Octane Render,[3] V-Ray 3,[4] Redshift (from April 2021),[5] and the Cycles render engine in Blender (starting with Blender 2.65).[6] OSL's surface and volume shaders define how surfaces or volumes scatter light in a way that allows for importance sampling; thus, it is well suited for physically based renderers that support ray tracing and global illumination.

RenderMan has limited OSL support that is used only for patterns; i.e. without any material closure (shading) functionality.[7] It is modified there for better AVX2 and AVX-512 instruction set support with doubled performance.[8][9]

Release 1.12 supports C++14 as default, but also newer C++17 and C++20. OpenImageIO support will be dropped for 2.0 with support of 2.2. Minimum OpenEXR Version changes up to 2.3. SIMD Batch shader Mode and OptiX support are in development and experimental. CUDA 11 and OptiX 7.1 are here supported levels.[10] 1.12.6 is supported in Blender 3.4. 1.12.6.2 is the first new release of the 1.12 series with a stable API. 1.12.13 is the current version.

Origin

[edit]

Larry Gritz explain origin of Open Shading Language:

We had a renderer (Sony Imageworks's fork of the Arnold renderer) where shaders were implemented as C++ plugins, and that had many problems. We desired a shading language for the renderer, and this is the one I designed. In addition to just wanting a language, we also sought to make many improvements over previous shading languages. We explained a lot of the details about the new ideas in this SIGGRAPH 2010 talk 'Open Shading Language'.[11] And apparently, the rest of the industry agreed, because it resulted in an 2017 Academy technical achievement award.[12]

—  email from Larry Gritz (2022.06.27) [citation needed]

Movies

[edit]

Many movies made in 2012 or later have used OSL,[13] including:

2017

[edit]

2018

[edit]
  • Peter Rabbit
  • Black Panther
  • Annihilation
  • Red Sparrow
  • Pacific Rim Uprising
  • Avengers Infinity War
  • Deadpool 2
  • Incredibles 2
  • Jurassic World: Fallen Kingdom
  • Hotel Transylvania 3: Summer Vacation
  • Ant Man and the Wasp
  • Skyscraper
  • Mission Impossible: Fallout
  • The Meg
  • Kin
  • Smallfoot
  • Alpha
  • Venom
  • First Man
  • Bad Times at the El Royale
  • Fantastic Beasts: The Crimes of Grindelwald
  • Bohemian Rhapsody
  • Holmes and Watson
  • Spider-Man: Into the Spider-Verse

2019

[edit]
  • The Kid Who Would Be King
  • Alita: Battle Angel
  • Lego Movie 2
  • Lucky 13 (an episode of Love, Death & Robots)
  • Captain Marvel
  • Triple Frontier
  • Avengers: Endgame
  • Pokémon Detective Pikachu
  • Godzilla: King of Monsters
  • Rim of the World
  • John Wick 3 Parabellum
  • Men in Black International
  • Toy Story 4
  • Spider-Man: Far From Home
  • Hobbs & Shaw
  • Angry Birds 2
  • The Art of Racing in the Rain
  • Secret Life of Pets
  • The Mandalorian (S1)
  • The Dark Crystal: Age of Resistance
  • The King
  • Jumanji: The Next Level
  • Richard Jewell
  • Game of Thrones (S8)
  • Lost in Space (S1)
  • Togo

2020

[edit]
  • Underwater
  • Birds of Prey
  • Onward
  • Bloodshot
  • Greyhound
  • The Old Guard
  • Mulan
  • Tenet
  • The New Mutants
  • Artemis Fowl
  • The Eight Hundred
  • Over the Moon
  • Wonder Woman 1984
  • Soul
  • The Mandalorian (S2)

2021 / upcoming

[edit]
  • Chaos Walking
  • Peter Rabbit 2: The Runaway
  • The Falcon and the Winter Soldier
  • Secret Magic Control Agency
  • Zack Snyder's Justice League
  • The Mitchells vs the Machines
  • Jupiter's Legacy
  • Luca
  • F9

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Open Shading Language

View on Grokipedia
from Grokipedia
Open Shading Language (OSL) is a small but rich programming language designed for programmable shading in advanced renderers and other graphics applications, particularly suited for describing materials, lights, displacement, and pattern generation in physically-based rendering systems that employ ray tracing and global illumination. Developed initially by Sony Pictures Imageworks for its in-house renderer used in feature film animation and visual effects, OSL was released as open-source software under the New BSD license to encourage widespread adoption and community contributions. For its contributions to rendering technology, OSL received an Academy Award for Technical Achievement in 2017. Since 2020, its development has been stewarded by the Academy Software Foundation (ASWF), ensuring ongoing maintenance and integration with industry-standard tools. OSL features a C-like syntax that allows technical artists and developers to create custom shaders without needing to handle low-level details like explicit ray tracing or light loops, as these are managed by the host renderer's integrators. Key capabilities include the use of radiance closures to represent light scattering behaviors such as BSDFs (Bidirectional Scattering Distribution Functions), support for shader networks with , and for computing texture derivatives. It unifies surface and light shaders, treating transparency as a form of illumination, which simplifies complex scene descriptions. The language integrates with libraries such as OpenImageIO for image I/O, Imath for mathematical operations, Boost for utilities, and for just-in-time compilation, enabling efficient execution across various platforms. OSL is supported in production renderers including , Blender's Cycles engine, and OTOY's OctaneRender, making it a standard for high-fidelity in , animation, and architectural visualization. Its and ensure robustness, with shaders compilable to for secure and performant runtime evaluation.

History

Origins and Development

The development of Open Shading Language (OSL) began in under the leadership of Gritz at , where it was created specifically for integration with their in-house renderer, Arnold, to facilitate complex procedural while avoiding dependency on proprietary vendor-specific tools. This initiative addressed the limitations of existing shading languages, which often bound users to particular rendering engines, by prioritizing portability and flexibility for production environments. Key initial design goals emphasized support for radiance closures to enable efficient computation of light interactions without directly outputting final colors, the deliberate exclusion of explicit ray tracing within shaders to keep them integrator-agnostic, and a strong orientation toward techniques tailored for high-fidelity in film production. These choices allowed shaders to describe material behaviors symbolically, deferring sampling and integration to the renderer for compatibility with advanced algorithms like and bidirectional . OSL's architecture and early implementations were publicly presented at 2010 in a talk by Gritz and colleagues from , highlighting its suitability for workflows. Within Sony, the language saw rapid internal adoption, notably contributing to for the 2012 film , where it supported intricate procedural effects in more than 650 shots.

Open Sourcing and Milestones

Open Shading Language (OSL) was initially released as open source on January 14, 2010, by Sony Pictures Imageworks under the New BSD license, enabling its adoption by visual effects and animation studios as well as rendering software vendors. In April 2020, stewardship of the OSL project was transferred to the Academy Software Foundation (ASWF), broadening industry collaboration and ensuring long-term maintenance through an open governance model involving multiple studios and vendors. Key milestones in OSL's development include the initial version 1.0 release in 2010, which established the core language for programmable shading in production renderers. The 1.12 series, beginning in 2021, introduced a stable application programming interface (API), facilitating reliable integration into third-party tools and enhancing developer confidence in extending the language. More recently, version 1.14 was released on April 6, 2025, incorporating C++20 support for modern compiler features, SIMD optimizations for batched shading performance, and deepened integration with NVIDIA's OptiX for GPU-accelerated rendering workflows. OSL received the in 2017, recognizing Gritz for its design, implementation, and dissemination as a highly optimized runtime system that advanced procedural in film and . The project has benefited from contributions by over 50 developers through its repository, including significant enhancements such as support for light path expressions to enable advanced ray tracing and control in shaders.

Design Principles

Core Concepts

Open Shading Language (OSL) serves as a higher-level programming language designed specifically for defining materials, lights, displacements, and patterns within ray-tracing renderers used in advanced visual effects and animation production. Unlike traditional shading approaches that compute final pixel colors directly, OSL shaders generate symbolic representations of radiance, known as closures, which describe how light interacts with surfaces and volumes in a physically plausible manner. This abstraction allows renderers to handle complex light transport calculations efficiently, focusing on scattering behaviors rather than immediate numerical outputs. At the heart of OSL's design are shader networks, structured as directed acyclic graphs (DAGs) where individual shader nodes connect to form layered, procedural materials that remain independent of specific renderer implementations. These networks leverage closures—symbolic expressions for light scattering components—to enable renderer-agnostic , with ensuring only necessary computations occur based on network connections. Closures encapsulate diverse interactions, such as reflection, refraction, and , allowing shaders to contribute to without predefined execution paths. OSL distinguishes itself from low-level shading languages like GLSL, which are optimized for real-time GPU rendering with constraints on procedural depth and explicit stages. In contrast, OSL targets offline rendering environments, supporting unbounded procedural complexity without requiring manual loops over sources or explicit ray tracing within shaders; instead, it treats lights as emissive surfaces integrated by the renderer's core algorithms. This design facilitates unlimited complexity in material descriptions, as shaders avoid direct sampling and rely on the host system for integration. In physically-based rendering pipelines, OSL plays a pivotal role by enabling the definition of Bidirectional Scattering Distribution Functions (BSDFs) through its closure system, which supports accurate modeling of transport for reflections, transmissions, and volumes. Deferred execution of these closures allows renderers to re-evaluate responses dynamically against varying directions and intensities, optimizing sampling and reducing redundant computations across multiple rays per . This approach ensures scalability for high-fidelity scenes, where shaders provide blocks for integrators to assemble complete radiance fields.

Key Features

One of the distinguishing capabilities of Open Shading Language (OSL) is its support for radiance closures, where surface and volume shaders produce symbolic descriptions of light scattering behaviors rather than final colors. These closures, such as diffuse or specular bidirectional distribution functions (BSDFs), are evaluated lazily by the renderer during path integration, allowing for efficient handling of techniques like multiple . OSL includes a suite of built-in functions for procedural texture and pattern generation, enabling the creation of complex materials without external dependencies. Notable examples are the noise() function, which generates Perlin or for organic variations, and the spline() function, which interpolates values or colors along cubic splines for smooth transitions in patterns like ramps or mappings. The language facilitates advanced through light path expressions, which tag and filter light transport paths using regular expression-like syntax to direct contributions to arbitrary output variables (AOVs). For instance, expressions like C<RD>*<L> can isolate paths from camera to light, keeping shaders focused on while the renderer manages output separation. OSL shaders deliberately omit explicit ray tracing calls or light loops, delegating sampling and integration to the host renderer to promote in scenes with high geometric complexity or . Effects like reflection and are encapsulated within closures, avoiding per-shader that could lead to inefficiencies. At its core, OSL employs a strong with built-in types including int and float for scalars, vector, point, and normal for 3D spatial data, color for spectral representation with space conversions (e.g., RGB to HSV), matrix for transformations, and closure for deferred scattering computations. It supports C++-like operators for arithmetic, comparisons, and component access across types, extended with shading-specific features such as qualifiers (e.g., "world") and limited linear operations on closures.

Syntax and Semantics

Basic Structure

Open Shading Language (OSL) shaders are stored in source files with the .osl extension, which contain declarations for shaders, types, or other constructs. A basic shader file begins with a shader declaration using the syntax shader name (parameter_list) { body }, where the parameter_list specifies inputs and outputs, and the body encloses a sequence of statements within curly braces. For example, a simple shader might be defined as shader SimpleMaterial (color diffuse_color = color(1,0,0)) { /* statements */ }. This structure organizes the shader as a self-contained unit, with parameters acting as interfaces for integration into rendering pipelines. Variable declarations in OSL follow a typed format, such as type name or type name = initial_value, supporting built-in types like int, float, color, point, vector, and matrix, as well as user-defined structures and arrays. Parameters in shader declarations can be marked as input, output, or both, with defaults provided for inputs, for instance, output color result; input float roughness = 0.5;. These declarations establish the data flow within the shader, ensuring type safety and enabling efficient evaluation during rendering. Control flow in OSL includes conditional statements like if (condition) { block } else { block } and loops such as for (init; condition; increment) { block }, while (condition) { block }, and do { block } while (condition). Keywords like break and continue allow early loop termination or skipping. However, OSL prohibits in shaders to avoid potential stack overflows in shading execution contexts, where deep call stacks could arise from ray tracing or surface evaluations. User-defined functions are declared with return_type name (parameter_list) { body }, supporting calls to other functions or the same function non-recursively, and can return closures for polymorphic behavior in shading computations. For example, closure color mix_closures(closure color a, closure color b, float t) { return a * (1 - t) + b * t; }. This enables modular while maintaining the language's focus on deterministic, non-branching-heavy evaluations suitable for parallel rendering. Preprocessor directives include #include "filename.osl" for incorporating external libraries or headers, and #define identifier value for defining constants or macros, facilitating code modularity and portability across shader implementations. OSL's syntax draws inspiration from C and the RenderMan Shading Language, providing a familiar framework for graphics programmers.

Shading Closures and Execution Model

In Open Shading Language (OSL), closures serve as first-class types that represent unevaluated expressions describing light scattering events, enabling to defer detailed computations to the renderer for efficiency. The primary closure type is closure color, which behaves arithmetically like a color but cannot be inspected numerically during shader execution to preserve its symbolic nature. For instance, a simple diffuse scattering can be declared as closure color Ci = diffuse(N);, where N is the surface normal, creating a symbolic BSDF (Bidirectional Scattering Distribution Function) that the renderer evaluates later. The execution model of OSL shaders operates on a per-shading-point basis, typically at surface or volume intersection points, where the shader computes and outputs a closure color assigned to the Ci parameter rather than a final radiance value. This allows the renderer to integrate the closures across light paths using advanced techniques like path tracing or Metropolis light transport, batching evaluations for coherence and unbiased results. Shaders execute in a SIMD (Single Instruction, Multiple Data) manner across multiple points, with variables dynamically switching between uniform and varying states without explicit directives, ensuring scalability in production rendering. OSL supports layering multiple BSDF components within a single closure by linearly combining them, facilitating realistic models such as layered surfaces with diffuse and specular interactions. For example, a basic layered BSDF might be expressed as Ci = diffuse(N) + specular(F, N);, where F is the incoming direction and Fresnel terms (computed via functions like fresnel_dielectric) weight the contributions based on incidence angle for physically plausible reflection and transmission. These layers are added as weighted closure color terms, with the renderer handling the summation during sampling to avoid in . Deferred ray tracing in OSL is achieved through closures that encode requests for indirect illumination without permitting inline ray tracing calls in the shader code, preventing path bias and recursion depth issues. The shader emits closures that signal the need for secondary rays (e.g., via emission or components), which the renderer traces and re-evaluates the closure network against incoming light from those paths. This model supports efficient re-evaluation of unchanged shading contexts, as seen in bidirectional integrators. Error handling for closures incorporates built-in runtime checks, such as domain clamping in mathematical functions to avoid NaNs, with the error() and warning() functions allowing shaders to report issues like invalid parameters. Invalid or uninitialized closures default to a null state (equivalent to zero, rendering as black), providing a safe fallback that the renderer propagates without crashing the evaluation pipeline.

Implementations

Compiler and Tools

The Open Shading Language (OSL) provides a suite of compiler and utility tools designed to facilitate shader development, compilation, and testing. Central to this ecosystem is the oslc command-line compiler, which parses OSL source files with the .osl extension and translates them into portable bytecode files with the .oso extension. This process involves lexical analysis, parsing, semantic checking, and code generation, producing an intermediate representation suitable for loading into rendering systems. Developers can control optimization through command-line flags, such as -O0 for no optimization (useful for debugging), -O1 for basic optimizations like constant folding and dead code elimination, -O2 for aggressive optimizations including inlining and loop unrolling, and -O3 for the highest level incorporating LLVM-specific passes for further performance gains. The compiler leverages the LLVM backend to generate highly optimized machine code during just-in-time compilation, enabling efficient execution on diverse hardware architectures. Complementing the compiler, the liboslexec library serves as the core runtime component for executing compiled OSL shaders. It handles the loading of .oso files, construction of shader networks (including layered and connected shaders), and dynamic evaluation of shading operations at render time. A key feature is its support for just-in-time (JIT) compilation using LLVM, which translates the bytecode into native machine instructions optimized for the host CPU, allowing for runtime adaptations such as parameter changes without recompilation. This library abstracts the complexities of shader execution, providing APIs for integrating OSL into host applications while ensuring thread-safety and support for layered shading models. For development and , OSL includes testshade, an interactive utility that enables of outside a full rendering environment. Users can apply to procedural point clouds or simple geometries, vary input via command-line options or an optional GUI, and visualize outputs as images or files to verify behavior, such as color mappings or procedural patterns. This tool supports features like multi-layer testing and sweeps, making it invaluable for iterative refinement without the overhead of complete scene renders. Another essential tool is oslquery, which interrogates compiled .oso files to extract metadata about interfaces, including names, types (e.g., float, color, ), default values, hints (e.g., page, widget), and connection metadata for networks. This information is output in structured formats like or XML, enabling automated UI generation in host applications; for instance, it powers in Blender's editor for seamless OSL integration. The tool operates via a simple , querying individual or entire groups to support toolchains in production pipelines. To build the OSL compiler and tools from source, developers require LLVM version 14.0 or later for the backend infrastructure, a supporting the C++17 standard (such as GCC 9.3+, 5+, or 2017+), and 3.19 or newer for configuration. The project is cross-platform, with full support for (x86_64), macOS (x86_64 and ), and Windows (x86_64), allowing compilation on standard development machines without specialized hardware. These tools collectively form a robust development environment for creating performant OSL shaders deployable in production renderers.

Runtime and Integration

Compiled OSL shaders are executed through the liboslexec library, which implements the ShadingSystem class responsible for just-in-time (JIT) compilation and evaluation using to generate optimized x86 . This runtime environment performs per-point evaluations, where each shading point receives a shading context containing essential geometric and parametric data such as position (P), surface normal (N), and texture coordinates (u, v). Liboslexec supports multithreading to leverage multi-core processors in renderers, enabling parallel evaluation across shading points, and includes experimental GPU offloading capabilities, such as integration with OptiX for accelerated execution on compatible hardware. Integration with rendering pipelines occurs via the OSL API, where renderer plugins initialize and manage instances of the ShadingSystem, providing a ShadingContext that supplies additional runtime parameters like ray differentials for and mipmapping, as well as support for arbitrary output variables (AOVs) to capture per-shader contributions. OSL also exposes callbacks allowing renderers to implement custom sampling strategies for BSDF closures during integration, ensuring seamless embedding without requiring explicit ray tracing or light loops within the code itself. Performance is enhanced through several runtime optimizations, including inline function expansions and closure simplifications performed during compilation to reduce computational overhead. Starting with version 1.14, liboslexec introduces batch shading support for SIMD processing using instructions like , allowing multiple shading points (up to 4 in b4 mode) to be evaluated simultaneously for improved throughput on vectorized hardware. Debugging facilities in liboslexec include verbose modes configurable via the ShadingSystem, which output detailed execution traces and error messages during evaluation. For runtime errors, stack traces are generated to pinpoint issues in the JIT-compiled , and integration with GDB is facilitated through LLVM's debug , enabling source-level of native executions. Since version 1.12, OSL maintains a stable (ABI) in liboslexec, ensuring binary compatibility across minor releases and supporting hot-reloading of in production environments without requiring renderer restarts.

Adoption

Supported Renderers and Software

Open Shading Language (OSL) has been integrated into several major renderers, enabling programmable shading for production workflows. Arnold, originally developed by , has supported OSL natively since its inception as the primary for the renderer. Pixar's RenderMan incorporates an OSL backend, allowing users to author shaders that leverage OSL's closure-based system alongside RenderMan's pattern nodes. Chaos Group's supports OSL through dedicated nodes that load shader code directly into material networks. Redshift added OSL compatibility starting in April 2021, facilitating GPU-accelerated shading with OSL scripts. OTOY's Render includes OSL support for custom procedural textures and materials, integrated via its node editor. Illumination Research's 3Delight renderer also natively handles OSL shaders, emphasizing compatibility for film and animation pipelines. In addition to standalone renderers, OSL is embedded in various 3D software applications. Blender's Cycles renderer has supported OSL since version 2.65, primarily on CPU with experimental GPU acceleration via the OptiX backend, though some features like certain closures remain unavailable on GPU. SideFX Houdini integrates OSL through its Solaris context, allowing shader authoring within procedural environments. Autodesk 3ds Max introduced OSL map support in version 2019, enabling users to create and load custom s compatible with multiple renderers like and Arnold via the shader API. While does not have native OSL support, community-developed experimental plugins have explored integration for material shading extensions. OSL integration typically occurs through direct loading of compiled .oso files, which contain platform-agnostic intermediate code that renderers just-in-time compile to during rendering. Many tools provide node-based editors for OSL scripts, such as Blender's Script node or Arnold's OSL shader node, where users can embed code or reference external files for real-time previewing and editing. Hybrid approaches exist, including OSL shaders wrapped within (MEL) scripts for , leveraging Arnold's integration to combine procedural logic with shading. Community-driven extensions have expanded OSL's reach, including custom backends for Intel's Embree ray tracer and NVIDIA's OptiX in OSL versions 1.11 and later, enabling optimized CPU and GPU execution in third-party applications. These extensions often involve building OSL with specific flags for bitcode generation, allowing seamless embedding in ray tracing frameworks without full renderer overhauls.

Applications in Production

Open Shading Language (OSL) has been employed in numerous film and visual effects (VFX) productions since its open-source release in 2010. In Sony Pictures Imageworks' pipeline, OSL facilitated procedural shading for skin and hair in Spider-Man: Into the Spider-Verse (2018), enabling stylized, hand-painted aesthetics through custom nodes integrated with tools like Katana. Similarly, for Avengers: Endgame (2019), OSL shaders supported environment and asset rendering at Industrial Light & Magic, handling intricate surface interactions in large-scale scenes. More recently, OSL contributed to rendering new character emotions in Pixar's Inside Out 2 (2024). In animation, OSL enables procedural asset generation in open-source tools like Blender's Cycles renderer, supporting indie film productions with custom textures and BRDFs that enhance reusability without proprietary dependencies. Beyond entertainment, OSL finds use in architectural visualization through V-Ray's OSL map support, where procedural textures simulate materials like occlusion for realistic interiors without extensive modeling. In scientific , custom OSL displacements render volumetric data, such as in astronomical visualizations blending Python scripts with for interactive 3D outputs. OSL also streamlines asset creation in USD pipelines, facilitating material interchange across studios via standards like MaterialX. OSL's workflow advantages include shader reusability across compatible renderers like Arnold and RenderMan, minimizing artist retraining by standardizing procedural descriptions. Production teams share OSL libraries on platforms like , accelerating development for VFX tasks such as pattern generation and light scattering. This portability has solidified OSL as a in VFX ecosystems, reducing pipeline fragmentation.

References

  1. https://open-shading-language.readthedocs.io/en/v1.13.12.0/intro.html
  2. https://github.com/AcademySoftwareFoundation/OpenShadingLanguage
  3. https://www.oscars.org/news/18-scientific-and-technical-achievements-be-honored-academy-awards-0
  4. https://www.aswf.io/news/osl-joins-aswf/
  5. https://docs.otoy.com/osl/assets/doc/osl-languagespec-1.11.pdf
  6. https://docs.blender.org/manual/en/latest/render/cycles/osl/index.html
  7. https://www.prnewswire.com/news-releases/sony-pictures-imageworks-releases-open-source-shading-language-osl-to-development-community-81485057.html
  8. https://blog.selfshadow.com/publications/s2012-shading-course/martinez/s2012_pbs_osl_notes_v3.pdf
  9. https://dl.acm.org/doi/10.1145/1837026.1837070
  10. https://www.cgw.com/Press-Center/In-Focus/2012/Amazing.aspx
  11. https://www.fxguide.com/fxfeatured/spider-man-the-detailed-vfx-of-spiders-and-lizards/
  12. https://blog.selfshadow.com/publications/s2012-shading-course/martinez/s2012_pbs_osl_slides.pdf
  13. https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/releases/tag/v1.14.5.0
  14. https://www.oscars.org/sci-tech/ceremonies/2017
  15. https://blog.selfshadow.com/publications/s2013-shading-course/martinez/s2013_pbs_osl_slides.pdf
  16. https://stackoverflow.com/questions/46093694/what-are-the-key-differences-between-open-shader-language-and-glsl
  17. https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/wiki/OSL-Light-Path-Expressions
  18. https://open-shading-language.readthedocs.io/en/main/datatypes.html
  19. https://open-shading-language.readthedocs.io/en/stable/
  20. https://open-shading-language.readthedocs.io/en/stable/syntax.html#shaders
  21. https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/blob/main/src/doc/osl-languagespec.pdf
  22. https://open-shading-language.readthedocs.io/en/stable/syntax.html#variable-declarations-and-assignments
  23. https://open-shading-language.readthedocs.io/en/stable/syntax.html#types
  24. https://open-shading-language.readthedocs.io/en/stable/syntax.html#control-flow-if-while-do-for
  25. https://open-shading-language.readthedocs.io/en/stable/syntax.html#functions
  26. https://open-shading-language.readthedocs.io/en/stable/syntax.html#preprocessor-directives
  27. https://open-shading-language.readthedocs.io/en/latest/datatypes.html
  28. https://open-shading-language.readthedocs.io/en/latest/intro.html
  29. https://open-shading-language.readthedocs.io/en/latest/stdlib.html
  30. https://raw.githubusercontent.com/AcademySoftwareFoundation/OpenShadingLanguage/main/INSTALL.md
  31. https://lists.aswf.io/g/osl-dev/topics?page=18&after=1666904101833725016
  32. https://rmanwiki-25.pixar.com/space/REN25/20416192/OSL%2BPatterns
  33. https://documentation.chaos.com/space/VC4D/116855771
  34. https://docs.otoy.com/cinema4d//OpenShadingLanguageOSL.html
  35. https://lists.aswf.io/g/osl-dev/topics
  36. https://help.autodesk.com/view/MAXDEV/2026/ENU/?guid=osl
  37. https://help.autodesk.com/view/ARNOL/ENU/?guid=arnold_user_guide_ac_shading_ac_osl_shaders_html
  38. https://help.autodesk.com/view/ARNOL/ENU/?guid=arnold_for_maya_shaders_am_OSL_Shaders_html
  39. https://groups.google.com/g/osl-dev/c/l-zwku9fVGc/m/9jifPSoSBAAJ
  40. https://lists.aswf.io/g/osl-dev/topic/how_to_build_osl_optix/74085583
  41. https://www.hollywoodreporter.com/movies/movie-news/motion-picture-academys-software-foundation-begins-open-shading-language-research-project-1290521/
  42. https://www.aswf.io/blog/pixar-relied-on-open-source-to-introduce-new-emotions-in-inside-out-2/
  43. https://odederell3d.blog/2020/05/25/using-osl-shaders-in-v-ray-for-3ds-max/
  44. https://ui.adsabs.harvard.edu/abs/2024IAUGA..32P1704K/abstract
  45. https://www.linuxfoundation.org/blog/blog/academy-software-foundation-digital-transformation-of-the-entertainment-industry-is-driven-by-open-technology-and-a-visionary-inclusive-community
Add your contribution
Related Hubs
User Avatar
No comments yet.