Fix edge color clamping in artistic_ior

[SavaLione]

Summary

Hi,

This fixes the issue related to the green circle on some materials:

• Standard Surface with colors outside of 0-1 renders incorrectly #3004

Three shaded backends were changed and tested: GLSL, OSL, and MDL.

I'm somewhat sure about the code for the GLSL and OSL shaders.
With the MDL shader, I'm not sure whether it is considered acceptable practice to add functions directly to the XML file.
Nevertheless, all tests completed successfully, and everything looks good to me (including the MDL backend).

Tests

I compiled MaterialX Viewer as a standalone application and as a web application using Emscripten.
The MDL backend was tested using the Nvidia MDL SDK (version 2026.0.2-391700.2276) and the supplied dxr.exe application in the examples.
Visually, everything looks OK.

Tests were successfully compiled and executed.
All 94 test cases passed (39629 assertions).

MaterialX Viewer web:

MDL before the fix:

MDL after the fix:

[jstone-lucasfilm]

Thanks for taking this on, @SavaLione! This looks like a good fix, and the GLSL and OSL changes are exactly what I'd expect. I have one request on the MDL side before we merge, along with a suggestion on test coverage.

On the MDL question you raised, this logic belongs in the MDL module rather than the implementation XML. The function body for mx_artistic_ior lives in source/MaterialXGenMdl/mdl/materialx/pbrlib_1_6.mdl, where it already clamps mxp_reflectivity in the same manner as the GLSL and OSL code, so the inline math::clamp on reflectivity in this PR is redundant with that existing line. I'd suggest leaving pbrlib_genmdl_impl.mtlx as it is on main, and instead applying the new clamp in the function itself, alongside the existing one:

color n = math::lerp(n_max, n_min, math::clamp(mxp_edge_color, color(0.0), color(1.0)));

Since each of the later versioned modules (1.7 through 1.11) re-exports this function from pbrlib_1_6, that one line covers every MDL version we generate.

On test coverage, none of our current test materials drive artistic_ior outside the [0, 1] range, so our render tests wouldn't catch a regression of this fix. I'd suggest adding a case with an edge_color above 1.0 to resources/Materials/TestSuite/pbrlib/bsdf/conductor.mtlx, which would exercise this path across all of our shading languages.

Overall this looks like a great second contribution, and with the refinements above, I believe it should be ready to merge.

[SavaLione]

Hi @jstone-lucasfilm ,

Thanks for the helpful information about the project's internal structure and how the MDL backend works.
Now I'm finally able to see where the MDL shader generation happens, and it definitely doesn't make sense to edit the XML files to fix the clamp issue (as you pointed out).

I have reverted all changes to the XML file and applied your suggested change to pbrlib_1_6.mdl.

Also, I implemented a test case that checks this particular issue:

The values for this test case are taken from the material mentioned in the initial issue (#3004), so it is possible to visually inspect the clamping on the gold surface.
If some tests use pixel diff, or if anyone needs to see a more noticeable difference, I can push the values outside the [0, 1] range.

[jstone-lucasfilm]

Excellent work, @SavaLione, and this looks ready to merge.