You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
As discussed in the following issues, MaterialX colorspace handling is currently lacking:
#1523
#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-L471
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.The text was updated successfully, but these errors were encountered: