Rapier เอนจินฟิสิกส์ 2D·3D ที่เขียนด้วย Rust

 (rapier.rs)
3 คะแนน โดย GN⁺ 2024-02-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Rapier คือชุดเอนจินฟิสิกส์บน Rust ที่มุ่งเป้าไปยังแอปพลิเคชันที่ต้องใช้ ฟิสิกส์แบบเรียลไทม์ เช่น เกม แอนิเมชัน และโรโบติกส์
  • มีเป้าหมายด้านการทำงานที่รวดเร็วและเสถียร พร้อมรองรับ determinism ข้ามแพลตฟอร์ม แบบเลือกใช้ได้เมื่อจำเป็น
  • มีฟีเจอร์ที่จำเป็นสำหรับการจำลองฟิสิกส์ เช่น การชนและแรงของวัตถุแข็ง ข้อจำกัดของจอยน์ต์ อีเวนต์การสัมผัสและเซนเซอร์ รวมถึงสแนปช็อต
  • มี JavaScript binding ทำให้สามารถใช้ Rapier ได้ในสภาพแวดล้อมอื่นนอกเหนือจาก Rust
  • เป็นโอเพนซอร์สฟรีภายใต้ไลเซนส์ Apache 2.0 พัฒนาโดย Dimforge และรับการสนับสนุนผ่าน GitHub Sponsor

กรณีใช้งานที่ Rapier มุ่งเป้า

  • Rapier คือชุดเอนจินฟิสิกส์ 2D และ 3D ที่เขียนด้วย Rust
  • กลุ่มเป้าหมายหลักคือแอปพลิเคชันที่ต้องประมวลผลฟิสิกส์แบบเรียลไทม์
    • วิดีโอเกม
    • แอนิเมชัน
    • โรโบติกส์
  • เป้าหมายการออกแบบคือ การทำงานที่รวดเร็วและเสถียร และรองรับ determinism ข้ามแพลตฟอร์มแบบเลือกใช้ได้

