Arnold USD/Solaris MaterialX vs Arnold Material Builder image color-space setting not respected and uneven material response, causing maketx encoding and chromaticity differences

**Describe the bug**

Arnold USD / Solaris appears to interpret textures and material networks differently depending on whether the material is authored through standard MaterialX/USD image nodes or through an Arnold Material Builder subnetwork.

Across multiple scenes, I am seeing large visual mismatches between materials that are intended to represent the same surface response. The differences include:

- different texture interpretation

- different chromaticity / hue response

- different roughness/specular response

- different bump/normal/displacement response

- different contrast/detail response

- different perceived albedo/luminance response

- different overall material energy/appearance

The issue is especially visible on cloth/fabric-style materials using multiple texture maps. Depending on whether the material is authored through the Arnold Material Builder path or through a standard MaterialX/OpenPBR-style USD material network, Arnold can produce noticeably different results even when the same source texture set is used.

A key part of the issue seems to be texture color-space / encoding handling. In the standard MaterialX/USD material workflow, using regular MaterialX image nodes, the exposed image color-space control does not appear to reliably affect Arnold’s texture interpretation in Solaris. Changing the MaterialX image color-space setting does not produce the expected change in the Arnold render.

However, in the Arnold Material Builder subnetwork workflow, changing the generated `.tx` / `maketx` encoding does affect the render as expected.

This makes it difficult to build predictable USD/Solaris material workflows for Arnold, because the same source texture set can behave differently depending on the material authoring path.

**To Reproduce**

Steps to reproduce the behavior:

1. In Houdini Solaris, create or import geometry using a texture-based material.

2. Build one version of the material through an Arnold Material Builder subnetwork.

3. Build another version of the material using a standard MaterialX/OpenPBR-style USD material network.

4. Use the same or equivalent texture set for both materials:

- base color / albedo

- roughness

- metallic

- specular / IOR / anisotropy maps, where applicable

- normal map

- displacement map, where applicable

- additional masks, where applicable

5. Assign each material version to the same geometry.

6. Render or preview with Arnold USD / Arnold Hydra delegate in Solaris.

7. Switch between the Arnold Material Builder version and the MaterialX/OpenPBR USD material version.

8. Observe that the rendered material result changes substantially, even though the intended texture set and surface response are meant to match.

Additional texture color-space / `.tx` test:

1. Use standard MaterialX image nodes in a Solaris/USD material network.

2. Change the exposed image color-space setting on the MaterialX image nodes.

3. Render or preview with Arnold USD.

4. Observe that the MaterialX image color-space setting does not appear to reliably affect Arnold’s texture interpretation.

5. Build the equivalent texture setup through an Arnold Material Builder subnetwork.

6. Generate `.tx` files with different intended `maketx` encodings.

7. Switch between the generated `.tx` variants.

8. Observe that changing the `.tx` / `maketx` encoding in the Arnold Material Builder workflow affects the Arnold render as expected.

The mismatch is visible in Solaris viewport/IPR and across multiple test scenes.

**Expected behavior**

When the same texture set and equivalent material parameters are used, Arnold should produce a broadly comparable material appearance between an Arnold Material Builder network and a standard MaterialX/OpenPBR-style USD material network.

Some differences are expected because Arnold-native shaders and MaterialX/OpenPBR shaders are not identical, but the current differences appear large enough to make the material workflows difficult to match or transfer predictably.

The MaterialX image color-space setting should either:

1. be respected by Arnold in the Solaris/MaterialX workflow, or

2. clearly indicate that it is unsupported / ignored / handled differently.

If the mismatch is expected due to unsupported MaterialX/OpenPBR parameters, different default values, different normal/displacement handling, different texture color-space handling, or renderer-specific shader behavior, it would be useful to know which parts of the networks are not equivalent.

**Screenshots**

Attached screenshots show large material differences between the Arnold Material Builder workflow and the standard MaterialX/OpenPBR-style USD material workflow. The comparisons include material network setups, rendered results, displacement/normal/detail differences, chromaticity/hue shifts, and generated `.tx` texture variants with different intended encodings/naming conventions.

The screenshots also show encoding differences between the Arnold Material Builder subnet image workflow and the standard MaterialX image workflow when using automated `maketx`.

Encoding differences between ArnoldMaterialBuilder subnet image and mtlx image with the automated maketx naming differences.

The screenshots show large differences in material appearance even when the intended texture set and final surface are meant to be equivalent.

**Used Software Versions**

- Arnold / HtoA: `6.5.1.1`

- Arnold USD / Hydra Delegate: `included with HtoA 6.5.1.1`

