Find a way to fix incorrect collision normals in edge collisions

Question

The main problem is that Bullet 2 (2.82, to be specific - and perhaps Bullet 3 also has not tested it yet) handles edge collisions, generating distorted reaction normals.

Test Case 1: A small btBoxShape , located (0.9.0), vertically aligned, falls onto another box (also made from btBoxShape ), coordinated. Normal is calculated correctly, collision occurs only in the Y (vertical) axis. The box bounces slightly on the OY axis and stays around it.

Test case 2: a small box located (0.9.0), vertically aligned (the same) falls on another side face (this time made from btBvhTriangleMeshShape made from 2 coplanar triangles), also encoded. Normal is not calculated properly, collision occurs in all axes. The box bounces to the side, sometimes (depending on the specific collision coordinates) it is very noticeable.

Even hard coding of normal and recalculation of collision points based on it (see below) does not help.

 //newNormal was set to hard-coded value of (0,-1,0) before cp.m_normalWorldOnB = colObj0Wrap -> getWorldTransform().getBasis() * newNormal; cp.m_positionWorldOnB = cp.m_positionWorldOnA - cp.m_normalWorldOnB * cp.m_distance1; cp.m_localPointB = colObj0Wrap -> getWorldTransform().invXform( cp.m_positionWorldOnB 

NB using btAdjustInternalEdgeContacts does not help in any visible form, despite the correct configuration of tri info and the code check is done in order. Despite the fact that it works and gives some slight improvement in the reliability of modeling (albeit at a rather high cost of the processor), it still does not solve this problem.

The question arises: how to fix the case 2 behavior to match case 1. Any advice on how to avoid this situation (welcomes the kludges code), or why it doesn't work the way it should be welcomed.

Further link:

https://github.com/bulletphysics/bullet3/issues/92

http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=8113

https://bullet.googlecode.com/files/GDC10_Coumans_Erwin_Contact.pdf

https://code.google.com/p/bullet/issues/detail?id=27

http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=4603

Answer 1

The problem arose because there were several collisions between two objects - the same thing happens with the ↔ tri collision ball. A collision defect not only detects a collision of three surfaces, ending the iteration for the surface triangle (as expected), but also it continues to move along the BVH (as well as the expected view), which leads to another collision with the neighboring edge of the triangle. This can be reproduced in many ways , eg. throwing an object near the edge of the trim (but still on the inside of the grid!), throwing an object near the inner border (border), but asymmetrically (a symmetrical drop will cause the edge to cancel forces). The object will fly to the side (sometimes wildly), even if the surface is perfectly flat at this point.

The only universal solution that came to my mind and does not require a thorough rewrite of the Bullet 2 code is filtering the oncoming object collector, for example. in gContactStartedCallback , detecting all surface collisions and removing all edge collisions for all edges adjacent to that surface. Observing numContacts >= 2 on these trimesh varieties is usually the way to go; this should not happen too often, and checking a pair of points on the collector is not processor intensity.

Removing contacts based on their distance also works wonders here, although this method is too coarse / context specific to fix, which will be used in the production IMO code. I'm still looking for a simpler and more efficient solution.

In addition, a partial workaround (as noted in one of the discussions on the forum) was to change the timestep values; by default, a crash occurs for triangular grids against any object moving at a reasonable speed. For "normal speeds" a fixed time interval of a maximum of 1/300 for "high speeds" of 1/600 or even less, YMMV is required. Please note that it significantly increases the CPU load and only reduces the problem, in many situations, without solving it at all.

A related issue was posted in the Tracker section here .