Real-Time Physics Simulation Forum

projectileman wrote:GIMPACT 0.2 and GIMPACT 0.3 use the btPersistentManifold and btManifoldResult for reducing the number of collision contacts, so you'll get a very little number of contact points (no more than four). This kind of result is very useful for physics collisions

But your request of more points its more a feature request for GIMPACT, so I'll be thinking on supporting these special queries such finding the total number of collided triangles and so on.

We can modify btGImpactCollisionAlgorithm class for managing more specialized queries.

topcomer wrote: Yes that would be great. Since I move all the vertices by myself using the solution of an external solver, I definitely need to know which vertices are colliding and I don't know how to use the 4 contact points to get such an information. In which sense is it useful for physics collisions?

bool CustomMaterialCombinerCallback(btManifoldPoint& cp,        const btCollisionObject* colObj0,int partId0,int index0,const btCollisionObject* colObj1,int partId1,int index1)
{
//here you have access to the triangle info,using partId and index for each object
}
extern ContactAddedCallback             gContactAddedCallback;


int main(int argc,char** argv)
{
        gContactAddedCallback = CustomMaterialCombinerCallback;

//...

    //enable custom material callback
        staticBody->setCollisionFlags(staticBody->getCollisionFlags()  | btCollisionObject::CF_CUSTOM_MATERIAL_CALLBACK);

}

Erwin Coumans wrote: Actually, it seems you are not just asking for more contact points, you want a mapping between vertices of the mesh, and contact points.

When a concave trimesh versus trimesh is colliding/overlapping, ultimately this ends up in multiple triangle versus triangle tests. This gives one or more contact points, with a penetration depth and normal. Those contact points are not necessary related to vertices: imaging a big triangle, with a smaller triangle overlapping in the middle: The 'closest points' or more accurate, the points that define the penetration depth (or minimum translational distance) can be determined by a face of one triangle, and an edge of another triangle.

You can however retrieve the partId and triangleIndex for each of the contact points, at the time when they are added. You can use a callback, see the 'CustomMaterialCombinerCallback' in ConcaveDemo.cpp how to do this:

Erwin Coumans wrote: We could store the partId/index for the triangle in the contact point. However, then we would also need to store a pointer to the childshape, including an accumulated transform for this childshape: you can store multiple trianglemeshes inside a compound shape, so we would need to identify which childshape is used.

Hope this helps,
Erwin

projectileman wrote: Are you trying to make deformable bodies?? great!!
Let me know about that please, I want to test if the last version of GIMPACT (0.3) can support deformations.

projectileman wrote: At this moment I recommend using GJK for triangle collisions in deformable bodies, because the original tri-collision from GIMPACT only takes the face normals as separation axes, without considering edge-edge directions. Just uncomment the BULLET_TRIANGLE_COLLISION define for enabling GJK, in the btGImpactCollisionAlgorithm.h file.

Also I've considered tetrahedrization as a new feature on GIMPACT, which would be more well suited for deformables.

About the collision info, you must determine which triangle faces are collided and then apply the respective forces-impules to the linked vertices acording with the collision impulse-point, it's a though.

topcomer wrote: For each pair of contact points, how many normals I get? In the case this is just one, it can't be normal to both the triangle faces, so it's just the direction of the line connecting the two points? I hope the question is clear.

What would it be the difference between the separation axes and GJK in pratical terms? Do they both give a collision point + a normal? This might be important because I could just take care of getting the callback suggested by Erwin without having to implement different versions for different collision algorithms, and try which one works better.

Erwin Coumans wrote:

topcomer wrote: For each pair of contact points, how many normals I get? In the case this is just one, it can't be normal to both the triangle faces, so it's just the direction of the line connecting the two points? I hope the question is clear.

A pair of 'closest points' has one normal that points from point in object B towards a point in object A.

rasheedibrah wrote:I know this is coming a bit late (4 years late haha), but did you ever get it working. That is, get the program to output the colliding vertices? If so, care to share the solution?

Thanks