immersive-web / webxr-ar-module

Repository for the WebXR Augmented Reality Module

Home Page:https://immersive-web.github.io/webxr-ar-module

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Specify which reference spaces have to be supported for immersive-ar sessions

bialpio opened this issue · comments

We should specify which reference spaces can be requested via XRSession.requestReferenceSpace() for immersive-ar sessions as it does not seem to be covered anywhere in the text. The main WebXR spec describes that immersive sessions always support local-floor reference space, but this might not make a lot of sense for AR as floor position might not always be known.

local-floor reference spaces do not require knowledge of the floor, they're just better with said knowledge:

If the floor level isn’t known it MUST be estimated. If the estimated floor level is determined with a non-default value, it MUST be rounded sufficiently to prevent fingerprinting.

I'm not convinced that this is the right behavior (especially to force immersive sessions to return local-floor even in cases where it makes little sense) - we're running into the risk of apps trusting the estimated values and offering experiences that aren't great. There's no (?) way to communicate from the API that the floor is estimated (and no way to express how accurate it is), so the apps will either have to always assume it's accurate and risk offering poor experience, or never assume so. At the very least, it seems to me that we should allow the UAs to make the call whether local-floor is supported for a given immersive-ar session instead of making it required.

The point of all local reference spaces is that they're primarily for 3DOF -- they work fine for 6DOF but they're supposed to be used for when the experience doesn't intend for the user to move around much.

they're supposed to be used for when the experience doesn't intend for the user to move around much

In that case, I'd say we should allow the UA to not support local for smartphone AR (users might be stationary, but their smartphones still can move quite significantly), or add a separate mode for that because currently it seems to me that we're treating immersive-ar as synonymous with HMD AR.

Actually, not supporting local is going a bit too far, please ignore this statement. Still, local-floor is in my opinion not going to be useful for some devices. I'm not saying it shouldn't be supported at all, it's just that the current language makes it mandatory for UAs to support it even if they know beforehand that they won't be able to provide useful data. In my opinion it can only make the experience worse, because now the apps can rely on data that does not reflect the reality.

There's no (?) way to communicate from the API that the floor is estimated (and no way to express how accurate it is), so the apps will either have to always assume it's accurate and risk offering poor experience, or never assume so.

That was one of the three bullets discussed in immersive-web/webxr#534 - that issue got closed with two of the bullets resolved, but this particular design point around emulated floor height is still unaddressed.

I just carved this out as immersive-web/webxr#844 so we can drive the "local-floor" emulated height issue to closure.

Poking @klausw, @rcabanier and @Manishearth, with whom we'd discussed this today.

@bialpio would a note mentioning that AR supports all the reference spaces that VR does satisfy this issue given that #844 is now filed?

@bialpio would a note mentioning that AR supports all the reference spaces that VR does satisfy this issue given that #844 is now filed?

Yes, it will resolve the main part of this issue, although I still feel a bit uncomfortable with forcing UAs to return local-floor spaces that might potentially not be useful to the apps. I think we can continue the discussion in issue #844

Yeah, we'd ideally like to give the user the ability to check this. I'll make a PR.