Penetration Depth for mesh

This topic is 5080 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hey, So my collision detection routine for two meshes returns a list of colliding triangles. What is the best way to calculate the penetration depth? In the context of collision response, does it make sense for the depth to be calculated for each triangle-triangle collision or one for each body taking the deepest depth? Thanks, John

Share on other sites
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.

Share on other sites
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).

Share on other sites
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.

Share on other sites
Oliii, Thanks for the reply. Some thoughts...

With a sphere tree how should the primitive triangles be grouped? Right now I am using a BB tree with leafs storing 1 triangle.

I do have the model topology available, but I thought that might be to heavy. Right now my models are simple shapes, but if I had a complex character model I thought having topology would be pretty excessive. Do you know how modern games do it?

I am confused about this closed contours idea. If I have X triangle intersections, how would I decide which triangles belong in which contour, and how do I construct the counter?

I was thinking of implementing v-clip, but I read it can't handle coplanar faces easily. My models are triangulated so I have plenty of coplanar faces. As well v-clip seems like a beast to implement.

Share on other sites
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.

Share on other sites
Okay, so I am trying to implement a physics engine that is suitable for games. So I guess I should go down the simple volume path.

I have some reservations though. Imagine a unit pyramid colliding with a unit cube. Any simple volume that contained the pyramid would give bad results near the tip of the pyramid. How do games handle the cases where the bounding volumes don't fit well?

Share on other sites
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.

Share on other sites
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.

1. 1
Rutin
41
2. 2
3. 3
4. 4
5. 5

• 16
• 18
• 12
• 14
• 9
• Forum Statistics

• Total Topics
633362
• Total Posts
3011526
• Who's Online (See full list)

There are no registered users currently online

×