Some concave shape collisions not registering

[Leezer]

Hello,

I'm hoping someone can shed some light on the problems that I've been having with subclasses of btConcaveShape, specifically pertaining to colliding them with btConvexShapes. Much like in the ConcavePhysicsDemo, I am trying to shoot convex collision shapes (btBoxShape) at a deforming concave shape (I have tried btBvhTriangleMeshShape as well as btGImpactMeshShape). The triangle mesh that I want to turn into a collision shape (the one I want to shoot cubes at) is a convex mesh to start. I want to be able to deform its vertices and have the its internal bounding data be updated accordingly.

First, I tried reading the mesh from an OBJ and using the parsed data to make a btBvhTriangleMeshShape. I used this shape to create a kinematic rigid body with a mass of 0 (because I didn't want it to fall or get pushed back by the shooting cubes). I then called partialRefitTree() every time I moved one of its vertices. This seemed to work ok - I could see that bounding volumes were being updated (i.e. stretching to accommodate the mesh's deformation). However, while some of the shooting cubes bounced off the btBvhTriangleMeshShape, others passed right through. I tried tweaking some of the values associated with the rigid body that I created from the btBvhTriangleMeshShape as well as the rigid bodies created for each shooting cube, including mass, setContactProcessingThreshold(), setCcdMotionThreshold(), and setCcdSweptSphereRadius(). For the last three, I turned these off and on, pushed their values way up and pulled them down. For mass, I set both rigid bodies' masses really low, really high, the same, different, etc. My results didn't change - I still had some cubes passing through the mesh shape and being caught inside it.

I read a lot of posts saying that an alternative way to represent a dynamic concave mesh is to use a btGImpactMeshShape. Thinking that it would give me better performance, I followed the steps for integrating GImpact into my code and created a kinematic rigid body using the btGImpactMeshShape. But, once I got things up and running, I still had some cubes bouncing off the btGImpactMeshShape and some passing through (since some were bouncing off, I figured that I was calling postUpdate() and updateBound() at the correct times).

Next, I thought that maybe there were stability issues with colliding a convex collision shape (the btBoxShape) with a concave one (btBvhTriangleMeshShape or btGImpactMeshShape). I read on the GImpact documentation that registering the btGImpactCollisionAlgorithm results in recognizing collisions between concave shapes and GImpact shapes - since a btGImpactShape is itself a concave shape, I thought that I could try shooting GImpact shapes at the larger GImpact shape. So, instead of shooting btBoxShapes, I shot out btGImpactMeshShapes (small triangular mesh cubes read from an OBJ). This produced disastrous results - most cubes flew right through the larger btGImpactMeshShape and others got stuck on its walls. I tried putting postUpdate() and updateBound() in different places. I again tweaked the rigid body values that I mentioned above. No success.

Frustrated, I ignored the capability of deforming vertices and used a btConvexHullShape to represent the triangle mesh that I want to shoot cubes at and switched my shooting cubes back to btBoxShapes. Collisions were excellent - no cubes passed through the shape.

This leaves me with 3 options:
Find a way to patch the btBvhTriangleMeshShape so that some cubes don't fly through it.
Find a way to recalculate the convex hull of the btConvexHullShape at each time step so that the shape can accommodate deforming vertices (I've tried this by creating a new btConvexHullShape and adding the deformed points to it at every time step - the simulation speed is, as would be expected, terrible. So this is not looking like a practical option).
Switch to ODE.

Please, if anybody has any suggestions at all, reply. Even just of ideas to try or other values to adjust.

Thank you,

--Leezer

[Leezer]

Okay, I've managed to fix the problem by doing the following:

- Restarting my computer.
- Using refitTree() instead of partialRefitTree() each time my btBvhTriangleMeshShape's vertices are deformed.

After I restarted, I noticed that the btBoxShapes were no longer clipping through a stationary btBvhTriangleMeshShape. I guess...some sort of cache got cleared? Not sure why it would suddenly work.

But as soon as I animated the btBvhTriangleMeshShape, I noticed btBoxShapes would shoot through it. So, by observing the changing bounding AABB (hitting "a" on the keyboard), I noticed that the bounding volume was expanding to accommodate the vertex deformations, but it wasn't completely enclosing the deformed btBvhTriangleMeshShape. I switched to the less efficient, but more robust refitTree() to make sure that all vertices were taken into account in the recalculation of the btBvhTriangleMeshShape's bounding info.