Roy Nieterau

Been using Solaris for 2 years now with Redshift and Karma. I'm missing a render view to

This is the single biggest complaint I'm getting from artists here too - rendering in the viewport is just too much of a pain. A dedicated viewport is really what they're looking for.

The render clones setup allows to do that - but the "background render" comparatively is slower to update than the viewport render so for local tweaking when doing lookdev it very much defeats the purpose. If only:

- The "live" local scene render could just render directly to the Render Gallery (as if it were a 'local clone' without coming from another process) then I assume it'd be faster on the updates + basically be able to act as render gallery.
- The render gallery (where the clones render) would be much improved, that would help too! (e.g. snapshots can be buggy and/or very slow; we've had snapshot databases getting corrupt too)

Muting layers does correctly render in viewport, giving you hope that your hidden layer will not render, but it does render into EXR (we found that we have to use something else then configure stage to be able to hide layers for renders).

I wondered about this - because technically there's nothing stopping us from explicitly passing the muted layers list to the Husk render process? But it doesn't seem like `husk` by default comes with a simple command line flag to mute certain paths. If it had, then the USD render ROP for example could by default pass those arguments along so that what you'd render would match the muted layers as configured in Houdini. Allowing it to behave the same, even if the muting itself wasn't written in the USD file?

Ah, that does unfortunately make it more difficult to assess which issues lie with Solaris vs the Arnold delegate/integration. Please do feel free to still send bugs to us. We can always investigate and advise "this one is for the Arnold team" when necessary.

I must admit that the Arnold Solaris integration really is a back and forth of being a pain in the ass and having good fixes, to then get broken on a new Houdini release. The Vulkan viewport e.g. gave issues with some viewport objects disappearing (switching back to older viewer with the env var fixed that though!).

---

I'm so immensely hopeful for Solaris and I can really see the power of it - but I'm ultimately so sad getting pushed back by our lookdev and lighting artist that the workflow is just so much more in the way due to a multitude of things - but the render view is one of those things that just ALWAYS pop up + the regular Arnold Solaris bugs + the fact that just quickly creating materials, without leaving the viewport with your mouse just really seemed possible.

Sorry for hijacking and derailing.

Is there any good way to query the currently configured audio panel settings? I'm in particular looking to query the currently selected file or CHOPs?

I've seen the hou.audio module [www.sidefx.com]. However, it has no ways to query the currently set values - only ways to set new values.

Then there is the hscript equivalent audiopanel [www.sidefx.com] which when executed without arguments would print the current configuration.

As such - the only way seems to parse the result of that into Python object, e.g. similar to this quick prototype [github.com].

Is there an easier way to access this?

Preferably there would just be access to e.g. `hou.audio.filename()` etc.

> Would be nice to have access to the data it is using to filter them under the hood.

Agreed - interested to hear how Houdini itself filters these. E.g. it can also detect LOP Import Camera in `/obj` is 'a camera' but there doesn't seem to be a `hou.ObjNode` way of querying whether it's a camera in that sense.