Works on: Desktop, Mobile and Web

Documentation | Changelog | Discord | Contributing | Architecture

---

2D and 3D physics engine for the Godot game engine. with better stability, performance, liquids, determinism, state serialization and no ghost collisions.

---

Godot Rapier Physics is a 2D and 3D physics drop-in replacement for the Godot game engine through rapier physics engine salva fluids simulation library.

Features

Stability	No Vibrations

Fluids 2D	Fluids 3D

Body Skin	Inverse Kinematics

No Ghost Collisions	Improved Stacking

Serialization	Deserialization
Save Physics State	Load Physics State

Locally Deterministic	Cross Platform Deterministic
Exact simulation every time (on same platform)	Exact simulation on multiple platforms

Installation

• Automatic (Recommended): Download the plugin from the official Godot Asset Store using the Asset Store tab in Godot:

  • Rapier Physics 2D
  • Rapier Physics 3D

  Note: Each dimension ships an export library and an editor library. Godot selects them automatically; the editor library includes built-in class documentation. Both run the parallel SIMD solver and are cross platform deterministic.

• Manual: Download the latest github release and move only the addons folder into your project addons folder.

After installing, go to Advanced Settings -> Physics -> 2D or 3D. Change Physics Engine to Rapier2D or Rapier3D.

Rust dependency

See godot-rust/ExtensionLibrary.

[dependencies]
godot-rapier = { git = "https://github.com/appsinacup/godot-rapier-physics.git", tag = "v0.36.0", features = ["single-dim2"] }

Feature sets matching the shipped addon builds:

Build	Features
2D	single-dim2, serde-serialize, parallel, experimental-threads, api-4-7
3D	single-dim3, serde-serialize, parallel, experimental-threads, api-4-7

Editor libraries add register-docs to these feature sets and live under bin/editor/. Both debug and release exports use the libraries without this feature from bin/. Each CI job builds the two variants sequentially.

Use exactly one Godot API feature: api-4-4, api-4-5, api-4-6, or api-4-7.

SIMD and cross-platform determinism are not features you opt into: SIMD is always compiled (with a scalar fallback on targets that lack it) and enhanced-determinism is enabled on the Rapier dependencies for every build. parallel stays optional since web builds cannot use it.

For web/Emscripten builds, add one web feature: experimental-wasm for threaded web builds, or experimental-wasm-nothreads for no-thread web builds. experimental-wasm-nothreads includes experimental-wasm. CI builds web with wasm32-unknown-emscripten, release-wasm, and -Zbuild-std.

When depending on another GDExtension crate, set GDRUST_MAIN_EXTENSION to your extension's ExtensionLibrary type and explicitly forward Godot Rapier's init stages from your extension. Godot only runs one main ExtensionLibrary, so the user's extension must register the Rapier server and classes too:

use godot::prelude::*;
use godot_rapier::RapierPhysics3DExtensionLibrary;

struct MyExtension;

#[gdextension]
unsafe impl ExtensionLibrary for MyExtension {
    fn min_level() -> InitLevel {
        InitLevel::Servers
    }

    fn on_stage_init(level: InitStage) {
        RapierPhysics3DExtensionLibrary::on_stage_init(level);
    }

    fn on_stage_deinit(level: InitStage) {
        RapierPhysics3DExtensionLibrary::on_stage_deinit(level);
    }
}

For 2D projects, use RapierPhysics2DExtensionLibrary.

Do not load the standalone Godot Rapier addon in the same Godot project when bundling it through another Rust GDExtension, because Godot classes can be registered twice.

Youtube Videos

GamesFromScratch:

Showcase

Got a game or app you built with this addon? We showcase them on godot.rapier.rs/showcase. Submit your entry here.

Implementation Progress

The 2D part is pretty stable, though there are some issues, the 3D part is still missing some things. See the Implementation Progress to get an idea of what status it is in and what features it has.

Limitations

• Double builds need to be manually built.
• No support for asymmetric collisions (eg. object 1 hitting object 2 but object 2 not hitting object 1). This is the exact check rapier does: (A.layer & B.mask) != 0 || (B.layer & A.mask) != 0
• 2D intersect_point skips objects with input_pickable off, and physics bodies have it off by default. Godot doesn't tell a GDExtension whether a point query comes from mouse picking or from a script, so Rapier honors input_pickable for both to keep mouse picking correct. To get Godot's behavior for script queries, either turn on input_pickable on the bodies or disable the physics/rapier/queries/point_query_honors_pickable project setting. With the setting off, mouse picking also reaches non-pickable objects.

Module build

In order to build it as a module, go to:

• Godot Rapier Physics Module 2D
• Godot Rapier Physics Module 3D

Balaur Engine

The authors of this addon are also building Balaur: a node-based 2D and 3D game engine written in Rust, together with Sébastien Crozet, the author of Rapier.

Rapier is its physics too, stepped on a fixed 60 Hz tick, but the determinism covers the whole engine rather than just the physics server: same inputs, same bits on every platform, with a digest per tick, record and replay, and rollback. Scripts are written in Rune and hot reload in milliseconds with the state intact.

It is at 0.1 and builds from source for now. Godot Rapier Physics is a separate project and is still maintained.

AI Usage

This project uses AI to aid in software development (and accepts AI contributions). In order for the code quality to remain high, and to not have a ton of bugs, crashes, etc. We use a set of best practices, that are used all throughout the industry, such as: manual testing, automated testing, architecting it, creating spec docs, linting, benchmarking, etc. More can be found out here: CONTRIBUTING.md

Every bit of code is tested against this pipeline / process. There is also an automated CI that runs automated tests to ensure that features still work/

There is also a lot of observability and documentation which we use, as the codebase is large and it will keep growing, so having a high level understanding of it is very important, as well as a low level one. For that we have both references from code for nodes/properties, but also documentation and blogposts per features:

• ARCHITECTURE.md
• CHANGELOG.md
• Feature List

Star History

Star History