Some general tips and suggestions to help improve performance while working in Solaris.

• High numbers of primitives can slow down USD and Hydra, particularly in cases of hundreds or thousands of sibling primitives. Where possible, try consolidating Mesh primitives, and use GeomSubsets to bind materials to different parts of the mesh.

• It is good practice to group primitives underneath a single prim, and is essential when building assets, so that referencing works. Even when building a scene, it’s recommended to have a single primitive that contains all of the lights, assets, and cameras. Some of the common ones are /Scene or /world.

• Houdini’s Prim Pattern matching is extremely powerful, but it is also very easy to traverse too many prims in the scene. Investing time to understand how to craft intuitive prim patterns is very valuable.

• Use Selection Rules to store and re-use primitive selections while working in Houdini. USD Collections are great for grouping prims, but are designed for cases where primitive collections need to be transmitted through USD to other parts of a pipeline or workflow.

• Scopes are useful for organizing prims, without having places where accidental transforms can be authored. They also make scenes easier for Hydra to process, as Scopes don’t contribute to a prim’s transform.

• When converting geometry from SOPs into LOPs, importing too many attributes can make USD files bigger on export.

• Use purpose, to ensure that the viewport doens’t get bogged down trying to draw everything all the time.

• Setting purpose on many individual prims can add lots of overhead for the viewer Hydra. Instead, consider setting purpose on a parent prim, to avoid having to manage it on individual prims.

• Set the Scene Polygon limit to a value your graphics card can handle, to get the most out of Distance-Based Geometry Culling. The bounding boxes for primitives that are further from camera can be useful, but if even those are adding overhead, don’t hesitate to set them to invisible.

• When working inside of a SOP Create, SOP Modify, or Instancer LOPs, hiding the Solaris panels, and setting the viewport to Hide Other Objects will improve interactivity within that SOP network. If you want to keep those interface elements visible, you can also connect an Output SOP to a null, which will prevent the Solaris UI’s from re-translating your SOP works after every little tweak.

• Recooking nodes can cause seemingly simple operations to be very slow. For example, transforming a cube should be interactive. However, if you are transforming a cube at the top of your network, and displaying a node way at the bottom, that simple transform is causing a lot of re-cooking.

• Watch out for Houdini time dependencies. These can cause LOP nodes to re-cook unnecessarily, and give more work to USD. You can use Cache LOPs immediately after a group of nodes with animation or animated expressions, to write the time samples to USD. Slow USD exports also affect rendering, as the USD Render LOP writes a temp USD file that is rendered using husk.

• The Lop Layer Colors are useful indicators when trouble-shooting slow cooking scenes. Each LOP node works on a a layer, and that color corresponds to nodes that are editing the same layer. Whenever these colors change in the node graph, it is a hint that a new layer has been added to the stage. It might also mean that a completely new stage has been created as well. These points where the color changes is a hint that there could be composition-related overhead.

• As LOP layers have more and more opinions and values added, there can be slow-downs in the viewport. If you notice simple transforms are very slow in the viewport, try using a Configure Layer to start a new layer above where you're working, and see if that improves interactivity.

• Merge LOPs can be useful to improve scenes, but they can also cause more work in some cases as well. If each input to the merge has complex USD composition setups, re-cooking the Merge LOP can end up as a huge bottleneck.

• By default Scene Graph Tree and Scene Graph Details follow the current, selected node. While this can be convenient, it does incur some overhead as the stage must be composed at that point in the node graph in order to update the Scene Graph Tree and Scene Graph Details. Sometimes this isn’t noticeable, but if the stage at the select node involves lots of composition tweaks, layer flattening, or other changes to the structure of the stage, it can make Houdini slow.

• In very heavy scenes, it is recommended to unload payloads in both the viewport and the network. There are payload controls on the Sublayer and Configure Stage nodes. The preference to change payloading defaults is in the Lighting preferences. This lets you decide which parts of a scene you are interested in, and only pay for the cost of loading that.

• Using activation to streamline your working scene can be bad, as activation/deactivation can cause USD to do a lot of recomposition work, that Houdini must then wait for. It is generally better to rely on payloads or visibility.

• Population masks can be a powerful way to streamline a scene, but they are absolute, and USD/Houdini are completely prohibited from seeing or editing prims that fall outside of the mask.

• Solaris provides an Sdf file format plugin for USD, which means you can sublayer, reference, or payload .bgeo files directly. This can save time/disk space writing out .usd files. To control how the .bgeo files are loaded into the stage, use a USD Configure SOP to setup detail attributes to specify which SOP attributes will be added to the stage.

• When working in the Python LOP, you can use Sdf-level APIs within an Sdf.Changeblock() to get massive performance boosts. The tradeoff is less convenient functions for manipulating the scene. Sdf code requires understanding the differences between prims on a UsdStage, and Primspecs in an SdfLayer.

• You can get access to Houdini’s prim pattern matching in Python using hou.LopSelectionRule. Use the node’s input stage to resolve the prim paths. This can sometimes be easier than simply traversing using native USD APIs, and is more comfortable and familiar to artists in Solaris.

• For Each blocks are super convenient, but it won’t be as fast as iterating within a Python LOP.