Understanding the Python Environments#
Understanding the different ways to use Python in OmniVerse is crucial when deciding where to start. If you’re new to using Python in OmniVerse then please read the following descriptions.
Developing Extensions
Using Python Scripting Components
Writing scripts using the The Script Editor
Understanding each environment’s purpose and context are key when choosing between them.
Extensions#
Extensions are the most common domain for programming in Omniverse. They are the building blocks of an Omniverse Application. Virtually all user interface elements in an Omniverse Application such as Omniverse USD Composer or View, are created using Extensions. Examples include the Content Browser, the Viewport and the Stage. Extensions often create their own UI and are persistent in an Application as long as they are set to load in the Extension Manager.
The modular nature of Extensions allows them to be used in any Omniverse Application, thereby augmenting the functionality of that Application. If you are familiar with the popular JavaScript library React, you will notice that Extensions are modeled after React Components.
Get started by exploring the Programming Your Extension section
Python Scripting Components#
Python Scripting Components (PSC) are a convenient way to attach Python code to a specific asset (Prim) in your scene (Stage). It is a Python class that contains a reference to the Prim it’s attached to. When you attach a PSC to a Prim, a new instance is created. This means that you can attach a PSC to any number of Prims and each one will be its own instance and will behave separately from the others. If you are familiar with Unity, its very similar to attaching a Script Component to a Game Object. For Unreal developers, it’s similar to attaching a Component Actor to a Blueprint.
Like an Extension a PSC implements startup(), shutdown() and update() which fires every tick when the simulation is running. When the parent Prim is deleted the PSC is shutdown and destroyed.
The Script Editor#
The Script Editor is an Extension that lets you manually execute an entire file or multi-line block of Python code. It’s similar to a command line environment environment and can import and leverage much of the Kit API and USD Schemas. This makes it a great way perform simple tasks or tests without having to create an Extension.
Which coding environment should I use?#
The environment to use relies heavily on what you’d like to achieve. Let’s take a look at several ideas a developer could create and suss out which technology is best to use.
You are building a reusable tool#
Let’s say you are building The Randomizer Tool. It’s purpose is to add randomized rotations (Transforms) to objects (Prims). You would like this tool to act on many Prims at once and you need its UI to be persistent so the user can use it whenever it’s needed.
✅ An Extension is the appropriate environment to use.
❌ A PSC wouldn’t be appropriate because if the parent Prim is deleted the tool will be destroyed.
❌ The Script Editor isn’t appropriate because we need the Randomizer Tool to be persistent across Application sessions.
You are creating a programmatic animation#
Let’s say you’d like to render out an animation of exactly 3 bouncing balls. The balls do not need to interact and each one will bounce twice and then get destroyed.
❌ An Extension would be overkill for this project. Unlike a PSC, an Extension would keep running after the ball is deleted from the scene unless it is manually disabled in the Extension Manager. Furthermore, there are no complex interactions between any of the bouncing balls and we don’t need to let the user create new ones on the fly with modifiable parameters.
✅ A PSC could be written to animate a ball Prim to make it bounce. A PSC is appropriate here since it is designed to act on a specific prim and a UI isn’t necessary. The PSC can be reused on as many ball prims as desired. It also has the advantage of shutting down when the Prim is deleted.
❌ The Script Editor would have the following drawbacks: It would need the ball Prim to be specified when executed. Also, deleting the prim wouldn’t automatically dispose of the script.