...
Any closure can be output to a special outputvariable() function to be output as an AOV. "Pass through" nodes are familiar to Softimage users: they can be inserted anywhere in a Shade Tree to register the downstream subtree as an output variable.
Consider the following simplified line of code and the corresponding evaluation :
...
| Info |
|---|
Note that AOVs can be output in any node of the OSL tree. If two different OSL nodes contribute to the specular_aov variable 3Delight will correctly blend their contribution together in the final output and in the AOV. |
AOV Forwarding
3Delight introduces the concept of AOV forwarding to solve a classical problem with reflection, refraction and transmission AOVs. For example, a diffuse surface reflected by a mirror will usually appear in the reflection AOV. In some cases it is much more practical to see that diffuse surfaces in the diffuse AOV, leaving the reflection AOV black for that surface. This feature is not part of OSL language but is an attribute that users can set on a per-object basis. This means that there is no need to change your shaders in order to benefit from this feature.
Follows a visual example of some commong AOVs with and without forwarding:
| RGBA | diffuse | reflection | refraction | emission | |
|---|---|---|---|---|---|
| Without forwarding |  |  |  |  |  |
| With forwarding | |  |  |  |  |
Gone is lockgeom
A remnant of the RenderMan way of doing things is the 'lockgeom' parameter which hints of symbolic linking of data defined on the geometry to parameters defined in the shader. From our point of view, this is feature is useless, as-is, in the OSL world:
- Symbolic linking is weak in that it is ill-defined : what happens if you have many parameters with the same name in an OSL network ?
lockgeomcan be elegantly implemented by a ... connection (explicit linking).
...