Physics Core


The NVIDIA Omniverse™ Physics simulation extension is powered by the NVIDIA PhysX SDK. Below you can find a short description of the main features of PhysX that are available in Omniverse.

This page focuses on interacting with the Physics extension through the Omniverse user interface. However, you may setup and interact with physics components also via the Python API, see Help > Physics Scripting Manual and the source code for the snippets and samples in Window > Simulation > Demo Scenes.



Rigid-Body Simulation

PhysX provides state-of-the-art, scalable rigid-body simulation that you may use to add dynamics to scene assets with just a few mouse clicks. Using the Physics Joints feature, you can connect rigid bodies and create advanced mechanisms.


With the articulation feature, you can simulate ragdolls, or high-fidelity robotic systems including, for example, walking robots or industrial robot arms.

Deformable-Body Simulation

Make your assets squishy with the PhysX real-time deformable-body simulation based on the finite-element-method (FEM).

Character Controller

The Character Controller (CCT) is a video-game-style movement controller that permits a user to move around a world without being able to go through Physics-collision-enabled objects.

Particle Simulation

Use the PhysX GPU-accelerated position-based-dynamics (PBD) particle simulation feature to add fluids, granular media, and cloth to a scene.

Getting Started

The physics simulation extension omni.physx.bundle is enabled in Omniverse Create by default - if you are using another Omniverse App, you may enable the physics extension in the Window > Extensions window.

A great starting point for exploring physics are the demo scenes available in Window > Simulation > Demo Scenes: Just load a scene and hit play (see highlighted play button in the screenshot). We introduce the basic elements of a physics simulation with the Box on a plane snippet:

Basic Physics (UI) Elements

There are three key primitives (prims) on the snippet stage:

  1. The physicsScene prim provides simulation parameters such as gravity direction and magnitude, the simulation time-step size, and advanced solver algorithm settings.

  2. The boxActor prim is a cube shape that has rigid-body dynamics: it spins and falls under gravity.

  3. The groundPlane is a simple mesh that is configured as a static collider: It does not move but the box can collide with it.

You can configure the three prims, and their physics properties in particular, through the Property window (Window > Property). For example, the rigid-body options for the box reveal its initial 180-degree-per-second spin around its x-axis.

You can easily recreate the snippet setup with the following steps (you may want to clear the stage first with File > New):

  1. Create the ground plane mesh with Create > Mesh > Plane. You can scale it in x and z to make it larger.

  2. Configure the plane mesh as a static collider by right-clicking it in the viewport or stage tree, and selecting Add > Physics > Colliders Preset.

  3. Create the cube shape with Create > Shape > Cube and move it up above the plane, so it can fall.

  4. Configure the cube as a rigid body analogous to the plane but selecting Add > Physics > Rigid Body with Colliders Preset. Set its initial rotational velocity in x to 180 deg/s in the property window, see highlight above.

  5. Create the physics scene with Create > Physics > Physics Scene.

  6. Hit play and watch the cube spin and fall onto the plane.

Note that a shortcut to creating the ground plane is Create > Physics > Ground Plane.

Simulation Control

The settings that control your simulation are in four key places:

  1. The property window of the prims that are simulation objects, for example rigid bodies. In the property window, you can add and remove simulation components, and fine-tune properties such as mass, collision-shape approximation, etc.

  2. The property window of the Physics Scene that holds general simulation properties such as gravity and solver parameters.

  3. The Physics Settings window provides per-stage settings saved in USD metadata for portability; for example, settings include a lower bound on the simulation rate and mouse-interaction parameters.

  4. The Physics Preferences in Edit > Preferences provide general simulation settings such as the option to en/disable reset on stop.

  5. The layer metadata that USD uses to scale units (e.g. distance). The physics extension considers this scaling when parsing simulation parameters, so you should be aware of what scale you are authoring a simulation in.

Debug visualization

Visualizing for example collision-shape approximations may help you figure out issues with a simulation. There are many visualization and other debug options in the Physics Debug Window (Window > Simulation > Debug). In addition, you can enable feature-specific debug visualization in the Show/Hide (Eye) menu in the viewport:

Physics Debug Visualization Viewport Eye


Debug visualization can be slow for large scenes.

Mouse Interaction

Finally, it is fun and may be helpful for testing to interact with objects. You can push or grab objects by shift-clicking them in the viewport when the simulation is running. See the related settings and description in the Mouse Interaction Settings.

Property Window

In the Property Window (Window > Property), you can edit the physics properties of a prim, or you can add or remove simulation components (i.e. USD APIs).

You can add physics components with the Add button that shows a list of components that you may add to the selected prim. The list is context-sensitive and only shows physics components that are compatible with the prim and other physics components that the prim already has. Adding a component populates the Property Window with a new rollout that shows the component’s properties (i.e. API attributes).

Property Window Add Button

You may remove a component from a prim by clicking the red X that is shown with the component rollout:

Property Window Remove Button

A hint for editing numeric values: Ctrl-Click or double-click lets you edit the current value. If you want to reset values to their default, you can do so by clicking the blue square next to the value:

Property Window Reset to Default

You can hover over the name of a property to reveal a tooltip with further information about a parameter:

Property Window Attribute Tooltip

Physics Scene

The Physics Scene holds stage-wide (at the moment, see note below) simulation settings such as gravity. To create a scene, select Create > Physics > Physics Scene. Then, you can configure the scene settings in its property window. For details on the parameters, refer to their tool tips.


  • Currently, only a single simulation scene is supported that owns all simulation objects on the stage. In the future, the extension will support creating multiple scenes and assigning simulation objects to different scenes.

  • The extension creates a temporary default scene if simulation objects are detected but a physics scene is missing. You may disable this behavior in the Physics Preferences.

  • Often it makes sense to create physics objects such as a scene in their own USD layer.

Physics Materials

Materials defining properties of physics objects can be created with Create > Physics > Physics Material or added to an already existing Material prim through the Add > Physics menu.

A physics material can be assigned to a physics object in the Physics Materials on Selected Models rollout in the Property window, which binds the material to the prim with the ‘physics’ purpose. Physics materials follow the same resolution logic as render materials as they are both based on the same Material prim type.

One may define both render and physics properties on the same Material prim (e.g. to combine the visual and physical properties of rubber in a single material prim) and assign it in the “Materials on selected models” rollout.

Another option is to bind a material to the Physics Scene prim in the Physics default material rollout, and this material is used as a default when a physics object does not have a physics material bound to it after USD material resolve. Note that multiple physics material types (Rigid/Deformable/PBD Particle) can be added to the same material prim, so that the material bound to the Physics Scene can define defaults for all physics object types.

When parsing physics material properties of a prim the priority is then as follows:

  1. Material binding with a ‘physics’ purpose (physics material).

  2. Material binding with no purpose (render material).

  3. Material binding with a ‘physics’ purpose on the Physics Scene prim.

  4. Default values of material properties.

Physics Settings

Physics Settings are per-stage settings saved in USD metadata. You can view and change them through Window > Simulation > Settings. The Physics Settings window should be by default docked behind the Stage tab on the upper-right side.


You can configure what data the simulation writes back to USD (analogous to editing operations).

Update to USD

Enables writing object transforms back to USD. Expert setting that should be left enabled.

Update velocities to USD

Enables writing object velocities back to USD. If you do not need velocity information, you can disable the writeback to save some computational overhead.

Output Velocities in Local space

Display velocities in local coordinate space. The simulation also expects user changes to velocities (like initial velocity of a body) to be in local/global space according to this setting.

Update Force Sensors to USD

Enables writing articulation force sensor data back to USD. If you do not need data from sensors in the scene, you can disable the writeback to save some computational overhead.


