This post will discuss common issues and solutions when using cryptomatte AOVs together with teamrender in Cinema 4D.
When using AOVs in Cinema 4D, users expect them to work exactly the same way as other AOVs. but that is not the case, especially when using it in combination with teamrender.
In Cinema 4D, the difference between using the Multi-pass and the Direct checkboxes in the AOV panel is important.
A brief summary of direct passes:
There are two ways of exporting AOVs out of Redshift. Using the native cinema 4D multi-pass paths (workflow) or using the Redshift native ‘direct’ paths.
When you use the Multi-pass checkbox on an AOV (this is the default for most passes) then you are using Cinema 4D’s native multipass settings and paths as shown below. (In that case, make sure it’s enabled, and that you are using the correct path.)
When you have Direct enabled on the other hand, it will use Redshift’s own saving workflow instead. This is the default for cryptomatte passes, for example.
A main advantage of Direct is that when using Direct you can control the direct output setting on a per-AOV basis. That is not possible with the Standard Cinema 4D Multi-pass method.
When you have both checkboxes checked (Multi-pass and Direct), you are then saving both simultaneously.
In this example, I created a shared folder so all windows machines have access to that same folder.
I mounted that folder to a drive letter—letter W in this case.
If we render as normal, we can use the multi-pass method, and render to this ‘renders’ folder that I created.
This will work fine with the multi-pass method. However when we need to use the ‘direct’ method, as it is the case with cryptomatte, then these relative paths are not sufficient.
In the example above I mounted a path to a drive letter called W.
If we render the cryptomatte AOV in this same way the following problem will happen:
It will render only one of the two cryptomatte frames when using teamrender. The reason for this is because on one machine the shared folder is mounted to the letter 'W'. But on the other machine that path does not exist.
Because of that, we need to use an ‘absolute’ path instead.
You can check the full path inside explorer like this:
In the image above you will notice sections A (the machine name where the folder is shared) and B, the drive letter that we normally see with mounted drives.
However, if we change the path inside Cinema 4D to contain the machine name instead of that drive letter, then cryptomatte (the direct AOV pass) will be able to be saved for both frames in our example.
That means that THIS:
Will become THAT:
Now we’re using an absolute path. And as we can see when using RS Cryptomatte AOVs together with teamrender, everything should save correctly. (In our case it should save all 2 frames, one from each machine.)
The reason this now works is because the ‘direct output' path that you can see on the right side of the AOV panel now refers to an absolute path.
The default ' direct’ path
By default it’s using three variables for the full path there ($filepath, $filename, $pass):
This is pointing to the path that is set inside the multipass section of the save tab in render settings
You can find what the filename is inside the AOV tab of the Redshift rendersettings. In our example:
This refers to the AOV name that is set inside the AOV panel.
In the case of macOS or Linux, this article will elaborate in a bit more detail on what an absolute path might look like on Linux or macOS: