Unrecognized colorspace should throw rather than warn to stderr

[doug-walker]

Currently, if an unrecognized colorspace string is encountered in MaterialXGenShader, it prints a warning to std::cerr. This is not ideal for several reasons:

• The render proceeds and will have incorrect colors
• Printing to stderr is difficult for applications to deal with
• Raising an exception would be more in line with how MaterialX usually handles this type of situation

This PR changes the behavior to raise ExceptionShaderGenError.

This change required omitting the test file ocio_color_management.mtlx from the MaterialXGenMdl tests. The test was previously succeeding (when compiled with MATERIALX_BUILD_OCIO=ON), although it should not have.

In addition, a change was made to improve the name of the color space conversion functions generated by the OcioColorManagementSystem. Previously the names only used the cacheIDs of the OCIO Processors, which was not very friendly to troubleshooting. Now the names are more similar to the "srcColorSpace_to_dstColorSpace" naming used by the DefaultColorManagmentSystem. This avoids a problem when MaterialX is compiled with the current OCIO main branch due to a change in the cacheID formatting.

While testing, I noticed that the MaterialX createValidName function sometimes creates names with double underscores. OCIO's shader generator avoids this since (although some drivers accept it) it is technically undefined behavior. I added a sanitizeName function locally to work around this.

As I worked further, I noticed that the GenShader tests were not actually testing color management, even though MaterialXTest/MaterialXGenShader/GenShaderUtil.cpp explicitly tries to enable color management. The problem was that it was not ensuring that a targetColorSpace was set (as the rendering tests do). If that is empty, the color management shaders are never generated or tested. I ensured that is now being set. As a result, I needed to make sure the ocio_color_management.mtlx test file was omitted from the GenShader tests when OCIO is not enabled.

Finally, I fixed a bug with the DefaultColorManagementSystem where the conversion from "lin_rec709_scene" to "lin_rec709" was not handled properly as a no-op. I added a test case for this in color_management.mtlx.

Claude Code was used during the creation of this PR.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: doug-walker / name: Doug Walker (2681950, 767fab7)

[jstone-lucasfilm]

Thanks for putting this together, @doug-walker!

Moving from a std::cerr warning to a proper ExceptionShaderGenError is clearly the right direction, and I especially appreciate your catch that our GenShader tests weren't actually exercising color management, in contrast to our color-managed render test suite. The OCIO shader naming and the no-op fix in DefaultColorManagementSystem are both welcome as well.

One thing I'd like to work through before we merge: now that an unsupported transform throws, it reaches a spot in the Graph Editor that wasn't quite ready for it. RenderView::reloadShaders currently catches only mx::ExceptionRenderError, so a new ExceptionShaderGenError would propagate unhandled and take down the editor on shader reload. This looks like a pre-existing gap rather than anything introduced here (the neighboring loadMaterialLibrary and the Viewer's reloadShaders both already catch std::exception), but since this PR is what makes the path reachable, it seems like a natural place to address it.

For example, you could mirror the existing pattern as follows:

catch (mx::ExceptionRenderError& e)
{
    for (const std::string& error : e.errorLog())
    {
        std::cerr << error << std::endl;
    }
}
catch (std::exception& e)   // ExceptionShaderGenError, etc.
{
    std::cerr << e.what() << std::endl;
}

Let me know how this sounds to you, and I'm happy to help with the Graph Editor update as needed.

[doug-walker]

Thank you @jstone-lucasfilm, I'll add a commit with your proposed changes!