the 5.2.1.1 - 5.4.4 MtoA upgrade breaks rendering on our Linux renderfarm clients

[spencer]

The setup: lab full of Windows 10 workstations, with Maya 2023 and MtoA 5.4.4 (Arnold 7.3.4). Deadline for renderfarm management. Small (six hosts) Linux-based renderfarm, with Maya 2023 and MtoA 5.2.1.1 (Arnold 7.1.3.2).

Despite the version difference in MtoA, rendering works just fine.

Updating the MtoA version on one of the renderfarm clients, to match what's on the workstations, breaks rendering, and it has to do - I think - with color management. These are from the job output logs in Deadline - same render job, just before and after the MtoA update.

OLD MtoA

[color_manager] using color manager of type "color_manager_ocio"

[color_manager_ocio] using config file /usr/autodesk/maya2023/resources/OCIO-configs/Maya2022-default/config.ocio

NEW MtoA

[color_manager] using color manager defaultColorMgtGlobals of type "color_manager_ocio"

ERROR [color_manager_ocio] could not read '<MAYA_RESOURCES>/OCIO-configs/Maya2022-default/config.ocio' OCIO profile.

I've tried setting the MAYA_RESOURCES environment variable directly and can see it when I log into the renderfarm client but that does not help.

My guess is that something changed in Arnold between 7.1.3.2 and 7.3.4, but I don't know where to begin to figure out what changed, and how to fix it. 

Can someone help with this issue? Thank you.

[ashley.handscomb.retallack]

The path key <MAYA_RESOURCES> should be replaced by the color manger translator with the path to the maya resources folder before rendering starts. Are you rendering .ass files directly or the Maya scene?

[Stephen.Blair]

For Arnold to print that message, "<MAYA_RESOURCES>" has to be passed directly  to Arnold as the ocio path. That should never happen.

Seems to be something general about <MAYA_RESOURCES> not being replaced:

Error could not read '<MAYA_RESOURCES>/OCIO-configs/Maya2022-default/config.ocio' OCIO profile - Cha...

Maya2022/2023/2024 vray 6.1 renderout in deadline different from local render - Deadline - AWS Think...

[spencer]

I am rendering a Maya scene, not an .ass file.

[spencer]

It does appear to be something that's not working correctly in Deadline. I've attached the task report from the render job in Deadline to this reply; one can see where it's throwing the error.

The "Gotta Jibboo..." and subsequent environment variable setting messages come from the Deadline "GlobalJobPreload.py" file being executed.

[spencer · Accepted solution]

This is, I think, resolved successfully. 

I needed to add a "path mapping" rule in Deadline to swap <MAYA_RESOURCES> for /usr/autodesk/maya2023/resources which lets me successfully render.