Provide solution to filter out unwanted collisions with internal edges of a triangle mesh. about bullet

[GoogleCodeExporter]

We need some good reproduction cases. Will ask for them on the forum.

Original comment by erwin.coumans on 31 Mar 2008 at 4:41

[GoogleCodeExporter]

I attached at

http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=9&t=1814&st=0&sk=t&sd
=a&start=30

a reproduction case called "sphereDrive.zip".

Original comment by [email protected] on 26 May 2008 at 8:39

[GoogleCodeExporter]

Another forum issue (probably) relating to this issue:
http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=9&t=2842

Original comment by [email protected] on 18 Nov 2008 at 7:24

[GoogleCodeExporter]

Rounded shapes, such as capsules and shapes with a larger collision margin 
don't 
suffer from this problem.

Try using the kinematic character controller with a capsule, and use a shrinked 
shape 
for its internal convex cast (for stair climbing/sliding). Can you double check 
the 
btKinematicCharacterController?

Original comment by erwin.coumans on 18 Nov 2008 at 8:12

[GoogleCodeExporter]

 erwin.coumans: "shapes with a larger collision margin don't 
suffer from this problem."

What is considered "a larger collision margin" ?

Original comment by [email protected] on 19 Nov 2008 at 10:01

[GoogleCodeExporter]

'larger collision margin' can be 'a collision margin at least 5% of the minimum 
collision shape dimensions (in any direction).'

A sphere and capsule consists of 100% collision margin.

I'll mark this issue, so we can look at it again before Bullet 2.74 release.

Original comment by erwin.coumans on 19 Nov 2008 at 4:00

• Added labels: Milestone-2.74

[GoogleCodeExporter]

Here is a very boiled down repro case

http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=9&t=3052&start=15

Original comment by [email protected] on 22 Jan 2009 at 12:47

[GoogleCodeExporter]

The script below fixes the problem, reported by sparkprime here:
http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=9&t=3052&start=15

Problems occur, however, when the triangle normal is used during collisions 
with concave edges. So additional 
logic needs to be added (for example by instrumenting triangles that only share 
'convex edges').

void contact_added_callback_obj (btManifoldPoint& cp,
                                 const btCollisionObject* colObj,
                                 int partId, int index)
{
        (void) partId;
        (void) index;
        const btCollisionShape *shape = colObj->getCollisionShape();

        if (shape->getShapeType() != TRIANGLE_SHAPE_PROXYTYPE) return;
        const btTriangleShape *tshape =
               static_cast<const btTriangleShape*>(colObj->getCollisionShape());


        const btCollisionShape *parent = colObj->getRootCollisionShape();
        if (parent == NULL) return;
        if (parent->getShapeType() != TRIANGLE_MESH_SHAPE_PROXYTYPE) return;

        btTransform orient = colObj->getWorldTransform();
        orient.setOrigin( btVector3(0.0f,0.0f,0.0f ) );

        btVector3 v1 = tshape->m_vertices1[0];
        btVector3 v2 = tshape->m_vertices1[1];
        btVector3 v3 = tshape->m_vertices1[2];

        btVector3 normal = (v2-v1).cross(v3-v1);

        normal = orient * normal;
        normal.normalize();

        btScalar dot = normal.dot(cp.m_normalWorldOnB);
        btScalar magnitude = cp.m_normalWorldOnB.length();
        normal *= dot > 0 ? magnitude : -magnitude;

        cp.m_normalWorldOnB = normal;
}

bool contact_added_callback (btManifoldPoint& cp,
                             const btCollisionObject* colObj0,
                             int partId0, int index0,
                             const btCollisionObject* colObj1,
                             int partId1, int index1)
{
        contact_added_callback_obj(cp, colObj0, partId0, index0);
        contact_added_callback_obj(cp, colObj1, partId1, index1);
        //std::cout << to_ogre(cp.m_normalWorldOnB) << std::endl;
        return true;
}

Original comment by erwin.coumans on 18 Feb 2009 at 9:43

• Added labels: Milestone-2.75
• Removed labels: Milestone-2.74

[GoogleCodeExporter]

As outlined in the forum, the solution is to gather information about the angle
between the triangles that share that edge. If the angle is small the above 
callback
can be used. Otherwise normal processing is done. Edge/Triangle connectivity
information is needed to gather that information.

When implementing the above fix it will solve the problem only a single body 
level. 
I doesn't solve the problem when hitting an edge that is 'visually' shared 
between
two bodies. Any idea how that could be done as well?

