What is the difference between OmniJoint and Physics Joint? Can they be converted into each other?

Omniverse Isaac Sim
1

I am studying the use of SMPL human models in Omniverse and executing the relevant motion data in the AMASS dataset.
The first question I encountered was the difference between OmniJoint and Physics Joint, which one should I choose? And whether the two types of joint data can be converted to each other.
I hope someone who is doing related research can help guide me. Thank you very much.

image
image1674×718 111 KB

2

I’m not e expert but if this helps

OmniJoint - joints more for traditional game engine characters for driving skinned meshes / mainly for animation driven characters / assets. So the joints are driven by animation data / clips.

Physics Joint - Physics based joints to work with physX, where you can define the physical property’s of a joint, attach colliders and setup physics based simulations. So your asset would move based on physics e.g. falling to the floor, hinge joints so parts bend in a set direction based on physical property’s.

Doesn’t seem like they are interchangeable, I’ve been trying to connect the two myself with no luck / noticed a few unresolved tickets with the same issues so might not be supported?

3

reat question, and vanessa.thompson’s summary is on the right track – let me fill in
the details and point you toward the right workflow for SMPL + AMASS.

OmniJoint (UsdSkel / skeletal animation)

OmniJoint is part of the omni.usd.schema.anim extension and builds on the
UsdSkel schema. It
represents joints in a skeletal animation hierarchy – the joints that drive
skinned mesh deformation via linear blend skinning (LBS).

  • Positions come from animation clips, motion capture retargeting, or an animation graph
  • They carry bind pose, rest pose, and retarget metadata
  • The physics engine does not participate – these joints are purely transform-driven
  • They exist inside a SkelRoot + UsdSkel.Skeleton hierarchy

For characters that are expressed in this format – including many Digital Human assets –
this is the system to use. The animation retargeting tools (omni.anim.retarget.core)
can map animations from one skeleton to another at runtime.

Physics Joint (UsdPhysics constraint)

Physics joints (UsdPhysics.RevoluteJoint, UsdPhysics.PrismaticJoint,
UsdPhysics.SphericalJoint, etc.) are constraints between pairs of rigid bodies
driven by the PhysX solver. They govern how physics-simulated bodies move relative to
each other – the constraint solver enforces the joint rule every physics step.

These are what you would use for robot articulations: robot arms, grippers, legged
robots. The robot’s links are rigid bodies, and physics joints define which DOFs are
free, joint limits, and drive targets.

See the Physics Joints documentation
for the full list of joint types and how to configure drives and limits.

Can they be converted into each other?

No – they serve fundamentally different purposes and use incompatible schemas.

OmniJoint / UsdSkel Physics Joint
Driven by Animation clips, MoCap retargeting PhysX constraint solver
Acts on Skinned mesh vertices (via LBS) Rigid body positions/velocities
Use case Digital humans, character animation Robot arms, articulated mechanisms
Physics engine involvement None Central

There is no built-in conversion API. A UsdSkel skeleton has no rigid bodies
or collision shapes for PhysX to simulate, and a physics articulation has no
skinning weights or blend shape targets for mesh deformation.

On your specific SMPL + AMASS use case

To be precise: SMPL and AMASS are not supported input formats in Isaac Sim 6.1.
Neither appears anywhere in the extension source or documentation. What the built-in
human animation system is actually built around is different:

The built-in path: NVIDIA SimReady USD characters

Isaac Sim ships a character animation pipeline (isaacsim.replicator.agent.core,
omni.anim.behavior.core) that loads human characters from Isaac/People/Characters/
– NVIDIA-authored SimReady USD assets – and animates them using a
HumanMotionLibrary.usd motion library via motion matching. Custom animations can
be imported into the library via the behavior UI or ImportCustomActionCommand, but
the input must be a USD SkelAnimation file, and the source skeleton must be mapped
to the built-in “Human” rig. Four source rig automaps are included:

  • NVIDIA Digital Human
  • Reallusion (Character Creator / iClone)
  • Unreal Mannequin
  • Omniverse Default

There is no SMPL automap. If you fed a SMPL skeleton through auto-tagging, the
pelvis joint would resolve correctly (it matches the “Hips” keyword), but most
other joints would be misassigned or unmatched – SMPL’s l_collar/r_collar,
spine1/2/3, and 24-joint-only hand structure (no fingers) don’t fit the expected
mapping. You would need to set up the tag mapping manually.

What a SMPL + AMASS pipeline in Isaac Sim would actually look like

There is no official guide for this. A community path that could work:

  1. Convert SMPL .pkl to USD: Use smplx Python library to recover the skeleton
    and rest pose, then write a SkelRoot + UsdSkel.Skeleton USD file.
  2. Convert AMASS .npz to animation: Use smplx to decode the axis-angle pose
    parameters into joint rotations, then either:
    • Write a UsdSkel.Animation prim with time-sampled rotations directly, or
    • Export as BVH and use Omniverse’s Asset Importer (omni.kit.tool.asset_importer
      supports BVH) to convert to USD – then bring it into Isaac Sim.
  3. Manually map SMPL joints to the Human rig: Open the Retargeting UI and assign
    the 24 SMPL joint names to the Human rig tags by hand.
  4. Import into the motion library: Use the behavior extension UI or
    ImportCustomActionCommand to retarget and store the animation.

Steps 1-3 are entirely outside Isaac Sim and require custom code.

If your goal is human character simulation for SDG (synthetic data generation)

The path of least resistance in Isaac Sim 6.1 is to use the provided
Isaac/People/Characters/ assets and the isaacsim.replicator.agent pipeline
directly. These are simulation-ready, already tagged for the Human rig, and
integrate with the behavior and navigation systems out of the box.

Hope this helps clarify the joint system distinction and what a SMPL + AMASS
pipeline in Isaac Sim would actually involve.

Closing this topic. If you are still experiencing this issue or have follow-up questions about the conversion pipeline or manual rig mapping, please open a new topic and include a link back to this one for context.