DrJ's approach is the best approach for colliding against static geometry because all of the pertinent data can be pre computed and you can rely on using dotproducts only. Basically what he is doing is he generates vectors that point to the insides of the triangle. You find where a point intersects the plane formed by the triangle, and if that point is in front of all of the planes represented by the vectors that point inward then the ray hit that particular triangle.
EDIT: and unless I misunderstood you drj, there is absolutely no point in putting something like collision detection into video card implementation...that defeats the purpose of OpenGL as a low level graphics rendering API.
EDIT1: Oh, and brush collision code is better than all of this :-) (i use it in my engine)
[edited by - Shadow12345 on October 2, 2003 10:29:23 PM]
[edited by - Shadow12345 on October 2, 2003 10:31:46 PM]
[edited by - Shadow12345 on October 2, 2003 10:33:44 PM]
point in triangle
Brush collision uses BSP trees and bounding planes, which still requires a fair amount of testing, particularly for a complex physical system, such as modeling a dynamic (not static!) piece of cloth. Cloth can be a difficult material to model well, for several reasons. One, as one of the NeHe articles describes (article #40?), there are the physics systems to take into account, which are often far from trivial. Second, even when one applies the proper physics equations for the forces, strange things occur due to round-off error, time discretization, and so on. Third, the modeling of a piece of fabric/cloth in 3D can create a very complicated collision detection issue: one does not want the cloth "passing through" itself.
To prevent an object from "passing through" itself, one needs to test for collision of each piece of the object with all other pieces of the object... before and after they've moved. This can be very time consuming, and I've yet to find a better solution than collision-testing each tesselated facet. Such a collision for a piece of cloth, for example, means testing whether the applied Euler equations (i.e., velocity + acceleration at each vertex) cause a vertex to pass through another face of the cloth (presumably, a face held fixed as of the last rendering frame). This test has to be applied for each vertex along its entire path of motion.
To summarize, I believe that hardware manufactureres would do a great service by including at least some rudimentary collision detection "helper" functions in their hardware. For complex virtual reality simulation, modelspace collision detection is vital, and eats up a lot of CPU time that is better spent on the model physics, AI, and so forth.
[edited by - drj on October 3, 2003 11:03:28 AM]
To prevent an object from "passing through" itself, one needs to test for collision of each piece of the object with all other pieces of the object... before and after they've moved. This can be very time consuming, and I've yet to find a better solution than collision-testing each tesselated facet. Such a collision for a piece of cloth, for example, means testing whether the applied Euler equations (i.e., velocity + acceleration at each vertex) cause a vertex to pass through another face of the cloth (presumably, a face held fixed as of the last rendering frame). This test has to be applied for each vertex along its entire path of motion.
To summarize, I believe that hardware manufactureres would do a great service by including at least some rudimentary collision detection "helper" functions in their hardware. For complex virtual reality simulation, modelspace collision detection is vital, and eats up a lot of CPU time that is better spent on the model physics, AI, and so forth.
[edited by - drj on October 3, 2003 11:03:28 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
