Arbitrary Output Variables (AOVs) are the secondary images produced by the renderer. There can be any number of them generated simultaneously and each one may go to a different file, a different display driver, or use different pixel filter settings. In some cases, special pixel filter modes may be used to avoid mixing values from different samples in a non-sensical way; typically these select a single sample to be representative of the whole pixel.
Broadly speaking, AOVs in RIS fall into these main categories: built-in, integrator (global), custom, and light path expressions.
For users interested in what is typically referred to as "render passes" for compositing a beauty image, look at the page on light path expressions (LPE).
The built-in AOVs display mostly geometric information pertaining to points on the visible surfaces seen by the camera. These values are automatically generated by the renderer and are available as AOVs regardless of the active integrator. Here is the current list of available builtin-ins:
Notice that data passes (normals, z-depth, world position, etc) are not filtered by default. Filtering together values may result in errors and nonsense values so it is avoided. Additive passes meant for beauty compositing are typically filtered the same to provide clean images and improved anti-aliasing.
id, rawId, z all use zmin filtering by default.
cpuTime and sampleCount use the sum filter by default.
Post motion blur (2D Motion Blur vectors) can be important to a pipeline. While we recommend using motion blur in the render, sometimes a lack of resources forces this to post processing.
dPdtime AOVs are useful for post blurring in 2D but this does not contain camera motion blur (the camera movement)
dPcameradtime AOVs are available for camera motion blur. This means motion blur can be separated and controlled with finer detail, especially if the camera movement introduced more blur than you'd like artistically, you can adjust it separately. A static camera will produce no results for this AOV and thus no example below. If you render from a locked camera then it can be omitted without penalty.
On top of regular LPE-based AOVs, this integrator outputs a number of standard AOVs typically used by compositors.
|P in world-space|
__Pworld.r : x component
__Pworld.g : y component
__Pworld.b : z component
|Nn in world-space|
__Nworld.r : x component
__Nworld.g : y component
__Nworld.b : z component
__depth.r : depth from camera in world-space
__depth.g : height in world-space
__depth.b : geometric facing ratio : abs(Nn.V)
__st.x : s
__st.y : t
__st.z : 0.0
|Reference Position primvar (if available)|
__Pref.r : x component
__Pref.g : y component
__Pref.b : z component
|Reference Normal primvar (if available)|
__Nref.r : x component
__Nref.g : y component
__Nref.b : z component
|Reference World Position primvar (if available)|
__WPref.r : x component
__WPref.g : y component
__WPref.b : z component
|Reference World Normal primvar (if available)|
__WNref.r : x component
__WNref.g : y component
__WNref.b : z component
In addition to the above, some custom shading plugins may recognize other requests for AOVs and respond to them in their own particular ways. The names of these AOVs and what exactly gets displayed is up to the particular plugin.