Clarify when a requiredFeature is allowed to pass

[toji]

In some cases the requiredFeatures passed to requestSession() may depend on the presence of data that takes a while to initialize or is transient. For example: bounded-floor reference spaces are specified to require bounds and a sensor based floor. For many devices the exact floor height or playspace bounds won't be available immediately when the device first comes online. If, for instance, you're using a Windows Mixed Reality device the headset needs to be moved around a bit to establish which environment you're in before any pre-configured bounds are available and the floor plane is detected.

So the question is: Should a session request with requiredFeatures including bounded-floor be allowed to resolve prior to the bounds/floor are firmly established? Or should the request be rejected because we don't know for certain that the data necessary for the reference space is going to be available?

My assumption so far has been that we should allow the session to resolve when the platform can support the required feature, even if they don't fully satisfy the requirement at the time of session creation. I view requiredFeatures as a blunt instrument to prevent things like dropping an Oculus Go user into a bounded-floor experience that they will never be able to properly access, rather than a annoying gatekeeper that turns users away because they have not yet jiggled their headset an acceptable amount. This does, of course, leave open the possibility that the device may not be properly configured for the experience in question, which would ostensibly be a failure of the requirement. But generally it should be less problematic for a user who's got a room-scale capable device that they've configured for a stationary space to be shown room-scale content than for a 3DoF device to be shown the same thing, because in the former case there's at least a chance that they can reconfigure their device to see the content, and even if they don't there's likely to be a better understanding of why this particular failure happened.

[cabanier]

Should a session request with requiredFeatures including bounded-floor be allowed to resolve prior to the bounds/floor are firmly established?

On ML One, if we can't resolve the floor, we default to a predefined distance from the device. This usually happens right after setting up the device or if the room is so dark that we can't figure out the current position.

Or should the request be rejected because we don't know for certain that the data necessary for the reference space is going to be available?

We decided it would be better to show something that is possibly slightly incorrect. For most AR content, it ends up being roughly right.

[NellWaliczek]

I agree that features such as reference spaces which will require resources to spin up, but are known to be platform supported, can pass the "required" check. This is especially true because required/optional features protect apis that return promises due to their nature. Perhaps there's an exception to this that I'm not thinking of?