WebXR immersive-ar feature handling rationale

Help & Support
2

Hi Michael.

It is two sided coin. Benefit of this approach, is that developer does not need to think about providing details for API enabling, then can just check if feature is available, then can use. If startXr method would accept flags for enabling features - then developer will have to explicitly enable feature before checking if it is available based on hardware availability.

The negative of it, is that providing optionalFeature to session, will lead to UAs enabling some internal features and it actually will consume CPU/GPU behind the scenes. So there is a cost enabling it, but not using it.

This one comes from stuff mentioned above, additionally, I believe it is not a good path to use requiredFeatures, as it will lead to inability to start session when some feature is not available.
Here is an example if requiredFeatures would be a path: developer would provide some API, if it is not available, it will fail to start session, developer needs to subscribe to such case, and then decide what to do, if want to progressively use session without that feature, then it will have to try starting session again, but that only can happen with user intent (click, touch, etc). So UX will be bad: click, show message something is not available, and click again?

While optionalFeatures path - is way more UX friendly: start session, check if feature is available - use it, if not, decide what to do, either end session or do app logic without some feature.

Currently most WebXR features are actually experimental, and their coresponding API Specs are not final. They are subject to change. As WebXR is still not finalized, we decided to just enable stuff for developers to experiment with. It is likely in the future we will add flags object to session, so developer will be providing flags to enable optional features.

Current goals of integrations:

  1. Make sure developer can access WebXR features with least coding as possible.
  2. Provide close integration with engine and WebXR freatures, so developer does not need to learn and interpret internals of WebXR specs.
  3. Currently due to specs are not final, many of those APIs are subject to change, and they likely to have breaking changes, untill WebXR specs are more stable.
2 Likes