MaterialX icon indicating copy to clipboard operation
MaterialX copied to clipboard

Allow support for custom nodes that return surfacematerial data

Open mkuo-lucasfilm opened this issue 1 year ago • 2 comments

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.

mkuo-lucasfilm avatar Jun 24 '24 22:06 mkuo-lucasfilm

Thanks for this note, @mkuo-lucasfilm, and I'm CC'ing @niklasharrysson so that he's in the loop.

jstone-lucasfilm avatar Jun 24 '24 22:06 jstone-lucasfilm

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.

niklasharrysson avatar Jun 28 '24 11:06 niklasharrysson