Hello.
I have already burned lot of time testing but nothing usable came out. So trying others.

Currently i was very disappointed with render options in Solaris and ways how we can check our results.

What we want is option to have IPR - progressive render going, being able to change values and see them reflecting in render. Be able to save and compare with previous renders. As easy and basic as it sounds, there is no solid option for that in Solaris.


Rendering into viewport (that was the first one i ruled out), is not good representative of the final render we would see in EXRs. The viewport doesn't update or show true nature of things and i dont trust it to validate our results. Is not usable for heavy scenes and will not render things that are payload unloaded from viewport. It only renders whats physically visible in viewport, which cant be used for example with big instances, as we cant load that many geo into viewport to check renders. But does support progressive rendering.


Using Clone option (second ruled out), which supports progressive rendering and is pretty true to what we would get in final results, mostly doesnt work in production scenes, as its failing to start Clone to get pixels from. Works like a treat with simple scene with RubberToy


Rendering in BackgroundRender doenst work with IPR, but is pretty good representation what we will actually render and is true to what will be present in EXR. Unfortunately doesn't seem to support anamorphic lens, and renders square image for those anamorphic cameras.

Render to Mplay is same as Background Render very true to final exports, supports anamorphic lense, but is missing progressive updates, and every change of shading parameter needs new render. Comparing images is also not great.

Im looking for ideas and suggestions.

Thanks for reporting all this. I admit I'm somewhat surprised to read that the viewport can't handle heavy scenes but Background Render or Render to MPlay can.

martinkindl83
The viewport doesn't update or show true nature of things

I'd really like to get more detail on this.

martinkindl83
Im looking for ideas and suggestions.

I think you've highlighted the options currently available (viewport + snapshots, background renders, clone renders, render to mplay/disk). We are looking at more workflows, trying to bring the best of each existing workflow together, but there's nothing available to show on this yet.

Thank you Rob for looking into it.
I think it looks like we are after the old renderView features.

Viewport rendering:
it renders only whats visible to viewport: if i hide payload it wont render (but would if i would do render to EXR), if i have 50mil point cloud, loading it into viewport is very not great, even if i display it as poits, if i hide it from viewport it wont render - but still would render into EXR.

Just making sure that i havent missed anything: progressive rendering is only available in viewport or clone right? no other oprions would give us progressive render or autoupdates on shader/parm change.


As for viewport, to be honest i cant fully comment on Karma, as we mainly use Arnold. It failed me too many times for me to trust it. Mainly with changing render settings, AOVs, or just changing things around, even flick OpenGL<>Arnold doenst solve it. Also something i found out yesterday, 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).

Thanks for the clarification on this.

martinkindl83
i cant fully comment on Karma, as we mainly use Arnold

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.

martinkindl83
we found that we have to use something else then configure stage to be able to hide layers for renders

Yes, that is by design and you are not the first person to have been caught by surprise. Configure Stage for layer muting etc is meant to configure the stage you're seeing in Solaris, not the stage you may later be writing to disk (which includes rendering to mplay). Given that you're not the first, it does suggest we're missing something (either supporting what you're trying to do, or being far more obvious that it won't work). Can you log an RFE for this?

yep, can do RFE

also double checking this:

Just making sure that i havent missed anything: progressive rendering is only available in viewport or clone right? no other oprions would give us progressive render or autoupdates on shader/parm change.

martinkindl83
yep, can do RFE

also double checking this:

Just making sure that i havent missed anything: progressive rendering is only available in viewport or clone right? no other oprions would give us progressive render or autoupdates on shader/parm change.

Si

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

martinkindl83
progressive rendering is only available in viewport or clone right? no other oprions would give us progressive render or autoupdates on shader/parm change.

That is currently correct.

Thank you

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.

I think its important to pass our feedback, even the negative one as that's what might help us in a long run.

I will share my experience, which might be harsh, but believe me i love houdini.

I have over 20yrs experience, mainly lighting and lookdev for feature films and commercials. I setup several lookdev and lighting pipelines.

