Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Khronos] MaterialX Specification for glTF texture procedurals #1906

Open
ashwinbhat opened this issue Jun 26, 2024 · 2 comments
Open

[Khronos] MaterialX Specification for glTF texture procedurals #1906

ashwinbhat opened this issue Jun 26, 2024 · 2 comments

Comments

@ashwinbhat
Copy link
Contributor

I'm relaying a request on behalf of members on Khronos glTF PBR Procedural Texture group committee.
The proposed extensions:

  1. KHR_texture_procedurals
  2. EXT_texture_procedurals_mx_1_39

will allow defining procedural patterns graphs in glTF using MaterialX 1.39 standard library nodes.

We are seeking clarification on MaterialX Specification, specifically around expected behavior of nodes when invalid values are supplied. Will the MaterialX specification define the behavior or will the behavior be defined by the underlying language implementation (glsl, msl, osl etc). This is especially relevant for math, and operator nodes in MaterialX standard library.
For example, consider sqrt node, what is the expected behaviour if input is negative?

In order for Khronos glTF PBR Procedural Texture group committee to proceed with using MaterialX 1.39 as a standard, it would be helpful if this behavior is clarified either at the node level or as a general guideline in the specification for each category of nodes.

@jstone-lucasfilm
Copy link
Member

@ashwinbhat This is a good topic, and my sense is that clarifying the edge-case behavior of each node is an important goal for the MaterialX project, and will be relevant for both glTF and OpenUSD use cases.

Taking your example of the sqrt node, the MaterialX specification should state explicitly which inputs have defined and undefined behaviors, rather than leaving this documentation to individual shading languages.

@ashwinbhat
Copy link
Contributor Author

Thanks @jstone-lucasfilm. I'm tagging @lexaknyazev for visibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants