Critters, using a shader network of nine OSL shaders wired together via PxrOSL

Users who are willing to trade off additional flexibility for decreased efficiency have access to OSL via the PxrOSL node. The PxrOSL node has two modes of operation:

  1. Single Shader Mode:

    • write a single OSL shader, and an optional, corresponding .args file
    • compile it (with oslc)
    • include the node into a larger PxrPattern/PxrBxdf network by passing the .oso filename to PxrOSL
  2. Network Instance Mode:

    • write a number of OSL shaders
    • compile them to .oso (with oslc)
    • "wire" these together, either manually or preferably with the help of a node-authoring system
    • produce an OSL-network XML file to describe the interconnections of nodes
    • produce an optional .args file to expose the interface for the network
    • include the network in a patter/bxdf network, usually just a single PxrBxdf target, passing the name of the network file (without the .xml file extension) to PxrOSL

PxrOSL patterns currently support many of the features of OSL, but it is important to note that they do not support the use of closures. Instead the plugin is designed to create pattern results that are subsequently utilized by connecting the OSL outputs to other patterns and also feeding the OSL shader results into the various inputs of BXDFs.

An example of this is provided below, wherein two different OSL shaders are used: one to create an wood texture (adapted from "Advanced RenderMan") and another to create a 2-layer material that looks like carbon fiber. For each surface type, the same PxrDisney shader is used, but two very different PxrOSL shaders are used to create the different looks.


Oak and carbon fiber, using two OSL shaders wired into PxrDisney

The RIB file for the image above is provided in the /lib/examples/RIS/scenes/pattern/osl/ directory of your RenderMan Pro Server installation, the OSL shaders in the /shaders/ subdirectory therein.

PxrOSL Performance Notes

There are a couple of performance considerations to be aware of when using PxrOSL. Firstly, OSL executes shaders in a "vertical" fashion, instead of across a grid of points like other PxrPattern nodes. This can result in a loss of efficiency if many textures are accessed and the setup for the textures is executed continuously across an group of shading points.

Also, the cost of compiling the shaders and shader networks at runtime can become a significant, especially since this compilation phase will prevent multiple threads from running at their highest efficiency. Normally for scenes that take a while to render, this cost is effectively amortized. However, if there are hundreds of thousands of unique shader instances, that cost can start to impact final render times.

One of the benefits of using OSL, however, is the ability to create optimized, native machine code based on the uniform input parameters to the shader. For complex networks and code that is written to take advantage of these optimizations, the performance improvements can be significant.

Known Limitations

As yet, not all of the operations of OSL are supported. The following are currently not supported:

  • material closures
  • textureinfo
  • trace
  • texture3d
  • environment
  • pointcloud_search
  • pointcloud_get
  • pointcloud_write
  • setmessage
  • getmessage
  • surfacearea
  • 16-bit textures
  • arbitrary named transforms

Also note that currently only the standard three types of OSL texture filters are supported.

See Also

  • For technical information about PxrOSL and further implementation details, see Working with PxrOSL.