Arnold USD/Solaris integration feedback: node design, stale IPR, material UX, and documentation

**Describe the issue**

I am grouping this as broader HtoA/Solaris integration feedback rather than as one isolated rendering bug. I can split specific items into separate issues if that is more useful.

Arnold itself is a strong renderer, but the current Houdini/Solaris integration often feels harder to use than it needs to be. Several workflows feel like they still carry over older Houdini/ROP-era HDA/OTL patterns instead of feeling like first-class, modern Solaris-native workflows.

The result is a steep starting curve. In practice, using Arnold in Solaris often means searching for the right node, testing which controls actually work, restarting renders to clear stale IPR/cache states, and trying to infer the intended workflow from documentation that does not always match the current Solaris experience.

The main areas where I am running into friction are:

- node design / HDA / OTL structure feeling carried over from older ROP-style workflows
- atmosphere/fog setup feeling indirect instead of having a clear Solaris-native node/workflow
- atmosphere/fog sometimes appearing cached/stale in IPR and requiring a full renderer restart
- texture/image/shader changes sometimes appearing stale and requiring a renderer restart
- Arnold light filters not being exposed as clearly as expected through Solaris-style nodes/HDAs
- Arnold dome light default/auto behavior producing unwanted results, especially with camera visibility enabled/set to `1`
- Arnold Material Builder subnetworks feeling cumbersome compared to native Solaris material workflows
- material input/output visibility inside Arnold Material Builder requiring too much dropdown/clicking friction
- duplicate or overlapping native MaterialX and Arnold-specific MaterialX-style nodes inside Arnold USD material subnetworks
- unclear `noice` denoising workflow inside Houdini/Solaris
- Solaris-specific documentation feeling less precise and less current than Arnold documentation for other DCC integrations

These are only some of the issues I have faced and the ones that came to mind while writing this. Some of them have taken days of searching, testing, debugging, and finding workarounds.

**Examples**

**Atmosphere / fog workflow**

Setting up Arnold atmosphere/fog in Solaris feels more indirect than expected. In my testing, atmosphere/fog could sometimes appear cached or stale in IPR, requiring a full renderer restart before changes updated correctly, especially after disabling atmosphere/fog.

It would be useful if atmosphere/fog had a clearer dedicated Solaris-style node/workflow, or if the recommended workflow were documented more explicitly.

**Texture/image/shader update behavior**

In some cases, changing a texture/image path, changing the texture used by a material, or modifying shader settings does not update reliably in Solaris/IPR. The previous texture or shader result can appear cached or stale, and a full renderer restart may be required before the new state is reflected correctly.

This creates uncertainty during lookdev, because it is not always clear whether the render reflects the current material/shader settings or stale renderer/IPR state.

**Light filters**

Arnold light filter workflows would be easier if Arnold light filter HDAs were exposed more directly and discoverably inside the light filter workflow.

Currently, the workflow feels less obvious than expected and less consistent with how Solaris users expect renderer-specific light/filter nodes to be exposed.

**Dome light default behavior**

The Arnold dome light workflow in Solaris can produce confusing results with its default/automatic settings. When a dome light is created, the initial `auto` behavior/settings can produce unwanted results, especially when camera visibility is enabled/set to `1`. In my case, this required a manual switch to Lat-long.

It would be useful if the overall light behavior and settings were clearer and better documented, especially the relationship between controls, filters, and contribution.

**Arnold Material Builder**

The native Arnold Material Builder subnetwork works, but the UX feels cumbersome. To see or manage material inputs/outputs, I have to click through dropdowns and manually select what should be visible.

This adds friction when building materials and feels unnecessarily hidden compared to more modern Solaris-native material workflows.

Compared to Karma and RenderMan Solaris workflows, the Arnold Material Builder feels more like a nested shader network than a clean Solaris-native material authoring experience.

**Duplicate / overlapping MaterialX and Arnold nodes**

The Arnold USD material subnetwork appears to contain duplicate or overlapping native MaterialX and Arnold-specific MaterialX-style nodes.

For example, there can be multiple multiply-style nodes available, and it is not clear which one is intended for a Solaris/Arnold USD workflow.

As a user, this creates uncertainty around whether to use the native MaterialX node, the Arnold-specific variant, or another similarly named node. This becomes especially confusing when trying to build portable MaterialX/OpenPBR-style materials while still rendering through Arnold.

It would be useful if the recommended node choice were clearer, or if the UI/documentation explained when to use native MaterialX nodes versus Arnold-specific nodes inside Arnold USD material networks. Even now, I am not certain which one to use. In practice, I end up choosing based on which one gives the closest expected material response, rather than knowing which node is technically correct.

**Denoising / `noice` workflow**

I already submitted a separate issue about `husk`-rendered EXRs not being denoise-able with `noice` from the command line due to EXR metadata/product-type differences compared to `kick` output.

In the broader Solaris integration context, the main issue is discoverability. The intended workflow for using Arnold `noice` denoising inside Houdini/Solaris is not clear enough. I ended up building my own terminal/scripts-based workflow for mass folder denoising with `noice`, but this may be problematic for regular users. Even in my case, I would have welcomed a clearer explanation of how to use `noice` from the UI at the start.

My preferred workflow is still to run `noice` as a post-process on already-rendered EXRs. It would be useful if the UI and documentation made the supported Solaris/Arnold denoising paths clearer.

**Documentation**

The documentation for HtoA/Solaris workflows could be clearer, more current, and more precise. In several areas, it is difficult to understand the intended workflow for Arnold-specific features, especially around:

- atmosphere/fog
- lighting overall
- Arnold Material Builder usage
- native MaterialX nodes vs Arnold-specific MaterialX-style nodes
- texture/image/shader update behavior in Solaris/IPR
- `noice` denoising workflow in Solaris
- ROP settings vs Solaris delegate settings
- what is considered legacy workflow vs recommended workflow

