Solver Differences

The same asset can behave differently across physics solvers. Each solver handles contacts, state, and constraints differently, even when you use the same Isaac Lab API.

The table below compares the documented PhysX and Newton MJWarp, Kamino, VBD, and MPM workflows. The detailed sections focus on three solvers used for rigid robots: PhysX, MuJoCo-Warp (MJWarp), and Kamino. For additional Newton solver configurations, see Newton. OvPhysX runs PhysX without Isaac Sim; see OvPhysX for its configuration and supported features.

For tuning steps, see Tune MJWarp and Tune Kamino. The solver API references list configuration fields and defaults.

For finer-grained comparisons of features, contact materials, and joint support among Newton solvers, see the Newton supported-features matrix.

For checkpoint compatibility and articulation ordering, follow Transfer Policies Between PhysX and Newton. Its side-by-side transfer demonstrations show PhysX-trained policies running in Newton MJWarp.

Capabilities at a glance

These are direct solver capabilities exposed through Isaac Lab’s asset APIs. Support for a particular task still depends on its registered physics presets. Rigid and deformable or material dynamics may be handled by different solvers in a coupled scene.

✅ means supported, ❌ unsupported, and ⚠️ limited support. GPU requirements and experimental features are qualified in each cell.

Solver capabilities in documented Isaac Lab workflows

Capability	PhysX	Newton MJWarp	Newton Kamino (P-ADMM / DVI)	Newton VBD	Newton MPM
Main workload	Rigid robots and mesh deformables	Rigid articulated robots	Rigid mechanisms, including loops	Cloth, soft bodies, and cables	Fluids, granular media, and snow
Rigid-body dynamics	✅ Yes	✅ Yes	✅ Yes	✅ Yes	❌ No; colliders only
Articulation formulation	✅ Reduced coordinates	✅ Generalized coordinates	✅ Maximal coordinates	⚠️ Limited maximal-coordinate joints	❌ No joint dynamics
Cloth (surface mesh)	✅ Yes; GPU, experimental	❌ No	❌ No	✅ Yes	❌ No
Soft bodies (volume mesh)	✅ Yes; GPU, experimental	❌ No	❌ No	✅ Yes	❌ No
Segmented cables (CableObject)	❌ No	❌ No	❌ No	✅ Yes; experimental	❌ No
Particle-grid continuum materials	❌ No	❌ No	❌ No	❌ No	✅ Yes; experimental
Main tuning controls	Timestep, TGS/PGS iterations, GPU capacities	Substeps, iterations, contact capacities	Substeps, P-ADMM/DVI convergence, stabilization	Substeps, iterations, material and contact stiffness	Voxel resolution, substeps, rheology convergence
Solver details	PhysX overview	MuJoCo-Warp	Kamino	VBD	Implicit MPM
Tuning workflow	PhysX	MJWarp	Kamino	VBD	MPM

PhysX surface and volume deformables use an experimental asset API and require CUDA. Their assets use UsdReplicateContext so PhysX can parse each environment’s deformable from USD within the scene clone plan. Nodal kinematic targets are supported for volume deformables only. See Deformables and DeformableObject for the asset requirements.

VBD’s limited joint support does not replace a general robot articulation. The maintained Franka deformable tasks assign the robot to MJWarp and the deformable to VBD through proxy coupling. MPM advances particle materials; dynamic rigid bodies need a separate rigid solver. See Coupled Solvers and Implicit MPM for the supported scene construction and coupling limitations.

Why solver settings do not translate directly

A configuration value has meaning only within the solver that consumes it. For example, PhysX scene controls do not configure a Newton solver, and MJWarp’s MuJoCo-specific controls do not configure PhysX. The common Isaac Lab configuration selects a backend and solver; it does not translate a numerical setting into an equivalent physical effect.

Even settings with similar names can participate in different contact models or convergence criteria. Porting therefore starts by preserving the mechanical model, collision geometry, material bindings, reset state, actuator behavior, and control period. Then compare the resulting physical behavior and tune the target solver with its own controls.

Friction and contact

