Adding a Second Engine — The Dedicated Unreal Simulation Track

Isaac Sim handles high-fidelity physics validation. But not every simulation needs that level of fidelity. Some use cases prioritize cinematic visuals, wide terrain, and immediate interactive control. That is why a separate Unreal Engine-only track exists.

Each Engine Has Different Strengths

Rendering diagram…

• Isaac track — Physics validation, sensor synthesis, RL training. Precise but heavyweight.
• UE track — Photorealistic rendering, expansive battlefields, rapid scenario authoring in Blueprint, browser-based operation via Pixel Streaming. Stronger at experience and expression than at validation.

Even under the same label "simulator," a precision-validation tool and an immersive-operations tool are different products. Rather than doing both poorly in one engine, we split them into separate tracks where each engine excels.

The Key: Shared Infrastructure

Running two completely separate tracks doubles the operational burden. So the upper layers are shared.

Rendering diagram…

Orchestration — run submission, queuing, workers — and the RuntimeConfig contract and web UI are shared between both engines. The only thing that changes is the bottom-level runner — Isaac or UE. Swapping the engine leaves the workflow above it untouched.

💡 Sensors are self-contained within each engine — UE-track sensors (cameras, LiDAR) are implemented internally in UE, unlike Isaac sensors. Different engines mean different sensor implementations, but keeping the output interface (topics, datasets) consistent lets downstream tooling remain engine-agnostic.

⚠️ Always-on unattended operation is forbidden in both tracks — UE, like Isaac, occupies the GPU heavily even in headless rendering mode via NVENC. "It's just a demo, leave it running" is dangerous regardless of engine. An auto-stop safety mechanism is mandatory in both tracks.

In a nutshell

📌 Precision physics, sensors, and RL belong to Isaac; cinematic rendering, large terrain, and real-time interaction belong to Unreal — engines split by purpose. Run orchestration, contracts, and UI are shared; only the bottom-level runner is swapped. Sensors are engine-specific in implementation but unified in output interface, keeping downstream tooling engine-agnostic.