PixarAnimationStudios / OpenUSD

Universal Scene Description
http://www.openusd.org
Other
6.03k stars 1.2k forks source link

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

Open pablode opened 2 years ago

pablode commented 2 years ago

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 commented 2 years ago

Filed as internal issue #USD-7388

jstone-lucasfilm commented 2 years ago

@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:

https://github.com/AcademySoftwareFoundation/MaterialX/issues/859#issuecomment-1132991144

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 commented 2 years ago

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 !