Min Simulation Frame Rate

Sets the minimum simulation update rate in Hertz with respect to render-frame updates. In general, the Physics simulation runs in real (wall) time, so if rendering is slow, the simulation may take many steps at Time Steps Per Second to keep the Physics simulation state synchronized with wall time. This parameter limits how many steps the simulation may take to keep up synchronization. For example, if Min Simulation Frame Rate is 30Hz and the PhysicsScene Time Steps Per Second is 60 (Hz), the simulation takes at most two steps between render frame updates, no matter how long a frame render takes. This is a useful parameter when rendering a Physics scene to keep the simulation updates in lockstep with rendering: Just set Min Simulation Frame Rate equal to the Time Steps Per Second value.

Mouse Interaction

Mouse Interaction Enabled

Enables interaction with physics objects through shift-click if the simulation is running. For advanced physics-based authoring, refer to the Zero Gravity extension.

Mouse Grab

Toggles between grabbing behavior (enabled) and applying a push (disabled).

Mouse Grab With Force

Toggles between grabbing using a force (enabled) or using a D6 joint (disabled). Both the force and D6 are applied at the click (raycast) location.

Mouse Grab Force Coefficient

Scales the force used for grabbing. The grabbing force is proportional to the mass of the grabbed object and multiplied with this parameter.

Mouse Push Acceleration

Scales the push-acceleration applied to the object.

Physics Preferences

Besides the physics scene and physics settings, the Physics tab in Edit > Preferences provides global simulation-related settings.


Create Temporary Default PhysicsScene When Needed

Controls whether a scene is auto-created when you press Play and simulation objects are present but no PhysicsScene was added to the stage.

Reset simulation on stop

If enabled, the state (i.e. transforms, velocities) of the simulation objects is reset to the initial state before Play was pressed.

Use Active CUDA Context

If enabled, the PhysX simulation uses the currently active CUDA context for its GPU computations. If disabled, a new context is created for the simulation.

Reset Physics Preferences

Use this button to reset the values of the Physics preferences here, and the debug-visualization.

Backward Compatibility

Backward Compatibility Check on Scene Open

Configures the behavior of the physics USD backward compatibility module: In case of opening a scene with deprecated USD schema the extension can either ignore it, print out a warning to console, show a visual prompt to upgrade, or upgrade the scene automatically without prompting.

Run Backwards Compatibility On Current Stage

Manually trigger a backwards compatibility check and update on current stage.

Run Backwards Compatibility On Folder

Manually trigger a backwards compatibility check and update on a folder.


Num Simulation Threads

The number of simulation threads controls how many background threads are spawned and reserved for simulation.

Use PhysX CPU Dispatcher

Use internal PhysX task scheduler instead of the default one. Can be more efficient for some scenes.

Expose PhysX SDK Profiler Data

Adds PhysX SDK profiling zones to the Kit profiler.

Release Physics Cooked Data

Deletes cooked data (i.e. pre-optimized simulation data for collision meshes, etc.) for all prims on the stage from USD, i.e. deletes the corresponding API and attributes holding the data. Forces re-cooking of the data (if the local mesh cache is cleared as well).

Local Mesh Cache

Enable, set the size of, and release the local (disk) mesh cache that stores results from collision mesh approximations and Physics data cooking for reuse with identical geometry.


USD supports scaling of units through layer metadata that you may edit in the layer properties, see below. The default unit scaling for new stages can be set in the Stage tab of the Preferences Window.

Layer Units Metadata

The Physics extension scales default or auto-computed values by this metadata. For example, if Meters Per Unit is 0.01 (i.e. 1cm per unit), as you would set for assets that were authored at a centimeter-scale, the Physics extension sets the gravity magnitude of a newly created scene to 981.0 cm / s2. Any property value that you edit is assumed to be in the scale of the layer that it is authored in (see limitations in the note).


  • Time is never scaled and is always in seconds (Time Codes Per Second is not considered for physics simulation).

  • Automatic reconciliation of unit-scales between different layers is currently not supported, so you must ensure that all layers are authored at the same scale.

  • In order to run simulations in engineering SI units (except angles), set all scaling to 1.0. Related, you may change the stage up-axis in the layer metadata from graphics-default Y-up to Z-up that is more common in engineering.

  • Angles are represented in degrees and cannot be set to radians. All physics parameters that refer to rotation are in degrees as well: For example an angular drive of a revolute joint has its stiffness defined in units of torque/degrees.

Physics Debug Window

The Window > Simulation > Debug window should be the first place to look when physics simulation is generating unexpected results.

Simulation Control

In addition to running and stopping, you can Step the simulation one time step at a time, so you can inspect problems that happen very quickly.

Simulation Overrides

You can manually perform updates from USD or release simulation objects, and override the CPU/GPU and solver settings of the PhysicsScene.

Simulation Debug Visualization

You can enable and configure a low-level visualizer that renders directly based on the PhysX engine’s state, which is useful if for some reason the simulation is not in sync with USD. When you check the Enabled box, the different elements to visualize are presented. Note that data is only visualized when the simulation is running. The Scale field can be used to adjust the length of some lines and arrows.

Note that 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 may appear to lag one frame behind the graphics rendering.

Deformable Debug Visualization

Configure the options for deformable bodies.

Collision Mesh Debug Visualization

In addition to the wireframe debug visualization available in the viewport show/hide menu, you can visualize the collision-mesh approximations using solid render meshes. You may also inspect a convex decomposition using the explode-view distance.


Enable and configure PVD data logging by the PhysX PVD logger, which can be helpful to inspect the PhysX simulation objects created from USD data.


Sleeping is a mechanism in PhysX to save on computational resources when dynamic physics objects (e.g. rigid or deformable bodies) are not in motion and do not require simulation updates. If an object is not moving for a short time duration, it may go to sleep until it is woken up either by

  • the user when they set a property that causes the object to move again, for example applying a force on a rigid body or changing the target position of an articulation joint drive;

  • or the simulation when another object collides or interacts with the sleeping object, such that the sleeping object may move again.

For the different dynamic object types, e.g. rigid bodies, articulations, or deformable bodies, you will find sleep-related properties such as a flag to have the rigid body start a simulation asleep, or the thresholds that PhysX uses to determine if an object is not moving and may be put to sleep. If you set those thresholds to zero, you can disable sleeping altogether on the object.


There is a subtle connection between sleeping and effective solver iterations (e.g. position and velocity iteration settings): In a GPU simulation, it is computationally efficient to apply the same number of iterations to all objects in the scene; and this number will be equal to the maximal iteration setting over all physics objects in the scene that are not asleep. Especially for deformable bodies whose dynamics can be affected when the effective iteration count changes, this is important to keep in mind: For example, if you have two deformable bodies with 20 and 40 iterations each in a scene and both are awake, the solver will apply 40 iterations to both. However, if the body with 40 iterations goes to sleep, the other body will only have 20 iterations applied to it, which may change its behavior.

Rigid-Body Simulation

Rigid bodies and static colliders are the foundational building blocks that you can use to add physics to your scene. You can add rigid body dynamics to a geometry in your scene so that it accelerates under gravity and collides with other physics objects (including deformables and fluid), and create static physics objects by adding collision to scene geometry (e.g. a basic ground plane).

For further, in-depth technical detail on the rigid-body simulation standard in USD, you may refer to the Proposal.

Adding Dynamics to a Geometry

Any prim that has a transform can be made into a rigid body (i.e. any USD Xformable-derived prim). Examples include geometric shapes like Cube or Sphere, or Mesh prims. Adding rigid-body simulation to a prim is straightforward: Either right-click the prim in the viewport or stage tree, or use the Add Button in the prim’s property window, and do Add > Physics > Rigid Body with Colliders Preset.