Original comment by [email protected] on 7 Apr 2009 at 8:37

[GoogleCodeExporter]

When enabling CCD collision then the problem gets even worse as now much more 
edge
collision are detected. 

Original comment by [email protected] on 9 Apr 2009 at 1:21

[GoogleCodeExporter]

Original comment by erwin.coumans on 6 May 2009 at 7:17

• Added labels: Milestone-2.76
• Removed labels: Milestone-2.75

[GoogleCodeExporter]

In most cases a workaround is sufficient:

For the convexObject sliding along the triangle mesh:

1) use convexObject->setContactProcessingThreshold(0.); 

2) Use above contact callback to correct collision normals.

Better improvements to the collision normal (and distance) can be made if 
connectivity information is present.

Original comment by erwin.coumans on 16 Nov 2009 at 8:24

[GoogleCodeExporter]

Using convexObject->setContactProcessingThreshold(0.) didn't improved the 
behavior
for me noticeable. 

The given callback does only work on convex edges and otherwise intersections 
are
caused. So the callback is only useable on convex meshes, but those don't have 
the
'stuck' problem anyway.

So connectivity info (like also Havok is using) seems to be the only way to fix 
it.

Original comment by [email protected] on 17 Nov 2009 at 12:52

[GoogleCodeExporter]

I'm working on a basic implementation that calculates connectivity, angles 
between 
connected triangles sharing an edge (edge angles), and a contact callback that 
only 
adjusts the contact normal/depth dependent on this additional information.

A first version should be available in Bullet 2.76, later this month (January 
2010)

Original comment by erwin.coumans on 8 Jan 2010 at 5:57

[GoogleCodeExporter]

A first version of btInternalEdgeUtility has been added (in 
Bullet/src/BulletCollision/CollisionDispatch). 

During initialization, assign a triangleInfoMap as user property to the 
triangle 
mesh. You can do this manually, or using btGenerateInternalEdgeInfo:


btBvhTriangleMeshShape*trimeshShape=...;
btTriangleInfoMap* triangleInfoMap = new btTriangleInfoMap();
btGenerateInternalEdgeInfo(trimeshShape, triangleInfoMap);

Then at run-time, during a contact callback, call btAdjustInternalEdgeContacts, 
make 
sure colObj0 has the triangle mesh shape.

static bool CustomMaterialCombinerCallback(btManifoldPoint& cp, const 
btCollisionObject* colObj0,int partId0,int index0,const btCollisionObject* 
colObj1,int partId1,int index1)
{
    if (enable)
    {
        btAdjustInternalEdgeContacts(cp,colObj1,colObj0, partId1,index1);
    }
}

See attached modified Bullet/Demos/ConcaveDemo as an example. This will be 
added to 
the Bullet 2.76.

Feedback is welcome.

Original comment by erwin.coumans on 16 Jan 2010 at 2:03

Attachments:

• ConcavePhysicsDemo.cpp
• ConcaveDemo.h
• main.cpp

[GoogleCodeExporter]

See commit http://code.google.com/p/bullet/source/detail?r=1877

Original comment by erwin.coumans on 16 Jan 2010 at 2:04

[GoogleCodeExporter]

I consider this issue fixed with the new btInternalEdgeUtility 
http://code.google.com/p/bullet/source/detail?r=1877

If there are remaining issues with btInternalEdgeUtility, please let us know 
soon, otherwise we close this issue 
(and you can open a new issue for issues with btInternalEdgeUtility.

Original comment by erwin.coumans on 19 Jan 2010 at 12:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The approach of double sided triangle doesn't work well penetration directions 
are 
conflicting. We need to simplify the btInternalEdgeUtility and only deal with 
single 
sided triangles.

Original comment by erwin.coumans on 21 Jan 2010 at 9:15

• Changed state: Started

[GoogleCodeExporter]

Attached is some reproduction case, starting in deep penetration.

Original comment by erwin.coumans on 21 Jan 2010 at 4:41

Attachments:

• VehicleDemo.zip

[GoogleCodeExporter]

The btInternalEdgeUtility seems to do its job, so let's close the issue.

You can give some feedback here:
http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=4603&start=15

Original comment by erwin.coumans on 2 Feb 2010 at 5:53

• Changed state: Fixed

[GoogleCodeExporter]

Hi this works perfectly but doesn't seem to work with the parallel dispatcher, 
any ideas? thanks.

Original comment by [email protected] on 26 Jul 2010 at 5:44