NVIDIA Omniverse = USD + PhysX + RTX-enabled Renderer

Related resources

Classes of UsdPhysics(Rigid Body Physics)

  • ArticulationRootAPI
  • CollisionAPI
  • CollisionGroup
  • CollisionGroupTable
  • DistanceJoint
  • DriveAPI
  • FilteredPairsAPI
  • FixedJoint
  • Joint
  • LimitAPI
  • MassAPI
  • MassUnits
  • MaterialAPI
  • MeshCollisionAPI
  • PrismaticJoint
  • RevoluteJoint
  • RigidBodyAPI
  • Scene
  • SphericalJoint
  • Tokens

Constraints Types:

  • Explicit constraints: joints…
  • Implicit constraints: contacts…

USD is a bit like git for computer graphics.

Fix Base Link adds:

def PhysicsFixedJoint "root_joint"
    rel physics:body1 = </g1/pelvis>


The GPU rigid body feature provides GPU-accelerated implementations of:

  • Broad Phase
  • Contact generation
  • Shape and body management
  • Constraint solver

All other features are performed on the CPU.

Performance Considerations: GPU rigid bodies can provide extremely large performance advantages over CPU rigid bodies in scenes with several thousand active rigid bodies. However, there are some performance considerations to be taken into account.

  • D6 joints will provide best performance when used with GPU rigid bodies. Other joint types will be partially GPU-accelerated but the performance advantages will be less than the performance advantage exhibited by D6 joints.
  • Convex hulls with more than 64 vertices or polygons or with more than 32 vertices per-face will have their contacts processed by the CPU rather than the GPU, so, if possible, keep vertex counts within these limits. Vertex limits can be defined in cooking to ensure that cooked convex hulls do not exceed these limits.
  • If your application makes heavy use of contact modification, this may limit the number of pairs that have contact generation performed on the GPU.
  • Modifying the state of actors forces data to be re-synced to the GPU, e.g. transforms for actors must be updated if the application adjusts global pose, velocities must be updated if the application modifies the bodies’ velocities etc.. The associated cost of re-syncing data to the GPU is relatively low but it should be taken into consideration.
  • Features such as joint projection, CCD and triggers are not GPU accelerated and are still processed on the CPU.

Compliant Contacts are particularly useful when dealing with contact configurations that become easily unstable.

Armature that is additional inertia added to the link, and, depending on modeling, can show up as an apparent acceleration-resisting force/torque on the link.

Best Practices Guide

Omniverse Visual Debugger


In the simplified example below, the simulation is set to run at 120 time steps per second, while rendering is set to 60 frames per second, resulting in two physics steps per rendered frame:


Orbit[Isaac Lab]: Actuator Modeling

  • Unified RL platform
  • Open source with BSD-3 license
  • Perf improvements
  • Multi-GPU training based on torch.distributed()
  • Recording capabilities (Animation and video)
  • Tiled RGB/depth rendering with an example


  • Target type: position/velocity
  • Drive type: force

Actuators: In simulation, the joints are either position, velocity, or torque-controlled. For position and velocity control, the physics engine internally implements a spring-damp (PD) controller which computes the torques applied on the actuated joints.

\[\begin{split} \tau_{j, computed} & = k_p * (q - q_{des}) + k_d * (\dot{q} - \dot{q}_{des}) + \tau_{ff} \\ \tau_{j, applied} & = clip(\tau_{computed}, -\tau_{j, max}, \tau_{j, max}) \end{split}\]