Hello,

I am new to Houdini and Solaris, I have a background in lookdev/lighting with Katana in the film industry. I'm currently in the process of transitioning over to Houdini with Solaris and RenderMan.

When working on scenes I've noticed that changing parameters or doing simple stuff like just clicking on nodes causes Solaris to "cook ops" for a considerable amount of time which stops me from doing anything until it is done.

I have uploaded a video to YouTube showing what I mean:

I'm wondering if this is all normal for Solaris workflows and if not, what am I doing wrong? I've tried the "pause scene updates" toggle in the scene view but that doesn't stop the cooking from happening.

In Katana everything you do is fast because it doesn't actually calculate anything until you hit render, which is a massive help when working on huge production scenes. Does Solaris have a workflow which allows you to do a similar thing? I need to be able to work on very heavy scenes without having Solaris chug and cook everything after all adjustments that I make.

Any insights on what I am doing wrong and what the correct workflow is for handling and working with large datasets would be greatly appreciated.

Thank you,
Rassoul

One thing that can be handy is the "follow current node" toggle in the Scene Graph Tree pane. When it is disabled your SGT will only show the scene graph of your currently displayed LOP. When it is enabled, it will show the scene graph of whatever LOP you have currently selected, causing it to re-evaluate the stage every time you select a different LOP.

Siavash Tehrani
One thing that can be handy is the "follow current node" toggle in the Scene Graph Tree pane. When it is disabled your SGT will only show the scene graph of your currently displayed LOP. When it is enabled, it will show the scene graph of whatever LOP you have currently selected, causing it to re-evaluate the stage every time you select a different LOP.

That is actually very helpful in speeding it up, thanks for that.

I also found the "manual update" mode which massively helps but of course it is not an ideal workflow when working on shots.

Can you post the scene so that we can see if the lag is consistent across machines?

I can share the scene but not the geo in the scene as they are production assets.

I have had teammates test the scene and the issue is still there for them too. Also, my machine is very high end so it's not an issue of an underpowered machine or anything like that.

Are you able to reduce the amount of stuff populated/loaded while you work? By default lops loads and cooks everything on the stage, where's Katana doesn't. But you could try the "Create Configure Stage Node from Load Masks" option in the Screen Graph Tree "Manage viewport load masks" menu to limit the number of prims populated/loaded onto the stage. That's somewhat similar to expanding a location in the Katana UI, which causes it to cook.

Also, I can't tell from your video if you're using instancing or not, but for environments try and have as much instanced as possible (either by prim instancing (sometimes called USD native instancing) or point instancing). Instancing causes far less prims to be created during stage composition, resulting in fewer prims for lops to cook.

That is a great tip regarding the viewport masks and visibility, very useful. However, although it does increase performance it makes me run into another issue - Hiding pieces of the helicopter for better performance also hides them in the render. I still want the render to render everything in the scene, but the viewer to for example, only show the helicopters fuselage for better performance instead of loading in all 7000 objects.

In Katana the viewport overrides do exactly that, they allow you to hide and view the things you want to work with but when you render something it renders everything in your node graph. The scene itself and the viewport are separate.

I guess this is just a shortcoming of the whole Hydra viewport/rendering setup as opposed to having a separate system for renders and viewers, you can't really detach the two processes?

I guess what I can do is setup different view masks for different things. One which is just a few objects for quick working and then the load all option for when I want to view and render everything and then switch between them while I work. It's not ideal but it does definitely get the job done.

To answer your question about the environment, there is currently no environment loaded in. Just the two helicopters. That's the main reason I am worried about the performance, this is about 25% of the entire scene so I need to figure out performance optimizations if I hope to be able to handle the full production scene.

I guess this is just a shortcoming of the whole Hydra viewport/rendering setup as opposed to having a separate system for renders and viewers, you can't really detach the two processes?

No, it's not a shortcoming, if anything it's better than the Katana "can't see anything till I expand it" logic.

You might need to read up about render purpose/proxy workflows. The idea being that your "proxy" is what is loaded into the hydra delegate, either the openGL viewer or your target renderer's one. You have full control over this.

L

You are assigning primvars on 27918 descendants with the wildcard in your BaseAssigments(Render Geometry Settings node).

Have you tried to remove the wildcard? You don't need to use wildcard. You only need to assign at the top group as long the child items don't all ready have the primvars you are adding, and you need to do a override.

If this don't work it's probably best to assign all these primvars on the surface/look USD file, before loading it into the light scene.

Rassoul
In Katana the viewport overrides do exactly that, they allow you to hide and view the things you want to work with but when you render something it renders everything in your node graph. The scene itself and the viewport are separate.

Have you tried setting the purpose of your prims? You could set certain ones to "render" - those would be hidden in the viewport but present in the render.

Thank you all for the suggestions. I've been able to massively improve the performance of the scene using them.

I optimized my primitive matching patterns which helped almost entirely eliminate the cook times, restructured the network so that when making live changes to things like lights, downstream nodes didn't need to be recooked, and setup the render purpose for the geos with proxies that are 1/13th as dense.

Viewport interactivity has gone up massively and cook times for ops have been reduced to 1 second max. FPS went from 9 to 111 with the render purposes set.

There is still a lot to learn about Solaris but this round of optimization has at least made my scene workable. I'm sure I can optimize it even further as I learn.

If you have any resources for optimizing and working with huge production scenes in Solaris then please do share.

Thanks again for your insights!

Great to hear you got performance to a better place.

One thing that did occur to me is it's somewhat possible to get a katana like workflow by having two different stages and putting your shot lighting in a hda. Dropping down the hda twice, but only editing the copy that has a smaller subset of geometry loaded allows you to control when the full version refreshes simply by saving the hda. It may not be completely optimal or practical but thought I may was well throw it out there. The trick is to have a subnet with a configurestage lop that populates and loads everything at the end, and then pin the full render viewport to that subnet. Kind of hard to explain so I attached a movie that should clarify the setup.