Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bounding box types #16

Open
kvark opened this issue Jun 26, 2017 · 5 comments
Open

Bounding box types #16

kvark opened this issue Jun 26, 2017 · 5 comments

Comments

@kvark
Copy link
Owner

kvark commented Jun 26, 2017

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
Copy link

nical commented Jun 27, 2017

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.

@icefoxen
Copy link

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
Copy link
Owner Author

kvark commented Oct 11, 2017

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

@icefoxen
Copy link

Fiiiiiine, if you insist. :-P

@johannesvollmer
Copy link

johannesvollmer commented May 17, 2021

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants