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

[hdSt] Incorrect material tag detection for MaterialX glTF PBR #1882

Closed
pablode opened this issue May 24, 2022 · 3 comments
Closed

[hdSt] Incorrect material tag detection for MaterialX glTF PBR #1882

pablode opened this issue May 24, 2022 · 3 comments

Comments

@pablode
Copy link
Contributor

pablode commented May 24, 2022

HdStorm detects masked and translucent MaterialX materials by checking for the opacity, opacityThreshold and transmission inputs:
https://github.com/PixarAnimationStudios/USD/blob/3b097e3ba8fabf1777a1256e241ea15df83f3065/pxr/imaging/hdSt/materialXFilter.cpp#L441-L507

But this logic does not work with the recently added MaterialX glTF PBR, as it has alpha, alpha_mode and alpha_cutoff inputs: https://github.com/AcademySoftwareFoundation/MaterialX/blob/ef98d9e8b4705b855f97afd23ee1fe5fb66cd736/libraries/bxdf/gltf_pbr.mtlx#L13-L15

I think a proper solution to the problem could be to traverse the node nodedefs breadth-first and to check for certain MaterialX PBR nodes and their inputs. More specifically, a bxdf/shading node most likely is translucent if the nodedef contains a translucent_bsdf. If it contains a dielectric_bsdf or generalized_schlick_bsdf with "T" or "RT" set for the scatter_mode input, it should also be tagged as translucent.

CC-ing @jstone-lucasfilm here for his opinion. Since rasterization-based renderers usually handle translucent materials differently than opaque ones, maybe a helper function provided by the MaterialX library would be an idea?

A second approach to the problem could be to have standardized metadata attributes for this purpose.

@jilliene
Copy link

Filed as internal issue #USD-7388

@jstone-lucasfilm
Copy link

@pablode This is a great question, and it's likely an area where both the MaterialX and USD codebases can be meaningfully improved. In MaterialX, we provide a mx::isTransparentSurface method for this purpose, but it has not yet been updated for the transparency conventions of the glTF PBR shading model:

https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/source/MaterialXView/Material.cpp#L73

As you note, a more forward-looking approach would be to provide metadata on shader inputs that describes their interactions with surface transparency, and there are discussions of this idea on the MaterialX GitHub and in the proposed specifications for MaterialX 1.39:

AcademySoftwareFoundation/MaterialX#859 (comment)

For now, I think it makes sense to update existing functions like mx::isTransparentSurface to take the conventions of glTF PBR into account, and these functions can then be integrated effectively into HdStorm.

@spiffmon
Copy link
Member

I confirmed that your "For now" proposal would work for us, @jstone-lucasfilm . We have discussed Sdr-level metadata to more flexibly describe these behaviors for rasterizers, but settled on the less robust name-matching @pablode identified because it facilitated already entrenched glsl shader-authoring patterns in the studio... if you do move forward in that direction, please keep us in the loop so we can verify with our shading folks that it would integrate into Sdr smoothly?

Thanks for drilling into this area, @pablode !

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

4 participants