- Houdini: `21.0.671`

- USD: `Houdini-bundled USD version`

- Compiler: `Not applicable — using prebuilt Houdini/HtoA packages`

- OS: `macOS 26.4.1`

- Hardware: `Apple Silicon / M2`

- Any 3rd-party app: `SideFX Houdini Solaris`

**Additional context**

This appears to be a material/shader and texture interpretation issue rather than only a lighting or display color-management issue. I am seeing large mismatches between Arnold Material Builder subnetworks and standard MaterialX/OpenPBR-style USD material networks across multiple scenes.

Because the issue persists across both ACEScg/ACES 2.0 and Linear Rec.2020/AgX setups, it does not appear to be caused by one specific OCIO config, rendering space, or display transform.

Possible areas to investigate:

- Arnold Material Builder vs MaterialX/OpenPBR shader translation

- standard MaterialX image node handling in Arnold USD/Solaris

- MaterialX image color-space setting interpretation

- texture color-space handling

- automated `maketx` behavior

- OCIO file-rule interaction with texture conversion

- default parameter differences between Arnold-native and MaterialX/OpenPBR shaders

- normal map interpretation

- bump/displacement interpretation

- roughness/specular response

- OpenPBR parameter support in Arnold USD/Solaris

- USD material translation through Solaris

A key detail is that this behaves differently depending on the material authoring path.

In the standard MaterialX/USD material workflow, using regular MaterialX image nodes, the exposed image color-space control does not appear to reliably affect Arnold’s texture interpretation in Solaris. Changing the MaterialX image color-space setting does not produce the expected change in the Arnold render.

However, in the Arnold Material Builder subnetwork workflow, changing the generated `.tx` / `maketx` encoding does affect the render as expected.

This is why the OCIO config and file-rule behavior matter here: with standard MaterialX image nodes, I cannot reliably control texture interpretation per image node from inside Solaris, so correct texture interpretation depends heavily on OCIO file rules, naming conventions, and manually generated `.tx` variants.

In practice, this means the same source texture set can behave differently depending on whether it is used through:

- standard MaterialX image nodes in a USD material network

- Arnold Material Builder texture/shader nodes with explicitly generated `.tx` files

I also tested explicit texture encoding / naming variants to make sure this was not only caused by one ambiguous texture conversion.

For example, I generated `.tx` files with different intended encodings/naming conventions, including variants such as:

- `_raw`

- `_Raw_ACEScg`

- original source texture names

This was done to separate color textures from non-color/data textures and to test whether Arnold/MaterialX was interpreting the `.tx` files differently depending on the generated texture variant.

The fact that I had to rely on explicit naming and OCIO/file-rule driven conversion highlights the workflow problem: the MaterialX image node exposes a color-space control in Houdini/Solaris, but in my tests that setting does not appear to reliably drive Arnold’s texture interpretation or automated `maketx` behavior. As a result, texture interpretation has to be managed indirectly through OCIO config rules, file naming, and manually generated `.tx` variants.

I also included examples showing chromaticity / hue differences between the two material paths. In these tests, switching between the standard MaterialX/USD material path and the Arnold Material Builder path produces a visible color/chromaticity shift in the rendered result. The floor/background and cloth material response change noticeably, even though the scene, camera, display/view transform, and intended material setup are the same.

This appears likely related to texture color-space / `.tx` encoding interpretation, because changing the generated `.tx` / `maketx` encoding in the Arnold Material Builder workflow affects the render, while the MaterialX image color-space setting in the standard USD material workflow does not appear to drive Arnold’s texture interpretation reliably.

This makes the workflow fragile, especially for any mixed texture sets containing both color textures and non-color/data textures.

Because the MaterialX image color-space setting does not appear to drive Arnold’s texture interpretation here, it becomes difficult to guarantee that each texture is encoded and interpreted correctly when moving between Arnold Material Builder materials and MaterialX/OpenPBR-style USD material networks.

I tested multiple material setups and multiple scenes, and the mismatch remains visible. The issue does not appear to be only one broken texture or one isolated material network.

At the moment I am reporting this based on Solaris viewport/IPR comparisons and screenshots. I can try to provide a reduced reproduction scene later if required.

No repository file, test, or code entry point is identified. Reproduce the mismatch in Houdini Solaris with Arnold USD/Hydra Delegate using the two material-authoring paths and the reported MaterialX color-space and .tx/maketx variations; done means isolating a specific translation or texture-interpretation failure, or documenting which behavior is unsupported.

Written by the indexing model from the issue text.