Hello,

I have seen a few posts similar to this, so I think I am not alone. This isn’t meant to be a “solaris bad” post, but rather point out some issues I am having/my experience. I have been using solaris for quite a while now and I can see how it has vastly improved over the past few years. That being said, every time I use solaris things quickly become frustrating. One more thing I wanted to point out. I realize how amazing USD and its implementation in solaris is, but this is more from the perspective of an artist that just needs to render a scene and isn’t particularly concerned with (or want to be) the complexities of USD every time it comes to rendering/lookdev/layout.

Performance: (For reference I have 128 gigs ram, 7950x, 4080 super)

I have been using solaris for lighting/rendering, but I just completely gave up trying to do layout in solaris. It always gets to the point where the interaction is so slow I can’t even move an object because the viewport is so slow. So many things you have to watch out for-time dependent lops, where the display flag is vs which node you are editing, lopnet bogged down by re-cooking, etc. If I am rendering geometry imported from sops and I need to make a change to an attribute or modify the geometry, that could potentially trigger re-cooking all the lops below it. Animating a camera or trying to move an object can be a nightmare. I have to constantly be changing the display flag or re-ordering things just to get barely usable FPS.

One of the great things about GPU rendering being able to iterate quickly. However, karma can be painfully slow to just start rendering. I believe the Docs mention this. Changing a material setting or enabling a hidden object/adding a new object (even light-weight objects) can result in having to wait long periods before rendering even starts. These waiting times grow as the stage becomes more complex. Sometimes closing the project and re-opening it helps with performance.

Stability:

Aside from performance issues, seemingly simple operations in solaris wind up crashing houdini. Hiding/showing primitives in the stage trigger crashes, switching on karma xpu triggers crashes, turning off xpu and going back to opengl triggers crashes, etc. Recently I had a simple stage where one object was literally just a sphere. It was hidden and I needed to enable it in the scene graph tree. As soon as I enabled the sphere it triggered a crash. I re-opened houdini and tried enabling it again. Crashed again. Finally on the 4th time it started working. I was able to show/hide without any crashes. Nothing changed, same hip file.

Now, combine all this together. Imagine you want to do layout/lookdev while using karma xpu (instead of opengl). You get very poor performance while trying to transform objects. So you have to move nodes around/change the display flag to improve peformance. This causes XPU to be extremely slow because you are changing things which causes xpu to freeze before it can start rendering. Then add the crashing on top of that. Then it all becomes a nightmare of crashing, slow viewport performance and waiting long periods of time for karma to start rendering for simple changes.

Aside from all that sometimes I just want to do things without having to worry about the complexities of USD. But some newer features are locked behind solaris. For example, the layout brushes are locked behind solaris and you have to convert your assets /sop geo to a usd asset just to be able to use the brushes.

I know this has been pretty negative but I will say my experience with solaris has been better when working with studios that have multiple departments. Getting data from other departments and delivering FX using USD and solaris was a great experience. Also getting decent performance with large amounts of data.

Anyway, anyone have any thoughts or tips? Would be glad to hear. Thanks.

evanrudefx
One of the great things about GPU rendering being able to iterate quickly. However, karma can be painfully slow to just start rendering. I believe the Docs mention this. Changing a material setting or enabling a hidden object/adding a new object (even light-weight objects) can result in having to wait long periods before rendering even starts. These waiting times grow as the stage becomes more complex. Sometimes closing the project and re-opening it helps with performance.

This is almost certainly shader compilation.
We have some big improvements coming in this area for the next major release of Houdini.

evanrudefx
. Hiding/showing primitives in the stage trigger crashes, switching on karma xpu triggers crashes, turning off xpu and going back to opengl triggers crashes, etc.

Please get these into bug reports (eg with an example scene with clear repro steps).
We often get crash bugs fixed within a matter of days once they're submitted.
Do you at least get crash logs? They're also very useful.

Coming from Vray, Karma XPU did work pretty well for us - in fact so well that we decided to do complete projects with it.

We especially find volumes, particles and hair to be a lot better (and faster) than with vray. General interactivity is so much better (besides the shader compilation issue and some of the solaris weirdness).



Of course once you start digging deeper, you will find stuff that is not optimal yet. Here are some of the problems we have and some features we are still missing.

- rendering many lights: it seems that xpu slows down substantially the more lights you add to the scene. This is even pretty noticable with only a couple of lights (vray does have adaptive lights which help a lot)

- rendering aovs: it also appears that aovs slow down xpu a lot. In some tests, the rendertime would go up 50% when adding a standard set of aovs.

- noise: while certain things render pretty quick and clean (hair for example) others are more difficult (with refractive materials being the worst). Sometimes its close to impossible to remove noise from certain parts of the image. I do hope that this will improve a lot with the next major houdini update (with adaptive sampling, path guiding and what not).

- shaders: while the current set of Mtlx shaders is ok, there are still some features missing that we are used to from vray (a brdf rayswitch for example). I am also wondering, if there will be more Karma specific shaders like a dedicated skin shader, a karma noise node with all the houdini noises, flakes, OSL support (at least for textures), volume displacement and better material layering.

