Your first steps
into OpenUSD.

Can you do this right now?

The 50 GB figure is our own extrapolation, not NVIDIA's. Neither the README nor the companion tutorial states a disk requirement — both were checked. Treat it as a floor, not a specification.

How that estimate was reached. NVIDIA's NGC listings put the Kit SDK at roughly 1 GB compressed and the air-gapped bundle at roughly 5.7 GB compressed. Uncompressed, plus a build tree, plus shader, extension and packman caches, 50 GB is a safe working figure — but still a figure we made up.

No NVIDIA account or login is required for any step in this guide. This is an absence-of-evidence conclusion: no login step appears anywhere in the README or the template docs, and the clone is a public repository.

Three ideas that make sense of this

How this relates to USD Composer

• The product USD Composer is a scene-authoring application NVIDIA shipped as part of its launcher-era product line.
• The template kit-app-template includes a template named USD Composer, described in the repo as a starting point for authoring complex OpenUSD scenes, aimed particularly at configurators (template README).
• You are not downloading the product You are generating a new application of your own, with a Composer-like feature set and layout.
• Deliberately reduced The template is an essential set of extensions, not a byte-identical clone of the retail app.

It is a foundation you extend, not a product you run.

The time budget, step by step

The 10 to 30 minute build range is our estimate, not NVIDIA's. NVIDIA documents the 5–8 minute shader figure but says nothing about build duration. Build time is dominated by download speed, so treat the range as a rough shape rather than a number. The 5–8 minute shader figure is documented, in two places.

One thing to know before you start

• This is a feature branch The public kit-app-template repository tracks a feature branch of the Kit SDK — regularly updated, intended for prototyping and testing.
• Production lives elsewhere For production work NVIDIA points to the Production Branch distributed through NGC, stated at the top of the README.
• For learning, this is right Just do not be surprised when it changes under you.

2. See what templates are available

   Windows

   .\repo.bat template list

   Linux

   ./repo.sh template list

   You should see: the first repo command you ever run bootstraps the tooling, downloading packman and the repo_* packages into _repo/. A minute or two of download progress. Subsequent commands start instantly.

You will be asked to accept the Omniverse licensing terms on first use of the template tool. Acceptance is recorded as a breadcrumb file, .omniverse_eula_accepted.txt, at the repo root. Accepting binds you to the NVIDIA Software License Agreement and the Product-Specific Terms for NVIDIA Omniverse.

The five application templates

3. Run the wizard

   Windows

   .\repo.bat template new

   Linux

   ./repo.sh template new

   You should see: an interactive prompt sequence navigated with arrow keys and Enter.

4. Answer the prompts

   1. What do you want to create? → Application
   2. Which template? → USD Composer
   3. Name of the application .kit file — namespaced, lowercase, alphanumeric. The template default is my_company.my_usd_composer. Use your own namespace: mystudio.composer. This becomes a real filename, so the naming rules are not decorative.
   4. Application display name — free text, shown in the title bar. Default My USD Composer.
   5. Version — semantic versioning recommended. Default 0.1.0.

   Then, because USD Composer requires one, you are prompted for a setup extension. The wizard names it: omni_usd_composer_setup.

   6. Extension name — default my_company.my_usd_composer_setup_extension. Match your namespace: mystudio.composer.setup.
   7. Extension display name and version — as above.

   You should see: the tool reporting the path it created. Defaults are fine everywhere if you are only testing.

5. Confirm the wizard did its job

   The tool edits several things on your behalf:

   • source/apps/<your-app>.kit your application definition, now on disk
   • premake5.lua gains a define_app("<your-app>.kit") line so the build system finds it
   • repo.toml your app path is added to repo_precache_exts.apps
   • source/rendered_template_metadata.json records what was rendered — this is what makes template modify and template list work later

   You should see: git status showing changes to premake5.lua and repo.toml, plus a new source/ directory.

About the setup extension

This extension holds the application's layout, window arrangement, and extension configuration. It is generated as editable source in your project — the file you will edit first when you want to change how your app looks.

Application layers

You may also be asked whether to add application layers. Say No. Layers add optional capability — notably streaming to a browser — and you do not need them to run locally. You can add them later without regenerating anything:

.\repo.bat template modify

./repo.sh template modify

Scripting it (optional)

To make this reproducible in CI, record the answers and replay them:

.\repo.bat template new --generate-playback my_playback.toml
.\repo.bat template replay my_playback.toml

./repo.sh template new --generate-playback my_playback.toml
./repo.sh template replay my_playback.toml

The wizard prompts may not read exactly like this. The substance — app name, display name, version, then setup extension name, display name, version — is documented in the template README, but the exact wording and ordering came from documentation, not from a live run. Real wizards drift from their docs.

