<cabanier> scribenick: cabanier

trevorfsmith: welcome everyone!

Creating tag to indicate parity with "VR Complete"

Coordinate work on lighting estimation: https://github.com/immersive-web/lighting-estimation

trevorfsmith: log is going to bad :-)
... and it's all my bad
... there's a lot of movement on this feature lately
... the explainer was extended quite a bit
... let's talk about next steps
... kip, can you give us an update

kip: sure. the explainer is close to the last iteration
... all the feedback was captured
... quite a few issues were added
... I tried to mention the folks that made the suggestions
... people can pick things up if they want to help out
... some things are simple
... ie reference to microphone or administrative things
... I want to make sure that people don't think this is finalized
... most feedback was pretty straightforward. A big question is if a convenience function should be created for a cubemap
... there could be benefits if the browser already has access to it
... mozilla would like to see this function but other UA should decide if they want this

trevorfsmith: thanks for the update
... and thank everyone for contributing
... google is eager to work on this

NellWaliczek: yes, thanks for putting it all together
... I sent the latest draft to our internal team to get feedback
... I would be happy to explain how to go from explainer to spec

kip: thanks

trevorfsmith: is there anyone else would like to comment on this?

klausw: we are focusing on android and arcore so it should be possible for us to implement this

<kip> to mention breaking changes

klausw: I don't know if we need to wait for the explainer to end

trevorfsmith: let's follow up on github and the mailing list

kip: it would be great that people implement it as a way to test the spec
... we do expect breaking changes
... rather than promises, we'd have polling for events
... the idl will change
... but the current spec should be good to get ideas out

New modules possibilities for performance and AR

kip: we are already doing experiments ourselves

NellWaliczek: before digging into the AR question
... if we take a look at the email of July 31
... there are labels to issues for breaking things out into modules
... questions about gamepad, AR, etc

<NellWaliczek> https://github.com/immersive-web/webxr/labels/gamepad-module

<NellWaliczek> https://github.com/immersive-web/webxr/labels/ar-module

<NellWaliczek> https://github.com/immersive-web/webxr/labels/input-profiles

<NellWaliczek> https://github.com/immersive-web/webxr/labels/layers-module

NellWaliczek: this is not a module yet. more work is needed
... the last one is the one I want to talk about:

<NellWaliczek> https://github.com/immersive-web/webxr/labels/performance-module

NellWaliczek: Brandon and I noticed that there were a lot of issues that were at the end
... and that should be good for a new module
... so we tagged them with the performance module lable
... if people can review that label, and might be interested in driving progress on these things
... I think Kip might be interested
... Brandon and I are advocating on moving this out
... since it's not required for baseline functionality

<Zakim> kip, you wanted to say interested

kip: we would be interested and want to put resources on it

NellWaliczek: I believe Microsoft is interested as well
... so maybe now is the time to re-evaluate

trevorfsmith: one of the things is that the timing is unclear
... do these all have the same timeline?
... would it make sense to create separate modules?

NellWaliczek: yes and it's related what we want to talk about
... I'm inclined to open a single repo
... and then decide later if they need their own repo
... some things might fail. ie we implement them and authors aren't interested

<Zakim> klausw, you wanted to say will some items be open to being merged into main s pec?

klausw: when you say these are modules, could it be that it could be merged into a future core spec?
... because it's hard for users to go over several specs

NellWaliczek: absolutely
... it would likely be a level 2 of the core spec
... we don't know the answers where the content will end up
... some stuff might end up in specs of other groups
... we just want to incubate and then once it gets closer to ready, make a decision
... we'll just have to stay open to do the right thing
... performnance "module" is not quite right. more like performance "repo

trevorfsmith: let's switch to AR

<trevorfsmith> scribenick: trevorfsmith

Nell: We have multiple tensions and requirements for what people are trying to do with AR. I wrote a bunch of this in my last email. The original motivation behind pulling out AR functionality fromt he core spec into modules was a separation of concerns and speed of movement.
... Trevor mentioned at the time that it could mean a delay for the AR features, but we definitely don't want that. The equivalent discussion we just had for performance, but for AR... those questions were postponed in the spirit of focus.

<Leonard> sorry, I need to leave now.

Nell: We wanted to be able to move forward with features that are more clear while incubating features that are less clear.
... At amazon we say "is it a one way door" where the cost of recovering is high. We pulled out AR becauase it was a two way door decision.

https://www.irccloud.com/pastebin/UZxSjrOw/

Rik: As far as ML is concerned we don't really care about whether it is additive or source-over displays, as this is a hint to the developer. It doesn't change how they would construct the scene. immersive-vr and immersive-ar changes how the app is created.
... Most developers won't use the same assets for AR and VR scenes. So we don't want to display VR experiences on AR hardware because it will look bad.

Nell: Alex?

alexturn: It's more about being explicit about choosing a form factor and thus an env blend mode so we can be more explicit by being in a store or targeting devices. On the web it's more broad, so I'm inclined to agree with Rik about knowing which form factore. I don't know if we would block 90% of the VR on the device (only supporting inline) and we'd need to relent at some point.
... We'd say fine you could support VR and AR by adding a black think in the background. Well, immersive-vr is the only way to use AR devices so a lot of logically AR experiences would end up using immersive-vr. We'll have folks who want to do AR without anchors and hit-testing. There's plenty of that which can be accomplished with reduced features.

