Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Broader MaterialX node support: ND_image_float, normalmap_float, tiledimage

Abierto
  • ¿Algo no está bien?
#80 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp
Área
tooling

Línea de trabajo

Comienza en utils/src/layerReadMaterial.cpp y sigue el manejo existente de nodos de texture y normalmap descrito en el issue. Compara cómo encajarían ND_image_float, ND_normalmap_float y ND_tiledimage_* en esas rutas; el trabajo está terminado cuando los tres patrones de nodos definidos sean compatibles en la conversión de USD/MaterialX-to-glTF.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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!

Lenguaje dominante
C++
Estrellas
398
Forks
42
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de adobe/USD-Fileformat-plugins

Todos los issues de adobe/USD-Fileformat-plugins

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.