bounding boxes pt 2

[boxrick]

[Spike]

[Urre]

Spike: a very useful reason to add support for rotated bboxes would be physics. I wouldn't mind making Twig use those instead of particles. It'd obviously need to be made as separate builtins, for calling aligned box shape tracing (possibly even a rotating sweep, wohoo), and not replace the current bbox operations.

[Spike]

What's the difference between that and 'simply' tracing against meshes?
Imho the definition of a bounding box is a box specifying the maximum bounds of an object. In this context there is no need for it to rotate, only to expand with rotation (in quake the bbox is specified by the absmin/absmax vales).
If you want to blur stuff a bit, then a collision box is the box with which things will collide. Imho in Quake, this would actually be best represented with a cylinder. Which would not need to rotate, and would not need to push things out of the way in order to rotate. But yes, quake uses a non-rotating box, because a BSP tree is built from the other object's mins/maxs.

Triggers trigger when their bounding box is touched - because the bounding box is larger than the model actually is, allowing items to be grabbed off shelves (triggers have special touch code or they would never be touched). Nothing else uses the bounding box as anything but an optimisation, in quake. I think most games out there follow this behaviour.
By rotating the collision box, you are stating that the object is a box, and if its not, then you're just wasting cpu cycles.
And if it really is a box, why are you not using full mesh-based collisions instead?
If all you wanted was to stop the corners of collision boxes from getting in the way constantly, then use cylinders or spheres.[/i]

[Urre]

Well I don't know what boxrick was ultimately after, but I can imagine implementing aligned box collisions is easier than sweeping mesh collisions, and certainly faster. You can also cull the rotated box with a regular non-rotated bounding box, ofcourse.