Align anchors and RWG (e.g. planes)

[bialpio]

We should consider aligning real-world geometry APIs with anchors APIs. Whatever we think is the right model to communicate anchor updates / tracking loss to the application is going to likely be the right model to communicate geometry updates / tracking loss to the application. The discussion about it is already happening in issue #12, and is also touched upon in RWG repository in issues immersive-web/real-world-geometry#4, immersive-web/real-world-geometry#5. For example, a document about possible ways to inform apps about plane removals is available here.

[thetuvix]

For the specific aspect of communicating "anchor updates / tracking loss" to the app, we already do have our common mechanism in place - the XRSpace returned by anchorSpace. If a later plane enumeration API returns planeSpace, an app could handle the anchor space and the plane space polymorphically for tracking the position of the app's attached scene nodes each frame.

Outside of the XRSpace would be any further mechanism for communicating that an anchor has been lost forever, or that a plane/mesh seems to no longer exist where it was last seen. What it means for tracked objects to appear or disappear from a given list feels specific to anchors or real-world geometry, since those two APIs fundamentally differ in what they set out to do:

• "Anchors" track a closed app-defined set of meaningful physical locations.
• "Real-world geometry" tracks an observed result set of planes/meshes/etc. for some bounded spatial query.

What it means for an object to appear or disappear from an app-controlled list or a bounded query result over time seem different enough to leave them separate.

[bialpio]

You're right, it seems that XRSpace is the way to go - the applications can tie the objects that they'd like to place relative to planes, anchors, etc, by expressing virtual object location as relative to the corresponding XRSpaces. The auxiliary objects (e.g. XRAnchor, XRPlane) can then be used to clean up virtual objects if something disappears forever (the XRSpace will still be present in that case, but will never be "localizable").

When creating the issue, I was mostly thinking about unifying the approach that we take in the API, I did not want to suggest that we shove anchors and planes into the same array / set / collection. :) For example, if we think that a set of still tracked anchors is the right approach, then we'd need to have a good reason to diverge from this approach ("set of still tracked planes") when designing plane detection API.