Collider::convex_mesh() produces surprising results

[leftmostcat]

When using Collider::convex_mesh(), I seem to consistently get a center of mass "outside" the shape, causing the resulting body to behave incorrectly. The following is a simple repro case with a regular tetrahedron, which I expect to fall, collide with the "table", and come to rest quickly. Instead, it will fall and then begin spinning for an extended duration.

I suspect that I'm specifying the indices incorrectly, but there is no documented ordering or other restrictions, either on Collider::convex_mesh() or the underlying implementations.

use bevy::prelude::*;
use bevy_rapier3d::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(RapierPhysicsPlugin::<NoUserData>::default())
        .add_plugins(RapierDebugRenderPlugin::default())
        .add_systems(Startup, set_up_camera)
        .add_systems(Startup, set_up_physics)
        .add_systems(Update, bevy::window::close_on_esc)
        .run();
}

fn set_up_camera(mut commands: Commands) {
    commands.spawn(Camera3dBundle {
        projection: Projection::Perspective(Default::default()),
        transform: Transform::from_xyz(0.0, 10.0, 0.0).looking_at(Vec3::ZERO, Vec3::Z),
        ..default()
    });
}

fn set_up_physics(mut commands: Commands) {
    commands
        .spawn(Collider::cuboid(100.0, 0.1, 100.0))
        .insert(TransformBundle::from(Transform::from_xyz(0.0, 0.0, 0.0)));

    commands
        .spawn(RigidBody::Dynamic)
        .insert(Velocity::default())
        .insert(
            Collider::convex_mesh(
                vec![
                    Vec3::new(-0.5, 0.0, 0.0),
                    Vec3::new(0.5, 0.0, 0.0),
                    Vec3::new(0.0, 0.0, 0.866025404),
                    Vec3::new(0.0, 0.816496581, 0.433012702),
                ],
                &[[0, 1, 2], [0, 1, 3], [0, 2, 3], [1, 2, 3]],
            )
            .unwrap(),
        )
        .insert(TransformBundle::from(Transform::from_xyz(0.0, 9.0, 0.0)));
}

[Vrixyz]

Seems fixed following dimforge/parry#192. I do not reproduce the same behaviour.

That being said, with this code the convex mesh takes a lot of time before actually falling 🤔.

My observed behaviour

delayed_fall.mp4

[sebcrozet]

I’m pretty sure the issue here is that the index buffer given to Collider::convex_mesh is invalid. Although it is not clearly documented, the input mesh is supposed to have outward triangle normals. I wrote that small test for checking the triangles validity and it is showing that:

Convex polyhedron face [0,1,3] is not properly oriented: [[0.0, -0.433012702, 0.816496581]].dot([[0.5, 0.0, 0.866025404]]) = 0.7071067814251437 > 0.0
Convex polyhedron face [1,2,3] is not properly oriented: [[-0.7071067814251437, -0.216506351, -0.4082482905]].dot([[-1.0, 0.0, 0.0]]) = 0.7071067814251437 > 0.0

Considering the input polyhedron isn’t properly formed, weird behaviors are expected and not worth debugging (nor fixable).

I think there are three actions to move forward here:

1. Check if it works properly with an index buffer set to [[0, 1, 2], [0, 3, 1], [0, 2, 3], [1, 3, 2]] (I flipped the orientation of the two problematic triangles).
2. We should run this check automatically when building the convex polygon on that function. The check is expensive O(n²), so we should make it optional somehow. Perhaps we only enable it in debug mode?
3. The documentation of Collider::convex_mesh (and all the related convex_mesh functions it calls indirectly) should mention the constraints the inputs should satisfy: the shape must be convex, manifold (no hole, topologically well-formed, no t-junctions), oriented with outward normals (i.e. the normal of each triangle must point toward the polyhedron’s exterior); and say that Collider::convex_hull should be preferred if the user doesn’t know if their input satisfy these constraints.

[Vrixyz]

Changing the input indeed fixes the behaviour 🎉 ; thanks for the precision! Keeping this open for the documentation/warning suggestions.