Available Now
Book a demo and get early access. Free trial!
Unreal Engine vs. NVIDIA Isaac Sim in a 40,000+ Object Robotics Test
What happened when we ran the same 40,000+ object robotics simulation in Unreal Engine and NVIDIA Isaac Sim, and why Champion helps keep it stable.
unreal-engine-vs-nvidia-isaac-sim-in-a-40k-object-robotics-test
Last updated:
August 8, 2025
Large-scale robotic simulations aren’t just about logic; they’re about whether your engine can keep time when thousands of moving parts are in play. We ran the same conveyor + delta robot setup in Unreal Engine and NVIDIA Isaac Sim to see how each handled 40,000+ active objects. Here’s what happened.
We began this project with Unreal Engine because it allowed us to rapidly prototype the environment and control logic. Within a short time, we had a functioning system: conveyor belts advancing on schedule, delta robots executing pick-and-place routines, and collision triggers responding as expected.
Performance was excellent in small-scale trials. The simulation maintained smooth motion, accurate timing, and visually rich output — ideal for validating early concepts.
However, when we scaled the simulation to 40,000+ active moving objects, system performance degraded. Timing inconsistencies began to appear, leading to misaligned conveyor events and robotic arms failing to engage items correctly. These delays were not the result of logic errors, but of CPU and GPU frame-step processing falling behind the simulation load.
In Unreal Engine, the bottlenecks were rooted in real-time frame execution. High object counts increased both rendering and physics computation demands, introducing jitter into the conveyor timing. The downstream effect was clear: even small delays caused robotic events to desynchronize.
We then ported the identical scenario to NVIDIA Isaac Sim. Although the initial setup required more engineering effort — including Python-based scripting, USD scene management, and precise physics configuration — the results at scale were markedly different.
Isaac maintained fixed-step simulation timing under the full 40,000+ object load. GPU-native physics through Omniverse handled collision detection and kinematic updates without introducing the frame drift observed in Unreal. Conveyor and robot synchronization remained intact throughout the test.
| Aspect | 🎮 Unreal Engine | 🖥️ Omniverse / Isaac Sim |
|----------------------------------|-------------------------------------------------------|--------------------------------------------------------|
| ⚙️ **Initial Setup** | ⚡ Fast, minimal setup; rapid prototyping | 🛠️ More engineering effort; Python + USD configuration |
| 🚀 **Early Performance** | ✅ Smooth and stable in small-scale trials | ✅ Stable in small-scale trials |
| 🎨 **Visual Quality** | 🌟 High visual fidelity | 🎯 Good visuals; physics-focused |
| ⏱️ **Physics & Timing** | ⏳ Real-time frame execution; drift under high load | 🕒 Fixed-step timing; deterministic at high load |
| 📈 **Scalability** | 📉 Degrades at 40,000+ objects; timing jitter | 📊 Maintains sync at 40,000+ objects; no frame drift |
| 🤖 **Collision & Kinematics** | 🖥️ CPU/GPU split; bottlenecks in heavy load | 🧮 GPU-native physics handles well |
| 🏆 **Best Use Case** | 🛠️ Rapid prototyping & concept validation | 🏭 Large-scale industrial workloads, deterministic sim |
The conclusion was consistent with our expectations: Unreal excels in rapid prototyping and visual fidelity, while Isaac offers deterministic physics performance under heavy industrial workloads.
Having tested both engines under identical conditions, we’ve experienced their strengths and weaknesses firsthand. At Champion, we design simulation pipelines that combine Unreal’s speed of iteration with Isaac’s performance at scale — without forcing you to choose between the two.
👉 If you want your robotics simulations to remain stable under full production load, visit champion3d.io — where we turn CAD into synchronized, GPU-optimized virtual environments that scale.
