Edit 2: If you haven't read any of this thread yet, you should just skip all the posts (including this one) until the 6th reply. Read that one. Edit: Oh yeah, my source code example is in C++ . Keep in mind as you read this that I am confused to the point where I have no idea what I am doing really (not to mention I am kinda tired) so if you think I am doing something incorrectly, or if you would do it differentley, please feel free to tell me. The end result I am trying to get is boxes (rectangular prisms, specifically) that are able to be rotated, and tell if they are colliding with another box. I was planning on implementing it as below: Okay, lets say I have a box. Rather than having it defined by it's 8 verticies, it is defined as follows (this is a rough example, just try to bear with me): This way, I could check the collision by checking each of the lines of another box against each of the planes of this box (at least I think I could, like I said, I dont really know if this is a good way to do this). Note that in the actual program, the constructor makes sure the faces are rectangles and the boxes are rectangular prisms. Also, if it matters, as a convention, a line's 1st point will be the left or top point of the line (in comparison to the face). So here's what I'd like to know: Question 1: Is this a stupid way of doing this? Question 2: If not, how would I go about rotating the box on its axes? Are there any formulas (formulae?) that would help me out here? Thanks for reading through this, I hope it was understandable. [Edited by - PunaProgrammer chris on June 27, 2006 6:26:05 PM]

Quote:Original post by PunaProgrammer chris
Question 1: Is this a stupid way of doing this?

No, it's not stupid :-) However, it's far from being the most efficient or useful algorithm for detecting intersection between oriented boxes.

Quote:Question 2: If not, how would I go about rotating the box on its axes? Are there any formulas (formulae?) that would help me out here?
Thanks for reading through this, I hope it was understandable.

The explicit form you're using can be useful in same cases, but usually for an oriented box it's sufficient to represent it as follows:

vector3 center;     // The center of the boxvector3 axis[3];    // The three orthonormal basis vectors (axes) of the boxfloat   extents[3]; // The half-extents of the box along each axis

Most box queries (including intersection with points, spheres, planes, or other boxes) can be expressed efficiently and compactly using this representation. As for the box-box test, an algorithm commonly used for this is the separating axis test. You can find info on this algorithm and others in the articles section here on gdnet.

Heh, that way looks like it takes much less code. Thanks for the info, I will look into this separating axis test. Just one question though to clarify, the extents are the width, height, and depth, correct?

Quote:Original post by PunaProgrammer chris
Heh, that way looks like it takes much less code. Thanks for the info, I will look into this separating axis test. Just one question though to clarify, the extents are the width, height, and depth, correct?

Yeah, I wasn't very clear about that. The extents are how far the box extends in both the positive and negative directions along the respective axis. So assuming width is along the x axis, height along y and depth along z:

extents[0] = width/2;extents[1] = height/2;extents[2] = depth/2;

Okey dokey.
I looked up the spliiting axis on google and came up with this: http://www.harveycartel.org/metanet/tutorials/tutorialA.html
I also came across a link to that page on a thread while doing a gamedev.net search. That seems to be the closest thing I can find, but I can't think of how that would be implemented in 3D, other than to test each rectangle for collision. I can't seem to find the article you mentioned in the articles section, could I get some assitance here?
Thanks again.

Here is the collision detection articles section. The article I was thinking of is called 'Simple Intersection Tests for Games', and is toward the bottom.

This article seems to do a pretty good job of telling how to calculate for collision in 3d using a splitting plane test (I guess the 3D version of the SAT?): http://www.gamasutra.com/features/20000203/lander_02.htm (the bottom half of the second page and most of the the third page seem to have all the info I need for that).
However this method needs to know the faces/edges/verticies of the box. Is there a way to just calculate the position of the verticies of a box using the center/axes/lengths and if so how?
Any help here would be appreciated.

[Edited by - PunaProgrammer chris on June 27, 2006 6:29:18 PM]

Quote:Original post by PunaProgrammer chris
However this method needs to know the faces/edges/verticies of the box. Is there a way to just calculate the position of the verticies of a box using the center/axes/lengths and if so how?
Any help here would be appreciated.

That actually wasn't the article I had in mind. Here is the article with the oriented box test using the SAT. It's the fourth or fifth section of the article; it has an explanation of the algorithm, along with source code.

Again, for most common queries it's not necessary to compute the faces, edges or vertices of the box explicitly.