<aside>

Part 1 Part 1 — Essential USD/Solaris Attributes — Preparing Geometry for Solaris 🟢

Part 2 Part 2 — HDA Solaris USD Prep Stage 🟡

Part 3 Part 3 — HDA LOP Scatter with Proxies 🟡

Part 4 Part 4 — HDA Solaris Master Material v1.01 🟢

Part 5 Part 5 — Karma and USD Render Visibility (Not the same) 🟡

</aside>

The Workflow - CRUCIAL

When preparing geometry for Solaris, attributes help determine how geometry is identified, organized, and interpreted when translated into USD.

The basic workflow:

1. Identify geometry pieces and assign a variant ID.
2. Generate a name for each piece.
3. Assign a usdpurpose to each representation. Render or Proxy.
4. Generate the path.
5. Export the geometry to the stage.

<aside>

$$ \begin{gathered} \text{i@variant} \\[4pt] \downarrow \\[4pt] \text{s@name} \\[4pt] \downarrow \\[4pt] \text{s@usdpurpose render/proxy} \\[4pt] \downarrow \\[4pt] \text{s@path} \\[4pt] \downarrow \\[4pt] \text{Export} \\[4pt] \end{gathered} $$

</aside>

1. Generate i@variant

<aside>

The i@variant attribute gives you a consistent numeric identifier

</aside>

The variant attribute is an integer identifier that can be used to distinguish geometry variations in a procedural workflow.

For example, a collection of different leaf meshes that later can be scattered on points.

Option A — Enumerate SOP

Use an Enumerate SOP to generate sequential integer IDs. Configure the enumeration and attribute class according to how you want the geometry to be numbered.

Option B — Connectivity SOP

Use a Connectivity SOP to identify connected components and assign an integer attribute to each component.

Important distinction: Enumerate assigns numbers according to its settings, while Connectivity identifies connected components. They solve different problems, so choose the method that matches your geometry and workflow.

2. Generate s@name

<aside>

Consistent s@name make easier to identify, organize, and manage geometry.

</aside>

The name attribute identifies geometry pieces and can help determine how geometry is organized.

A useful approach is to generate the name from the variant ID.

For example:

s@name = "Grass_" + itoa(i@variant);

If i@variant is 2, the resulting name is Grass_2.

This creates a consistent naming convention:

• Grass_0
• Grass_1
• Grass_2

Alternative — Name SOP

If you don't need to generate names from variant IDs, use a Name SOP to assign names directly to geometry pieces.

3. Generate s@usdpurpose

<aside>

The usdpurpose attribute communicates the intended purpose of a geometry primitive when the SOP Import workflow translates it into USD purpose metadata.

</aside>

For example, on the render branch:

s@usdpurpose = "render";

On the proxy branch:

s@usdpurpose = "proxy";

The main purpose values are:

<aside> ⚠️

The representations must actually exist. Assigning render or proxy alone does not create create the proxies.

</aside>

Bonus: Create the Render and Proxy Representations

<aside>

</aside>

A common USD workflow uses separate representations of the same asset for different purposes.

• Render geometry: The detailed geometry intended for final rendering.
• Proxy geometry: A simplified representation that can be used for efficient viewport display.

For example, a detailed tree could have a high-resolution render representation and a simplified proxy representation.

Depending on your setup, this may involve applying different operations to each branch.