Feasibility and desirability of persisting anchors

[AdaRoseCannon]

/tpac Persisting anchors on a device to allow a session to resume where they left off with the same anchors.

[cabanier]

@AdaRoseCannon did we end up discussing this at TPAC? FYI Oculus just released support for persistent Spatial Anchors. I would love to add support for anchors to the Oculus browser as long as they support persistence. Otherwise I think that they are not useful enough.

[AdaRoseCannon]

We did talk about it. I don't remember the final decision on persistent anchors only the discussion that they are not a stepping stone to shared anchors but a distinct feature.

I think the Anchors features like these are blocked waiting on industry standardisation so we don't nail our feet to the floor too soon.

On Thu, 9 Dec 2021, 17:59 Rik Cabanier, @.***> wrote:

@AdaRoseCannon https://github.com/AdaRoseCannon did we end up discussing this at TPAC? FYI Oculus just released support for persistent Spatial Anchors https://developer.oculus.com/experimental/spatial-anchors-overview/. I would love to add support for anchors to the Oculus browser as long as they support persistence. Otherwise I think that they are not useful enough.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/immersive-web/anchors/issues/69#issuecomment-990089998, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAHSMWOYLYPABTVSDUHW7LUQDVAZANCNFSM5F3OGK6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[cabanier]

We would be building on top of our OpenXR implementation which is part of the OpenXR standard. The API could be extremely simple: an anchor can be saved to an unique ID and an author can use this unique ID later to reconstruct the anchor. The UUID would be tied to the origin.

[bialpio]

From my perspective, it's unlikely that we would implement anchor persistence in Chrome anytime soon. In order to do so on top of ARCore, we'd have to use Cloud Anchors API, which IIUC would mean that ARCore needs to reach out to a backend service (some details here), and I'm not too thrilled about that.

Non-exhaustive alternatives that we could pursue in Chrome for Android:

• Come up with a way of persisting anchor information without ARCore's (direct) help, using existing APIs (point clouds, plane detection, maybe throw in GPS data to the mix?). I have not yet attempted to design something like this; it may be a bit easier than trying to come up with a cross-framework format for sharing anchors as it would only have to work with ARCore, but it does resemble a more general "anchor sharing" problem to me.
• File a feature request on ARCore to provide a simpler API to persist anchors locally, with the hope that the backend service is mostly there to enable anchor sharing, which we don't need here.

Standard disclaimer that it is my personal opinion, other team members may disagree with me. I also may be missing something, I have not dug too deeply into the problem yet.

[cabanier]

@bialpio it's unfortunate that you need to reach out to a backend service. Is the issue that this would be too much setup cost or that it's not part of Chromium? If I remember correctly, Chrome already uses some backend services for web features.

@thetuvix , I see that there are Microsoft specific OpenXR extensions for Anchor persistence. Are you interested in exposing that?

[cabanier]

Persistent anchor are now in the spec