Modularity and Content Reuse Best Practices

Overview

Re-using and instancing scene description data amongst identical content is a common concept in many DCCs, File Formats, Runtimes and UIs.

There are many reasons for this, such as workflow benefits:

  • Centralized editing / DRY: Avoids duplication/repetition of effort

  • Catalogues & Object Libraries: Content reuse can enforce that a particular type of object is identical to its canonical description in a catalog or library.

  • Broadcasting of changes: Efficient propagation of identical changes to many primitives or objects

Content reuse is also integral to the scalability of an application’s runtime and the feature may be deeply integrated into architectures to achieve high performance.

  • De-duplication of Transform, Geometry, Material and Texture data optimizes storage, system memory (RAM) or video memory (Vram)

  • Sharing of duplicate Scene Graph data (prims, prim hierarchies) speeds up traversal based processes such as scene loading or scene translation for rendering.

When working with OpenUSD, these concepts may seem intuitively familiar from other systems / domains, but they may be have different meanings and behaviors.

Modularity, the Model Hierarchy and “Assets”

Modularity and Content Reuse are some of the defining benefits of OpenUSD and the Composition Engine, the “model hierarchy” and instancing are some of the enabling features.

The model hierarchy is used to annotates important prims in the stage. The “Component” and “Assembly” kinds in particular are used to denote encapsulated, modular and referenceable packages. When composed, the model hierarchy forms a useful index of stage contents which may be preferrable to deep, complex and unstructured prim hierarchies.

These properties make the model hierarchy a great companion for OpenUSD instancing, as instanceable prim hierarchies need to be encapsulated and become read only, which are often desirable properties for reused, modular model hierarchies.

The term “Asset” is also frequently used to describe such ecapsulated structures, reflecting its real-world connotations and serving as an intuitive descriptor for modular setups. This document employs the term “Asset” regularly, specifically to denote OpenUSD structures characterized by having either “component” or “assembly” model root prims.

Topics

Next: Content Reuse