Jump to content
  • Advertisement
Sign in to follow this  
Vast

AABB-Plane Collision

This topic is 3345 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

Hi All, I have followed the article on the good old flipcode (can't believe how long its been since the forums were up) regarding the collision detection (URL: http://www.flipcode.com/archives/Basic_Collision_Detection.shtml) And I have got it working perfectly (after a lot of tweaking and altering). I have a 3d point/plane collision detection, and then a custom to my game 3d point/wall collision detection. Now, I'm not entirely sure about how to expand it to use a bounding box. Could someone please shine some theory regarding this? Which points to test, in which order? I am assuming I have to define the bounding box as two 3D vectors (x) around the player position (*) such as this: x_____o |...........| |.....*....| o_____x ? Where do I go from there, having a working point/plane, point/wall collision detection? Thank you in advance! Sincerely, Tim EDIT: Got the ASCII picture to work

Share this post


Link to post
Share on other sites
Advertisement
the SAT will get you there (Separating Axis Theorem). Conceptually, the SAT can be a bit hard to grasp at first, but it is very easy to implement.

Here it is in 2D.

The SAT can be extended to 3D easily, and also made to work with a 'sweep' motion. Similar to throwing a box (or whatever polygonal convex object you may choose) along a fixed direction.

I would use that, rather than cast rays from the corners of the box. It will be more accurate, more reliable, and faster.

Share this post


Link to post
Share on other sites
Alternatively since it's just plane box intersection you can find the signed distance to the plane for every point on the box (+-Xx,+-Xy,+-Xz)and if all of those signs are the same then it lies completely on one side, otherwise there is a collision.

Signed distance explained:
http://mathworld.wolfram.com/Point-PlaneDistance.html

Share this post


Link to post
Share on other sites
Quote:
Alternatively since it's just plane box intersection you can find the signed distance to the plane for every point on the box (+-Xx,+-Xy,+-Xz)and if all of those signs are the same then it lies completely on one side, otherwise there is a collision.
True, but that's more work than is necessary. A more straightforward (or at least more efficient) method is to compute the projected radius of the box with respect to the plane normal, and then compare this value to the distance from the box center to the plane (in code this reduces to a couple of dot products, more or less).

Share this post


Link to post
Share on other sites
Hi!

Thank you for the replies. I already have the code to check what side of the plane the point is on, but I was hoping to avoid having to run each corner of the box against the plane. I will check these algorithms further to see what the best way of doing it is.

Once again, thank you for the replies. If you have more ideas - please :)

Sincerely,
Tim

Share this post


Link to post
Share on other sites
I think he wants more than just a plane, but a polygon colliding with a box. Doing it via casting rays through vertices wouldn't work very well I'm afraid.

Any questions, just ask.

Share this post


Link to post
Share on other sites
Quote:
Original post by oliii
the SAT will get you there (Separating Axis Theorem). Conceptually, the SAT can be a bit hard to grasp at first, but it is very easy to implement.

Here it is in 2D.


Nitpicking, but SAT is typically used for the boolean satisfiability problem. I skimmed your reply and went "wait, what?" (then went back and read your parenthesis). I've never seen "SAT" used for the separating axis theorem before!

Other than that, yeah what you said. :)

Share this post


Link to post
Share on other sites
Quote:
Nitpicking, but SAT is typically used for the boolean satisfiability problem.
Eh, that's not really a valid nitpick :) 'SAT' is a commonly used abbreviation for separating axis theorem; you'll find the abbreviation used widely online and in references on intersection detection in real-time simulations. (Plus, around here at least the separating axis theorem is discussed quite a bit more frequently than the Boolean satisfiability problem ;)

Share this post


Link to post
Share on other sites
I'm doing some reading and it seems a little difficult to grasp. Is this how collision is usually done in 3D games (read Quake3) which use an AABB?


Sincerely,
Tim

Share this post


Link to post
Share on other sites
In my experience I usually only end up comparing AABBs to other AABBs(which is very easy) in the broad phase of my collision detection. Then if two AABBs collide follow that up with SAT to compare their convex polygons/ polyhedrons. If you're dealing with models that aren't so convex BSP trees can be used to represent the models and check point intersections or break models into convex pieces.
Also, a note on my previous suggestion about using the signed distance of the points. You'd only be interested in the sign of these distances not the magnitude so you can drop the division by a vector length at the end since it will always be positive(saving a precious dot and sqrt). The calculation will end up being 8 vector subtractions and 8 dot products, which probably isn't the fastest way to do it, but definitely one of the simplest ways to do it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!