The name of the preset highlights the two main components that a dynamic rigid body typically has:

  1. A rigid body component which provides dynamics-related properties such as linear and angular velocity, or whether the body is kinematic.

  2. a collision component which is applied to body geometry that defines the collision-shape which determines how the body collides with other collision-enabled objects on the stage (e.g. a ground plane or a deformable body), and provides related properties, see Collision Settings.

You may configure the rigid-body and collision parameters in the corresponding rollouts in the Property Window. For details on the parameters, refer to the tool tips.

The typical USD and physics component structure that you encounter when you turn assets into rigid-bodies is that of a compound-shape rigid body.

Static Colliders

If you apply only the collision component to an asset with Add > Physics > Colliders Preset, you create a Static Collider. Static colliders do not move (unless you move them) but still collide with other Physics objects (e.g. rigid or deformable bodies). Therefore, this is the configuration you should choose, for example, for the floor and walls of a physics-enabled room scene. A very simple static collider is the Physics ground plane that you can add to a scene with Create > Physics > Ground Plane.

Note that the Colliders Preset traverses all descendants of the target prim and applies a separate collider component to every suitable descendant so that assets consisting of multiple meshes become a single compound static collider. Of course, you can apply the component to specific meshes of an asset as well: Just use Add > Physics > Collider on the target meshes.

Compound-Shape Rigid Bodies and USD Hierarchy

Typically, graphics assets consist of several meshes that should move together. The Rigid Body with Colliders Preset provides automation to achieve this when you apply it to the common (USD-hierarchy) parent of the meshes that should move together. Let us look at an example of two barstools falling onto static-collider cubes:

The right stool is a compound rigid body, while the left stool is four separate rigid bodies corresponding to each of the meshes of the asset. In the USD stage, the compound stool’s structure and component-assignments are as follows:

Compound barstool USD stage structure

I.e. the preset applied the rigid body component to the parent Xform and then traversed all the descendants of the Xform while applying the Colliders Preset to any geometry it encountered. The result is the compound stool.

For the left stool, we applied the preset to each of the four meshes, so there is no rigid-body component on the parent Xform, but each collider component also has a rigid-body component in addition.

In the video, you may have noticed that the collision of the stool’s legs with the cubes are not reflecting the actual geometry of the legs. This is due to the default convex-hull collision-geometry approximation that the preset applies. See Collision Settings for further information and a video of the stools with improved collision approximation.

A compound-structure with just a single collision geometry can also be useful to create a rigid body that has separate collision and visualization geometries. A simple example is:

Custom-Collision Rigid Body USD Structure

The rigid-body component is applied to the parent Xform, the sphere shape serves as visualization, and the capsule provides the collision geometry. The capsule is excluded from rendering by setting the render Purpose to guide in the Visual property-window rollout. A possible intent is to make the sphere roll along a straight line more easily; in more complex, Mesh-based geometry applications you can use this approach to fine-tune the collision geometry of a high-detail visual mesh.


  • You cannot nest rigid bodies - any rigid-body component found among the USD-hierarchy descendants of a prim with a rigid-body component is ignored. Except if that descendant’s transform op stack has a resetXformStack op.

  • You may animate, i.e. change the relative transforms of the nested collision geometries making up the rigid body, which updates the inertial properties of the compound rigid body. However, such an animation does not impart momentum onto the compound; if that is your intent, you should use Articulations or separate rigid bodies with Joints instead.

Kinematic Rigid Bodies

The rigid-body rollout provides a checkbox to make the rigid body kinematic. The resulting simulation object is similar to a static collider: It only moves if you change its transform through the UI, or through a script or animation. However, the advantage of using a kinematic body for animation is that the simulation infers a continuous velocity for the body from the transforms (i.e. keyframes) that you provide, and this velocity is imparted to dynamic bodies during collisions, which results in higher simulation fidelity.

Another way to think about dynamic vs. kinematic rigid bodies is in terms of transform read/write access by the simulation engine: A dynamic body has its transform written to by the simulation, while a kinematic rigid body’s transform is read by the simulation (static colliders are also read-only).

Instancing Rigid Bodies

There are two approaches to increasing performance when dealing with many identical rigid bodies (or colliders) in a scene: USD Scenegraph Instancing and the USD Point Instancer. Both reduce the size of the USD scene graph which in turn increases performance and reduces the scene’s memory footprint.


When you drag-and-drop an asset from the Content Window into the stage, you are creating a reference to the asset. If you require many copies of the asset in your scene, it is best to turn the references into instances. You can achieve this by enabling the Instanceable flag in the property window:

Instance Flag

Instancing is straightforward if you are creating duplicates of static colliders, but for rigid bodies there is an important consideration: The Rigid Body component must be added to each instance and not the referenced asset (i.e. master/prototype). The reason for this is that the rigid-body component provides properties that describe the state of the object (e.g. its linear velocity) which are unique for each instance, and, therefore, the instances cannot share a single rigid-body component on the referenced asset. A typical rigid-body instancing setup would be as follows:

  1. Add the collider component to the source asset (considering the limitations on mesh-approximations for rigid bodies)

  2. Create a reference to the asset using drag-and-drop from the content window

  3. Enable the Instanceable flag on the reference

  4. Add the Rigid Body component to the reference (you do not need the preset that also applies the collider, as the source asset already provides it to all instances)

  5. Create duplicates of the instanceable rigid body

If you create instances of a static collider, you can skip the rigid-body-component-adding step.

Point Instancer

An alternative approach is the USD Point Instancer feature. Currently, you can only create a point instancer via the Python API, so you best refer to the Instanced box on a plane snippet source code in the physics demo scenes for more information. The advantage of the point instancer is that it provides a vectorized interface to the poses and velocities of the instances.

Mass Properties

By default, the mass of a dynamic rigid body is derived from the volume of its collision geometry, multiplied by a density. For compounds, the mass is the sum of the masses of its collision geometries, see below. Unless a density is specified explicitly, a default of 1000 kg/m3 is used (scaled to scene units).

One can set an explicit density in two ways: 1) By binding a physics material to the collision geometry, or 2) by adding a Mass component (Add > Physics > Mass) to the collision geometry or a rigid-body ancestor. A density specified in a Mass component overrides any material density.

You can also use the Mass component to set the mass of a collision geometry directly. An explicit mass overrides any densities specified on the geometry. In summary, the precedence is:

Default 1000kg/m3 < Material density < Mass-component density < Mass-component mass

Note that if there is no collision geometry to derive mass via density, the mass defaults to 1.0 mass units.

Compounds and USD Hierarchy

For compounds, you can specify mass properties for each of the collision geometries following the precedence rule above. A collision geometry of a compound may inherit an explicit density set on an ancestor, so there are additional USD-hierarchical precedence rules:

  • Ancestors’ mass properties override descendants’ properties according to the precedence rule above.

  • For equal-level precedence, e.g. Mass-component density, the descendants specific values override the ancestor specifications.

This is not straightforward to parse, so we illustrate it further with the barstool example in the Compounds Section: We can add a Mass component to the stool rigid-body Xform and set a homogeneous density (e.g. the density of wood): The stool mass is then equal to the sum of the collision-geometry volumes times this explicit density.

Alternatively, we could model the stool’s mass more accurately by considering the fabric seat’s lower density. We apply a Mass component to the fabric seat and set it to the lower density. The stool parts without a density specified then use the overall (wood) density while the seat uses the lower density when the overall mass is computed.

