Practical USD: Geometry [1/4] (Patreon)

Welcome to Practical USD, my new series exploring how you can make a complete USD pipeline work for you! We'll cover every important USD feature: storing and modifying geometry, building scenes, working with layers, instances and variants, and much more.

For interacting with USD files I'll be using Nvidia Omniverse USD Composer. It's a faithful implementation of USD and is free for anyone to use. To set it up, install the Omniverse SDK from the link and install USD Composer from the Exchange. You can of course use Houdini Solaris, Maya USD, or any other app you prefer.

To kick things off, let's look at the basics of USD as an exchange format and how geometry data is understood by USD.

Most 3D apps and DCCs support import and export of USD these days. When we save geometry as USD we're usually talking about .usdc (binary or "crate" format) and .usda (human-readable text format). The .usd extension can refer to either, but in practice it usually means binary. There is also .usdz, a multimedia container that is mostly associated with Apple devices.

Next, let's define two very important USD concepts: stage and prim.

A stage is where all of our stuff goes. It's an apt word (compared to some other inscrutable USD terminology): a stage is a place to put props and actors as we create a scene.

A prim is, basically, a thing on a stage. A cube is a prim, a light is a prim, a shader is a prim, even an empty container is a prim. (This is different from the traditional definition in 3D of a primitive being a basic geometric shape like a plane or torus.)

Armed with this knowledge, we can build a stage with a simple prim in a text editor. The following lines create a default cube:

#usda 1.0

def Xform "practical_usd" {        def Cube "cube"            {            }}

An Xform (transform) is a container prim that can be positioned in 3D space. The def specifier simply means we're defining something on our stage.

Save this as .usda and then open the file in USD Composer (or your app of choice).

This simple USD cube is missing a lot of standard 3D geometry data, so let's make a cube in a full DCC (I'll use Blender here) and export to .usda. Open that file in a text editor and we can see how much extra information is included. We now have UVs, normals, vertex data, and more.

Import this new cube into Composer and we'll be able to view the geometry and browse through all its attributes.

What is an attribute? It's a name and value (or set of values) that describe an aspect of a prim.

We also see a few attributes using the primvars:name syntax, such as primvars:UVMap in this case. A primvar is a special kind of attribute that is often intended for rendering-specific data.

Since all these attributes are so clearly delineated in a .usda file it's actually possible to manually modify geometry outside of a DCC. For example, in many cases a simulation or groom will leave behind a vast number of attributes that are useless for the rest of the scene creation and rendering process. You could simply open up the USD file in a text editor and delete the relevant lines. Even in the case of our Blender cube we've got a bunch of extraneous stuff. The primvar primvars:sharp_face is likely unnecessary, as is all the metadata telling us the cube was made in Blender.

You can also add attributes and primvars to existing geometry. You could change the vertex color, specify subdivision scheme, toggle double-sidedness and more. We can make our Blender cube red by adding:

color3f[] primvars:displayColor = [(1, 0, 0)] (    interpolation = "uniform")int[] primvars:displayColor:indices = [0, 0, 0, 0, 0, 0]

This type of manual modification will start running into problems with extremely large files as most text editors will grind to halt loading too many characters into memory. It's easy enough to make these same changes in any DCC; they're just GUIs for the concepts we've talked about. Setting the cube's color to red in Maya and exporting will add the same lines of text that we did manually.

Editing on this level isn't something you want to do without careful consideration in each situation, but it's sometimes a quick and easy way to improve file size and memory usage.

Let's load up a more complex shape to see how it looks. This is some fur I created for a honey bee model. It has all the attributes needed for rendering, such as UVs (traditionally stored in USD as primvars:st), and root to tip taper on each hair (widths). In other geometry you might find attributes like velocity, radius, lifespan, and more.

USD's ability to expose every single bit of data like this is very powerful. Many advanced techniques can be more easily implemented thanks to having quick access to the building blocks of our geometry.

Conclusion

Great! We now know what stages, prims, Xforms, attributes and primvars are, plus have a good basic understanding of how USD stores and interprets geometry. Even if you're not using a full USD pipeline I still recommend using USD as an exchange format. It's robust and modern and there's no downside in adopting it.

Next, well move on to creating a complete stage populated with geometry, using some more advanced USD features. Check out Part 2!