Re: [webvr-internal] WebXR call agenda, Jan 9th 2018

Hello everyone,

Here are the notes of today's meeting.



* - Brandon will send an email thread to talk about other technologies for
how to meet. Meet is forcing everyone to use Chrome.- Incubator/Ideas
repo:- Name? - David Dorwin: Proposals, Propose work. - Ideas is too
broad.- Blair: All the proposed names/concepts imply something different.
What is the purpose of the repo.- Brandon: My idea is that is should be
about proposals with technical background. That is why I like "proposals"
as a name.- Nell: The idea is not that this repo is where the ideas should
be incubated. The idea is to submit ideas only and to make actual designed
and elaborated ideas in the main repo.- David Dorwin: this repo should be
for discussion not for landing anything.- Blair: Link to the process
followed by the RUST team:
https://github.com/rust-lang/rfcs/tree/master/text
<https://github.com/rust-lang/rfcs/tree/master/text>- Brandon: Playground
might be for random discussion.- Nell: Likes the idea of "Proposals".-
David Dorwin: the word "work" should be in the name or explanation to
identify that the proposals should be about what the community group should
work on.- Nell: Let's take this off line not to spend too much time on
this.- Brandon: A couple of things to talk off line- A explanation of the
process.- Code of conduct.- Brandon has been working on writing the spec
for the WebXR change during the holidays. Getting in a place where he is
happy with the formatting but wants feedback.- Trevor wants to talk about
the WebVR polyfill.- Trevor: Mozilla has been working on a polyfill for AR.
Would be good to move the repo under the W3C.- Nell: Is there any problem
from Google to move the repo to the immersive web org?- Jordan: It makes
sense to make the move but there is still not support for 2.0 (WebXR).-
David: Do we have a single polyfill repo or a webxr and webvr/carboard
one?- Trevor: There are 2 trains. The first revision with only VR and then
the new one with AR capabilities. It could be a fork or at least a
different repo.- David: It makes sense in the interim to have a single
polyfill repo where to have the shared options and where we can move the
current repo.- Brandon: Jordan and Brandon will work on how to move the
repo to the new structure.- Jordan: Will there be multiple polyfills for
multiple versions at the moment?- Brandon: Take it on a case by case basis.
Start with one and decide as needs arise (like a very AR focused one if
needed).- Update on input- Brandon: We had an input proposal and found
incompatibilities with other APIs and decided to wait until this issues are
resolved or figured out. Chrome is eager to provide WebXR to developers.
Would like not to have to sit on the API waiting. Proposal: There was an
initial simple API = point and click. It should support all the devices and
input mechanisms (including Hololens hand gesture). It should not provide
incompatibilities. The idea would be to provide just that simple
functionality as we foresee that it will be most likely future proof.-
Nell: MS is thinking on the same terms. Get the gamepad as a fallback
(although it does not have support for coordinate systems and it would need
another extension). Worried about developers getting tangled in using the
API in the wrong way. It is problematic not offering anything though.
Really eager to see what Brandon has in mind to make public.- Brandon:
Shared the same concerns.- Ada: It would be interesting to show the
potential API (even more if it can be polyfilled) and get something to
work. Devs will get excited about using it. Deprecated APIs is not the best
option.- Joshua Marinacci: Devs hate if something is abandoned with no
replacement. As long as people feel that there is a plan, they feel that
there is progress.- Nell: Let's make a proposal on this.- Brandon: Will
have something soon.- Kip: What about a higher level API even? Something
where the browser does all the heavy lifting and just provides the final
location of the collision. Something that could orthogonal.- Brandon: That
is the direction of the proposal. Something that does not provide low level
access but provides actions.- Ada: Could be tied to DOM based events
(declarative).- In the WebGL call it was brought up that instead of using
FrameBuffers as the WebXR API is proposing, if it would be better to expose
a texture array directly to WebGL 2.0 contexts. - Rafael: Brandon, does
WebGL 2.0 have everything needed to do this? Will it provide better
performance?- Brandon: Multiview comes again and again in the WebGL calls.
They’re concerned about the current plan to use an “opaque” framebuffer.
Can this be exposed using the most basic primitives possible? The problem
is that WebGL 1.0 does not provide these functionalities.- Rafael:
Multiview is optional. Once you use it, you have to use it. Once is
available devs will like to use it. The proposal now is to have a texture
array and the browser and the API to decide which to use for each eye.- One
problem with the opaque framebuffer proposal is that it doesn’t allow you
to mix multiview and non-multiview rendering. It’s all-or-nothing.-
Brandon: I am willing to drop the multiview flag with WebGL 1.0.- Some
concern about taking it that far.- Brandon: Let's take this discussion
offline.- Link to the multiview extension by the Khronos group:
https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview_multisampled_render_to_texture.txt
<https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview_multisampled_render_to_texture.txt>*

Regards,
Iker

On Tue, Jan 9, 2018 at 2:15 PM, Kearwood Kip Gilbert <kgilbert@mozilla.com>
wrote:

