I would like to implement object boundaries in my engine and really don't need/want any kind of physics or rigid bodies or anything like that. In essence, I just want to check if two arbitrary positioned (on arbitrary axis etc) boxes intersect. It would be nice if the library had other primitives as well. Does anyone know if there is such a thing out there? Something that just does the math and spits out true or false or an intersection point in a more or less straight forward way (something like "bool isIntersecting(Box b1, Box b2)" ? I've downloaded bullet physics, but there is not even a single tutorial out there about this and it seems like I need about 200 lines of code to set up something similar to that. Also if anybody has these functions already implemented in their engines, would you mind sharing them? (either through github or any other way), I would really appreciate that too. 

30 minutes ago, dimi309 said:

I've done that here:

Have a look at src/BoundingBoxSet.cpp in the source code. I haven't based it on any literature, just wrote it off the top of my head. But it's well tested. In my case I load the box from wavefront files, but you could replace that part.

 

Edit: Actually, I don't think this will work too well for my current use. I noticed you have the

              const glm::vec3 thisOffset,
              const glm::vec3 thisRotation,
              const glm::vec3 otherOffset,
              const glm::vec3 otherRotation

call variables. My box vertices are already rotated, I don't have rotation angles available (I could calculate them but it's a bit backwards, I'd rather just have the algorithm work off of plain, pre-rotated vertices (which is how I have it represented now). But thanks, I appreciate your help anyways.

That's exactly what I'm looking for! Thanks. I'm just going to rewrite it with DirectX math and as far as I can see all I have to do is fill in the std::vector<std::vector<float> > vertices; with the box vertices and call the bool collidesWith(...) function? Also, are you sure it works with arbitrary box shapes (various 3d rectangles) that are at arbitrary angles to each other? And what about the speed of it? The function looks to be simpler than what I expected, is the reason I ask. But thanks!, I'll get to work!

Also, if anyone else wants to post some more of their functions I would really appreciate it. I could use the sphere/box sphere/sphere intersection as well. Thanks.

2 minutes ago, dimi309 said:

The way to use it is indeed how you mention. I have used it with different rectangles in my games and it worked. I haven't had any performance issues but it depends on how loaded your scene will be I suppose. The little caveat is that the way you rotate your models would have to match the way the collision detection performs rotations, or change the latter to match the former.

In any case we often have to change code. The important thing about this snippet, in my view, is it's simple logic:

Check if a point is within a box. If the box is rotated, inverse-rotate the point rather than rotating the box, keeping the actual collision detection math simple (or rather non-existent), which is also good for performance.

To check if two boxes collide, run the above to check if any of the 8 corners (points) of box 1 is within box 2 and vice versa.

Sorry, a bit late here, I've updated my last reply with this 

Actually, I don't think this will work too well for my current use. I noticed you have the

              const glm::vec3 thisOffset,
              const glm::vec3 thisRotation,
              const glm::vec3 otherOffset,
              const glm::vec3 otherRotation

call variables. My box vertices are already rotated, I don't have rotation angles available (I could calculate them but it's a bit backwards, I'd rather just have the algorithm work off of plain, pre-rotated vertices (which is how I have it represented now). But thanks, I appreciate your help anyways.

Any ideas?