btBvhTriangleMeshShape sucks bodies onto other side

[MajorNr01]

I have a static (0 mass) rigid body with a btBvhTriangleMeshShape as collision shape, the whole thing representing a height-map style terrain. There are different reasons for why im not using the terrain shape and I believe that this is irrelevant to the problem.

Right now im just generating a heightmap with heights proportional to their distance to the origin sqared. At some point I noticed that my rigid bodies (boxes with btBoxShape) occasionally disappeared, somewhat "tunnelling" through the triangle mesh. No high speeds, I even turned down my timescale once, still happening.

After some experimentation I found out that the boxes are actually being "sucked" down onto the other side, as if the triangles in the mesh have some preferred side where bodies are moved to, regardless of where they came from (perhaps I missed a feature here?).

But it does not stop there. As it turns out, this phenomenon happens only with rather steep triangles (relative to gravity I guess) and also only on about every second triangle in the mesh (very regular pattern). Additionally it only happens in areas of the coordinate system, where x and y have the same sign (x > 0 & y > 0 or x < 0 & y < 0). The parts of the mesh that lie in +x & -y or -x & +y respond just fine, the boxes collide normally.

Also, I made sure that all the triangles have the same vertex winding order. Im drawing the exact same data with backface culling on and all the triangles are visible on the same side. Still, the bvh triangle mesh shape generally does not seem to care about triangle sides anyway, except in the cases as stated above. Then all bodies colliding with the triangles are moved to one preferred side upon collision.

I would call bug here, because the behaviour seems incomprehensibly nonsensical to me, but perhaps I just missed some normal functionality of btBvhTriangleMeshShape.

[Pacha]

I have the same issue with my custom shape. Using a ghost object and a kcc.

The bad collisions happen on the edges, use a debug drawer to see the edges of your shape and you will see that the bad collisions happen there. If you look it up in the forums, there are ways to remove the unwanted edges. None of them worked for me though. It might not be the same bug/issue, but you might try that.

[MajorNr01]

I have the same issue with my custom shape. Using a ghost object and a kcc.

The bad collisions happen on the edges, use a debug drawer to see the edges of your shape and you will see that the bad collisions happen there. If you look it up in the forums, there are ways to remove the unwanted edges. None of them worked for me though. It might not be the same bug/issue, but you might try that.

Thank you for your reply, but I'm not sure it's about the edges. I can have giant triangles where the edges are meters away and boxes colliding with them are moved through in this weird way that I'm still struggling to describe...

[Flix]

As I 've explained in another thread, I don't have a big experience with Bullet's btKinematicCharacter controllers, and the btBvhTriangleMeshShapes I've used so far seem to work well enough for my needs.

However, I'm answerng here just to say that it's possible to convert a btStridingMeshInterface to a series of tetrahedeons, through <BulletCollision/Gimpact/btCompoundFromGimpact.h>. You may try this approach in case of problems (I suggest unwrapping the resulting compound into many static rigid bodies and using m_collisionWorld->forceUpdateAABBs(false) for better performance).

Of course much performance is lost in the process (even if using -lOpenGLSupport without frustum culling slows down the rendering phase by 4 times now: 4 triangles drawn instead of one), but the result can improve collision detection considerably.

P.S. I'm aware that this is more a hack than a solution: fixing the character controller (if that is to blame), or having a btBvhTriangleMeshShape with one-way front-face collision repulsion (in case of well ordered meshes) should be much better if you're experiencing problems with that particular shape.

P.S.2. I suggest removing double vertices and degenerate triangles in case of object sinking too.

[MajorNr01]

As I 've explained in another thread, I don't have a big experience with Bullet's btKinematicCharacter controllers, and the btBvhTriangleMeshShapes I've used so far seem to work well enough for my needs.

However, I'm answerng here just to say that it's possible to convert a btStridingMeshInterface to a series of tetrahedeons, through <BulletCollision/Gimpact/btCompoundFromGimpact.h>. You may try this approach in case of problems (I suggest unwrapping the resulting compound into many static rigid bodies and using m_collisionWorld->forceUpdateAABBs(false) for better performance).

Of course much performance is lost in the process (even if using -lOpenGLSupport without frustum culling slows down the rendering phase by 4 times now: 4 triangles drawn instead of one), but the result can improve collision detection considerably.

P.S. I'm aware that this is more a hack than a solution: fixing the character controller (if that is to blame), or having a btBvhTriangleMeshShape with one-way front-face collision repulsion (in case of well ordered meshes) should be much better if you're experiencing problems with that particular shape.