Two smaller caveats. The "add application layers" prompt is documented for Kit Base Editor and not shown in the USD Composer prompt list, so the flow may differ. And my_playback.toml is our substitution for NVIDIA's {playback_file_name}.toml placeholder.

One structural change worth knowing about

As of the 110.1.0 release, templates are no longer plain files inside the repository. They are versioned packages (kit_core_templates, kit_sample_templates) declared in tools/deps/repo-deps.packman.xml and resolved into _repo/deps/. Both are currently pinned to 110.2.0+feature.11994.96415c1d.gl.

• Your directory stays clean It contains only your own code and configuration. Template boilerplate stays out of it.
• templates/ is a reference copy The directory still visible at the repo root is not what the wizard reads. The wizard reads from _repo/deps/.
• Old tutorials are wrong here Anything telling you to edit files under templates/ to change what gets generated describes a model that no longer applies.

The template keys and defaults quoted throughout this guide were read from the in-repo templates/ copies, because packman package contents cannot be fetched over plain HTTP. They should be identical to the packaged copies, but we could not verify that. If the packaged templates have drifted, the keys and defaults could differ. Low risk, non-zero.

One car, five tools

• A delivery format answers how do I ship this scene.
• USD answers how do we keep building it, across teams and tools, for the next eighteen months.

But couldn’t you just…

The problem is not moving a scene once. It is keeping one scene alive while many people change it.

There is no USD application you launch to build a scene — you author USD from Python or C++, or through an application that speaks it, such as Houdini, Maya, Blender or the Omniverse apps. What follows stands in for that: the same authoring, reduced to five buttons.

Watch the listing rather than the picture. Every button writes a statement — a prim, a transform, a colour — and the view on the right is only ever a reading of those statements. Nothing you press draws anything; it says something, and something else draws it.

Before you go on

This is the core idea: OpenUSD describes a scene, and tools can read, compose, and display it.

"Prim" is short for primitive, and it is the basic object of the USD world. If you can select it, hide it, move it or point at it, it is a prim. A scene is nothing but prims arranged in a tree, and the tree is what gives every one of them an address.

What follows from that

• Paths are absolute they always start at / and read top to bottom.
• Names must be unique among siblings the full path is then unique across the stage.
• Rename an ancestor and every descendant's path changes with it.
• Nothing tracks the old path which is why asset structure gets its own chapter later.

Each prim also carries a type saying what it is — Xform for a group that moves, Mesh for geometry, Cube for a box — and schemas can bolt extra bundles of properties onto it; neither needs unpacking today.

A prim is one object in the scene, and its path is both where it sits and who it is.

Several layers compose into one stage — that is composition, and the rest is detail.

• External references pull a prim hierarchy from another layer into this one.
• Internal references pull from a prim elsewhere in the same stage — the target is a prim path with no layer.
• One arc covers both cases. That is why a reference is the first thing to reach for.
• The source is never modified. Overrides you author sit on top of what the reference brought in.

def Xform "World"
{
    def "Chair_1" (
        references = @./chair.usd@</Chair>
    )
    {
        double3 xformOp:translate = (0, 0.9, 0)
        uniform token[] xformOpOrder = ["xformOp:translate"]
    }
}

Building a scene out of assets

• A part is a component asset with its own USD file.
• A rack references the same part many times.
• A workcell references racks, fences and storage.
• A facility references workcells — and is itself referenceable.

Nothing in that pyramid is a copy. Each tier is one file naming the tier below it, so a correction to part.usd arrives in all thirty-six places on the next load. Build it bottom up and the scene assembles itself.

Composition encapsulation

"Not live" is a feature, not a limitation. Encapsulation is what makes a referenced asset predictable: what you composed is what you get, regardless of what the rest of the stage does afterwards.

Reach for a reference first. A scene of a thousand chairs is one chair file and a thousand short prims.

1. What is the main object?

   Name the one thing this asset is. A chair, a robot, a whole apartment building. If you cannot say it in a few words, this is probably two assets that have not been separated yet.

2. What parts does it contain?

   List what lives inside it, and at what grain. A robot has arms and a base; whether the bolts are parts of their own is a decision, not a fact. Parts nobody will ever address separately do not need to be separate.

3. Which parts may change later?

   Colour, level of detail, an open door and a closed one. A part with more than one acceptable state is a candidate for a switch the asset carries with it, rather than for a second file.

4. Who will use this asset next?

   A colleague in the same tool, a renderer in a farm, a customer building their own scene on top of yours. That answer decides which names you are still allowed to change later and which you are not.

Answer them out loud before you open a file. The four answers are cheap to change while they are still sentences, and expensive to change once they are a folder of published layers.

The rest of the chapter is those four answers made concrete: where the parts live, what they are called, which of them can move, and what you have promised the next person.

