Intent to Ship: WebXR AR Lighting Estimation

[Alex Cooper]

Contact emails

alco...@chromium.org, baj...@chromium.org

Explainer

https://github.com/immersive-web/lighting-estimation/blob/master/lighting-estimation-explainer.md

Specification

https://immersive-web.github.io/lighting-estimation/

API spec

Yes

Design docs

https://github.com/immersive-web/lighting-estimation/blob/master/lighting-estimation-explainer.md

Summary

Allows sites to query for estimates of the environmental lighting conditions within WebXr sessions. This exposes both spherical harmonics representing the ambient lighting, as well as a cubemap texture representing "reflections".

Blink component

Blink>WebXR>AR(Android)

TAG review

https://github.com/w3ctag/design-reviews/issues/574

TAG review status

Issues open (Non-normative only)

Link to origin trial feedback summary

https://docs.google.com/document/d/1AaEmO4JZpIQsMAhjiYW6o6cv3ZvB0hBAAOVmQiVy5MA/edit?usp=sharing&resourcekey=0-BHYsjthU1fMW82gOIHd_eg

Risks

Interoperability and Compatibility

This feature has been incubated in the Immersive Web Community Group, in a spec co-authored with representatives from Mozilla. Though heavily influenced by ARCore, care was taken to ensure that solutions would be compatible with ARKit as well.

Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/218)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2020-November/031594.html)

Web developers: Positive Interest is primarily from libraries (e.g. Three.js, ModelViewer)

Ergonomics

This feature is an extension of the WebXR Device API. The reflection cubemap is retrieved as a WebGL texture, and at least one format requires the half float extension to be enabled if a webgl1 context is used. The spherical Harmonic values may be a bit opaque to regular users, and are expected to be fed into some form of existing renderer (e.g. three.js, babylon.js, etc.)

Is this feature fully tested by web-platform-tests?

Yes

Launch bug

https://crbug.com/1093069

Sample links

https://storage.googleapis.com/chromium-webxr-test/latest.html?target=proposals/lighting-estimation.html

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5704707957850112

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/zt3gLmrhTHc/m/9jxodKr5CAAJ

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

Hi, comment below.

On Thu, Feb 11, 2021 at 9:42 AM Alex Cooper <alco...@chromium.org> wrote:

Contact emails

alco...@chromium.org, baj...@chromium.org

Explainer

https://github.com/immersive-web/lighting-estimation/blob/master/lighting-estimation-explainer.md

Specification

https://immersive-web.github.io/lighting-estimation/

API spec

Yes

Design docs

https://github.com/immersive-web/lighting-estimation/blob/master/lighting-estimation-explainer.md

Summary

Allows sites to query for estimates of the environmental lighting conditions within WebXr sessions. This exposes both spherical harmonics representing the ambient lighting, as well as a cubemap texture representing "reflections".

Blink component

Blink>WebXR>AR(Android)

TAG review

https://github.com/w3ctag/design-reviews/issues/574

There are a couple of open questions on the TAG review, could you respond to them there?

 

TAG review status

Issues open (Non-normative only)

Link to origin trial feedback summary

https://docs.google.com/document/d/1AaEmO4JZpIQsMAhjiYW6o6cv3ZvB0hBAAOVmQiVy5MA/edit?usp=sharing&resourcekey=0-BHYsjthU1fMW82gOIHd_eg

Risks

Interoperability and Compatibility

This feature has been incubated in the Immersive Web Community Group, in a spec co-authored with representatives from Mozilla. Though heavily influenced by ARCore, care was taken to ensure that solutions would be compatible with ARKit as well.

Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/218)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2020-November/031594.html)

Web developers: Positive Interest is primarily from libraries (e.g. Three.js, ModelViewer)

Ergonomics

This feature is an extension of the WebXR Device API. The reflection cubemap is retrieved as a WebGL texture, and at least one format requires the half float extension to be enabled if a webgl1 context is used. The spherical Harmonic values may be a bit opaque to regular users, and are expected to be fed into some form of existing renderer (e.g. three.js, babylon.js, etc.)

Is this feature fully tested by web-platform-tests?

Yes

Launch bug

https://crbug.com/1093069

Sample links

https://storage.googleapis.com/chromium-webxr-test/latest.html?target=proposals/lighting-estimation.html

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5704707957850112

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/zt3gLmrhTHc/m/9jxodKr5CAAJ

This intent message was generated by Chrome Platform Status.

--
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/CAGOLbz3EZWPkKZYU8ivZ7i4kACOkq1_quqGk6zTNLirBWt6aQQ%40mail.gmail.com.

[Alex Cooper]

Thanks Chris,

I replied on the TAG review and have opened a PR against the spec to add the portions mentioned there. It's worth noting that (as far as I understand it), the TAG feedback is around adding additional information to a non-normative section, and that all of this data in Chrome is only exposed after a permission prompt.

Thanks,

Alex

[yo...@yoav.ws]

LGTM

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d7edbe60-8e98-4e0b-83d6-902e649533cdn%40chromium.org.

[Alex Russell]

LGTM3 with nits:

Looking at the Explainer, there don't appear to be any considered alternatives. Presumably there were other potential API shapes available, and other areas of the design that might have landed a different way (e.g., why is there only one value for `reflectionFormat`?). Understanding those is important, and I'd like to see XR explainers improve in this area. I may block future intents if explainers don't include them, and would appreciate seeing them explored in this doc too.