Assembling USD Composition Arc

For this demo, I use asset exported from Speedtree.  

A palm tree asset with:

• 3 base shape seeds (A, B, C)

• 4 wind variations per seed (Static, Calm, Breezy, Storm)

• 2 seasonal looks per seed (Summer, Winter)

Total = 24 unique combinations (3 × 4 × 2)

For preparing the asset I use opensource software Gaffer.  

Gaffer is a free, open-source, node-based VFX application.

"When you're working with any 3D assets or models, almost all the time you'll need to do two basic cleanup tasks:

1. Fix or organize the attributes (like materials, properties, or metadata) attached to the objects

2. Rename the primitive objects (the basic building blocks like meshes, curves, or groups) to follow proper naming conventions"

In USD (Universal Scene Description), certain components are designed to work together in pairs:

• A "render" component

• A corresponding "proxy" component

In this setup components are:

• Geometry Subnames: render (geometry) and proxy

• Animation Caches: render (geocache) and proxy (proxycache)

• Render Shaders: full material and preview variant

Texture management often becomes a complex, time-consuming process due to varying naming conventions across digital content creation tools and renderers. To streamline this workflow, I've implemented an OpenPBR Surface standardization approach. The texture publish template simplifies the process by providing predefined OpenPBR plugin names, allowing artists to simply place textures in the appropriate file selectors. This method generates two texture sets: one for rendering and another for proxies, reducing manual configuration and potential errors.

The composition is generated using Python USD modules, creating a variant selection with subnames "A", "B", and "C". Each cache is integrated as a USD clip, defaulting to a loop between frames 900-2000. Render and proxy prims inherit shader variants for "summer" and "winter" scenarios. USD collections are established to organize caches and shader primitives.

Templates enable artists to efficiently organize and integrate Speedtree data. Proper file layering requires preliminary cleanup before publishing. The publishing node features four input ports: "render", "proxy", "render_layer", and "proxy_layer". It supports three publishing categories: geometry, geocache, and material. Artists must carefully validate subnames and configure variant names to ensure accurate data integration.

For managing the pipeline I’m using Ayon.

Ayon is a robust open-source pipeline for studios and remote teams.

Components are published to Ayon, facilitating streamlined review and version tracking. 

Using the Ayon API, I query USD component names and file paths to compile the final composition arc. The result is a .usda file published into the Ayon pipeline as an asset assembly, ensuring systematic asset management and integration.

The asset remains self-contained within its root folder, leveraging Ayon for review and version management. All textures and components are loaded using relative paths from the publish folder, enhancing cross-vendor and cross-platform shareability. The Speedtree asset is now prepared for layout and rendering.

Workflow testing across Houdini, Gaffer, and Omniverse exposed shader nuances. The current demonstration uses 3Delight shaders for primary materials and USDPreview for previews. The optimal approach would be using a universal PBR material capable of translating seamlessly across major render engines. MaterialX and OpenPBR emerge as promising solutions for achieving this renderer-agnostic material workflow.

In Houdini's Solaris, variant collections enable dynamic selection of tree variants. Wind-specific seed variations are scattered and exported as USD instancers.

Omniverse, as a native USD platform, inherently reads USD compositions. Leveraging Omniverse Kit's OpenPBR implementation in MaterialX, the next objective is to explore and validate a renderer-agnostic material workflow, ensuring seamless material translation across different rendering environments.