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?

7

Just wanted to post an update here, that I have added/updated the suppport for locally defined custom nodes. These changes should be in the dev branch soon.

You can still reference in the mtlx files in the exact same way as you have done here and any local custom nodes should work. I would recommend keeping the custom nodeDefs/nodeGraphs separate from the material/surfaceshader nodes. So using at least two mtlx files. One to put the custom nodeDefs/nodegraphs, and another for the material/surfaceshader nodes where you are using the custom node(s) which of course includes the first.

2 Likes
8

Thank you.
I refactored the mtlx file as you said, here it is again:
SphereDistanceShader-usda.zip (2.1 KB)
Unfortunately it still throws an error while loading.

9

Custom nodes that use textures are required to have the nodegroup specified to be “texture2d” this is outlined in the UsdMtlx overview. Other than that, your custom node choices hit some subtle bugs, one due to the fact that you are using a custom multioutput node and another because your input names have a leading underscore.

To get this working right now you would need to rename _Map to Map …, and output just the calculated color3. So just set the metalness and specular_roughness values directly on the surfaceshader instead of having them come through outputs from the custom node. My apologies for not being clearer that I was suggesting to have the custom node output just the one color it was calculating and nothing else. But also thank you for doing that and helping to find these bugs!

Again I will note that locally defined custom nodes have been updated so you now can have your locally defined custom surfaceshader node that you originally attempted. However you will still need to remove the leading “_” from the custom node’s input names. I will work on fixes for both of these bugs and get them into dev as soon as I can.

10

Thank you for the notes!
Could you clarify why leading underscores are problematic? I wasn’t aware of that at all.

11

It can lead to name mismatches when we are up lining parameters and their values between the Storm and the Mx generated shader. It seems like in some cases the final parameter name has that leading underscore is removed, this seems to happen when the parameter name is concatenated with something like nodeName_paramName. So we would end up looking for the value of nodeName_paramName when only know about nodeName__paramName or something like that. I do have a fix so it hopefully it continue to be an issue for long.

1 Like