NVIDIA Omniverse™ Create features real time physics simulation. Create relies on the NVIDIA PhysX SDK for rigid body dynamics, NVIDIA Blast for destruction and fracture, and NVIDIA Flow for fluid dynamics.
The Physics integration still has the following known issues:
Only a single simulation scene is supported.
Pair and Group filtering cannot be changed during simulation.
Debug visualization can be very slow for large scenes.
Rigid Body Dynamics¶
To start using physics simulation, the appropriate extensions must be enabled. Currently the following extensions are available:
Basic functionality including Property Window
Additional work in progress features
Make sure that you have enabled these extensions in the Window->Extensions window.
Adding Basic Physics to Your Scene¶
As a first step, making sure the units of your scene are set up correctly is very important, because it will influence the behavior of your simulation. These units (Meters Per Unit, Kilograms Per Unit, and Time Codes Per Second) are visible as metadata properties of your root layer.
Before you can have anything that behaves physically in your scene, you need to add a PhysicsScene. This object holds basic physics settings like gravity. All physical objects have to be tied to a scene. To create a scene, select Create > Physics > Physics Scene.
Often it makes sense to create these physics objects in their own layer.
Select the PhysicsScene in the stage window; the Property window will now let you change important simulation settings such as gravity. As long as you only have a single PhysicsScene in your scene, it will act as the default, and all physics object will automatically be associated with it.
The next most important thing you will generally need in your scene are static colliders. These are objects that don’t move (unless you move them) but will still collide with physical objects, such as the walls or floor of a room. The simplest case is a so called ground plane, which can be created via Create > Physics > Ground Plane. This will add a new object comprised of a big quad visual and a static Plane collider. This will prevent your dynamic objects from falling indefinitely.
If you have your own mesh or prim geometry that you would like to make into a collider, just select it and then right click Add > Physics > Collider. Instead of creating a new USD object, this will simply add physics collision attributes to the existing object. The precise set of attributes added may depend on the kind of object you have selected.
Finally, to make something into a dynamic rigid body, select it, and then right click Add > Physics > Rigid Body. In addition to adding colliders, this will also add rigid body attributes. Note that when you select an entire subtree of objects, collision attributes will be added to every applicable geometry, while the rigid body attributes are only added to the topmost node in the selection. This means that all parts of your selection will collide with the world, and everything parented under the topmost node will move together with it as a rigid assembly. Notice that additional physics attributes have been added to the Property window.
There is a shortcut for making colliders and rigid bodies, using the Add > Physics > Rigid Body with Colliders Preset. This will apply Rigid Body to the currently selected object and then it will apply Colliders to all geometries on the selected object or on the hierarchy below.
An object can only be made to move as a single unit. If you have multiple things combined together into a single mesh object, you will need to separate them into parts first, before physics can make them move independently.
Once you have a dynamic object defined, you can press the Play button. If you did everything right, this will make the object start falling until it hits your static object or ground plane, and comes to rest. Pressing Stop will (by default) reset your simulation state to how it was before you pressed Play. While the simulation is running, you can also pull the dynamic object(s) around by shift-clicking and dragging them. They should try to follow your mouse cursor but still collide with obstacles.
The Create > Physics menu creates new prims in your stage.
The Add > Physics menu (right click or in Property window) adds physics properties to your selection.
It the Property window one can remove individual components like RigidBody or Collider
All physics properties of an object are visible in the Window > Property window.
In the Property window there is a Add > Physics button that brings down a list of physics options that can be applied to selected object. The list is context sensitive and show the physics components that can be added to the selected object. Adding such a component will populate the Property window with new rollouts and attributes.
Rigid bodies and colliders have a Rigid Body Enabled and Collision Enabled, respectively. This check box that can be used to temporarily disable rigid body and collision behavior respectively without entirely removing the respective component and losing all the attribute settings.
The kinematic Enabled check box is for making animated key frame objects that can ‘push’ dynamic physics objects. First you need to key frame animate the object (see the Animation section of this guide), then just tick that check box and it should just work.
Note that many attribute edit fields in the Property window have a right click pop-up menu that lets them be reset to a default, minimum or maximum value.
By default, the mass of a dynamic body is derived from the total volume of all the collision geometry under the body, multiplied by a density. Unless a density is specified explicitly, a default of 1000 will be used. One can set an explicit density on any collider by adding a Mass component. In a hierarchy, a child’s prim’s density overrides parent prim’s density. However, a parent’s explicit Mass will override a child’s density derived mass. It is also possible to have a density set in a PhysicsMaterial, which has the weakest precedence. Physics materials will be discussed later.
Collision Shape Settings¶
Implicit shape prims are automatically converted to a matching physics representation and don’t need further configuration. Most of their settings are relatively obscure and can be left at their default values. The Collision Offset tuning parameter is perhaps worth mentioning, it defines a small distance from the surface of the object at which contacts will start being generated (The default values is -inf which means that the application will try to determine the best value based on scene gravity, simulation frame rate and object size.).
Prims of type Mesh get an additional Mesh Collision rollout: This controls if the mesh should receive very coarse collision in the form of a box or sphere, a fitted convex hull, or even a decomposition into convex pieces. Note that PhysX doesn’t currently support collision between two dynamic triangle meshes.
Generally, the generated collision shapes are not exactly the same as render geometry, so it can be important to see them. The viewport has an Eye icon menu containing Show By Type > Physics > Colliders. This will render collision shapes with an outline based on the USD state.
Physics treats meshes as single sided for collision purposes, while Omniverse renders all meshes as double sided by default. This creates a tension that makes it easy to author scenes that don’t behave as intended. We recommend that in the Rendering > Render Settings window, under the Common tab, users authoring physics colliders enable Back Face Culling so it becomes clear which faces are front vs back facing.
If a mesh has faces facing the wrong way, this can be inverted using the Geometry > Orientation dropdown in the Property window of the mesh.
Currently collision visualization does not effectively distinguish front and back faces of triangles, we hope to improve this in the future.
Cylinder and cone shapes have two collision shape implementations: convex mesh based (default) and custom geometry based. They can be switched by the Collider > Custom Geometry checkbox in the Property window of a cylnder or a cone.
Physics materials can be created via Create > Physics > Physics Material. This will create a material object that can be assigned to colliders using the dropdown in the Physics Materials on Selected Objects rollout. Alternatively, one can use the Add > Physics > Rigid Body Material from the Property window to add the Rigid Body Material on an existing graphics material. It can then be assigned as a Physics Material using the above method.
Physics materials have friction, restitution (a.k.a. ‘bounciness’) and material density attributes.
Collision groups are groups that colliders can belong to. Once you have multiple collision groups, you can set them up to collide with each other or not. You can create a collision group object using Create > Physics > Collision Group. One adds collision shapes to the group using the Includes and Excludes attributes, subject to inheritance rules defined by Expansion Rule (see https://graphics.pixar.com/usd/docs/api/class_usd_collection_a_p_i.html#details for details).
All objects in the same collision group will collide with each other. By default, objects in two different collision groups will also collide. In the Property window of one collision group, however, you can add a list of other collision groups this group should not collide with. PhysicsScene has an attribute Invert Collision Group Filter that lets you invert this behavior, in case you prefer that by default different groups should not collide, and then specify pairs of collision groups that do collide.
Pairwise Collision Filter¶
In cases where using collision groups is insufficiently fine grained, one may select two bodies, colliders or articulations, and choose Add > Physics > Pair Collision Filter. This will disable collision between only the pair of selected objects which will both have a Filtered Pairs rollout added. This takes precedence over collision groups.
Joints give you the ability to connect rigid bodies in ways that are not entirely rigid. A good example is a car: the wheels of the car revolve around their respective axes, the suspension can slide up and down along an axis. The technical terms for the former is “revolute joint”, the second is a “prismatic joint”.
To add a joint to your scene, first select the two objects to connect. It is also possible to select a single joint in order to connect it to the world frame. Then select Create > Physics > Revolute Joint, etc.
When the joint is selected, its joint gizmo will be drawn. This is the usual coordinate frame in the 3d view, along with some joint type specific visualization to indicate the joint’s field of motion. The joint can be translated or rotated using this gizmo as if it was any other kind of 3d object.
The properties pane of the newly created joint will show its properties, including:
Can be used to disable the joint temporarily.
For some joint types, selects the axis along which the joint rotates or slides.
Break Force, Torque
If the joint experiences more strain than this value during simulation, it will disconnect.
Note also that each joint is defined by two attachment frames, Local Position/Rotation 0 and 1. Each is defined relative to the respective object being connected. (So a Local Position 0 of (0,0,0) means the joint attaches at the origin of Body 0.) Normally these two local frames line up in world space, and define the ‘global’ position of the joint gizmo. It is however possible that the frames do not line up. In this case the global pose of the joint gizmo will be either one of the two joint frames, or a pose in between the two, depending on the specific behavior of the joint type.
You can use the Add > Physics to add drives or limits to your joint. Limits let you reduce the permissible range of motion, and drives let you add spring and damper elements or a motor.
Articulations are an advanced, hierarchic mode of joints, useful for creating hierarchical mechanisms such as a vehicle or a robot. To use articulations, one should organize the joints of a mechanism and the objects they connect into a tree structure. For example, to create an articulated wheelbarrow, one would create the body (tray) object, which would have a child revolute joint for the wheel axis, and the joint would have a child wheel body. To mark the wheelbarrow as an articulation, an Articulation Root component must be added to its top level body.
The graph of joints connecting bodies will be parsed starting at this body, and the parts will be simulated relative to one another, which is more accurate than conventional jointed simulation. Joints in the hierarchy that close loops will be ignored by the articulation and be simulated in the conventional manner. Joints have an Exclude from Articulation attribute which can be used to select one of multiple potential loop closure joints to be ignored. Note that the Articulation Root has an Enable Self Collisions attribute. If this is cleared, it automatically filters all collisions between parts of the hierarchy.
Tendons create constraints within articulations. There are two types:
Fixed Tendons impose constraints on joint positions. For example, fixed tendons are used to simulate the Shadow robotic hand in Isaac Gym: In a human finger, the motion of the two outermost joints is linked, which can be modeled with a fixed tendon.
Spatial Tendons impose distance constraints between attachment points on links. This allows, for example, modeling hydraulic actuators that can push and pull on links, artificial muscles in a biomimetic robot, or elastic-string-like mechanical components.
You can enable debug visualization for tendons in the Show/Hide (Eye) menu in the viewport, see screenshot. Choose Selected to visualize tendons related to a selected joint or link, or choose All to show all tendons in the stage, which is the recommended setting when editing Spatial Tendons in particular.
Further tendon-type-specific details on the visualization are provided in the respective sections.
The example video shows the Fixed Tendon snippet in Physics Demo Scenes > Snippets. The three articulation links are connected by two revolute joints. The red link is the articulation’s fixed base. The revolute joint connecting the red link to the first blue link features a joint drive that drives the joint alternatingly to zero and forty-five degrees. The second revolute joint connecting the two blue links does not have a drive, but is constrained to follow the position of the driven joint by a fixed tendon.
In particular, the fixed tendon in the snippet consists of two so-called tendon axes that each refer to one of the revolute joint positions. Each axis has a corresponding gearing attribute that is used to compute an abstract tendon length from the gearing-weighted joint positions.
The fixed tendon enforces constraints on this length by applying spring-damper forces to the links that are parametrized by the stiffness and damping attributes. The tendon applies an equal and opposing reaction force to the parent link of the tendon root axis, see the section on creating a tendon below.
In addition to the length constraints, you can add limit constraints by setting an upper and lower limit for the length, and an appropriate limit stiffness. This allows implementing one-sided constraints (with stiffness set to zero).
Refer to the snippet Python code to learn more about the tendon dynamics, and sizing the stiffness and damping parameters based on gravity and articulation link mass. Full details on the tendon dynamics are available in the USD schema documentation of
Creating a Fixed Tendon
When creating a fixed tendon, it is important to be aware of the articulation structure, since the tendon cannot link arbitrary joints in the articulation, but must follow the articulation structure exactly. In particular, all joint axes in the tendon must be connected to each other by exactly one articulation link.
This means that just like articulations, fixed tendons have a tree like structure, and the root axis must be at the root of the tendon, i.e. applied to the articulation joint that is the single common ancestor of all other joints with axes in the tendon. For example in the snippet, the root axis must be on the joint between the red and blue link, as it is the articulation-ancestor of the second joint between the two blue links.
After identifying the root, apply the Fixed Tendon Root Axis (i.e. the
PhysxTendonAxisRootAPI) using the Add button in the property window of the target joint. You are prompted for an instance name that is used to group axes into a single tendon.
Add additional Fixed Tendon Axis (i.e.
PhysxTendonAxisAPI) to joints, taking the above structure constraints into account. Make sure to set the same instance name for all axes intended to be part of the same tendon. Then, proceed to configure gearings for all axes and common parameters in the root axis.
If the behavior is not as expected, make sure to check the log output for any warnings related to tendons.
Fixed tendons currently only support Revolute and Prismatic joints. Support for Spherical and other joints will be added in the future.
Tendon axes are grouped into tendons by instance name, so make sure to use the same name for all axes belonging to the same tendon.
The debug visualization draws an overlay of lines and circles that represent the fixed tendon. The circles reflect the axes while the lines connect axes that belong to the same tendon. A solid circle highlights the tendon axis of the selected joint. Green indicates a regular axis, green-yellow a root axis, and red indicates an issue with an axis, most likely due to a structure issue, see the constraints above.
Finally, if there are multiple tendons running through a joint, you may highlight single tendons by clicking on the eye button in the tendon-axis display in the property window.
The example video above shows the Spatial Tendon Actuation snippet in Physics Demo Scenes > Snippets. The moving links of the two articulations are held up against gravity and actuated by tendons. The spheres are the debug visualization of the attachments that define the tendon geometry, and the blue lines visualize the line-of-sight distances that the tendons constrain using spring-damper forces.
The three different attachment-sphere colors distinguish the different types of attachments:
Root attachments (cyan) provide tendon-wide parameters such as spring-damper parameters, etc. The root attachments experience the reaction forces of the constraint forces applied to the leaf attachments.
Regular attachments (magenta) are used to route a tendon along articulation links. There is no force propagation through regular attachments, so they do not exert any forces on the links.
Leaf attachments (yellow) exert constraint forces to enforce a distance constraint on the path from the leaf to the root. A spatial tendon may branch, and, therefore, each leaf defines a sub-tendon with its own distance constraint. The leaf has sub-tendon specific parameters, such as the sub-tendon rest length and limits.
The tendon length of a (sub-)tendon is the sum of line-of-sight distances between the attachments on the path from a leaf to the root attachment. The tendon then applies spring-damper forces to the root and leaf to maintain a target length. In addition to a target length, you may set limits on the lengths, and choosing the upper and lower limit appropriately allows implementing one-sided constraints, e.g. modeling the tendon as an elastic string that can only constrain an upper length of the tendon.
The direction of the forces that are applied to roots and leaves is defined by the tendon geometry. For example, in the snippet above, the yellow leaf attachments apply a force to the moving links in the direction of the blue line towards the magenta middle attachment; analogously, the equal-magnitude root reaction force is also in the direction of the magenta middle attachment.
In the snippet, the two tendons demonstrate two separate approaches to actuation: The front tendon moves the middle attachment while keeping the target tendon length constant, while the other tendon changes the target tendon length. Further details such as sizing of the spring-damper parameters are presented in detail in the snippet Python code. Full details on the tendon dynamics are available in the USD schema documentation of
Creating a Spatial Tendon
Spatial tendons are created by adding attachments to articulation links in the property window Add menu, see above. Since an articulation link may have multiple attachments, you must provide an instance name for each attachment.
The tendon (tree) structure is created by defining parent-child relationships between attachments. An attachment’s parent is defined by 1) the parentLink relationship that points to the articulation link that has the parent attachment, and 2) the parentAttachment token that specifies the instance name of the parent attachment. Note that unlike fixed tendons, spatial tendons are not constrained by the articulation structure.
The second Spatial Tendon snippet in Physics Demo Scenes > Snippets demonstrates a branching spatial tendon.
You may create a spatial tendon as follows:
Add a Spatial Tendon Root Attachment to an articulation link.
Add intermediate Spatial Tendon Attachment’s to links (note that it is possible to add multiple attachments belonging to the same tendon to the same articulation link).
Add a Spatial Tendon Leaf Attachment to terminate a sub-tendon, i.e. branch of the tendon tree.
Configure the connectivity of the tendon by defining the attachments’ parents (see the Authoring hints below for a graphical approach to this).
Configure gearings and the tendon-wide and sub-tendon parameters in the root and leaf, respectively.
The debug-visualization spheres can be moved interactively to position them on the articulation link. After an attachment is added to a link, the debug-visualization sphere is auto-selected for immediate positioning.
Connections are auto-created when two attachments that are eligible for connection are selected. If it is not clear on which of the two attachments the parent attributes should be set, e.g. for two regular attachments that do not have any parent attributes set, the selection order determines which attachment has its parents attributes set: The first-selected attachment has the parent attributes set to point to the second-selected attachment.
The parent link and instance name are reflected in the debug-visualization sphere USD prim paths. You can browse to the corresponding attachment API in the property window by either de-selecting the attachment (press Escape) or selecting the parent link after selecting the attachment sphere; the property window will scroll to the corresponding API-type section. Going the other way is possible as well: Just click the Eye button shown with the API in the property window and the corresponding attachment is selected.
All these authoring concepts are further illustrated in this brief tutorial video:
A character controller (CCT) is our name for a video game style movement controller that permits the player to move around a world without being able to go through walls. To use this feature, be sure that the omni.physx.cct extension is loaded.
The player is represented by a capsule shape, so start by creating a capsule primitive (Create > Shape > Capsule). Then pull up the CCT window Physics > Character Controller, and press the Activate CCT button while the Capsule is selected. This will hide the capsule and give it CCT properties. When the Play button is pressed, you will take control of the CCT and can see a “first person” view. The CCT should collide with physical objects as expected.
The Edit > Preferences > Physics window has some important opportunities to configure your simulation. The Update to USD and Reset Simulation On Stop control what exactly should happen when you press Play. Depending on the settings, the simulation results will either be written back to USD just like editing operations, or just rendered with no side effect. Reset on stop means Create reverts state that the simulator has changed when Stop is pressed to just how it was when Play was pressed.
The number of simulation threads controls how many background threads are spawned and reserved for simulation.
Some important simulation settings are not global but rather per-scene, and can be found in the Properties window of the Scene. Enable GPU Dynamics in particular is important, and should be used to check discrepancies in results between CPU and GPU simulation modes. Time Steps Per Second defines how many times the simulation should update per second.
The Window > Physics > Debug window should be the first place to look when physics simulation is generating unexpected results. One of the most important diagnostics is right at the top: Step lets you advance your simulation one time step at a time, so you can closely observe problems that happen very quickly.
There is a low level visualizer in the Physics Debug window Simulator Debug Visualization rollout that renders directly based on the PhysX engine’s state, which is useful if for some reason it is not in sync with USD. This needs to be enabled with the Enabled check box, and then individual visualization options can be selected from the list below. The Scale field can be used to adjust the length of some lines and arrows. It is important to note that this data is only generated in Play mode when the simulator is running.
Also, some data like contact points are generated at the start of an update, and bodies are moved at the end of the update. Shapes are also drawn using their state at the start of an update so they line up with contact points. For this reason the visualization display will look one frame behind the graphics rendering.