Re: WebXR call agenda, May 29th 2018

FYI - Minutes from the TAG call are located here:

https://github.com/w3ctag/meetings/blob/gh-pages/2018/telcons/05-29-minutes.md <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 <mailto: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 <mailto:internal-webvr@w3.org> mailing list, accessible to any community group member.
>> 
>