Re: WebXR call agenda, May 29th 2018

Thanks Kip! The notes are highly appreciated!

On Tue, May 29, 2018 at 1:57 PM Kip Gilbert <kgilbert@mozilla.com> wrote:

> FYI - Minutes from the TAG call are located here:
>
>
> https://github.com/w3ctag/meetings/blob/gh-pages/2018/telcons/05-29-minutes.md
>
> Cheers,
>  - Kip
>
>
> On May 29, 2018, at 1:56 PM, Kip Gilbert <kgilbert@mozilla.com> wrote:
>
> I took some notes from this call.  Please advise if I missed anything...
>
> Kip:
>
>    - Gave re-cap of TAG call earlier in the day
>
> Brandon:
>
>    - Any announcements to bring up with the rest of the group?
>    - [No announcements]
>
>
>    - Agenda items are a bunch of pull requests
>    - Trying to get through a backlog of issues
>    - Brandon has been triaging issues
>    - 101 -> 55 issues :-)
>    - One more thing - Managed to close down the oldest bug in the repo,
>    by configuring travis to deploy the updated html when pushing to bikeshed!
>    - Now we don’t have to worry about massive diffs in the html file.
>    - On to the pull requests…
>
>
> *Renamed pointerOrigin and enum values to reflect usage pattern, not
> device type. (**#342* <https://github.com/immersive-web/webxr/pull/342>*)*
>
>    - Not changing too much
>
> Lewis:
>
>    - Origin pull request has functional authorizations, backed out.  Now
>    using a matrix rather than individual vectors
>    - Now just a terminology change
>
> Brandon:
>
>    - Now accommodates hololens better.  Do have a hand, but is a gaze
>    pointer on hololens
>    - Happy with where pull request is now
>    - Anyone have concerns
>
> Trevor:
>
>    - No problems here
>
> Brandon:
>
>    - Merged!
>
>
> *Created an explicit XRRay type (**#357*
> <https://github.com/immersive-web/webxr/pull/357>*)*
> Brandon:
>
>    - Primarily pull request that I’ve got includes a vector3 type.
>    - Appropriate in this case for a couple of reasons
>    - Primarily looking forward and would like this type to serve as input
>    for hit testing in the future
>    - Ensure that datatype has some basic guarantees - Can normalize it,
>    always guarantee returns a normalized direction, can throw on assign with
>    zero length vector
>    - Alternative would have been to use a DOMPoint.  Work in progress
>    spec, and would be 4 component.
>    - Alternative could also be to split out members for each component
>    (awkward)
>    - Hope to leave it as nothing but a storage type.  Don’t expect to
>    attach math operators
>
>
> Kip:
>
>    - What would the evolution be..  Arrays of the types or a type called
>    “Vector3Array”.  What about matrices?
>
>
> Brandon:
>
>    - Reluctant to introduce mathematical operations to deal with these
>    types specifically
>    - Don’t want to become the defacto lib for this on the web.  Difficult
>    to do effectively.
>    - For matrices not quite as necessary.
>    - I have a transform matrix getter mostly as a developer convenience.
>    This can be implemented as a lasy getter without worrying about the
>    components being modified later.  WebGL takes these as arrays.
>
>
> Kip:
>
>    - I agree with this, but want to pre-empt the inevitable questions
>    about why Vector3 and not others
>    - Brandon:
>    - Would be a good addition to the explainer
>
>
> Brandon:
>
>    - Please add any comments before merged.
>
>
> *Specify timing/behavior of the resetpose event (**#358*
> <https://github.com/immersive-web/webxr/pull/358>*)*
> Alex:
>
>    - Clarify what resetPose means.
>    - Is it good/okay for this to be platform specific or should be unify
>    to the extent we can
>    - Some platforms have system recenter behaviour, and should re-surface
>    that
>    - Do we want to take a stronger stance in WebXR on how the stage
>    responds?
>    - Windows MR allows some variation
>
> Brandon:
>
>    - Good point, worth considering
>    - Difficult to see as things stand right now and feel confident that
>    we could successfully enumerate all off those.
>    - Likely to be platform specific behaviour
>    - Worth enumerating what applications do in response to something like
>    this.  In reality the behaviour is absolutely nothing.  Users are used to
>    what is expected from the platform.
>    - Probably some worthwhile patterns.
>    - It’s reasonable for applications to make these kinds of adjustments
>    during a reset.
>
>
> Kip:
>
>    - Content may need to know that motion was due to reset and adjust
>    physics / gameplay to accommodate.
>
>
> *Add text explaining the depth range values. (**#359*
> <https://github.com/immersive-web/webxr/pull/359>*)*
> Brandon:
>
>    - Explaining the meaning of depth near and far
>    - Nell and Kip have given approval.
>    - Can we merge?
>    - Someone might have concern about when changes to the depth value
>    take effect (eg, next frame, timing concerns).
>
> Kip:
>
>    - Firefox depth values take effect on the next frame.
>    - Can we normalize across platforms?
>
> Brandon:
>
>    - Is it reasonable to have language such as “the next frame” on
>    platforms that may be more asynchronous.
>    - May need more infrastructure around this, such as a function that
>    returns a promise.
>    - Any Microsoft folks have some feedback
>
> Yashar:
>
>    - Need a little more time.
>
>
> *Clarified when exclusive sessions are rejected (**#360*
> <https://github.com/immersive-web/webxr/pull/360>*)*
> Brandon
>
>    - Had a conversation on a previous call
>    - Raphael said if there is an outstanding request, new ones should
>    reject
>    - This text formalizes that
>    - Nell has a comment about blocking.
>
> Yashar:
>
>    - There will be some feedback from Microsoft
>
>
> *Removed multiview attribute from XRWebGLLayer (**#361*
> <https://github.com/immersive-web/webxr/pull/361>*)*
> Brandon
>
>    - Simple pull request with wider implications
>    - Not clear that multiview functionality on WebGLLayer is a tractable
>    approach.
>    - This reviews multi view boolean from creation and attributes
>    - Also pushed a branch with a commit that goes further with if we want
>    to introduce multi view back as a texture array mechanism, this is how it
>    would look.
>    - Two issues - “No multi view can’t be a thing”, “Does anybody A. Have
>    comments about the outline on how we could pursue it in the future, B. Does
>    anybody feel like multi view really absolutely be a minimum viable product
>    for V1”
>
> Artem:
>
>    - My problem is that multi view is already not very user friendly,
>    requiring a lot of changes in your existing code
>    - Just to adopt WebGL already need to change vertex shaders, then also
>    need to add a ton of code to create the texture arrays and such.  Problem
>    is that the approach complicates things.  Adoption of multi view may not be
>    great.
>
> Brandon
>
>    - Would like two see this adopted in as many places as possible
>    - Multiview is not available on as much hardware as one would expect
>    due to driver vendors.
>    - Native implementations require texture arrays
>    - Question wisdom of papering over the feature capabilities in the
>    underlying platform.
>    - Concerned about no matter what you do, there’s going to be a certain
>    amount of shader changes that are needed to take advantage of this.  It
>    would be great if we could get everyone to do it from the beginning, but if
>    the requirement is that they have to change all of the shaders to make it
>    work with multi view, then people would never bother with multiview at
>    all.  If exposing multi view on top of WebGL 1 path, then can’t
>    interoperate with modules from 3rd parties such as particle libraries.
>
> Artem:
>
>    - Threejs is WebGL 1
>
> Brandon
>
>    - WebGL 2 is WIP for threejs.
>    - Would lead to one or nothing.
>
> Kip
>
>    - Work to implement multi view is similar to work needed to port to
>    WebGL 2, so maybe not too bad to just support in WebGL 2 without
>    compromise.  Do what’s best in WebGL 2.
>
> Brandon
>
>    - Look forward to more comments on PR
>    - End of agenda items.  Anyone have something else to bring up in last
>    few minutes?
>    - Thanks for joining call - AR call next week.
>
>
> — end —
>
> On May 26, 2018, at 12:12 PM, Brandon Jones <bajones@google.com> wrote:
>
> Sending the agenda out early this week because Monday is a US holiday and
> if I wait till then I'm certain to forget to send one. And that would be
> bad, because we've got a ton of pull requests to cover this week!
>
> *Call Agenda Items:*
>
>    - Renamed pointerOrigin and enum values to reflect usage pattern, not
>    device type. (#342 <https://github.com/immersive-web/webxr/pull/342>)
>    - Created an explicit XRRay type (#357
>    <https://github.com/immersive-web/webxr/pull/357>)
>    - Specify timing/behavior of the resetpose event (#358
>    <https://github.com/immersive-web/webxr/pull/358>)
>    - Add text explaining the depth range values. (#359
>    <https://github.com/immersive-web/webxr/pull/359>)
>    - Clarified when exclusive sessions are rejected (#360
>    <https://github.com/immersive-web/webxr/pull/360>)
>    - Removed multiview attribute from XRWebGLLayer (#361
>    <https://github.com/immersive-web/webxr/pull/361>)
>
> Please reply with any additional items you'd like to see addressed.
>
> *Call date:* Tuesday, May 29th (and every other Tuesday thereafter)
> *Call time:* 1:00 PM PST for one hour
>
> WebEx call details are posted to the internal-webvr@w3.org mailing list,
> accessible to any community group member.
>
>
>
>