Rik: AR mode would imply more privileges (e.g. camera access) and I don't think that is the case until we have more meshing.

Nell: Hold on to that one. There were investigations around privacy and security concerns on different hw. We should start with needs and concerns for baseline necessities for different hw.
... Are there other user agents with short term plans to support AR hardware. I believe Mozilla does. I would be interested in hearing Mozilla's stance. Specifically on additive light displays.

Kip: We do function on additive displays, ML specifically. We would like to see there being the ability to express AR explicitly. We want to not pollute VR with lots of AR content. We want to encourage people to prototype in the future by providing responsive mode tools where you might simulate AR without having AR hardware.
... Even if we don't have hit-testing and other sensing (lighting estimation) I'd like to see immersive-ar enabled instead of shipping only immersive-vr.

Klaus: I have one other thing that's important. For Chrome on smartphone when you request immersive-vr it goes into Daydream mode which would mean that handheld AR wouldn't work. It's not an additive display but in order to experiment we do need the AR mode.
... About security concerns: we do want consent prompts to explain what's happening, for example camera access prompts. There are a set of things we need to get right for AR mode but I think it's relatively smaller than having a grab-bag of features with mesh testing, etc. That could be a follow-up and not in the core.

Brandon: Regarding spoofing camera access, that's a handheld issue only. Most of the time headset users in VR would not be seeing a video feed.

Nell: If I recall, the headset systems have reserved pixels to indicate recording is in progress, like an icon but the website could still spoof that.

Klaus: Why would that be a concern.

Nell: Sites could spoof that they have camera access and fool the user. This was raised at a f2f last June.

Klaus: That is true of any webpage?

Brandon: It wouldn't show a live camera feed and couldn't draw a recording indicator in your peripheral vision. You could have an immersive page that goes to the trouble of spoofing the recording indicator and try to blackmail. I don't know how many users would take that seriously, but it's less than zero.

Nell: This is the crux of why we pulled the AR stuff out, there's enough ambiguity that it would slow things down by a couple of months.

<Zakim> klausw, you wanted to say AR support on CHrome mobile

Brandon: Rik said the explainer made it sound like additive == AR mode, which is not the intention. It's meant to give you the ability to detect that you're not on an opaque page. If we had AR-only content with immersive-vr that would be a failure.
... I'm sensitive to polluting the VR mode argument. It seems to me that there is going to be a lot of 360/180 video content and I'm not sure why not to throw that up in an additive display so at the API level it didn't seem like we should be blocking it. We probably wants to communicate as precisely as possible how the content is shown.
... So, AR content should be in AR mode. I'd like confirmation from platform people (Kip, Rik, Alex) that if we did have immersive-ar mode along with immersive-vr would that reduce your concerns about enabling AR on your platform?

Nell: And "enabling" could mean "with warnings?"

<Zakim> alexturn, you wanted to agree on having a scoped ar mode

alexturn: We can build min-bar with immersive-ar but there are parts of their apps that could get by without pinning content to the world. That would give people the ability to get started.
... We could help avoid most of the mislabeled VR content being labeled as AR.

Nell: What is your need to differentiate handheld / head worn?

alex: It depends on whether that screen space is available in the 1.0 timeframe. I can see lots of things to ultimately do, but what would they do on day 1?

Nell: ??? missed it.

alexturn: If we had that flag it would help.

Nell: (repeating what I missed) Was he worried about differentiating handheld/head-worn by querying blend mode.

alexturn:

Rik: We will not ship immersive-vr for the reasons I said earlier, even with prompt about VR not looking right.

Nell: Follow up qs: what is the importance of handheld/headworn?

Rik: We don't have that concern.
... I'm not sure how they're different.

Brandon: I think the risk is detecting and getting it wrong and attempting screen aligned on ML.

Rik: We're not concerned.
... There's not much we can avoid bad UI.

<Zakim> kip, you wanted to answer Brandon's question

Kip: A lot of what was mentioned works for me as well. We will ship immersive-vr on our devices. We'd like to see immersive-ar. But we are concerned with handheld/head-worn. We have had people having trouble with this already.
... We'd want to differentiate based on design decision needs more than physical hw. Letting hw explicitely request AR mode and in general we give the user that information.
... If they asked for AR they'd get a different prompt. In the future there are additional perms needed they'd be prompted again.
... If we were to provide UX we could but given all of our AR platforms are more experimental it would be expected to see more UI around that.

<cabanier> +1 on what kip said

Nell: We're out of time so I'll go write up options for proceeding and we can either discuss them in the WG call (probably makes sense) vs trying to use email. I'll write it up by the end of the week. Any objections?

(no objections)

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: cwilso ada NellWaliczek bajones ddorwin bertf samdrazin alcooper kip alexis_menard Trevor F. Smith Leonard cabanier alexturn
Found ScribeNick: cabanier
Found ScribeNick: trevorfsmith
Inferring Scribes: cabanier, trevorfsmith
Scribes: cabanier, trevorfsmith
ScribeNicks: cabanier, trevorfsmith

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)