(author here) Both would work - doesn't fundamentally change the underlying idea.
This particular representation is lifted from raytracing in one weekend and emphasizes the fact that we're really thinking of aabb as an intersection of three "slabs" of space. for me, it makes the ray intersection bit somewhat easier to explain.
The minmax representation makes less sense if you are frequently updating the 3D objects position, no? You really want both representations available.
It make sense to generate the bounds JIT when you are actually building an octree to test collisions. Assuming you have a nontrivial amount of objects.
Typically intersection checks outnumber updates, so it's better to optimize the former. Also, that only works if the object's pivot is at the center of the bounding box or you're accumulating movements without an explicit position.
That being said, a lot of tricks work better with center/extent instead of min/max, such as computing the AABB around an OBB or doing separating axis tests with abs() tricks. A bounding box and bounding sphere can also be stored together as center/extent/radius with only one additional value needed. Min/max works better for accumulation, though.
For non 3d graphics people AABB -> Axis Aligned Bounding Box.
struct aabb { float x_minmax[2]; float y_minmax[2]; float z_minmax[2]; };
Why not just do struct aabb { float mins[3]; float maxs[3]; };
SIMD and data locality. You probably want to check across three vectors simultaneously and load the coordinates next to each other.
I'm guessing here. I haven't written video games in 20 years but struct packing/alignment was super important on the Sony PSP back then.
For SIMD at least, the {mins[3], maxs[3]} representation aligns more naturally with actual instructions on x86. To compute a new bounding box:
new_box.mins = _mm_min_ps(a.mins[3], b.mins[3]);
You would want [4] not [3], with the last one being padding. Of course, you can't always afford that.
Indeed. This is classic array-of-structs versus struct-of-arrays.
(author here) Both would work - doesn't fundamentally change the underlying idea. This particular representation is lifted from raytracing in one weekend and emphasizes the fact that we're really thinking of aabb as an intersection of three "slabs" of space. for me, it makes the ray intersection bit somewhat easier to explain.
The minmax representation makes less sense if you are frequently updating the 3D objects position, no? You really want both representations available.
It make sense to generate the bounds JIT when you are actually building an octree to test collisions. Assuming you have a nontrivial amount of objects.
Typically intersection checks outnumber updates, so it's better to optimize the former. Also, that only works if the object's pivot is at the center of the bounding box or you're accumulating movements without an explicit position.
That being said, a lot of tricks work better with center/extent instead of min/max, such as computing the AABB around an OBB or doing separating axis tests with abs() tricks. A bounding box and bounding sphere can also be stored together as center/extent/radius with only one additional value needed. Min/max works better for accumulation, though.