Anchor reference space ancestry

[jdmiranda]

While reading the explainer and documentation I didn't see any indication of ancestry for the anchor parent reference space.

If a future goal is to facilitate anchors between AR and VR then they would have to exist within the same reference space. However, if they are facilitate the localization into many maps then you need either a reference with offset to that map or you only allow anchors to be shared between reference spaces of the same id.

If prior reference spaces mutate due to merges or there is a common reference offset due to successfully localizing into many spaces then wouldn't you need some form of ancestry to facilitate the sharing of anchors.

You may not currently be localized into a shared space but you may eventually localize into some edge node map that allows for an eventual shared offset.

[bialpio]

I don't think I understand what you mean here. :( Could you rephrase the issue?

A bit of context: according to my understanding, reference spaces in the WebXR spec are tied to the session in which they were created (so for example "local" reference space on device A may have a different origin than "local" reference space on device B; even on the same device, 2 different sessions may have different origins of their "local" spaces). There is no hierarchy of reference spaces and anchors, and there is no easy way to relate reference spaces across different devices - image/marker tracking may help with that though (if device A knows the position of an image relative to its "local" space, and device B knows the position of an image relative to its "local" space, they can compute the transform between their "local" spaces, but they will need to keep recomputing it as time passes since there may be adjustments happening).

[jdmiranda]

As the session goes on, traditional slam would continuously relocalize and would adjust it's offset if it had localized into a previous session map. This wouldn't affect the position of the anchor since it's relative to the offset. It would change the hard values of xyz. But you'd have to compute the actual location anyways per frame. depending on how the scene graph is handled. New to WebXR so send links if I'm behind on the current thought process. In order to have a shared experience, you have to have a reference point to generate offsets. My earlier comment was in the context that anchors are only as accurate as of the confidence in (re)localization. Their accuracy is tied to their backing features. Usually, that also means that they are proximal to each other.
Meaning the further you get away from them the lower your confidence should be in their accuracy. This is why you would hang content relative to the nearest anchor. Content would/should be hung on as many anchors as you need. I'm referencing greater than room scale here. There's also a memory limit to the size that the maps can be that head pose is consuming so multi-map multi-session would be required for anything that you intended to have persistence or multiuser on. Given that context, the map (I say map and not session because a session could localize into a map) would need some kind of identifier or ancestry for future sessions to use those anchors.

[bialpio]

WebXR attempts to hide the details of the underlying algorithms that are used for localization. I think it may be useful to look at the description of how reference spaces are described in the spec. If the WebXR-powered experience wants to work in greater-than-room-scale case, it'd need to use "unbounded" reference space and tolerate that the origin of that reference space may be adjusted over time.

Given that context, the map (I say map and not session because a session could localize into a map) would need some kind of identifier or ancestry for future sessions to use those anchors.

Currently, anchors are not persisted across WebXR sessions, and there is not really a good way to achieve anchor persistence through WebXR API. Does that address your issue?