Interview with Andrew Kaufman from Image Engine on the usage of OSL for non-shading tasks in the open-source lookdev-tool Gaffer.
BD: We are here at FMX 2019 with Andrew Kaufman from Image Engine. Andrew, what was the rationale for choosing OSL for things like compositing, procedural modeling, Python scripting, and generating volumes as OpenVDB grids and what were your experiences?
Andrew Kaufman: One of the core philosophies in Gaffer is that we want to keep the number of languages minimal. We use C++ for all our core computation for performance reasons. Python is used for all the glue code and a lot of the UI. We needed a language that sits between the two, so we tried to see how far we can push OSL. We were already using it for shading and wanted to see whether or not we could use it for some live data manipulation in Gaffer, rather than introducing another language. One of the things we found out after that experiment proved successful, is that there are really good benefits to cross-training our employees in this language. We end up with people in all departments knowing OSL for one reason or another. Maybe you are in FX and you are learning OSL because you want to use it in your instancing setup or maybe you are in lookdev and you know OSL very
well because you are writing shaders all the time. Maybe you are in a department that is in between and you need a little bit of OSL for your QC render template. As a result, we end up with all these artists who know this language, which is useful for fast prototyping and actually seems fast enough for final results in most cases.
BD: What were your experiences with the users, how did they pick it up?
Andrew Kaufman: A lot of people were able to adopt it fairly quickly. For example, people who come from an Arnold or Renderman background would be familiar enough with OSL to be able to pick it up easily. People with a background in Houdini are used to VEX, so it is a kind of natural transition. You have to learn the new language in that case, but it is similar enough that you don’t have to spend a lot of time doing so.
BD: Did you find any boundary cases where OSL does not cut it?
Andrew Kaufman: So far, we have not. If we did discover boundaries where OSL was not working, we optimized how we were using OSL inside Gaffer. There is a lot of C++ you have to write in order to use OSL in the first place. So we optimized that code path. In the end, we always have the fall-back option to write a pure C++ node if we need to.
BD: OSL is not ported to work on GPU yet. That is probably not a problem at Image Engine because you are not using GPUs that much.
Andrew Kaufman: The master branch of OSL is getting there in terms of GPU support. It would be really cool to see what kind of performance gains we can get from that, but for now it has not felt necessary.
BD: How did OSL come along as a Python replacement?
Andrew Kaufmann: It works very well as a Python replacement in terms of performance but we really have not had much success incorporating it in production. Most artists still prefer Python over OSL. It lacks complex data structures and Python has a lot of useful modules that are not available in OSL. For example, if you want to interface with your asset management database or read a JSON file, you cannot do that in OSL. That is enough of a hindrance to prevent people from switching. We also do not have enough documentation yet on why it is beneficial.
BD: Using OSL to deform geometry is an obvious use case, but there probably is a lot of work to do to support it in a DCC. How difficult was it for you to plug it into all those parts of the pipeline?
Andrew Kaufman: I do not have actual stats on how much development time went into it. I know we did have to make a couple of pull requests back to OSL in order to get it running fast enough in those scenarios. We needed some extra queries to be able tonshort-circuit things. The code is on Github. If you take a look into the GafferOSL module, you can walk yourself through it. It certainly is complex if you are coming to it for the first time but it shouldn’t be overwhelmingly difficult for anyone who is writing a DCC.
BD: You did all the groundwork, so it is easier for those who want to follow up.
Andrew Kaufman: That is one of the advantages of open-source software, you end upnwith proper reference implementation thatactually works, not just some white paper that might be missing crucial details. For example, if you want to interface with your asset management database or read a JSON file, you cannot do that in OSL. That is enough of a hindrance to prevent people from switching. We also do not have enough documentation yet on why it is beneficial.
BD: Someone is writing a Cycles integration into Gaffer.
Andrew Kaufman: The Gaffer-Cycles project is a good example of extending Gaffer on your own. We have an extension system, not a plug-in because there is no plug-in API you have to map to. Just write your li- braries and get them on the right path. The extension system helps you do that. The Gaffer-Cycles project will presumably be considered stable at some point. The developer set it up as an extension so that you can download it separately from Gaffer, set a single environment variable and be good to go. Someone is working on porting Gaffer to Windows as well. That project can’t be done as an extension, because it requires core changes, but I know a lot of people are looking forward to using Gaffer on Windows. So hopefully that effort will be incorporated back into the official releases later this year.