Skip to main content

Common mistakes

My local build of Rapier is slower than the online demos​

Make sure you are building your project (or just the Rapier dependency) in release mode, e.g., cargo build --release. Rapier can be 100 times slower without optimizations enabled. Keep in mind that it is possible to compile your project without optimizations while keeping optimizations enabled for Rapier itself:

# Add this to your Cargo.toml
[profile.dev.package.rapier3d]
opt-level = 3

See the cargo book about profile overrides for details about this technique.

info

Also note that setting the number codegen units to 1 will further improve performances in a noticeable way, even for a release build (though the build itself will take longer to complete):

# Add this to your Cargo.toml
[profile.release]
codegen-units = 1

Rigid-body isn't affected by gravity​

If you expect your rigid-body to fall because of gravity but it doesn't, please make sure to double-check the following:

  • Your gravity vector is non-zero.
  • Your rigid-body is a dynamic rigid-body.
  • You didn't lock the translations of the rigid-body.
  • The rigid-body has a non-zero mass.

Note that a collider not attached to a dynamic rigid-body will never fall because it won't be affected by forces.

note

If the rigid-body has no collider attached to it, its mass will be zero unless you gave it a mass (or mass properties) explicitly. If the rigid-body has colliders attached to it and you didn't give the rigid-body a mass explicitly, make sure that at least one of the colliders has a non-zero density (or non-zero mass if you set it explicitly on the collider).

warning

The shapes that don't enclose any volume, i.e., the polylines, the half-spaces, the segments, and the triangles in 3D, have a zero mass whatever their density. So if a rigid-body only has colliders with such shapes attached to it, you need to set its mass/angular inertia manually. Note that a triangle-mesh isn't one of them: its mass properties are computed from the volume enclosed by its faces, which assumes that the mesh is closed and that its triangles are consistently oriented.

Applying a force to a rigid-body doesn't work​

If applying a force or an impulse to a rigid-body doesn't work, please make sure to double-check the following:

  • The rigid-body is a dynamic rigid-body.
  • The rigid-body has a non-zero mass (or non-zero angular inertia for torques).
  • The force or impulse must be strong enough to actually push the rigid-body. You may for example try with a very high force/impulse value (say, with a magnitude of 100_000.0) and see if this stronger force works.
  • The rigid-body is awake, either by calling RigidBody::wake_up(true) explicitly, or by using true as the last argument of the force/impulse application method.
note

If the rigid-body has no collider attached to it, its mass will be zero unless you gave it a mass (or mass properties) explicitly. If the rigid-body has colliders attached to it and you didn't give the rigid-body a mass explicitly, make sure that at least one of the colliders has a non-zero density (or non-zero mass if you set it explicitly on the collider).

A rigid-body suddenly stops being simulated​

It may happen that a rigid-body disappears from the simulation, i.e., it stops moving and stops generating contacts, without being removed by your own code. This generally means that non-finite values (NaN or infinites) appeared in its position or in its velocity for one reason or another (could be the simulation diverged, incorrect values provided, etc.)

Rather than panicking or letting these values propagate and corrupt the whole simulation, Rapier detects them at the beginning and at the end of each timestep, and puts the affected rigid-body, collider, or soft-body in quarantine: it is reset to its last valid position when one is known, its velocities are zeroed, and it is disabled.

The quarantined objects of the last timestep are reported by PhysicsWorld::quarantine (or by PhysicsPipeline::quarantine if you step the pipeline yourself). This report is cleared at each timestep, so it must be read after the step that generated it. Once the cause is fixed, a quarantined object is brought back into the simulation with RigidBody::set_enabled(true) (resp. Collider::set_enabled(true)):

world.step();

// After the step, the objects neutralized by this step are known.
let quarantined = world.quarantine().bodies().to_vec();
for handle in quarantined {
    println!("The rigid-body {:?} went non-finite and was disabled.", handle);
    // Once the cause is fixed, the rigid-body is brought back into the simulation.
    world.bodies[handle].set_enabled(true);
}

The most common configuration that leads to non-finite values is two dynamic rigid-bodies with a zero mass starting to be in contact. Therefore, make sure that your dynamic rigid-bodies have a non-zero mass. Note that the values given to the physics engine are checked too: a position or a velocity set to NaN by your own code (e.g. after a division by a zero-length vector) is caught at the beginning of the next timestep.

note

If the rigid-body has no collider attached to it, its mass will be zero unless you gave it a mass (or mass properties) explicitly. If the rigid-body has colliders attached to it and you didn't give the rigid-body a mass explicitly, make sure that at least one of the colliders has a non-zero density (or non-zero mass if you set it explicitly on the collider).

Why is everything moving in slow-motion?​

A common mistake, especially in 2D, is to use pixels as the length unit in the physics world. Let's say that in 2D you have a 100x100 pixels sprite for your player. It may be tempting to use a 100x100 cuboid collider for this sprite: ColliderBuilder::cuboid(50.0, 50.0) (we set 50.0 because this is the half-width of the cuboid). Doing this will make it look like the simulation runs in slow-motion because the cuboid will be huge compared to the magnitude of the default gravity (-9.81).

The recommended way of using Rapier is to use SI units (meters, seconds, kilograms, etc.) If the player sprite is a 100x100 cuboid, then it is as if your player is 100 meters tall and 100 meters wide, which is huge. Therefore it is recommended to have a scaling factor between the graphics and the physics. For example we can say that 1 physics meter is equal to 50 pixels. This means that we can initialize our player collider as a 2x2 cuboid while still using a 100x100 pixels sprite.

All we need to do to keep measures in sync is to multiply by our scaling factor 50 all the positions given by the physics engine before rendering:

// Scale the translation to convert from meters to pixels
sprite.set_translation(rigid_body.translation() * 50.0);
// Rotation angles don't need to be scaled
sprite.set_rotation(rigid_body.rotation().angle());