Overlapped boxes question
by Ron Nelson · in Torque Game Engine Advanced · 09/30/2009 (5:39 am) · 17 replies
Hi I wanted to see if there is some method to aquire the box information which is the amount that two bounding boxes overlap as in the picture below? This would be used to create new BoxF information.


About the author
#2
10/04/2009 (3:15 am)
Thanks for the input Adrian. However, I really think you would first need to calculate the percentage of overlap, also in most cases the normals of each in respect to each other. However in this case since I was only using it for mission area over megaterrain portions, one can assume that their directions are the same.
#3
10/04/2009 (5:20 am)
Quote:However in this case since I was only using it for mission area over megaterrain portions, one can assume that their directions are the same.I think you have to assume they're facing the right direction - otherwise your output wouldn't be a box, it'd be some odd prism shape.
#4
10/04/2009 (11:34 am)
Oh I know Daniel, but I have seen a lot of people doing a lot of crazy things these days with resources so I wouldn't put it past anyone to have some wierd mission area shape changing/rotating code out there for whatever reason.
#5
10/04/2009 (11:36 am)
However that being said it still does not resolve figureing out the percentage of overlap and since both boxes can be different sizes, that throws and additional variable in there.
#6
100 * volume of overlap box / volume of box 1
and similar for percentage of overlap with box 2 (or area instead of volume if you are considering it in 2D).
Also I'm assuming your boxes are axis aligned which also may be over simplifying.
10/04/2009 (12:40 pm)
Ron, I think I'm misunderstanding your question because once you have the extents of the overlap box, isn't the percentage overlap with box 1 just100 * volume of overlap box / volume of box 1
and similar for percentage of overlap with box 2 (or area instead of volume if you are considering it in 2D).
Also I'm assuming your boxes are axis aligned which also may be over simplifying.
#7
10/04/2009 (5:18 pm)
But you don't need the percentage overlap to figure out the overlap box, as far as I can tell. Just some vector operations. I think :P.
#8
Then you're talking about axis aligned boxes. In which case no percentages are required. It's simply the min of the maxes and the max of the mins like so:
Now if you want the amount/percent of overlap you can compare the volume of the overlap box to the other two boxes.
10/04/2009 (6:32 pm)
OP:Quote:This would be used to create new BoxF information.
Then you're talking about axis aligned boxes. In which case no percentages are required. It's simply the min of the maxes and the max of the mins like so:
bool Box3F::findOverlap(Box3F& inBox, Box3F* outBox)
{
if (!isOverlapped(inBox))
return false;
outBox->min.x = min.x > inBox.min.x ? min.x : inBox.min.x;
// repeat for y and z
outBox->max.x = max.x < inBox.max.x ? max.x : inBox.max.x;
// repeat for y and z
return true;
}Now if you want the amount/percent of overlap you can compare the volume of the overlap box to the other two boxes.
#9
10/04/2009 (6:41 pm)
... yeah that works but I like this better:bool Box3F::findOverlap(const Box3F& oneBox, const Box3F& twoBox)
{
if (!oneBox.isOverlapped(twoBox))
return false;
min.x = oneBox.min.x > twoBox.min.x ? oneBox.min.x : twoBox.min.x;
// repeat for y and z
max.x = oneBox.max.x < twoBox.max.x ? oneBox.max.x : twoBox.max.x;
// repeat for y and z
return true;
}
#10
10/04/2009 (6:47 pm)
Just use Box3F::intersect methods, this will compute the resulting intersection box and then you have all the info you need to compute your volume / area if required.
#11
Frank - I looked at Box3F::intersect before and it looks wrong to me, because it uses the min of the mins and the max of maxes which is doing a union rather than a intersect.
Dan - yup, agreed :-)
10/04/2009 (6:54 pm)
Scott - I think thats what I was trying to say in post 1 but you expressed it much more clearly than me :-)Frank - I looked at Box3F::intersect before and it looks wrong to me, because it uses the min of the mins and the max of maxes which is doing a union rather than a intersect.
Dan - yup, agreed :-)
#12
10/04/2009 (6:58 pm)
@Adrian: just looking the code... and yup it looks like you are right. Quite funny as I had my own union methods as it was missing ^_^
#13
10/04/2009 (7:41 pm)
heh @ broken Box3F::intersect. I didn't realize that was there. If it's going to be there though, it has to be corrected. Bugger 'cause now I've gotta make sure it's not being used anywhere in the engine in a way that will break when I fix it. :/
#14
(Hit build, the compiler will tell you everywhere its used with lots of nasty error messages)
10/04/2009 (8:04 pm)
Scott - don't fix it, just change its name to union :-)(Hit build, the compiler will tell you everywhere its used with lots of nasty error messages)
#15
10/04/2009 (9:34 pm)
Heh. Yeah, that's a nice easy solution. I was thinking "find in files" when I wrote that. Then I thought "hey, I'll just rename it to findOverlap and let the compiler sort it out". Didn't matter though as it was never used anywhere (no doubt why the flaw was never caught).
#16
- decalRoad.cpp line 1270
- decalRoad.cpp line 1362
- terrCell.cpp line 305, 313, ...
- tsShapeEdit.cpp line 792
I just post a msg on T3D private forum for this.
10/05/2009 (10:55 am)
In fact it is used inside T3D at the following places:- decalRoad.cpp line 1270
- decalRoad.cpp line 1362
- terrCell.cpp line 305, 313, ...
- tsShapeEdit.cpp line 792
I just post a msg on T3D private forum for this.
Torque Owner Adrian W
and if they do, the overlap box is
max extents = the minimums of the max extents of the two boxes
min extents = the maximums of the min extents of the two boxes
I think.