Having experimented with MaterialX a bit, it seems very limited. No radial ramp, facing ratio, wire shader, slope/curve/edges, and no real choices in noises among other things.

My question becomes, since these cannot be used with vex nodes, what is the idea going forward with MaterialX? The official documents warn against writing custom c++ shaders and suggests anything built should be made with native MaterialX nodes. That seems not only extremely difficult, (if not impossible?), but also a huge time waster if every studio is to build their own basic nodes.

As it seems MaterialX will be the standard in Houdini Karma going forward, this would, at least for us, have an impact if we choose to use karma at all, and would be nice to know what the roadmap is.

Valid concerns, but I think that SideFX's participation with MaterialX (and Houdini's customer base) has already made a difference on the MaterialX feature set - for example, SideFX fleshed out the Worley noise implementation. I'm hoping that SideFX will continue to working through the MaterialX working group to elevate and contribute to the specification.

I would continue to state your desires here and let SideFX work their magic.

AndreasWeidman
As it seems MaterialX will be the standard in Houdini Karma going forward, this would, at least for us, have an impact if we choose to use karma at all, and would be nice to know what the roadmap is.

Minor quibble: SideFX say Karma CPU will continue to support VEX along with Mtlx for the foreseeable future. Mtlx is only an exclusive path for XPU.

jason_iversen
Minor quibble: SideFX say Karma CPU will continue to support VEX along with Mtlx for the foreseeable future. Mtlx is only an exclusive path for XPU.

True, I should probably have stated that we are Redshift based, so GPU/XPU is where our interests are. One could argue that the idea of MaterialX being universal, as in being able to be used with Karma cpu/xpu, arnold, substance, is what makes it attractive, and I assume any vex nodes would not translate as universal.

I hope you are correct in that SideFx may help change things, but seeing as MaterialX has been around for a while now, I’m hesitant that the specification would change in the next decade, unless being combined with perhaps USD shade or something. Of course, this is mainly my disappointment talking, as I had so much hope for Karma XPU.

I agree that the current implementation is a bit annoying since MaterialX only gives you the most basic of building blocks. I asked on the MatX GitHub about integrating SideFX's ramps and they said that's coming in the next release. In the meantime, I messed around with making my own set of more advanced ramps and noises using basic MatX nodes. Worked out ok, although the ramps are not portable to other MatX apps since they use SideFX's Houdini-only ramps. The noise one I made is portable though. I tried bringing it into Clarisse 5.5 and it worked fine.

Ramp demo here: https://twitter.com/brianhanke/status/1471123861127237639 [twitter.com]

BrianHanke
I agree that the current implementation is a bit annoying since MaterialX only gives you the most basic of building blocks. I asked on the MatX GitHub about integrating SideFX's ramps and they said that's coming in the next release. In the meantime, I messed around with making my own set of more advanced ramps and noises using basic MatX nodes. Worked out ok, although the ramps are not portable to other MatX apps since they use SideFX's Houdini-only ramps. The noise one I made is portable though. I tried bringing it into Clarisse 5.5 and it worked fine.

Ramp demo here: https://twitter.com/brianhanke/status/1471123861127237639 [twitter.com]

Cool experiments, Brian, and good that the sideFX ramps will be official in the future.
I assume you are basically using different MaterialX nodes within a subnet? While great for defining useful presets and combining things, I have yet been able to create something useful. I’ve tried creating things like alligator pattern and such by manipulating the UV/Place2D scale/rotation etc, but in essense, without using some kind of image, it seems pretty impossible. There seems to be no way to generate 2D shapes.

I could be wrong, and I don’t want to sound to negative, but it feels like the materialX approach is pretty much to use textures for every channel and create nothing procedural. What’s worse is that even with such a limited node selection, we still can’t view anything but plain color/textures in the viewport. It feels like we are going backwards. The dream of having blender Eevee or unreal Lumens performance in the viewport in Houdini seems further away that ever tbh.

AndreasWeidman
I assume you are basically using different MaterialX nodes within a subnet? While great for defining useful presets and combining things, I have yet been able to create something useful. I’ve tried creating things like alligator pattern and such by manipulating the UV/Place2D scale/rotation etc, but in essense, without using some kind of image, it seems pretty impossible. There seems to be no way to generate 2D shapes.

You can create nearly any possible shape with min, max, add, mult, div, and trig, pow, exp/log functions.

MaterialX can ONLY define nodes using subnets containing these basic building block nodes. There's no reason you couldn't have a library of nodedefs for higher level convenience nodes. The AMD material library contains some of these.

One of materialX's render targets is GLSL, so I would hope that viewport to render parity is closer than ever before.

jsmack

AndreasWeidman
I assume you are basically using different MaterialX nodes within a subnet? While great for defining useful presets and combining things, I have yet been able to create something useful. I’ve tried creating things like alligator pattern and such by manipulating the UV/Place2D scale/rotation etc, but in essense, without using some kind of image, it seems pretty impossible. There seems to be no way to generate 2D shapes.

You can create nearly any possible shape with min, max, add, mult, div, and trig, pow, exp/log functions.

MaterialX can ONLY define nodes using subnets containing these basic building block nodes. There's no reason you couldn't have a library of nodedefs for higher level convenience nodes. The AMD material library contains some of these.

One of materialX's render targets is GLSL, so I would hope that viewport to render parity is closer than ever before.

That is good news, I hope you’re right.
Perhaps it would make sense to have a Houdini ”open source” section so somehow share these nodedefs as a community. I think we all pretty much want the same kinds of noises, ramps and other nodes. While I’m decent with code, creating shapes by doing complex math with nodes makes me want to do the dishes and clean the garage. Could be wrong, but I imagine it being extremly slow and frustrating

AndreasWeidman
While I’m decent with code, creating shapes by doing complex math with nodes makes me want to do the dishes and clean the garage.

Ha, same. Getting the ramp to go diagonal was a big stretch for my very limited math abilities. I hope that SideFX/others will package up all this stuff in the future. Right now it definitely is a step back since so many convenience features are missing.

AndreasWeidman
The dream of having blender Eevee or unreal Lumens performance in the viewport in Houdini seems further away that ever tbh.

Yeah, I still live in this Matrix, too. Yet, given the amount of bugs we experience with viewport switching between a stage and SOPs context, my hopes for a carefree viewport experience is further away than ever.

There are days I dread working in Houdini, particularly when doing UVs or switching back and forth between SOPs and a Karma stage. The anxiety for a crash is ever present.

jsmack
One of materialX's render targets is GLSL, so I would hope that viewport to render parity is closer than ever before.

That'd be really nice. Keep hope alive I guess.

AndreasWeidman
The dream of having blender Eevee or unreal Lumens performance in the viewport in Houdini seems further away that ever tbh.

One thing to note is, that SideFX recently looked to hire somebody with Vulkan knowledge. The job offer was quite clear that this person was meant to bring the current OpenGL viewport to Vulkan. We have already seen them adding DoF and Bloom to the Viewport. Having a more modern backend would hopefully increase the quality and speed.

I'll bring this up whenever I see a Karma / mtlx features discussion....

I'll be very sad if we lose the ability that VEX has to arbitrarily sample any geometry file or volume file, but it looks like most renderers are ready to give that up.

Perhaps if I'm looking for ultimate render flexibility I'll have to get used to using the Unreal Engine from now on...