← BlogCo-simulation & Rendering· 4/4

What Is Co-simulation — Why ZMQ, Why Leader/Follower

Rather than demanding one engine handle both precise physics and photorealistic visuals, co-simulation routes only state values across a lightweight message bus to connect two engines that each excel at different things.

~4 min
co-simulationZMQIsaac-SimUnreal-Enginearchitecture

What Is Co-simulation

A good physics engine (accurate collision and dynamics) and a good rendering engine (realistic light and materials) have different strengths. Instead of searching for one engine that does both well, co-simulation connects two specialized engines and bridges them — each doing what it does best.

Leader and Follower

The core structure is simple. One engine produces ground truth; the other presents it.

Rendering diagram…
  • Leader — Physics (e.g., Isaac PhysX). Computes vehicle position, orientation, and wheel state as the authoritative truth.
  • Follower — Visuals (e.g., Unreal Engine). Receives state from the Leader and renders it with high fidelity.

Both engines run synchronized to the same sim_time, exchanging only state values — not the entire scene.

Why ZMQ

ZMQ (ZeroMQ) serves as the message bus connecting the two engines.

  • No broker — PUB/SUB communication directly between processes without a central server keeps latency low.
  • Proven pattern — Already used in other co-simulation setups, so it is well understood and stable.
  • Lightweight — Small JSON state packets at 60 Hz impose negligible overhead.
Rendering diagram…

What Is Shared and What Is Not

The art of co-simulation lies in sharing as little as necessary.

  • Vehicles — pose + velocity is sufficient (~1 kbps).
  • Surface vessels — both engines must show the same ocean surface, so wave parameters are shared and each engine independently computes its wave surface using the same formula. Sending the full wave height-field mesh at 60 Hz would be wasteful.

💡 Determinism is critical — Both engines must produce the same result at sim_time = t. Without that, physics (Leader) and visuals (Follower) drift apart. Sharing only parameters and computing locally requires both sides to use an identical formula.

⚠️ Prefer the latest frame over a delayed one — In real-time co-simulation, when frames back up it is better to drop stale frames and display only the latest than to catch up (ZMQ's CONFLATE option). Handling back-pressure this way keeps the display smooth without stutter.

In a nutshell

📌 Co-simulation connects a physics-strong engine (Leader) and a visuals-strong engine (Follower) via a lightweight message bus (ZMQ). Only state values — not entire scenes — are exchanged; both engines run deterministically to produce matching results; and back-pressure is handled by "keep only the latest frame."

See standard test results with videos and verdict evidence on the imSim Portal.

View public results →