Oh no, more collision detection.
I''m sure this has been covered before but I searched the board and articles but couldn''t find the answer I was looking for.
I have a collision detection routine, that I coded, which works by first checking bounding spheres to see if they collide. If they do, the routine then goes on to compare the two meshes. It checks whether any point in object X is entirely on the opposite side of each face in object Y (using the normals).
This has been working well for me, but I''ve been looking to extend the routine and have hit upon two problems.
1) I can set the routine to check all points or just until there is a collision. In the case of the former, I end up with a list of points in space where collisions were registered. How can I average these out into one point that lies in the centre? Will a simple average function do?
2) If in one frame object X moves entirely past object Y, a collision won''t be registered. Naturally. Does anyone know the math required to find the point where the two are most likely to have collided, so that I can then run my usual checks?
Any pointers would be greatly appreciated.
Cheers.
1. If you had the points relative to some central position, you could just add them. You can still recover this by subtracting the location of the object from the points. ie, if you register collisions as points p, q and r, and the object is located at point s, then the collision can be estimated to be at:
(p - s) + (q - s) + (r - s) or p + q + r - 3s
this only works if the point s is a point p, q and r are "relative" to (like the center of a cube (0,0,0) and its corners).
2. You need to do path intersection. Rather than doing collision detection based on frame rate, either
a) animate up to the next collision (more complex timing); or
b) calcuate the intersection of an object A''s path with another object B, estimate whether A lies on the far side of B after a frame and if so "backtrack" until you find the collision. Simpler in terms of timing, more costly in terms of calculations.
See the Math and Physics forum; there was a fairly recent thread on this same topic (you might need to dig a bit).
(p - s) + (q - s) + (r - s) or p + q + r - 3s
this only works if the point s is a point p, q and r are "relative" to (like the center of a cube (0,0,0) and its corners).
2. You need to do path intersection. Rather than doing collision detection based on frame rate, either
a) animate up to the next collision (more complex timing); or
b) calcuate the intersection of an object A''s path with another object B, estimate whether A lies on the far side of B after a frame and if so "backtrack" until you find the collision. Simpler in terms of timing, more costly in terms of calculations.
See the Math and Physics forum; there was a fairly recent thread on this same topic (you might need to dig a bit).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement