Houdini Complex Scene Tips

Working in a complex scene may require you not to see all the geometry you are creating. You may even be using instancing to delay the geometry until render time (now available via packed geometry) to further optimize rendering. Use Packed Geometry.

If you are working on a shader, don't display all objects — turn on only the object you are working on. You can also easily copy that element into another file to work on it unconstrained.

If you are working on layout or lighting, you can use prototypes with Houdini's switch node to have the first frame for quick previewing and subsequent frames for rendering. Houdini also offers many display options on the top level container node.

Take advantage of the render-only and display flags combined with the null node. You can force objects on or off in your Mantra nodes.

If you don't need shaded mode, use wireframe — your interactions with the display will be faster.

Culling by camera frustum can save vast amounts of render time and is quick and easy to implement.

You can also use VEX instead of creating volumes — use VEX code to cull directly. See this YouTube walkthrough. I tested it in my Looooong Automaton and it worked great!

Example with POPs seen above, but this should be done with RBDs and other sims too. Use an attribdelete node — either syntax works. This step can substantially reduce cache sizes when caching simulations.

See the RBD Intro section for a full walkthrough. Simulating to points and instancing geometry at render time keeps your simulation lean and fast.

Instancing is essential for complex scenes. It defers geometry to render time and dramatically reduces viewport and render overhead.

Tip: you can use the USD Configure node in the SOP context before exporting, or in Solaris on the import nodes.

Unless you are working on texturing, shadow, or sampling parameters, render small tests for quicker feedback. You shouldn't be waiting long periods of time to test lighting or shading changes — there is no need to render the entire scene at full resolution. Work smart = work fast.

Mari and Substance often produce large textures (4K) that are not necessary for a given purpose. Think about how large your object will be on screen and size accordingly. Often less than 1K (512 or even 256) is sufficient unless it's right in your face on screen.

Size of your textures affects both disk space on the farm and access time. Large files being accessed for displacement, color, and so on are going to take time — make sure these files are not huge, particularly when you have multiple items using them. Start with 512 or smaller, and size up only if artifacts appear and it is necessary.

Houdini's Mantra renderer works most efficiently with RAT files. It takes only a few seconds to bring your TIFF, JPEG, etc. source file into mplay and save it as a RAT file.

mplay is analogous to Maya's fcheck but has different features.

Select the renderer that is optimal for your scene and split up your scene if necessary.

It can be helpful to split your scene into render layers, and if desired, render passes. These are different things — you can have render passes of render layers.

• Layers are when you split geometry (foreground, midground, background) — being careful to account for relationships between them. This can save a huge amount of render time, particularly for held elements that need only be rendered for one frame.
• Render passes are about splitting up the lighting layers for more control in compositing.

Both are excellent practices used by studios, but come at a pipeline cost of possible errors and overhead. Different layers may use different rendering/shading algorithms.

• If using Redshift: similar settings in the rop node for objects (passes) and AOV for layers — see the Redshift overview section.
• If using Karma: there is a separate node to set up these advanced lighting techniques.