Bounding Box
A bounding box (Axis-Aligned Bounding Box and Oriented Bounding Box) is an automatically-created invisible box that defines the rough size of an entity. Its purpose is to perform cheap QPhysics collision tests given the entity is visible (often before moving on to more expensive ones).
As shown in the graph, a bounding box is compromised of two coordinate-based points: "mins" and "maxs." Both "mins" and "maxs" represent offsets to the bounding box's origin, where "mins" is always negative, and "maxs" is always positive. Interestingly, the sum of the offsets "mins" and "maxs" is the size of the bounding box.
Bounding boxes can be seen used with:
- QPhysics collision detection (mainly NPCs and players)
- Prerequisite for hitbox collision detection
- Line of sight tests
- Visleaves occupied by an entity
If a bounding box needs to be overridden manually, these can be done:
- Modellers use the $bbox QC command
- Mappers and scripters use the
minsandmaxskeys, if thesolidkey is set to 2 - Programmers call the functions
UTIL_SetSize()orCBaseEntity::SetSize()
Note:Entity parts that protrude its bounding box will not pass QPhysics collision tests. This includes hitboxes.Rotation
Bounding boxes are always aligned to the world's axes; they never rotate. This is presumably because of their use for collision detection of players: it would be impossible to turn around in a tight corridor if the four corners of your bounding box rotated with you. Axis-aligned boxes are also far cheaper to compute.
While this isn't a huge issue for objects that are roughly square from above, it makes oblong dimensions difficult to manage without switching to VPhysics. When VPhysics isn't an option there isn't much that can be done: a Day of Defeat: Source player who has gone prone has an oblong shape that can rotate through a full 360°, which Valve could only accommodate for by creating a "squished" bounding box that leaves the head and feet sticking out at all times (an image of this would be nice).
Object-Aligned
Object-aligned bounding boxes rotate with their entity. They appear to be linked to VPhysics to some extent.
- Todo: Is there more to describe, like how well do they work? Merge with earlier section if there isn't anything else.
Industry Terms
Source and its community does not make use of all the industry terms to bounding boxes, however development in or outside Source may use these variants of bounding box terms: AABB and OBB, or Axis-Aligned Bounding Box and Oriented Bounding Box.
An AABB is "a 3D volume relative to a given origin," or a box that isn't rotated. Its name is due to the fact that all its edges are parallel to the axes it is aligned to. An OBB is a box that's rotated, also known as "a 3D volume relative to a given origin and angle."
In most cases including Source, a bounding box is an AABB, as it's very simple to test for intersections—an AABB can't rotate along its model, requiring a recompute of the bounding box instead. In cases where a bounding box rotates along its model, these bounding boxes are referred as an AABB.
Debug-Based
Bounding boxes are quite involved in debugging; there are not only tools that visualize bounding boxes, but also tools that rely on bounding boxes to work.
Console commands that relate to bounding boxes:
ent_bbox- Visualizes an entity's bounding box, either the one you look at, a targetname, or a classnameent_absbox- Visualizes an entity's AABB, either the one you look at, a targetname, or a classnamepicker- For the entity on your crosshair, visualise the bounding box and other details
Programmer functions that are related:
- UTIL_EntitiesInBox - Find all entities within a given bounding box.
NDebugOverlay::Box- Draw a box with the given mins and maxs. In
/
, the function DebugDrawBox()may be available.