Shader Configuraion
Shader Configuraion
Shader Discovery
Before RIS we could identify shader files in the shader paths by their extension (".slo") and by introspecting the file using sloinfo. Now, with RIS plugin shaders we no longer have a unique extension (they are simply ".so" files) and we currently have no introspection mechanism. The way in which we discover shaders differs beteen RfK 1.x and 2.0; please see the sections below for details for each version.
Shader Discovery for RfK 2.0
RIS plugin shaders have no sloinfo equivalent, therefore we currently require an args file for each plugin shader in order to load the shader and its parameters. The shader's type is determined by reading the required "shaderType" element in the .args file and the parameters each now require "type" property to specify the parameter type. The plugin has been extended to parse the .args file in lieu of using a sloinfo-type mechanism for shader introspection. Please refer to the Shader Type Tags document for detailed information about configuring the shader type in the args file. Detailed information about creating and interpreting RenderMan args files can be found in the Args File Format Guide.
Shader Discovery for RfK 1.5/1.6
Since RIS plugin shaders do not have a unique extension, we currently enumerate shaders via an XML file referred to as the "shaderManifest". RfK ships with a shaderManifestPxr.xml file that enumerates a subset of the Pixar RIS shaders. Note the "Pxr" suffix. There can be any number of shaderManifest files, each with a unique name created by adding a specific suffix. As long as the file starts with "shaderManifest" and has an "xml" extension it will be recognized.
The PRMan19 plugin will look for shaderManifest files at the top of each RMAN_SHADERPATH path. The shaderManifest that ships with the RfK bridge (found in $KATANA_RESOURCES/Shaders) will load the PRMan shader plugins from the ${RMANTREE}/lib/RIS directory.
Determining Shader Type
In order to determine the type of a shader (e.g. light, bxdf, displacement) the RendererInfo plugin looks for a shader type tag in the shader's .args file. If it finds the "<shaderType>" node it will look for "<tag>" children to determine the shader types. If "shaderType" is not found in the .args file the RendererInfo plugin will use the sloinfo mechanism for shader classification.
Below is a simple example of a .args file with shader type tags. Please note that the <shaderType> node must be a direct child of the <args> node:
<args format="1.0">
<shaderType>
<tag value="surface"/>
</shaderType>
....
</args>
The type tags that Katana recognizes at this time are: surface, light, displacement, atmosphere, interior, exterior, pattern", and *bxdf.
In addition to the value tag a detail tag is used for passing extra information to the plugin for a particular shader. Currently only light shaders will utilize the detail value, looking for one of two hints:
- "geoAreaLight" to indicate shader is a geometric area light.
- "envAreaLight" to indicate shader is an environment area light.
If neither of these hints are specified as a hint on a shader of type "light" the light will be treated as a pseudo-area light.
<shaderType>
<tag value="light" detail="geoAreaLight"/>
</shaderType>
- Note:
The legacy method for identifying geo area light shaders is still supported. This method required a shader parameter named areaLightHint hint is present and set to "geoAreaLight". If there is no type tag or detail hint and an areaLightHint parameter is set to "geoAreaLight" then the shader is considered to be a "geometric area light shader". If it is not present or is set to another value (by convention "psuedoAreaLight") it is treated as a normal light. Note that this legacy behavior will be deprecated in a future version of RfK.