Exposing computed boundingBox information

[zachernuk]

What is the right level of detail to expose bounding box information?

Fundamentally, an Axis-Aligned Bounding Box (AABB) only requires six values, e.g.: min(x,y,z) and max(x,y,z) OR center(x,y,z) and size(x,y,z)

In practice, most 3D engines expose some level of convenience over operations on AABB objects, e.g. to determine broad-phase intersections, adding and subtracting, or factoring their dimensions into matrix operations for transformation.

As well as that, there are questions of the lifetime of the objects created for this purpose - the timeframe for which objects are valid, when / if they're nulled, or whether things are resolved as being pass-by-value valid (i.e, they're re-creations that are only valid at the time of creation etc)

It seems like in the longer term, a comprehensive spatial web will need a more sophisticated set of 3D math objects, for relating DOMMatrix to DOMPoint, DOMRect etc. - but that seems like a big project that will require clearer use-cases and some initial, basic functionality for people to explore with.

Suggestions

1. Expose DOMPoint model.boundingBoxCenter and DOMPoint boundingBoxExtent directly on the model element
2. Expose a boundingBox as a key-value Dictionary so we see DOMPoint model.boundingbox.center DOMPoint model.boundingbox.min DOMPoint model.boundingbox.max ...but are unable to return radius or other convenience methods
3. Do the up-front work of creating an AABB interface that allows us to expose some selection of values and provides us with a context to supply convenience methods (e.g. intersect, volume, radius etc)

Personally, I think that while (3) is an inevitability, I'd actually lean on the simplest, roughest approach that gives early authors the bare minimum to work with, i.e. (1). I'm aware that can carry the risk of never being able to deprecate it, but I suspect we simply don't know enough about what we want to do the architecture up-front.

[toji]

A couple of thoughts:

• My experience has said that it's frequently more convenient to have a center+size than min+max. I do expect that you'll see various use cases that end up favoring both, though, so I don't think you'll be able to make a "correct" choice here.
• Re: "Expose a boundingBox as a key-value Dictionary", it's been made pretty clear to me in the past that Web APIs should consume dictionaries but never return them. If we want to return a bundle of attributes then an interface is the webby way to do that.
• If we do define an interface, then I strongly advocate for exposing center, size, min, AND max because they can be implemented as lazy attributes that are calculated from whatever the favored internal representation is. (WebXR does this with rigid transform matrices)
• That said, I would start with exposing a couple of attributes on the model element and only upgrade it to an interface if we see a strong reason for it. Thankfully the math required for most of the convenience methods you mentioned isn't very complicated.