Make shapes more extensible / Add support for user-defined shapes

[dimforge]

Make shapes more extensible / Add support for user-defined shapes

[sebcrozet]

Using type parameters is not an option because that would result in:

• The Collider having a type parameter.
• The ColliderSet having a type parameter.
• The PhysicsPipeline and QueryPipeline having a type parameter.
• Same for a lot of other structs (BroadPhase, NarrowPhase, etc.)

So that means most of the Rapier structs will have a type parameters which is one thing you want to avoid because:

• It can slow down compilation times of the end-user crate.
• It prevents the end-user from enabling compiler optimizations for Rapier while keeping optimizations disabled for their own crate. And since Rapier is about 100 times slower in debug mode, this would make the end-user app unusable in debug mode.

[sebcrozet]

Support for user-defined shapes will be possible in the next version of Rapier, to be released at the end of January 2021. However, for this release, serialization/deserialization will only work for shapes supported by Rapier by default.

I don't think there is any other options than using a Box trait-object (but I might be wrong). In that case, we need to see what we can do for serializing them

Have a look at https://github.com/dtolnay/typetag

I don't think using typetag is a great solution because it has limited platform support. See the README of one of its dependencies, inventory.

[sebcrozet]

Hi! Custom shapes is something I'd like to allow at some point but some big changes need to happen before that:

1. We need to move all the collision-detection stuffs out of Rapier. I've been working on it lately but it will probably not be completed before 2 or 3 months (because this requires some significant modifications of the way ncollide works).
2. I don't think there is any other options than using a Box<Shape> trait-object (but I might be wrong). In that case, we need to see what we can do for serializing them: either we #[serde(skip)] custom shapes altogether, or we find another solution, based on erased_serde perhaps?
3. The DefaultContactDispatcher should no longer be hard-coded into the narrow-phase. But that should be dealt with once we complete the modification for 1.

[robert-hrusecky]

Hi! Glad to hear this is part of the plan!

Another option instead of Box<dyn Shape> would be to use type parameters. I'm envisioning usage that would look like this:

use rapier2d::geometry::collider::{Shape, DefaultShape};
#[derive(Shape)] // macro that handles all the boilerplate dispatching code
pub enum MyShape {
    Default(DefaultShape),
    MyShapeA(MyShapeA),
    MyShapeB(MyShapeB),
}

Here the current Shape enum is renamed to DefaultShape, and Shape is now a trait. DefaultShape, MyShapeA, and MyShapeB, and MyShape all implement Shape. Rapier types can then be parameterized by MyShape in user code. This should make serialization a bit easier. It would also open up the option of excluding some of the default shapes if they are never used in the simulation.

[robert-hrusecky]

I have been convinced!

erased_serde seems like a viable solution.

[iMplode-nZ]

Using dyn pointers feels like it would lose a bunch of efficiency...

[robert-hrusecky]

I don't think it will be that bad, because the use of trait objects can be reserved just for user-defined shapes. For example:

pub enum Shape {
    /// A ball shape.
    Ball(Ball),
    /// A convex polygon shape.
    Polygon(Polygon),
    /// A cuboid shape.
    Cuboid(Cuboid),
    /// A capsule shape.
    Capsule(Capsule),
    /// A triangle shape.
    Triangle(Triangle),
    /// A triangle mesh shape.
    Trimesh(Trimesh),
    /// A heightfield shape.
    HeightField(HeightField),
    /// A user-defined shape.
    Custom(Box<dyn CustomShape>),
}

[iMplode-nZ]

That seems fine as long as there is a low amount of custom shapes. I guess the user could fork if they really needed a custom shape...

Also it seems like you are not using the enum_dispatch crate, which could be very helpful...

[chinedufn]

I don't think there is any other options than using a Box trait-object (but I might be wrong). In that case, we need to see what we can do for serializing them

Have a look at https://github.com/dtolnay/typetag

[iMplode-nZ]

I wonder if it would be possible to completely offload the collisions from the physics, such that people could have a custom collider that doesn't use the support function things. For my game, I'm trying to have everything be a voxel, which leads to very simple collision code without using the support function.

[sebcrozet]

@iMplode-nZ When user-defined shapes will be supported, it will be possible to provide your own collision-detection algorithms for your own shape types. So you could have some kind of VoxelSet shape with a custom collision-detection algorithm.

[iMplode-nZ]

I don't see how you could implement this... what would happen if a VoxelSet collides with a TriangleMesh?
(Also I would really prefer if the implementation doesn't include dynamic pointers or boxing at all)
I'm planning to offload all the collision work to the GPU, which is asynchronous, and I don't really see doing this with the CPU manually calling functions for whether two objects collide in the standard manner.

[sebcrozet]

@iMplode-nZ It will be your responsibility to provide the collision-detection algorithms between your user-defined shape and all the other shapes. For each pair of colliders, we do a dynamic dispatch to select the right collision-detection algorithm for a given pair of shapes. Right now this is done by the hard-coded DefaultContactDispatcher but once we support user-defined shapes, this dispatcher can be user-defined too.

Because there is a dynamic dispatch to select the algorithm, this involve trait-objects. But the collision-detection algorithm itself is free to downcast this trait-object to the concrete shape type before computing the contacts.