kvark/mint

Bounding box types

kvark opened this issue · 5 comments

kvark commented

Concepts like an axis-aligned bounding box are well understood and used widely. We may consider trying to standardize the simplest forms (Range, Box2, Box3).

Issues:

  1. There is no optimal representation that everyone agrees on. The pros/cons of each representation (min/max, center+extent, origin+size) depend on the actual usage. Arguably, the boxes shall be converted to a format for some math library before being processed anyway, so maybe it's not such a big a concern. I consider the "min/max" representation to be most canonical for having less types in it.
  2. One-dimensional boxes. Perhaps, just advising to use std::ops::Range is the way. Apparently, one can use it for floats.

cc @nical

nical commented

One-dimensional boxes. Perhaps, just advising to use std::ops::Range is the way. Apparently, one can use it for floats.

Yeah, Range is already in the standard library with extra goodies so I don't see the benefit of adding another one in mint.

Would it be worth having the notion of axis-alignment in the name of the 2d/3d boxes? I don't know how much people use oriented boxes (as opposed to aabb) and which of the two meanings would come to mind first when reading, say, Box2.

I think I'd lean towards min/max for the box representation, but I don't have a strong opinion.

I'm hardly an expert on the topic, but for reference I present the two common use cases where I use bounding boxes, at least for games:

  1. I have an object of fixed size I want to put at a point, such as an asteroid. In that case, having the bbox be center+extent is ideal, because the center of my object equals the center of the bbox.
  2. I have an object of variable size I want to fill a space, such as a dialog box or an effect. In this case, I usually want to be able to define the bbox based on the coordinates of the edges or corner points.

Fortunately it's trivial to have one representation that provides methods to create it or turn it into other representations.

Oriented boxes are More Complicated, you have to store an aabb + a rotation or each of the corner points.

kvark commented

I'm leaning towards the idea of not including the bounding boxes in mint because they are higher level abstractions, and strictly speaking they are more related to collision detection than vector math. Another library can be based on mint to cover this, plus stuff like rays, frustums, etc

Fiiiiiine, if you insist. :-P

Another use case I came across is selecting a rectangular pixel section within an image, not even in the game dev area, rather in the VFX area. Just to let you know, I don't really need the box in mint necessarily.

I have settled on the bottomleft origin + unsigned size, which has the benefit that it is impossible to create an invalid box. Using min + max might have performance advantages, but can always turn out to be invalid (min > max).