Rust로 작성된 2D·3D 물리 엔진 Rapier

 (rapier.rs)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Rapier는 게임·애니메이션·로보틱스처럼 실시간 물리가 필요한 애플리케이션을 겨냥한 Rust 기반 물리 엔진 세트임
  • 빠른 실행과 안정성을 목표로 하며, 필요할 경우 크로스플랫폼 결정성을 선택적으로 지원함
  • 강체 충돌과 힘, 조인트 제약, 접촉 이벤트·센서, 스냅샷 등 물리 시뮬레이션에 필요한 기능을 제공함
  • JavaScript 바인딩을 제공해 Rust 외 환경에서도 Rapier를 활용할 수 있음
  • Apache 2.0 라이선스의 무료 오픈소스이며, Dimforge가 개발하고 GitHub Sponsor로 후원을 받음

Rapier가 겨냥하는 사용처

  • Rapier는 Rust로 작성된 2D 및 3D 물리 엔진 세트임
  • 주 대상은 실시간 물리 처리가 필요한 애플리케이션임
    • 비디오 게임
    • 애니메이션
    • 로보틱스
  • 설계 목표는 빠르고 안정적인 동작이며, 선택적으로 크로스플랫폼 결정성을 지원함

제공 기능과 배포 방식

  • 물리 시뮬레이션을 위한 주요 기능을 포함함
    • 강체 충돌과 힘
    • 조인트 제약
    • 접촉 이벤트와 센서
    • 스냅샷
    • 선택적 크로스플랫폼 결정성
    • JavaScript 바인딩
  • Rapier는 무료 오픈소스이며 Apache 2.0 라이선스로 배포됨
  • 개발 주체는 Dimforge 오픈소스 회사임
  • 후원은 GitHub Sponsor를 통해 가능함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Rapier 결정론 모드로 온라인 멀티플레이어 게임을 만들었음
    플레이어가 번갈아 벌레를 상대 팀 쪽으로 들이받고 언덕을 점령하는 방식임
    아직 싱글플레이어 모드는 없고, AI 작성이 이전에 만든 체스류 게임보다 더 까다로움
    게임은 https://evrimzone.itch.io/crittershowdown에서 볼 수 있고, 물리/게임 로직 소스는 https://github.com/evrimoztamur/crittershowdown/blob/e4d9a19...에 있음
    나중에 어떻게 엮었고 뭘 배웠는지 글로 쓸 계획인데, 전반적으로 매우 탄탄한 라이브러리이고 Rust다운 API 설계 덕분에 필요한 걸 다 구현할 수 있었음

    • 재미있어 보임. 웹사이트에 배포하기 쉬웠는지 궁금함
      WebAssembly로 컴파일한 건지, 아니면 로직 전체를 로컬 서버에서 호스팅하는 방식인지 궁금함
    • 서버 쪽 멀티플레이어 게임을 만들려고 Rapier2D를 쓰기 시작해서, 관련 글이 빨리 올라오면 좋겠음

  • 몇 달 전 기하대수(Geometric Algebra) 에 빠졌는데, 2D, 3D, 4D 이상, 비유클리드 등 매우 다양한 기하를 다루는 데 놀랄 만큼 간결하고 직관적인 방식처럼 보였음
    그래서 기하대수가 물리 엔진의 좋은 기반이 될 수 있을지 궁금했음
    흥미로워 보이는 Rust 라이브러리가 몇 개 있지만 [1][2], 크게 주목받는 건 없어 보임
    이쪽을 살펴본 사람이 있는지 궁금함
    [1]: https://crates.io/keywords/geometric-algebra
    [2]: https://github.com/Lichtso/geometric_algebra
    시작해보고 싶다면 Freya Holmér의 “Why can't you multiply vectors?”가 좋은 입구일 수 있음: https://www.youtube.com/watch?v=htYh-Tq7ZBI 그리고 https://bivector.net/index.html

  • Rust용 Bevy Rapier 플러그인 가이드를 썼음: https://taintedcoders.com/bevy/rapier/
    Bevy 쪽의 흥미로운 대안으로 Bevy XPBD도 있고, 이것도 글로 정리했음: https://taintedcoders.com/bevy/xpbd/

    • 느리게 움직이는 물체를 움직이지 않는 것으로 취급하는 시스템을 보면 불안함
      “Sleeping”은 움직이지 않는 물체의 시뮬레이션 비용을 줄여 성능을 높이는 기법이고, SleepingThreshold 리소스로 조정할 수 있다고 되어 있음
      기본값 예시로 linear: 0.1, angular: 0.2가 들어감
    • 지금 xpbd로 물리 기반 2D 격투 게임을 만들고 있는데, 현재까지는 꽤 마음에 듦
      지금까지는 몇몇 충돌이 한 프레임 사라지는 문제가 하나 있었지만, 이런 건 쉽게 우회할 수 있고 더 좋게는 보고해서 수정할 수도 있음
    • XPBD가 꽤 흥미로워서 몇 번 시험 구현을 해봤고, 최근 게임잼 작품에는 AABB 전용 XPBD를 넣었음
      아직 회전만 제대로 못 했고, 나머지는 복잡도가 녹아내리는 느낌임
      선형대수? 필요 없음. 그냥 Vec3임. 행렬? 해법기? 1998년으로 돌아간 것처럼 모든 제약을 반복해서 만족시키면 됨
      충돌 여유값? 실력 문제임. 광역 단계? GJK? 과하게 생각하지 말고 현대 CPU에 맡기면 됨
      collect_pairs 최적화를 하고 나서 실제 병목이 malloc이었다는 걸 깨닫고 고치면, 100개쯤 되는 객체는 거뜬히 처리함. Bullet이 필요 없음
      속도 보정 단계도 처음엔 헷갈렸지만, AABB로 프로토타입을 해보니 일반 도형에도 다시 옮길 수 있을 것 같음
      처음엔 이 단계를 건너뛰었더니 모든 충돌이 살짝 탄성처럼 동작했음

  • Dimforge는 정말 대단한 일을 하고 있음
    로보틱스의 위치추정과 지도작성 같은 분야에서 nalgebra + Rust가 Eigen + C++를 대체할 수 있다면 정말 기대됨

    • 최근 로보틱스 프로젝트 대부분을 Rust로 하고 있는데, 업계가 C++ 특유의 관용구에 낭비하는 시간이 터무니없이 큼
      Rust에서는 그냥 되는 일이 많음. 다만 물러서지 않고 Rust 투자를 거부하는 구세대가 있어서 아쉬움
      솔직히 C++ 로보틱스 코드 주변에 거대한 산업이 있으니 이유는 이해됨
    • 이걸 현실로 만들고 싶음
      현재 Rust에서 쓸 만한 로보틱스 프레임워크가 있는지 궁금함
      ROS2가 Rust를 천천히 포함하고 있다는 얘기는 들었지만 [1], 어떻게 진행됐는지는 잘 모르겠음
      하드웨어 통합/추상화가 이미 C++로 되어 있으니 ROS는 센서 융합, 지도작성, 위치추정으로 들어가는 좋은 입구가 될 수 있음
      회사들이 이걸 쓰고 있는지도 궁금함
      [1] https://github.com/ros2-rust/ros2_rust

  • 수십 년 전 강체 물리 엔진을 만들 때 기억으로는 쌓기(stacking) 가 매우 어려운 문제였음
    당시 물체가 바닥으로 가라앉는 걸 피하는 최선의 해법은 바닥에서 시작해 물체를 바깥으로 밀어내는 방향성 비순환 그래프를 만드는 것이었음
    수렴하려면 여러 번 반복해야 했고 꽤 해키하게 느껴졌음
    요즘은 이 문제가 해결됐는지 궁금함. 이 프로젝트에서는 쌓기에 대한 언급을 찾지 못했음

    • Box2D 저자가 바로 그 주제로 훌륭한 글을 올렸음: https://box2d.org/posts/2024/02/solver2d/
      글 하단에 링크된 저자 영상은 각 해법기가 여러 어려운 쌓기 문제를 어떻게 처리하는지 보여줌: https://youtu.be/sKHf_o_UCzI
    • 요즘은 쌓기가 잘 동작함
      비순환 그래프가 필요하지 않고, 해법기 반복 횟수를 충분히 늘리면 수렴함
      접촉과 마찰 제약 수를 생각하면 여러 번 반복하는 건 자연스러운 일이고, 최대 잔차를 추적하면 거의 0에 도달할 때까지 돌릴 수 있음
      약간 망가진 부분은 충돌과 해법기가 제한된 갱신 속도에서만 도는 점임
      처음부터 관통 상태로 시작하면 이를 풀어야 하는데, 현실 물체는 그렇게 관통하지 않으므로 다소 “가짜” 처리이고 추가 움직임이 생겨 스택 안정성이 떨어질 수 있음
      그래도 이를 우회하는 여러 방법이 있고, 인기 있는 물리 엔진들은 각자 어떤 식으로든 해법을 갖고 있음

  • Rust는 고정관념을 계속 증명하는 듯함
    Rust로 만든 게임 엔진은 50개인데, Rust로 만든 게임은 5개뿐이라는 농담이 떠오름

    • 물리 엔진이 50개라도 있었으면 좋겠음
      Rapier가 정확히 필요한 요구를 만족하지는 않는데, 좋은 대안이 없음
    • 최근 재미있게 한 게임 하나는 Rust로 작성됐던 걸로 기억함: (the) Gnorp Apologue (https://gnorp.dev/)
      그러니 엔진 코드를 많이 쓰지 않아도 되는 소규모 2D 게임에서는 가능해 보임
      이 게임은 대부분을 SDL로 처리한 경우였음

  • Rapier로 작은 웹 데모도 만들어봤음: https://github.com/iErcann/NotRoblox
    Rust는 쓰지 않았음
    마음에 든 점은 AmmoJS보다 문서가 좋다는 것임. AmmoJS는 pybullet을 읽어야 했음
    비교적 최신이고, 서버(Node)와 클라이언트(브라우저) 양쪽에서 실행할 수 있음
    여기서는 서버 쪽에서 돌리지만, 양쪽 모두에서 돌리고 클라이언트 예측과 보정을 구현하는 것도 가능함
    번들도 작음. AmmoJS는 2MB 정도였던 것 같음

    • Rust 쪽에서는 Rapier 문서가 최신 상태가 아닌 걸로 알고 있음
      다행히 이전 버전에 묶여 있어서 아주 나쁘지는 않음

  • JavaScript 상호운용성도 정말 좋음: https://www.rapier.rs/docs/user_guides/javascript/getting_st...

  • Dimforge에는 예전에 nphysics라는 물리 엔진이 있었고, 소프트 바디와 멀티바디를 지원했음
    이제는 Rapier를 위해 폐기됐는데, Rapier는 그것들이나 nphysics가 하던 다른 기능의 절반도 지원하지 않음
    결과적으로 nphysics는 너무 오래돼서 현대 생태계에서 쓰기 어렵고, Rapier는 너무 새로워서 기능이 훨씬 부족함
    예전에도 비슷한 일이 있었음. Salva라는 유체 시뮬레이션 라이브러리가 nphysics와 양방향 결합을 지원하고 모든 GPU/CPU에서 돌았는데, 이제는 Sparkl을 위해 폐기됐음
    그런데 Sparkl은 그런 기능이 없고 CUDA만 지원함. 그래서 Salva는 nphysics만큼 낡았고, Sparkl은 너무 새로워 기능이 훨씬 적으며 크로스플랫폼 지원도 없음
    심지어 의도적인 듯함. “이 코드를 덜 크로스플랫폼으로 만들기 위해 다시 작성”한 셈임
    언젠가는 계속된 재작성이 멈추고, 실제로 필요한 기능을 모두 지원하는 무언가에 정착하길 바람
    하지만 재작성마다 기능을 잃는다면 Dimforge 생태계가 나에게 맞을지는 모르겠음
    Rapier도 언젠가 더 새로운 무언가를 위해 폐기되고, 그 새 엔진이 Rapier 기능의 절반도 지원하지 않을지 어떻게 알 수 있겠음
    새 프로젝트라서 성숙한 nphysics의 모든 기능을 지원하지 못한다는 건 이해함
    그런데 바로 그 성숙한 nphysics가 완전히 폐기되고 유지보수되지 않는다는 점이 문제임
    Dimforge에 이미 이런 전례가 없었다면 비현실적인 걱정이었겠지만, 기록이 있음
    언젠가 Rapier가 5년 전 nphysics가 이미 갖고 있던 기능 수준에 도달할 수도 있겠지만, 현재 빠진 기능 위에 무언가를 만들고 싶은 개발자에게는 임의의 5년 후퇴처럼 느껴짐

답변달기