Take into account performance implications of creating anchors

[bialpio]

Creating anchors can have performance implications from the perspective of used AR framework (ARCore hints at this for example here and here). Do we have any data related to anchor performance that we could use when coming up with anchor design? @cabanier, @thetuvix - do you have any numbers that you could share?

If the performance hit of creating an anchor is significant, we might want to consider imposing some limit on the number of anchors that the app could create.

[blairmacintyre]

There is no requirement that WebXR Anchors have a 1:1 relationship to ARKit anchors, so I think the browser can manage it.

I do think it is fair to say that if an anchor can't be created, for whatever reasons, the promise will fail. That gives a given implementation the ability to limit creation as they see fit. This may be necessary, for example, if a platform doesn't support anchors at all, or has different modes with different features. For example, when using the user-facing camera, ARKit (currently) disallows pose-based anchors.

And the abstraction layer of the browser let's us manage things in other ways. For example, for the pose-based anchors, if an anchor is created near another, they could actually both be attached to the same system anchor, and the browser could monitor their relative poses, and create new system anchors if needed. As one example.

We shouldn't be tailoring the API to particular inefficiencies in current platforms.

[bialpio]

(...) for whatever reasons, the promise will fail.

Agreed, there is a mechanism to fail anchor creation, but I think that if UA decides to reject the promise, it should also provide the failure reason to the application. Should communicating failure reasons also be a part of the spec, or are they left to the UAs to define?

For example, for the pose-based anchors, if an anchor is created near another, they could actually both be attached to the same system anchor, and the browser could monitor their relative poses, and create new system anchors if needed.

I’d be wary of emulating things that could also be emulated in JS by the application but without notifying the application that this emulation is done by the system. To me, it feels that the preferred behavior would be to either do nothing and let the app face the consequences of poor decisions (but maybe with some warning logged to the console so that app developers can find out about issues), or fail if the app reached some limit of the anchors.

And now I’m realizing that “let the app face the consequences of poor decisions” is contrary to the approach of imposing anchor creation limits. :) I think we can either close this issue & open a new one or turn this into “How should anchor creation failures be communicated to the application?”. Although it might still be valuable to gather some data about anchor performance across different AR solutions. Blair, WDYT, should we create a new issue or repurpose this one?

[blairmacintyre]

I'll leave the "create a new issue or not" up to you.

I will say, I'm 100% against imposing anchor creation limits in the API.

1. any limits we impose will be arbitrary, and be inappropriate for some platforms.
2. anchors being expensive is a platform issue, and it's not the same on all platforms.

If we limit anchors, platforms will try to work around it at the JS level, which is exactly the wrong place to do it. Efficient architectures shouldn't be hamstrung or have developers doing things better done at the platform level. Inefficient platforms can do the right things for their platform in terms of emulating, or they can refused to create more than a certain number of anchors.

I would like others to chime in. You are speaking from deep knowledge of ARCore. I do not have deep knowledge of any of these platforms. I would like to know what Microsoft and Magic Leap think, for example. And Apple (if anyone is reading).

[thetuvix]

I would be against any approach that propogates a meme in WebXR that anchors are "expensive" in any way.

On HoloLens, anchors are quite cheap to create. Specifically, if you put a second anchor close to your first anchor, and the system ends up using the same underlying features to track both, the anchor is basically free. In our spatial anchors best practice guidance, we tell users as such:

Local spatial anchors are easy and performant to create. The system will consolidate their internal data if multiple anchors can share their underlying sensor data. You should typically create a new local spatial anchor for each hologram that a user explicitly places, except in cases outlined below, such as rigid groups of holograms.

On HoloLens, we found it to be the natural instinct of many app developers to assume that anchors were expensive, and therefore go through varying degrees of gymnastics to minimize anchor usage, such as:

• Making one anchor and putting all their content on it (even 100m away), which basically negates the benefit of anchors
• Dropping their own lattice of anchors every 5m, and then manually moving content between the anchors
• Etc.

All of those app gymnastics would result in lots of fragile machinery that attempted to reimplement the system's underlying head-tracking system, but without any of the internal platform data that lets the system efficiently manage anchors while retaining stability. That problem will get far worse for WebXR apps that would find themselves picking heuristics that then don't work correctly on other platforms.

The most compatible path here across platforms would be for WebXR to just encourage apps to be honest about their intentions: apps should create a new anchor whenever they have a new chunk of content they want the platform to stabilize independently. The UA can then decide whether to actually create a new platform anchor for that new WebXR anchor, or whether to consolidate at the UA layer with some other anchor. The UA will be in no worse a situation than the app to make that decision optimally, and will very likely have a much better understanding of the particular best practices of the underlying platform that the WebXR app happens to find itself running on.

[bialpio]

Sounds good, I’m closing the issue.