Convert XRFrameOfReference to XRCoordinateSystem #340
Conversation
This is a speculative change based on today’s WebXR call. It drops the concept of a separate XRFrameOfReference object in favor of using XRCoordinateSystem directly. This necessitated moving where bounds were queried from, but I kind of like this better? Naming feels a little awkward at this point, but it’s a start.
|
|
||
| ```js | ||
| // Demonstrated here using a fictional 3D library to simplify the example code. | ||
| function onBoundsUpdate() { | ||
| if (xrFrameOfRef.bounds) { | ||
| let bounds = xrSession.getStageBoundsGeometry(xrCoordSystem); |
There was a problem hiding this comment.
Since bounds might not be always available, I suggest to change to tryGet.. and check that the returned object is not null (keep the previous if-check)
| ``` | ||
|
|
||
| When using a stage `XRFrameOfReference` the device will frequently have a configured "safe area" that the user can move around in without fear of bumping into real world objects. WebXR can communicate the rough boundaries of this space via the `XRFrameOfReference.bounds` attribute. It provides a polygonal boundary given in the 'geometry' point array, which represents a loop of points at the edges of the safe space. The points are given in a clockwise order as viewed from above, looking towards the negative end of the Y axis. The shape it describes is not guaranteed to be convex. The values reported are relative to the stage origin, but do not necessarily contain it. The `bounds` attribute is null if the bounds are unavailable for the current frame of reference. | ||
| When using a `stage` frame of reference the device will frequently have a configured "safe area" that the user can move around in without fear of bumping into real world objects. WebXR can communicate the rough boundaries of this space via the `XRSession`'s `getStageBoundsGeometry()` function. It provides a polygonal boundary given as an array of `XRStageBoundsPoint`s which represents a loop of points at the edges of the safe space. The points are given in a clockwise order as viewed from above, looking towards the negative end of the Y axis. The shape it describes is not guaranteed to be convex. The values reported are relative to the `XRCoordinateSystem` passed into the call, and do not necessarily contain the origin of that coordinate system. The bounds are unavailable for the device or given `XRCoordinateSystem`, an empty array will be returned. |
There was a problem hiding this comment.
It seems fine to squash XRFrameOfReference itself into XRCoordinateSystem, as XRFrameOfReference doesn't do much over XRCoordinateSystem as currently defined, except to add some stage-specific attributes. (and stages are only one kind of frame)
However, it feels like a design smell that we already find ourselves stashing the stage-specific bounds data off on XRSession. Especially as we start digging into anchors and other AR world understanding APIs, we are likely to have an increasing number of coordinate system flavors beyond stages that have extra metadata associated with them.
For example:
- Stages will have bounds
- Plane anchors will have extents, which will have change events
- Face anchors will have facial feature points that change each frame
- etc.
While stages will usually have just 1 instance, many of those other coordinate system flavors will have N instances, which will make it more awkward for us to stash such data elsewhere away from the coordinate system. Rather than finding a one-off solution for stage attributes, we should audition an API pattern here that works for stages, anchors and beyond.
I dig in on ideas there a bit in my comment on anchors issue 4.
|
After discussion on the WebXR call a few weeks ago it was determined that we primarily needed better docs and samples, not this specific change. Closing in light of that. |
Pull request is part of the conversation in #337. I'm not currently proposing this be merged, but I felt like having the necessary changes available in an form that was easy to comment on would be helpful in driving forward the conversation.
This is a speculative change based on today’s WebXR call. It drops the
concept of a separate XRFrameOfReference object in favor of using
XRCoordinateSystem directly. This necessitated moving where bounds were
queried from, but I kind of like this better?
Naming feels a little awkward at this point, but it’s a start.