> I’ve taken some [redundant] notes as well from the meeting.  Copying here
> in case they are useful.
>
>
>
> 2018-01-09 WebXR Community Group Call
>
>    - Brandon (Google)
>
>
>    - meet.google.com is not ideal because it doesn't work with every
>       browser. May switch to alternative.
>       - First call of new year
>       - Ask if any vendors have updates - None, on holidays
>       - Would like to set up another immersive web repo
>
>
>    - Talked about it as an incubator / ideas repo
>          - need name. "Ideas", "incubation" , "proposed work",
>          "playground", "sandbox", "Emerging Concepts", "Work Proposals", "RFCs"
>          - Will be a place to bootstrap ideas
>          - Brandon prefers to be more along purpose of "proposals"
>          - Vote for name offline
>          - readme in repro to contain explainer of process
>
>
>    - Code of conduct for entire org would be good
>
>
>    - Maybe a separate repo, that individual repos can point to
>
>
>    - Over the christmas/new years break Brandon spent time working on
>       input proposal
>
>
>    - 30% of spec text in place.
>          - Figuring out what verbiage would come along the spec
>          - Would like feedback on how spec is shaping up.
>
>
>    - Trevor (Mozilla)
>
>
>    - WebXR Polyfill
>       - Should make repo under the w3c.org?
>       - Should split repos that convert between different versions? (1.1
>       => 2.0, 2.0 => 1.1, fallback to "cardboard", fallback to "fake webxr" etc)
>       - Should move to immersive web repo?
>       - Have a single polyfill repo?
>
>
>    - Two trains: VR and AR experimental features
>          - Fork or separate repo?
>          - Will have common code between each polyfill type, so should be
>          single repo.
>          - Consensus: Use one repo.
>
>
>    - Brandon and Jordan collaborating after call to coordinate moving
>       polyfill under immersive web repo
>       - Jordan: Branches may work well
>
>
>    - Brandon
>
>
>    - Short term input proposals
>       - Related to another API that has not yet been released, can't talk
>       too much yet
>       - Backing off on earlier input proposal until we find out what the
>       unreleased API will be
>       - Would like something short term to ship earlier with WebXR
>       - Subset of input proposal, "select" and pointing, can be used
>       earlier
>       - Allow use of "gamepad extensions" until other unreleased API is
>       finished
>       - Nell / Microsoft: Existing gamepad API extension would need to be
>       modified due to coordinate systems if used before unreleased API is ready
>       - Ada: Implement something that could be polyfilled later
>       - Joshua: Should show that API is not being abandoned, let people
>       know that there will be a future even with transition plan needed.
>       - Kip:
>
>
>    - Perhaps we can implement a higher level API that compliments rather
>          than replaces the future lower-level API
>          - 3 options:
>
>
>    - 1. Browser raycast against depth buffer from last submitted frame,
>             returns hit in the screen space coordinate system
>             - 2. Describe location of targets in the webvr API, get
>             events with target identified back, rather than specific coordinate (could
>             be vertex information or pick-buffer)
>             - 3. Add ability to display DOM elements composited with
>             WebXR scene, allow events to fire on those DOM elements using regular click
>             events
>
>
>    - Brandon likes the direction, but needs thought to determine what
>          could be done in shorter timeline
>
>
>    - Rafael
>
>
>    - Do we have everything we need from WebGL 2 for WebXR?
>       - ie. Multiview
>       - Can we maybe expose this in WebGL 2 as an actual texture array?
>       - Maybe eliminate opaque framebuffers?
>       - Once using multiview, must be used everywhere
>       - Multiview limits antialiasing
>
>
>    - Artem:https://www.khronos.org/registry/OpenGL/extensions/
>       OVR/OVR_multiview_multisampled_render_to_texture.txt
>       <https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview_multisampled_render_to_texture.txt>
>       - Proposal is that you render to your texture arrays. Specific
>       indexes would be used for left, right eyes.
>       - Support WebGL 1 with Side-by-side and require texture arrays for
>       WebGL 2?
>       - Brandon: Drop multiview for WebGL 1?
>       - Rafael: If we do WebGL 1, then do it well.
>    - Next meeting in two weeks
>
>
>
>
>
> Cheers,
>
>   Kearwood “Kip” Gilbert
>
>
>
> *From: *'Brandon Jones' via webvr-internal
> <webvr-internal@googlegroups.com>
> *Sent: *January 8, 2018 2:41 PM
> *To: *public-webvr@w3.org
> *Subject: *[webvr-internal] WebXR call agenda, Jan 9th 2018
>
>
>
> First call of the new year! We've had a long break due to the holidays, so
> I expect there will be a fair amount that people want to cover. As usual,
> please respond with any items you would like to have added to the agenda.
>
>
>
> *Call date:* Tuesday Jan 9th (and every other Tuesday thereafter)
>
> *Call time:* 1:00 PM PST for one hour
>
> ‎*Call in number:* +1 319 332 7047 <(319)%20332-7047>
>
> *PIN:* ‪9744#
>
>
>
> *Call Agenda Items:*
>
>    - Details of "Ideas" repo creation (Including name, explainer, code of
>    conduct, etc.)
>    - Progress on WebXR Device API spec
>    - WebXR polyfill
>    - Short-term input solutions
>
> As this is only the second call to use a new call-in system (Google Meet)
> we'd continue to appreciate any feedback on difficulties joining the call.
>
>
>
> Thanks!
>
> --Brandon Jones
>
> --
> You received this message because you are subscribed to the Google Groups
> "webvr-internal" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to webvr-internal+unsubscribe@googlegroups.com.
> To post to this group, send email to webvr-internal@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/webvr-internal/CAEGwwi3Xc7aJSFzt%3Dq%2BbiQM07VsAkNxHOOxSyc7uj2R8HjM
> eDA%40mail.gmail.com
> <https://groups.google.com/d/msgid/webvr-internal/CAEGwwi3Xc7aJSFzt%3Dq%2BbiQM07VsAkNxHOOxSyc7uj2R8HjMeDA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>