improved edge collision filtering needed

[ghost]

Issue described here,
http://stackoverflow.com/questions/26805651/find-a-way-of-fixing-wrong-collision-normals-in-edge-collisions/

And (crudely) illustrated here:

The main problem is as follows: the edge collision of adjacent triangle gets triggered even if surface collision of main triangle has happened, resulting in erroneous reaction. To reproduce just throw anything on a trimesh close enough to an edge, but not exactly on the edge. This happens because each triangle in BVH is processed separately.

A simple demonstration goes as follows: create a triangle mesh box centered at (0,0,0) and having dimensions e.g. 5, 1, 5. Exact tesselation shouldn't matter in this case.

Drop a radius 3 sphere from (-2,9,0).

Watch how it happily bounces of the edge even though it clearly falls on a flat surface (with a 0.5 distance from the edge!).

The current workaround I use is to manually filter the collision points in manifold; yet I think that the collisions should generate proper reactions out-of-the-box.

btAdjustInternalEdgeContacts didn't help here, BTW, since, AFAIK, it fixes the normal of the edge collisions nicely, but doesn't filter out the unneeded edge collisions at all.

NB it's certainly present in current Bullet 2 code, dunno about Bullet 3 though.

[erwincoumans]

The btAdjustInternalEdgeContacts should solve this issue. Perhaps the triangle winding is inconsistent?

If btAdjustInternalEdgeContacts doesn't help, it is best to simply create a reproduction case by modifying a Bullet demo, such as Demos/BasicDemo or Demos/InternalEdgeDemo to show the issue. Copy and paste the code in a gist, https://gist.github.com/, and share the link in this issue.
Thanks for the help,
Erwin

[ghost]

I've been able to patch together a repro case @ https://gist.github.com/vaxquis/2d3989ed3e3ce7326410 ; things that are worth noting about it:

• it apparently does matter what the order of magnitude of used forces is vs time step, fixed time step etc, AFAIK because of the contact threshold vs the actual distance from the edge when the collision happens; changing the stepSimulation parameters, as well as changing speed (gravity), as well as changing tri dimensions can result with either proper behaviour or different anomalies,
• it can be reproduced with various settings (i.e. timesteps, triangles) but the exact placement of tri edges causing the issues is a bit different for each timestep/speed values,
• btAdjustInternalEdgeContacts has an impact on the overall simulation quality in some of the cases, but, as can be shown in this example, doesn't help this particular issue, and sometimes even makes it worse,
• the default setting of filtering for the repro case is "disabled", press ` to reset the simulation with filtering enabled. the behaviour is then (and only then) consistent with what happens at "regular" speeds/timesteps,
• I haven't noticed any visible difference when the tri winding is changed.

also, setCameraDistance(8.) is about right for this example.

My gut tells me this shows an underlying numerical problem. One way or another, removing extraneous collisions makes it behave as expected. Making timestep shorter or reducing the velocities, however, solves this issue only sometimes, and still can be screwed up by a "nasty" (small or thin) triangle.

Anyway, using algo such as

// after all collision points for a body hitting trimesh has been created
    for each ( collisionPoint in Manifold(body) )
        if ( collisionPoint.isOnTriSurface && !collisionPoint.isOnTriEdge )
            for each ( collisionPoint2 != collisionPoint in Manifold )
                if ( collisionPoint2.isOnTriEdge && collisionPoint2.triangle.isAdjacentTo( collisionPoint.triangle ) )
                    collisionPoint2.removeFromManifold

works OK here IMO, at least during my tests.

Edit: just checked today that removing contacts based on their distance also works wonders here, although that's way too crude/context specific of a fix to be used in production code IMO.

[JeffProgrammer]

@erwincoumans I've had this similar issue happen with PhysX (so its just not bullet doing this). In order to get around it for my sphere/trianglemesh geometry, I just iterated over all of the contact points before processing them and told PhysX to ignore points that were "bad". Is that possible to do with bullet, as I haven't found a way to iterate over the manifold and remove contact points before processing them?