BlenderDiplom interviews Larry Gritz, lead developer of the Open Shading Language (OSL) at Sony Pictures Imageworks. OSL has been sticking around in Cycles for a while and is supported by the latest version of V-Ray which is currently in Beta. This interview was conducted in May 2013 and was first released in German language in the magazine Digital Production.
BD: What changes did OSL introduce to the shading workflow at Sony Pictures Imageworks?
LG: Prior to OSL, SPI's shaders were compiled C plugins for Arnold. Our shader writers were spending more and more time dealing with low-level details -- C is rather clunky to use as a shading language, and very error-prone -- and dealing with headaches of interfacing with the renderer internals. Furthermore, it was increasingly difficult to achieve the kind of physically-based lights and materials that we wanted, and it was clear that we needed a different set of abstractions than had been used in prior shading systems.
OSL really changes three things for us at once: First, because the syntax and semantics of the language are designed with shading in mind, it is simply a more convenient notation for describing shading (especially compared to raw C). Second, it presents a really clean API that doesn't directly expose ugly or complex renderer internals. These two things put together mean that nearly all of the lines of code of a shader -- and the time and attention of the shader writer -- are about describing the material, and a great amount of work that was shuffling data around and dealing with renderer internals is eliminated. Finally, there is a big conceptual shift, from computing the appearance from one direction, which would have to include all the ugly details of sampling and integration in the shader itself, to computing view-independent material closures (which leave the sampling and integration up to the renderer, which is much better equipped to do it well). That has been a big enabler of our efforts to have more physically-based light and material models and get more pleasing and accurate images "out of the box."
BD: What were the motivations behind open sourcing OSL?
LG: Proprietary tools sometimes have a competitive advantage, but they also have a real cost: any tool or format that is truly unique to your facility is one where you can never hire somebody who already is an expert, you will never find external documentation, you will not have your 3rd party tools support it without a lot of additional plug-in development that you have to take on yourself.
So we were betting that any advantage of keeping it to ourselves would be small compared to the really big benefits of having an OSL ecosystem that extended beyond just SPI. We envisioned a day when 3rd party tools we use would support it, when we could hire TDs who were already familiar with this method of shading. It's even an advantage when hiring people who don't already know OSL, because it's a fact of life that artists move from facility to facility, and it's more appealing for a TD to learn skills that they feel will be valuable even after leaving Sony, than learning details about tools they'll never see again.
Also, it's very professionally satisfying for the software developers, who often don't get film credits and can't easily point to particular shots they worked on, to be working on things that are externally visible and get recognition from their peers at other VFX facilities.
Knowing that people will actually see your work makes you put more effort into making solid code you can be proud of. So we really believe that by developing OSL as an open source project, the implementation is better.
BD: Did you get many contributions from outside yet?
LG: Yes! Even before OSL was implemented, we circulated early drafts to some other interested studios and got lots of great early feedback even from other major well-known studios.
In terms of actual code contributions, the main feature authors are at SPI, but we have had many contributions from elsewhere. Especially now that OSL has been incorporated into Blender/Cycles, V-Ray, and Autodesk Beast, we regularly get contributions from the authors of those packages that include minor bug fixes, optimizations, and changes to the code that allow smoother porting and compilation for platforms we don't tend to use ourselves (particularly aid to getting it running nicely on Windows).
BD: OSL was open sourced in 2010, now we have 2013 and still Blender Cycles is the only render engine on the open market that supports OSL. Are the developers of render engines hesitant to adopt it and if so, what do you think are the reasons?
LG: That's not quite correct; it's also incorporated into Autodesk Beast and being incorporated into V-Ray, both of which have substantial user bases.
Also, although OSL has been open sourced since 2010 (in the sense that we did much of the initial development out in the open, even before it was completed), it was only mid-2012 that SPI completed the first "all-OSL" films, which was an important milestone that lots of people were waiting for before taking a gamble on it. So it's really only been one year of what you'd consider a 1.0, fully production-hardened state, and 3 major engines have incorporated OSL to date that we are aware of.
It's hard to switch an existing render engine to OSL for three reasons:
(1) the shader execution engine (and almost certainly the texture system, along with it) is a very large portion of a renderer to replace with an external package that you don't necessarily have full control over.
(2) "upgrading" an existing renderer to OSL may also involve a substantial overhaul of how lights and sampling work even in the non-OSL parts of the renderer; (3) products with large existing customer bases have a lot of inertia behind their user education, expertise, and shader libraries, so it's not a small task to pivot to a different way of specifying shading.
BD: The syntax is really similar to RenderMan Shading Language, did you choose that so users can port their existing shaders more easily?
LG: RenderMan Shading Language did a lot of things right, we wanted to build on that where it worked, but did not hesitate to deviate where we could improve. We didn't really worry about porting existing shaders, but we certainly wanted to build on what shader programmers already know of existing programming languages. RSL in turn looks very similar to C, as do most of the widely used shading languages (GLSL, Cg, Mantra, etc.), for similar reasons. There's no advantage to starting out with a language syntax that is wildly dissimilar to anything that shader writers are used to.