# Rendering Engines

Multiverse supports all the major production rendering engines. This document outlines some specific notes, characteristics and limitations to be aware of when rendering with your favorite rendering engine.

Note

As of Multiverse 7 you can embed in USD files two types of "shading networks":

  • usdPreview*-based shading networks (including those in USDZ assets)

  • Maya shading networks made with the 3DelightNSI renderer: these can be rendered in Multiverse with 3DelightNSI and/or they can be used for DCC-interchange purposes.

  • Maya shading networks from other renderers: these cannot be currently rendered by Multiverse, but they can be still used for DCC-interchange purposes. Support for other renderers may be added in the future provided it is technically possible.

    TDs can use the USDShade schema to read and reconstruct embedded shading networks in other DCCs or in Maya itself and then assign them as Maya material overrides.

# 3DelightNSI and 3DelightNSI Cloud

# Attributes on dlSet

The 3Delight for Maya plug-in does not provide 3Delight attributes on the Maya objectSet nodes. Instead 3Delight for Maya offers its own set-like node for rendering attributes, it’s called dlSet. You can put this node inside a Multiverse mvSet node for selective attribute override from MEOW.

Together with similar nodes from other renderers, to achieve render-agnostic setups:

# Arnold

# Attributes on Maya objectSet

The Maya to Arnold plug-in provides Arnold attributes on the Maya objectSet nodes. You can put this node inside a Multiverse mvSet node for selective attribute override from MEOW, and, together with similar nodes from other renderers, to achieve render-agnostic setups.

TIP

Arnold is picky and won't show attributes when clicking on the add override attribute button if no geometry is inside the set node, so temporarily add a poly sphere inside the set node, this will display the attributes to add in the UI.

# Arnold issues & limitations

  • Arnold uses the ARNOLD_PLUGIN_PATH to load procedurals.

    Due to the fact that Arnold API is often updated and requires a recompilation for the new version, Multiverse needs to support multiple versions of Arnold (one for each time the Arnold API is "broken"), this means we need to supply clients with Multiple versions of the procedural.

    Other renderers have a more stable API and/or don't require to do so.

    Arnold will therefore output a warning message for each procedural in the ARNOLD_PLUGIN_PATH that is not compiled with the Arnold version in current use, for example if you are using Arnold 7.1 / MtoA 5.1 you will see a warning for each non version matching procedural:

    00:00:00   775MB WARNING |  mvUsdArnoldProcedural52.dylib was compiled against non-compatible Arnold 5.2.2.1
    00:00:00   775MB WARNING |  mvUsdArnoldProcedural53.dylib was compiled against non-compatible Arnold 5.3.0.1
    00:00:00   775MB WARNING |  mvUsdArnoldProcedural54.dylib was compiled against non-compatible Arnold 5.4.0.0
    00:00:00   775MB WARNING |  mvUsdArnoldProcedural60.dylib was compiled against non-compatible Arnold 6.0.1.0
    00:00:00   775MB WARNING |  mvUsdArnoldProcedural61.dylib was compiled against non-compatible Arnold 6.1.0.0
    00:00:00   775MB WARNING |  mvUsdArnoldProcedural62.dylib was compiled against non-compatible Arnold 6.2.0.0
    00:00:00   775MB WARNING |  mvUsdArnoldProcedural70.dylib was compiled against non-compatible Arnold 7.0.0.0
    
    1
    2
    3
    4
    5
    6
    7

    You can safely ignore these warnings because only the correct procedural will be loaded for rendering (in the above case the one not mentioned, mvUsdArnoldProcedural71.dylib, will be used because MtoA 5.1.0 / Arnold 7.1.0.0 are installed on the system which printed this warning).

    If these warnings annoy you, you can also delete, or move to a backup folder, the procedurals for Arnold versions that you have not installed and not lanning to use, and you will suppress the warnings.

  • Arnold threading (on Windows)

    It is recommended to adjust the number of threads in the [ Render Settings> System ] tab and make sure to use the option Total Num of Cores - 1 in order to give Maya GUI 1 thread to process all events.

