struct aabb {
float centroid[3];
float width_height_depth[3];
};

published on Dec 23 2025

Axis-aligned bounding boxes are ubiquitous in 3D programming, typically used as stand-ins for some other shape (for example, for purposes of collision detection or determining visibility). The main characteristic of an AABB is that it is, well, axis-aligned: its sides line up with the coordinate axes. Over the years I’ve encountered a couple useful tricks for working with them that I want to share here. None of these are new.

AABB Representation

The first trick has to do with AABB representation. In some learning materials, I’ve seen AABB represented as a point (usually the centroid) plus the dimensions of the box:

struct aabb {
float centroid[3];
float width_height_depth[3];
};

Sometimes the width/height/depth are stored divided by 2, but you get the idea.

A better (in my opinion) representation is storing the min and max values for the x, y and z coordinates within the AABB:

struct aabb {
float x_minmax[2];
float y_minmax[2];
float z_minmax[2];
};

Incidentally, this representation is used in Peter Shirley’s raytracing series. A slighly different version of this is just storing min and max corners of the box. Those "minmax" regions are also referred to as "slabs", because the AABB can be thought of as the intersection between three "slabs" of 3D space (think of a slab as an infinite region bounded by two parallel 3D planes).

This representation occupies the same amount of memory as the point-plus-dimensions one, but I think it’s nicer because many operations call for computing those boundary values anyway. For example, computing the bounding box that encloses any two given bounding boxes is extremely trivial with this representation, whereas the point-plus-dimensions one requires some extra computation:

aabb enclosing_aabb(const aabb& b0, const aabb& b1) {
return aabb {
{std::min(b0.x_minmax[0], b1.x_minmax[0]), std::max(b0.x_minmax[1], b1.x_minmax[1])},
{std::min(b0.y_minmax[0], b1.y_minmax[0]), std::max(b0.y_minmax[1], b1.y_minmax[1])},
{std::min(b0.z_minmax[0], b1.z_minmax[0]), std::max(b0.z_minmax[1], b1.z_minmax[1])},
};
}

Finding AABB Vertex Coordinates

Some operations require us to know the coordinates of individual bounding box vertices. For example, to test whether a bounding box intersects an arbitrary plane we need to check whether all of the vertices lie on the same side of the plane or not.

At first glance it might seem like the point-plus-dimensions representation should be ideal for this, but it actually turns out that the slab one results in much simpler code.

Two key observations here are: 1) the AABB has only eight vertices; 2) a coordinate of an AABB vertex cannot have a value that is between the allowed min and max values. For example, for any AABB vertex, its X coordinate is always either X_min or X_max.

Putting these two observations together, we can conclude that the index of an AABB vertex (a number ranging from 0 to 7) fully encodes the coordinate values of that vertex. The rules for this encoding are pretty simple: 1) bit 0 corresponds to coordinate X, bit 1 to Y, bit 2 to Z (the rest of the bits are irrelevant since there are only 8 possible index values); 2) if the bit value is 0, its corresponding coordinate should have the minimum value, otherwise it should have the maximum value.

Using this rule, we can determine the coordinates of any vertex using some bit-twiddling and indexing with no floating point math whatsoever:

// assuming `i` is the vertex index.
// for each axis, isolate the corresponding bit and use it to look up
// the coordinate in the axis' minmax array.
float vertex_i_xyz[] = {
aabb.x_minmax[(i & 1) >> 0],
aabb.y_minmax[(i & 2) >> 1],
aabb.z_minmax[(i & 4) >> 2]
};

I haven’t seen this particular trick explicitly mentioned anywhere, though I am sure that many people have figured it out on their own.

Ray-AABB Intersection Test

There’s a very nice way to check whether a given ray intersects an axis-aligned bounding box. This test is pretty old with roots dating all the way back to Kajiya and Kay’s 1986 paper. It’s used extensively to this day.

Ray Tracing Gems 2 includes an explanation for this algorithm but to be honest I think it’s a bit terse, so I’ll try explaining it myself.

First, a ray is fully defined by its origin point o and its direction d. Any point along the ray corresponds to a value of a scalar parameter t and can be found by evaluating o + t*d.

We already mentioned that an AABB can be thought of as an intersection of three "slabs". The idea of this ray-AABB intersection test is as follows:

• For each slab, find the values of t corresponding to points where the ray pierces the slab. The value of t for the entry point is necessarily smaller than that for the exit point. We’ll call this pair of values a "t-range".
• If the t-ranges for all three slabs overlap, the ray intersects the AABB.

An axis-aligned slab is defined by two values - min and max. It’s pretty trivial to find the ray-slab intersection points using the ray equation. This example shows finding the t-value of the intersection point with the "min" wall of the X-slab:

// If there is a point where the ray pierces the "min" wall of the slab, the
// following must be true for that point's corresponding t-value:
o_x + d_x * t = x_min

// therefore:

t = (x_min - o_x) / d_x

The intuition behind this is that, whatever that intersection point is, its x-coordinate has to be x_min because that’s just how the X-slab is defined. Similar logic applies to Y and Z slabs, which gives us t-ranges for each slab.

Finding whether all t-ranges overlap is also easy. Each t-range has a start and end value. For all ranges to overlap, the largest start value has to be smaller than the smallest end value.

This condition is necessary: if the largest start value were larger than the smallest end value, then the range with the largest start value would not overlap the range with the smallest end value. This condition is also sufficient: every range starts before the range with the largest start value (by definition), and every range ends within or after the range with the largest start value (due to our condition), therefore they all overlap.

With all of that said, we can write some pseudo-code for the AABB-ray intersection test:

// returns true if the ray `r` intersects the aabb `box` AND the t-value
// for the intersection point is within the [t_min; t_max] range.
bool intersects(const aabb& box, const ray& r, float t_min, float t_max) {
const float3 min_walls { box.x_minmax[0], box.y_minmax[0], box.z_minmax[0] };
const float3 max_walls { box.x_minmax[1], box.y_minmax[1], box.z_minmax[1] };
const float3 reciprocal_ray_dir = 1.0 / r.d; // assumes div by 0 will result in inf.
const float3 t_minwalls = (min_walls - r.o) * reciprocal_ray_dir;
const float3 t_maxwalls = (max_walls - r.o) * reciprocal_ray_dir;
// we have the t-values for intersection points with every slab wall.
// now determine which of these are the start points of the t-ranges,
// and which are the end points.
const float4 t_ranges_starts { min(t_minwalls, t_maxwalls), t_min };
const float4 t_ranges_ends { max(t_minwalls, t_maxwalls), t_max };
const float largest_start = max_component(t_ranges_starts);
const float smallest_end = min_component(t_ranges_ends);
return largest_start <= smallest_end;
}

By now you probably have noticed that this algorithm contains a potential division by zero. Unless your environment is set to trap on division by 0, this operation should produce an infinity which is a perfectly legal IEEE floating point value (actually, would be a negative infinity in case of division by -0.0, which is also a perfectly valid IEEE float). The ray tracing gems article provides some further pointers on why this works, and explains a case where this code might produce NaNs (due to multiplying 0 with infinity).

---

Like this post? Follow me on bluesky for more!