Examine transparency handling for hardware code generation

[kwokcb]

This issue has been logged for discussion purposes

Background

• There is a code generation context setting on whether to consider "hardware transparency". By default this is set to false.
• The user must explicitly determine when this should be set to be true.
  • As a convenience a "is transparent" heuristic utility traverses the shade tree at a given shader root and examines specific inputs and input values to determine if the shader is transparent.
  • There have be requests to enhance this to recognize more cases. (the inputs considered are currently fixed)
• Depending on whether this option is set to true on not different code is generated.

Proposed Items To Examine:

• Whether the code to support transparency should always be emitted to avoid re-generating code which can be costly.
  • If unique shaders are cached then 2 versions are required to support "transparent" and "opaque" variants, or the same shader may need to be regenerated + replaced on value changes.
  • A value change implies a shader regeneration requirement but there is no support for this mechanism of detection.
• Whether the heuristic is too strict in checking for specific values to determine if a shade tree is (as opposed to could be transparent).
• transmission is not included in the final color computation and instead relies on h/w alpha blending which is a "cheap" way to draw transparent objects. This should be re-examined as this may not be a given.
• Enhance heuristics to allow for additional inputs to be checked with custom logic. e.g. should transmission_color be checked for "unlit" shader.
• do we still want to add support for a transparency "hint" attribute as proposed in the current 1.39 specification ? A suggestion from @niklasharrysson is that we move such a hint to <implementation>s as this has as it's main usage hardware rasterizers.
• more?

Appendix:

Some examples of such as switch:

• the PBR version of the surface constructor node here: https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/source/MaterialXGenGlsl/Nodes/SurfaceNodeGlsl.cpp#L201
• when emitting the final alpha blending of the fragment result here: https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/source/MaterialXGenGlsl/GlslShaderGenerator.cpp#L643
• for "unlit" shader support https://github.com/AcademySoftwareFoundation/MaterialX/pull/860

[kwokcb]

Based on specification discussion, the h/w logic should be updated to follow this heuristic:

hint (string): A hint to help code generators understand how input may be used.  The following hints are currently defined:
"transparency": the input is indicating a level of shading transparency.
"opacity": the input is indicating a level of shading opacity (inverse of transparency)

which can be added to the nodedef as desired and parsed as part of the heuristic utility.

Adding a ping to @JGamache-autodesk for follow-up from previous discussion.

[JGamache-autodesk]

I like this. Can I dream about a hint named "isotropic" that would select between isotropic and anisotropic versions of dielectric/conductor/schlick nodes when roughness.x is detected to be equal to roughness.y? This would allow standard_surface to run without a tangent stream most of the time.

[kwokcb]

Think dreams should be sent to @dbsmythe -- and best to raise this as a new "tangential" issue :)

The point about optimization based on "hint" is interesting but is counter to shader reuse as any value change means a rebuild is required. This is a good point though as an value change for transparency could also require a rebuilt but this does not currently occur.

So I would leave here an additional thought about adding an implementation level hint if a "value" change is a shader graph "topology" change.

[JGamache-autodesk]

Really good point! I am not currently integrating the isTransparent result into the shader hash used in the MayaUSD topologically-equivalent shader cache, which means a scene with a mix of transparent and opaque shaders is currently broken. Will open an issue.

[dbsmythe]

Regarding @JGamache-autodesk 's thought about adding a hint for anisotropy, this is an interesting idea which I think the hint system might be able to accommodate, though not quite in the same way as transparency/opacity. For transparency/opacity, the hint is placed on the to say that this input actually indicates the level of transparency or opacity, as the interpretation of those inputs is (I think) pretty universal and uncontroversial. For anisotropy, I think we could add a hint on whatever input is used to set the bitangent-direction roughness, but the hint's presence would merely indicate that there is a possibility for anisotropic reflections to occur, not necessarily that they are: this is because the input could either be specifying actual bitangential roughness, or it could be an anisotropic eccentricity amount depending on the implementation, and there isn't a standard interpretation of this value that I'm aware of. But since the primary purpose of this hint would be simply to indicate whether or not separate tangent/bitangent streams must be maintained, I think we can leave the interpretation of the hint as basically just a boolean "there might be anisotropy here". Not a perfect "there is anisotropy", but better than nothing. And note that the polarity of the hint must be "anisotropic" and not "isotropic" at least on nodes with two roughness-like inputs, as I don't think you could give a hint of "isotropic" and know that there couldn't possibly be anisotropy: since the hint lives in the nodedef, it can't be added only in certain situations known to be isotropic. For shader nodes with only a single roughness value, the absence of an "anisotropic" hint would be sufficient to indicate no anisotropy can occur.

One possible downside of this is that if an implementation now depends on the presence of this (new) hint to enable anisotropic reflections, then any legacy nodes without the hint in their nodedef would suddenly break.