USD Frequently Asked Questions
- What is USD and why should I use it?
- What programming languages are supported?
- What file formats are supported?
- What file format is my .usd file?
- How can I convert USD files between binary and ASCII?
- What data types are supported?
- What does a USD file look like?
- What happens to "overs" when their underlying prim is moved to a different location in the scenegraph?
- What's the difference between an "over" and a "typeless def" ?
- Why Isn't Python Finding USD Modules?
- Why Isn't the Maya/Katana/Alembic Plugin Being Built?
What is USD and why should I use it?
USD stands for "Universal Scene Description." It is a system for encoding scalable, hierarchically organized, static and time-sampled data, for the primary purpose of interchanging and augmenting the data between cooperating digital content creation applications. USD also provides a rich set of composition operators, including asset and file references and variants, that let consumers aggregate multiple assets into a single scenegraph while still allowing for sparse overrides.
See the Purpose and Overview section of the USD documentation for a more detailed discussion of what USD is (and isn't).
What programming languages are supported?
USD consists of a set of C++ libraries with Python bindings for scripting.
What file formats are supported?
Out of the box, USD includes a human-readable ASCII file format ("usda") and a binary file format ("usdc"), also known as Crate. It also includes support for reading and writing Alembic files. Users can extend USD to read and write from other file formats by writing a plugin that will translate the data in that format to the USD scenegraph.
What file format is my .usd file?
USD files created with the plain .usd extension, can be either binary-backed Crate files, or ASCII-backed files. This can be advantageous in certain scenarios; for example, if one has USD files which contain references to plain .usd assets, those assets can be converted between binary and ascii without changing the sources which refer to them.
How can I convert USD files between binary and ASCII?
Alternatively, one can convert files using the explicit file extensions, such as usda and usdc, directly.
For more information on USD file formats, see Converting Between Layer Formats.
What data types are supported?
See the Basic Datatypes for Scene Description section of the USD documentation for a complete list of supported data types.
What does a USD file look like?
Here's an example using references, inheritance, and variants. This is the representation generated by the ASCII file format.
This example is purely illustrative. It does not make use of all of the composition operators that USD provides and should not necessarily be taken as a model for how assets should be structured. Different users have different needs; USD simply provides the data encoding and composition operators and lets users decide how best to construct their assets.
The USD Tutorials page contains more examples as well as demonstrations of how to construct those examples using the provided APIs.
What happens to "overs" when their underlying prim is moved to a different location in the scenegraph?
USD provides the ability to provide sparse overrides for assets that are brought in to the scenegraph via one of the various composition operators. These overrides are referred to as "overs." For instance, consider the following example involving sublayers:
In this example, the book defined in sequence.usda has the title "Toy Story". However, this layer is brought in to shot.usda via a sublayer statement, and the book's title is overridden to "Wall-E." The question is: what happens if a user independently working on the sequence.usda file moves Book_1 to Desk, or if Book_1 is renamed to Video_1? In such a case, the "over" in shot.usda would be orphaned and be ignored in the scenegraph for shot.usda. It is the responsibility of the user working on sequence.usda to ensure that shot.usda is updated to avoid this problem.
What's the difference between an "over" and a "typeless def" ?
In a lot of usd files, I see something like:
Since we're not saying what type of prim "MyModel" is at this level, why isn't it just
Answer: When you def a prim, you're providing more information to the system than when you over a prim.
- def means "Even though I may not be declaring a typed prim in this layer, by the time the UsdStage has finished composing, I expect a type to have been provided by referenced/layered scene description" (in the example, presumably the type would be provided by the layer targetted by the payload arc.
- over means "If some referenced layer happens to define this prim, then layer the information I contain onto it; but if not, just consider this information ancillary"
This distinction is actually used in the Usd core to define, for e.g., default stage traversal behavior, as UsdPrim::GetChildren() only iterates over a prim's defined children (regardless of whether they possess a type in the current view of the stage), skipping prims that are just over.
Why Isn't Python Finding USD Modules?
If you get an error message when using USD's Python bindings like this:
This is caused by your PYTHONPATH environment variable not containing the USD modules. To fix this, simply add USD's Python libraries:
Where USD_INSTALL_ROOT represents the CMAKE_INSTALL_PREFIX set in your build configuration. See Advanced Build Configuration for more information.
Why Isn't the Maya/Katana/Alembic Plugin Being Built?
Each plugin USD ships is off by default in the build, to enable any of the plugins, simply activate the following flags in your CMake script, presuming you have the required dependencies.
See Advanced Build Configuration for more information.