rafal

In short, the issue is with the MaterialX file format plugin (usdMtlx lib) in the USD library.

Houdini/Solaris supports the MaterialX standard specification, but it does not directly rely on the .mtlx (XML) data storage or the implementation of code generation. Because Solaris is heavily USD-centric, it leverages USD's support for loading .mtlx documents into USD stage, and then processes them as any other USD Shade Material primitive. And also, Karma does not use code-gen from the mtlx library; it directly implements the shaders itself, based on the spec (and OSL/GLSL as an example).

So when you reference the .mltl file, it's the USD's mtlx plugin that reads it. But that plugin is flaky and very restrictive. It still seems to strictly insist on an old layout of the .mtlx elements, where all the shaders that feed into the final surface shader need to be inside a node graph (sub-graph). Eg, like in the example: https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/resources/Materials/Examples/StandardSurface/standard_surface_brass_tiled.mtlx [github.com]

These days pattern shaders can live directly inside the <material> element as siblings of the final surface shader, but USD plugin did not get updated for that yet. There is ongoing work on it so hopefully it will be able to handle your .mtlx file layout soon too.

MaterialX does not allow run-time processing of strings. VEX does, so it should work for Karma. But Karma and Houdini Vulcan don't support OSL, so if you try rendering with them, it may not work. Though it should not crash.

But since you are using Redshift, you can try posting that question there (Redshift forum) as well. It maybe Redshift that carashes.

The other thread: https://www.sidefx.com/forum/topic/101716/?page=1#post-449341 [www.sidefx.com]