Skip to main content
gamedev.net
🔒 Locked

2D Bounding Boxes

Started by AdmiralBinary May 28, 2002 at 8:13 PM 4 replies 650+ views
Original Post
AdmiralBinary
AdmiralBinary
Can anyone suggest a good bounding box-bounding box collision detection system? Basically, I want to be able to move a bounding box a ceratin distance per frame and make it stop when it hits another bounding box. This would obviously rule out the possibility of simply checking its position each frame... ---------------------------------------------------------- "Go out with me you will." - Young Yoda''s favourite pickup line
sjelkjd
sjelkjd
quote:
Original post by AdmiralBinary
This would obviously rule out the possibility of simply checking its position each frame...


Why?

AdmiralBinary
AdmiralBinary
quote:
Why?

I apologize - I didn''t state my question as clearly as I intended to. What I meant is this: I don''t want to move the box and then check if it''s inside another box. I want to move the box only as far as it can move without colliding with any other boxes . My reasons for this are:

1) A box moving at high speed will have passed through another box in the space of one frame, and no collision will have been detected.
2) Using the simple position-checking method, it''s very difficult (for me, at least) to detect which side of the box has been hit so it can be "pushed" to the point where it would have collided with the box.

I already have a system which can detect whether a ray passes through a rectangle and where it hits it (I used that in SS1 for the bullets), but I need the same sort of thing for rectangles now. Anybody?

----------------------------------------------------------
"Go out with me you will." - Young Yoda''s favourite pickup line
a person
a person
a rectangle is merely a section of a plane created by taking the inside area of 4 intersecting lines and ignoring the outer area. you can cast a ray from each edge of the rectangle which would result in checking all possible conditions. unfortunatly however, you will have to check box1 to box2 AND box2 to box1. it is possible that a large box1 and a small box2 will collide, but box1 being in such a position that both horizontal rays project past box2 (ie over and under) though a collision should occer (box2 horizontal rays correctly intersect box1). this should works for most cases you will need (iw ont say 100%, since this is theory, though i cant think of a case this would fail), and can even use your bullet code reducing the debugging.

just realize that such accurate collision detection can cause other problems because you have to back track the whole system to the earliest collision each time one occers, otherwise oddities occer. for instance two boxes collide early in the frame, and a third box misses. this third box, could however be affected by how you handle the "pushing" of the two that collide, and it is possible that the collision of the two boxes could actually cause the third box to collide with one of the other boxes dependin on the timing and speed of things.

my suggestion to you is to decide how percise collisions must be. if you require super accurate physics, i suggest doing some research on rigid body simulations (most talk about 3d, but you can easily ignore the extra axis). if some oddities are ok (for instance sometimes when things are really close, they may miss even though they should hit because of collisions that occer easlier in time) then you should have no problems. you may want to limit the speed of the object and use a smaller timestep (i am ssuming 100% framerate independent code in which if only 1 frame is rendered per second, the game logic does not break and things move 100% correctly and no less accuratly then if the framerate is 200 frames per second). if you dont have framerate independent code, do some searching on the board since it has been discussed a lot.
Arion
Arion
quote:
Original post by AdmiralBinary
My reasons for this are:

1) A box moving at high speed will have passed through another box in the space of one frame, and no collision will have been detected.



Do I understand, that the one box will step over the other with no collision ? In which case, could you have a look ahead vector to detect a collision ? Maybe half the velocity vector ?


quote:
Original post by AdmiralBinary

2) Using the simple position-checking method, it''s very difficult (for me, at least) to detect which side of the box has been hit so it can be "pushed" to the point where it would have collided with the box.



If a function can detect a rect-rect collision, could it also return which side of the box it collided with ?

Guy
AdmiralBinary
AdmiralBinary
Well, I can look ahead with vectors BUT the thing is that I want it to be able to "slide" along the edges of a rectangle and not just stop when it hits it. This seems to be what happens when I do corner-vector-ray-projection-thingy sorta stuff.

----------------------------------------------------------
"Go out with me you will." - Young Yoda''s favourite pickup line

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.