not much luck, hey? It's very hard to get a clean set of collision points from just intersecting triangles.

To be accurate, you'd need to determine colliding features for each convex sections of the meshes. So you need to post-process the list of triangles, and find out what would be the best collision points, given the connectivity information of ther triangles. Else, you'g get an awful lot of spurious collision points.

You can try that as a first measure. Take the pairs of inteersecting triangles, and treat them as if they were not part of any meshes, as if you were trying to collide a triangle soup. Finding the collision point for each pair is finding the MTD (Minimum Translation Distance) between the two. If you have a vertex piercing the other triangle, then the collisoin point would be the vertex, and the projection of that vertex on the other triangle's plane. With an edge-edge collision, then it's just the two closest points on each edges. But as you say, that does not make much sense when you take the mesh in it's globality.

If your models are closed, you can try to find the closed contours of intersection, and use that to define the collision points and surfaces. The contours should form a edge loop around where the polygons intersect. A bit like a polygon. From there, I don't know. Maybe take each contours as a single collision, and try to generate one collision point, in the middle of the countour, with the normal being a sort of mean normal of the contour.

Imagine two boxes resting on a table. The countour would be like the face of a box, or a 2D flat polygon. The point of intersection would be centre of the polygon, the normal going up. the depth would be the intersection of that ray (point of collison, normal) with one of the polygon (the table top).

I'd like to hear other solutions though.

to be frank, what I'd rather do in case of two complex meshes, is to simplify them with spheres, posibly a sphere tree, and use that as for collision detection directly. Not the most accurate, but certaionly more accurate than the triangle-triangle method, and faster.

That, or split you meshes into convex parts, and do a voronoi clip detection (see V-Clip).

If you can get your head around the GJK algorithm this will give you the penetration depth as part of the collision routine. If your interested in programming this yourself check out 'Collision Detection in Interactive 3D Environments' by Gino Van Den Bergen. Else simply check out the authors own collision library SOLID which you can get for free of t'internet....just google.

For the sphere tree, I was thinking more like this

http://isg.cs.tcd.ie/spheretree/

Check out the publications as well.

Games use simple volumes for collsions. Spheres, cylinders, boxes, and never do a mesh mesh collision test, especially for things like physics. It's way too costly. They are usually approximated by simplices, or by convex hull for greater accuracy. For animated characters, they are just approximated by one single large bounding box. Ragdolls usually use cylinders or boxes for limbs.

the close contour is just from the top of my head. SInce it's very hard to do decent mesh mesh collisions using triangle overlaps, you'll need some pre-processing for the topology and post processing to find any meaning when all you know is that a bunch of triangles intersected. I found that very frustating when I discovered the RAPID library (triangle triangle collsions), and that it was actually totally useless. Triangles aren't enough.

Close countour, if you are interested, is just interconnecting intersection segments together to form a contour line that hopefully will be closed.

Its not necessary to restrict yourself to one bounding volume per object. Instead use as many as are needed to cover all parts of your objects to a satisfactory fit. If your object is very complex and many bounding volumes are needed you can even create bounding volumes around existing bounding volume groups, building up a hierarchy so that collision groups can be culled quickly.

for a pyramid, you can use convex hulls (which will be the pyramid itself). In that case, you have to use an algorithm such as Extended GJK, or V-Clip. For general meshes, this can be overwhelming, and what games want is speed over accuracy. You can sacrifice a bit of accuracy (the collision shape does not exactly fit the mesh but approximate it) for faster, simpler collision checks.

Generally speaking, doing mesh-mesh collision detection using overlaps and a simple triangle-triangle intersection test is unworkable by itself. You'll get into situations where the calculating the collision depth will either be completely wrong or crippeld by lots of spurious contact points that will make the collision system unstable.

That's my experience of it anyway. In most situations, you can get away with simple volumetric approximations.