adobe / adobe/USD-Fileformat-plugins

Broader MaterialX node support: ND_image_float, normalmap_float, tiledimage

Open
#80 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
396
Forks
42
PR merge metrics
No merged PRs in 30d

Description

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`](https://github.com/adobe/USD-Fileformat-plugins/blob/main/utils/src/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!

Contributor guide

Open the contributing guide

Research direction

Start in utils/src/layerReadMaterial.cpp and trace the existing texture and normalmap node handling described in the issue. Compare how ND_image_float, ND_normalmap_float, and ND_tiledimage_* would fit those paths; done means the three authored node patterns are supported in USD/MaterialX-to-glTF conversion.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.