Open mkuo-lucasfilm opened 5 months ago
Thanks for this note, @mkuo-lucasfilm, and I'm CC'ing @niklasharrysson so that he's in the loop.
Thanks for the report @mkuo-lucasfilm. This is a case we have not run into before, where the concept of front and back shader assignment needs to be wrapped up in a custom node. We have considered the surfacematerial
node to be a terminal node that just handles shader assignment to geometry.
But I can see how this is needed to wrap up the LamaSurface
node as a self-contained node. So this is something we need to address in shader generation, to support having custom nodes with outputs of material
type.
I came across shader compilation errors when trying to implement a new LamaSurface node (Renderman definition: https://rmanwiki.pixar.com/display/REN26/LamaSurface). The LamaSurface node has two inputs of BSDF type and returns a surfacematerial.
We saw that the MaterialX Viewer skips the LamaSurface example because of this function (https://github.com/AcademySoftwareFoundation/MaterialX/blob/328fde8c5f293c1e6d6b14df0877c533be059855/source/MaterialXGenShader/Util.cpp#L368), which requires the top-level surfacematerial to be connected to a top-level surfaceshader. We believe that this check is in place as MaterialX does not yet have logic that handles custom nodes that return surfacematerial data, as this pattern is not used in any of the examples in the MaterialX repository.