If in addition, we specify a mass with the Mass component on the stool rigid-body Xform, all the densities we set earlier are ignored due to the precedent rule and the stool’s specified mass is homogeneously distributed among the collision geometry meshes.

Collision Settings

Collisions enable rigid bodies to interact with each other and a static-collider environment. The key parameters that determine collision behavior are:

Rigid-Body Collision Mesh Approximation

For dynamic rigid bodies, PhysX currently does not support using the asset (triangle) mesh directly for collision. The mesh geometry must be approximated with one of these four methods available in the Collider rollout of the property window:

Mesh Approximation for Rigid Bodies

The pink lines represent the Collider debug visualization that is useful for analyzing the generated approximations. From left to right are:

  1. Convex Hull: PhysX computes a convex hull for the asset mesh. If you require a tighter approximation or representing concave features, choose a Convex Decomposition instead.

  2. Convex Decomposition: PhysX performs a convex decomposition where the input mesh is approximated by several convex shapes. This allows approximating hollow meshes such as the cup above.

  3. A bounding sphere.

  4. A bounding box.


  • For both convex approximations, the vertex count per convex shape is limited to 60 for GPU acceleration support.

Static-Collider Collision Mesh Approximation

In addition to the rigid-body approximation methods, static colliders support triangle-mesh collision. Often, you can reduce the mesh complexity without losing much detail by selecting the mesh simplification option, see the right simplified cup mesh vs. the original on the left:

Mesh Approximation for Rigid Bodies

Note the short lines sticking out from the collider debug visualization mesh are the normals, which allow you to determine the orientation of the mesh faces, see note below.


  • Physics treats meshes as single sided for collision purposes, i.e. collisions only occur with the meshes’ front. In contrast, Omniverse renders all meshes as double-sided by default. This discrepancy may result in a scene that has unexpected collision behavior while rendering fine. We recommend that in the Rendering > Render Settings window, under the Common tab, users authoring physics colliders enable Geometry > Back Face Culling so it becomes clear which faces are front versus back facing.

  • If a mesh has faces facing the wrong way, they can be inverted using the Geometry > Orientation dropdown in the Property window of the mesh.

  • You can inspect the normals drawn onto the collider debug visualization to determine the orientation (see the cups’ triangle-mesh debug visualization above).

Barstools Revisited

In the barstool example above, the collision geometry is not well captured by the default convex-hull approximation and the hollow space between the legs collides with the cube. We can fix this by changing the collision approximation of the leg meshes to convex decomposition. The resulting collision is more accurate:

Note that changing the collision approximation and the associated geometry may impact the rigid body’s mass distribution if mass properties are computed from the collision geometry (e.g. by a specified density).


PhysX supports exact representations for Cube, Capsule, and Sphere shapes, so no approximations are required. By default, the Cone and Cylinder shapes are approximated with a convex hull. However, PhysX supports exact representation of the Cone and Cylinder as well if you enable the Custom Geometry flag in their Collider settings. Note that enabling the Custom Geometry flag currently incurs a performance penalty in a (by default) GPU simulation because part of the collision code runs on the CPU.


Besides the Collider properties, collision parameters are available in the Physics Material of the collision shape. For further details on the parameters, we refer to their tool tips. The offset parameters are explained in more detail below:

The Collision Offset defines a small distance from the surface of the collision geometry at which contacts start being generated. The default value is -inf which means that the application tries to determine a suitable value based on scene gravity, simulation frame rate and object size. Increase this parameter if fast-moving objects are missing collisions, i.e. tunnel (alternatively, check Enable CCD in the rigid body and the PhysicsScene for swept contact detection). Increasing the offset too much incurs a performance penalty since more contacts are generated between objects that need to be processed at each simulation step.

The Rest Offset defines a small distance from the surface of the collision geometry at which the effective contact with the shape takes place. It can be both positive and negative, and may be useful in cases where the visualization mesh is slightly smaller than the collision geometry: setting an appropriate negative rest offset results in the contact occurring at the visually correct distance.

Rigid-Body Materials

Rigid-body physics materials provide friction, restitution (a.k.a. ‘bounciness’), and material density properties. See the precedence rules in Instancing Rigid Bodies for density defined via materials. Static collider’s meshes support multiple materials by assigning materials to geometry subsets; see the Triangle Mesh Multimaterial snippet in the physics demo scenes for more information.

If a rigid body or static collider does not have an assigned material, a default material is applied with dynamic friction = static friction = restitution = 0.5. You may change the default material properties by binding a physics material to the Physics Scene. See also the Physics Material section for general physics material information.

Collision Filtering

The Physics extension supports collision filtering that you can use to disable collision between pairs and groups of physics objects (including rigid and deformable bodies, and articulations).

Collision Groups

You can create Collision Groups that are sets of colliders. The groups can be configured to enable or disable collisions between them.

Create a new group with Create > Physics > Collision Group. Then you can add colliders to its Includes and Excludes relationships, subject to inheritance rules defined by the Expansion Rule.

All objects in the same collision group collide with each other. By default, objects in two different collision groups also collide, but you can disable collisions between groups by adding to their Filtered Groups relationship. The PhysicsScene provides a flag Invert Collision Group Filter that lets you invert this behavior so that by default, different groups do not collide, except for Filtered Groups-specified collisions.


  • Currently, collision groups cannot be changed during simulation and require stopping and restarting the simulation. This will be addressed in a future release.

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 disables collision between the selected objects and their property windows have a Filtered Pairs rollout added. Pairwise filters have precedence over collision groups.


  • Currently, pair filtering cannot be changed during simulation and requires stopping and restarting the simulation. This will be addressed in a future release.


Joints give you the ability to connect physics objects by defining how the objects may move relative to each other. For example, a revolute joint can be used to connect a wheel to a car’s chassis: It allows the wheel to rotate around a single axis.

Joints may create connections between all types of rigid objects, i.e. dynamic and kinematic rigid bodies, static colliders, and also Articulations (i.e. their rigid-body links in particular). It is also possible to connect objects to the static world coordinate frame if you leave one of the joint’s Body relationships empty (which is then implicitly relating to the world frame).

In the overview table about joint types, you also find information about what joints can be simulated natively by Articulations and are compatible with, i.e. can create connections to articulation links.

Debug Visualization of the joints not only displays the joints and their frames, but allows authoring of the joint frames as well - just enable Joints in the Debug Visualization viewport options.


Explore the different joint motions with the Physics Demo Snippets that are available for each of the joint types.





The revolute joint allows rotation about a single axis.



The prismatic joint allows linear motion along a single axis.



The spherical joint allows rotation about three axes, i.e. a ball-in-socket-type joint.



The D6 joint can be configured to allow between zero and six degrees of relative motion, i.e. up to three linear plus three rotational motions. Use Joint Limits to lock individual axes. Articulations can natively simulate D6 joints with 1-3 unlocked rotational motions (all linear motion must be locked).



The fixed joint allows no relative motion. It is particularly useful when building fixed-base Articulations.



The distance joint allows any relative motion but limits how far apart the connected rigid bodies may be (in particular their joint frames).



The gear joint couples the rotations of two revolute joints by a gear ratio. See the snippet and its Python code for details.



The rack-and-pinion joint couples the rotation of a revolute joint to the travel of a prismatic joint by a gear ratio (rotation/distance). See the snippet and its Python code for details.


Joint Frames

Each of the two physics objects that are connected by a joint has an associated joint frame. The joint frame is fixed and positioned in the body’s local frame using the Local Position 0/1 and Local Rotation 0/1 properties.

Any joint motion is relative to the bodies’ configuration where the two joint frames are aligned: For example, a revolute joint configured to rotate around the x-axis allows rotation of the two body frames about their shared x axis, and at zero joint angle, the two frames are aligned. An offset is illustrated in the following revolute joint example:

