Rotating AABB (algorithm question)

[cep21]

AABB = Axis Aligned Bounding Box

I have a model.  I suround it by an AABB.  The model may need to rotate.  Rather than recompute the AABB (which would be slow), I'ld rather rotate the AABB with the model.  My absolute rotation comes to me as a Quaternion.  Here is my working algorithm.  Is there a faster way?

My AABB is defined by a center and 3 extent variables (X extent Y extent Z extent).  My AABB keeps track of its original center and original extents, but has a "using" center and "using" extent which it uses for culling purposes.  They start off equal.

1) Convert Quaternion to a 3x3 rotation matrix
2) Rotate the original center by this 3x3 rotation matrix.  This is now my new "using" center.
3) Make every value in the 3x3 matrix it's absolute value (IE if a value is -32 it becomes 32)
4) Multiply this 3x3 matrix by my "original" X,Y,Z extent of the bounding box.  This is now my new X/Y/Z extent.


This algorithm works correctly.  I'm wondering if there is a faster way.

[oNyx]

Usually you don't rotate em... they are axis aligned

And to tell the truth - usually it's good enough (it was good enough for Quake3 for example). If you're standing diagonally to your opponent on the grid the hitable area is ~40% bigger than usual (a factor of sqrt(2)), but - as I already said - it doesn't really matter.

If it's not accurate enough you could check for AABB intersection first and in case of a collision you could perform a more accurate check.

[cep21]

But the box around the person or object needs to change if the person rotates.  Otherwise they could move outside the box.

Games published by our own members! Check 'em out!

[oNyx]

Make the box bigger.

Take a look at these screenshots:
http://www.planetquake.com/alternatefire/unlagged_faq.html#IJRAMBIHOIJRAHBIM

[cep21]

Correct.  My question is how do I quickly figure out how much bigger to make the box.

[oNyx]

From the rotation centre the longest distance... then you have s sphere where you can wrap a cube around.

If you only rotate about one axis you could also do the same for a cylinder where you wrap a box around.

And if you don't do any more accurate collision detection you can also just do the box with trial'n'error/rule of thumb until it feels right.

[cep21]

"From the rotation centre the longest distance"

Do you mean the longest distance to any point in the model?  That's something along the lines of O(n).  What I suggested above is O(1).  I was wondering if my constant running time could be shorter.

[oNyx]

>That's something along the lines of O(n).

Who cares? It's a one time/offline operation. It's like thinking too much about the rendering time of pre rendered graphics

[nonnus29]

By making your AABB non axially aligned your throwing away one of the biggest advantages of using them; dead simple intersection testing   .

This algorithm works correctly.  I'm wondering if there is a faster way.

Why?  Even if you did this every frame for every (non-culled) object in the scene this code should never be a bottleneck in performance.

Like oNyx said; hierarchical bounding volumes would most closely approximate the principal of least cleverness. (ie check an oversize aabb first, then check bounding spheres  or elipses or whatever that more closely approxmate the model.)

[cep21]

The box stays AABB.  My algorithm rotates an AABB in O(1) into another AABB.  The question of "Is there a faster way" has more of a math/algorithms-are-cool drive than a gaming/practical-speedup drive.

Games published by our own members! Check 'em out!

[nonnus29]

The box stays AABB.

Oh, I see, n/m then!