Meeting minutes
<yonet> start this meeting
<Manishearth> https://github.com/immersive-web/webxr-ar-module/issues/53
webxr-ar-module#53 Global environment blend mode does not work with "third eye" video capture views requested by Manishearth to discuss the general space here
Manish: Headsets have 3rd eye view separate from l/r eyes for viewing
… Issue: 3rd eye is likely to be different environment blend mode. Alpha blend vs. additive blend
<?> bialpio (~bialpio@a8a9c748.public.cloak) has joined #immersive-web
<yonet_> what is on the agenda?
Manish: Big change for color black. Ideally there would be a separate environment blend mode (EBM), but EBM is global
Brandon: No qualms, with separate EBM for 3rd eye.
<?> artem (~artem@a8a9c748.public.cloak) has joined #immersive-web
<?> alcooper (~alcooper@a8a9c748.public.cloak) has joined #immersive-web
Brandon: Wonders how this issue might surface. Not necessarily triggered by application. Some other facility wants to access
… 3rd eye
Manish: <missed>
<?> yonet (~yonet@a8a9c748.public.cloak) has quit (Ping timeout: 180 seconds)
Brandon: Introducting this capability may allow use global EBM instead of one for each "eye"
… By default force 3rd eye view to be additive
Alex: History on Hololens starting with V1. Unity & Unreal would do work to put camera, but applications/worlds in those
… systems wouldn't correctly handle it.
… Hololen V2 -- provide 3rd eye if s/w doesn't do it.
… Found that apps need to opt-in to indicate that they will handle it correctly. We do need a good fallback
… in the cases where opt-in does not happen. Recommends the default to be a reformat of the other cameras
… to create a 1st person view.
<yonet_> awk Manisheart
Manish: When first implemented, THREE started crashing -- not set up for the extra camera.
… Fundemental difference between WebXR and IW (different order of asking/requests)
… also differences between OpenXR and WebXR (perhaps previous statement was not correct)
Alex: Comfortable with WebXR tells you what's coming, but more likely to get content that doesn't work.
<Manishearth> i really like the idea of making it an optional third feature
Brandon: Likes this pattern. No negotiation currenly in place for IW. There appears to be other ways around.
… Could tag the view as being the "observer" view. That seems better that being the last one in the array.
… Does this mean that a EBM needs to be defined for each view and not necessarily global
Rik: Camera views might be on a different frame rate. What would happen to the extra or insufficient frames?
Alex: OpenXR says extra views are locked to the frame rate.
<Zakim> kip, you wanted to mention that if the content submits an alpha buffer with pre-multiplied alpha, then the fallback is inherent. Content may still need to know that black will be visible; however.
<alexturn> Here is the relevant OpenXR extension, which lists the negotiation steps done there: https://microsoft.github.io/OpenXR-MixedReality/openxr_preview/specs/openxr.html#XR_MSFT_secondary_view_configuration_preview
Kip: Might want to batch eyes together. Would it be reasonable for 3rd eye to have a pre-multiplied alpha?
… If a platform expects a 3rd eye, then could globally set EBM to pre-multiplied alpha and require alpha on the view
Manish: Liked Alex's idea as an optional feature.
… If adding to ENUM, then needs to exist in Core module (not AR)
administrivia#98 Move Layers to WG - Yonet Let's discuss if it's time to move Layers to Working Group from Community Group.
Alex: Likes alll mechanisms to be orthogonal
Rik: Progress on Layer's spec. Waiting on WebGL spec for resolving major issue
<Manishearth> +1 for moving to wg
Rik: Wants to know when the work should move from CG to WG?
Ada: OK with moving to WG.
<Zakim> ada, you wanted to ask about anchors
Mounir: Have implementation. No particular concerns about moving or not.
<alexturn> To the previous premultiplied alpha discussion: "The XR Compositor will assume the opaque framebuffer contains colors with premultiplied alpha."
<alexturn> @kip ^
Ada: Mounir mentioned that anchors are in the wild, but not WG
Mounir: [same response], willing to go to WG
<kip> @alexturn That sounds ideal, IMHO
Ada: Please create issue to agenda item for WG meeting next week
Aysegul: Will vote. This was the announc,ment. Vote to taken via email
Next Topic
<Manishearth> https://github.com/immersive-web/webxr/pull/1068
<Manishearth> https://github.com/immersive-web/webxr/pull/1070
Manish: PRs 1068 & 1070, deal with Poses & reference spaces. These are competing resolutions
Brandon: Prefers 1070, especially in context of Chrome
Brandon: Does not seem resolvable in GitHub issues. Would like a straw poll to determine if 1070 is a bad (or at least not good) approach
Mounir: Wants to see discussion in GitHub
<?> dom (dom@9487a751.team.cloak) has quit (Ping timeout: 180 seconds)
Manish: Editors need to start merging the requests. Will do so via GitHub
Brandon: [next agenda item] This is a long-standing issue (~1.5 yrs ago).
… Have an algorithm that takes all updates for next frame. There is timing sensitivity. Surprised if any
… applications depending on exact timing. To better work with multi-process apps, the state for the next frame
… happens at the conclusion of the previous frame.
… Are there any concerns (particularly if not good)? If none, then writes some PRs to handle that change.
<mounir> I need to go early to make coffee before my next meeting -- thank you for chairing yonet_
Rafael: Does this proposal effect when render state gets update other than the RAF?
<Manishearth> yonet_ cwilso: note to chairs, the next agenda item isn't actually on this week's agenda, it seems to have stuck from last week. we resolved it, so the current agenda item is the last for today
<cwilso> thanks manish
<yonet_> thanks chris
Brandon: Not exactly. It can be worked out. Basic idea is to move line in algorithm from top to bottom of RAF loop.
… state changes would be on a 1-frame delay.
Rafael: Don't want to make things awkward for UA.
Alan Jeffery: Easiest change is to schedule a task to put things at the end
Brandon: <detailed technical discussion of render states, rate of change, etc. and what happens to a
… missed/unrendered RAF with Brandon and Alan.]
… Feels that a reasonable solution could be written. See PRs for results
Manish: Lifecycle of things in the render state is different -- clip planes, layers, etc.
Brandon: Agrees. There are a number of technical issues that need to be resolved prior to including in the spec.
… Will look at writing PR with Alan, then present to CG
Aysegul: Concludes topics -- returning 5 minutes to people