The Material Library LOP has a "Tab Menu Mask" parameter (inside the Tab Menu collapsible folder) that filters the entries in the Tab menu inside.

You can add your name to that list. Or if you name your HDD with the "builder" suffix, then the globbing entry '*builder' should already allow it.

There is no direct conversion from .mtlx to .usda in Houdini. The only way to to it is to read .mtlx with a Sublayer LOP (Tab > File), and then save the LOP's stage out to .usda file (eg, RMB on the LOP > Save > ...)

It does not look like anything changed there.

vrbn studios
This could also be achieved with the new GeomPropValueUniform node which was added to materialx last month. Is there a timeline yet for when this could be added to houdini?

GeomPropValueUniform will be available in the next version of Houdini.

tamte
My current solution is to create a "Material Library" node and add a MaterialX Shader Builder node for each sub-mesh.

Or if you want to have two levels deep, then you should be able to put down a subnet inside the LOP, and put the material builders inside it. Then point to them in the LOP's parameters to create USD materials.

What version of Houdini are you using? There were some issues with saving shelf tools, and that bug has been fixed in H20.5.402.

It should work fine in any H20.5. Make sure you switch to Karma in the viewport top-right corner.

The subnet in the kma_aovs.hiplc file needs a "Render Mask" spare parm to help Solaris figure out the correct shader translator. See attached fixed file.

The Material Library LOP traverses VOPs starting from the terminal (eg, subnet outputs in this case), and for each VOP it tries to use an appropriate shader translator based on the render mask intrisic property of an HDA or based on 'shader_rendermask' parameter. Karma networks consist of MaterialX and Karma-only nodes, so the translators can switch from node to node.

The subnet VOP can be quite problematic because it is common node use by many "languages", so deciding on a correct translator can be tricky. There are some heuristics trying to guess a best match, and it works most of the time. Here however, it looks like a wrong translator is picked which messes up the shader translation.

Because only Karma understands AOVs set up like that, it is crucial that the translation is performed using the karma shader translator throughout the whole network. And for that, the subnet needs to have that Render Mask spare parm set.

You can add such spare parm from RMB on the subnet > Parameters and Channels > Edit Parameter Interface..., then in the left-most panel choose Node Properties and search for "shader_". You will see a bunch of spare parms that help guide the translation of VOPs, and "Render Mask" is one of them.

This popped up again recently so I re-did the example using an HDA as jsmack suggested.

It's probably because you used "-n switch_20" on the command line. I think the MaterialX shader name is derived from the HDA name.

You can change the shader name in the HDA Op Type Properties in Houdini (RMB > Edit Operator Type). In the inputs/outputs there is a shader name for each signature. You can change that to an arbitrary shader name.

MaterailX shader nodes have only inputs, thus only VOP node inputs get translated to materialx. However, your channel reference approach (to the 'blend_mode' top parameter) should work, since ultimately you are setting a value on a MaterialX shader input.

As for the color-space value, in MaterialX, they are authored as an attribute of the input element. But `vop2mtlx.py` might not be handling them properly. It, it may be a bug/limitation of that script.

Eventually yes, Houdini will utilize the UsdUIBackdrop but there are higher priorities at the moment. Houdini will need to do it for Karma and MaterialX builders. The 3rd party renderers will need to author them in their custom shader translators. And Houdini's Edit Material Network will need to recognize them for all renderers.

MR SMITH
Thanks Rafal! truly appreciate the effort creating those files. I managed to do some tests.

You're welcome. Happy to hear it worked.

MR SMITH
*One thing that was a bit weird is that I was able to make an .hda file without issues even though i'm on Indie. Is this something temporary or did that limitation change?

I think that's all fine. You can create HDAs in Indie, but they are saved in an indie format, so will downgrade the session if loaded into a fully commercial session.

MR SMITH
Is this roundtrip with mtlx / hda / json still reliable for future hou versions and mtlx standards?

Yes, it's reliable, and will continue to be. That's pretty much how MaterialX standard nodes are processed for Houdini releases.

Actually HoudiniGL seems to recognize the karmaNodeGraphs.json file, so it renders the new custom shader as long as it's implemented entirely with standard MaterialX nodes.

The rough steps are:
1) Build a subnet VOP containing the implementation of your custom shader. There are some annoyances with defining subnet inputs and naming them. Pretty much the input name is imposed by the Subnet VOP, and will need to be hand-edited in step 3.
2) RMB > Save > MaterialX... to a foo.mtlx file
3) Hand edit the foo.mtlx file to add the nodedef element for you shader. Also delete the shader nodes that are outside of the nodegraph but were saved nonetheless in step 1. Remember to remove references to them from the nodegraph's inputs and outputs.
4) run the `mtlx2hda.py` and the `mtlx2karma.py` scripts on the command line to create an .hda file for Houdini (to crate new VOP nodes) and .json for Karma to render them.
5) test out by restarting Houdini, loading .hda and creating a new node.

Here is an example .hip file with steps described in the sticky notes. This file works in my setup. The .hda and .json files should be put in Houdini search path, but they also work if you just start Houdini from the command line in the foo subdir.

Native mtlx nodes should be faster than python shader translation scripts invoked during cooking.

To get .mtlx shader implementation you can use `vop2mtlx` or you may have some luck with RMB > Save > MaterialX. You may still need to manually adjust the .mtlx and create the nodedef for your shader.

Then you will need to run mtlx2karma to generate karma networks for your mtlx shader.

This probably means that HoudiniGL will not render your shader, though.

Indeed, MaterialX 1.38 does not have a geom prop value shader that would return a uniform string. There is one planned for 1.39.

p.s.
In MaterialX 1.38 is a little bit iffy when it comes to strings they can only be uniform, and yet geom prop value shader returns a varying string.

Edit Material Network re-constructs the shader network from USD primitives. And the USD shader primitive network does not encode the network boxes.

P.s., There is a concept of UsdUIBackdrop, but the shader translators don't make use of it yet.

This is a bug in the Edit Material Properties LOP, which is being worked on.

It has trouble with hide-when and disable-when expressions, because that LOP deals with "inputs:diffuseDoubleSided" (incoded into alpha-numeric name to avoid a colon), but the hide-when expression still uses just "diffuseDoubleSided" from the shader's HDA node.

In the parameter pane toolbar, if you click (gear) > Edit Parameter Interface, you can manually clean it up. Eg, delete the hide-when expression, and accept. Then the parameters should show up.

You can contact support@sidefx and ask to be added to that issue ticket to see the status.

Usually, you can just connect the shader outputs to the Collect inputs.

This should produce a USD Material primitive with several terminal outputs uniquely identifying shader type (surface vs. displacement) and shader context (karma vs mtlx).