Reference

If you get the error, unable to find layer file or cannot determine file format, try placing quotes around the location, even if its relative. Such as "$HIP/usd/usdScene", where the quotes ARE included.

SOP Import

When initially using the SOP Import node, you may notice an warning saying that the imported SOPs have no saved path and that the layer will be output to a file path based on its Houdini path. You can avoid this if desired by explicitly defining the Later Save Path via the parameter. You can always edit this later on via the Configure Layer node

The attributes "name" and "path" are protected. If geometry other other types of data possess these attributes, it will affect the hierarchical relationship of a data's path. Important to note, that if the name/path is relative, by containing a "/" in front, it will automatically assign that as the path. For example if the name is "/box", it will automatically create just the "box" on the highest level. However if the name was "geo/box", you would instead get "sopimport/geo/box", or whatever you have named the sop import node. This is useful to define hierarchies in the sop step.

A useful attribute to set at the SOP level is the "usdpurpose" primitive string attribute, which can control the purpose of the corresponding USD prim. Value set should be one of the following, "default", "render", "proxy", "guide".

"Class" primitive

The class primitive type is a special primitive that is not composed in the scene by default. It is skipped unless it is specifically asked for by one of the child primitives.

SOP Import

• You can change the Import Path Prefix from /$OS to anything you want if you want more control over the scene hierarchy.

USD Primitive: Any element in your USD scene. Each primitive can perform a different function. Primitive Type: The type of primitive defined by its function in the scene, Camera, Lights, meshes, materials. Xform: A parent primitive which can be moved around. Any primitive which is a child of an an xform will inherit the transformation from the xform. Scope: A parent primitive which cannot be moved around. Useful for organizing your scene and nesting primitives within other primitives. Sublayer: Imports from USD files or other LOP node chains. Most basic way to add USD files to the scene. Primitive kinds: A tagging function of USD for defining the use of a primitive within the scene.

Component: a single asset which is not made up of other assets. Eg: a door, a leaf, a window. Assembly: An important compiled asset made up of various other assets. Eg: A house made up of windows, doors, walls ect. Groups: Arbitrary groupings of other primitives. This can be a parent to any set of familial or similar components/assemblies.

Packed Primitives

• By default Solaris will create instances of the primitives, this can be changed via the Packed Primitives option under the Primitive Definition.
• For heavy amounts of packed primitives, under the Primitive Definition you can change Packed Primitives to Create Point Instancer. This generates a point cloud to copy the instances to. Blue text in LOPs and Solaris context means that they are instances of an object (often referenced from the Prototype primitive). This reuses memory but can have individual transforms.

Variants: Variation of an asset saved within the asset. Variations can be geometry and/or material based.

Component builder: 4 Different nodes that

1. Brings in geo
2. Brings in materials
3. Assigns materials to components
4. Outputs to disk as USD. Under the advanced settings, there is the "Geo Variant Name", it will by default set to $OS,can be useful to name the node to assetName_variant. The component node can also include lights and other primitives.

Reference node: Reference the contents of an external USD file/or layers created by other LOP nodes into a branch of the existing scene graph tree. Can also remove or replace existing references.

Component Geometry Variant node: Add all of the component geometries into a single variant set. Explore Variants node: Vizualise, set or extract variants on a primitive.

Instancing is when you only store one asset into memory, but then you copy it to various points. You can apply transformations to instances.

In Solaris there are 2 main nodes, the instancing node and the layout node. Layout node:

• Use the layout asset gallery. Useful to have the thumbnails.
• Under the layout asset gallery, you can create a new asset database to hold the assets.
• You need to drag over the assets from the data base into the layout node.
• The layout node by default will instance. This is good and speed and performance. This can be change to instanceable reference, to allow changes, like switching different variants.
• The Flush Data After Each Frame parameter controls whether it writes the data out after each frame is generated. This can also be used to create individual files.
• The USD Stitch render node can be used to merge USD files representing individual frames by composing them.

Instancer node:

• You can dive inside the instancer node grab the surface primitive. Inside the node it can be unpacked (unpackusd node) to draw/ create attribute masks which can be fed into the scatter align, or copy and points ect nodes.
• After generating the point information, you can use a reference node to copy to the points.
• If you want to create variation you can use the explore attribute node to duplicate the variants onto the same location (at origin), then using a collection node to create a collection of the variants to be used in the instancer.
• Collection takes all of the inputs and assigns a collection name to it. Don't forget to use an * to include all of the children in the primitive component.
• Under the Prototype tab, select the collection in the Prototype Primitive drop down, and then under Options disable Only Copy Specific Prototype Primitives.

