The mtlx nodes are lacking functionality and are low-level, which is fine. However, I can't seem to find a workflow to build upon.

I've tried creating HDAs. Initially, they seemed to work, but when things get more complex, the recooking process every time you change a slider becomes a non-viable workflow for me.

Annoyingly, if you add an mtlx constant into the parameter you're 'lookdevving', you can change the specific value through the constant without having to recook the entire network. Same goes for primvars. But keeping all those constants around makes the overal evaluation again slower.


Questions:

I'm assuming that native mtlx nodes are the only 'correct workflow' and will be much faster in the Python evaluation step compared to HDAs (will they though?)

Is the Python route with the voptomtlx still the way to go to convert HDA to mtlx? (or can use right click now)
https://youtu.be/QOUYP7My80M [youtu.be] I've checked this vid and seems like awefull lot of steps to roundtrip an asset to mtlx.

Is it easier to use something like Quiltix to build functionality that could be imported into Houdini or will that require similair amount of steps?

Does OpenGL still work with custom mtlx nodes if it worked in the original HDA consisting of low-level mtlx nodes?


Any tips or links around this topic would be more than welcome

Cheers, K!

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.

Thanks rafal! Clears up enough to follow through and test some assets. (bummer about GL hopefully future feature)

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.

rafal
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.

I found creating a subnet HDA first helps with setting the naming of the input output before saving as mtlx

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

As jsmack pointed out, I also found it easiest to create an hda first. Than using the vop2mtlx.py script. As far as I could tell I didn't need to change anything by hand this way. No extra shader nodes inlcuded, already had the nodedef stuff in it.
After that I followed step 4 and it seemed to work fine. Makes it probably easy to automate if needed.

*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?

Speed was good as far as I could tell from the tests I've done.
Similar speed to using an mtlxconstant in an parameter which I kinda hoped / expected.

Also good to see that the whole graph shows as a single prim in the scene graph. So it's definitely an option.

I couldn't manage to make it work in GL, even though the original hda works fine. Hopefully this is my fault. Loosing GL and also loosing the flexibility from an HDA makes me think the speed gain alone isn't worth the hassle.

Followup questions I'm still curious about:
- Anybody got custom or converted mtlx nodes that also work in GL? (Thought this wouldve been one of the strong points of mtlx, only half joking haha)
- Is this roundtrip with mtlx / hda / json still reliable for future hou versions and mtlx standards? Or better not to expect backwards compatibility yet?

I'm prob gonna just wait on bug: 133382, hopefully it's something thats fixable and reassess after. I'm pretty sure that will already solve most of my gripes.

Cheers!



ps extra info from sidefx team for anybody interested:

"As for the issue of recooking of asset (subnet) parameters, its related to the complexity of subnets having both parameters and children. While we were able to efficiently handle parameter changes to VOPs that have a corresponding USD shade primitive (eg, mtlx constant), we were hitting edge cases when trying to optimize the subnets (node graphs). There is currently bug 133382 filed for this issue.

One workaround is to use mtlx constant VOPs. Another is to use Edit Material Properties LOP to selectively edit values on shaders and materials (you can promote/loft the asset input to a material with a Parametr VOP). There is also primvar reader approach, where you affect the shader values using geomety poperty reader node.

Also, converting the asset to mtlx shader would work around the re-translation issue. The custom mtlx vop would have a corresponding USD shader prim, and therefore it would be possible to optimize the translation.

The dowside of building your own custom mtlx shader is that it can be a very cumbersome process."

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.

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.

Yeah it's strange cause normally it should be saved as .hdalc so you know it's a indie asset. But for some reason i managed to make an .hda (also tried that hda2mtlx.py script on an .hdalc and it complained. Thatswhy i thought it might be an temp fix or something)

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

Thats great to know! Makes it easier to put in some effort, knowing don't have to redo with next major releases.