Compared to Arnold documentation and workflows for other DCC integrations which I use as a fallback, the Solaris documentation feels less precise and harder to map to the actual Houdini node workflow. This creates a steep learning curve because the user often has to search through older documentation or documentation for other DCCs, test node behavior manually, debug stale states, and infer the intended workflow from trial and error.

**Expected behavior**

HtoA’s Solaris integration should feel like a modern Solaris-native renderer workflow.

Ideally:

- atmosphere/fog should have a clear dedicated Solaris-style node or documented workflow
- atmosphere/fog changes should update reliably in IPR without requiring full render restarts
- texture/image/shader changes should update reliably in Solaris/IPR without requiring a full renderer restart
- stale IPR/cache states should be clearly invalidated when relevant settings change
- Arnold light filters should be discoverable and easy to create from the light filter workflow
- dome light default/auto behavior should be predictable and clearly documented
- Arnold Material Builder should expose material inputs/outputs more directly and with less dropdown friction
- duplicate or overlapping native MaterialX and Arnold-specific nodes should be clearly distinguished
- `noice` denoising should have a clearer Houdini/Solaris workflow, including UI usage if supported
- renderer-specific Solaris nodes should feel consistent with modern Solaris node design whenever possible
- documentation should distinguish clearly between legacy Houdini/ROP workflows and current Solaris/USD workflows

Karma and RenderMan are useful references here. Both feel more aligned with modern Solaris node design and renderer integration patterns. HtoA would benefit from a similar level of Solaris-native node/workflow polish.

**Actual behavior**

Many HtoA Solaris workflows feel like older ROP-era HDAs/OTLs carried forward into Solaris rather than redesigned around Solaris-native node workflows.

The result is more clicking, more hidden state, more uncertainty around what node/workflow is intended, and more cases where users have to rely on trial and error rather than documentation or clear node design.

There are also cases where changes appear stale in Solaris/IPR and require a full renderer restart. This makes lookdev less predictable, because it is not always clear whether Arnold is showing the current authored state or cached/stale renderer/IPR state.

The Arnold USD material subnetwork can expose duplicate or overlapping native MaterialX and Arnold-specific MaterialX-style nodes. For example, multiply-style nodes can appear in more than one form, and it is not obvious which one should be used.

This creates a steep starting curve when using Arnold in Solaris. Instead of feeling like a modern, well-integrated renderer workflow, the experience often becomes:

- hunting for the correct node
- searching through documentation that does not always match the Solaris workflow precisely
- testing whether older ROP-era concepts still apply
- debugging stale viewport/IPR/cache behavior
- restarting renders to verify whether changes actually updated
- manually discovering which controls are actually supported
- using terminal-based workarounds for tools such as `noice`
- guessing whether a feature is unsupported, legacy, hidden, stale, broken, or simply not documented clearly

**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 is not meant as a complaint about Arnold’s render quality. The issue is specifically about the Houdini/Solaris integration layer: node design, HDAs/OTLs, discoverability, update behavior, denoising workflow, material authoring, and documentation.

Arnold is a strong renderer, but the Solaris integration currently feels more difficult to use than it needs to be.

The examples above are only some of the issues I have faced and the ones that came to mind while writing this. Some of them have taken me days of searching, testing, debugging, and finding workarounds. I have already found workarounds or partial solutions for several of these issues, but finding them took time that I do not think should have been necessary. In many cases the issue was not that Arnold could not technically do something, but that the Solaris workflow was unclear, stale IPR/cache behavior made it hard to trust what I was seeing, or the documentation did not make the intended path obvious enough.

Possible areas to improve:

- modernize HtoA Solaris node design / HDAs / OTLs
- provide dedicated Solaris nodes for atmosphere/fog workflows
- improve update behavior for atmosphere/fog so full render restarts are not needed
- improve texture/image/shader update behavior so material changes refresh reliably in Solaris/IPR
- improve stale IPR/cache invalidation when relevant settings change
- expose Arnold light filter HDAs more directly in the light filter workflow
- clarify Arnold dome light default/auto behavior in Solaris
- improve Arnold Material Builder input/output UX
- reduce dropdown friction inside Arnold Material Builder subnetworks
- clarify duplicate/overlapping native MaterialX and Arnold-specific nodes in Arnold USD material subnetworks
- document recommended node choices for common operations such as multiply, color correction, texture processing, and utility math
- provide a clear Houdini/Solaris workflow for Arnold `noice` denoising, including UI usage if supported
- document the relationship between Solaris/ROP/UI denoising workflows and command-line `noice`
- clarify which workflows are legacy and which are recommended for Solaris
- improve Solaris-specific HtoA documentation
- document differences between ROP, Solaris, Arnold USD, and Arnold Hydra delegate workflows
- provide clearer examples for common Solaris-native Arnold setups
- document known update/restart requirements, if any, for atmosphere/fog, texture/image/shader changes, dome light behavior, and denoising

Overall, this is what Arnold in Solaris currently feels like from the perspective of a regular user trying to use it: the renderer itself is strong, but the integration layer often feels unclear, legacy, and difficult to trust without repeated searching, debugging, restarting, cache/IPR invalidation, and testing. A more Solaris-native node design, clearer documentation, and more predictable update behavior would make a substantial difference.

The report covers HtoA/Solaris, Arnold Material Builder, husk/noice, IPR/cache behavior, and documentation rather than one entry point. Start by splitting these into independently reproducible issues and reviewing the relevant Solaris workflows and existing noice/husk guidance. Done should mean each concern has a scoped change, reproducible behavior, and clear documentation or validation criteria.

Written by the indexing model from the issue text.