The layout node is for a bit more manual placement, the instancer node is for some more procedural or point cloud placement.

Primvars: All of the defining features that exist on a primitive (normals, uv's, point position). You can create custom primvars. Some attributes, when brought in get changed to a specific USD name. For example, Cd gets changed to displayColor. Some main changes,

• Cd = displayColor
• N = normals
• P = points
• uv = st
• v = velocities Custom attributesl retain their names.

To keep USD small, only changes to USD files need to be tracked. For example, for a material saved via Material X to disk in USD any of the default shader values don't need to be written to disk, only if they are changed.

Material X

• At its core, Material X allows you to create materials that can be used in a wide range of render engines.

Simulations in Solaris

• Using the SOP import node you can bring in the simulation. Useful to create a prefix path, called /sim to organizer a bit better.
• Make sure to set the pscale before importing (if not it can default to 1).
• Important to clean the simulation (delete unused/non-important attributes) before importing.
• When saving out with the USD ROP you set the Valid Frame Range to the frame range that you want. However, in the Output File there is no need to use the $F to denote different USD files per frame as the USD file will contain them all. If the simulation is very large it can be advantageous to save out each frame as its on USD file for optimization and readability.

Redshift

Activating Motion Blur

To activate motion blur with Solaris for Redshift there are a few steps you have to go through.

1. Ensure there are velocity attributes on points
2. Under the rendergeometrysettings node, enable velocity blur.
3. Make sure that under the rendersettings transformations and shutter are activated (although they don't have to be it is useful for control)
4. Main shutter speed is controlled on the camera level under the sampling tab with the shutter open and shutter close parameters. TIP: You can also adjust the length of the blur by changing the Frame Duration (which will leave the "shutter" open for longer if higher, causing more blur or less if the reverse) and the Deform/Particle steps tab, these will produce more accurate interpolation, which may not always be wanted. These can be found under the rendergeometrysettings.

Snap Shots

Using the Render Gallery feature you can take snapshots of the viewport to view for later, as well as to act as a scene state. If you are using ACES and you want to save out a simple test render, you need to change a few settings when saving (accessed by right clicking on the image in the Render Gallery viewport). Color Space: Bake to OpenColorIO Display/View OCIO Display: sRGB - Display OCIO View: ACES 1.0 - SDR Video These settings will ensure the saved image matches the viewport.

Lighting

To use textures (or ramps) in a light, you can directly place the texture in the "Texture" parameter under "Base Properties". However, this is also another way specifically for Redshift. You can create a RS Light Shader, and then under the Redshift tab on the light assign the material to the light shader path.

SOP Based USD files

You can get the warning "The layer imported from SOPs has no save path set. The SOPs node's layer will be output to a file path generated from its Houdini Path" You can get around this by turning on the Layer Save Path in the SOP import node. A good string to put in can be $JOB/geo/$HIPNAME.$OS.usd

This is critical to understand, if we don't direct the layer save path, it will by default save the model information into a USD file. Where really we should be saving the reference to the USD file on disk, that way we can make changes easier.

USD in TOPS

If using the USD Render File node, make sure to navigate to the Husk Options, and under Other Delegate turn on Redshift. You may have to override the output for the Main EXR in the USD Render File in the TOPENT.

Variants

• A way to store versions of child primitives on their parent.
• Variant Set: Contains individual variants that a user can choose
• Variants are Flexible: Swap material, geo, change the child hierarchy
• Should be store on the root prim of the asset: Allows the variant selection if marked as instanceable or payload is unloaded.
• They don’t change the namespace down to the prim that owns the variant set For example “/geo/forest/tree/model”, tree can change /model but not above itself Use cases
• Families of geometry
• Levels of detail
• Material Assignments

Create LOD

• Set the primitive path
• Variant set
• Variant name root (creating the prefix)
• Allows you to create as many LOD as needed
• By default this isn’t really a USD way of working, as if you were to write this out, the usda file would contain the information for each LOD explicitly instead of referencing it.

Set Variant

• Sets a primitive to a specific variant

Add Variant node

• First input is the stage, second input is all the prims to add to a variant
• Creates the primitive path for where the variants are going to live Add variant to existing
• Acts as a for loop, will allow you to add variants to existing prim Configure Layer Node
• Acts as a control panel for shaping USD layers
• Allows you to designate a defined path to save out

Asset Structure Guidelines

Assets are called models in USD Component models are published assets that keep their geo behind a payload Assembly models are publishable assets which reference components or other assembly assets Published component and assembly models should inherit from a class primitive.

A component is the most basic asset published in USD

• Always on the root “xform” prim
• Payload makes geometry deferrable
• Not referencing external models, saved into one spot on disk
• Inherits from at least one Class prim

Simple Component With Purpose Scope

• There is no need to mark every primitive with its purpose (Just the parent primitive)
• You could define the purpose to be Purpose: proxy and Purpose: render, to help with optimizing scenes.

Scene Assembly

• A published asset with aggregates other published component or assembly models together
• Intermediate xforms use the group kind
• Payload arcs don’t provide benefits when the exist with components.

If you want to use a switch node to control which prims are used, just have it target a specific path and use the switch to control what goes into that path. For example, the renderSettings node reads the desired camera as /camera, instead of /camera/main or /camera/secondary. This way whatever is in the /camera is what is used.

Simple assembly with materials and new geo

• Could override materials on individual components with materials in different scope
• When new geometry is needed, store it behind a payload and give it the component kind.

Variant Layers

• Variants can be store as separate files or all in one layer
• One File: Simplifies file management, reduces number of layers USD has to track
• Multiple: Maybe easier for tools or pipelines to handle, ex) Layout LOP in Solaris

The name attribute will change the name of the mesh The path attribute will designate where it should exist in the hierarchy

Reference prim path

• Allows you to bring in specific branches
• However if not careful, the prim path can get messy

Sublayer node brings in the whole file Reference node brings in specific prims

Asset Reference

• In addition to being able to reference in USD files, the Asset Reference also contains the ability to transform its contents.
• It also allows you to bring in variants Payload
• Allow you to unload assets from viewports, a special type of reference designed for optimization.
• Has a weaker opinion than a Reference
• When we unload the a Payload the stage will not load anything in the file being “payloaded”
• We can write a lightweight description of the contents (AssetInfo, Variants, Bounding Box) in order to know what is not being loaded into the scene
• They main asset loads the payload, the payload then loads the geo and material.
• You can unload the payloads by going into the scene graph tree, clicking the mask and selecting unload payload
• If you want to single out for loading/unloading, you can flag the L column in the scene graph tree
• Using the same mask button, you can select Create Configure Stage Node From Load Mask, which will create a node containing the information for which files to payload.

Stage Manager

• A bit of a different User Interface, nice for file navigation
• You can use the stage manager to reorganize hierarchies, and add new primitives to organize the stack
• It also has transform controls per primitive
• Allows for variant setting and payload management
• You don’t need to start from scratch, you can use it to reorganize paths from nodes above itself
• This node modifies the data in the scene graph tree. The edits are saved in the HIP file, not the USD file itself.

Primitive LOP

• From the path parameter box you can create a bunch of different primitives and paths

• Useful for creating an empty scene hierarchies

• Parent primitive type sets anything that isn’t a leaf primitive

• Primitive specifier: Define: Defines the primitive (sets what it is), Over: Override that is coming into the hierarchy, if we place this on top of another primitive it will override it, Class: A primitive from which other primitives inherit properties

XFORM VS TRANSFORM LOP

• Transform lop: Bring in primitives and do transformations on them
• Xform LOP: It can transform primitives as well as create an empty transform primitive, it also has the option to change to edit and act as a transform node.

Schema’s

• Same thing as a type on a primitive
• Ex_ Meshes, Lights, Cameras, Shaders
• Defines the supported properties Attribute renaming
• Common attributes are renamed
• P > points
• N > normal
• V > velocities
• uv > st

Primvars

• Collect properties that are not in the schema
• shop_materialpath > primvar:shop_materialpath
• Catchall for anything not defined in the schema

Moving from LOPS to SOPS

• LOP Import Camera: Allows you to load your camera in from solaris.
• LOP Import: Allows you to bring primitives into the SOP context. This brings info in as a packed USD, we can use the unpack USD node to break it down further.
• The traversal option will determine where it ends the search to load the asset in. You can break up the single packed USD into more packed USDs if needed.
• If you want to access the polygons, under the unpack section choose polygons as the output.

Layers

• Layers in USD are files on disk, or sections on scenes that we have partitioned out in memory and we will write out later.
• The scene graph layer panel allow us to view the layers
• Colors around nodes define the different layers (randomly assigned)
• Implicit layers: Houdini will determine the best way to save it to disk.
• Flatten Implicit: Puts it all into a single flat USD file.
• Separate Layers: Keep layers separate into individual files.
• Using merge nodes can help us layer things when working in memory (some caveats when referencing or sublayering data in)
• The merge node has an option for merge style to identify how the layering should occur.

Configure Layer SOP

• Allows us to control layer breaks and designate where layers are saved to disk.
• Most importantly, use this note to save the file path to disk, establish the default primitive location, what to do with input layers (flatten them, ect) and whether or not to start a new layer.
• Set input active layer to explicit defines an explicit save path.
• Often no need to flatten if there is only one layer.

USD ROP

• Output processing: Match output layer extension: ensures that any layers that get saved out match the file type chosen for the output file (so they are all USDA, USDC ect)
• Output processing: Use relative paths: Ensures that all paths are relative
• This will sublayer in each layer into the USD Master file.

Sublayer

• You can then reload the files as a sublayer, either individually or each on its own. Examples of composition
• If you have 2 primitives that share the same name, and occupy the same location in the stack, the lowest version down will overwrite previous versions

Variants

• To create a variant, drop down an "Add Variant" node. The variant set is the name that will appear when right clicking on the asset in the scene graph tree. Very important, the variant source primitive section defines the root path of the primitive that should be copied for each variants input. That is to say, you need to set this to the primpath location for each variant. So if you have 5 lights, and each lights prim path is /light, then you need to set it to /light. If it was 5 pig models stored at /pigModel/1, /2, /3, ect, then you would use /pigModel. If not set properly then the variants will not be organized correctly.

Scene Structure & Organization

Graft Branches Takes prims/branches form the second input and attaches them onto branches of the scene graph tree in the first input. Important, this will let you graft any where you want. So instead of having explicitly state for each light to be placed at scene/lights/light1,light2, light3. You can just have them grafted to scene/lights/. This makes it a bit more procedural. To use, on Graft Branches set the primitive path to where you want the graft to get send to ex, /shot, and under the source prim, set the source prim path to just / , as this will take all that is above the graft branches.

Layer Break Simple way to think if it is that anything above the layer break is used for reference only. For example, lets say you had a camera node that was split into a graft branches as the inline, and then a separate chain. If you add a sop create node on the offshot and dive in, you would be able to use the camera inside of the sopcreate since it is fed directly into it. However when when you graft the branch back into main, a copy of the camera would be made. If you put a layer break after the camera, onto the secondary branch, it will read it only as a reference and not get stored.

Reference Can pull in USD files and place them where we want them. The graft branches places data from memory into the tree while the reference does the same just with data on disk. However, if you connect data to the right input, it will use the multi-input options and let you access the data from memory. The scene graph tree will display the data as green, and in the layers tab it will have a little sticky saying it is a reference. This is important because when it gets saved the data will be saved into its only layer. You may want to drop a Configure Layers node so that way you can explicitly set the path.

One downside with this is that a reference may only display one primitive. This is because you cannot reference a root level, so if your data is stored at /box, /cone, /grid. Only one of them would be displayed. To reference all three of the above you would have to connect the network 3 times, one for each primitive, then explicitly define which one you want to bring in on the reference node.

Layering/Composition Arcs Each new layer can override or add new information from the previous layers. The USD term for these overrides are called opinioning. Composition arcs have a strength ordering which determines which takes priority. LIVEPRS, Locals, Inherits, Variant Sets, Reference, Payload, Specialize. This means that references may not override sublayers (locals higher then references). For example, if you have a sublayered box, then a reference with animated transformation data, the transformation won't carry over as the sublayer has its own information about the position information (its own opinion) which is stronger than a reference.

Optimization

Anything that has a green clock badge (time varying), will flow down stream causing every node beneath it to be time varying and cause it to recook on every frame. You can get around this by caching the frames required by either

1. Dropping down a cache node and caching the frames you need (setting it to cache all frames can work as long as the cook isn't too heavy)
2. On the node that is causing the time varying setting the Frame range to "Sample Frame Range"
3. Caching the USD to disk. Note, you don't need to cache the whole stage, you can just cache the area that is causing the time varying.