Open topic with navigation

Solaris AOVs

• Render Var LOP
• Redshift AOV Settings
• Render Product LOP
• Special Cases
• color vs rs:beauty Render Var
• Light Group AOVs
• Custom  AOV 
• Cryptomatte AOV
• Deep AOV
• Redshift Render Vars List

Render Var LOP

Render Var LOP

Use the Render Var LOP to create and control all Redshift AOVs.

Each Redshift AOV requires its own unique Render Var LOP and a specific Source Name that determines what type of Redshift AOV is used.

After Render Vars have been created they must be collected with a Render Product LOP before output.

A Render Var LOP is dependent on the following key parameters in order to determine what type of Redshift AOV is output.

• Data Type - This defines what type of data is necessary for the Redshift AOV and determines the channel names in the output image.

• Source Name - This defines what type of Redshift AOV is used for the Render Var.

  • List of Redshift Source Names

• Source Type - How the source name is interpreted by the renderer.

  • Raw is used for all Redshift AOVs

• Name - Custom name for the AOV that is output in the file name.

• Format - The format of the data when saving the image.

Primary Render Var parameters

Redshift AOV Settings

A Render Var LOP has its own Redshift specific settings tab that contains all of the Redshift AOV settings that would be necessary. By default these parameters are set to do nothing so they must be overridden when used with the corresponding AOV type.

In the example image below the AOV Denoising parameter has been enabled by using the "Set or Create" parameter option for this Render Var. For more information on overriding parameters in Solaris please see the Solaris Overview page.

Redshift specific settings for Render Var

Render Product LOP

Render Product LOP

Use a Render Product LOP to define a collection of Render Vars. A Render Product is then used in combination with a Render Settings LOP for final rendering.

The main parameter used in a Render Product LOP is the "Ordered Render Vars" parameter outlined below, it specifies the Render Vars that should be used in the final render for this Render Product. A * wildcard can be used in the path to automatically include any available Render Vars in that location as demonstrated below.

Render Product setup to automatically include any of the render vars

For more information on the Render Product LOP please see the Houdini documentation: https://www.sidefx.com/docs/houdini/nodes/lop/renderproduct.html

Special Cases

The Render Vars covered below have unique behaviors and requirements.

color vs rs:beauty Render Var

The "color" render var is the only AOV intended to be used as the primary IPR viewer in the Solaris viewport.

All other AOVs (including "rs:beauty") do not support IPR undersampling even though they can be previewed from the viewport itself.

It is important to always include the "color" render var in a Solaris render product.
IPR interactivity will be reduced when previewing any render var other than "color" as the active render output.

Main Redshift beauty pass: "color"	Additional Redshift beauty AOV: "rs:beauty"

Light Group AOVs

Light Group AOVs can be created in Solaris by creating a compatible Redshift AOV and then filling the "Light Group" parameter with a previously defined light group name that was used with a light in the scene. The example image below would create a Diffuse lighting AOV only for the key light in the scene.

Example settings for a Diffuse AOV for a specific "key_light" Light Group

Light Groups: Remainder

You may have lights in your scene that don't have a light group or don't need to be isolated for a particular AOV, but you still need their contribution rendered.

This can be managed by rendering the remaining lights by adding the "<other>" light group to the Light Group field — this automatically groups all remaining lights together into a single AOV.

Custom  AOV 

A Redshift Custom AOV can be created in Solaris with the "rs:custom" Source Name but the custom shader must be applied to something in the scene and the name of the render var must match the custom AOV name.

Since the custom shader may not be required for any objects in the beauty render this can be accomplished with a workaround by assigning the shader to an empty mesh node in the scene or a sphere with a scale of zero.

In the example image below an empty "mesh" node was created in the stage and then had an ambient occlusion shader assigned only to it. This satisfies the requirements for a Custom AOV and results in the expected render.

Assigning a shader used for a Custom AOV to an empty mesh node

Cryptomatte AOV

Adding a "rs:cryptomatte" render var results requires the additional step of defining a custom "Output File" location in the Redshift tab's Cryptomatte section as outlined below. The cryptomatte exr file cannot be included in a multi-layer EXR so it will always result in a separate crytpomatte only file.

Example settings for a Crytpomatte AOV

Deep AOV

If a "rs:deep" render var is required it must be rendered by itself as no other render vars are currently compatible with deep rendering in Redshift. A deep AOV also requires the additional step of defining a custom "Output File" location in the Redshift tab's Deep section as outlined below.

Example settings for a Deep AOV

Redshift Render Vars List