feat!: Body::TriMesh implementation

[Dmajster]

Resolves #41

I have made a new pull request for the Body::TriMesh implementation. This one is based off of Herons main branch. The feature works but still has some todo's left inside as I think they need to be discussed. I have compiled a list of those issues that need to be resolved before this can be reviewed & merged.

• [ ] 1. For the 2D feature ColliderBuilder::trimesh() expects the vertices to be of a format Vec<Vec2> instead of Vec<Vec3>. Here one solution would be that we can map the vertices from 3d to 2d by just stripping away the .z component before passing if off to the builder. The other solution that I think would be more appropriate is that we define seperate Body enums for 2d and 3d as there are multiple shapes that don't have a equivalant in more/less dimensions.
• [ ] 2. Implementing a test case for the trimesh. Here the question is how we want to do this. Are gonna store an example mesh and verify all the vertices and indices match up? Do we hardcode a shape in the test?
• [ ] 3. Implementing a debug visualization for the trimeshes.

[jcornaz]

Thank you very much @Dmajster,

Before going too far, I would like to mention that, thanks to @faassen, heron now features "convex-hull" shapes. That already makes possible the modelisation of complex (convex) collision shapes. If your shapes are convex, it is likely that ConvexHull is a simpler and more reliable solution. For example, convex-hull does not suffer from the "zero mass" and "zero angular intertia" problem.

Of course, TriMeshes and ConvexHull are not fully interchangable, and there is still a value in adding support for TriMesh. This is why I keep the issue and PR open, and I will be very happy to merge this when ready. I just want to make sure you are aware of the ConvexHull solution.

To answer your questions:

1. Use Vec3 and ignore the z component. That's what is done at the other places of the API, and that's what bevy does too. (Transform takes a translation defined with Vec3 and a rotation defined with Quat) even when using 2d.
2. We hard-code a simplistic example. Note that you don't need to test trivial stuff. In case of TriMesh you can probaly add a single simple test that make sure it doesn't crash when two trimeshes collide.

[jcornaz]

Hi,

I merged main into this branch and solved the conflicts. I also converted your unit test into an integration test where it is easier to make sure that there is no crash in case two trimeshes collide (I just spawn two entities at the same place, and call app.update()). The test is failing atm.

If you'r still working on this, you can rebase your branch onto my version of the feature/body-trimesh branch. (For an unknown reason, I couldn't directly push to the PR)

[MOZGIII]

I made this for my own needs, but you may find it interesting: https://github.com/MOZGIII/bevy_trimesh. It constructs the TriMesh data from the rendering mesh's geometry. Would be nice to have a way to construct a heron's [Body::TriMesh] directly from the underlying rapier's TriMesh type - or maybe, from a generic Raw(ColliderBuilder) would be even better?

UPD: submitted #160 as an implementation of a generic collision shape.

[jcornaz]

Note that this is now indirectly supported via custom collision shapes (#160)

I leave the PR open, because it can still be a nice addition to have first-class support for tri-meshes. But you can close it if you don't want to continue working on it.

[jcornaz]

Heron is now discontinued. Sorry this change never got merged.

Thank you for your interest in the project and your contributions.