Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Not all of the operations of OSL are supported. The following are currently not supported:

  • material closures
  • trace
  • environment
  • pointcloud_search
  • pointcloud_get
  • pointcloud_write
  • setmessage
  • getmessage
  • surfacearea
  • raytype

Also note that currently only the standard three types of OSL texture filters are supported. OSL shaders using incomplete or unsupported features can cause the program to terminate.

...

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

...

The SIMD version of OSL is optimized to execute 16 samples at a time with Intel® Advanced Vector Extensions 512 (Intel® AVX-512). It can also execute using Intel® Advanced Vector Extensions 2 (Intel® AVX2), Intel® Advanced Vector Extensions (Intel® AVX), or Intel® Streaming SIMD Extensions 4.2 (Intel® SSE4.2) at reduced performance levels. The SIMD version of OSL supports all OSL 1.8 language features and library calls supported by RenderMan.

It is enabled with the following user optionfollowing option

Code Block
Option "userosl" "int osl:batched" [1]


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. The Batched mode may have a greater impact on startup time than non-batched but for complex scenes the overall benefit is worthwhile.

...

There are a couple of options that control the behavior of OSL and it's usage in RenderMan.

  • Option “user” “osl” “int osl: verbose” [0-5] – Controls the verbosity of OSL message echoed by RenderMan. 0 is off, and 1-5 each add one more class of OSL messages to what is printed. Those classes are 1 – SEVERE, 2 – ERROR, 3 – MESSAGE, 4 – WARNING and 5 – INFO.

  • Option “user” “osl” “int osl: statisticslevel” - This is similar to the “osl:statistics:level” attribute, but it controls the level of statistics tracked by RenderMan for the integration of the OSL shading system as a whole.

Note a number of OSL attributes options are available to be set within a RIB file. The following attributes options are supported:

  • Attribute Option "user" "int osl:debug" [0]
  • Attribute Option "user" "int osl:optimize" [1]
  • Attribute Option "user" "int osl:lockgeom" [1]
  • Attribute Option "user" "int osl:debug_nan" [0]
  • Attribute Option "user" "int osl:debug_uninit" [0]
  • Attribute Option "user" "int osl:compile_report" [0]
  • Attribute Option "user" "int osl:statistics:levelrange_checking" [0]

Refer to the OSL documentation for details on their usage.  You can read more about the current version of OSL by visiting OpenShadingLanguage.

Accessing Shading Contexts

It's possible to access RenderMan specific contexts that C++ shaders can see on the RixShadingContext via the getattribute call with "context" as the object. 

Code Block
string mymode = "unknown"; getattribute("context", "shadingMode", mymode);
if (mymode == "displacement") ...

...

Utilizing the trace() shadeop:

Limited support for the trace() shadeop is included.  The trace() shadeop cannot be called during displacement, presence, and opacity shading.  The trace() shadeop is also limited to retrieving geometric values, as we disallow recursive shading so the optional "shade" parameter is ignored and always assumed to be 0. After a trace(), getmessage() can retrieve the "hit", "hitdist", and "geom:name" values, as well as values for primvars on the hit geometry.

Accessing Shading Contexts

It's possible to access RenderMan specific contexts that C++ shaders can see on the RixShadingContext via the getattribute call with "context" as the object. 

Code Block
string mymode = "unknown"; getattribute("context", "shadingMode", mymode);
if (mymode == "displacement") ...


The values for "shadingMode" correspond to the RixSCShadingMode in RixShading.h:

  • presence
  • opacity
  • scatter
  • volumeTransmission
  • volumeScatter
  • emission
  • bake
  • displacement

If you desire grid-like shading instead of ray hits, rather than use shadingMode, you can query a boolean context attribute which returns either 1 or 0 and includes:

  • eyePath
  • lightPath
  • primaryHit
  • missContext
  • reyesGrid

Accessing RIS builtin Variables

Things that are accessible via the RIS GetBuiltin shading call are exposed in OSL via

getattribute("builtin", "varname", val); 

unless they are already available via standard OSL globals.  The following are available via this call (see the RixShading documentation for their definitions):

  • Po
  • PRadius
  • Non
  • Naon
  • Tn
  • curvature
  • curvatureU
  • curvatureV
  • Id
  • Id2
  • incidentRaySpread
  • incidentRayRadius
  • incidentLobeSampled
  • mpSize
  • motionBack
  • biasR
  • biasT
  • du
  • dv
  • dw
  • dPdu
  • dPdv
  • dPcameradtime
  • outsideIOR
  • wavelength
  • Oi

Note that the du/dv/dw/dPdu/dPdv values obtained this way during ray-traced hit shading will represent radius based differentials as used throughout RIS, instead of the usual diameter based differentials provided in OSL globals and via implicit differentiation via Dx()/Dy() calls.

  • presence
  • opacity
  • scatter
  • volumeTransmission
  • volumeScatter
  • emission
  • bake
  • displacement

If you desire grid-like shading instead of ray hits, rather than use shadingMode, you can query a boolean context attribute which returns either 1 or 0 and includes:

...

Implicit Derivatives

OSL uses implicit differentiation to track the derivatives of variable where needed.  RenderMan maps the x and y space of derivatives to the implicit u and v space of the underlying geometry.  Implicit derivatives are used to control texture filtering, and can also be used to create new shading normals for bump-mapping. However, this only works if the original values coming from the renderer are "primed" with derivatives, because they must be computed along with the variables from those initial values, transformed through other mathematical operations, until they are used in a texture() or calculatenormal() call.  The main place these derivatives will come from is the shader global P, and indeed prman primes this shader global with appropriate derivatives.  Additionally, interpolated varying primitive variables on the geometry that are accessed with getattribute("primvar","primvarname",value), or simply just getattribute("primvarname", value)  will have derivatives provided. 

...