Loading MaterialX files in usdview

Community USD
1

Hi, I’m trying to wrap my head around referencing MaterialX files from USD.
No matter what I do, I seem to be running into errors in usdview –

Depending on which way I structure the file, I get either

  • usdMtlx/reader.cpp -- Output for </MaterialX/NodeGraphs/ND_MyNoiseGraph/noise_texcoord.inputs:in1> missing
    or
  • usdImaging/materialParamUtils.cpp -- Invalid info:id ND_MyNoiseGraph node: /MaterialX/Materials/MyNoiseGraph/ND_MyNoiseGraph.

If anyone would be able to take a look at the files and tell me what I’m doing wrong that would be well appreciated.
I tried:

  • directly referencing a .mtlx file from usda. The structure in usdview seems right, and the material is bound, but I get errors and no MaterialX.
  • referencing a .mtlx file as variant (in preparation for having multiple variants). Same as above the structure in usdview looks right, but I get errors and don’t see the material.

Here’s the files:
MyNoiseGraph-usda.zip (4.0 KB)

And if you don’t have time looking at the zip, here’s how the .usda looks, maybe the error is obvious?

#usda 1.0
(
    upAxis = "Y"
    metersPerUnit = 0.01
    defaultPrim = "Root"
)

def Scope "MaterialX" (
    references = [
        @./MyNoiseGraph.mtlx@</MaterialX>
    ]
)
{
}

def Xform "Root" (
)
{
    def Sphere "Sphere" (
        prepend apiSchemas = ["MaterialBindingAPI"]
    )
    {
        rel material:binding = </MaterialX/Materials/MyNoiseGraph>
    }
}
2

What version of MaterialX are you using for your runtime? I wonder if there’s a mismatch between your document and your runtime.

3

The MaterialX documents use 1.39, usdview is a local build from the latest release tag (v25.05.01) which to the best of my understanding also uses MaterialX 1.39.

4

I downloaded youre example files and you are referencing the mtlx file correctly in USD. The errors you are seeing are due to the fact that we do not currently support custom surface shader nodes when they are defined locally as you have done here. We only support custom surface shader nodes when they are defined in a shared library. Meaning the nodedef/nodegraph should be in a separate mtlx file from the file specifying the surface material. The path to the nodedef/nodegraph file should be specified with the PXR_MTLX_PLUGIN_SEARCH_PATHS environment variable. For your use case is it possible to redifine your custom node in that way?

5

Thank you so much for looking at my files.
If I understand your response correctly, that would be the last point under (7) in the USD-MaterialX-Docs, is that correct?

Nodegraphs with a ‘surfaceshader’ output can be defined locally, however custom nodes which are implemented using such a nodegraph need to have both the node and nodegraph defined in a shared library.

To follow up on that: the “shared library” concept means that the mtlx file with the custom node implementation can’t be embedded inside a USDZ file; it needs to be “somewhere else”. Is that correct? Or can it be embedded together with the other mtlx file in USDZ as well?

1 Like
6

Ahh ok it doesn’t look like the shared library approcah would work in a usdz context.
While we don’t support locally defined custom surface shader nodes we do support other nodes to be defined locally. So another way you can get this example working would be to remove the surface shader portion from the custom node. At the end of the day this custom node is plugging in a color to a standard surface shader node. So if you separate those things and update your custom node to output the color instead, and then plug that custom node output into the standard surface shader node, it would work. Is something that would work in general for you? To have custom nodes separate from the surface shader node?