NVIDIA Omniverse, Chapter 2: What’s actually in that Default Editor

Last chapter, we got an app running and left it there — a full editor window, menus, panels, the works, all of it appearing the moment you ran ./repo.sh launch. Time to pop the hood and figure out where all of that actually came from, because the answer is more useful than it sounds.

[embed]NVIDIA Omniverse, Chapter 1: Getting Your First App Running If you’ve ever tried to learn Omniverse and bounced off it — too many acronyms, too many tools, unclear where the…medium.com

Two layers, not one

The repo looks like a single project, but it’s really two separate things stacked on top of each other, and it’s worth keeping that split in your head from day one — it answers almost every “wait, can I edit this file?” question you’ll have going forward.

Think of it like moving into an apartment. The building’s plumbing, wiring, and load-bearing walls were built by someone else, follow codes you didn’t write, and aren’t really yours to touch. Your actual apartment — the rooms you decorate, the furniture you arrange — is what you’re there to make your own. NVIDIA’s build tooling is the building; your application is the apartment.

Layer 1 — the building (NVIDIA’s, don’t touch):

• repo.sh / repo.bat — the entry point that boots everything else up
• repo.toml — the actual settings for how the tooling behaves
• premake5.lua — registers your app with the build system
• tools/deps/ — pins exact versions of everything under the hood

Layer 2 — your apartment (this is what you’re here to build):

• source/apps/<your_app_name>.kit — your app's entire definition: what features it includes, its runtime settings, its window title. This is the file you'll spend the most time in.
• source/extensions/<name>/ — where your own custom code eventually lives (empty for now — we'll fill this in a couple of chapters from now)

Simple rule going forward: if it’s in Layer 1, or auto-generated, leave it alone. If it’s your .kit file's dependency list or settings, or anything under source/extensions/, it's fair game.

Why the editor came fully loaded

Here’s the thing that isn’t obvious the first time you see it: that entire editor — menu bar, viewport, stage tree, properties panel, content browser, console, toolbar — none of it is hardcoded into Kit.

Every single panel is its own optional extension, listed in your .kit file's dependency list, the same way a car's trim level is built from optional modules rather than baked into the frame. Heated seats, sunroof, the works — each one bolted on separately, and each one removable if you don't want it.

Which means: if you don’t need a piece of the default editor for the app you’re building, you can just… take it out.

Stripping the chrome

Before removing anything, it helps to sort what you’ve got. A simple way to classify each dependency in your .kit file:

• Engine — the actual rendering/scene runtime. Keep this no matter what.
• Chrome — default editor UI. Safe to strip once you’ve got your own interface.
• Authoring tool — a nice-to-have convenience feature, not core.
• Dev-only — should never ship in something you hand to an end user.
• Policy — telemetry/privacy-related, worth a second look before deciding.

Sorting your dependency list into these buckets first — even just a quick table — makes the next part far less nerve-wracking, because you’re not guessing at what’s safe to remove.

With that sorted, here’s what came out on a first pass:

+---------------------------------+------------------------+
| Extension                       | What it drew           |
+---------------------------------+------------------------+
| omni.kit.window.stage           | Stage tree panel       |
| omni.kit.window.property        | Property editor panel  |
| omni.kit.window.content_browser | Content browser panel  |
| omni.kit.developer.bundle       | Developer tools bundle |
| omni.rtx.settings.core          | Render Settings panel  |
+---------------------------------+------------------------+

The gotcha: removing something doesn’t always remove it

Here’s where it gets interesting. Pulling omni.kit.window.property out of the dependency list didn't actually make the property panel disappear.

Why not? Picture cutting the wire to a lamp, only to find it’s still lit — because it turns out there’s a second extension cord feeding it power from an outlet across the room you didn’t know about.

That’s exactly what happened: another extension that was still in the list, omni.kit.property.bundle ("all the property editors, bundled"), declares the property window as its own dependency. Kit resolves dependencies transitively — removing your direct line to something doesn't matter if anything else you kept still needs it.

The same thing played out with the content browser. Nothing removed, had tried for it directly, but a few authoring tools still in the list — an asset importer, a material library browser — each need somewhere to browse and select assets from, so they quietly pull the content browser back in behind the scenes.

And omni.rtx.settings.core turned out to be a genuine classification mistake by me, not a transitive one — it sounds like pure engine config, but it's actually what puts the Render Settings panel on screen. Worth remembering: names can be misleading, and the "Engine" bucket deserves a second look before you assume something belongs there.

The takeaway: before assuming a removal is complete, check what else you’re keeping that might be quietly re-introducing the same thing. If something in your list has “bundle” in the name, suspect it first — bundles exist specifically to pull in a group of related things at once, which is exactly what makes them likely to smuggle back in whatever you just removed.

Next chapter, we’ll deal with the question this naturally raises: after you make a change like this, when do you actually need to rebuild versus just relaunching the app? Turns out the answer isn’t “always” or “never” — and getting it wrong is exactly how you end up staring at an extension that swears it’s gone but clearly isn’t.