박스2디 개발자가 3차원 물리 엔진 ‘박스3디’를 오픈소스로 공개

왜 박스3디가 나왔나

• 박스2디(Box2D) 개발자가 3차원 물리 엔진 박스3디(Box3D)를 오픈소스로 공개함

  • 박스2디를 3D 게임에 맞게 확장한 형제 프로젝트에 가까움
  • 전체 라이브러리 소스는 C17이고, C API를 제공함
  • 현재 깃허브에서 사용할 수 있고 문서와 예제도 준비 중임

• 기본 구조는 박스2디와 거의 비슷하게 유지하면서 3D 게임에 필요한 기능을 추가함

  • 삼각형 메시 충돌(triangle mesh collision)
  • 높이 필드 충돌(height-field collision)
  • 베이크된 복합 충돌(baked compound collision)
  • 서브스텝 솔버, 연속 충돌, 넓은 SIMD 접촉 솔버, 멀티스레딩 훅, 선택적 내부 스케줄러도 포함됨

• 개발 계기는 꽤 현실적임. 개발 중인 게임 ‘더 레전드 오브 캘리포니아’에서 언리얼 기본 물리인 카오스(Chaos)가 요구사항을 제대로 못 맞췄음

  • 얇고 긴 물체가 회전할 때 자이로스코픽 토크(gyroscopic torque)를 제대로 시뮬레이션하지 못하는 문제가 있었음
  • 서바이벌 게임에서 나무를 베어 쓰러뜨리는 장면을 만들었는데, 나무가 화면에서 순간이동하듯 불안정하게 움직였다고 함
  • 큰 캡슐이 부드러운 삼각형 메시 위로 떨어지는 상황이라, 물리 엔진 입장에선 쉬워야 하는 케이스였다는 게 더 뼈아픔

언리얼 물리를 갈아엎은 과정

• 처음엔 기존 오픈소스 3D 물리 엔진인 졸트(Jolt)를 포크하는 선택지도 고려했음

  • 하지만 밸브에서 하프라이프: 알릭스용 커스텀 물리 엔진 루비콘(Rubikon)을 만든 더크 그레고리우스가 루비콘 라이트를 기반으로 해보라고 제안함
  • 실제로 루비콘 라이트를 언리얼에 직접 붙였더니 자이로 토크도 되고, 나무도 자연스럽게 쓰러졌다고 함

• 이후 루비콘 라이트 포크는 점점 박스2디 코드와 구조로 바뀌었고, 그 결과물이 박스3디가 됨

  • 박스2디 3.0의 최적화와 자료구조를 3D 쪽에도 가져오고 싶었던 게 큰 이유
  • 2D와 3D 엔진의 API, 자료구조, 알고리즘을 최대한 비슷하게 유지해야 개발자가 제정신으로 유지보수할 수 있었다는 얘기임
  • 현재 박스3디에는 일부 루비콘 라이트 코드가 볼록 껍질 생성과 충돌 알고리즘 쪽에 남아 있고, 나머지는 박스2디 기반 코드와 새 코드로 구성됨

• 언리얼의 물리 엔진을 교체할 수 있었던 건 프로젝트 구조가 꽤 커스텀이었기 때문임

  • 블루프린트 대신 자체 스크립팅 시스템을 사용함
  • 애니메이션은 에소테리카(Esoterica)를 언리얼로 포팅해 사용함
  • 커스텀 ECS가 박스3디에 직접 연결됨

대규모 오픈월드에서 필요한 물리 기능

• 박스3디는 단순히 ‘충돌이 된다’ 수준이 아니라 특정 게임 요구사항에 맞춰 성능을 깎은 엔진임

  • 거대한 레드우드 나무가 빠르게 쓰러져 복셀 지형에 부딪히는 상황을 최적화하고 있음
  • 메시 충돌과 연속 충돌 감지를 안정적으로 만드는 데 큰 노력이 들어감
  • 복셀 시스템은 런타임에 충돌 메시를 빠르게 만들어야 해서, 격자 형태에 잘 맞는 중앙값 분할(median split)을 사용함

• 스트리밍도 핵심 기능으로 다뤄짐

  • 게임의 대형 요새는 키트배싱 방식으로 만들어지고, 큰 요새 하나에 충돌 메시가 5만 개 정도 들어갈 수 있음
  • 이걸 물리 엔진에 하나씩 로드하면 메모리와 생성 비용이 터짐
  • 그래서 여러 충돌 모양을 최적화된 자료구조로 조리해 하나의 거대한 복합 모양처럼 로드하는 시스템을 만들었다고 함

• 이미 몇몇 프로젝트에서 박스3디를 사용 중임

  • 더 레전드 오브 캘리포니아
  • 페이스펀치 스튜디오의 게임 플랫폼 s&box
  • 바비 앙겔로프가 이끄는 오픈소스 게임 엔진 에소테리카
  • 글렌 피들러의 1000명 플레이어 우주 게임

지금 써도 되나

• 개발자는 박스3디를 아직 알파 소프트웨어로 보고 있음

  • 곧 v0.1 태그를 찍고 v1.0 릴리스로 쌓아갈 계획
  • 기능 세트는 이미 좋은 위치에 있지만 테스트와 문서가 더 필요하다고 밝힘
  • 캐릭터 이동 개선, 고스트 충돌 완화, 최적화, 조인트 솔버 개선이 후보 작업으로 언급됨

• 박스2디와 달리 박스3디는 풀 리퀘스트를 받을 가능성이 높고, 아마 CLA를 사용할 예정임

  • 박스2디와 박스3디를 장기적으로 함께 지원하겠다는 입장
  • 별도 웹사이트나 디스코드는 만들지 않고, 박스2디 사이트와 디스코드에서 업데이트를 이어갈 예정

---

기술 맥락

• 여기서 핵심 선택은 언리얼의 기본 물리인 카오스를 고쳐 쓰는 대신, 프로젝트 요구사항에 맞는 커스텀 물리 엔진을 가져간 거예요. 왜냐면 이 게임은 단순 클라이언트 연출이 아니라 서버에서 수십만 엔티티와 나무, 래그돌, 복셀 충돌을 직접 책임져야 했거든요.

• 브로드 페이즈가 중요해진 이유도 여기 있어요. 객체가 적으면 대충 후보를 좁혀도 되지만, 서버에 수십만 엔티티가 있으면 충돌 후보를 빠르게 줄이는 자료구조가 성능의 생명줄이 돼요. 그래서 작성자가 미들웨어에 넘기기엔 위험하다고 판단한 거예요.

• 복합 충돌을 베이크하는 설계도 꽤 실전적이에요. 요새 하나에 충돌 메시가 5만 개쯤 있으면, 그걸 바디와 셰이프로 하나씩 생성하는 순간 로딩 시간과 메모리가 같이 터져요. 미리 최적화된 하나의 큰 충돌 구조로 굽는 쪽이 스트리밍에 훨씬 유리한 거죠.

• 박스3디가 박스2디와 구조를 맞춘 것도 유지보수 판단이에요. 2D와 3D 물리 엔진을 완전히 다른 코드베이스로 굴리면 같은 최적화를 두 번 발명해야 해요. 그래서 API와 자료구조를 최대한 비슷하게 둔 게 장기 지원의 비용을 줄이는 선택이 된 거예요.