Broader MaterialX node support: ND_image_float, normalmap_float, tiledimage

[viktor-hallen]

Hi,

Thanks for the OpenPBR/MaterialX support in the glTF fileformat plugin. I've been testing 2026.07 for USD + MaterialX/OpenPBR to glTF/GLB and the conversion looks really promising.

This is not a bug report per se, just curious about a few of the currently supported node patterns and whether the restrictions are intentional, technical limitations, or just variants that haven't been implemented yet.

From layerReadMaterial.cpp the texture usage path seems to roughly be ND_texcoord_vector2, then optionally ND_place2d_vector2, into ND_image_vector4 / ND_image_color3 / ND_image_vector3 / ND_UsdUVTexture_23, with some optional node supports before it reaches OpenPBR.

For float inputs it looks like it goes through ND_image_vector4 into ND_separate4_vector4 before landing on the OpenPBR float input.

Would it make sense to also support the simpler ND_image_float feeding directly into something like OpenPBR.specular_roughness, rather than requiring the vector4 to separate4 route? I get that the latter matters for packed textures, but image_float seems like a pretty natural fit for standalone scalar maps.

Regarding normalmaps: Houdini and the MaterialX Graph editor both author the normalmap node as ND_normalmap_float. UsdMtlx seems to do the same, translating normalmaps to ND_normalmap_float by default. But the reader currently only expects ND_normalmap.
Any chance of supporting _float as well?

And then there's ND_tiledimage_*. Authored graphs commonly do ND_tiledimage_color3 straight into OpenPBR.base_color instead of place2d plus image. Would it be feasible to support ND_tiledimage_* by mapping its tiling and offset params into that same internal texture transform representation?

Curious how these three (ND_image_float, ND_normalmap_float, ND_tiledimage_*) would fit into everything!

Thanks!

[fhechtAdobe]

Hi @viktor-hallen. Sorry about not getting back to you sooner. This was brought to my attention when you posted this, but then fell through the cracks. Apologies.

Regarding your general questions about how we arrived at the MaterialX graphs that the file format plugins currently generate. They are very intentional. They are derived to be a minimal set of nodes and topologies that we support. This is partially driven by the needs of the assets that we usually encounter and the capabilities that other formats commonly have for their materials models, especially GLTF.

Our in-house rendering system does not support general MaterialX, but it does support the same subset. The goal is to have valid MaterialX that a general MaterialX capable renderer can handle and render correctly (*), but not expand into full general MaterialX, because the incurs significant compilation overhead. Hence the restricted subset.

We started originally with ND_image_vector4, ND_image_color3 and ND_image_vector3 for float, color and vector3 (normal map) inputs. We went with ND_image_vector4 exactly because we need to support being able to select a channel from a general RGBA texture. Many formats, especially GLTF extension, prescribe a specific channel packing and hence we needed this from the get go. Also, before we implemented MaterialX support we supported UsdPreviewSurface and that has built in channel selection as well.

Eventually we discovered that there is a straight forward port of the UsdUVTexture texture node that we've been using with UsdPreviewSurface in the form of the ND_UsdUVTexture_23 and we pivoted to using that. We can still parse the old nodes, but we only generate MaterialX networks with the ND_UsdUVTexture_23 node.

Regarding ND_normalmap vs ND_normalmap_float. When we started the MaterialX support there was only ND_normalmap and now that has been evolved into ND_normalmap_float. We should be updating it to support the newer node and only generate the new node. I don't know when we get the there. Patches/PRs to add that support are most welcome.

Likewise, if support for parsing ND_image_float would be helpful, then adding that is not a conceptual issue. We just haven't gotten to it and it is not a priority for us. So if you care about that, sending us a PR would be the easiest way to get that going.

The story is similar for ND_tiledimage_*. We chose the combo of an image reader node with an explicit and optional ND_place2d_vector2 node, which is more analogous to how the nodes for UsdPreviewSurface work. That is what our in-house system already supports. Adding support for the combined ND_tiledimage_* would encode the same basic information, just differently. So adding support should be possible. And again I would to encourage you or anyone interested to send us a patch/PR for that support. We probably won't generate those nodes, but adding support for parsing them should be technically not too complicated.

I hope this useful information and gives some insight in how we arrived at what we have today. Please reach out if would like to contribute. We're more than happy to take patches/PRs.

Thanks and cheers,
Florian

(*) The only exception to that, that I'm aware of is how ambient occlusion is wired in. OpenPBR doesn't have an ambient occlusion input. It's currently blending it with the albedo/base_color, but with a weight of 0. So a normal MaterialX renderer will just use albedo, but topology wise the AO feeds into the network and renderer can detect that an then use that input separately, if their shading algorithm can use it.