It doesn't matter if the triangle is clockwise or counterclockwise. The sign of the dot product (dotp) will take care of that, and the result should be the same with either orientation.

Your code does exactly implement my instructions; however, I'm afraid that I made a mistake in my instructions, , and that is probably why you're seeing the wrong results.

In fact, when you do this:

intersect.x = v1.x - normal.x*dotp;intersect.y = v1.y - normal.y*dotp;intersect.z = v1.z - normal.z*dotp;  

You're actually projecting the point down onto the triangle. The value of intersect computed here is the vector within the plane of the triangle that, when added to tri.v1, gives you the point of interest projected onto the plane of the triangle. This length of this has nothing to do with what you want.

Here's the fix, . Replace the code above with the following:

intersect.x = - normal.x*dotp;intersect.y = - normal.y*dotp;intersect.z = - normal.z*dotp;  

With this code, intersect will be the vector that points from the point of interest (x,y,z) towards the triangle. This value of intersect is perpendicular to the triangle, and its magnitude is the minimum distance to the plane of the triangle.

Since you're using this for collision detection, you should note that this code really just gives the minimum distance to the plane of the triangle and not really to the triangle itself. It is entirely possible, even likely, that your point of interest may still be very far away from the triangle. If the triangle is horizontal, then the point may be horizontally a 1000 units away, but only 50 units perpendicular to the triangle's plane. How to fix this easily? You may want to do an oriented bounding box check first, make sure the point is contained within the bounding box before checking the minimum distance. If the point falls outside the bounding box, skip the more detailed check.

I do apologize for the error. I just didn't review it carefully enough to begin with.

Edited by - grhodes_at_work on July 13, 2001 1:26:24 PM

Ok but even if I use the bounding box collision detection before this one, it''s still possible that it tell me that there is a collision when there is not. Am I right?

Yes, using these quick-and-dirty techniques to detect collisions will often result in erroneous detections. But we often have to do approximate checks just to do it fast enough. And its often good enough for games. The bounding box check is a very nice way to avoid doing detailed checks that aren''t necessary.

If you''re interested in very precise collision detection (at a cost of CPU usage) then you might want to look into triangle-to-triangle intersection techniques. There is a *lot* of work done at the University of North Carolina at Chapel Hill on this (although their implementations are not considered robust by many folks in the game industry). Here is a link to their work:

http://www.cs.unc.edu/~geom/projects.shtml

See the second block of projects, "Collision Detection/Proximity Queries." For noncommercial use, you should be able to download code, or at least binaries.



Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

Ok thanks, I think all this info will help me