P.S.2. I suggest removing double vertices and degenerate triangles in case of object sinking too.

Would you mind helping me with the one-way front-face collision thing? I've been up and down through the class reference of btBvhTriangleMeshShape and I haven't encountered such a thing yet.

And in general, is there any kind of preference to the sides of the triangles in the shape? The way the shape handled for me up until now, I got the impression that triangle sides and therefore vertex order is completely irrelevant to the shape.

Which is still the case with my problem here! No matter how the vertices are ordered for each triangle, there is still this one same side to certain triangles where colliding bodies get moved to the other side...

I would really appreciate ANY help with this because it seems like there is absolutely nothing I can do about it and my project is paralyzed until I can use btBvhTriangleMeshShape again!

[Wingly]

From your description this seems to be the same bug that me and a friend encountered when we started working with bullet. Rigid bodies getting sucked through the terrain (which was a btBvhTriangleMesh) at specific triangles.
This bug seems to be related to bullet 2.82 since after we changed to 2.81 everything worked fine. So if you are using 2.82 and don't mind changing to 2.81, that might be a "solution".

Ps. English isn't my first language so sorry for any grammatical/spelling errors = P

[Flix]

Would you mind helping me with the one-way front-face collision thing? I've been up and down through the class reference of btBvhTriangleMeshShape and I haven't encountered such a thing yet.

That's because it's not present.

And in general, is there any kind of preference to the sides of the triangles in the shape? The way the shape handled for me up until now, I got the impression that triangle sides and therefore vertex order is completely irrelevant to the shape.

That's what I've always thought the btBvhTriangleMeshShape is designed: no difference between front and back polygons (although it's probably possible to cull back-faces while raycasting on triangles due to a recent Bullet addition: but that does not involve the collision detection algorithm).

Which is still the case with my problem here! No matter how the vertices are ordered for each triangle, there is still this one same side to certain triangles where colliding bodies get moved to the other side...

That might be a bug (as Wingly reported), but have you checked the InternalEdge Bullet Demo?

I would really appreciate ANY help with this because it seems like there is absolutely nothing I can do about it and my project is paralyzed until I can use btBvhTriangleMeshShape again!

Have you tried the "conversion" process I've described above?

[SilentSpartan]

This bug seems to be related to bullet 2.82 since after we changed to 2.81 everything worked fine. So if you are using 2.82 and don't mind changing to 2.81, that might be a "solution".

I have similar problem.
It seems that the root of problem in btGjkPairDetector.cpp
In 2.82 workaround for sticky convex collisions was added.
I tried to switch off that fix (m_fixContactNormalDirection(0) in both constructor of btGjkPairDetector) and it helped me.
I think it is a bug.

[Flix]

@MajorNr01 & Pacha:
I've managed to reproduce a collision problem (for the first time) between a btKinematicCharacterController and a btBvhTriangleMeshShape.
I'm not sure this is what you've experienced; so please watch the video below:
VIDEO: COLLISION PROBLEM AND SOLUTION:

Problem description and solution:
I've found out that some problems people have with btKinematicCharacterControllers penetrating through a static btBvhTriangleMeshShape like background can be caused simply by the fact that when the character starts inside the AABB of the btBvhTriangleMeshShape,
and:

Code: Select all

m_dynamicsWorld->getBroadphase()->getOverlappingPairCache()->cleanProxyFromPairs(m_character->getGhostObject()->getBroadphaseHandle(),getDynamicsWorld()->getDispatcher());
//or
m_character->reset (m_dynamicsWorld);	// that internally calls the method above

are called before starting the program (and that's what happens in the Bullet's CharacterDemo, when clientResetScene() is called at the end of initPhysics(): that Demo works fine because it does not use a single btBvhTriangleMeshShape as a background) then the static shape does not work correctly inside btKinematicCharacterController::recoverFromPenetration(...).

To solve the issue it's possible to:
a) make the character start outside the btBvhTriangleMeshShape's aabb.
or:
b) simply get rid of those calls inside clientResetScene().

This is what I discovered yesterday, but I'm not sure if it's a definitive solution to the problem or not...
if not maybe by overriding btKinematicCharacterController::preStep() and reimplementing btKinematicCharacterController::recoverFromPenetration() it's possible to resolve collisions with concave shapes faster.

P.S. This trick works not only for btBvhTriangleMeshShape, but for all the shapes with a big AABB (e.g. btHeightFieldShape).

[Edit:] I've recently discovered that it's only the call to: m_character->reset (m_dynamicsWorld); that must be removed, cleanProxyFromPairs(...) alone seems to work.