In a glTF MaterialX shading network, this affects normal maps, occlusion-roughness-metalness maps, and other textures containing multiple non-color data channels.
I'd propose to set the sourceColorSpace of images used in MaterialX shading networks to 'raw', to allow for easier workarounds. This includes explicit transformations inside the nodegraph, as well as baking of colorspaces into textures.
As discussed in the following issues, MaterialX colorspace handling is currently lacking: https://github.com/PixarAnimationStudios/USD/issues/1523 https://github.com/PixarAnimationStudios/USD/issues/1632
I'm working around this in my glTF to USD converter by performing the conversions explicitly using MaterialX math nodes.
One problem that I've encountered with this approach is, that MaterialX
<image>
nodes do not return raw values. In fact, the sRGB detection logic described in the UsdPreviewSurface spec with the default mode 'auto' is used. This means that all 8-bit RGB and RGBA textures are implicitly, and often incorrectly sRGB-decoded: https://github.com/PixarAnimationStudios/USD/blob/857ffda41f4f1553fe1019ac7c7b4f08c233a7bb/pxr/imaging/plugin/hioOiio/oiioImage.cpp#L470-L471In a glTF MaterialX shading network, this affects normal maps, occlusion-roughness-metalness maps, and other textures containing multiple non-color data channels.
I'd propose to set the
sourceColorSpace
of images used in MaterialX shading networks to 'raw', to allow for easier workarounds. This includes explicit transformations inside the nodegraph, as well as baking of colorspaces into textures.