[blink-dev] Intent to Experiment : WebXR Device API

[Eric Deily]

Contact emails :

baj...@chromium.org, sko...@chromium.org

Spec :

https://immersive-web.github.io/webxr/

Summary :

This API provides access to input and output capabilities commonly associated with Virtual Reality (VR) and Augmented Reality (AR) functionality. It is intended to completely replace the WebVR API (https://www.chromestatus.com/feature/4532810371039232). The WebXR Device API has been designed to address the issues found in the prior WebVR API based on developer, web platform, hardware manufacturer, and implementer feedback.

Link to “Intent to Implement” blink-dev discussion :

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/XMLgC_SR0dw

Goals for experimentation :

• Get feedback on shape of new WebXR Device API, especially as developers migrate from WebVR to the new WebXR Device API

• Get feedback on simplified common input capabilities provided by this API, and understand which capabilities in Gamepad Extensions API are required that are not supported in WebXR Device API, and why they are required.

• Move developers to the new standards track API and sunset the WebVR API and origin trial.

Experimental timeline :

Enabled : Chrome M67-68 inclusive

• 12 APR : Chrome 67 Branch to Dev

• 24 MAY : Chrome 68 Branch to Dev

• 29 MAY : Chrome 67 to Stable*

• 24 JUL : Chrome 68 to Stable*

Disabled : starting Chrome M69

• 19 JUL : Chrome 69 Branch to Dev

• 04 SEP : Chrome 69 to Stable*

* Stable dates are estimates : https://www.chromium.org/developers/calendar.

Any risks when the experiment finishes?

Unless the API transitions to Stable, sites will lose the ability to interact with VR hardware, especially since we plan to end the WebVR origin trial no later than the end of this experiment.

Ongoing technical constraints :

None

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

The WebXR Device API will be available on on all five platforms, but VR capabilities are launching separately. Currently, Cardboard, Daydream, and “magic window” are supported on Android  and support for OpenVR (e.g., Vive) and Oculus Rift on Windows is behind a flag.

 

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5680169905815552

[Chris Harrelson]

LGTM

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5b74c72d-0200-46d5-9df5-f80a1d91f385%40chromium.org.

[David Dorwin]

Thanks. There is one additional part of this intent that is needed to address the second and third goals.

tl;dr: We would like to run a parallel origin trial to expose VR controllers as Gamepads, as they were with WebVR, in order to facilitate the transition and get developer feedback as more advanced input functionality is developed for WebXR.

WebVR used the Gamepad interface for input - for everything from Cardboard clicks to 3 DoF Daydream controllers to advanced 6 DoF desktop controllers.

Gamepads were associated with a VR display, and t

here were Gamepad Extensions to provide controller pose and handedness.

WebXR Device API defines an XR-specific input interface, XRInputSource, that replaces the use of Gamepad, providing a consistent way to handle selection across the range of input devices. However, the current initial definition does not support more advanced controller usage, such as additional buttons. More incubation and understanding of OpenXR will be necessary in order to determine the best way to support these use cases.

In the meantime, in order to maintain consistent capabilities as developers transition to the new WebXR Device API, avoid developer confusion and inadvertent use of the old mechanism for simple input needs, and get targeted feedback on WebXR input needs, we would like to allow WebXR developers to additionally opt-in to exposing VR controllers as Gamepads. Most WebXR developers will only request a single token for the WebXR Device API and use its input interface. However, the minority of developers that require advanced controller features will be able to request an additional token to expose a Gamepad instance [1] for each XRInputSource.

 

Thus, we are also requesting approval for an origin trial for "WebXR Gamepad Support." It will follow all the same dates as the main WebXR Device experiment. We will use the results of this experiment to help influence the future of WebXR's input capabilities.

[1] In addition to exposing a Gamepad instance, the token will add the displayId and hand attributes from the Gamepad Extensions to the Gamepad interface [2]. WebXR developers can iterate through the available Gamepads to find instances with a non-zero displayId then check the hand attribute to determine which XRInputSource it corresponds to. WebXR Device API currently only supports one device, so there is no need to compare the actual displayId value.

[2] The touched attribute was originally part of the Gamepad Extensions but has since graduated to the core Gamepad spec. We will send a separate Intent to Ship for this attribute, but if that is not approved in time, it will also be enabled by this "WebXR Gamepad Support" token because it is an important feature for VR controllers.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9CZNS-4JSXFTgJmC8rNyDS3MgZ0cxJStVyu%3D394Kn-og%40mail.gmail.com.

[Chris Harrelson]

LGTM. This plan sounds good, thanks for explaining it clearly.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHD2rsitkM%3DNuKV30cpo%2BZqDWPfm9m2nCr15K90kE%2B4S9iXGSQ%40mail.gmail.com.