- lightlinking is (still) somewhat broken, at least in the viewport. There are often cases, where doing some sort of change will suddenly break the lightlinking and only an xpu restart can fix that. Rendering through husk does seem to work fine though. Shadow linking would also be really nice.

- distributing high resolution single frame renders: with some projects we need to provide high res still images (20k+). Vray has a function for that which works very well. Maybe this could work with clones?

- projections: any sort of easy to use shader based projection (especially camera projection) would be great (coord sys is not that). I imagine a projection gizmo primitive that can be referenced in a shader.

- trace sets for reflections/refractions

Nice feedback! I hope you let SideFX know by logging bugs/rfe's.
https://www.sidefx.com/forum/topic/70943/ [www.sidefx.com]

Haha, I know the drill. For some stuff I already have. I was hoping to get developer feedback on some of the stuff first (like "we know, this is already happening or is going to happen) so I may be more precise or get some examples.

brians

evanrudefx
One of the great things about GPU rendering being able to iterate quickly. However, karma can be painfully slow to just start rendering. I believe the Docs mention this. Changing a material setting or enabling a hidden object/adding a new object (even light-weight objects) can result in having to wait long periods before rendering even starts. These waiting times grow as the stage becomes more complex. Sometimes closing the project and re-opening it helps with performance.

This is almost certainly shader compilation.
We have some big improvements coming in this area for the next major release of Houdini.

evanrudefx
. Hiding/showing primitives in the stage trigger crashes, switching on karma xpu triggers crashes, turning off xpu and going back to opengl triggers crashes, etc.

Please get these into bug reports (eg with an example scene with clear repro steps).
We often get crash bugs fixed within a matter of days once they're submitted.
Do you at least get crash logs? They're also very useful.

Thanks, I will try to start reporting crashes when I can.

ronald_a
Coming from Vray, Karma XPU did work pretty well for us - in fact so well that we decided to do complete projects with it.

We especially find volumes, particles and hair to be a lot better (and faster) than with vray. General interactivity is so much better (besides the shader compilation issue and some of the solaris weirdness).



Of course once you start digging deeper, you will find stuff that is not optimal yet. Here are some of the problems we have and some features we are still missing.

- rendering many lights: it seems that xpu slows down substantially the more lights you add to the scene. This is even pretty noticable with only a couple of lights (vray does have adaptive lights which help a lot)

- rendering aovs: it also appears that aovs slow down xpu a lot. In some tests, the rendertime would go up 50% when adding a standard set of aovs.

- noise: while certain things render pretty quick and clean (hair for example) others are more difficult (with refractive materials being the worst). Sometimes its close to impossible to remove noise from certain parts of the image. I do hope that this will improve a lot with the next major houdini update (with adaptive sampling, path guiding and what not).

- shaders: while the current set of Mtlx shaders is ok, there are still some features missing that we are used to from vray (a brdf rayswitch for example). I am also wondering, if there will be more Karma specific shaders like a dedicated skin shader, a karma noise node with all the houdini noises, flakes, OSL support (at least for textures), volume displacement and better material layering.

- lightlinking is (still) somewhat broken, at least in the viewport. There are often cases, where doing some sort of change will suddenly break the lightlinking and only an xpu restart can fix that. Rendering through husk does seem to work fine though. Shadow linking would also be really nice.

- distributing high resolution single frame renders: with some projects we need to provide high res still images (20k+). Vray has a function for that which works very well. Maybe this could work with clones?

- projections: any sort of easy to use shader based projection (especially camera projection) would be great (coord sys is not that). I imagine a projection gizmo primitive that can be referenced in a shader.

- trace sets for reflections/refractions

Yea, I have had bugs with light-linking too. With karma seems like you have to go with denoising because as you said its almost impossible to resolve noise in some parts of the image.

I also see great potential here but it's no replacement for /obj. As been noticed by others here doing animations in Solaris is a none starter due to unmanageable recooks and what not. Which in turn forces me to jump through the translate-to-USD hoops to be able to use Karma at all. Which creates other problems on its own.

And while the Karma render itself is great the UX is terrible imho, lack of a proper VFB (visual frame buffer) and everything being tied to volitile viewports makes it hard to use. Render Gallery could use a lot of work! The clones are brilliant but should be more control and all AOVs should transfer from them. Also the elusive missing 'render' button is still a mystery to me

Light mixer also great but a hit crashy at times.

So awesome potential here, it just needs to be unlocked better!

About to finish a project using solaris. Scene is ready to render. I need to render multiple passes. All I need to do is hide some geometry. The scene renders perfectly fine. So I add a prune to de-activate some geometry. Guess what? solaris crashes with karma xpu. Well, surely I can just disable the sop import. That crashes too. All I am trying to do is hide/deactivate some primitives. I literally cannot render this scene once I disable some particles. Going to scene graph and hiding also crashes. this is wild. I have crashed 12 times in a row simply trying to disable some geometry.

update, turns out its not crashing. Its just the karma xpu getting stuck on initialization. If I let it sit for like 5 minutes it gets unstuck and works. Still makes 0 sense to me. If I open houdini, open my project and hit render the scene takes around 2 seconds to start rendering. If I disable the particles in any way-(prune, disabling sop import, setting render visibility, etc)I have to wait around 3 minutes to start rendering. If I try to do anything else during that time it crashes. How hiding geometry cause the time to start rendering go from 2 seconds to 3 minutes?. Oddly, if I save my scene after hiding the geometry and waiting for it to render, it renders again in 2 seconds off a fresh houdini session. Wild.

XPU (and Optix) need to recompile their internal code based on what combination of geometry and rendering features are active in the scene. The fact that it takes 3 minutes is something we're working with NVidia to improve.

The good news is that once that combination has been compiled, it gets cached, so when you load that scene again it should be instant.

For the next major release of Houdini we plan to build a "pre-compile" step where XPU will go away and pre-compile the code for all the combinations of features/geoemtry we ever expect someone to use. It'll probably take a few hours, so hopefully, people can do it either on their lunch break or over night. But once that is in place, these long stalls should go away.

And when you say "crashes", are you rendering in the IPR viewport? Or offline via karma/husk. Because if in the viewport, you should see a readout in the top-right corner saying "compile #" (with the # being the number of compilation jobs)

brians
XPU (and Optix) need to recompile their internal code based on what combination of geometry and rendering features are active in the scene. The fact that it takes 3 minutes is something we're working with NVidia to improve.

The good news is that once that combination has been compiled, it gets cached, so when you load that scene again it should be instant.

For the next major release of Houdini we plan to build a "pre-compile" step where XPU will go away and pre-compile the code for all the combinations of features/geoemtry we ever expect someone to use. It'll probably take a few hours, so hopefully, people can do it either on their lunch break or over night. But once that is in place, these long stalls should go away.

And when you say "crashes", are you rendering in the IPR viewport? Or offline via karma/husk. Because if in the viewport, you should see a readout in the top-right corner saying "compile #" (with the # being the number of compilation jobs)

Yea, I was using IPR viewport. What happened is after pruning the geometry, it said compiling and would render slowly. A 30 second frame had an estimated time of 12 hours or so. In the task manager it said not responding. If I did anything else in houdini like orbit the camera, switch back to opengl, save the file, or change a parameter houdini would crash. Thanks for the reply. I just didn't expect/understand that the possibility could happen where I would need to wait 3-5 minutes for hiding a primitive. As long as I don't do anything during that time houdini won't crash.

evanrudefx
In the task manager it said not responding.

The Optix compiler does not allow interruptions :/
We're working with NVidia to try and get that fixed. Meaning that even if it is compiling jobs, Houdini shouldn't hang.
Thanks for your patience.

Can't agree more with the many points mentioned here.
Animation in Solaris is a nightmare, even when all I need is a very basic camera rig it can be way too involved to be useful.
And not being allowed to look through the stage camera in a SOP edit node(I do realize they belong to different contexts) is such a bummer and makes creative workflow as most inefficient as possible, if no more complicated roundabout way is further involved.
And no viewport position handler in a null node just like /obj is another no-go.
And the scene interpretation happening each time I jump between the Solaris and SOP context slows down the viewport.
Karma is great but I pretty much gave it up due to lots of pain and lessons learned in the bitter way mentioned above.
Solaris might be insanely powerful if you get 5 different departments in charge of different aspects of the same scene but it's really no fun for solo artists who need to finish everything by themselves in one hip file.

Lewis_Orton
Can't agree more with the many points mentioned here.
Animation in Solaris is a nightmare, even when all I need is a very basic camera rig it can be way too involved to be useful.
And not being allowed to look through the stage camera in a SOP edit node(I do realize they belong to different contexts) is such a bummer and makes creative workflow as most inefficient as possible, if no more complicated roundabout way is further involved.
And no viewport position handler in a null node just like /obj is another no-go.
And the scene interpretation happening each time I jump between the Solaris and SOP context slows down the viewport.
Karma is great but I pretty much gave it up due to lots of pain and lessons learned in the bitter way mentioned above.
Solaris might be insanely powerful if you get 5 different departments in charge of different aspects of the same scene but it's really no fun for solo artists who need to finish everything by themselves in one hip file.

Yea, not being able to see the stage camera in a sop create really sucks.

Lewis_Orton
Can't agree more with the many points mentioned here.
Animation in Solaris is a nightmare, even when all I need is a very basic camera rig it can be way too involved to be useful.
And not being allowed to look through the stage camera in a SOP edit node(I do realize they belong to different contexts) is such a bummer and makes creative workflow as most inefficient as possible, if no more complicated roundabout way is further involved.
And no viewport position handler in a null node just like /obj is another no-go.
And the scene interpretation happening each time I jump between the Solaris and SOP context slows down the viewport.
Karma is great but I pretty much gave it up due to lots of pain and lessons learned in the bitter way mentioned above.
Solaris might be insanely powerful if you get 5 different departments in charge of different aspects of the same scene but it's really no fun for solo artists who need to finish everything by themselves in one hip file.

It's very exciting to see that the SOP context camera look-through issue and the scene proxy representation are addressed in 20.5! If we have a simple camera rig solution in Solaris it would be a real lifesaver!