> This page is for version Release 3.0 (default). > For other versions, use one of these documentation indexes: > - Release 3.0 (default): https://docs.nvidia.com/isaaclab/3.0/llms.txt > - Release 2.3: https://docs.nvidia.com/isaaclab/2.3/llms.txt > - Release 2.2: https://docs.nvidia.com/isaaclab/2.2/llms.txt > - Release 2.1: https://docs.nvidia.com/isaaclab/2.1/llms.txt > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.nvidia.com/isaaclab/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/isaaclab/_mcp/server. # Physics Backends Isaac Lab supports three physics backends behind its common asset, sensor, and scene APIs. Choose the backend that matches the runtime and solver family you need, then choose a preset that the target task exposes. See [Backends and Presets](/source/concepts/backends_and_presets) for preset selection and [Backend architecture](/source/concepts/backends_and_presets#backend-architecture) for the implementation architecture. ## Backend and solver terminology A **backend** integrates a physics runtime with Isaac Lab and owns simulation lifecycle and data exchange. A **solver** is the numerical method that advances the physical state within that backend. Newton is therefore not synonymous with MJWarp: Newton hosts MJWarp, Kamino, VBD, MPM, and other solver paths. A **physics preset** is a task-supported configuration that selects a backend and, when applicable, one of its solvers. Solver settings and behavior are not numerically portable between solver families. Expect to retune a task when changing solvers; see [Solver Differences](/source/concepts/solver_differences). ## Choose a backend | Backend | Runtime requirement | Maturity | Solver family | Intended use | | ------- | ------------------------------------------------------------- | --------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------- | | PhysX | Isaac Sim and Omniverse Kit | Established reference | PhysX TGS by default; PGS available | Broadly validated Isaac Lab workflows and behavior-parity reference | | Newton | Warp-native; Isaac Sim is not required for kit-less execution | Beta | Multiple solvers, with MJWarp as the primary validated path | Kit-less simulation and workflows that need Newton solver choices | | OvPhysX | Optional `ovphysx` runtime extra; no Omniverse Kit | Experimental | PhysX, configured primarily through USD | Experimental kit-less PhysX workflows | Follow [Installation](/source/setup/installation/index) for the supported installation paths and current optional extras. Do not combine OvPhysX with a Kit runtime in the same process. For the general PhysX--Newton policy validation workflow, see [/source/how-to/transfer_policies_between_physx_and_newton](/source/how-to/transfer_policies_between_physx_and_newton). When a checkpoint's joint or body ordering differs from the target backend, use the [articulation ordering guide](/source/how-to/transfer_policies_between_physx_and_newton#joint-and-body-ordering). ## PhysX PhysX is Isaac Lab's established reference backend. It runs through Isaac Sim, uses the Temporal Gauss-Seidel (TGS) solver by default, and also offers the Projective Gauss-Seidel (PGS) solver. Its GPU scene capacities are static, so contact-rich or large vectorized scenes may require explicit buffer sizing. Keep TGS as the starting point for articulated robots; evaluate PGS when a stiff legacy asset behaves poorly with TGS. The generated API remains the source of truth for solver selection values and defaults. Configure scene-level fields with `~isaaclab_physx.physics.PhysxCfg`; the generated API reference is the authoritative field list. Per-actor physical properties remain on the USD schema configuration described in [/source/concepts/schema_cfgs](/source/concepts/schema_cfgs). For a diagnose-first workflow covering solver selection, iterations, contacts, stability, and GPU capacities, see [Tune the PhysX Solver](/source/how-to/solver_tuning_physx). For how the backend starts Isaac Sim, owns the simulation lifecycle, and exposes PhysX tensor views, see [the PhysX backend page ](/source/concepts/physics-backends/physx). ## Newton Newton is a Warp-native backend that can run without Isaac Sim. Its Isaac Lab integration is beta, with MJWarp as the primary validated solver path. See [the Newton backend page ](/source/concepts/physics-backends/newton) for solver options, task support, and links to Newton's own solver documentation. ## OvPhysX OvPhysX is an experimental kit-less PhysX path. It drives PhysX without Omniverse Kit, while scene-level solver settings primarily come from the USD `PhysicsScene` prim. Only settings that are not represented in USD live on `~isaaclab_ov.physics.OvPhysxCfg`; consult its generated API reference for those fields. Feature coverage is still evolving. See the [OvPhysX specialist page ](/source/concepts/physics-backends/ovphysx) for current limitations and runtime constraints. ## Find supported tasks and APIs Backend support is task-specific. Use [https://isaac-sim.github.io/IsaacLab/release/3.0.0/source/setup/environments.html](https://isaac-sim.github.io/IsaacLab/release/3.0.0/source/setup/environments.html) to browse registered environments and presets, or ask a task for its current choices: ```bash uv run isaaclab train --rl_library rsl_rl \ --task Isaac-Cartpole-Direct --help ``` The help output is the source of truth for that task's `physics=` choices. For native solver data and views, see [/source/concepts/native-physics-api/index](/source/concepts/native-physics-api/index). For field-level configuration, follow the generated API links for `~isaaclab_physx.physics.PhysxCfg`, `~isaaclab_newton.physics.NewtonCfg`, its solver configurations, and `~isaaclab_ov.physics.OvPhysxCfg`.