Joint Frames

The revolute joint connects the red and blue geometries that are configured as a static collider (red) and dynamic rigid body (blue) respectively. Let us focus on the Local Rotations first. The Local Rotation 0 for box0 is thirty degrees around x which is reflected in the joint-frame visualization. As soon as the simulation is started, the blue box will rotate up to align its frame (that is not rotated). The thirty degree Joint Limit is relative to the aligned frames as well (see the see red lines and arc visualization).

In the same example, you will notice the different values used to define the (y) local positions of the frames: 0.6 and -60.0. The reason is that joint positions scale together with a body. In the example, the red box0 is created from a unit-cube with side-length 1.0 which is then scaled by 10.0, 100.0, 10.0 in x, y, and z, respectively. The blue box1 is created from a cube with side-length 100.0 which is scaled by 0.1, 1.0, 0.1 in x, y, and z, respectively. Therefore, both geometries have the same world dimensions, but their different scaling results in the joint frames being correctly positioned by the 0.6 (times 100.0) and -60 in y, respectively.

Joint Limits

Some joints provide limit properties directly in their corresponding rollout, so you can configure ranges for the relative motion that the joints allow (e.g. thirty degrees rotation in the revolute joint example above).

For the D6 joints, you can add limit components in order to lock or limit specific axes with Add > Physics > Limit in the D6’s property window. In order to lock an axis, set the lower limit to above the high limit. See the D6 Joint snippet in the demo scenes as well.


Due to differences in the underlying PhysX implementation, spherical joint limits are pyramidal in native articulation joints, and conical for regular spherical joints.

Joint Drives

Many joints support adding drives so you can physically actuate a mechanism (vs. kinematic animation). For example, you can add a drive to a revolute joint that connects a wheel to a car to make it move. Add the drive with Add > Physics > (type) Drive where the type will be context-sensitive and describing the motion of the drive (e.g. angular for a revolute joint).

Drives apply a force to the joint to maintain a position and/or a velocity that is proportional to

stiffness * (position - target_position) + damping * (velocity - target_velocity)

so the stiffer you configure the drive, the harder it will push the bodies to satisfy a given target position for the drive. Damping is analogous for the joint velocity, and you can implement a velocity drive by setting stiffness to zero.


Spherical joints currently do not support drives, but you may configure a D6 joint with drives to get the same driven motion, including native simulation support in articulations.


Articulations provide an alternative, often superior approach to creating mechanisms over adding joints to rigid bodies. Typically, you achieve higher simulation fidelity with articulations as they have zero joint error by design, and can handle larger mass ratios between the jointed bodies. PhysX simulates articulations in reduced-coordinates, where the configuration of the articulation is determined by its root body and the joint angles instead of the world pose of each body involved.

You can often turn jointed rigid bodies into an articulation if they do not contain unsupported joints, see the Joint Table, and making sure that loops are resolved appropriately. To enable articulation simulation on jointed rigid bodies, apply the articulation root component to the appropriate prim.

Articulation Tree Structure

Articulations must have a tree structure in terms of the rigid-body links and the joints between them (loops are possible, however). The tree structure is created solely by the Body 0 and Body 1 relationships of the joints connecting the articulation links (i.e. rigid bodies) - the USD hierarchy has no impact on the articulation structure other than during parsing, see below. Therefore, you may organize the joints and links in the stage tree as you see fit.

Here are two example articulations: A ragdoll and a robotic arm.

Articulation examples

The tree structure for the arm is straightforward: The root is at the base on the ground plane, and revolute joints connect the different links up to the manipulator, where the tree has its only branch to connect the two gripper parts to the arm through prismatic (i.e. linear) joints.

For the ragdoll, we can choose any link, i.e. limb as the root and the resulting structure is always a tree. For example, we can choose the head to be the root, and connect the torso to it with a spherical joint, which in turn uses spherical joints to attach the arms, and so on.

Floating and Fixed-Base

There is a key difference between the two articulation examples: The ragdoll is a floating articulation which means the root (e.g. the head) may move freely in space.

The robot arm is a fixed-base articulation: Its root or base is fixed to the world frame.

USD Hierarchy / Articulation Root

You should consider the USD hierarchy when you apply the Articulation Root component to a prim such that one or more articulations are created.

The rules are as follows:

For a fixed-base articulation, add the Articulation Root component either to: 1) the fixed joint that connects the articulation base to the world, or 2) an ancestor of the fixed joint in the USD hierarchy. The second option allows creating multiple articulations from a single root component added to the scene: Each descendant fixed joint will be defining an articulation base link.

In the robotic-arm example above, we connect the robot’s base to the world frame using a fixed joint, and then could, for example, apply the root component to this joint.

For a floating-base articulation, add the Articulation Root component either to: 1) the root rigid-body link or 2) an ancestor of the root link in the USD hierarchy.

In the ragdoll example, we could, for example, apply the root component to the head link.


When you use extensions that access the underlying PhysX articulation data (e.g. omni.physx.tensors), it is beneficial to set up articulations such that their USD and PhysX topologies are identical - only then do you get a one-to-one relationship between USD and PhysX joint parameters such as limits and drive targets. The USD physics interface must provide identical behavior for articulation and regular joints, and it may therefore swap joint limits or negate joint drive targets when parsing from USD to the PhysX articulation; this is because USD joints do not have to follow the articulation topology, i.e. it may be that the body0 relationship does not point to the parent link in the PhysX articulation, but the USD joint limit is defined in the body0 to body1 joint frame order.

Closing Loops

While articulations natively only support tree-structures, it is possible to create loops in the articulation by adding joints between articulation links that have the Exclude from Articulation flag enabled. For example, we could tie the ragdoll’s hands together by adding a distance joint between the two hand spheres.


It is currently not possible to set articulation joint positions directly or while the simulation is running. In order to set joint positions, use joint frame poses before starting the simulation.


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.

Debug Visualization

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.

Fixed Tendons

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 two gearing attributes are set to 1 and -1 respectively, such that the joint angles are equal if the tendon constrains its length to zero.

The fixed tendon enforces constraints on this length by applying spring-damper forces to the joints, like a joint drive, that are parametrized by the Stiffness and Damping attributes, and a per-axis Force Coefficient that scales the force applied at each axis, i.e. joint. In the demo, the tendon should only apply forces to the second, passive joint, so we set the force coefficient to zero for the drive-joint axis, and to -1 for the passive joint. It must be -1 in order for the tendon to drive the joint in the correct direction that reduces constraint violations.

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.

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.

Fixed Tendon Axis Add Menu

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.

Debug Visualization

Fixed-Tendon Debug Visualization

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.

Spatial Tendons

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:

  1. 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.

  2. 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.

  3. 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 PhysxTendonAttachmentRootAPI.

Creating a Spatial Tendon

Spatial Tendon Axis Add Menu

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:

  1. Add a Spatial Tendon Root Attachment to an articulation link.

  2. 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).

  3. Add a Spatial Tendon Leaf Attachment to terminate a sub-tendon, i.e. branch of the tendon tree.

  4. Configure the connectivity of the tendon by defining the attachments’ parents (see the Authoring hints below for a graphical approach to this).

  5. Configure gearings and the tendon-wide and sub-tendon parameters in the root and leaf, respectively.

Authoring and Debug Visualization

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:

Force Sensors

You can attach force sensors to an articulation link in order to read out forces and torques acting on the link. The sensor is analogous to an inertial-measurement-unit (IMU) sensor on the link, except that you measure the forces and torques resulting in the accelerations that an IMU would report. You can add a sensor to a link as follows:

  1. Create an Xform descendant of the articulation link. The Xform’s relative transformation to the link defines the pose of the sensor in the link frame.

