Physics Simulation Forum

I'm using bullet and gimpact (as you can see in some other post) but I really don't understand how to use the informations provided by the contact manifold. If I get 4 collision points for each pair, then I have to make a search and several tests using normals and points-on-a-triangle checks to see which vertices are colliding, so I have to make another collision detection algorithm by myself. Am I missing something?

It's a pity because the detection is amazingly robust and fast..

You don't need to search which vertices are valid. Each contact manifold provides the number of vertices that are valid.

Please see the CollisionInterfaceDemo how to iterate over contact points:


By the way, I moderated the title and location of your topic, please post in the Bullet section.
Thanks,
Erwin

I've been using that code you posted for the last 4 days, but it seems that I get only 4 vertices, so I still have to iterate through all the triangles to see which are colliding. Also, the four points I get do not correspond to any vertex of my mesh, but they seem to just lay on the triangles surface or edges.

I' sorry for the title, but I did a lot of searches in the forum, and I've seen you also always suggest to avoid trimesh collisions and to use the corresponding tetrahedra instead, but I don't see how to do this.

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.

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?

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:


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

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.

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.

Thanks for the reply.
Well, having a map would be the best choice, but knowing the triangles colliding would be almost as great. I try to use a callback and tell if I have any problem/success. I just have a point to clear out. 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.



Ok I understand. I hope the callback will satisfy my needings then.



GIMPACT 0.3? That sounds great!
Yes I have a deformable model based on tetrahedral meshes, and I'm using GIMPACT to detect collisions of its trimesh boundary. I'm using the GIMPACT present in the last release of Bullet, and it's seems that collisions work after the deformation, what I do is:

- create a kinematic rigid body having the trimesh as its shape
- move each vertex of the mesh each time step according to the computed solution of the deformable solver
- detect collisions
- input the velocities of the colliding points to the deformable solver

and the trimesh seems to realistic colliding with the environment, though often I don't retrive the right faces/vertices corresponding to the collision points (the reason why I opened this topic).



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.

For the impulse, I just need to know the velocity of the collision point and the id of the colliding face/vertex, then the deformable model takes care to compute the corresponding deformation and response force. I just want to avoid after a collision detection (which is basically a search) to search again for the triangles containing the contact points.

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

When using actual tetrahedra (in a btCompoundShape or in a future GIMPACT shape) would behave better using GJK, because there is some volume.

Note that the latest Bullet 2.62 uses GIMPACT 0.2, which has GJK enabled by default. The future GIMPACT 0.3 will have SAT enabled by default, but you can switch back to GJK. However, I expect you will get better quality when using tetrahedra, instead of a triangle mesh.

Hope this helps,
Erwin

I tried the callback:

bool CustomMaterialCombinerCallback(btManifoldPoint& cp,
const btCollisionObject* colObj0, int partId0, int index0,
const btCollisionObject* colObj1, int partId1, int index1)
{
if( colObj0->isKinematicObject() )
std::cout << "*************TRIANGLE ID: " << index0 << std::endl;
if( colObj1->isKinematicObject() )
std::cout << "*************TRIANGLE ID: " << index1 << std::endl;
return true;
}

and I get only -1 as output when a collision occurs. I've done as you said:

extern ContactAddedCallback gContactAddedCallback;
gContactAddedCallback = CustomMaterialCombinerCallback;
body->setCollisionFlags( body->getCollisionFlags() | btCollisionObject::CF_CUSTOM_MATERIAL_CALLBACK );

and also I don't get the collision points anymore in the manifolds. Am I doing something wrong?

Hey Topcomer!! Can I get your MSN ID or GTalk please?
I would like to discuss with you about how to make gimpact managing tetrahedra data.

It seems that you've already made a lot of stuff in deformable meshes, but there is a lack of collision detection for that.

Please send me an email to projectileman (a) yahoo com or my gmail account projectileman (a) gmail com .

thanks.

is the closest distance computed only for actually colliding pairs? That is, the normal points always inside the body?

Anyway, as I explain above, the callback does not work.

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

I think I did but I don't remember how and I am on holiday and don't have my external HDD with my old code with me, sorry.. probably it wasn't a neat solution

I guess you have done a lot of research on trimesh - trimesh collisions , Could you please advice on the best approach.
I do not want to go with convex decomposition of concave shapes , can i have an optimized trimesh-trimesh detection?
Is Bullet-GIMPACT good enough?
Thanks a lot in advance , would be a great help!