← BlogCo-simulation & Rendering· 4/4

Co-simulation이 뭔가 — 왜 ZMQ인가, 왜 Leader/Follower인가

물리 정밀도(Isaac PhysX)와 시각 사실감(언리얼)을 한 엔진이 다 할 필요 없이, 가벼운 메시지 버스로 상태만 흘려보내 합치는 co-simulation의 발상.

약 2분
co-simulationZMQIsaac-SimUnreal-Enginearchitecture

Co-simulation이 뭔가

좋은 물리 엔진(정확한 충돌·동역학)과 좋은 렌더 엔진(사실적인 빛·재질)은 서로 다른 강점을 가집니다. 둘 다 잘하는 엔진 하나를 찾는 대신, 각자 잘하는 두 엔진을 이어 붙이는 방법 — 그게 co-simulation(공동 시뮬레이션) 입니다.

Leader와 Follower

핵심 구조는 단순합니다. 한 엔진이 진실(ground truth) 을 만들고, 다른 엔진은 그걸 표현합니다.

도식 렌더링 중…
  • Leader — 물리(예: Isaac PhysX). 차량의 위치·자세·바퀴 상태를 진짜로 계산합니다.
  • Follower — 시각(예: 언리얼). Leader가 보낸 상태를 받아 화려하게 렌더만 합니다.

두 엔진은 같은 시간(sim_time)에 맞춰 돌고, 상태 값만 주고받습니다 — 전체 장면을 통째로 보내는 게 아니라요.

왜 ZMQ인가

두 엔진을 잇는 메시지 버스로 ZMQ(ZeroMQ) 를 씁니다.

  • 브로커가 없다 — 중앙 서버 없이 PUB/SUB로 직접 주고받아 지연이 낮습니다.
  • 검증된 패턴 — 다른 co-sim에서 이미 쓰던 방식이라 안정적입니다.
  • 가볍다 — 작은 JSON 상태 패킷을 60Hz로 흘려보내도 부담이 적습니다.
도식 렌더링 중…

무엇을 공유하고, 무엇을 안 하나

co-sim의 기술은 "최소한만 공유"하는 데 있습니다.

  • 차량 — pose + 속도면 충분 (~1kbps).
  • 수상함 — 같은 파도 위에 떠야 하니, 파도 파라미터를 공유하고 양 엔진이 같은 식으로 독립 계산합니다. 전체 파면 메시(heightfield)를 60Hz로 보내는 건 낭비입니다.

💡 결정론(determinism)이 핵심 — 두 엔진이 sim_time=t에서 같은 결과를 내야 합니다. 그래야 물리(Leader)와 시각(Follower)이 어긋나지 않습니다. 파라미터만 공유하고 각자 계산하려면, 양쪽이 같은 공식을 써야 합니다.

⚠️ 늦은 프레임보다 최신 프레임 — 실시간 co-sim에서 프레임이 밀리면, 밀린 걸 따라잡는 대신 오래된 프레임을 버리고 최신만 표시하는 게 낫습니다(ZMQ의 CONFLATE). 백프레셔를 이렇게 처리해야 화면이 끊기지 않습니다.

한 줄 정리

📌 Co-simulation은 물리 잘하는 엔진(Leader)과 시각 잘하는 엔진(Follower)을 가벼운 메시지 버스(ZMQ)로 잇는 발상이다. 전체 장면이 아니라 상태 값만 공유하고, 결정론적으로 같은 결과를 내며, 백프레셔는 "최신 프레임만 남기기"로 처리한다.