An Xform child of an articulation link that describes the sensor's local pose in the link frame.
  1. Add the Physics Articulation Force Sensor component to the Xform.

  2. Ensure that Update Force Sensors to USD is enabled in the Physics Preferences.

  3. Read out the sensor in the Articulation Force Sensor rollout in the Xform’s property window.

You may also apply the sensor component directly to the link geometry; in this case, the sensor pose coincides with the link pose. In the property window you may further define in what coordinate frame the forces are reported in, and which force components should be added to the sensor readout.

Character Controller

A character controller (CCT) is a video-game-style movement controller that permits the player to move around a scene without being able to go through physics objects, for example a static-collider wall of a scene, or a dynamic rigid-body geometry. It is straightforward to use a CCT in a scene:

  1. Make sure that the omni.physx.cct extension is loaded.

  2. Create a capsule shape (Create > Shape > Capsule) and scale it to fit the scene. The capsule represents the player’s collision shape (other shapes are not supported).

  3. Pull up the CCT window Window > Simulation > Character Controller, and press the Activate button with the capsule-shape prim selected. This hides the capsule and gives it CCT properties.

  4. Press play and take control of the CCT to explore the scene while colliding with physics objects.

Note that creating a capsule is optional - if you activate the CCT without anything selected, one is auto-created for you.

The CCT behavior can be tweaked through Python scripting: For example, you can add a key binding and scripting to make the CCT jump. In the Window > Simulation > Demo Scenes Character Controller snippet, you can find example code for this. Another advanced example of CCT scripting is available in the Block World extension (omni.blockworld) which then adds the Block world sample to the General Samples available in the demo scenes.

Deformable-Body Simulation

PhysX features GPU-accelerated finite-element-method (FEM) simulation that allows you to add deformable-body dynamics to mesh assets. As a simple example, compare a deformable-body to a rigid-body barrel:

You can create a deformable body from a mesh-geometry asset with the Add Button in the mesh’s property window: Choose Add > Physics > Deformable Body. This command not only adds the deformable-body component to the mesh, but also generates the collision and simulation tetrahedral (tet) meshes from the source mesh for the PhysX engine:

Deformable-body meshes

Note that we spatially separated the (usually co-located) meshes of the barrel, which are, from left to right:

  1. The visualization (i.e. the source asset) mesh.

  2. The collision tetmesh that PhysX uses to resolve collisions with other physics objects.

  3. The simulation tetmesh that PhysX uses to run the FEM simulation, and that drives both the collision and visualization meshes through an embedding, i.e. skinning. Note that it is not an issue that the generated simulation mesh is bigger than the visualization and collision meshes; this is typically the case.

The collision and simulation meshes above are the Debug Visualization for deformables that you can use to inspect the generated meshes. See the mesh simplification section in the component parameters for more information about the mesh generation.

The dynamics of the deformable body are configured in 1) the component parameters available in the Deformable Body rollout in the property window and 2) the Deformable-Body Material that you can create and bind to the deformable body (analogous to rigid-body materials).


  • You cannot create compound deformable bodies analogous to compound rigid bodies. If you want to create a single deformable body from a set of source meshes, you need to first fuse the meshes with an external tool.

  • CPU simulation of deformable bodies is not supported, so you must have GPU simulation enabled in the Physics Scene (it is enabled by default).

Debug Visualization

You can enable visualization of the collision and simulation tetmeshes of the selected or all deformable bodies with the viewport show/hide options (the eye):

Deformable-body debug visualization

The gap size used for tetmesh visualization can be adjusted in the Deformable Debug Visualization rollout in the Physics Debug Window (Window > Simulation > Debug).

Deformable-Body Material

The material properties define, for example, how stiff the body will be with the Young’s Modulus, or the body’s dynamic friction against other objects. The steps to bind a material to a body are analogous to the rigid-body materials:

  1. Use Create > Physics > Physics Material, and create a new Deformable Body Material.

  2. Configure the material parameters - refer to the tool tips for further information.

  3. Bind the material to the deformable body (mesh) in the Physics Materials on Selected Objects rollout in its property window.

When a deformable body does not have a defined material, it will use default parameters that are identical to the parameters of a newly created deformable-body material. See also the Physics Material section for general physics material information.

Deformable-Body Component Parameters

In the Deformable Body rollout, you can configure parameters that mostly affect the PhysX FEM solver algorithm. We discuss a selection of the parameters and considerations below; for the remaining parameters, please refer to their tool tips for further information.

Solver Convergence

Two parameters that have an impact on solver convergence for a deformable body are the simulation-mesh resolution and the solver position iterations: The higher the resolution, the more solver iterations you typically need. Increasing the resolution may be necessary to capture finer details of the source visualization mesh.

We illustrate this in an example: The left barrel is created with default parameters; the right barrel has identical parameters, except that it has twice the simulation mesh resolution. The position iterations are left at their default value of sixteen.

The right, higher-resolution barrel appears to be softer, despite having the same Young’s Modulus, i.e. stiffness than the left barrel. This is because the default number of iterations are too low for the solver to converge for the higher complexity of the right barrel. You should be aware of the fact that sometimes, softness does not result from the material properties that you set, but may be caused by insufficient solver iterations that are applied. A good approach is to compare the behavior at different iteration counts when choosing an appropriate value. See also the note below about effective solver iterations when several physics objects are present in the scene.

Here is the same scene as above, but with four times more solver position iterations:

With the higher iteration count, we obtain better convergence and closer behavior of the identical-material but different-resolution barrels.


  • The number of solver iterations that are applied to a deformable body depends on all objects in the scene that are not asleep, see the note in Sleeping.

  • A higher iteration count results in a higher computational load and will affect performance. Therefore, you should strike an appropriate balance between simulation fidelity and iteration count.

Collision Mesh Simplification

The asset visualization mesh is pre-processed by default when you create a deformable body. The preprocessing is designed to help generate tetmeshes that are well-suited for the simulation engine. The default pipeline is as follows:

  1. Remesh the input mesh by reconstructing its triangles on a voxel grid.

  2. Simplify the remeshed input mesh using quadric mesh simplification.

  3. Create the collision tetmesh from the simplified mesh.

  4. Create the voxel tetmesh from the collision tetmesh.

What each step does is illustrated in this two-dimensional example:

Deformable-body mesh simplification

You can fully parametrize the simplification pipeline:



Collision Mesh Simplification

Enables/disables both remeshing and simplification steps. If disabled, the input mesh is triangulated, if necessary, and then tetrahedralized to obtain the collision tetmesh.

Enable Remeshing

Enables/disables the remeshing step before simplification.

Remeshing Resolution

The voxel grid resolution used for remeshing; Autocomputed by default which determines an appropriate resolution from a heuristic. The autocomputed resolution is typically high; manually lowering the resolution may help removing unwanted details of the asset mesh, or with asset meshes that are not watertight.

Target Triangle Count

The target mesh resolution for quadric simplification; Autocomputed by default which determines an appropriate target count from a heuristic.

Self-Collision Filter Distance

If the initial, i.e. rest pose of the deformable body results in undesired self-collisions affecting behavior, adjust this parameter to slightly larger than two times the contact offset.


A deformable body can be attached to primitives which have one of the following components:

  • Collider

  • Rigid Body

  • Deformable Body

Deformable Body - Collider/Rigid Body Attachments

Attachments between a Deformable Body and a Collider/Rigid Body can be created as follows:

  1. Move both primitives into an overlapping pose

  2. Select both primitives

  3. Create > Physics > Attachment

