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

Allow support for custom nodes that return surfacematerial data #1902

Open
mkuo-lucasfilm opened this issue Jun 24, 2024 · 2 comments
Open

Comments

@mkuo-lucasfilm
Copy link
Contributor

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 (

vector<TypedElementPtr> findRenderableMaterialNodes(ConstDocumentPtr doc)
), 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.

@jstone-lucasfilm
Copy link
Member

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

@niklasharrysson
Copy link
Contributor

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.

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

3 participants