Content Reuse

The concepts of reuse and instancing are very closely related. Understanding reuse and modularity is a important before attempting to implement successful instancing strategies.

Composition Arcs

OpenUSD’s composition functionality incorporates a variety of composition arcs to support content reuse. These include reference, payload, inherit, and specialize arcs. These arcs enable the composition of prims and their descendants onto other prims, either from separate external layers/files or internally from prims located elsewhere within the same stage.

In both scenarios, prims can be composed multiple times, thereby facilitating content reuse.

It’s worth noting that while composition through sublayering is also a method for reuse, it doesn’t align as closely with the concept as the aforementioned arcs. This is primarily because sublayers are typically used to amalgamate contributions and overrides from different workstreams, departments, or processes through layerstacks. This differs from the composition of modular and composable content.

Internal Arcs

The following arcs are used to compose prims that exist within the same stage onto other prims that also exist in the same stage.

• References

• Specialize

• Inherit

The difference between these arcs lies in their strength (see LIVRPS) and their “composition encapsulation” - reference arcs only evaluate in the local layer stack of the prim which introduces them. In other words, they do not remain “live” within the composed stage and do not update when their target is modified.

Specialize and Inherit arcs on the other hand do remain “live”. This makes them more costly (in terms of performance) but also opens up additional use cases: Just like reference arcs, they facilitate reuse via composition of one prim onto another. But because they remain live, they are also useful in “refinement” workflows. Ie, an application can refine data at runtime by authoring opinions onto the target of a specialize or inherit arc.

External Arcs

Composing prims from external layers is implemented in these arcs:

• References

• Payload

They form the primary building blocks for composition of external layers in OpenUSD (besides sublayers).

Reference arcs are the only arcs which can compose internally and externally. Neither of these arcs remain live like Specialize or Inherit arcs, but they can exist on the same prims as specialize or inherit arcs.

Reuse with point instancers

OpenUSD provides an additional content reuse mechanism via point instancers

Point instancers are somewhat similar to internal references, without requiring separate “anchor” prims for each reuse. Instead, array attributes on point instancer prims hold the paths to the prims which are to be reused, as well as their positions and other attributes. The instances, their properties and their placement is compressed into array attributes.

Point instancers are a lot more compact than internal referencing and may scale to higher instance counts, but come at the cost of flexibility, addressability and legibility.

Just In Time (JIT) De-duplication

At a lower level, there are multiple systems in the OpenUSD data pipeline which facilitate de-duplication of data, without the users needing to take action. Whilst they are not the focus of this document, their existence might steer the decision making process when choosing the best reuse style for a given situation.

• Deduplication of Array data in binary (crate) OpenUSD files.OpenUSD will automatically detect duplicate arrays, for example for point positions on mesh prims, and de-duplicate them. So a OpenUSD file with 1000 identical polygon meshes might only be marginally larger in size than a OpenUSD file with a single copy of the same mesh.

• Deduplication in render delegates - strictly speaking, this is not a feature of OpenUSD itself but needs to be implemented in the render delegate for a given renderer. The Storm render delegate for example de-duplicates primvar data by default. This means that, similarly to the deduplication in OpenUSD, 1000s copies of a mesh may not be significantly more costly (in terms of memory).

• Deduplication by the renderer - a renderer might deduplicate compiled materials for example, after they have been translated and compiled from their OpenUSD description.

Whilst this kind of low level data de-duplication has significant impacts and benefits, it also costs time to compute. This may surface when writing a usdc file with a lot of duplicated data, as OpenUSD needs to hash the data in order to detect duplicates. Similar time costs might occur during scene translation for rendering.

➤ Next: Instancing