Posing Deformable-body for attaching to Collider

The attachment can be visualized using the show/hide menu in the Viewport:

Debug Visualization: Attachment Points (Pink) and Filter Tetrahedra (Cyan)

The debug visualization shows two elements of an attachment:

  • Attachment points (Pink)

  • Filtered tetrahedra (Cyan)

The filtering is needed to prevent collisions between tetrahedra of the deformable and the collider. Omitting filtering would result in jittering. Both attachment-point placement and filtering can be adjusted in the Compute Auto Attachment section of the attachment properties:

Controls to configure automatic generation of attachment points and filtering.



Attach Overlapping Vertices

Enables creating attachment points at collision-mesh-vertex locations. Vertices are attached if they are close to the collider volume.

Overlap Offset

Defines how close vertices need to be to the collider volume in order to be attached.

Attach Rigid Surface

Enables creating attachment points on the surface of the collider volume at locations that are contained by the volume defined by the deformable collision mesh.

Surface Sampling Distance

Distance at which collider-surface locations are sampled as attachment points.

Illustration of how attachment points are selected based on auto attachment computation parameter.

Collision Filtering

Enables collision filtering of deformable collision-mesh tetrahedra.

Filtering Offset

Defines at which distance to the collider volume filtering takes place.

Illustration of how filtered tetrahedra are selected based on auto attachment computation parameter.

Deformable Body - Deformable Body Attachments

Debug visualization of two attached Deformable Bodies.

Attachments between two Deformable Bodies can be created in the same way as attachments between Deformable Bodies and Colliders/Rigid Bodies. For deformable-deformable attachments, collision-mesh vertices of both deformables are considered. Only vertices that are contained in the intersection volume defined by both tetrahedral meshes are used as attachment points:

Illustration of which collision mesh vertices get selected as attachment points.


  • The Overlap Offset parameter is not supported, as deforming locations outside of the deformable volume is ill-defined.

  • Both Attach Rigid Surface and Surface Sampling Distance are not supported.

  • Advanced/Enable Deformable Collision Filtering Pairs allows for exact pairwise tetrahedral collision filtering. If enabled, any part of one deformable can still collide with filtered parts of the other deformable if the parts are sufficiently distant in the rest pose. Depending on the geometry and the stiffness of the deformables this might be required, but usually it is not.

Particle Simulation

PhysX features GPU-accelerated position-based-dynamics (PBD) particle simulation that allows you to add fluids, granular media, and cloth to a scene. The particle objects can interact with all other simulation objects such as articulations, and rigid/deformable bodies. This video shows the Paint Ball Emitter demo where particle fluid balls are launched onto collider plane. It is available in the Window > Simulation > Demo Scenes window.


  • The particles schema is not finalized and may change in the future.

  • CPU simulation of particles is not supported, so you must have GPU simulation enabled in the Physics Scene (it is enabled by default).

  • For more technical background of the underlying simulation, refer to Position Based Fluids by Macklin and Müller.

Simulation Components

A particle simulation consists of a few key components:

  1. Particle objects to simulate, which are sets or cloths; see below for steps to create the objects.

  2. A particle system prim that you may create with Create > Physics > Particle System.

  3. A PBD Particle Material that you may create with Create > Physics > Physics Material, or add to an existing material using Add > Physics > PBD Material (in this menu, you may also find parameter presets for water and viscous fluid). See also the Physics Material section for general physics material information.

The particle objects are associated with a particle system, which has attributes that define simulation behavior that is common across all its objects. Additional simulation parameters are provided by the PBD Particle Material that is bound to the particle system as a physics material. The PBD material attributes are also shared between all objects associated with the particle system. Some material attributes only apply to specific object types: For example, the material drag parameter only applies to cloth objects, while cohesion only applies to fluid particles.

Multiple particle systems per stage are supported; however, particles in different systems cannot collide with each other.


In a future version of this feature, per-object materials will be supported.

Particle System Configuration

Many simulation parameters are attributes of the particle system or its bound PBD particle material. For information about most of these attributes, we refer to their tool tips. However, the various contact and rest offsets that the user should configure can be difficult to grasp from the descriptions alone, so we add further information here. First, we consider

Particle-Particle Interaction

For solid particles, the parameters can be sketched (in 2D) as follows:

Solid particle contact offsets

First, the size of solid particles is governed by the Solid Rest Offset parameter: Two solid particles are touching when their centers are two times Solid Rest Offset apart. The same distance also defines when fluid and solid particles are touching. In particular, the Fluid Rest Offset only affects fluid particle-particle interaction as follows:

The Fluid Rest Offset cannot be considered to be the radius of a fluid particle as with solid particles. However, the radius is used together with the particle mass to determine the rest density of the fluid that the solver uses as a target density (i.e. constraint density).

The simulation generates a neighborhood for each (fluid and solid) particle, and two particles are neighbors if their distance is less than two times the Particle Contact Offset. The solver limits the number of particles that can be in a given particle’s neighborhood via the maxNeighborhood parameter (defaults to 96). In the neighborhood of a particle, constraints are evaluated by the solver, e.g. contact constraints for solid particles, or density constraints for fluid particles.

Particle-Non Particle Interaction

The Contact Offset and Rest Offset parameters of the particle system work analogously to the rigid- and deformable-body parameters:

Particle to non-particle offsets

When a particle (its center) is closer to a collision geometry than the sum of the particle system’s plus the collider’s Contact Offset, contacts are generated and processed by the solver. The particle and the collider are in contact when the distance of the particle center to the collider geometry surface is equal to the sum of their Rest Offsets. Note that the Solid Rest Offset only applies to particle-particle interactions, see above, and is irrelevant for contacts with non-particle-object interactions.

Offset Autocomputation

By default, the particle system offsets are computed from the Particle Contact Offset which defaults to 0.05 meters scaled to scene units. Therefore, you best change the resolution of a particle set by adjusting the Particle Contact Offset, as the other offsets follow. Since we cannot currently display the autocomputed values to the user in the UI, here are the formulas we use under the hood to compute the offsets:


Autocompute Value

Contact Offset

1.0 * Particle Contact Offset

Rest Offset

0.99 * Particle Contact Offset

Fluid Rest Offset

0.99 * 0.6 * Particle Contact Offset

Solid Rest Offset

0.99 * Particle Contact Offset

Creating Particle Sets

Particle sets are used to simulate fluids or granular material like sand. The particle positions are setup using either a Points or a PointInstancer prim.

You can setup the particle positions in the Points or PointInstancer using Python code, for example running a script in the Window > Script Editor, and you may refer to the Isosurface Fluid Demo for sample code. Another option is to use the Particle Sampler to create particles from meshes, see below.

After setting up the Points or PointInstancer, select Add > Physics > Particle Set in its property window, and configure the set in the new particle-set rollout. In particular, setup the relationship to the particle system that the set belongs to. Most parameters defining particle behavior (i.e. dynamics) are attributes of the particle system and the PBD particle material bound to it, see Particle System Configuration.

Particle Sampler

Particle sampler - Sphere Mesh to resulting sphere-shaped particle set

You may create Points-based particle sets by sampling the surface and volume of a source mesh. Select the source mesh, and do Add > Physics > Particle Sampler. See the note below about a current visibility issue with the created particles.

