Hi all, what is the preferred method for scaling/transforming 3D procedural patterns such as Mtlx Fractal3D? I can use Mtlx Transform Matrix but that's a bit crude from a UI/UX perspective. Is there maybe going to be a "Place3D" node to complement Mtlx Place2D?

Thanks

for simple scaling/translation, there's multiply and add nodes, however I agree that convenience transform operators are sorely missing.

SideFX have spoken about the willingness to build convenience HDAs on top of the core Mtlx nodes, but wanted to ensure Mtlx is robustly implemented before setting out on that journey.

Thank you gents

jsmack
for simple scaling/translation, there's multiply and add nodes, however I agree that convenience transform operators are sorely missing.

Don't know why simply multiplying position didn't occur to me, thank you!

jason_iversen
SideFX have spoken about the willingness to build convenience HDAs on top of the core Mtlx nodes, but wanted to ensure Mtlx is robustly implemented before setting out on that journey.

That's good to hear. I imagine SideFX has to stick to what's available in MaterialX so they don't break portability(?). I hope that doesn't tie their hands too much. Kind of got spoiled with those Maxon noises in Redshift...


And has anyone gotten Worleynoise3D to output much of anything?

jason_iversen
SideFX have spoken about the willingness to build convenience HDAs on top of the core Mtlx nodes, but wanted to ensure Mtlx is robustly implemented before setting out on that journey.

thought about this is pretty scary, I guess it already started with the fake ramp nodes
but I don't understand why would it be better to create hacky wrappers around limited system like MtlX rather than contributing to it's nodebase directly

MtlX is currently lacking a lot to be production ready, but my fear is that hacky bandaids are not gonna cut it
I hope MtlX will be an option for people who are ok with quite limited control and just want relatively simple sharable materials
but that Karma will have it's own powerful shading language and rich arsenal of nodes at least what VEX offers but hopefully beyond, since even VEX nodes don't make it easy to do some operations you'd expect from every renderer (not even modern) like robust Ray Type Switch or Camera Projection, etc...

If i plugin the matrix and change the 1,1,1 to other values nothing seems to change,

How do you propperly wire evrything to make it work ?

tamte
thought about this is pretty scary, I guess it already started with the fake ramp nodes
but I don't understand why would it be better to create hacky wrappers around limited system like MtlX rather than contributing to it's nodebase directly

MtlX is currently lacking a lot to be production ready, but my fear is that hacky bandaids are not gonna cut it
I hope MtlX will be an option for people who are ok with quite limited control and just want relatively simple sharable materials
but that Karma will have it's own powerful shading language and rich arsenal of nodes at least what VEX offers but hopefully beyond, since even VEX nodes don't make it easy to do some operations you'd expect from every renderer (not even modern) like robust Ray Type Switch or Camera Projection, etc...

On that note, now that Karma has a price tag, can we expect it to match the competition in terms of performance and shader arsenal?

I do like the performance gain of MaterialX vs. VEX. Or maybe it's due to implementation of the classic and principled shader.

Andy_23
I do like the performance gain of MaterialX vs. VEX.

Don't be fooled, MaterialX is not what makes the speed difference
MaterialX is not a shading language, it is just a description layer that tries to unify material description for all renderers and hence in this case a huge bottleneck of what types of nodes and workflows are available to use when one wants to stay truly compatible
Every renderer has to implement equivalent of each node
And the speed depends on the particular renderer
In Karma's case Karma CPU and Karma XPU (even CPU part) are different architectures, One Vex, one not and that's where the speed difference comes from whether you describe shaders through mtlx or not

tamte
Every renderer has to implement equivalent of each node

The compatibily will be broken if sidefx add new feature or node. Right?

jerry7
The compatibily will be broken if sidefx add new feature or node. Right?

If it's not reflected in the mtlx specs then yes

But it will be necessary to make Karma feature set grow on its own pace without being hindered by MaterialX

And then it's up to an user to either stick with pure MtlX definition or go beyond and use full potential of a particular renderer without the need to stay 100% compatible

Kma_hair is an example of a node that you can use, I believe even mix with mtlx nodes, but is will work only with Karma

Because to be honest I want 1 powerful renderer with flexibility and robust featureset rather than be able to build basic and very limited materials that work for multiple renderers

Portability of the source node network from Houdini to other platforms is not really going to be possible with convenience HDAs, but the resolved UsdShade network will contain only Mtlx nodes, and that might be importable into other editing platforms (or into Houdini). However, it might not look terribly pretty if those Houdini convenience HDAs are large and sprawling.

nothing against convenience HDAs if they had rich library of functions to work with that they would be robust and fully functional
but reading that those fake ramps have limit of 10 keys etc., while understandable because it's working with very limited system, it's not filling me with confidence of future proof solution, it more sounds like just to satisfy people trying Solaris and switching renderers on daily basis and also not scare anyone off by not having such nodes at all, all understandable reasons especially for renderer in Alpha

but it may be too early to even tell which way Karma will go and what kind of shading language will be available to us to even remotely compete with VEX or even OSL flexibility
but if MaterialX is not gonna be able to describe it it simply wouldnt be smart to force it as a frontend

regardless of all that my main point was that all parties would need to contribute to MaterialX as much as possible to make it as modern and descriptive to have a chance to become an industry standard for describing material networks

tamte

Andy_23
I do like the performance gain of MaterialX vs. VEX.

Don't be fooled, MaterialX is not what makes the speed difference

I noticed that tunning parameters directly in the materialx vop node has a more fast feedback than vex node.

tamte
Andy_23
I do like the performance gain of MaterialX vs. VEX.
Don't be fooled, MaterialX is not what makes the speed difference

I'm seeing vast differences in render time with Principled vs. MaterialX standard shaders. Which leads me to question the implementation and underlying code execution.

Currently, the MatX Shaders seem black boxed, hence my assumption of different implementation and faster shading execution.

Andy_23
I'm seeing vast differences in render time with Principled vs. MaterialX standard shaders. Which leads me to question the implementation and underlying code execution.

They're pretty different shaders. What is a 'vast' difference? The mtlx stuff takes some shortcuts in fresnel blending that are done correctly at the bsdf level in the principled shader. This could lead to less variance in mtlx by using an approximation.

jsmack
What is a 'vast' difference?

25 vs. 15 minutes in rendertime for "simple" diffuse/specular shading. I picked this up while debugging the Linux/Win Karma performance differences that since been fixed with the .435 build.

I'll run the tests again over the weekend.

Happy rendering

For photocraphic memory

I think the right idea is to ship higher level convivence mtlx nodes that are built out of standard mtlx nodes, not mtlx HDAs. That would keep things cross compatible.