If you know the max and min points of a bounding box, is the following a correct way to express the corner points of the bounding box, or will it only work if the bounding box is axis aligned. Thank you.

// CREATE ALL THE BOUNDING BOX'S EIGHT CORNER POINTS
Point3d point_0(pntMax.x, pntMin.y, pntMin.z); // RIGHT BOTTOM NEAR
Point3d point_1(pntMax.x, pntMax.y, pntMin.z); // RIGHT BOTTOM FAR
Point3d point_2(pntMin.x, pntMax.y, pntMin.z); // LEFT BOTTOM FAR
Point3d point_3(pntMin.x, pntMin.y, pntMin.z); // LEFT BOTTOM NEAR
Point3d point_4(pntMax.x, pntMin.y, pntMax.z); // RIGHT TOP NEAR
Point3d point_5(pntMax.x, pntMax.y, pntMax.z); // RIGHT TOP FAR
Point3d point_6(pntMin.x, pntMax.y, pntMax.z); // LEFT TOP FAR
Point3d point_7(pntMin.x, pntMin.y, pntMax.z); // LEFT TOP NEAR

Well the first thing you might want to do is try to find a counter-example. So you are trying to find a given bounding box, with given coordinates. You take this box and determine the min/max x,y and z. Then construct a new bounding box using your way and try to prove that is doesn't work. If that is possible you are sure it doesn't work.

Wel let's take a box that isn't axis aligned.
We take a box with corners:
(x,y,z)
0: (0,0,0)
1: (1,0,0)
2: (2,1,0)
3: (1,1,0)
4: (0,0,1)
5: (1,0,1)
6: (2,1,1)
7: (1,1,1)

Determine the min and max:
min max
x 0 2
y 0 1
z 0 1

So the end result will be
(x,y,z)
0: (2,0,0)
1: (2,1,0)
2: (0,1,0)
3: (0,0,0)
4: (2,0,1)
5: (2,1,1)
6: (0,1,1)
7: (0,0,1)

And we see that the new bounding box is different from the original bounding box. *not considering the order of the corner points, that is irrelevant at this point*.
So now we have found a counter example that this way of writing down the corner points will give the original bounding box.

So you know that you way is correct to find a bounding box,
but the new bounding box is equal to or larger then the smallest bounding box. Because you will always get an axis aligned bounding box, and the smallest bounding box could be smaller.

It depends on where you want to use it, it gives you a bounding box, but not the smallest one possible.

Would that be a little mistake on your part. Where in the end results you have as your first point...(2,0,0), but that is not a part of the original box?

Quote:Original post by tekno
And we see that the new bounding box is different from the original bounding box. *not considering the order of the corner points, that is irrelevant at this point*.
So now we have found a counter example that this way of writing down the corner points will give the original bounding box.

That was actually the summary of my post. If you generate a bounding box with your method, with as input a bounding box that is not axis aligned, or not a cube, you will actually get a larger box, which is in turn a bounding box for the original bounding box. So yes you get a bounding box, but not the true minimal bounding box.

So no,with only the min and max point and your way of expressing the corner points the new box will not always be equal to the original bounding box.

In my post I gave an example of a bounding box, for which I determined the min and max parameters and then constructed the bounding box according to your way of expressing the corner points and it resulted in a different box. That was a counter-example to give an example of a case in which it won't give the original box. But the new box is a bounding box of the original bounding box, so in the end it still is a bounding box of the original object, but it might be larger

Your code is only for axis-aligned boxes. An oriented bounding box doesn't have a min and max per se (well, in local space it does), but rather has three axes (a local coordinate system) and extents along each of those three axes.

To find the corners of an OBB (oriented bounding box) you first need to find them in local space, like this:

corner[0].Set(extents[0], extents[1], extents[2]);

And so on. And then transform them into OBB space, like this:

corner[0] = TransformLocalToWorld(corner[0]);

Where TransformLocalToWorld() performs the proper rotation and translation to get from box space to world space.

If you have the box axes, you can also brute force it, like this:

corner[0] = boxpos + extents[0] * axis[0] + extents[1] * axis[1] + extents[2] * axis[2];

And so on for each signed permutation of the extents.

Does that help?

But to describe the box in a local coordinate system you would need to express the local axis in terms of the world coordinates. You would need at least two vectors to describe two axis, the last one could be found with a normal vector. And then you still have a vector to determine the origin of the local coordinate system in world coordinates. Plus you still have to give the min and max values.

So you would at least need:
2 vectors to describe axis of local system in world coordinates(and calculate third)
or 3 vectors to describe axis of local system in world coordinates

1 vector to describe the origin of the local system in world coordinates

and 6 numbers representing the min and max values in terms of the local axis.

Is that correct jyk ??

Because if that would be the case, I don't see any reason to not just store the 8 corner points.

Very informative. Thank you all.

Quote:But to describe the box in a local coordinate system you would need to express the local axis in terms of the world coordinates. You would need at least two vectors to describe two axis, the last one could be found with a normal vector. And then you still have a vector to determine the origin of the local coordinate system in world coordinates. Plus you still have to give the min and max values.

So you would at least need:
2 vectors to describe axis of local system in world coordinates(and calculate third)
or 3 vectors to describe axis of local system in world coordinates

1 vector to describe the origin of the local system in world coordinates

and 6 numbers representing the min and max values in terms of the local axis.

Is that correct jyk ??

Because if that would be the case, I don't see any reason to not just store the 8 corner points.

Well let's see, if you count vectors, you have 3 axes + 1 position + min + max = 6, vs. 8 corners. So the memory footprint is about the same.

However, most OBB operations that I'm aware of, including line/OBB intersection, frustum culling, and static and moving OBB/OBB intersection, work by operating on the local coordinate systems and extents of the OBBs. So in general, the standard representation of an OBB is:

Vector3 axes[3];
Vector3 center;
Vector3 extents;

Also, if you plan on changing the orientation of your OBB at any time, you'll need some representation of that orientation to work with, such as a quaternion, 3 axes, or a 3x3 matrix. Eight corners won't be much help in this case.

So basicly is just depends on what you are planning to do :)

Yeah, I suppose so. If you really only need the corners, then I suppose that representation would suffice.