This USD Create Component SOP is the centerpiece of the tool set. When you add the node, you will see four colored inputs for different requirements:

Input	Description
Default/Render	This is input is required and typically contains the hi-res geometry for the final render.
Proxy	This input is optional and normally contains a low-res version of the geometry for accelerating the viewport. The USD Create Proxy Geometry SOP provides a fast way to create this type of geometry.
Sim Proxy	This input is optional and can contain special guide geometry for physics tools like the Edit LOP.
Subcomponents	This input is optional and contains subcomponents that will be “merged” into the main component. The USD Create Subcomponent recipe is a convenient way to create USD-compliant subcomponents.

You can create the USD Create Component operator inside any SOP context, for example a Component Geometry LOP, a Geometry OBJ, or a SOP Create LOP.

To create the hi-res render version, you actually only have to connect your geometry to the component node’s first input. This will already create a complete component definition. However, we strongly recommend to define a meaningful Name. By default, the component’s name is taken from the operator’s name with the $OS token. So you can either change the node’s name or override the Name parameter’s current entry.

• The Kind dropdown menu lets you choose whether you want to create a Component or a Subcomponent. Other kinds like group or assembly are not supported.

• The Type will be an Xform in most cases.

Back on the Solaris stage you can see the typical tree-hierarchy in the Scene Graph Tree with a render primitive. If you create the component inside a SOP Create LOP or import it with a SOP Import LOP, you’ll notice that the tree contains another, higher-ranking component. This extra level is added from the nodes' Import Path Prefix. If necessary, you can simplify the tree hierarchy there.

Since there’s no proxy geometry defined, the render primitive will be used for rendering, viewport previews, and simulation.

Especially with heavy geometry and large scenes, proxies are a common means to accelerate viewport operations. You can choose from several methods to create proxy geometry.

One way is to turn on Create Proxy from First Input directly on the component node. Now you can choose from two Style options for the proxy: Box and Convex Hull. The first one creates a simple bounding box around the original object, the second menu entry calculates a more complex, yet very reduced version from the input geometry. In the SOP Visibility section, you can choose, which version you want to see in the SOP viewport - Proxy or Render.

Another method uses the USD Create Proxy Geometry SOP at the component node’s second input. When you connect the proxy node, turn off Create Proxy from First Input. The proxy operator’s functionality is the same as on the component node.

Finally, you can also use nodes like the Poly Reduce SOP. This node boils down the number of polygons with a Percent to Keep parameter. The big advantage over the “create proxy” methods is that Poly Reduce tries to maintain the hi-res object’s original shape as good as possible. If you choose to work with polygon reduction, we recommend adding a usdpurpose=proxy (string) primitive attribute to the processed geometry, for example with an Attribute Create SOP.

When you return to the Solaris stage, you’ll find a proxy primitive in the Scene Graph Tree. The proxy geometry will also be shown in the viewport, but when you render the scene, you’ll see the hi-res object.

The USD Create Component SOP is not only capable of handling single objects, but also instances. The node will use the input geometry as a prototype and create the same memory-efficient structure you might already know from USD tools like the Copy to Points LOP or the PointInstancer LOP.

Inside the SOP context, you can use a point source like the Scatter and Align SOP and the Copy to Points SOP to scatter the objects.

• Once you have set up your scene, terminate the network with a USD Create Component SOP.

• Now, turn on Instanceable. This option creates a Prototypes branch on the stage and assigns the copied geometry.

• Also set Kind to None or Subcomponent, as the parent Prototypes primitive is already of kind component. Nested components create a warning, although the scene can be rendered.

The Packed Geometry Setup dropdown menu defines how the instances will finally appear. In many cases you’ll choose from two options.

• The default Create PointInstancer schema should be the preferred choice when you have to deal with vast amounts of instances.

• With Create Native Instances you’ll generate a single “prototype primitive” that will efficiently represent many copies of an asset. Native instances are actual transforms on each instance, and the instances are represented in the scene as unique namespaces.

When you turn on Prototypes Destination, you can change the default Prototypes primitive name in the Scene Graph Tree.

Note that proxies are considered as well. When you connect some light-weight geometry to the component node’s second input, it’ll be used in the viewport. This can be a true time-saver with complex and heavy prototype geometry! In the final render, however, you’ll again see the original object(s).

The Transform section contains the parameter from the Transform SOP and provides the same functionality.

With instanced prototypes, you’ll transform the entire setup, not individual objects. If you want to transform the prototype, you have to do that with a separate transform node.

If you want to transform the instances, you can do that, for example, in the Scatter and Align SOP’s Scale and Orientation sections. Another way is to define random pscale and orient point attributes.

The USD Create Component SOP also supports subcomponents. This kind is important for hierarchical modelling and lets you split an asset into independent elements. Imagine an animated puppet that’s made of a body with a head, arms, and legs. Instead of having the parts packed into a single component, it’s normally better to use subcomponents. Please bear in mind that subcomponents also support instances.

The process of creating subcomponents is actually straightforward and we recommend using the USD Create Subcomponent recipe. This tool adds a pre-configured USD Create Component SOP to the network. To define a subcomponent, you basically do the same as with a “regular” component. The only real difference is that Kind is set to Subcomponent.

Once you've defined the subcomponent, you can wire it to the USD Create Component SOP’s fourth input. If you have multiple subcomponents, you can bundle them with a Merge SOP.

On the Solaris stage you will now see a more complex scene tree with an appropriate hierarchy. The level of complexity depends on your SOP setup because you can also connect a subcomponent to the fourth input of another subcomponent node.

Materials from SOP geometry aren’t considered or translated. If an object has a material applied, it’ll be converted into a geometry subset that’s grouped under the actual mesh in the Scene Graph Tree. However, this subset doesn’t have any material properties. In contrast to the Component Builder recipe, the USD Create Component SOP does not add a material scope to the asset definition and you need to create materials directly in Solaris.