| On this page |
Have you ever made up your mind what happens when you render a scene? Pressing the 
USD Render ROP’s Render to MPlay or Render to Disk buttons triggers a chain of different processes which finally result in an image. The essence of these buttons is, of course, to make things as comfortable as possible for the user. However, sometimes it’s important to know what’s going on in the background, especially in terms of memory and how images are saved to disk.
This page doesn’t tell you how to optimize your render settings. This page explains the role of husk in the render process, how different render products are handled, and where to expect memory and bandwidth increases.
Definitions ¶
Before we dive into the depth of husk, it’s important to know a few definitions. If you're an experienced user, feel free to skip this chapter.
| Term | Description |
|---|---|
| Render product | A render product represents an output file or output buffer, for example an EXR file. |
| Render var | Render vars are also called AOVs. Render vars contain specific lighting and material properties like color or diffuse reflection. You can also extract data channels, for example normals and depth. Render vars are saved separately and give you more control over certain aspects of the rendered image. |
| Hydra | Hydra is a common bridge for connecting USD scene data and render engines. |
| Delegate | A Hydra render engine, for example Karma, RenderMan, or Redshift. |
husk
|
A delegate-agnostic command line tool in Houdini that processes, controls, and handles the entire rendering task. |
Render products ¶
If you add a 
Karma Render Settings LOP, you also create an entry in the Scene Graph Tree. Under /Render tree, you can find a renderproduct entry. Note that you can create multiple render products for the same scene.
Click the renderproduct primvar and take a look at the Scene Graph Details panel. There you’ll see that the product type is raster - and this is the only type husk can process. Also, when you render inside Houdini’s viewport, the only render product is raster.
In this case, husk will save the product with its own libraries. The source of the raster is not important because husk can handle several raster types like RAT. If husk doesn’t recognize the product type, it’ll tell the delegate to save the product. For example, RenderMan is looking for file or OpenEXR types. Other types are deepimage or checkpoint.
Even if husk doesn’t know the product type, it will still do the rendering, but the saving part is done by the delegate.
Karma product types ¶
Karma has a karma:deep product type because husk and Hydra aren’t capable of handling deep images. As a consequence, only the delegate (here it’s Karma) will save deep images.
Another Karma-specific type is karma:checkpoint. A checkpoint is a way for Karma to interrupt and restart a job, for example on a farm.
Render vars (AOVs) ¶
Each render var represents an AOV. husk “forces” the delegate to allocate data buffers that have to exist throughout the entire render process. Number and size of the AOV have significant impact on memory usage. With 4K images, the delegate can buffer more than 100 MB per AOVs. In a scene with 15 AOVs, you’ll have at least 1.5 GB only for frame buffers.
Render vars are shared between multiple render products to save resources. You can, for example, have one EXR that outputs only color. Another EXR outputs ambient occlusion, position, and tangents.
Deep images & buckets ¶
A deep image can only be written to disk when all samples for the pixels have been resolved. Therefore, Karma needs to store a large amount of information before it can write the data. Deep image can have hundreds of gigabytes, and even modern computers can struggle with such a huge amount of data.
To overcome potential memory issues, husk automatically switches to bucket mode. In bucket mode, the image is split into small subsets that can be processed by the computer. Once a bucket is finished, the used memory will be flushed and is available again.
Tiling & stitching ¶
Karma XPU, on the other hand, doesn’t have a bucket mode. Karma would have to keep the entire deep image data until the image is finished. The solution for deep images in Karma XPU is tiling. Similar to buckets, tiling also subdivides the render into smaller chunks that can be handled by the computer. Tiling is available for any render delegate (even Karma CPU) that goes through husk.
You can, for example, create multiple render products, define the tiles, and send out every tile to a different machine of a farm. This workflow allows for high computation performance for a single image.
A user-friendly way to define tiles uses the --tile-count command line argument. For example, adding -tile-count 4 3 will automatically break up the image into 4 x 3 tiles. With the --tile-index argument you can select which tile you want to render. These tiling options are available in the Tiles tab of the USD Render ROP.
Another, less convenient method to break the raster into tiles, is the 
Render Settings LOP’s Data Window NDC parameter. To make the parameter resolution-independent, image size is normalized and ranges from 0 to 1 in horizontal and vertical direction. A value of 0.25 represents 25% of the image, a value of 0.5 is exactly the half.
Stitching ¶
To combine the tiles into a single image, you typically use the itilestitch command line tool that ships with Houdini. You can find it here:
Windows
C:\Program Files\Side Effects Software\Houdini <version>\bin
Linux
opt/hfs<version>/bin
Mac
/Applications/Houdini/Houdini<version>/Frameworks/Houdini.framework/Versions/<version>/Resources/bin
Auto-tiling ¶
Instead of creating and stitching the tiles manually, you can also use auto-tiling. In auto-tiling mode, husk will load the USD file one time. Then it will tell the delegate to render multiple frames, and each frame will be a different tile. The tiles will be saved temporarily and stitched together after the render process. Auto-tiling is a good option for GPU rendering because each render var is allocated by the delegate. In many cases, those render vars have to use VRAM and RAM.
Auto-tiling works in conjunction with karma:raster and karma:deep. Other product types like RenderMan or Arnold might work, but have not yet been tested.
Denoising ¶
When you denoise the individual tiles, you might see seams after the stitching process. We therefore recommend applying denoising only to the stitched image.
You can use the idenoise command line tool to denoise your images - it’s located in the same directory as itilestitch.
Memory and bandwidth ¶
You’ll see bandwidth peaks at different moments when using husk. Depending on the product type, the way that data is saved can be different.
Bandwidth peaks occur, when husk loads the USD files and textures.
With raster images, husk will only save out an image at the end when the entire image is rendered. Then you’ll also notice a significant bandwidth peak. This also applies to standard EXR with multiple AOVs because they're raster product types.
With deep images, data is saved to disk when a bucket line is completed. This behavior is different from raster images and bandwidth increases at render time. With deep images and Karma XPU, husk has to allocate the whole raster and that’s why auto-tiling is used. For Karma CPU, memory is only allocated per bucket.
When you render snapshots, husk will save out the intermediate buffers from time to time. During this process, bandwidth increases. This also happens when checkpoint data is saved.
The AOVs for Cryptomatte don’t have to exist until they're written by husk. This means a higher memory allocation towards the end of the render or when a snapshot is saved. In general, Cryptomatte requires more memory, but not as much as deep images. Rendering Cryptomatte in bucket mode is slightly more efficient.
