The sections below refer to an example file. You can load this example file if you want to follow along:

$HFS/houdini/help/files/ifd_workflows/ifd_workflows.hipnc

Copy the ifd_workflows directory out of $HFS to somewhere in under you user directory so Houdini can write IFD files inside it.

Houdini has some of the best support for Alembic caches in the industry, including fast and flexible Bullet solver support for packed primitives. Given this support, artists are creating more and more geometry in their workflows. Even motion graphics and set-dressing benefit from streamlined geometry formats. These formats are well suited to fast IFD workflows.

There are several varieties of Packed Primitives:

(See Packed Primitives for more information.)

This section will use Packed Disk Primitives as an example, but you can also use Alembic primitives. We use Alembic in the section below on motion blur.

You can often interchange Packed Primitives and Alembic primitives when working in Houdini; not always, but usually. This is because a Packed Primitive is a generalization of Alembic primitives, but can be made up of all types of geometry, including Alembic primitives. For more information, see the Packed Primitives page.

Because Packed Disk Primitives by their nature are geometry streamed from a file, similar to Alembic primitives, we don’t have to use a special procedural to get smaller IFDs.

In the example file, look inside the packed_pig Geometry Object. It contains a geometry network with a few nodes, all wired into a Copy SOP. If we look at the File SOP, it’s pointed to pig.bgeo.sc. To avoid duplicating our geometry on-disk, the File SOP offers the option to load the geometry as a Packed Disk Primitive; if you set the Load parameter to "Packed Disk Primitive", Houdini doesn’t load the Full Geometry and instead streams Pig from disk.

(Because it is Packed Geometry, the File SOP gives us some nice options both for managing how much Houdini has to display. This has no bearing on the IFDs, sine we are loading the bgeo as a Packed Disk Primitive, but it does make working interactively more pleasant.)

If you render the mantra_pig_packed ROP and look at the IFD file, it’s only 15Kb! Even though we're copying our packed Pig to several points, and varying the color of each one, the IFD is still tiny. Using Packed Disk Primitives make uses less disk space and network IO.

Material Stylesheets are extremely useful with on-disk geometry. Stylesheets let you assign and vary shaders without having to load the geometry and bind to it. See Material Stylesheets.

In the network editor, go to /out, and look at our ROPs. We're using the Force Objects parameters to make sure each ROP only dumps a specific part of our scene into the IFD.

To make sure the IFDs get the materials, each ROP has Declare materials (on the __Render > Render_) tab set to "All SHOPs". Since the geometry only references a material but doesn’t include it, we need that material to be included in the IFD. Declaring all SHOPs forces all materials to be included in the IFD, so they are available for any procedurals to use.

You’ll notice neither pig or procedural_pig have a material assigned at the Object level or at SOP level. Both have an attribute called shop_materialpath. As long as the current hip file has a material that matches that attribute, and we declare the materials on the ROP, everything will render.

On the mantra_pig_packed ROP, go to Driver tab. The Disk file checkbox is on. If you click Render to Disk, nothing will appear to happen, but the ROP will generate an IFD file (instead of generating a temporary IFD file and automatically rendering it). Render IFDs for both mantra_pig and mantra_pig_packed. Note how much faster the procedural ROP runs.

If you go inside the ifd folder where you opened the project, you’ll see the IFD sizes are drastically different:

The benefits are obvious: the IFD file that references packed geometry instead of including it is 0.2% the size, and you don’t have to regenerate the IFD if the geometry file changes.

Imagine you're rendering a shot with hundreds of gigabytes in cars, windows, and other props. In a shot that’s 600 frames long. A shot accessed by many computers at once. You can see why a studio would prefer to work this way. Even to a lone artist, or a school with more modest resources, saving disk space, and using Mantra tokens instead of Houdini licenses, are huge wins.

Another method for importing external geometry at render time is the Delayed Load Procedural. The Delayed Load Procedural is a shader that fetches an object’s renderable geometry from disk at render time, replacing whatever geometry was inside the object (meaning the object can be empty, or contain simple proxy geometry).

In the example file, there is a Geometry object called pig and one called procedural_pig. If you hold on each node, you’ll see that pig has 1 child SOP (a File SOP pointing to $HIP/geo/pig.bgeo.sc), and procedural_pig has no child nodes.

Select the procedural_pig node. In the parameters, click the Render ▸ Geometry tab. A parameter called Procedural Shader points to a Delayed Load procedural. If you jump to that node, you’ll see that its File parameter points to the pig.bgeo.sc file on disk.

If you click the Render View, and set the ROP to mantra_pig_procedural, you’ll see our pig statue render. You can even render mantra_pig, to visually compare.

(With Auto-Update on, sometimes you’ll get old geometry still rendering; just click the 'Render' button again, or 'Refresh', to flush the stale IFD and generate a new one.)

Like with the packed primitive workflow above, the generated IFD is much smaller because it references the pig geometry instead of including it:

Motion blur requires Mantra to capture models over an interval of time, thus requiring the geometry at the current frame, and also geometry from at least one other point in time. If you're including the geometry in the IFD file, this will balloon the size of the IFD even more. Yikes!

This example will show how referencing external Alembic animation caches allows us to use motion blur while keeping the IFD small.

Open the example .hip file, and select the object called alembic_bear. The object itself is pretty simple, with only a plastic material. Inside, an Alembic SOP points to the external Alembic file. This is very similar to what we did with Packed Primitives in the previous section.

Navigate to the /out network, and select the ROP called mantra_alembic_bear. On the Rendering tab, Geo Time Samples is set to 2. Because we're using an external Alembic cache, this parameter tells Mantra to sample the same cache at two different points in time, but it doesn’t have to copy the geometry to the IFD.

If you render this node, the bear has proper motion blur. You can compare this to the other motion-blur ROPs that don’t reference external files: mantra_bgeo_bear and mantra_bear_vel. The mantra_bgeo_bear node is simply rendering bgeo geometry, thus for each Geo Time Sample, a copy of the geometry is included in the IFD. The mantra_bear_vel nbode also uses BGEOs, but has velocity baked to the points as the v attribute.

All three nodes render a motion-blurred bear, but the sizes of the IFDs the produce are very different:

Because the bear only has 626 points, the differences aren’t as dramatic as with the Pig IFDs. But you can still see a significant advantage to using the Alembic cache. And as the geometry gets more complex, the advantage only gets bigger.

(You can also generate per-frame .bgeo files of Packed Primitives to get light-weight IFDs, but your farm’s network IO capabilities might be less overwhelmed by a single Alembic cache. This isn’t going to always be the case – every network is different. But if renders seem to pick up slowly with one type of geometry, try using the other.)

See also:

• Alembic files

• Alembic Geometry SHOP

• Rendering with a large number of polygons