Physics Core

Overview

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.

Feature

Description

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

articulations
Articulations

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

deformables
Deformable-Body Simulation

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

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

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 > Physics > Demo Scenes.

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 > Physics > 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 Preferences in Edit > Preferences provide more general simulation settings such as lower bounds on the simulation rate, and UX settings such as enabling mouse interactions.

  4. 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 > Physics > Debug). In addition, you can enable feature-specific debug visualization in the Show/Hide (Eye) menu in the viewport:

Physics Debug Visualization Viewport Eye

Note

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.

Note

  • 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 Preferences

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

General

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.

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.

Reset Physics Settings

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

Update

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. Use Output Velocities in Local Space to control the coordinate frame that the velocities are reported in. If you do not need velocity information, you can disable the writeback to save some computational overhead.

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.

Simulator

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.

Num Simulation Threads

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

Enable Anisotropy for Fluid Rendering

Improves rendering appearance of simulated fluids, e.g. particle-based PhysX fluid.

Release Physics Cooked Data

Deletes cooked data (i.e. pre-optimized simulation data for collision meshes, etc.) from USD, i.e. deletes the corresponding attributes holding the data. Forces re-cooking of the data.

Run Backwards Compatibility

Manually trigger a backwards compatibility check and update.

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.

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.

Convex Decomposition and Mesh Simplification Default Settings

Change the default settings applied to convex decomposition and mesh simplification, see Collision Settings.

Units

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 (currently only distances, see the note below). 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).

Note

  • Currently, only the Meters Per Unit, i.e. distance scaling is considered for physics simulation. Mass scaling, i.e. Kilograms Per Unit will be supported in the future.

  • 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 > Physics > 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.

PVD

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

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.

Note

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.

Note

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

Instancing

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/protoype). 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.

Note

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

Note

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

Shapes

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.

Parameters

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.

Physics Materials

Physics materials for rigid and deformable bodies can be created with Create > Physics > Physics Material. Here, we focus on rigid-body material, see Deformable-Body Material below for deformable material.

Alternatively, one can do Add > Physics > Rigid Body Material in the property window of a graphics material to add a physics material component to it (e.g. to combine the visual and physical properties of rubber in a single material prim).

The created physics material can then be assigned to colliders in the Physics Materials on Selected Objects rollout in the property window. Physics materials follow the same USD-hierarchy inheritance rules as render 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.

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.

Note

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

Note

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

Joints

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

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.

Types

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

Type

Description

Articulations
native
compatible

revolute

The revolute joint allows rotation about a single axis.

yes
yes

prismatic

The prismatic joint allows linear motion along a single axis.

yes
yes

spherical

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

yes
yes

d6

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.

no
yes

fixed

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

yes
yes

distance

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

no
yes

gear

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

no
no

rackandpinion

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.

no
no

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.

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.

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

The only point at which you must consider the USD hierarchy when creating articulations is 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 root link.

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.

Note

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

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

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.

Note

  • 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 > Physics > 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 > Physics > 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).

Note

  • 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 > Physics > 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.

Alternatively, you may add a deformable-body component to a render material and define the body’s material together with the render material.

When a deformable body does not have a material assigned, it will use default parameters that are identical to the parameters of a newly created deformable-body material.

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.

Note

  • 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:

Parameter

Description

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.

Feature Previews

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

Note

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 > Physics > Demo Scenes window. The samples include:

Feature

Description

clothandrigids
Cloth and Rigids

A position-based-dynamics (PBD) particle cloth in a two-way interaction with rigid bodies. The cloth features self-collision, and stretch, bending and shear constraints implemented with an implicit spring model.

fluidemitter
Fluid Ball Emitter

PBD particle fluid rendered using point-instancer spheres demonstrating dynamic creation of additional particles (150 per ball).

isofluid
Fluid Isosurface Glass Box

PBD particle fluid rendered with a mesh extracted from the particle positions using the Marching Cube algorithm, and demonstrating two-way interaction with rigid bodies.

inflatables
Inflatables and Rigids

PBD particle cloths with an additional pressure constraint create inflatables that are two-way interacting with rigid bodies.

skeletonhand
Skeleton Hand Articulation

A skeleton hand is configured as an articulation and driven by motion-capture data recorded with a Leap sensor. The fingertips are deformable bodies attached to the fingertip bones. The hand picks up a cup filled with PBD fluid and pours it into a second cup.

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