Forums Solaris and Karma materialx surfaceshader mix node not importing

materialx surfaceshader mix node not importing

   464   1   0
User Avatar
jakethorn
Member
1 posts
Joined: Jan. 2024
Offline
 
I have a materialx file that mixes two open_pbr_surfaces:

<?xml version="1.0"?>
<materialx version="1.39">
  <open_pbr_surface name="surface1" type="surfaceshader">
    <input name="base_color" type="color3" value="0, 1, 0" />
  </open_pbr_surface>
  <open_pbr_surface name="surface2" type="surfaceshader">
    <input name="base_color" type="color3" value="0, 0.5, 1" />
  </open_pbr_surface>
  <mix name="out_surface" type="surfaceshader">
    <input name="fg" type="surfaceshader" nodename="surface1" />
    <input name="bg" type="surfaceshader" nodename="surface2" />
    <input name="mix" type="float" value="0.5" />
  </mix>
  <surfacematerial name="mixed_material" type="material">
    <input name="surfaceshader" type="surfaceshader" nodename="out_surface" />
  </surfacematerial>
</materialx>


When I try to load that materialx file using the reference node, I get the following warnings and the material doesn't work:
Shader not found at </MaterialX/Materials/mixed_material/NodeGraphs/surface1> for input "fg"
Shader not found at </MaterialX/Materials/mixed_material/NodeGraphs/surface2> for input "bg"

However, if I create my materialx material directly in Houdini, then I am able to mix surfaceshader types no problem.



Can anyone point out to me what I'm doing wrong? Thanks in advance!
Edited by jakethorn - Feb. 10, 2026 03:25:41

Attachments:
hou_material.png (81.6 KB)

User Avatar
rafal
Staff
1473 posts
Joined: July 2005
Offline
 
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.
  • Quick Links