Following up on the discussion in #2914, this is a proposal to formally specify the behavior of MaterialX nodes when given inputs outside their accepted range, rather than leaving that behavior undefined as we do today. While this issue was first discussed in the context of math nodes, the underlying question applies broadly, so the intent here is to consider the change globally across the Standard, PBR, and NPR nodes.
As one example, our specification currently restricts the accepted values of ln to the range (0, +inf), and the result of ln for a non-positive input is undefined. Because the behavior is undefined, each shader generator defers to its underlying math library or GPU driver, where computing the logarithm of a non-positive number is itself undefined in GLSL. The practical result, as @bhouston observed in #2914, is that a degenerate-but-valid graph can render differently across our GLSL, MSL, and OSL generators, which works against the cross-renderer parity that MaterialX aims to provide.
The same pattern recurs throughout the libraries wherever a node declares an accepted-values range. It applies to other math nodes such as sqrt and acos, and to edge cases such as division by zero, atan2(0, 0), and normalization of a zero-length vector. It applies equally to the PBR nodes, where inputs such as weight, roughness, and IOR carry their own valid ranges, as well as to the NPR nodes. We already have one precedent for handling this kind of case explicitly in the standard library: the safepower node was added to give defined behavior where power of a negative base would otherwise be undefined.
For this GitHub Issue, we'd like a developer to write a proposal to the Specification Proposals document, establishing the overarching principle in the General section and then applying it across the relevant Standard, PBR, and NPR nodes, so that each defines a single, language-independent result across its full input domain. This can then be reviewed by the community and merged to main. The proposal can also note the design questions worth resolving along the way, such as which behavior to specify for each node, whether to redefine existing nodes or add safe variants in the manner of safepower, how to manage backward compatibility for assets that depend on the current behavior, and how to weigh the small added cost of guards in generated shaders.
Because this would touch a wide surface of the libraries, it is all the more valuable to work through the design before moving to implementations. If we proceed with this change, we should update the specification and codebase in tandem, adding the guards needed in each shader generator so that all languages exhibit consistent results for these inputs in each version of MaterialX.
Following up on the discussion in #2914, this is a proposal to formally specify the behavior of MaterialX nodes when given inputs outside their accepted range, rather than leaving that behavior undefined as we do today. While this issue was first discussed in the context of math nodes, the underlying question applies broadly, so the intent here is to consider the change globally across the Standard, PBR, and NPR nodes.
As one example, our specification currently restricts the accepted values of ln to the range
(0, +inf), and the result oflnfor a non-positive input is undefined. Because the behavior is undefined, each shader generator defers to its underlying math library or GPU driver, where computing the logarithm of a non-positive number is itself undefined in GLSL. The practical result, as @bhouston observed in #2914, is that a degenerate-but-valid graph can render differently across our GLSL, MSL, and OSL generators, which works against the cross-renderer parity that MaterialX aims to provide.The same pattern recurs throughout the libraries wherever a node declares an accepted-values range. It applies to other math nodes such as sqrt and acos, and to edge cases such as division by zero,
atan2(0, 0), and normalization of a zero-length vector. It applies equally to the PBR nodes, where inputs such as weight, roughness, and IOR carry their own valid ranges, as well as to the NPR nodes. We already have one precedent for handling this kind of case explicitly in the standard library: the safepower node was added to give defined behavior wherepowerof a negative base would otherwise be undefined.For this GitHub Issue, we'd like a developer to write a proposal to the Specification Proposals document, establishing the overarching principle in the General section and then applying it across the relevant Standard, PBR, and NPR nodes, so that each defines a single, language-independent result across its full input domain. This can then be reviewed by the community and merged to main. The proposal can also note the design questions worth resolving along the way, such as which behavior to specify for each node, whether to redefine existing nodes or add
safevariants in the manner ofsafepower, how to manage backward compatibility for assets that depend on the current behavior, and how to weigh the small added cost of guards in generated shaders.Because this would touch a wide surface of the libraries, it is all the more valuable to work through the design before moving to implementations. If we proceed with this change, we should update the specification and codebase in tandem, adding the guards needed in each shader generator so that all languages exhibit consistent results for these inputs in each version of MaterialX.