​

Cryptomatte is an AOV shader which encodes Cryptomatte ID mattes into EXR outputs. Usage varies by DCC. In all DCCs however, it involves setting up a global AOV shader, though in Maya and Cinema 4D this is done automatically. AOV shaders are shaders that run on all samples after the main shading network has evaluated. When Cryptomatte is present, and a Cryptomatte AOV is active, it will handle the rest of the setup itself inside of Arnold. The setup includes creating more outputs, writing metadata and manifests, and installing the proper filters. Cryptomatte's Filter and sidecar manifest driver are bundled in the same plugin, but should not be used manually by users.

The basic procedure is as follows:

1. Activate a Cryptomatte AOV. This should be configured to write to an RGB EXR file.
2. Connect a Cryptomatte shader to AOV shaders in the render globals (in Maya and Cinema 4D this is automatic and can be skipped).
3. Render the EXR to disk. You'll get the AOV expanded into all the Cryptomatte data, with metadata. Options on the Cryptomatte shader can be considered global options for the system, in a sense an extension of the Arnold options.

Cryptomatte Globals

Sidecar Manifests

Write the manifest to a sidecar .json file instead of into the header. Writing these is deferred until after the render.

Cryptomatte Depth

Controls how many layers of Cryptomatte will be created, which is the number of matte-able objects that can be stored per pixel. 6 is the default and is essentially always plenty.

Strip Object Namespaces

A name processing option. Strips namespaces from objects in Maya style naming.

Strip Material Namespaces

A name processing option. Strips namespaces from material names in material matte.

Standard Cryptomatte

Preview in Exr

Preview AOVs are what users see in render viewers. The preview AOV is no longer used by decoders (like the Cryptomatte node in Nuke) and so are dead weight. This option is disabled by default, which means they don't write to EXRs (recommended off).

Process Maya

Maya Names: (for example, "namespace:obj"). If disabled, colons are considered as defining namespaces.

Process Paths

Path-Style names: (e.g. "/obj/path/name"). If enabled, anything before the last forward slashes is considered as defining namespaces.

Process Obj Path Pipes

Obj Path Pipes: (e.g. "|obj|path|name") Consider pipes (|) part of the object path. (For older C4D).

Process Mat Path Pipes

Strip Material Pipes: (e.g. "/a/b/c|standard_surface" -> "/a/b/c") In paths, cut material names after pipes (|). (For C4D).

Process Legacy

Legacy Styles: Includes old C4D style, as well as Softimage.

User-defined Cryptomatte AOVs

In addition to the Cryptomattes made with name parsing, you can create custom ones, driven by String user data. There are ports for defining four of them on the Cryptomatte shader.

"Offset" overrides for user-defined cryptomattes are not supported.

AOV Name The name of the AOV from which to create the Cryptomatte. This should be a custom RGBA AOV.

Source User Data

The name of the user data to be used. This must be string user data. If the user data is not present, the object will be part of the background.

Name Processing

All mattes are based on names. If two objects are named "horse", either through overrides or processed names, they will both belong to the same matte. Object names and material names are used for mattes.

Asset matte might be better called "namespace". It contains, by default, information that is extracted from the object name. This is complicated because different DCCS have wildly different naming conventions, and may be mixed style in the same scenes when sharing ass files.

Input name: `soldier:helmetShape`
Asset name: `soldier`
Object Name ("strip object namespaces" on): `helmetShape`
Object Name ("strip object namespaces" off): 'soldier:helmetShape`. 
Note: If "strip object namespaces" is on, soldier:helmetShape and soldier2:helmetShape would share the same object matte but not the same asset matte. 

Overrides

Standard Cryptomattes Overrides

There are also override mechanisms for changing the names of objects. These are all controlled through user data. The user data may be per object, polygon, curve, instance, etc. Manifests work properly with these, with some exceptions, such as the case of integer offsets on instanced objects.

Name overrides (type: string)

To override names used by Cryptomatte, user data of the following names may be used. They should be applied to the shape.

• crypto_asset - Overrides the shape's name in the "asset" Cryptomatte, if defined.
• crypto_object - Overrides the shape's name in the "object" Cryptomatte, if defined.
• crypto_material - Overrides the shape's name in the "material" Cryptomatte, if defined.

Maya example: to override asset name, add a string parameter named mtoa_constant_crypto_asset to a shape, and set that value to whatever you would like the name to be.

"Offset" overrides (type: integer)

crypto_asset_offset` `crypto_object_offset` `crypto_material_offset

If one of these integer attributes is defined (on a shape, polygon, curve, instance, etc), it modifies the existing name. Unlike the string overrides, it only modifies the name, it does not replace it. The integer value of the user data is appended to the name. For example:

object name: helmet` `crypto_object_offset: 4` `name in cryptomatte: helmet_4

On polygons or curves, this allows selection of certain clusters of polygons as if they were separate objects. On instances, it modifies the names of all the geometry in the instances. For example, if you have instances of tanks, and you put the user data onto the instance, then one tanks's thread material might be keyable as tread_material_1, and the next one might be keyable as tread_material_2.

Maya example: to override asset name, add a integer parameter named mtoa_constant_crypto_asset_offset to a shape, and set that value to whatever you would like the offset to be.