# Redshift

# Attributes on redshift* set-like nodes

The Redshift for Maya plug-in does not provide Redshift attributes on the very useful Maya objectSet nodes. However Redshift for Maya offers its own set-like nodes for rendering attributes, such as the redshiftMeshParameters node (Redshift has also other set-like nodes). You can put these set-like nodes inside a Multiverse mvSet node for selective attribute override from MEOW, and, together with similar nodes from other renderers, to achieve render-agnostic setups.

# Redshift issues & limitations

  • Rendering from the command line via redshiftCmdLine.exe executable is not supported due a to Redshift internal limitation with material serialization in procedurals. You can however render from the command line using Maya batch via Render.exe -r redshift.

# Renderman

Minimum Version

The minimum supported version is Renderman 23.2.

# Output All Shaders

By default the Renderman for Maya translator does not translate shading engine nodes that are connected with custom attributes to Maya shape nodes.

In order for MEOW shader overrides to work as expected, you must set “Output All Shaders” rendering setting set to on (note that the default for this value is off):

# Attributes on Maya objectSet

The Renderman for Maya plug-in does not provide Renderman attributes on the very useful Maya objectSet nodes. However Multiverse solves this problem by adding the Renderman attributes to its own mvSet node (under the "extra attributes"). You can use mvSet node for selective attribute override from MEOW, and, by adding other renderer-specific set-like nodes, achieve render-agnostic setups.

# Renderman issues & Limitations

  • Due to a limitation in the Renderman, R08008 - Attribute grouping:membership isn't supported inside Renderman procedurals. Therefore reflect/refract/shadow set will only work “globally” on a mvUsdCompoundShape node, but not “selectively” on items in MEOW. This has been reported to Pixar also by other users, hopefully it will be fixed in newer versions of Renderman.
  • Turning a mvUsdCompoundShape node into a mesh light is supported, however “selective” mesh light on items via MEOW is not supported yet. It is technically possible to achieve this, so if you are a customer affected by this limitation please contact us to speed up fixing this issue.
  • Renderman 24 XPU cannot be supported since XPU itself does not yet support rendering procedurals.
  • Light linking USD prims with Maya lights is not possible due to limits in the RenderMan API design.

# VRay

# Attributes on Maya objectSet

The VRay for Maya plug-in does not provide VRay attributes on the very useful Maya objectSet nodes. Multiverse solves this problem by adding the VRay attributes to the Maya objectSet node.

VRay for Maya offers its own "set-like" node for rendering attributes, it’s called VRayObjectProperties. You can put this node inside a Multiverse mvSet node for selective attribute override from MEOW, and, together with other set-like nodes from other renderers, to achieve render-agnostic setups. Note that VRayObjectProperties does not contain all the VRay attributes (for example it lacks subdivision attributes), so we recommend to use the Maya objectSet node to which Multiverse adds all of VRay attributes.

# VRay issues & limitations

  • Multiverse needs to support multiple versions of VRay (v4, v5 and v6 so far) and due to the fact that VRay offers a single environment variable to find its plugins, both version of the Multiverse plugins for VRay need to be present in the same folder. VRay will therefore output an error for version of the plugin that does not match with the VRay version in use.

    You can safely ignore this error because only the correct plugin will be loaded and used.

    If this errors annoy you, you can also delete, or move to a backup folder, the VRay plugin and the VRay procedural for the VRay version that you are not using: this will suppress the warning.

  • Turning a mvUsdCompoundShape node into a mesh light is supported, however "selective" mesh light on items via MEOW is not supported yet. It is technically possible to achieve this, so if you are a customer affected by this limitation please contact us to speed up fixing this issue.

  • Changing frame or changing parameters while running an IPR session is not supported yet: this is a VRay specific issue and has been reported to Chaos Group.

Last Updated: 7/25/2023, 8:39:34 AM