Hey,

I was taking it as given that MaterialX would work with prman, and was excited to be able to use the same shaders for karma and prman.

Sort of works with a simple Mtlx Standard Surface, but wiring any precursor mtlx nodes in has prman simply stop rendering for me. I"m guessing it's actually making a USD preview shader here after all.

Docs are still a little sparse - am I right to conclude it won't work for now? Is it on the roadmap?

Cheers,
Rangi.
H19.0.383
RIS 24.2

I'm interested in the portability aspect of MaterialX as well. I saw this little blurb in the Renderman 24.2 release notes:

hdPrman: Consume MaterialX through hdPrman. Pattern networks are compiled to OSL. BxDFs are transcoded to PxrSurface.

I haven't seen anything in the actual Renderman docs about it. The Lama stuff is not really relevant to this as far as I understand.

I did a little test to see how Renderman would handle the Solaris MtlX Standard Surface implementation.
First Karma:


And Renderman:


The results look very different obviously. The subsurface material is much brighter on the Renderman side, the glass is not refracting anything, the blue material is missing the sheen component, and the anisotropic specular looks wrong on the metal. And like you mentioned, anything plugged into the Standard Surface node will cause Renderman to fail (and Storm as well). BXDFs instead of Standard Surface also do not work.

It still feels very Wild West at the moment, I would expect this stuff to get fleshed out more in the coming months.

You've got to be careful about what you're comparing there, too... If you author your matx shaders in VOPs, we automatically create a corresponding (approximate) USD Preview Surface shader, so RenderMan may just be rendering the USD Preview Surface. If you really want to test this out, you need to destroy/deactivate teh USD Preview Surface shader, or load a MatX shader directly from a mtlx file and attach it directly to the geometry. Or maybe that's what you've done already... I really don't know much about prman support for matx.

Thanks mtucker, that was my initial thought as well but I don't think that's the case here. Deactivating the auto-generated preview materials doesn't change anything in the render, and there is clearly subsurface scattering happening on the leftmost teapot, which USD Preview Surface doesn't support.

RenderMan supports generating and then using an osl shader from a mtlx file. However, what I'm seeing when the RenderMan hydra delegate receives a network of mtlx nodes that have been set up in Solaris is that those individual nodes resolve to glsl shaders. RenderMan doesn't know what to do with those, and our code generation process doesn't properly kick in. I'm wondering if there's maybe a way to bake out a mtlx definition file from a Solaris mtlx network? Or would there be a way to influence whether these nodes resolve to glsl vs osl?

I don't know much about MaterialX, so I don't know how you instruct it to generate OSL instead of GLSL code... But unlike Storm, Karma doesn't actually convert the HdMaterialNetwork back into MaterialX (we don't use HdMtlxCreateMtlxDocumentFromHdNetwork). Assuming that hdPrman does use that function, maybe there is something in there that locks the resulting mtlx network into generating GLSL code?

Yeah, we use HdMtlxCreateMtlxDocumentFromHdNetwork. I'm still looking into it more, but I've noticed when coming from a mtlx file the HdNetwork has an extra NodeGraph encapsulating the network that is input to the terminal node. Whereas the HdNetwork that we get from a network of Solaris mtlx nodes doesn't have that. So I'm feeling like extra NodeGraph is somehow an assumption/requirement for that function to work properly; it throws an exception while trying to process the network.

-Katrin

I also have noticed that often Storm requires an extra NodeGraph for it to render correctly. In the attached file, I had to put the tiled image shaders inside a VOP Subnet to get the required NodeGraph.

However, MaterialX itself does not appear to require pattern shaders to be inside a NodeGraph. Eg, if I pull the tiled image shaders out of the VOP Subnet, wire them to the terminal node, then right-click on the terminal node (ND_USDPreviewSurface VOP) > Save... > MaterialX, then the saved file (attached) passes the MaterialX document validation call.

So I'm not sure where the NodeGraph requirement comes from, but it seems to be an incorrect assumption to require the NodeGraph.

We were able to come up with a fix for this extra NodeGraph requirement in hdPrman, so it'll be working in hdPrman in an upcoming RenderMan for Houdini build. Storm may have to wait until USD/hydra can be updated.