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
Expose DOMPoint model.boundingBoxCenter and DOMPoint boundingBoxExtent directly on the model element
Expose a boundingBox as a key-value Dictionary so we see
DOMPoint model.boundingbox.centerDOMPoint model.boundingbox.minDOMPoint model.boundingbox.max
...but are unable to return radius or other convenience methods
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.
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.
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)
andmax(x,y,z)
ORcenter(x,y,z)
andsize(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
toDOMPoint
,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
DOMPoint model.boundingBoxCenter
andDOMPoint boundingBoxExtent
directly on the model elementboundingBox
as a key-value Dictionary so we seeDOMPoint model.boundingbox.center
DOMPoint model.boundingbox.min
DOMPoint model.boundingbox.max
...but are unable to returnradius
or other convenience methodsintersect
,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.