The sampler then performs the following steps:

  1. If there is no particle system on the current stage, creates a new particle system with default settings.

  2. Auto-computes a suitable (sampling) Particle Distance from the Fluid Rest Offset in the particle system offset values.

  3. Creates a Points prim that stores the sampled points, and applies a particle set component (fluid default) to the Points.

  4. Listens to changes that may affect the sampling result and re-samples the generated points. Resampling triggers include:

    • setting a specific Particle Distance, or toggling Sample Inside Volume on the source-mesh Particle Sampler properties

    • unchecking the Fluid checkbox in the generated Points’ Particle Set properties (because the Fluid Rest Offset and Solid Rest Offset may result in different values for the auto-computed Particle Distance)

    • transform changes on the source mesh

    You may stop the automatic resampling by either deleting the source mesh or its sampler component, or removing the relationship to the created Points in the sampler component.


Due to an issue with the rendering pipeline (to be fixed), the sampled particles are not visible until you trigger an update by toggling a render-related setting of the created Points, e.g. toggle the Cast Shadows checkbox in the Geometry/Mesh rollout of the Points.

Debug Visualization

The particle debug visualization is available in the viewport show/hide options (the eye) and allows inspecting particle sets, and the various offsets of the associated particle system in particular.

Here is a slideshow of the particle-set visualization options on the Fluid Isosurface demo available in the Demo Scenes which uses Isosurface postprocessing to visualize the fluid as a solid mesh:

The particles shown in the slideshow are set to have a radius of Fluid Rest Offset, but you may change the debug-visualization particle radius to another offset in the Physics Debug Window (Window > Simulation > Debug):

Controls to configure debug-visualization particle radius

Note that Particle Rest Offset will automatically choose the correct offset (i.e. Fluid or Solid Rest Offset) based on the particle object.

Creating Particle Cloth

The video shows the Particle Cloth tutorial that you may find in Window > Simulation > Demo Scenes > Tutorials. Particle-cloth is simulated as solid particles placed at the mesh vertices that are connected to nearby particles by spring-damper elements. The spring-dampers can be placed by the user, or automatically by the simulation. The automatic placement results in a spring-damper setup that stretching, bending, and shearing.

In order to create a cloth, follow these steps:

  1. Select a target mesh and do Add > Physics > Particle Cloth

  2. The mesh will now have the two components Particle Cloth and Compute Springs for Cloth

  3. Setup the spring-damper stiffness and damping parameters in the Compute Springs for Cloth rollout

  4. Setup the offsets, and the Solid Rest Offset in particular to an appropriate value given the mesh. For example, in the Particle Cloth tutorial shown above, we set the Solid Rest Offset to one-half of the vertex spacing of the uniform plane mesh.

Debug Visualization

The debug visualization and the particle radii for Cloth work analogously to the particle-set visualization. In order to display the cloth wireframe, make sure to check the corresponding box in the Debug settings shown above.


The video shows the Particle Inflatable tutorial that you may find in Window > Simulation > Demo Scenes > Tutorials. Start with a target mesh that has a well-defined volume, e.g. a sphere or cube mesh, and make sure that it has sufficient resolution to capture deformation. Then, follow the steps to create a cloth, and set a nonzero pressure in the Particle Cloth rollout to get an inflatable.

Particle-Cloth Attachments

A particle cloth can be attached to primitives which have either a Collider or Rigid Body component. For an introduction to attachments, see Attachments.

Particle Cloth Attachments can be created as follows:

  1. Move both the cloth and the other primitive into an overlapping pose

  2. Select both

  3. Create the attachment with Create > Physics > Attachment

Posing Particle Cloth for attaching to Collider

Debug visualization

The attachment can be visualized using the show/hide menu in the Viewport:

Debug Visualization: Attachment Points (Pink) and Filter Points (Cyan)


  • The attachment debug visualization can be scaled: Viewport Settings > Gizmo Constant Scale or Gizmo Global Scale.

The debug visualization shows two elements of an attachment:

  • Attachment points (Pink)

  • Filtered points (Cyan)

Collision Filtering

For particle-cloth attachments, attachment points and filtering always correspond to vertices of the particle cloth. The filtering is needed to prevent collisions between vertices of the particle cloth and the collider, and omitting filtering might result in jittering. All attached vertices are automatically also filtered, but it can be useful to further filter some non-attached vertices in the vicinity.

Illustration of how attached and filtered vertices are selected based on auto attachment computation parameter.

Both attachment-points and filtering parameters can be adjusted in the Compute Auto Attachment rollout of the attachment properties:

Controls to configure automatic generation of attachment points and filtering.


  • Both Attach Rigid Surface and Surface Sampling Distance are not supported.

  • Advanced/Enable Deformable Collision Filtering Pairs is not supported.

Post-Processing for Fluid Rendering

There are several particle-set post-processing features that can improve the appearance of fluid particle sets. The features only affect the render output, and have no effect on the underlying simulation, i.e. particle dynamics. You can add each component through the Add > Physics menu in the property window of the particle system:

Particle system post-processing components


As the name implies, this step smoothens the particle positions depending on the user-set strength.


Anisotropy uses data computed by the solver to stretch the particle spheres into ellipsoids such that the fluid surface appears smoother. Note that only the PointInstancer prim supports nonuniform scaling, and, therefore, a Points prim is auto-converted to a PointInstancer if you add anisotropy to the particle system of a Points-based set.

Anisotropy post-processing


The isosurface post-processing component extracts a render mesh from the (fluid) particles in the particle system:

In addition to configuring the isosurface extraction in the rollout added to the particle system’s properties, you may add a render material to the particle system to control the appearance of the extracted mesh.

Diffuse Particles

The diffuse particle component uses simulation data and the user-set parameters to spawn diffuse particles that can be used to visualize, for example, sea spray at a wave’s crest.

Render diffuse particles as follows:

  1. Make sure the Flow extension (omni.usdflow) is enabled

  2. Setup a fluid particle set

  3. Apply the Diffuse Particles component to the fluid set’s particle system

  4. Select the particle system prim, right-click it, and create a Flow Point Emitter with Create > Flow > Point Emitter (such that the emitter is a direct child of the system in the USD hierarchy)

  5. Add Flow render and simulation parameter prims, and configure them to achieve the desired render effect

Feature Previews

You can get a sneak preview of some of the upcoming features in Omniverse Physics by enabling the preview extensions.


Please keep in mind that the features presented in the previews are work in progress; all aspects of the features, i.e. the USD schema, simulation behavior, parameters, etc. are subject to change in future versions.

PhysX Feature Preview

If you enable the PhysX Preview extension omni.physx.preview, additional Preview Samples are added to the Window > Simulation > Demo Scenes window. The samples include:



Franka Deformable

Franka robot arms use Jacobian-based inverse kinematics to lift and drop the red cube in a bowl of deformable cubes.

Franka Nut and Bolt

The nut and bolt interaction leverages the new signed-distance-field (SDF) collision feature of PhysX, which enables a contact-rich interaction. Nuts are fed by a vibratory feeder to a Franka robot arm. The arm is controlled by a finite state machine providing end-effector targets to a Jacobian-based inverse kinematics controller.

Nuts and Bolts

The nuts and bolts interaction leverages the new signed-distance-field (SDF) collision feature of PhysX, which enables a contact-rich interaction. The friction parameters are tuned low enough such that the nuts are threading onto the bolts solely under the influence of gravity. The demo uses the flatcache extension to achieve significantly higher framerates.

PhysX Flatcache

The Flatcache feature enables bypassing USD to communicate PhysX simulation data to the rendering engine, which is more efficient and results in higher combined simulation and rendering performance.

The feature currently only supports rigid bodies (excluding point instancer rigid bodies as well). You can enable and test the Flatcache feature as follows:

  1. Enable the extension omni.physx.flatcache

  2. Enable FPS display in the viewport show/hide menu (eye) HUD Stats

  3. Compare FPS in a scene with many rigid bodies (e.g. ~1k) with and without Flatcache enabled