native btAdjustInternalEdgeContacts implementation

[ghost]

Currently using btAdjustInternalEdgeContacts (to allow smooth movement of objects vs triangle meshes) required to hook it to ContactListener manually, delegating the call from Java (app) to native (discrete world step) to Java (onContactAdded) to native (btAdjustInternalEdgeContacts) again. Since it's a possible efficiency bottleneck and it increases the complexity of the code required to handle such cases (triMesh collisions), the proposed solution would be to e.g. add a boolean switch to ContactListener, with btAdjustInternalEdgeContacts called automagically when it's true on every entry to onContactAdded when one of the surfaces is a triangle mesh.

Note: based on current Bullet implementation (http://bulletphysics.org/Bullet/BulletFull/btInternalEdgeUtility_8cpp_source.html & http://bullet.googlecode.com/svn/trunk/Demos/InternalEdgeDemo/InternalEdgeDemo.cpp) I'd like to also note that btAdjustInternalEdgeContacts does a couple of not-so-trivial checks (i.e. if the obj0 is the tri mesh and if it has all the necessary data already set in triangleInfoMapPtr) before it actually processes the edge contacts, returning gracefully if the conditions are not met - as such, we don't have to worry about it ourselves, simple

if ( adjustInternalEdgeContacts ) {
    Collision.btAdjustInternalEdgeContacts(cp,colObj1Wrap,colObj0Wrap, partId1,index1);
}

before delegating the call to user's onContactAdded implementation coupled with setter for adjustInternalEdgeContacts in ContactListener is IMO the solution here.

[xoppa]

Would it be possible for you to provide a simple test showing the difference? Preferable based on the tests code base so we can include them along with the tests. See https://github.com/libgdx/libgdx/tree/master/tests/gdx-tests/src/com/badlogic/gdx/tests/bullet.

[ghost]

After testing btAdjustInternalEdgeContacts quite thoroughly, I can only say it doesn't solve the triangle mesh collision problems at all. I've asked a question on SO (http://stackoverflow.com/questions/26805651/find-a-way-of-fixing-wrong-collision-normals) looking for other people with this problem or possible solutions, but it seems Bullet ain't that popular... The code for tests (based on Your code, Xoppa), is here:

https://github.com/vaxquis/bullet-test/blob/master/core/src/com/badlogic/gdx/tests/bullet/BulletTezt.java

I've been testing many different solutions by now, and it seems that delving deeper into Bullet internals is required for this problem to be solved in any satisfactory way. I'm closing this issue, as it's strictly Bullet-dependent, not libGDX dependent AFAIK. Still, any thoughts/input on the subject would be very appreciated.

Further reading/reference:

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

[ghost]

A final note on this issue, for reference for future generations: a partial workaround (as noted in one of the forum discussions) was to reduce the fixed timestep; the default one fails for triangle meshes vs any object moving with reasonable speed. For "regular speeds", timestep of max 1/300 is needed, for "high speeds" 1/600 or even less, YMMV. Since it increases the CPU load a lot and only reduces the problem, in many situations not solving it at all, I'm still looking for better solution, i.e. one that would properly process triangle meshes with the same degree of accuracy as e.g. box primitives.