The rule that matters is short: never overwrite a published file. The moment an asset has been handed on, somebody's scene resolves to it, somebody's render is halfway through it, and somebody's approved shot depends on it looking exactly as it does today. A file saved over itself leaves none of them a way back.

chair/
    chair_v001.usd
    chair_v002.usd
    chair_v003.usd
    chair_latest.usd  ->  chair_v003.usd

• Sequential integers — _v001, _v002, _v003. Plain, sortable and unambiguous in a log. Zero-pad them so they still sort correctly as text.
• A pointer for the moving target — a _latest file or link lets a consumer opt into updates. Pinning to a number is how they opt out.
• Publishing is one-way — a version is never reused and never repaired in place. A mistake in _v002 is fixed by publishing _v003.
• Say what changed — an asset whose internals changed can publish quietly; one whose interface changed is asking every consumer to do work, and should say so.

Variants: a change the asset carries itself

Question three asked which parts may change later, and not every such change needs a new file. A variant set is a named switch carried on a prim; its variants are the positions that switch can point at, and exactly one is selected at a time — so a single asset can describe every configuration it has, instead of shipping one file per configuration. A material set holding red, blue and green; an LOD set holding high and low.

The selection is itself an ordinary authored opinion, so a stronger layer can re-switch an asset it is not allowed to edit: author the selection in your own layer and the asset's file is never touched. That is also why the name of the set and the names of its variants belong on the public side of the interface — they are part of the promise, while whatever each variant composes behind them is not.

Anticipate some change with variant sets, but do not plan for every eventuality — that is bloat. Publishing a new version is the cheaper answer for a change nobody will ever want to switch between.

How an asset keeps its own dependencies straight when it moves — textures, resolvers and anchored paths — is chapter 9's subject.

Publish beside, never on top. A version you can go back to is what makes a change safe to make.

A model file answers one question: what shape is this, and what does its surface look like. That is a real and useful question, and formats that answer it are small, fast and everywhere. An OBJ is a bag of vertices and faces. A glTF adds materials, a node hierarchy and animation, aimed at handing a finished thing to a runtime that will display it.

USD is answering a different question. Not "what shape is this" but "what is in this scene, where did each part come from, and who is allowed to say what about it". Chapters 2 and 3 already gave you the machinery: layers that stack opinions, references that pull one asset into many places, overrides that adjust a thing locally without touching its source. None of that is geometry. All of it is the part that a model format has no place to put.

def Xform "World"
{
    def "Chair_1" (
        references = @./chair.usd@</Chair>
    )
    {
        double3 xformOp:translate = (0, 0, 0)
    }

    over "Chair_1"
    {
        color3f[] primvars:displayColor = [(0.9, 0.7, 0.1)]
    }
}

• A model is a noun; a scene is a sentence. The chair is the noun. Where it stands, which chair it is a copy of, and who repainted it are the sentence.
• Structure is content. The grouping and naming of a scene is information someone authored deliberately, and it is as losable as anything else.
• The collaboration story travels too. Layers keep separate people's contributions separate, which is a thing you can only preserve if the format has somewhere to keep it.

This is why "USD versus glTF" is the wrong shape of question. They can sit in the same pipeline happily: a glTF is a reasonable thing to deliver out of a USD scene, and a poor thing to run a production in.

A model format describes an object. USD describes a scene, its structure, and how a team works on it.

These suit a reader who has a fast connection, spare disk space and a machine that can render. They reward reading rather than editing: open them, walk the hierarchy, and see how many separate files a single polished frame is actually made of.

The restaurant pack is the clearer lesson of the two, because of one split it makes visible.

• Open the tree before the viewport in a scene this size the hierarchy tells you more in a minute than the render does in ten.
• Find the world file and read what it references. It is usually short, and it is the map of everything else.
• Look at what is not geometry cameras, lights, section tools and sun studies are prims like any other, and they are where the workflow lives.
• Note which tool each part came from. A collaborative scene is several applications' output standing in one stage without arguing.

Neither of these is a first scene. Downloading nine gigabytes before you have opened a stage tree is a way of spending an evening without learning anything. Section 03 is where to start.

Large scenes are for reading, not for editing. Open them to see how many files a finished world is.

Do a thing, read the line it wrote. That loop is the whole method, and here it costs nothing.

1. Move an object

   Drag a prim in the viewport and watch xformOp:translate rewrite itself in the text.

2. Mute a layer

   Switch off the strongest opinion and watch a weaker one take over the value.

3. Read who won

   Every property names the layer that set it. That is the question, in every scene above.

What it is, and what it is not

What it does give you is the reading habit: not what is this value, but which file said so.

Change one thing and read what it wrote. That is the whole method, and it works at 25 MB and at 9 GB alike.