Isaac Sim vs Gazebo
Both are free, both are Apache 2.0 at the source level, and both ship a first-party ROS 2 bridge — so the usual shorthands do not separate them. What does: one needs an NVIDIA GPU and fixes its physics engine; the other publishes no GPU minimum and lets you choose the engine at runtime.
Updated 2026-08-24
Choose Isaac Sim if the work needs RTX rendering and RTX-based sensors, OpenUSD scenes, GPU-accelerated physics and the Isaac Lab learning framework — and you have NVIDIA hardware, because that is a stated requirement rather than a recommendation. Choose Gazebo if you want a simulator whose physics engine is a runtime plugin choice, whose sensor models are broad and noise-configurable, and whose ROS 2 packages come from packages.ros.org like the rest of your stack. Both are free. The hardware floor and the asset format usually decide it.
Side-by-side comparison
| Dimension | NVIDIA Isaac SimOpenUSD simulation platform | GazeboOpen source robotics simulator |
|---|---|---|
| What it is | A simulation platform built on NVIDIA Omniverse, with rendering, sensors, importers, synthetic data generation and ROS integration arriving together | A robotics simulator assembled from separate libraries — physics, rendering, sensors, GUI and message transport — each installable and replaceable on its own |
| Maintainer | NVIDIA | The Gazebo project, on GitHub as gazebosim; the current Gazebo is the successor to Gazebo Classic, not the same program |
| Source licence | Apache 2.0 | Apache 2.0, across the libraries |
| What it takes to actually run it | Additional components under separate NVIDIA terms — the Omniverse Kit SDK, 3D models and textures | The same Apache 2.0 libraries throughout, from the project's own package repositories |
| Physics engine | NVIDIA PhysX 5, developed in its own SDK repository — the compatibility table pairs Isaac Sim 6.0.0 with PhysX SDK 5.9.0 | Whichever plugin you load through Gazebo Physics; DART is the default |
| Choosing a different engine | Not a dimension of the design — PhysX is the engine | A runtime plugin choice: dartsim, bullet, bullet-featherstone or TPE, selected on the command line or in SDF |
| Hardware floor | An NVIDIA GPU — build prerequisites list RTX 4080 as the workstation minimum and A40 for datacenter | No published GPU minimum; the project's own CI builds it on Ubuntu, Homebrew and Windows |
| Operating systems | Windows 11, or Ubuntu 22.04 / 24.04; x86-64 and aarch64 | Ubuntu, macOS via Homebrew, and Windows |
| Rendering | Multi-sensor RTX rendering at scale | Gazebo Rendering, with OGRE 1.x and OGRE-Next 2.x plugins |
| Sensors | RTX and physics-based sensors | Camera, depth, RGBD, thermal, segmentation, bounding-box and wide-angle cameras, GPU lidar, IMU, NavSat, magnetometer, altimeter, air pressure, air speed, force-torque and a Doppler velocity log, with noise models |
| Native scene format | OpenUSD | SDFormat |
| Also reads | URDF, MJCF and CAD | URDF, through SDFormat's URDF parser |
| ROS 2 | A first-party ROS bridge, with NVIDIA-published Humble and Jazzy workspaces | ros_gz, maintained by the Gazebo project itself, pairing Gazebo releases with ROS 2 distributions from Humble to Rolling, with binaries on packages.ros.org |
| Learning framework | Isaac Lab — GPU-accelerated, BSD-3, built on Isaac Sim | None first-party; the Gazebo libraries cover physics, rendering, sensors, GUI and transport |
Same licence, different shape
Both are Apache 2.0 at the source level, so the old framing — proprietary NVIDIA product against open source alternative — no longer describes the licence. It does still describe the shape. Isaac Sim is one platform that arrives whole: NVIDIA's own README describes a simulation platform built on Omniverse, with importers, sensors, synthetic data generation and ROS integration included, and its licence file is careful about the seam — "Building or using the software requires additional components licenced under other terms. These additional components include dependencies such as the Omniverse Kit SDK, as well as 3D models and textures." Isaac Lab restates it from the other side: BSD-3 itself, but it requires Isaac Sim, "which includes components under proprietary licensing terms". Gazebo is the opposite shape. It is not one program but a set of Apache 2.0 libraries — Gazebo Sim for the simulation loop, Gazebo Physics, Gazebo Rendering, Gazebo Sensors — each with its own repository, maintainer and release. That is also the practical difference in how you engage with them: Isaac Sim's README states plainly that NVIDIA does "not support direct community contributions at the moment", while Gazebo's libraries take contributions in the ordinary way. If you expect to patch the simulator rather than only use it, that is a real distinction.
One engine versus a choice of engines
Isaac Sim's physics is NVIDIA PhysX, a separate SDK on its own release cadence — the repository's compatibility table pairs Isaac Sim 6.0.0 with PhysX SDK 5.9.0. You get GPU-accelerated physics, and you get it from PhysX. Gazebo starts from the opposite premise, stated in the Gazebo Physics README: "there is not a single physics engine that is universally best for all simulation contexts", so engines are plugins loaded at runtime. The repository carries plugin components for dartsim, bullet, bullet-featherstone and the Trivial Physics Engine, and Gazebo Sim's own source picks the default in a comment you can read — "3. Use DART by default", falling back to gz-physics-dartsim-plugin when nothing else is specified. Be fair about the cost of that flexibility, though. Feature coverage is per plugin, not uniform, and the clearest evidence is Gazebo's own in-progress MuJoCo backend, whose README lists joints, contact reporting and gravity among the features not yet implemented. A pluggable engine is a genuine architectural advantage; it is not a promise that every engine behaves the same.
The GPU floor, and what Gazebo's sensors actually cover
This is usually the row that decides it. Isaac Sim's own prerequisites list an RTX 4080 as the workstation minimum and an A40 for datacenter, on Windows 11 or Ubuntu 22.04 / 24.04 — so "can everyone on the team run it" is a budget question before it is a technical one. Gazebo publishes no GPU minimum, and its own CI builds on Ubuntu, Homebrew and Windows, which is why it tends to be the simulator that runs on whatever laptop a new engineer arrives with. The usual next claim — that Gazebo therefore cannot produce useful perception data — is too strong. The Gazebo Sensors table includes segmentation, bounding-box and thermal cameras alongside RGB, depth and RGBD, a GPU-accelerated lidar, and a Doppler velocity log for underwater vehicles, all with configurable noise. What Gazebo does not have is Isaac Sim's rendering: OGRE and OGRE-Next are competent real-time renderers, not RTX. So the honest split is not annotations versus none. It is whether your model has to transfer to a real camera, in which case the pixels matter and Isaac Sim is doing work Gazebo does not attempt — or whether it consumes geometry, ranges and state, in which case Gazebo's sensor suite is likely already enough.
ROS 2, packaging, and the Gazebo Classic trap
ROS 2 support is where this comparison has aged worst, in two directions. First, it is no longer a Gazebo win by default: Isaac Sim ships a first-party ROS bridge and NVIDIA publishes Humble and Jazzy workspaces to go with it. What differs is packaging and breadth. ros_gz is maintained by the Gazebo project itself and its compatibility table pairs named Gazebo releases with ROS 2 distributions from Humble through Rolling, with binaries hosted on packages.ros.org — the same apt source as the rest of your ROS install. Second, and more damaging to old comparisons: much of what is written about "Gazebo" describes Gazebo Classic, which is a different program. Its repository carries the warning that Gazebo Classic reached end-of-life in January 2025 and directs users to migrate. If a tutorial you are reading launches gazebo or gzserver rather than gz sim, you are reading about the predecessor — and a benchmark or feature comparison based on it tells you very little about the simulator you would actually install today.
When to choose each
Perception and sim-to-real work that needs camera-realistic images and RTX-based sensors, OpenUSD scenes assembled from other 3D tools, GPU-accelerated reinforcement learning through Isaac Lab, and teams already standardised on NVIDIA hardware.
ROS 2 robots, navigation and multi-robot work, marine and aerial platforms — its sensor set includes a Doppler velocity log, air-speed and altimeter models — projects that need a specific physics engine or a CPU-only and mixed-hardware team, and anyone who expects to read and patch the simulator's source.
Where Rigyd fits
The format question is the one Rigyd touches, and it is asymmetric here. Isaac Sim's native scene format is OpenUSD, which Rigyd produces directly, with derived physics attached — that side is an export. Gazebo's native format is SDFormat, and Rigyd does not emit SDF. The Gazebo project maintains gz-usd, a converter between SDF and USD, but its README pins support to OpenUSD v24.08 — "Only v24.08 supported currently" — and we have not verified end-to-end that a Rigyd-generated USD asset survives that conversion with mass, friction and collision geometry intact, so we are not going to claim it does. If your pipeline is Isaac Sim, Rigyd removes the asset-preparation step. If it is Gazebo, Rigyd gets you a physics-annotated asset but you own the last conversion, and you should check the result in the simulator rather than trusting the export. And nothing here helps with the decision itself: Rigyd has no opinion on your GPU budget, your ROS 2 distribution, or which solver your contacts need, which is usually what the choice actually turns on.