Skip to main content

Common mistakes

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

Make sure the Rapier library is built in release mode. Rapier can be 100 times slower without optimizations enabled. Keep in mind that the optimization of the Rapier library is selected by the RAPIER_PROFILE option of CMake (release by default), independently from the build mode of your own C code (selected by CMAKE_BUILD_TYPE): a debug build of your application can still use an optimized Rapier library, as long as it isn't configured with -DRAPIER_PROFILE=debug. The build mode of the library actually loaded by your application is given by r3BuildProfile:

/* Warn if the Rapier library loaded by the application isn't optimized. */
if (strcmp(r3BuildProfile(), "release") != 0) {
    fprintf(stderr, "Rapier is built in debug mode: the simulation will be very slow.\n");
}

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.

warning

Make sure that the descriptions of your rigid-bodies and colliders are initialized by their constructors, e.g., r3DynamicRigidBodyDesc() and r3BallColliderDesc(0.5). A zero-initialized description is a disabled object, and a zero-initialized rigid-body description has a zero gravityScale. See below.

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 100000.0) and see if this stronger force works.
  • The rigid-body is awake, either by calling r3RigidBody_WakeUp(handle, 1) explicitly, or by using 1 as the last argument (wake_up) of the force/impulse application function.
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 crashing 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 (and the forces applied to it) are zeroed, and it is disabled. Note that a quarantined soft-body keeps its non-finite particle positions: they must be fixed with r3SoftBody_SetParticlePosition before enabling it again.

The quarantined objects of the last timestep are copied by r3QuarantinedRigidBodies (resp. r3QuarantinedColliders, r3QuarantinedSoftBodies). This report is cleared at each timestep, so it must be read after the step that generated it (keep in mind that it may contain the handles of objects you removed since). Once the cause is fixed, a quarantined object is brought back into the simulation with r3RigidBody_SetEnabled(handle, 1) (resp. r3Collider_SetEnabled, r3SoftBody_SetEnabled):

r2Step(world, NULL, NULL);

/* After the step, the objects neutralized by this step are known. */
size_t num_quarantined = r2QuarantinedRigidBodies(world, NULL, 0);
R2RigidBodyHandle *quarantined = malloc(num_quarantined * sizeof(R2RigidBodyHandle));
num_quarantined = r2QuarantinedRigidBodies(world, quarantined, num_quarantined);