ฟีเจอร์ที่มีให้และรูปแบบการเผยแพร่

  • รวมฟีเจอร์หลักสำหรับการจำลองฟิสิกส์ไว้ด้วย
    • การชนของวัตถุแข็ง และแรง
    • ข้อจำกัดของจอยน์ต์
    • อีเวนต์การสัมผัสและเซนเซอร์
    • สแนปช็อต
    • determinism ข้ามแพลตฟอร์มแบบเลือกใช้ได้
    • JavaScript binding
  • Rapier เป็นโอเพนซอร์สฟรีและเผยแพร่ภายใต้ ไลเซนส์ Apache 2.0
  • ผู้พัฒนาคือบริษัทโอเพนซอร์ส Dimforge
  • สามารถสนับสนุนได้ผ่าน GitHub Sponsor

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-29
ความคิดเห็นจาก Hacker News

  • เคยสร้างเกมออนไลน์แบบมัลติเพลเยอร์ด้วย โหมด deterministic ของ Rapier
    เกมเป็นแบบให้ผู้เล่นผลัดกันพุ่งชนแมลงไปทางฝั่งทีมตรงข้ามและยึดเนินเขา
    ตอนนี้ยังไม่มีโหมดเล่นคนเดียว และการเขียน AI ก็ยากกว่าเกมแนวหมากรุกที่เคยทำก่อนหน้านี้
    เกมดูได้ที่ https://evrimzone.itch.io/crittershowdown และซอร์สโค้ดฟิสิกส์/ลอจิกเกมอยู่ที่ https://github.com/evrimoztamur/crittershowdown/blob/e4d9a19...
    วางแผนว่าจะเขียนเล่าในภายหลังว่าประกอบทุกอย่างเข้าด้วยกันอย่างไรและได้เรียนรู้อะไรบ้าง แต่โดยรวมแล้วเป็นไลบรารีที่แข็งแรงมาก และด้วยการออกแบบ API แบบ Rust ก็ทำให้ทำทุกอย่างที่ต้องการได้

    • ดูสนุกดี อยากรู้ว่าปล่อยขึ้นเว็บได้ง่ายไหม
      สงสัยว่าคอมไพล์เป็น WebAssembly หรือโฮสต์ลอจิกทั้งหมดไว้บนโลคัลเซิร์ฟเวอร์
    • กำลังเริ่มใช้ Rapier2D เพื่อทำเกมมัลติเพลเยอร์ฝั่งเซิร์ฟเวอร์ เลยหวังว่าจะมีบทความเกี่ยวกับเรื่องนี้ออกมาเร็ว ๆ

  • เมื่อไม่กี่เดือนก่อนผมไปหลงใหล Geometric Algebra มา และรู้สึกว่ามันเป็นวิธีที่กระชับและเข้าใจง่ายอย่างน่าประหลาดในการจัดการเรขาคณิตได้หลากหลายมาก ทั้ง 2D, 3D, 4D ขึ้นไป, non-Euclidean ฯลฯ
    เลยสงสัยว่า geometric algebra จะเป็นรากฐานที่ดีสำหรับฟิสิกส์เอนจินได้หรือไม่
    มีไลบรารี Rust ที่ดูน่าสนใจอยู่ไม่กี่ตัว [1][2] แต่ดูเหมือนจะยังไม่ได้รับความสนใจมากนัก
    เลยอยากรู้ว่ามีใครเคยสำรวจทางนี้บ้างไหม
    [1]: https://crates.io/keywords/geometric-algebra
    [2]: https://github.com/Lichtso/geometric_algebra
    ถ้าอยากเริ่มต้น วิดีโอ “Why can't you multiply vectors?” ของ Freya Holmér อาจเป็นทางเข้าที่ดี: https://www.youtube.com/watch?v=htYh-Tq7ZBI และ https://bivector.net/index.html

    • ข้อเท็จจริงที่น่าสนใจคือ Excalidraw เคยใช้ geometric algebra และตอนนี้ก็ยังใช้ขับเคลื่อนอินเทอร์แอ็กชันบางส่วนอยู่: https://github.com/excalidraw/excalidraw/blob/master/package...
    • ส่วนที่น่าสนใจน้อยที่สุดของฟิสิกส์เอนจินคือ การแทนเวกเตอร์
      geometric algebra นั้นไอโซมอร์ฟิกกับเวกเตอร์แอลจีบราแบบ Heaviside “ดั้งเดิม” และปัญหาที่ยากจริง ๆ คือเรื่องอย่างการจัดการการชน การอนุรักษ์พลังงาน และเสถียรภาพ
    • ผมก็ตกลงไปใน โพรงกระต่ายของ geometric algebra เหมือนกัน และยังไปหลงใหล Clojure ซึ่งเป็นอีกวิธีหนึ่งที่ “กระชับและเข้าใจง่ายอย่างน่าประหลาด”
      เลยสร้างไลบรารีที่สามารถสร้าง geometric algebra แบบใดก็ได้และทำโอเปอเรชันสนุก ๆ ได้หลายอย่าง ซึ่งใช้เป็นพื้นฐานของฟิสิกส์เอนจินได้ด้วย
      ถ้าสนใจอยู่ที่นี่: https://cljdoc.org/d/net.clojars.jordibc/geometric-algebra/
    • ทิวทอเรียลที่เกี่ยวข้อง: https://www.youtube.com/watch?v=5R2sv9GCwz0
    • ตัวที่ได้รับความสนใจมากกว่าน่าจะเป็นไลบรารีนี้: https://github.com/fu5ha/ultraviolet

  • ผมเขียนไกด์สำหรับ ปลั๊กอิน Bevy Rapier บน Rust ไว้: https://taintedcoders.com/bevy/rapier/
    อีกทางเลือกที่น่าสนใจฝั่ง Bevy คือ Bevy XPBD ซึ่งผมก็เขียนสรุปไว้เหมือนกัน: https://taintedcoders.com/bevy/xpbd/

    • พอเห็นระบบที่ถือว่าวัตถุที่เคลื่อนที่ช้าเป็นวัตถุที่ไม่เคลื่อนที่แล้วรู้สึกไม่ค่อยสบายใจ
      มีการบอกว่า “Sleeping” เป็นเทคนิคที่ช่วยเพิ่มประสิทธิภาพโดยลดต้นทุนการจำลองวัตถุที่ไม่เคลื่อนที่ และสามารถปรับได้ด้วยรีซอร์ส SleepingThreshold
      ตัวอย่างค่าเริ่มต้นคือ linear: 0.1, angular: 0.2
    • ตอนนี้กำลังทำเกมต่อสู้ 2D ที่อิงฟิสิกส์ด้วย xpbd และจนถึงตอนนี้ก็ชอบมันพอสมควร
      ที่เจอจนถึงตอนนี้มีแค่ปัญหาว่าการชนบางครั้งหายไปหนึ่งเฟรม แต่เรื่องแบบนี้เลี่ยงได้ง่าย และที่ดีกว่าคือรายงานเพื่อให้แก้ไขได้
    • XPBD น่าสนใจมากจนผมลองทำ implementation ทดสอบอยู่หลายครั้ง และในผลงาน game jam ล่าสุดก็ใส่ XPBD ที่รองรับเฉพาะ AABB ลงไป
      ตอนนี้ยังทำเรื่องการหมุนได้ไม่ดี แต่ที่เหลือเหมือนความซับซ้อนละลายหายไป
      linear algebra? ไม่ต้องใช้ แค่ Vec3 ก็พอ เมทริกซ์? ตัวแก้สมการ? แค่ไล่ทำให้ทุก constraint เป็นจริงซ้ำ ๆ เหมือนย้อนกลับไปปี 1998
      collision margin? เป็นปัญหาเรื่องฝีมือ broad phase? GJK? อย่าคิดเยอะ ปล่อยให้ CPU สมัยใหม่จัดการไป
      พอทำ optimization ให้ collect_pairs แล้วค่อยพบว่าคอขวดจริง ๆ คือ malloc และพอแก้แล้วก็จัดการวัตถุระดับร้อยชิ้นได้สบาย ไม่ต้องพึ่ง Bullet
      ตอนแรกยังงงกับขั้นตอนแก้ความเร็วอยู่บ้าง แต่พอทำต้นแบบด้วย AABB แล้วก็ดูเหมือนจะย้ายกลับไปใช้กับรูปทรงทั่วไปได้ด้วย
      ตอนแรกผมข้ามขั้นตอนนี้ไป ทำให้การชนทั้งหมดมีพฤติกรรมเด้งเล็กน้อยเหมือนยืดหยุ่น

  • Dimforge กำลังทำสิ่งที่น่าทึ่งมาก
    ถ้า nalgebra + Rust สามารถมาแทนที่ Eigen + C++ ได้ในงานอย่างการระบุตำแหน่งและการทำแผนที่ในวงการหุ่นยนต์ ก็น่าตื่นเต้นมาก

    • ช่วงหลังมานี้ผมทำโปรเจ็กต์หุ่นยนต์ส่วนใหญ่ด้วย Rust และเวลาที่ทั้งวงการเสียไปกับสำนวนเฉพาะทางแบบ C++ นั้นมากเกินเหตุจริง ๆ
      ใน Rust มีหลายอย่างที่มันใช้งานได้เลยตามปกติ แต่อดเสียดายไม่ได้ที่ยังมีคนรุ่นเก่าที่ไม่ยอมถอยและปฏิเสธการลงทุนกับ Rust
      พูดตามตรงก็เข้าใจเหตุผล เพราะมีอุตสาหกรรมขนาดใหญ่อยู่รอบ ๆ โค้ดหุ่นยนต์ C++
    • อยากทำให้สิ่งนี้เกิดขึ้นจริง
      ตอนนี้สงสัยว่าใน Rust มี เฟรมเวิร์กหุ่นยนต์ ที่ใช้งานได้ดีบ้างไหม
      เคยได้ยินว่า ROS2 กำลังค่อย ๆ รองรับ Rust [1] แต่ไม่แน่ใจว่าคืบหน้าไปถึงไหนแล้ว
      เนื่องจากการรวมและนามธรรมของฮาร์ดแวร์ถูกทำไว้ใน C++ อยู่แล้ว ROS จึงอาจเป็นจุดเริ่มต้นที่ดีสำหรับงาน sensor fusion, mapping และ localization
      ก็สงสัยเหมือนกันว่ามีบริษัทไหนใช้งานสิ่งนี้อยู่บ้าง
      [1] https://github.com/ros2-rust/ros2_rust

  • จากที่จำได้ตอนสร้างเอนจินฟิสิกส์ rigid body เมื่อหลายสิบปีก่อน ปัญหาเรื่อง การซ้อนวาง (stacking) นั้นยากมาก
    ตอนนั้นวิธีที่ดีที่สุดในการหลีกเลี่ยงไม่ให้วัตถุจมลงพื้น คือสร้างกราฟไม่มีวงจรแบบมีทิศทางที่เริ่มจากพื้นและผลักวัตถุออกไปด้านนอก
    ต้องวนซ้ำหลายรอบกว่าจะลู่เข้า และรู้สึกว่าเป็นวิธีที่ค่อนข้างแฮ็ก
    อยากรู้ว่าสมัยนี้ปัญหานี้ถูกแก้ไปแล้วหรือยัง ในโปรเจ็กต์นี้ผมหาไม่เจอว่ามีการพูดถึงเรื่อง stacking

    • ผู้เขียน Box2D มีบทความที่ยอดเยี่ยมตรงประเด็นนี้เลย: https://box2d.org/posts/2024/02/solver2d/
      วิดีโอของผู้เขียนที่ลิงก์ไว้ท้ายบทความแสดงให้เห็นว่าแต่ละ solver จัดการกับปัญหา stacking ยาก ๆ อย่างไร: https://youtu.be/sKHf_o_UCzI
    • ทุกวันนี้ stacking ทำงานได้ดี
      ไม่จำเป็นต้องใช้กราฟไม่มีวงจร และถ้าเพิ่ม จำนวนรอบการทำซ้ำของ solver ให้มากพอ มันก็จะลู่เข้า
      เมื่อคิดถึงจำนวน constraint ของ contact และ friction การวนหลายรอบก็ถือเป็นเรื่องธรรมชาติ และถ้าติดตามค่าสูงสุดของ residual ก็สามารถปล่อยให้มันรันจนเกือบเป็น 0 ได้
      ส่วนที่ยังพังอยู่บ้างคือ collision และ solver มักจะรันได้แค่ที่อัตราอัปเดตจำกัด
      ถ้าเริ่มต้นมาในสถานะที่ทะลุกันอยู่แล้ว ก็ต้องคลี่สถานะนั้นออก แต่ในโลกจริงวัตถุไม่ได้ทะลุกันแบบนั้น จึงเป็นการจัดการที่ค่อนข้าง “ปลอม” และอาจทำให้เกิดการเคลื่อนไหวเพิ่มขึ้นจนความเสถียรของสแต็กลดลง
      ถึงอย่างนั้นก็มีหลายวิธีในการเลี่ยงปัญหานี้ และเอนจินฟิสิกส์ยอดนิยมต่างก็มีทางแก้ของตัวเองไม่ทางใดก็ทางหนึ่ง

  • 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) กับฝั่งไคลเอนต์ (เบราว์เซอร์)
    อันนี้รันฝั่งเซิร์ฟเวอร์ แต่ก็สามารถรันทั้งสองฝั่งแล้วทำ client prediction กับ correction ได้เหมือนกัน
    ขนาดบันเดิลก็เล็กด้วย AmmoJS เหมือนจะประมาณ 2MB

    • ฝั่ง Rust เท่าที่รู้ เอกสารของ Rapier ยังไม่อัปเดตล่าสุด
      โชคดีที่มันค้างอยู่กับเวอร์ชันก่อนหน้า จึงไม่ได้แย่มากนัก

  • การทำงานร่วมกับ JavaScript ก็ดีมากจริง ๆ: https://www.rapier.rs/docs/user_guides/javascript/getting_st...

  • ก่อนหน้านี้ Dimforge เคยมีเอนจินฟิสิกส์ชื่อ nphysics ที่รองรับ soft body และ multibody
    ตอนนี้มันถูกยกเลิกเพื่อเปิดทางให้ Rapier แต่ Rapier ยังรองรับฟีเจอร์เหล่านั้นหรือฟีเจอร์อื่น ๆ ที่ nphysics เคยทำได้ไม่ถึงครึ่งด้วยซ้ำ
    ผลก็คือ nphysics เก่าเกินไปจนใช้งานในระบบนิเวศสมัยใหม่ได้ยาก ขณะที่ Rapier ใหม่เกินไปจนมีฟีเจอร์น้อยกว่ามาก
    ก่อนหน้านี้ก็เคยมีเรื่องคล้ายกัน ไลบรารีจำลองของไหลชื่อ Salva เคยรองรับการเชื่อมสองทางกับ nphysics และรันได้ทั้ง GPU/CPU ทุกแบบ แต่ตอนนี้ก็ถูกยกเลิกเพื่อเปิดทางให้ Sparkl
    ปัญหาคือ Sparkl ไม่มีฟีเจอร์เหล่านั้นและรองรับแค่ CUDA ดังนั้น Salva จึงเก่าเท่า nphysics ส่วน Sparkl ก็ใหม่เกินไป ฟีเจอร์น้อยกว่ามาก และไม่รองรับข้ามแพลตฟอร์ม
    มันถึงขั้นดูเหมือนตั้งใจเลย เหมือน “เขียนโค้ดนี้ใหม่เพื่อให้รองรับข้ามแพลตฟอร์มน้อยลง”
    หวังว่าสักวันหนึ่งการเขียนใหม่ซ้ำ ๆ จะหยุดลง และจะมีอะไรบางอย่างที่ลงตัวพร้อมรองรับฟีเจอร์ที่จำเป็นจริง ๆ ทั้งหมด
    แต่ถ้าทุกครั้งที่เขียนใหม่ต้องเสียฟีเจอร์ไปเรื่อย ๆ ก็ไม่แน่ใจว่า ระบบนิเวศของ Dimforge จะเหมาะกับผมหรือเปล่า
    จะรู้ได้อย่างไรว่า Rapier จะไม่ถูกยกเลิกในวันหนึ่งเพื่อเปิดทางให้ของใหม่กว่า แล้วเอนจินใหม่นั้นจะไม่รองรับแม้แต่ครึ่งหนึ่งของฟีเจอร์ Rapier
    เข้าใจได้ว่าโปรเจ็กต์ใหม่ยังไม่สามารถรองรับทุกฟีเจอร์ของ nphysics ที่สุกงอมแล้วได้
    แต่ปัญหาคือ nphysics ที่สุกงอมแล้วตัวนั้นกลับถูกยกเลิกทั้งหมดและไม่มีการดูแลต่อ
    ถ้า Dimforge ไม่มีประวัติแบบนี้มาก่อน มันก็คงเป็นความกังวลที่ไม่สมจริง แต่ที่ผ่านมาก็มีตัวอย่างอยู่แล้ว
    สักวัน Rapier อาจไปถึงระดับฟีเจอร์ที่ nphysics มีอยู่แล้วเมื่อ 5 ปีก่อนได้ แต่สำหรับนักพัฒนาที่อยากสร้างอะไรบนฟีเจอร์ที่ยังขาดอยู่ตอนนี้ มันให้ความรู้สึกเหมือน ถอยหลังไป 5 ปี แบบตามอำเภอใจ