Jump to content
  • Advertisement
VanillaSnake21

Is there a 3D object intersection math library that is not a part of a physics framework?

Recommended Posts

Posted (edited)

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. 

Edited by VanillaSnake21

Share this post


Link to post
Share on other sites
Advertisement

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.

 

Share this post


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

 

 

Edited by VanillaSnake21

Share this post


Link to post
Share on other sites

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.

Share this post


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

 

Share this post


Link to post
Share on other sites
Quote

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.

It might be worth noting that this isn't sufficient for a general intersection test. Two boxes can intersect without any vertices of either falling within the other box. (There are other tests, such as those based on separating axes, that will properly detect all cases, barring numerical issues at least.)

Share this post


Link to post
Share on other sites

 

10 minutes ago, Zakwayda said:

It might be worth noting that this isn't sufficient for a general intersection test. Two boxes can intersect without any vertices of either falling within the other box. (There are other tests, such as those based on separating axes, that will properly detect all cases, barring numerical issues at least.)

Alas, you're right 😱 It's been 5 years I've been using that algorithm.

 

collision.png

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

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