Support transforming bounding volumes

[Jondolf]

Objective

Make it straightforward to translate and rotate bounding volumes.

Solution

Add translate_by/translated_by, rotate_by/rotated_by, transform_by/transformed_by methods to the BoundingVolume trait. This follows the naming used for mesh transformations (see #11454 and #11675).

---

Changelog

• Added translate_by/translated_by, rotate_by/rotated_by, transform_by/transformed_by methods to the BoundingVolume trait and implemented them for the bounding volumes
• Renamed Position associated type to Translation

[Jondolf]

I changed it so that the rotation methods also rotate the centers of bounding volumes around the origin. This is important when you have e.g. a local AABB of a collider that is offset, and need to transform the AABB to match the collider's global pose. This is also what Parry does.

[mockersf]

adding rotation to something called "axis aligned" feel strange to me

[Jondolf]

For prior art, this is Parry's equivalent: https://docs.rs/parry3d/latest/parry3d/bounding_volume/struct.Aabb.html#method.transform_by

There are cases where AABBs are stored in local space and then transformed into world space, which requires computing the rotated version of the AABB. It's not computing the actual OBB (Oriented Bounding Box) but the AABB of the rotated shape. I agree rotation might not be the best term, but I'm not sure what a better name would be.

[alice-i-cecile]

This feels more like a revolve operation than a rotate: you're sweeping the object rotationally. Maybe there's a better name for all of the operations in there?

We could call this transform_sweep or something.

[Jondolf]

It's not necessarily a sweep or revolve in the sense that if you rotated a uniform AABB 90 degrees, it would be the same as the original AABB, not some AABB that contains all of the "swept" space. It's essentially just a merged version of the original AABB and the "rotated" one.

[Jondolf]

If it was transform_sweep, it would also imply that the starting position (before translation) would be contained within the resulting AABB. This is what swept_aabb in Parry returns. Here, however, the AABB only contains the volume of the "rotated" AABB at the end position, not the full swept AABB.

[alice-i-cecile]

Okay, noted. Hmm, not quite correct either then. I'm fine to just follow parry's naming for now.

[Jondolf]

Some more prior art in terms of naming and why we even need bounding volume transformations like these. Quotes from Christer Ericson's famous book Real-Time Collision Detection (chapters 4.1 and 4.2):

Desirable properties for bounding volumes include: [list cut down for brevity] Easy to rotate and transform

Bounding volumes are typically computed in a preprocessing step rather than at
runtime. Even so, it is important that their construction does not negatively affect
resource build times. Some bounding volumes, however, must be realigned at runtime
when their contained objects move. For these, if the bounding volume is expensive
to compute realigning the bounding volume is preferable (cheaper) to recomputing
it from scratch.

Computing an encompassing bounding box for a rotated AABB using the min-max representation can therefore be implemented as follows:

We could also remove the separate rotation and translation methods and only keep transform_by, but I think they're still nice to have.

Even more prior art:

• Bullet Physics AABB transformation
• Jolt Physics AABB transformation

[NthTensor]

The bounding boxes remain axis-aligned after rotation/transformation, right? Docs need to state that much more clearly. Otherwise seems useful.

[NthTensor]

This change is well motivated and matches the implementation in parry. I agree the naming is confusing but it conforms with standard practice and the docs clarify things further.

Looks good for merge, but I do have a non-blocking question about intended use. rotate_by appears to be non-decreasing in volume. Do repeated rotations by pi/4 cause the box extents to grow monotonically? How do you avoid arbitrarily large bounding boxes after repeated transformations?

[Jondolf]

Do repeated rotations by pi/4 cause the box extents to grow monotonically?

Yes.

How do you avoid arbitrarily large bounding boxes after repeated transformations?

The idea here is that we store the AABB in local space and only rotate that every time.

From Real-Time Collision Detection, chapter 4.2.6:

Last of the four realignment methods, the most common approach is to simply wrap
the rotated AABB itself in a new AABB. This produces an approximate rather than
a tight AABB. As the resulting AABB is larger than the one that was started with, it
is important that the approximate AABB is computed from a rotation of the original
local-space AABB. If not, repeated recomputing from the rotated AABB of the previous
time step would make the AABB grow indefinitely.

[NthTensor]

That makes sense. I would love it if you could work that into the docs somewhere (unless it already is and I missed it).

Edit for clarity: Specifically the bit about it only producing an "approximate" bounding box, and it usually not being good practice to rotate the same box multiple times.

[Jondolf]

Added a mention of how rotation can result in the AABB not being as tightly fitting, and how you should avoid successive rotations to the same AABB. This only really applies to axis-aligned volumes, so I didn't add this on the BoundingVolume trait itself but rather the AABB methods.

[NthTensor]

Looks great! Could we get that note added to the 3d bounds as well? This is looking really really solid.

[Jondolf]

Dunno how I missed that... That's what I get for writing docs at midnight 😅

Made a quick PR to add the note for Aabb3d: #12315