usdedit is a simple script that converts any single usd-readable file into its (temp) .usda ascii equivalent and brings the result up in your editor of choice, which is taken from the $EDITOR environment variable. Upon quitting the editor, any changes to the temp file will be converted back to the original file's format (assuming the FileFormatPlugin for the format allows writing), and the original file's contents will be replaced with the edited contents.
usdedit foo.abcworks as an alembic editor (in USD schema) for all elements of the alembic file that our translator currently handles. As we do not yet cover all aspects of the alembic schema, however, please be careful and do not usdedit an alembic file being used as a source file, since the roundtripping is lossy!
- Running usdedit on a very large file with lots of dense, numeric data may take a long time, create a really large ascii file in your temp area (wherever python's tempfile package decides to put it), and may push the boundaries of your editor's scalability.
- The mulit-file input to usdcat does not perform any kind of merge of the content in the separate files (and there is no such utility to do so, yet... parameterizing that problem is an interesting challenge!); it simply dumps the contents of each file, sequentially.
- The --flatten option uses UsdStage::Export(), which, as one might expect, "bakes in" the effects of all composition operators, simultaneously removing the operators themselves, in the result; this applies both to namespace operators like references, sublayers, and variants, and also to value-resolution operators like layer and reference time offsets. Flattening a stage does preserve USD native instancing by flattening each master into the generated layer and adding references on each instance to its corresponding master. Thus, the exported data may appear structurally different than in the participating source files, but should evaluate/compute identically to that of the source files.
usddiff runs a diff program on the result of usdcat'ing two named usd-readable files. It is currently quite primitive, with limitations noted below, but even so can be quite useful.
- It does not do any fuzzy numerical comparison. The slightest precision difference will cause a diff.
usdview is the most fully-featured USD tool, combining interactive gl preview, scenegraph navigation and introspection, a (growing) set of diagnostic and debugging facilities, and an interactive python interpreter.
Further Notes on Command Line Options
--renderer : The default, "opt" renderer is the HD (hydra) high-performance renderer developed for the USD project. The "simple" gl renderer is single-threaded, uses simple VBO's to draw unrefined (only) geometry, and is largely used for debugging the "opt" renderer, or for when the underlying graphics hardware does not support the features required by the "opt" renderer. "Simple" also:
- currently does not support intrinsics like Spheres, Capsules, Cylinders, and Cubes
- uses only the main thread
- does not support renderer plugins
- --select primPath : loads and images the entire stage, but selects primPath in the prim browser, and positions the free camera as if one had hit the f ("frame selection") hotkey.
- --mask primPath [primPath ...] : opens the stage in masked mode, restricted to these paths for viewing only a subset of the prims on a stage.
- --norender : if one does not absolutely need the gl visualization of the stage, just access to navigating and introspecting the data, this option can substantially reduce the startup time and file I/O. Expect some errors in the terminal if you should happen to select some of the menu/shortcut options, as we have yet to do a cleanup pass for this mode. Errors should be harmless, however.
- --unloaded : Populates the stage without including any payloads. For a scene constructed of references to models built with payloads, this can create a summary "model hierarchy" view of the scene in a small fraction of the time it would take to compose and present all the prims in the scene. You can then load or unload subtrees of the prim hierarchy using either the "Edit > Load" menu, or the RMB context menu in the browser.
- --numThreads : this will determine how many threads the hydra renderer, boundingBox computer, and other multi-threaded computations will be able to use.
- --complexity : hydra uses OpenSubdiv to refine Mesh gprims whose subdivisionScheme is anything other than polygonal. A complexity of 1.0 indicates no subdivision, for maximum performance and lowest fidelity.
Utility for creating usdz packages from USD compositions and the assets (images and others in future) they reference.
usdchecker attempts to validate a USD or usdz file using a series of rules and metrics that will evolve over time.
usdstitch aggregates any number of usd files into a single file. This process is different from flattening a stage. The key differences are:
- The result of usdstitch will contain the ordered union of composition arcs present on prims in the input sequence of files, whereas flattening removes (by baking in ("flattening") the composed opinions) composition arcs.
- usdstitch merges the TimeSamples from the input sequence of files, whereas flattening preserves the TimeSamples of only the strongest layer that contains TimeSamples, which is consistent with how value resolution interprets layered TimeSamples on a stage.
The goal and purpose of usdstitch is to create a merge of all of its input files, as if each file represents a timeslice of a complete scene, and we wish to merge all the scenes together. This is neither equivalent to stage flattening, as just described, nor will it produce an equivalent result to flattening a LayerStack, which is the process of combining all the (nested) SubLayers of a root layer into a single layer, preserving all composition arcs (other than subLayers) and guaranteeing the same evaluation behavior, thus (purely) optimizing N layers into one. USD does not yet have a tool for this operation.
usdstitchclips is a tool which produces an aggregate representation of a common prim (and all its descendant prims) shared across a set of USD files using the Value Clips feature. This utility will provide a Value Clip representation of the input files, which are presumed to form a sequential animation, determined by the startTimeCode and endTimeCode of each layer in the sequence. It produces two files, as described in the usage output below:
result.topology.usd- this file will contain the unioned prim and property topology and metadata of all the input files - that is, all prims and properties that appear in any of the input USD files.
result.usd- this file will minimally contain the prim hierarchy described by the --clipPath command argument, to host the Value Clip metadata at clipPath. This means that in the resulting composition, all prims at or below clipPath in namespace will receive values from the input clip layers.
result.usdwill also contain a reference, on its root prim (the root path component of clipPath) to the same-named prim in
Note that the animation content of the stitched result is completely dependent on the layout of timeSamples in the input USD files. So, in particular:
- If the input files contain only default values, there will be no animation, as Value Clips only look for timeSample values.
- When the
--templateMetadataargument has not been specified, then the startTimeCode and endTimeCode metadata of each clip layer will be used to determine the time-range over which that clip will be active, and all timeSamples within that range within the clip layer will be consumed.
- When the
--templateMetadataargument has been specified, then the range over which each clip will be active is determined by the required
--templatePathargument, and the two optional arguments
--templatePath: A regex-esque template string representing the form of our asset paths' names. This can be of two forms: 'path/basename.###.usd' and 'path/basename.###.###.usd'. These represent integer stage times and sub-integer stage times respectively. In both cases the number of hashes in each section is variable, and indicates to USD how much padding to apply when looking for asset paths. Note that USD is strict about the format of this string: there must be exactly one or two groups of hashes, and if there are two, they must be adjacent, separated by a dot.
--stride: An optional (double precision float) number indicating the stride at which USD will increment when looking for files to resolve. For example, given a start time of 12, an end time of 25, a template string of 'path/basename.#.usd', and a stride of 6, USD will look to resolve the following paths: 'path/basename.12.usd', 'path/basename.18.usd' and 'path/basename.24.usd'. If no stride is specified, we will use the value 1.0.
--activeOffset: An optional (double precision float) number indicating the offset USD will use when calculating the clipActive value that determines the time-range over which each clip is active.
- Given a start time of 101, an endTime of 103, a stride of 1, and an offset of 0.5, USD will generate the following:
- clipTimes = [(100.5,100.5), (101,101), (102,102), (103,103), (103.5,103.5)]
- clipActive = [(101.5, 0), (102.5, 1), (103.5, 2)]
In other words, an offset allows us to slide the window into each clip in which USD will look for timeSamples to map into the stage's time, rather than simply using the window implied by each clip's filename.
- Note that the
activeOffsetcannot exceed the absolute value of
usddumpcrate provides information on usd files encoded using USD's Crate File Format.
Provides information on Sdf Layers which underpin USD.
Provides information in a variety of formats (including usda-like) about Sdf Layers or specified (filtered) parts of a layer. Uses range from finding full information about specific properties, to creating "suitable for web/index display" versions of USD files that elide large array data.