Lastly i started with company that is using Katana for lighting, which was enough for me to step down from lighting and move to other departments. Not saying Katana is bad, but my personal experience with using Houdini over 10years made it just hard to move to Katana.

Anyway, many Houdini artist at that company are looking forward to move back to Solaris including me. But after my experience with Solaris - all the above notes that i agree with 100%, I dont think any Katana leads would be convince-able to move to Solaris and steer the whole lighting department. Even worse, if i would be asked, as much as i love Houdini, and have not the best relationship with Katana, i would not be able to recommend moving to Solaris.


PS: Just to add to the list (which is not what this thread is about - i was really hoping someone with more experience might help me out to understand how we should be using the Solaris for lighting), i really miss feature to find, where given override to parameter happens. In Katana you have yellow icon indicating that the default value has changed, but also have option to see, where the change is coming from. This feature is missing in Solaris and its pretty crucial feature for debugging.

colorbleed
Sorry for hijacking and derailing.

Not at all, this feedback is really useful to us. I know there is a lot still not-yet-done with the Render Gallery, and a lot that we're not able to jump on and turn around quickly, but I promise we're listening and we care about making this better.

martinkindl83
i really miss feature to find, where given override to parameter happens

We do have something for this - "Editor Nodes". For example, here I'm trying to track down where the subdivision scheme got set to "none" and can see it was in "edit_pCube187".

robp_sidefx

martinkindl83
i really miss feature to find, where given override to parameter happens

We do have something for this - "Editor Nodes". For example, here I'm trying to track down where the subdivision scheme got set to "none" and can see it was in "edit_pCube187".

That's awesome. Had no idea.
Learning every day.
Thank you for sharing.

martinkindl83
That's awesome. Had no idea.
Learning every day.
Thank you for sharing.

Just trying to get you one step at a time closer to retracting "i would not be able to recommend moving to Solaris"

And I really respect and appreciate it.

sorry i realized i have never posted the log error, when i try to start new Clone

Socket Error: "Thu, 03 Jul 2025 00:37:29 GMT": MESSAGE SEND ERROR(clone1) ws://127.0.0.1:32801/clone Msg='""' Error='"Broken pipe"'

any hints what to look for?

Hey @martinkindl83, can you please post your OS and exact Houdini version that is producing that error when starting a clone? Does it happen every time, even on a minimal scene (cube, camera, light, and a render settings prim for good measure)?

Thanks,
Mark

Hi Mark
we are using Rocky Linux 9.4 Blue Onyx (x86-64) with H20.5.550, but i was getting same error on Centos and older H20.5 version

Empty scene with rubbertoy always works.
Production scene never works.
Deleting some nodes, i have some chances to start a clone, but doesnt mean that next time i open the scene and delete exactly the same nodes, it will start the clone.
Not really helpful for repro steps.


Can i please just verify, the error code above, is that from you guys right? From native houdini. Pipe told me its not from them. So double checking.

Sorry for the huge delay here... Yes, that message is almost certainly originating from within Houdini. It looks like the interactive Houdini process couldn't establish a connection to the clone process. That may be because the clone process terminated unexpectedly, or it took too long to respond to the connection request, or any number of other things I can't imagine. There are a lot of layers to this cake. The fact that it works with a simple scene at least means there isn't something wrong with the low level technology or the network stack. It's something about the initial handshake that is going wrong. Do you see anything else in the Log Viewer (make sure clone logging is enabled)? Does this message come up very quickly or does it take a while? Does the clone (hython) process shut down? Can you tell if it shuts down before or after or at basically the same time as this message is generated?

Just looking for breadcrumbs to follow...

Thank,
Mark

Thank you Mark.
It works in simple scene every time (rubbertoy with rendersettings). In production scenes it almost never works, but if i get crazy and start deleting nodes, at some point im able to start it sometimes. But deleting the same nodes next time, dosnt mean i will be able to connect.
There is probably 30s delay from clicking create clone until i get connect and immediately disconnect error in logs. Hython stays active and doesnt close.

I totally get that this is something very hard to debug on your side.