Skip to main content

Simulation structures

This page describes all the useful components and resources added automatically by the RapierPhysicsPlugin.

Rapier Context​

The data structures handled by rapier for a specific context are stored in different components.

An ergonomic QueryData helper is provided to reduce boilerplate: See https://docs.rs/bevy_rapier3d/latest/bevy_rapier3d/plugin/context/systemparams/struct.RapierContext.html

Gravity​

Gravity is represented as a vector. It affects every dynamic rigid-body taking part of the simulation. The gravity can be altered at each timestep (by modifying the component field RapierConfiguration::gravity). Learn more about per-rigid-body gravity modification in the dedicated section.

Integration parameters​

The IntegrationParameters component field from RapierContext controls various aspects of the physics simulation, including the timestep length, number of solver iterations, number of CCD substeps, etc. The default integration parameters are set to achieve a good balance between performance and accuracy for games. They can be changed to make the simulation more accurate at the expense of a bit of performance. Learn more about each integration parameter in the API docs.

Island manager​

The IslandManager component field from RapierContext is responsible for tracking the set of dynamic rigid-bodies that are still moving and these that are no longer moving (and can ignored by subsequent timesteps to avoid useless computations). The island manager is automatically updated by PhysicsPipeline::step and can be queried to retrieve the list of all the rigid-bodies modified by the physics engine during the last timestep. This can be useful to update the rendering of only the rigid-bodies that moved:

this is not used, nothing links to it. Also, it's not compiling.

 
fn print_active_bodies_positions(island_manager: Res<IslandManager>, positions: Query<&RigidBodyPositionComponent>) {
    // Iter on each dynamic rigid-bodies that moved.
    for rigid_body_handle in island_manager.active_dynamic_bodies() {
        if let Ok(rb_pos) = positions.get(rigid_body_handle.entity()) {
            println!("Rigid body {:?} has a new position: {}", rigid_body_handle, rb_pos.position);
        }
    }
}

Learn more about sleeping rigid-bodies in the dedicated section.

Physics pipeline​

The PhysicsPipeline from the RapierContextSimulation component is responsible for tying everything together in order to run the physics simulation. It will take care of updating every data-structures mentioned in this page (except the other pipelines), running the collision-detection, running the force computation and integration, and running CCD resolution.

Collision pipeline​

The CollisionPipeline is similar to the PhysicsPipeline except that it will only run collision-detection. It won't perform any dynamics (force computation, integration, CCD, etc.) It is generally used instead of the PhysicsPipeline when one only needs collision-detection.

info

Running both the CollisionPipeline and the PhysicsPipeline is useless because the PhysicsPipeline already does collision-detection.

Query pipeline​

The QueryPipeline is responsible for efficiently running scene queries, e.g., ray-casting, shape-casting (sweep tests), intersection tests, on all the colliders of the scene.

Learn more about scene queries with the QueryPipeline in the dedicated page.

CCD solver​

The CCD solver resource is responsible for the resolution of Continuous-Collision-Detection. By itself, this structure doesn't expose any useful feature. So it should simply be passed to the PhysicsPipeline::step method. Learn more about CCD in the dedicated section.

Physics hooks​

The physics hooks are trait-objects implementing the PhysicsHooks trait. They can be used to apply arbitrary rules to ignore collision detection between some pairs of colliders. They can also be used to modify the contacts processed by the constraints solver for computing forces. Learn more about physics hooks in the dedicated section.

Event handler​

The event handlers are trait-objects implementing the EventHandler trait. They can be used to get notified when two non-sensor colliders start/stop having contacts, and when one sensor collider and one other collider start/stop intersecting. Learn more about collision events in the dedicated section.