for (size_t i = 0; i < num_quarantined; i++) {
    printf("The rigid-body {%u, %u} went non-finite and was disabled.\n", quarantined[i].index,
           quarantined[i].generation);
    /* Once the cause is fixed, the rigid-body is brought back into the simulation. */
    r2RigidBody_SetEnabled(quarantined[i], 1);
}
free(quarantined);

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: r2CuboidColliderDesc(r2Vector(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:

R2Pose pose = r2RigidBody_Position(rigid_body);
/* Scale the translation to convert from meters to pixels. */
sprite_translation = r2VectorScale(pose.translation, 50.0);
/* Rotation angles don't need to be scaled. */
sprite_rotation = pose.rotation.angle;

Alternatively, the length unit of the simulation can be set to 50 with r2SetLengthUnit, which scales the internal tolerances of Rapier accordingly. However, every value given to the engine (sizes, positions, velocities, and the gravity) must then be expressed in pixels.

My objects are not inserted, or don't behave as expected​

The descriptions (R3RigidBodyDesc, R3ColliderDesc, R3JointDesc, etc.) must be initialized by one of their constructors, which give every field a meaningful default value, before being modified. A zero-initialized description (e.g. R3RigidBodyDesc desc = {0};) gives a zero value to every field, which is either rejected by the insertion (e.g. a 3D rotation made of zeros isn't a valid quaternion), or accepted silently with surprising results: a disabled object, a rigid-body with a zero gravity scale, a collider with a zero density and collision groups preventing it from colliding with anything, etc.

/* WRONG version: every field is zero, so the rigid-body would be disabled, with a zero gravity
 * scale. In 3D, its insertion even fails because a zero quaternion isn't a valid rotation. */
R3RigidBodyDesc wrong_body = {0};

/* CORRECT version: the constructor gives every field a meaningful default value. */
R3RigidBodyDesc body = r3DynamicRigidBodyDesc();
body.position.translation = r3Vector(0.0, 1.0, 0.0);

The same applies to the 3D rotations: they are unit quaternions, and a quaternion made of zeros isn't one of them. The identity rotation is the quaternion with w = 1 and x = y = z = 0, which is what r3TranslationPose gives:

/* WRONG version: a zero-initialized quaternion isn't a valid rotation, the call fails. */
// R3Pose pose = {{1.0, 2.0, 3.0}, {0}};

/* CORRECT version: start from the identity rotation (0, 0, 0, 1), or build a rotation from an
 * axis and an angle. */
R3Pose pose = r3TranslationPose(r3Vector(1.0, 2.0, 3.0));
pose.rotation = r3RotationFromAxisAngle(r3Vector(0.0, 1.0, 0.0), 0.5);
r3Collider_SetPosition(collider, pose);

A function fails with R3_INVALID_HANDLE​

The handle of an object becomes stale as soon as its object is removed from the world: the functions given a stale handle fail with the R3_INVALID_HANDLE error. Note that removing a rigid-body also removes the joints attached to it, and its colliders if r3RemoveRigidBody is asked to, so their handles become stale as well. If an object may have been removed by another part of your application, check its handle first, e.g., with r3RigidBody_Contains:

r3RemoveRigidBody(handle, 1);

/* The handle is now stale: using it (even to remove it again) fails with R3_INVALID_HANDLE. Check
 * it first if the object may have been removed by another part of the application. */
if (r3RigidBody_Contains(handle)) {
    r3RigidBody_WakeUp(handle, 1);
}
danger

Freeing the world with r3FreeWorld invalidates all its handles, including their copies stored anywhere in your application. Unlike the handles of removed objects, they can't be detected: using one of them is undefined behavior.

A scene query reports an R3_NOT_FOUND error​

Some functions report their failure to find something as the R3_NOT_FOUND error, e.g., r3CastRay when the ray doesn't hit anything. This error is given to the error handler (installed with r3SetErrorHandler) like any other error, which is an issue if your error handler aborts the application. When a miss is an expected outcome, use the Try variant of the function if there is one, e.g., r3TryCastRay, which reports a miss with its found field instead of an error:

/* WRONG version, if missing the ground is expected: a miss is an error (R3_NOT_FOUND) given
 * to the error handler, and the returned hit is meaningless. */
// R3RayHit hit = r3CastRay(world, NULL, r3Vector(0.0, 10.0, 0.0), r3Vector(0.0, -1.0, 0.0), 1.0, 1);

/* CORRECT version: a miss is reported by the `found` field. */
R3OptionalRayHit hit =
    r3TryCastRay(world, NULL, r3Vector(0.0, 10.0, 0.0), r3Vector(0.0, -1.0, 0.0), 1.0, 1);
if (!hit.found) {
    printf("Nothing below.\n");
}

The objects allocated by Rapier are leaking or crashing​

The objects allocated by Rapier and owned by your application (the world, the event collectors, the snapshots, the shared shapes, the controllers, etc.) must be freed by their dedicated Free function, e.g., r3FreeEventCollector, and never with the free function of the C standard library. On the other hand, the objects inserted into the world are owned by the world: they are freed by r3FreeWorld (or when removed), and must not be freed by your application. The descriptions, the handles, and the other plain structures don't own anything and never need to be freed:

/* The objects allocated by Rapier are freed by their own Free function, never by `free`. */
R3EventCollector *events = r3NewEventCollector();
r3Step(world, NULL, events);
r3FreeEventCollector(events);

/* Freeing the world frees everything it contains, and invalidates all its handles. */
r3FreeWorld(world);
world = NULL;

Some fields of the Rapier structures contain garbage values​

The C definitions given to the compiler must match the library your application is linked to: RAPIER_DIM2 or RAPIER_DIM3, RAPIER_F32 or RAPIER_F64, but also RAPIER_FEM and RAPIER_ROBOTICS if the library is built with the corresponding features, since they change the content of some structures (e.g. R3IntegrationParameters and R3SoftBodyDesc), and RAPIER_PARALLEL which declares the functions of the parallel builds. The Rapier::rapier CMake target defines them automatically. If you define them yourself, check them once at the start of your application with r3CheckAbi, which reports an error if the version, the dimension, the precision, or the definitions of the optional features (given by R3_ABI_FEATURES) don't match the library:

/* Checks the version, the dimension, the precision, and the RAPIER_FEM/RAPIER_ROBOTICS definitions,
 * which change the layout of some structures (e.g. R3IntegrationParameters). */
if (r3CheckAbi(R3_ABI_VERSION, R3_DIMENSION, sizeof(R3Real), sizeof(R3Vector), sizeof(R3Pose),
               R3_ABI_FEATURES) != R3_OK) {
    fprintf(stderr, "Incompatible Rapier library: %s\n", r3LastError());
    exit(EXIT_FAILURE);
}

A function fails with R3_WORLD_BUSY​

A world can be read by several threads at once, but its modification (and its stepping) requires an exclusive access. A modification conflicting with another access fails with the R3_WORLD_BUSY error instead of waiting. This happens when the world is modified by another thread at the same time, or when a callback called during a timestep (e.g. a physics hook) tries to access the world being stepped: the callbacks must only read the world through the R3ReadContext they are given (with the r3Read functions, e.g., r3ReadRigidBody_Translation), and defer their modifications until the end of the timestep.