Concepts•Jun 2026•3 min read

Convex Hull vs Oriented Bounding Box

Two ways to wrap a shape for collision detection. One hugs every contour and makes your physics engine sweat. The other settles for "good enough" and runs all day. We pick the one that ships.

The short answer

Oriented Bounding Box over Convex Hull for most cases. An OBB tests in constant time with a fixed 15-axis SAT check and a tiny memory footprint, which is exactly what real-time physics, broad-phase culling, and.

  • Pick Convex Hull if need an exact tight fit for a static or low-count query — precise pick/ray tests, mesh-mesh proximity, or computing the minimum enclosing shape where accuracy beats speed
  • Pick Oriented Bounding Box if doing real-time collision, broad-phase culling, or anything that runs thousands of times per frame and needs predictable constant-time cost
  • Also consider: Many engines use both — OBB (or AABB) as the cheap broad phase, then a convex hull or GJK narrow phase only on the pairs that survive. They are layers, not enemies.

— Nice Pick, opinionated tool recommendations

The Honest Difference

A convex hull is the smallest convex polygon (or polyhedron) that contains your point set — it traces the actual silhouette, every real vertex on the outside. An oriented bounding box is a rectangle rotated to best align with the shape: eight corners, one orientation, done. The hull adapts to whatever you throw at it and can have hundreds of faces on a detailed mesh. The OBB always has six. That single fact drives every tradeoff downstream. The hull answers 'what is the exact convex boundary' and the OBB answers 'what's a cheap box that's roughly oriented like this thing.' One is geometry; the other is an approximation with a budget. Confusing them is how you end up with a collision system that's mathematically gorgeous and unplayable. Pick based on how many times per second you intend to ask the question, because that number decides everything.

Where Convex Hull Earns Its Keep

When you genuinely need a tight fit, nothing here beats the hull. It clings to the true outline, so it never reports a phantom collision in the empty corners that an OBB's slack creates. For a long thin diagonal sword, an L-shaped bracket, or a concave-ish mesh, the OBB wraps a box full of dead air and lies about contact. The hull tells the truth. It's the right call for precise picking, accurate minimum-enclosing-shape computation, and narrow-phase tests where a few false hits ruin the simulation. Algorithms like QuickHull and Graham scan build it in O(n log n), which is fine when you build once and reuse. The catch is the per-test cost: hull-vs-hull collision means GJK or full SAT over a variable axis count, and that variability is exactly what a frame budget hates. Tight is great until tight is the bottleneck.

Where the OBB Wins the Real Fight

The OBB's whole pitch is predictability. Six faces, fifteen separating axes for a 3D pair, constant time, every time — your profiler shows a flat line instead of spikes when a detailed mesh wanders into frame. That's worth more in shipping software than a snugger fit nobody can perceive at 60fps. It rotates with the object, so unlike an AABB it doesn't bloat grotesquely when a long object turns 45 degrees. Memory is trivial: a center, three axes, three extents. It's the default broad-phase volume in serious physics engines for a reason. Yes, it's looser than the hull, and yes a concave shape exposes its slack. But you cull 95% of pairs with it instantly and only pay for precision on the survivors. 'Good enough, instantly, forever' beats 'perfect, eventually, sometimes' in any system with a clock.

The Verdict

Oriented Bounding Box. Not because it's more accurate — it isn't — but because correctness you can't afford at scale isn't correctness, it's a stall. The convex hull is the better answer to a question most real-time systems never get to ask, because they've already blown the frame computing it. Use the hull where it belongs: static precision work, narrow-phase truth-telling, minimum-enclosure math, low query counts. For the 10,000-checks-per-frame reality of games, robotics broad-phase, and culling, the OBB's flat constant-time cost is the entire ballgame. The grown-up architecture uses OBB to throw out the obvious misses and a hull or GJK pass only on what's left — but if you forced me to ship one volume and walk away, I ship the box. The hull is the more impressive object. The OBB is the one that keeps your sim above 60fps. Ship the box.

Quick Comparison

FactorConvex HullOriented Bounding Box
Per-test costVariable — GJK/SAT over many axes, scales with face countConstant — 15-axis SAT, same every frame
Fit tightnessExact convex silhouette, no dead spaceLoose box with slack in the corners
Memory footprintVariable vertex/face list, grows with detailCenter + 3 axes + 3 extents, fixed
Concave-shape honestyTight up to the convex boundaryWraps lots of empty air, false positives
Real-time scalabilitySpikes under detailed meshesFlat, predictable broad-phase culling

The Verdict

Use Convex Hull if: You need an exact tight fit for a static or low-count query — precise pick/ray tests, mesh-mesh proximity, or computing the minimum enclosing shape where accuracy beats speed.

Use Oriented Bounding Box if: You are doing real-time collision, broad-phase culling, or anything that runs thousands of times per frame and needs predictable constant-time cost.

Consider: Many engines use both — OBB (or AABB) as the cheap broad phase, then a convex hull or GJK narrow phase only on the pairs that survive. They are layers, not enemies.

Convex Hull vs Oriented Bounding Box: FAQ

Is Convex Hull or Oriented Bounding Box better?

Oriented Bounding Box is the Nice Pick. An OBB tests in constant time with a fixed 15-axis SAT check and a tiny memory footprint, which is exactly what real-time physics, broad-phase culling, and game engines actually need. The convex hull is tighter and more "correct," but tightness you can't afford 10,000 times per frame is a liability, not a feature.

When should you use Convex Hull?

You need an exact tight fit for a static or low-count query — precise pick/ray tests, mesh-mesh proximity, or computing the minimum enclosing shape where accuracy beats speed.

When should you use Oriented Bounding Box?

You are doing real-time collision, broad-phase culling, or anything that runs thousands of times per frame and needs predictable constant-time cost.

What's the main difference between Convex Hull and Oriented Bounding Box?

Two ways to wrap a shape for collision detection. One hugs every contour and makes your physics engine sweat. The other settles for "good enough" and runs all day. We pick the one that ships.

How do Convex Hull and Oriented Bounding Box compare on per-test cost?

Convex Hull: Variable — GJK/SAT over many axes, scales with face count. Oriented Bounding Box: Constant — 15-axis SAT, same every frame. Oriented Bounding Box wins here.

Are there alternatives to consider beyond Convex Hull and Oriented Bounding Box?

Many engines use both — OBB (or AABB) as the cheap broad phase, then a convex hull or GJK narrow phase only on the pairs that survive. They are layers, not enemies.

🧊
The Bottom Line
Oriented Bounding Box wins

An OBB tests in constant time with a fixed 15-axis SAT check and a tiny memory footprint, which is exactly what real-time physics, broad-phase culling, and game engines actually need. The convex hull is tighter and more "correct," but tightness you can't afford 10,000 times per frame is a liability, not a feature.

Related Comparisons

Disagree? nice@nicepick.dev