PhysX uses patch-based Coulomb friction: nearby contacts can be correlated into a friction patch. Its friction-correlation and offset controls are part of PhysxCfg. MJWarp uses MuJoCo’s contact model, including its selectable pyramidal or elliptic friction cone and frictional impedance ratio. Kamino resolves hard frictional contacts in its maximal-coordinate constrained dynamics solve and exposes contact-material mixing and warm-start configuration through its generated API.

The collision path also differs. PhysX exposes continuous collision detection through enable_ccd, but Isaac Lab disables that option when GPU dynamics is enabled. MJWarp can use either its internal MuJoCo contact path or Newton’s collision pipeline; those modes are mutually exclusive. Kamino can use Newton’s collision pipeline or, when enabled, its own internal collision detector. These choices determine which capacity and collision controls are active.

Porting implication. Equal material coefficients do not guarantee equal slip, grasp stability, or contact counts. Revalidate collision geometry and contact behavior before tuning friction. A task that depended on PhysX CCD needs an independently validated timestep and collision strategy on Newton; MJWarp’s ccd_iterations is a convex GJK/EPA convergence limit, not a PhysX-style CCD switch.

Restitution and stabilization

PhysX applies restitution using per-material properties and a scene-level bounce threshold. Its optional stabilization pass can improve large-timestep behavior, but can make reported contact-sensor forces inaccurate. MJWarp expresses contact compliance through its MuJoCo model and solver formulation; Kamino exposes Baumgarte stabilization separately for bilateral joints, unilateral joint limits, and unilateral contacts.

These are different mechanisms, so copying a restitution or stabilization setting does not preserve resting-contact behavior. The exact configuration surface belongs in the PhysxCfg, MJWarpSolverCfg, and KaminoConstraintsCfg API references.

Porting implication. Validate bounce, penetration, chatter, and measured contact forces in the target solver. Do not use a stabilization or restitution control as a substitute for valid collision geometry, reset state, or material properties.

Coordinates and state consistency

PhysX articulations and MJWarp use reduced joint coordinates for their articulated state. Kamino solves rigid multi-body systems in maximal coordinates with constraints. Its reset path can reconcile body poses with reduced joint state through forward kinematics; whether that path is used is determined by use_fk_solver and the articulation structure.

Isaac Lab asset APIs maintain the public state interface across the backends, but custom reset code can still write a state that is inconsistent with the target solver’s representation.

Porting implication. Use the asset write APIs for resets and validate the first step with a fixed state. For Kamino, treat disagreement between joint state and body poses as a reset-modeling problem before tuning solver gains.

Timesteps and convergence

PhysX advances at the simulation timestep and uses actor iteration counts within scene limits. MJWarp and Kamino each run num_substeps solver substeps per physics tick, so their solver timestep is the simulation timestep divided by the substep count. More substeps change integration work; they do not translate a PhysX iteration setting into a Newton equivalent.

Substeps do not inherently refresh Newton-pipeline contacts. When that pipeline is active, collision_decimation can re-collide within a physics tick only when it is positive and less than num_substeps; the default value of zero collides once at the start of each tick. This setting does not apply when MJWarp uses its internal MuJoCo contact path or Kamino uses its internal collision detector.

MJWarp provides outer iterations, line-search iterations, and a residual tolerance. Kamino’s P-ADMM and DVI modes have different iteration and convergence controls. PhysX has its own position and velocity iteration model. Consult the generated APIs and the focused tuning guides for current controls instead of copying another solver’s defaults.

Porting implication. Compare a fixed reproduction at the intended policy period, then separately test timestep, substeps, and solver convergence. An iteration increase cannot correct invalid contact geometry, incompatible reset state, or an unstable controller.

Capacity and memory

PhysX allocates GPU buffers for scene limits, including rigid-contact capacity. MJWarp has per-world contact and constraint limits such as nconmax and njmax. Kamino has per-world contact allocation controls in addition to the capacity used by its selected collision path. Their units and failure modes are solver-specific, even when every environment contains the same asset.

Porting implication. Measure the target solver’s busiest reset and contact states before scaling environment count. Increase an observed overflowing capacity first; capacity changes cannot repair an invalid contact model or convergence problem.