Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Eight

Oh no, more collision detection.

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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).

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!