16:38:17 <RRSAgent> RRSAgent has joined #immersive-web
16:38:21 <RRSAgent> logging to https://www.w3.org/2024/03/25-immersive-web-irc
16:38:22 <marisha> marisha has joined #immersive-web
16:38:24 <cwilso> present+
16:39:59 <cwilso> present+ Lazlo Gombas, Javier Fernandez, Alex Cooper, Atsushi Shimono, Brandon Jones, Piotr Bialecki, Rik Cabanier
16:42:00 <mblix> mblix has joined #immersive-web
16:42:32 <yonet> yonet has joined #immersive-web
16:42:46 <marisha> present+
16:42:52 <lgombos> present+ Laszlo_Gombos
16:50:35 <yonet> present+
16:58:09 <Brandel> Brandel has joined #immersive-web
17:00:57 <bajones> bajones has joined #Immersive-Web
17:01:05 <bajones> present+
17:01:21 <etienne_> present+
17:01:22 <bialpio> bialpio has joined #immersive-web
17:01:46 <alcooper> present+
17:01:50 <bialpio> present+
17:01:52 <nick-niantic> nick-niantic has joined #immersive-web
17:01:58 <Brandel> present+
17:02:01 <atsushi> meeting: Immersivw-Web WG/CG f2f 2024/03 Day 1
17:02:11 <cwilso> IRC instruction manual : https://github.com/immersive-web/administrivia/blob/main/IRC.md
17:03:04 <marisha> Guide on Scribing: https://w3c.github.io/scribe2/scribedoc.html
17:03:51 <yonet> agenda: https://github.com/immersive-web/administrivia/blob/main/F2F-March-2024/schedule.md
17:04:30 <cwilso> zakim, this is Immersive Web
17:04:30 <Zakim> got it, cwilso
17:04:34 <atsushi> rrsagent, this meeting spans midnight
17:04:34 <cwilso> zakim, start meeting
17:04:35 <Zakim> RRSAgent, make logs Public
17:04:36 <Zakim> please title this meeting ("meeting: ..."), cwilso
17:04:47 <giorgio> giorgio has joined #immersive-web
17:04:57 <cwilso> meeting: Immersive Web March 2024 FTF
17:05:01 <cwilso> zakim, start meeting
17:05:01 <Zakim> RRSAgent, make logs Public
17:05:02 <Zakim> please title this meeting ("meeting: ..."), cwilso
17:05:06 <Brett_> Brett_ has joined #immersive-web
17:05:34 <mblix> mblix has joined #immersive-web
17:05:36 <marisha> Scribe: marisha
17:05:42 <yonet> item: https://github.com/immersive-web/webxr/issues/1365
17:06:07 <atsushi> topic: Give developers control over "overlay" browser (webxr#1365)
17:06:14 <atsushi> rrsagent, publish minutes
17:06:16 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/25-immersive-web-minutes.html atsushi
17:07:03 <ada> present+
17:07:04 <Brett_> hello laszlo
17:08:04 <Omegahed> Omegahed has joined #immersive-web
17:08:09 <Brett_> :wave:
17:08:12 <giorgio> no video from room also here
17:08:58 <Brett_> present+
17:09:09 <Omegahed> present+
17:09:11 <nick-niantic> present+
17:09:14 <mblix> present+
17:10:30 <jfernandez> present+
17:11:21 <giorgio> Nice to see you guys! ;-)
17:11:43 <Mats_Lundgren> Mats_Lundgren has joined #immersive-web
17:15:11 <Phu> Phu has joined #immersive-web
17:18:06 <ada> https://github.com/immersive-web/webxr/issues/1365
17:18:33 <marisha> cabanier: A little while ago the Quest Browser released a feature where if you click the Quest button, instead of a plain overlay, we bring up the 2D browser
17:18:52 <marisha> cabanier: We keep the visual blurred so the developers can change what's in the 2D experience
17:18:59 <marisha> cabanier: Or could change the settings of your WebXR experience
17:19:08 <marisha> cabanier: We got many requests to trigger and exit this manually
17:19:39 <marisha> cabanier: Right now the only way is to hit the Quest button and exit by clicking Resume. Right now we are the only ones with this feature, but we think it's a good feature and could be done by other manufacturers
17:20:05 <marisha> cabanier: There could be an API to call this at any time. The 'resume' API should probably be user-activated
17:20:09 <ada> q+ to ask about DOMOverlay
17:20:19 <Brandel> q+
17:20:31 <nick-niantic> q+
17:20:36 <marisha> cabanier: We got lots of feedback that devs want to control this
17:20:39 <ada> ack ada
17:20:39 <Zakim> ada, you wanted to ask about DOMOverlay
17:20:42 <Brett_> q+
17:20:42 <bajones> q+ to ask about potential for pages to grief users
17:20:56 <marisha> ada: It's a cool idea and it seems like this would be a good fit for DOM overlay
17:20:57 <Brett_> q+ to fully flesh out this idea for HTML support in WebXR
17:21:21 <marisha> ada: Some DOM overlay wouldn't make sense like 'what does fullscreen' mean, but you're just showing the full browser window
17:21:45 <marisha> ada: The bit that developers could trigger and bring up might be more interesting if it was with the DOM overlay API where they could more fully customize it
17:22:08 <marisha> cabanier: Right now it's not just the page but the full Brorwser navigation , refresh button, address bar, etc
17:22:27 <alcooper> q+
17:22:36 <marisha> cabanier: DOM overlay takes an element, makes it fullscreen, not sure how this would work
17:22:54 <marisha> ada: You could take the full window, wouldn't need the Browser chrome
17:22:58 <ada> q?
17:23:00 <marisha> cabanier: I think that would break a lot of assumptions for pages
17:23:31 <marisha> cabanier: Maybe something like a DOM overlay for when devs want to trigger it
17:23:45 <bialpio> q+
17:23:54 <marisha> q+
17:23:58 <ada> ack Brandel
17:24:19 <marisha> Brandel: Right now you're sending visible: blurred and only head placement is updated
17:24:28 <marisha> Brandel: seems like it's straying from what visible:blurred was for
17:24:38 <marisha> cabanier: No we alwasy had this overlay screen
17:25:06 <marisha> Brandel: But that was meant to have WebXR in a frozen state. But now indirectly you have a way to react in the WebXR session via the 2D page
17:25:17 <marisha> Brandel: So it's not at the same scope as visible: blurred
17:25:29 <marisha> cabanier: visible:blurred just indicates you don't have controls any more, only head pose
17:25:57 <marisha> Brandel: My question is more about whether that's all that we want to vend. What do we expect to come through vs not come through?
17:26:06 <marisha> Brandel: visible:blurred was not going to update the world for any reason before
17:26:42 <marisha> Brandel: My main question is whether this is adequately descriptive of what it is and what it's for
17:27:12 <marisha> bajones: visible:blurred means that something else is taking input right now but page content is still visible and can still do head tracking. Tracking could be at a lower rate
17:27:35 <marisha> bajones: The intent of that state is: you can still see the world, but none of the inputs
17:28:05 <marisha> Brandel: For cases of audio, keyboard, and DOM events, you wouldn't lose anything by virtue of being in overlay
17:28:27 <marisha> cabanier: You're right in that mode, keyboard events would start working again
17:29:27 <marisha> Brandel: Any set of events that are expected in WebXR vs 2D is what is the concern
17:29:30 <ada> ack nick-niantic
17:30:05 <marisha> nick-niantic: How does this work today, and how could it work in ways that are more beneficial? When you go into this mode, where does the Browser show and where does the 3D content show?
17:30:34 <marisha> cabanier: Browser is on top, right in front of the user
17:30:41 <marisha> Brandel: I beleive it's in whatever position it previously was
17:31:13 <marisha> nick-niantic: So the Browser is not occluded by anything in the scene. If I had a scene with a car in it, with a car's color, I could bring up this window and click a button to immediately update the color of the car?
17:31:14 <marisha> cabanier: yes
17:31:50 <marisha> nick-niantic: This sounds like what we were asking for with DOM layers a while back except for a combination of being in a fixed position, or when the browser could always be open, but then you'd need to be able to get it out of your way
17:32:25 <marisha> nick-niantic: But not doing depth-testing with the scene also is a little bit undesirable, if something was in front of that browser window you could move it out of the way
17:32:35 <marisha> cabanier: I don't think there's anything stopping us from placing the browser where they want it
17:32:40 <Phu> q+
17:32:51 <marisha> Brandel: The user can put the window wherever they want
17:32:59 <marisha> cabanier: I think nick wants it programmatically
17:33:33 <marisha> nick-niantic: Even programmatically is tricky, trying to find a placement for it. We also allow the user to move it around and it can follow your head around
17:33:52 <marisha> nick-niantic: A system to manage that automatically would be okay, but having it be embedded in the scene and movable
17:34:28 <marisha> nick-niantic: Being able to do things like press a button on your wrist to make it appear and disappear would be desirable
17:34:47 <marisha> nick-niantic: We would want it to be interactable with the rest of the scene
17:35:12 <marisha> ada: Something like that would work on Vision Pro quite well if you don't have hand tracking requested, because we have transient pointers
17:35:21 <marisha> ada: If you were to target the DOM content, you could just not bubble it up to the WebXR content
17:35:34 <marisha> Brandel: The only reason it would work with Vision Pro is because it wouldn't work with Meta
17:36:12 <marisha> Brandel: When you have the ability to track user inputs to a webpage, it exposes serious security issues (like watching someone put input into a banking website)
17:37:16 <marisha> nick-niantic: Today if I have a webpage and I have an iframe, that would be an external source
17:39:01 <marisha> Brett_: You could just have the input disappear when user inputs over an iframe
17:39:07 <marisha> bajones: Yes but that would be weird
17:39:26 <marisha> ada: You could re-implement something like transient-pointer in order to make this work
17:39:53 <marisha> ada: I think everyone wants a way to get DOM into the web. this seems like the closest approach so far.
17:40:19 <marisha> cabanier: You also want occlusion and depth-sorting? That would be pretty difficult and expensive
17:40:48 <marisha> cabanier: I think the OS supports it but you have to resolve depth for every frame
17:41:01 <ada> ack Brett_
17:41:01 <Zakim> Brett_, you wanted to fully flesh out this idea for HTML support in WebXR
17:41:03 <marisha> Brandel: Regarding trust and safety, we also don't want to the Browser chrome to be obscured
17:41:15 <bialpio> q-
17:41:26 <marisha> Brett_: I want to be able to use HTML in VR and position it. The one thing holding it back right now is security. We can't have a cursor here because it could be an iframe
17:41:41 <marisha> Brett_: We could have a security policy with shared array buffers to not include iframes from cross-origin domains
17:41:54 <marisha> Brett_: It would allow us to start experimenting with DOM overlay in a safe environment
17:41:57 <Brandel> q?
17:42:14 <marisha> cabanier: I think there is a proposal here. The HTML would have to come from its own document
17:42:37 <marisha> bajones: In general the conclusion with this group is that when we get ot a point where we can start doing that, this is very likely going to be a restriction set in place
17:42:54 <marisha> bajones: There are other technical issues around it. But in general I think we're in agreement that that is the safest way to start pushing into that space
17:43:13 <marisha> cabanier: Every DOM layer would be its own document with the same origin
17:43:45 <marisha> Brett_: Right now you can only have one WebXR session but you could maybe later have two WebXR sessions overlayed on each other
17:44:48 <marisha> cabanier: In the overlay Browser you have to block all input
17:44:56 <marisha> Brett_: But what about a scenario where you don't blur everything
17:45:12 <marisha> bajones: Overlay browser is the topic of discussion currently
17:45:49 <marisha> bajones: for DOM layers that is DOM content in the world, while you retain input in the XR session, I think is desirable and everyone recognizes how powerful that could be.
17:46:50 <marisha> bajones: Interaction with the DOM layer gets tricky, if the developer has their own cursor pointer (like from a gun), then it diverges frmo the cursor pointer that interacts with the DOM layer
17:47:07 <marisha> Brandel: WebXR need not be the only pathway to spatial content on the internet
17:47:28 <marisha> Brett_: But the only way to use HTML content in VR.. how to do that
17:47:28 <ada> ack bajones
17:47:28 <Zakim> bajones, you wanted to ask about potential for pages to grief users
17:47:38 <marisha> bajones: There would be many ways
17:48:30 <marisha> bajones: One of the things that came to mind about the gesture to pull up the Browser overlay: if I'm pulling up the Browser while in the session, it's probably because I want the user to do something within the session, rather than allowing them to run away
17:48:45 <Brett_> q+ browsering 2 buttons
17:49:09 <marisha> bajones: This seems like an opportunity to grief the user if I don't let the user do the thing they want to do, if a gesture works
17:49:49 <marisha> bajones: You could trick the user into never triggering the actual system gesture
17:50:09 <marisha> bajones: You need a way to mitigate that, and it also implies the version of the Browser that I bring up programmatically should also have some sort of visible difference to the typical browser
17:50:26 <marisha> bajones: Maybe it doesn't ahve a tab bar, an abbreviated chrome (it feels slightly less useful that way)
17:51:06 <marisha> bajones: If you're going to allow positioning of teh window programmatically - it feels like a bad idea, you don't want to allow them to hide it behind the user's head or run away from their hand
17:51:25 <ada> zakim, close the queue
17:51:25 <Zakim> ok, ada, the speaker queue is closed
17:51:27 <marisha> bajones: But the ability to hint ot the Browser that "this might be a good place for content" to spawn the Browser there optionally
17:51:59 <marisha> bajones: I'm more concerned about the griefing scenarios where devs would deny users access to the real browser
17:52:31 <marisha> bajones: This goes back to the API where there's a gesture to always reliably open the Browser
17:53:26 <marisha> bajones: In order to fake the system gesture for this, it's a huge ordeal. With a programmatic gesture, you are invited to generate and dismiss this object
17:53:46 <marisha> bajones: If you have a trigger but not a resume gesture, the concern is quite a bit less
17:54:18 <marisha> cabanier: The proposal is to require user action to resume the WebXR session
17:54:50 <marisha> bajones: Clicking the 'resume' button is not propagated to the page?
17:54:52 <marisha> cabanier: It is not
17:55:34 <marisha> Brandel: Are the select/click actions trusted in the XR environment?
17:55:42 <marisha> cabanier: I'm not sure
17:56:00 <marisha> ada: Wasn't the point of 'select' to have a trusted event in WebXR?
17:56:27 <marisha> bajones: That was the intention for the event. You also have to initialize the session in the context of a trusted event
17:56:35 <Brandel> q?/
17:56:39 <marisha> q-
17:57:30 <marisha> bajones: If the user can trigger something and it not be closed arbitrarily, it seems like it should be the full browser
17:58:11 <marisha> bajones: You said you don't need a user activation to call this API. Would it be sufficient to require that but initially open into this mode?
17:58:58 <ada> ack alcooper
17:59:33 <marisha> alcooper: You mentioned a user case to direct devs to a separate site for payment - why do devs want a separate site rather than showing their own content - is directing to a separate 2D page also spoofable?
17:59:55 <marisha> alcooper: If the developer can guess what your browser looks like an pretend it
18:00:01 <Brandel> q?
18:00:19 <marisha> Brett_: What about one gesture to open the full browser and another button to open a partial web view (same dom origin)
18:00:34 <marisha> alcooper: That sounds like what we were discussing as a separate thing and why you'd want to pull up the full browser
18:01:02 <marisha> alcooper: Maybe for payments there would be a separate API for trusted scenarios
18:01:07 <ada> ack Phu
18:01:15 <marisha> cabanier: I agree it's a concern, maybe multiple tabs should not be available..
18:02:01 <marisha> Phu: So bringing it up with the user action (not programmatic event) - what are scenarios where people will bring up the Browser without leaving the WebXR session?
18:02:11 <marisha> cabanier: Right now they don't have a choice, the browser just comes up automatically
18:02:48 <marisha> Phu: Bringing up the browser only partially solves the problem that DOM overlay would try to solve. Doing it programmatically sounds additionally useful
18:03:27 <marisha> Phu: But there is the spoofable concern. Today a webpage can declare whether a webpage can appear in an iframe or not. Maybe we update the contract to allow communication for other modes (webxr)
18:03:44 <marisha> cabanier: That sounds like a whole new paradigm for the browser
18:04:10 <marisha> Phu: The website could declare their preferences or declare their trusted origins
18:04:45 <marisha> alcooper: Tehre might be permission policy stuff that might allow that today. But this is in reverse of that almost
18:05:11 <marisha> Phu: Could at least enable it in developer mode or something so people could validate the scenario
18:05:30 <marisha> Phu: Everyone who uses our SDK asks for a way to embed web content
18:06:19 <ada> zakim, open the queue
18:06:19 <Zakim> ok, ada, the speaker queue is open
18:06:29 <marisha> Scribe: Brandel
18:06:29 <ada> https://github.com/immersive-web/webxr/issues/1364
18:08:07 <Brandel> ada: Now we have several stand-alone webXR device, the original metaphor for how webXR was devised isn't how we're running them. We don't seem to have broad agreement about what is and is not running in this new model
18:08:34 <alcooper> q+
18:08:35 <Brandel> ada: e.g. video, getUserMedia, various animation events etc,
18:09:18 <idris> idris has joined #immersive-web
18:09:28 <cabanier> q+
18:09:31 <atsushi> i|https://github.com/immersive-web/webxr/issues/1364|topic: Backgrounded Tabs and WebXR (webxr#1364)
18:09:35 <Brandel> ada: My issue posits three buckets for definite yes, definite no and some "maybes" for things we could gain some benefit from but we should discuss them here!
18:09:42 <yonet> ack alcooper
18:10:32 <Brandel> alcooper: we ran into this even on desktop VR. the 2D window 'lost focus', resulting in some input shenanigans. We need to find clarity on this.
18:10:56 <Brandel> alcooper: one question is power consumption - what are people permitted to shut down vs. what is obligatory for the session
18:11:06 <yonet> ack cabanier
18:11:13 <mblix> q+
18:11:39 <Brandel> cabanier: I would expect there to be a difference between minimizing a browser to tab-switching to entering an XR session
18:12:18 <Brandel> ada: I had asked for the page's rAF but grudgingly accept the importance of suspending it
18:13:06 <Brandel> cabanier: WebApps may provide an overall listing of which capabilities are available within a minimized or an inactive tab, but it may be down to the individual feature
18:14:24 <Brandel> Brandel: I'm aware that the initial treatment of audiocontext, we suspended the context on session start.
18:14:51 <Brandel> cabanier: We should defer to the logic of the 'hidden state' API for individual features rather than attempt to collect or mandate the status of features on our own
18:15:35 <Brandel> Phu: Working on those features one-by-one in/for webXR is messy, and should be left to the feature owners there
18:15:42 <bajones> q+ to say that we do reference the page visibility state in the spece
18:16:12 <Brandel> ada: Should we seek these people out to clarify the behavior is and discuss the best resolution for these?
18:16:34 <yonet> ack mblix
18:16:38 <Brandel> alcooper: I would need to go code spelunking in order to find the relevant owners and discuss the right action
18:17:32 <Brandel> mblix: We have been talking about this from the spec perspective - are there alternatives like performance, to assess the relative costs of enabling various features like window.rAF?
18:17:57 <Brandel> cabanier: we have looked at this in the past, and a lot of people run exorbitantly expensive ads that would negatively affect webXR performance etc.
18:18:18 <Brandel> mblix: could we pursue the optional enablement of various features on the basis of explicit page intent?
18:18:27 <Brandel> cabanier:  that seems reasonable
18:19:09 <Brandel> cabanier: This would be difficult to polyfill across different devices and vendors, given the hard boundaries for capability.
18:19:23 <yonet> ack bajones
18:19:23 <Zakim> bajones, you wanted to say that we do reference the page visibility state in the spece
18:19:26 <bajones> https://immersive-web.github.io/webxr/#ref-for-visibilitystate-attribute
18:19:46 <Brandel> ada: It's *not* something we can likely polyfill, we would probably need to return the success or failure in the features request for the session.
18:20:34 <Brandel> bajones: We do mention the visibility state in an `inline` session description, It's likely we can do something more useful - even if it's non-normative language describing this.
18:21:16 <Brandel> bajones: I've been spelunking through similar APIs to look for precedent, and found FullScreen and Picture-in-picture. There is scant mention of anything useful for our purposes.
18:21:25 <Brett_> q+ In theory, full user control is ideal?
18:21:40 <yonet> ack Brett_
18:22:32 <Brandel> Brett_: Could we have a range of user-configurable capabilities to control this? Ideally both developer- and user-facing capabilities to configure?
18:22:57 <Brandel> bajones: I would recommend against granularity exposed to the user, given the level of legibility those options necessarily entail. I'm concerned people won't understand this.
18:23:43 <Brandel> bajones: What does this enable for the user beyond what reasonable defaults furnish for them?
18:23:56 <ada> q?
18:35:46 <m-alkalbani> m-alkalbani has joined #immersive-web
18:41:05 <etienne> etienne has joined #immersive-web
18:41:37 <bialpio> q?
18:46:13 <yonet> yonet has joined #immersive-web
18:46:18 <yonet> Topic: https://github.com/immersive-web/webxr/issues/1360
18:52:21 <ada> q?
18:52:24 <ada> zakim, open the queue
18:52:24 <Zakim> ok, ada, the speaker queue is open
18:52:59 <marisha> marisha has joined #immersive-web
18:53:05 <atsushi> s|https://github.com/immersive-web/webxr/issues/1360|Indicate "preferred" immersive mode (webxr#1360 -> https://github.com/immersive-web/webxr/issues/1360 )
18:53:23 <yonet> q+
18:53:58 <bajones> q+
18:54:00 <ada> q+
18:54:01 <Brandel> cabanier: I propose this because it is simliar to an openXR API. If a user is already in pass-through, maybe we should allow users to remain in pass-through. Likewise, devices that support AR and VR but _prefer_ VR, it might be useful to hint to the user that the device will do better with a given mode.
18:54:33 <bialpio> q+
18:54:39 <ada> ack yonet
18:54:43 <Brandel> cabanier: I'm not sure of the scope of additional information disclosure, but it seems like it's only a little. The API would indicate what is preferred, but wouldn't enforce it.
18:54:43 <idris> q+
18:55:36 <Brandel> yonet: Generally I undestand developers to be explicitly developing _for_ AR or VR. How does this work for them?
18:56:04 <Brandel> cabanier: you will be able to return the mode that is preferred from the developer's side.
18:57:03 <Brandel> cabanier: a requested AR session would still be an AR session, likewise with VR - this is more about the capacity to provide continuity. Developers could still tailor for individual devices
18:57:37 <Brandel> cabanier: This is about the _device_ providing the indication of preferred mode, rather than the content or the user.
18:58:22 <Brandel> cabanier: The system could let the user decide, but it would be a system indication. A developer could still launch what's available
18:58:32 <ada> ack bajones
18:58:51 <Brett_> +q your plan with quest is to switch this flag when in pass-through and web in home?
18:59:13 <Brandel> bajones: There is a long list of people who care a lot about a very little amount of information, so any exposure is something we need to be wary of
19:00:31 <Brandel> bajones: especially in concert with other browser signals, this serves to flesh out even more contextual information about exactly what the user is experiencing. I'm not personally overly concerned myself, but other people are,
19:01:35 <Brandel> bajones: I echo yonet 's thoughts about nudging users and authors towards a specific (and potentially more disclosing) context for interaction, which is both unfornuate and _primarily_ a library problem
19:01:45 <nick-niantic> q+
19:01:47 <Brandel> bajones: though realistically, people do stupid things.
19:02:17 <Brandel> bajones: User preferences could provide a way to override information like this
19:02:42 <ada> qack ada
19:02:46 <ada> ack ada
19:02:51 <Brandel> bajones: particularly remembering preferences could make this less frustrating
19:03:08 <bialpio> q-
19:03:20 <alcooper> q+
19:03:37 <Brandel> ada: if this could be requested along with a session rather than in `isSessionSupported`, it could be more frictionless - given that it's mainly about a preference but not a required capability.
19:04:34 <Brandel> ada: gating the time at which the information is vended also reduces the scope of how it can be integrated into general information-gathering as well
19:05:22 <bajones> q+ to say that I like Ada's proposal
19:05:36 <Brandel> ada: whether frameworks would care to honor this information depends on them - but the basic presence of "supports preferred" might be enough on the isSessionSupported
19:06:13 <Brandel> bajones: Most of the time, the main thing that distinguishes an AR session from a VR one is that the AR simply loads and displays _less_
19:06:34 <ada> ack idris
19:06:37 <bajones> q-
19:07:17 <Brandel> idris: this seems like a good proposal, but the preferences should lie primarily with the developer's awareness of the experience rather than the user's
19:07:48 <ada> q+
19:08:18 <ada> ack nick-niantic
19:08:18 <Brandel> idris: the user should have ability to agree or disagree to a given set of arrangements, but it's on the developer to decide what to offer
19:08:50 <cabanier> q+
19:08:58 <ada> ack alcooper
19:09:27 <Brandel> nick-niantic: the uncertainty of not knowing what's going to be entered might imperil the load-status of everything required for the session, but it's not a big deal
19:09:44 <ada> ack ada
19:10:40 <alcooper> q+
19:11:20 <Brandel> ada: given that invoking a session requires a prompt anyway, `preferred-vr` and `preferred-ar` both going into the session would just defer the decision to another moment unless we specify a default
19:11:42 <ada> ack cabanier
19:11:44 <bajones> q+
19:12:15 <Brandel> ada: this would probably only cater to people who have the ability to construct the absolute best experience possible across all capabilities
19:12:28 <bialpio> q+
19:12:59 <Brandel> cabanier: generally, AR sessions request many more features than VR. AR wants hit-testing, lighting estimation, world geometry - where VR often only needs local-floor etc.
19:13:34 <Brandel> cabanier: that kind of thing results in additional overhead, given the per-frame computations required for some of them. That becomes expensive if it's not essential and by design for the experience
19:13:52 <ada> ack bajones
19:14:30 <Brandel> bajones: we could say if you use 'sessionPreferred' you can only use optional features, but that doesn't feel great.
19:15:51 <Brandel> bajones: I am trying to figure out the circumstances under which you might decide between AR and VR based on the knowledge that one is _more_ preferred? Ultimately, I think an author is going to be highly opinionated
19:16:05 <ada> q+ to say what's your preferred? incorect your getting vr instead
19:16:21 <cabanier> q+
19:16:33 <Brandel> bajones: it's hard to tell how an author would make different choices based on the results of knowing this setting
19:16:45 <ada> ack alcooper
19:16:53 <Brandel> bajones: The preloading feature makes knowing ahead of time more compelling
19:16:57 <ada> zakim, close the queue
19:16:57 <Zakim> ok, ada, the speaker queue is closed
19:17:20 <Brandel> alcooper: we have different features for VR vs. AR, so there's an immediate divergence based on that decision from the start
19:17:50 <ada> ack bialpio
19:18:01 <Brandel> alcooper: as an author, if I already know the category of device, it's likely I can make decisions about what to offer
19:18:33 <cabanier> q-
19:18:38 <Brett_> +q why not call it just info on the users current reality? AR or VR?
19:18:38 <Brandel> bialpio: given that there are a range of states for a given device, it's not likely that we can know what the preferred mode should be based on the hardware.
19:19:38 <Brandel> bialpio: the branching between committing to AR and VR become tangled, especially when some features have been enabled and others haven't.
19:20:17 <cabanier> q+
19:20:29 <ada> ack ada
19:20:29 <Zakim> ada, you wanted to say what's your preferred? incorect your getting vr instead
19:20:37 <Brandel> bialpio: It's not clear to me how much this affects the complexity for pre-fetching, whether people would pull everything or need to make decisions at that moment when the information is known
19:21:31 <Brett_> Would it be nice for a normal webpage to know if its being opened in VR or AR?
19:21:33 <Brandel> ada: if we return this at the moment that the session is actually granted, while you don't get the preload ability, you still have the opportunity to re-negotiate the terms of the session before it has started in earnest
19:22:08 <Brandel> bialpio: Right now the only way to load either AR or VR is to have two buttons - one for each high-level kind
19:23:49 <Brandel> Brandel: we will always have a permission dialog here, so trying to smooth out the friction this kind of query requires isn't as important
19:23:59 <Brandel> Brett_: Does a page knows the context it's in?
19:26:33 <atsushi> topic: lunch break
19:26:36 <atsushi> rrsagent, publish minutes
19:26:38 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/25-immersive-web-minutes.html atsushi
19:44:28 <m-alkalbani> present+
20:32:34 <bialpio> q?
20:33:34 <nick-niantic> nick-niantic has joined #immersive-web
20:35:34 <marisha> marisha has joined #immersive-web
20:35:34 <ada> zakim, choose a victim
20:35:34 <Zakim> Not knowing who is chairing or who scribed recently, I propose Cooper
20:35:37 <Brandel> Brandel has joined #immersive-web
20:35:40 <Brandel> presnt+
20:35:45 <Brandel> present+
20:35:47 <bajones> bajones has joined #Immersive-Web
20:35:48 <etienne> etienne has joined #immersive-web
20:35:49 <alcooper> scribenick:alcooper
20:36:02 <marisha> present+
20:36:19 <Mats> Mats has joined #immersive-web
20:36:40 <alcooper> ada:Topic keeps being brought up around accessibility discussions and automation; but if nothing else this is a good foundation for an accessibility story
20:36:43 <atsushi> atsushi has joined #immersive-web
20:36:53 <alcooper> ... which is currently a bit lacking
20:37:35 <alcooper> ... two part API, first is a stencil buffer where they render the ID of each object as a color with no antialiasing
20:37:51 <ada> https://github.com/immersive-web/webxr/issues/1363
20:38:02 <bajones> q+
20:38:18 <Phu_MS> Phu_MS has joined #immersive-web
20:38:25 <alcooper> ... Scene Graph attached to a session somehow; where each object in the scene graph contains an ID that matches the color in the stencil and a few properties to make it useful
20:39:02 <nick-niantic> q+
20:39:21 <cwilso> zakim, open the queue
20:39:21 <Zakim> ok, cwilso, the speaker queue is open
20:39:21 <atsushi> i/ada:Topic keeps being brought up around accessibility/topic: Add Scene Description API for automation and a11y (webxr#1363)
20:39:23 <ada> zakim, open the queue
20:39:23 <Zakim> ok, ada, the speaker queue is open
20:39:23 <bajones> q+
20:39:27 <nick-niantic> q+
20:39:27 <atsushi> chair: Ada
20:39:31 <atsushi> rrsagent, publish minutes
20:39:33 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/25-immersive-web-minutes.html atsushi
20:39:39 <yonet> yonet has joined #immersive-web
20:40:04 <Brett_> q+ Is what your describing like the right side of this image? Could DOM Overlay's be used like the left side of this image?
20:40:10 <m-alkalbani> m-alkalbani has joined #immersive-web
20:40:10 <alcooper> ... Some proposals to make this useful: 4x4 transformation matrix (not sure if local or global), bounding box with identity applied (even if not currently visible), attachment to a specific XR space, name/description (description like an alt tag), role in the environment (aria role)
20:40:44 <Brett_> +q forgot to paste image https://manipulation.csail.mit.edu/data/coco_instance_segmentation.jpeg
20:40:46 <alcooper> ... this could also be used to tab through content and even fire select events without needing inputs
20:41:25 <alcooper> ...sound effects or whether things represent a person on a person
20:41:50 <alcooper> ... navigation to another page (aria role relationship), and/or any state that it has
20:42:08 <alcooper> ... Does this sound useful?
20:42:31 <alcooper> ... Probably wouldn't be too difficult to implement from a browser standpoint (hook a buffer up to screen reader functionalities), also useful for automation
20:42:52 <alcooper> ... Downside is that this wouldn't be automatic; developers would need to do additional work; but unblocks usage in areas where accessibility is required
20:43:21 <alcooper> ... What carrots should we provide to encourage developers to use it?
20:43:42 <Brandel> q?
20:43:51 <yonet> ack bajones
20:44:12 <alcooper> bajones: This has been talked about a bit in Editor's meetings, a few highlights
20:44:35 <alcooper> ... really interesting idea, been talking about need for accessibility for a long time; not just WebXR but anyhting that creates a buffer of pixels
20:44:41 <alcooper> ... requires hacks to be accessible today
20:44:51 <alcooper> ... possibility of extending to WebGL/WebGPU, which may also be a bit of a curse
20:45:20 <alcooper> ... Talked about this a bit more abstractly, but hard to find a way to meet in the middle with accessibility folks and/or prototype
20:45:45 <cabanier> q+
20:45:57 <alcooper> ... Really need people who can prototype this to figure out that we're moving in the right direction, and then need to provide carrots to developers
20:45:58 <Omegahed> Omegahed has joined #immersive-web
20:46:02 <alcooper> s/carrots/encouragement
20:46:40 <alcooper> ... e.g. developers have to do application specific ray tracing, and we can use this to maybe provide hints or objects that were hit-test
20:46:53 <alcooper> ... Maybe something more primitive than color buffers of objects like just bounding boxes
20:47:08 <alcooper> .... If you have hte color buffer we can ID those a bit better
20:47:22 <alcooper> s/hte/the
20:47:55 <alcooper> bajones: Gives the opportunity for the browser to also highlight what you're looking at which the page may not be able to do, e.g. on the Apple Vision Pro
20:48:04 <alcooper> ... whatever we talk about here, we should disconnect it from a session
20:48:15 <alcooper> ... may want to build this outside of having a session
20:48:21 <Brandel> q+
20:48:33 <alcooper> ... and then attach it to a space
20:48:48 <alcooper> ... Minor nitpick: Rigid Transforms, not 4x4 matricies
20:48:53 <yonet> ack nick-niantic
20:48:56 <alcooper> nick-niantic:
20:49:00 <ada> q+ to suggest a descriptive torch
20:49:41 <alcooper> nick-niantic: A couple observations, a lot of 3D frameworks lean into these representations that don't give you tools to get a full description of the scene
20:50:01 <alcooper> ... a lot of ways to manipulate geometry of scene beyond initial scene description
20:50:19 <alcooper> ... therefore it's indeterminate and hard to do custom hit testing
20:50:38 <alcooper> ... In some ways having a full description of the scene is impossible
20:51:01 <alcooper> ... I'd try to think more concretely about what values people can get and write a spec to give them a way to get benefits out of those values
20:51:57 <alcooper> ... need to be clear what these scene-reading applications are and what value they provide
20:52:19 <alcooper> ... but also not looking for a solution that fits everything, since likely need to run code to do a hit test
20:52:42 <alcooper> ada: Goal wasn't to force a developer to fully enumerate all these properties; just that they get more benefit to providing more of them
20:52:50 <alcooper> ... if a developer doesn't do anyhting, things will still work as before
20:53:17 <alcooper> ... for automation kind of just want to use it with WebDriver to figure out where buttons are
20:53:51 <alcooper> ... a lot of sites rely on automation testing which is currently hard in WebXR since there's not the same feedback mechansims as HTML/CSS provide
20:54:19 <alcooper> ... accessibility is the most important story; automation is a side benefits, everything else is meant to be developer benefit/motivation to use this
20:54:43 <ada> q?
20:54:51 <yonet> ack Brett_
20:54:53 <alcooper> ... maybe search engines can use this to index part of the page
20:55:03 <yonet> ack forgot
20:55:03 <Zakim> forgot, you wanted to paste image https://manipulation.csail.mit.edu/data/coco_instance_segmentation.jpeg
20:55:16 <alcooper> Brett_: Is it like this image https://manipulation.csail.mit.edu/data/coco_instance_segmentation.jpeg
20:55:23 <alcooper> ada: Yeah kind of
20:55:33 <alcooper> Brett_: So this is an accessibility frame buffer?
20:55:41 <alcooper> Ada: yes, with an object on the side
20:56:17 <bajones> q+
20:56:18 <alcooper> Brett_: Loading HTML into WebXR solves this for that WebXR (given the existing content), and same for model/image tags
20:56:32 <alcooper> ada: But that doesn't solve the WebGL problem
20:56:58 <alcooper> Brett_: But could you describe this all via HTML?
20:57:11 <alcooper> ada: We'd essentially have to rebuild HTML for the Web which is a 30+ year project
20:57:16 <yonet> ack cabanier
20:57:27 <cabanier> https://www.w3.org/WAI/APA/wiki/WebXR_Standards_and_Accessibility_Architecture_Issues
20:57:40 <Brandel> q-
20:57:40 <alcooper> cabanier: We've discussed this a few times, including link from Accessibility group
20:57:51 <alcooper> ... Is this the same proposal?
20:57:54 <alcooper> ada: Very similar
20:57:54 <Brandel> q+
20:58:35 <alcooper> ada: so full scene graph including things that aren't rendered and you'd also have the framebuffer
20:58:49 <alcooper> cabanier: In that case why do we need matrices/bounding boxes and why not just pixels?
20:59:14 <alcooper> ada: Thought it could be cheap and interesting, but if it's not useful shouldn't list it. Initial list is just initial impressions of what my be useful
20:59:32 <yonet> ack bajones
20:59:49 <alcooper> bajones: From an accessibility standpoint how important is it to see something off the screen exists
21:00:02 <alcooper> ... maybe if you have mobility issues you can be targeted towards it
21:00:09 <alcooper> ... (via tabbing)
21:00:20 <alcooper> ... This makes me say we probably want more than just a pixel buffer approach and they are complimentary
21:00:28 <alcooper> cabanier: Might be very hard to calculate the bounding boxes
21:00:49 <alcooper> bajones: This gets into what Nick was talking about that things may become impractical
21:01:16 <alcooper> Brandel: One place definitely needed is to include/give information about things that aren't in view, and pixels won' t be enough
21:01:33 <alcooper> cabanier: DOM would still give you this information
21:01:58 <alcooper> ... unsure if there is a need for the extended scene description if there's a pixel buffer and the fallback dom
21:02:11 <alcooper> ... fallback dom wouldn't have spaces/bounding boxes, is just standard html
21:03:04 <alcooper> ada: If you just had an object that was one set of objects/vertices with a smart shader you could still work out where things like heads/arms are to be rendererd accurately in the scene graph
21:03:13 <Brett_> +q Model tag smart-shader + 3D CSS Dom Overlay Smart shader
21:03:22 <alcooper> ... scene graph doesn't have to be literally what's being rendered to the page, could fake it a bit/provide basic positions
21:03:41 <yonet> ack ada
21:03:41 <Zakim> ada, you wanted to suggest a descriptive torch
21:03:56 <alcooper> ada: Another useful thing could be if pixel buffer sometimes came from eye or sometimes from hand
21:04:13 <cwilso> q+ Brett to talk about Model tag smart-shader + 3D CSS Dom Overlay Smart shader
21:04:20 <alcooper> ... e.g. could scan with hand like a torch (flashlight) vs. just what looking at
21:04:56 <alcooper> bajones: Definitely need secondary buffer to get info when pointing sideways vs. what is being viewed; concerned about performance
21:05:06 <alcooper> ada: Resolution doesn't have to be same as pixel buffer
21:05:42 <alcooper> bajones: This does effectively mean doing a second render pass.
21:06:03 <alcooper> ... similar if this buffer isn't antialised but color buffers are
21:06:07 <yonet> ack Brandel
21:06:11 <alcooper> ... lots of pitfalls that can lead to bad performance
21:06:44 <alcooper> Brandel: Despite the fact that most engeines are using direct scene graphs, that shouldn't necessarily be what's submitted for this since instancing, et.c can lead to inaccuracices
21:06:49 <alcooper> ... but this does mean that it can be simpler
21:07:03 <alcooper> ... Doesn't have to update as often
21:07:10 <alcooper> ... These aren't dealbreakers
21:07:28 <alcooper> ... may also need this for things like shadertoys that are just two triangles
21:07:40 <alcooper> ... WebGL doesn't have a scene graph and just has pixels as well
21:07:46 <alcooper> ... conceptually harder to construct this sometimes
21:08:10 <alcooper> ... shouldn't overindex on what some people have to do to create these views
21:08:35 <alcooper> ada: Could use this to update instances if browser keeps the two in sync
21:08:36 <yonet> ack Brett_
21:09:07 <alcooper> Brett_: If we do use model tags could automatically generate scene graph
21:09:24 <alcooper> ... on a smartphone today, can use accessibility features in 3D css/dom overlay
21:09:51 <yonet> ack Brett
21:09:51 <Zakim> Brett, you wanted to talk about Model tag smart-shader + 3D CSS Dom Overlay Smart shader
21:10:57 <alcooper> ada: It's possible to do this with DOM overlay today, but falls apart via VR today
21:13:12 <ada> ada has changed the topic to: https://github.com/immersive-web/administrivia/blob/main/F2F-March-2024/schedule.md
21:20:18 <yonet> yonet has joined #immersive-web
21:24:41 <yonet> Topic: https://github.com/immersive-web/depth-sensing/issues/44
21:26:03 <bajones> scribenick:bajones
21:26:41 <Felix_Z> Felix_Z has joined #immersive-web
21:26:50 <atsushi> s|https://github.com/immersive-web/depth-sensing/issues/44|Potentially incorrect wording in the specification (immersive-web/depth-sensing#44)
21:26:54 <atsushi> rrsagent, publish minutes
21:26:55 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/25-immersive-web-minutes.html atsushi
21:27:01 <bajones> bialpio: When talking with Rik about the depth sensing API we realized that there may be a mistake in the spec. Want to see if there's any potential future changes of this sort.
21:27:33 <bajones> ...: Feels like we will have to introduce a breaking change with what Chrome is already returning in order to be more concrete.
21:28:44 <bajones> ... In ARCore we're not returning from the near plane, just returning as-is. Doesn't match Quest, need to offset to make them match.
21:29:23 <bajones> ... We don't want to have to apply this offset to the depth buffer ourselves, which incurs a perf penalty, so need to return an offset for the user to use.
21:30:02 <bajones> ... That's the breaking change. The data will be the same, but if users don't change how they interpret the data it won't work cross platform.
21:30:38 <ada> q?
21:30:43 <cabanier> q+
21:30:44 <bajones> ... Do we need to account for anything beyond the near plane. For example, how is the data interpreted between near/far planes?
21:30:50 <ada> ack cabanier
21:31:21 <Brandel> q+
21:31:22 <bajones> cabanier: How did we come to the conclusion that the values returned are between the near/far plane?
21:31:46 <bajones> bialpio: We assume 0 means near place + 0 mm?
21:31:54 <bajones> cabanier: I don't know if that's true?
21:33:04 <nick-niantic> q+
21:34:01 <bajones> bialpio/cabanier: Discussion of how to use projection matrices to get values. Math math math.
21:35:00 <bajones> bialpio: First thing is that we need to change the spec to not say values are from the near plane, because it turns out to not be true for any devices today.
21:35:57 <bajones> ...: We also have to expose the near value that it's relative to, or there's no way it can work. Once you have a depth buffer you already have data that you have to fix up.
21:36:58 <bajones> ...: Might have to expose depth far? Only if the depth buffer data is normalized. In order for the developer to know how to use for anything other than occlusion they need to know these values.
21:37:16 <bajones> ...: Occlusion might work if the values match the near/far planes.
21:37:47 <cabanier> q+
21:37:52 <bajones> ...: How can we future proof, since we're already making a breaking change.
21:38:42 <bajones> cabanier: I think the depth should always be linear
21:39:10 <bajones> Brandel: Logrithmic depth is beneficial in some cases, not necessarily in AR context given the scales involved.
21:40:00 <bajones> nick-niantic: AR core returns 16 bit ints with distance in mm
21:40:08 <ada> q?
21:40:09 <bajones> cabanier: Meta returns floating point meters
21:41:02 <bajones> bialpio: Bigger the numbers, the more inaccurate the reporting is going to be.
21:41:36 <bajones> bialpio: AR Core says beyond 8 meters precision falls off.
21:42:18 <ada> q+
21:43:14 <bajones> bajones: How does the different scale get resolved today?
21:43:40 <bajones> bialpio: Already reports scaling factor and data format.
21:44:19 <bajones> Ada: Could we provide a conversion function?
21:44:37 <bajones> bialpio: That exists on the CPU, but how do we do it on GPU?
21:45:10 <bajones> nick-niantic: Could you provide a matrix?
21:45:23 <bajones> bialpio: For non linear values? Probably not.
21:45:47 <Brandel> q?
21:46:01 <bajones> cabanier: Could we tell devices that decide to go the non-linear route that the have to expose a v2 of the API?
21:46:11 <bajones> bialpio: Yeah, that would work.
21:46:41 <bajones> ... last question for Rik. your depth far is at Inifinity? Do we have to expose that?
21:47:27 <bajones> ... We just expose absolute values.
21:47:41 <bajones> bajones: Doesn't that imply that depth far is at infinity?
21:47:59 <bajones> bialpio: Probably? That sounds right but not sure.
21:48:56 <ada> ack Brandel
21:48:56 <yonet> ack Brandel
21:49:02 <bajones> ... I think we can skip it. Should be able to absorb that math into the scaling factor.
21:50:01 <bajones> Brandel: Did you say the values are perpendicular in ARCore? Because that would make the values non linear.
21:51:17 <bajones> <more discussion about if we need more math or less math>
21:51:34 <yonet> ack nick-niantic
21:52:01 <bajones> nick-niantic: Trying to understand depth near on Oculus. Why do we need to have it? Due to how the cameras compute it?
21:52:19 <bajones> cabanier: Yes.
21:52:46 <yonet> ack cabanier
21:53:16 <bajones> ... Only reason we might need depth far is if implementations use something other than infinity for the far plane.
21:53:25 <Brett_> q+
21:53:37 <bajones> bialpio: Does openXR enforce units?
21:53:50 <bajones> cabanier: depth 16, yes.
21:54:15 <bajones> bialpio: I think the math will work out.
21:54:17 <ada> q-
21:54:28 <yonet> ack Brett_
21:55:22 <bajones> Brett_: Is the near plane supposed to represent where the depth starts counting from from the headset moving out?
21:55:31 <bajones> bialpio: Yes.
21:55:45 <yonet> Topic: https://github.com/immersive-web/webxr/issues/1366
21:55:46 <bajones> ... Think I have what I need to make progress.
21:56:47 <atsushi> s|https://github.com/immersive-web/webxr/issues/1366|Feature for the UA to handle viewing the system inputs during a session (immersive-web/webxr#1366)
21:56:49 <atsushi> rrsagent, publish minutes
21:56:51 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/25-immersive-web-minutes.html atsushi
21:57:04 <yonet> Scribe: Brett_
21:57:23 <marisha> How to scribe: https://w3c.github.io/scribe2/scribedoc.html#scribe
21:58:48 <bajones> q+
21:58:48 <Brandel_> Brandel_ has joined #immersive-web
21:59:25 <yonet> ack bajones
21:59:26 <cabanier> q+
21:59:28 <Brett_> Ada: On the vision Os when you dont enable hand tracking because the a hands arnt visible we show the users hands. We are thinking from using this it might be nice to have this for when you turn on hand tracking they could opt in and use their real hands. In general, instead of using WebXR input profiles you use system rendering. You might be able to have the controller do stuff with depth buffers for interaction. Want to guage interest and[CUT]
21:59:43 <Brett_> like when pages cut out information for security reasons like with dom layers
22:00:22 <Brett_> bajones - depth compositing isn't a factor. today my understanding is on vision pro you can request the hands without hand tracking and get the hands and then it stops if you ask for the hands
22:00:46 <Brett_> ada - we dont want to stop people doing existing hand writing so they would opt into this
22:01:22 <Brett_> brandon - do you envision this as a real time toggleable thing you could turn
22:01:32 <Brett_> brandon - or flag at session time for all meat all the time
22:01:54 <Brandel_> q+
22:02:17 <Brett_> ada : describing transition between system hands
22:02:38 <yonet> ack cabanier
22:02:49 <Brett_> idea: about putting on boxing gloves but being cute, switching from real hands to controller hands
22:03:22 <Felix_Z> q+
22:03:38 <Brett_> ada: maybe it should be toggleable on the fly, like a method in the session;
22:03:52 <Brett_> brett: what about clipping your hands in and our with depth sensing
22:05:26 <Brandel> q-
22:05:43 <Brett_> brandon: by layering the hands video feed on purpose, you could composite it without depth
22:05:59 <Brett_> ada: this will be a feature flag and you turn it on and then there is an open PR that is about inputs and weather or not they should be rendered
22:06:13 <Brett_> ada: in this situation we would set that to true to show that hte hands are already rendered somewhere else
22:06:18 <bajones> q+
22:06:43 <Brett_> rick: on the quest that flag false always unless you add this feature
22:07:08 <Brett_> rick: could this work in AR. it would work for AR depth sorting hand visibility or depth sensing can do this too
22:08:03 <Brett_> ada: it could be viable for AR and I guess you would be doing whatever the system does, the system could do
22:08:18 <Brett_> rik: leave the hands up to the UA with interacting with controller? ada: yes
22:08:22 <yonet>  ack Felix_Z
22:08:31 <Brett_> this is about systems rendering inputs
22:09:07 <Brett_> Felix: Is this about hands only? Or what is currently supported by the system? What about tracked sources?
22:10:20 <Brett_> Ada: Tracked sources will be rendered by the system, your in VR and the system is rendering controllers, they could appear on the table, you also have system rendered hands, currently the system does the hand rendering
22:10:44 <Brett_> Felix: What about an input rig?
22:10:52 <Brett_> I need to ask more about that
22:11:28 <cabanier> q+
22:11:28 <Brett_> Felix: One more question, do you see values in just rendered the active input sources?
22:11:42 <Brett_> Ada: Transient pointers are an example of something that isn't even tracked like that
22:12:08 <Brett_> Ada: Per input? Maybe its gonna be like... like when you do hit testing you give it a target ray mode track, it could be like that
22:12:32 <Brett_> Ada: Maybe its only for tracked pointers like things that would get rendered, actually I dont think so it would be for all tracked pointers
22:12:35 <cabanier> q-
22:13:02 <Brett_> Felix: Turn off rendering of active rendering sources as an option?
22:13:28 <Brett_> Ada: Quest perspective, put controllers down, have hands, pick them up,
22:13:35 <Brett_> Brandon: We talked about trackers representing the body before
22:13:46 <Brett_> 1+
22:13:47 <Brett_> Q+
22:13:56 <yonet> ack Brandel_
22:14:00 <Brett_> Ada: That would be interesting, the user agent would render those?
22:14:38 <Brett_> Felix: We have the tracked sources, thats the controllers, we are using hands right now, controllers not being blocked out when depth is wrong can be destracting
22:14:47 <Brett_> Ada: Would you want to be able to cut out the controller with depth buffer?
22:14:54 <yonet> ack bajpnes
22:14:58 <Brett_> Ada: technically?
22:15:56 <Brett_> Ada: Session startup?
22:16:10 <Brett_> Rick: Would know if punch-through or not and can not render controller. Your punchtrough hand would remove the hand your rendering.
22:16:31 <Brett_> Ada: User agent could request the feature, then you render, then tell them not to render these, others can or can't
22:17:16 <Brett_> Felix: I got an idea for the possibility to toggle this at runtime? Make this universal, one rendering of hand is one XR input source, a list of masks could be exposed and find hte mapping of the rendering to the XR input source
22:17:27 <Brett_> Felix: Then system rendering can be turned off and people can toggle rendering per input source
22:17:52 <Brett_> Ada: We can't expose the mask raw data
22:18:31 <yonet> ack bajones
22:18:32 <Brett_> Ada: Per input, seems harder to do it for every input
22:18:51 <Brett_> Rick: but one controller and one hand
22:19:01 <Brett_> Brandon: I don't know if this is rendering a mask per hand
22:19:05 <yonet> ack Brett_
22:19:49 <Brett_> Brett: Feet, hands, body, this can expand to the rest
22:20:09 <cabanier> q+
22:20:28 <Brett_> Ada: compositing hands with virtual objects is an exciting possibility, like light saber
22:20:36 <Brett_> brandon: I would like to know more about levels of control
22:20:49 <Brett_> q+
22:21:04 <Brett_> brandon: simple start might be good
22:21:47 <yonet> ack cabanier
22:21:50 <Brett_> other idea: making it good to start is good, this might be an easy thing to change at runtime, global render all controllers rendering sounds fine to me
22:21:57 <ada> q?
22:22:04 <yonet> ack Brett_
22:22:47 <Brett_> Brett: With masks we can put our feet through portals, we don't see the mask data but layering the masks is still amazing
22:24:21 <Brett_> Rik: If your interacting with your room, you arn't interested in your hands, there is an option to filter hands out of the depth so this is important here too
22:24:46 <Brett_> Brett Fix ^ in the context of hands being filtered out of depth data as a current option today
22:42:52 <bajones> bajones has joined #Immersive-Web
22:44:58 <Brandel> Brandel has joined #immersive-web
22:46:27 <etienne> etienne has joined #immersive-web
22:48:30 <yonet> yonet has joined #immersive-web
22:58:58 <ada> Zakim, choose a victim
22:58:58 <Zakim> Not knowing who is chairing or who scribed recently, I propose Rik
22:59:31 <atsushi> atsushi has joined #immersive-web
23:00:38 <marisha> marisha has joined #immersive-web
23:00:43 <marisha> present+
23:01:01 <cabanier> scribenick cabanier
23:01:12 <Omegahed> Omegahed has joined #immersive-web
23:01:17 <cabanier> bajones: we've brought this up at TPAC
23:01:27 <cabanier> .... we didn't decide on anything concrete there
23:01:45 <cabanier> ... are there any aspects that we want to reconsider or deprecate?
23:01:59 <cabanier> ... deprecation is an arduous process
23:02:11 <cabanier> ... but it's ok to look on our bets and decide if they didn't pan out
23:02:21 <cabanier> ... maybe it's healthier for implementor and user
23:02:24 <Brandel> q+
23:02:29 <cabanier> ... inline sessions are an example
23:02:41 <Mats> Mats has joined #immersive-web
23:03:05 <cabanier> ... but stereo inline or magic window could come in the future but not necessarily using inline session
23:03:18 <Mats_> Mats_ has joined #immersive-web
23:03:19 <cabanier> ... very few people use them. afaik only the samples page does
23:03:40 <cabanier> ... maybe we can simplify things by dropping them
23:03:43 <Brett_> q+ model tags inline, is Inline Mode how Dom Overlays work today?
23:03:56 <Brett_> q+
23:03:59 <cabanier> q+
23:04:02 <ada> ack Brandel
23:04:17 <cabanier> Brandel: you mentioned that inline isn't used much. Do you have analytics
23:04:24 <atsushi> i|bajones: we've brought this up at TPAC|topic: Evaluate if any aspects of the API should be deprecated. (immersive-web/webxr#1341)
23:04:27 <atsushi> rrsagent, publish minutes
23:04:28 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/25-immersive-web-minutes.html atsushi
23:04:43 <cabanier> bajones: we have some but they're not likely very good
23:05:00 <cabanier> ... it very much depends if they have a headset or not
23:05:18 <cabanier> ... I don't believe our numbers show that this is needed
23:05:57 <cabanier> ... I have not seen much use. Things are based on three or babylon or playcanvas and those don't use inline sessions
23:06:05 <cabanier> ... only the sample page
23:06:21 <ada> ack Brett_
23:06:28 <cabanier> ... the only other use is pages based on the samples
23:06:38 <atsushi> s/scribenick cabanier/scribenick: cabanier
23:06:56 <cabanier> Brett_: inline mode won't get you anything XR related
23:07:14 <cabanier> bajones: you can get orientation data on android
23:07:43 <cabanier> ... you can use offset reference space and other things
23:08:14 <cabanier> ... but the only thing is that if you built your framework around the webxr frameloop, you can reuse it on the 2d page
23:08:34 <cabanier> ... but it's not a big deal to switch between raf and the xrsession's frameloop
23:08:38 <nick-niantic> q+
23:09:22 <cabanier> ... maybe offset reference spaces?
23:09:29 <Brandel> q+
23:09:30 <cabanier> ada: I use those
23:09:44 <cabanier> cabanier: I've seen them used as well
23:10:12 <Brett_> q+
23:10:23 <yonet> ack cabanier
23:10:46 <cabanier> cabanier: can we get rid of secondary views?
23:10:56 <cabanier> alcooper: I believe hololens has them
23:11:27 <cabanier> Brandel: NTT has a prototype that uses them
23:12:03 <cabanier> ada: for the a11y pixel fallback, would that be a secondary view?
23:12:15 <cabanier> bajones: that would be a different thig
23:12:34 <cabanier> ada: it's potentially used for a buffer that you can share with people
23:12:46 <bialpio> q+
23:12:55 <cabanier> bajones: I believe that's the one of the use cases for secondary views
23:13:08 <cabanier> ... I believe hololens had an observer viewport
23:13:30 <cabanier> ... but I believe we discussed using it as an observer view
23:13:48 <cabanier> ... I don't know how well supported that use case is in the spec language
23:13:59 <cabanier> ada: I'm not super attached to it
23:14:12 <cabanier> ... as a web developer, I haven't seen much adoption
23:16:36 <marisha> It looks like this fairly popular mathematics animation library might be using inline sessions: https://github.com/CindyJS/CindyJS
23:17:15 <cabanier> bialpio: a bunch of api use xrview and secondary views are allowed there
23:17:38 <cabanier> ... so you could add camera data to such a secondary view
23:17:56 <alcooper> q+ to talk about native support
23:17:59 <cabanier> ... for layers, we don't want to add more pressure on the system
23:18:17 <cabanier> ... we only use them because we already have a lot of data.
23:18:22 <ada> q?
23:18:28 <yonet> ack bialpio
23:18:34 <ada> ack nick-niantic
23:18:34 <cabanier> ... for raw camera access, I was thinking of creating artificial views
23:18:35 <bialpio> q-
23:18:44 <ada> q+ to ask about what if a future device
23:18:53 <cabanier> nick-niantic: for reference space, can we get rid of them?
23:19:11 <cabanier> ... for example, you want an unbounded grounded reference space
23:19:32 <cabanier> ... you can ask for the ground on android and it doesn't really know
23:19:33 <bialpio> q+
23:19:49 <cabanier> ... the avp lets you ask for an unbounded reference space and you can only walk a meter
23:20:23 <cabanier> ada: the vision pro case is a bug
23:22:56 <cabanier> idris: magic leap and hololens support unbounded reference spaces
23:23:17 <cabanier> cabanier: I believe Quest supports all reference spaces correctly but it doesn't support unbounded yet
23:23:45 <cabanier> nick-niantic: the intent of reference space is not super well implemented
23:24:11 <cabanier> ... let's not give the developer tools that are not consistent
23:24:31 <cabanier> ... we only want to start at the origin
23:24:53 <cabanier> alcooper: are you saying there should be more clarity around the reference spaces?
23:25:08 <cabanier> ... so not deprecate  but make them better defined
23:25:19 <cabanier> nick-niantic: as a developer I want the ground to be at 0
23:25:21 <cabanier> q+
23:25:29 <cabanier> ... I always want the origin facing forward
23:25:44 <cabanier> ... I want you to be able to set my own content boundary
23:26:55 <cabanier> bajones: are you saying that as a developer you want things but maybe that is not what everyone wants
23:27:12 <cabanier> ... for unbounded space, I might wants things pinned around the house
23:27:19 <cabanier> ... you want things to be preserved
23:27:33 <cabanier> ... webxr doesn't have facilities to preserve that
23:27:34 <bialpio> q-
23:29:35 <yonet> ack Brandel
23:30:17 <cabanier> Brandel: in the context of inline sessions, it doesn't seem that anyone uses is so we can take it out
23:30:30 <cabanier> ... for reference spaces there is enough reason to keep them
23:30:51 <cabanier> ... are there things that we want people to do with them?
23:31:07 <cabanier> bajones: it's certainly possible to have clarifications
23:31:17 <cabanier> ... I wouldn't mind doing a review on these
23:31:34 <cabanier> ... and maybe we should normalize that and codify that in a spec
23:31:44 <cabanier> ... there are edges case
23:32:08 <yonet> ack Brett_
23:32:09 <cabanier> Brandel: it's pretty clear that layers benefit from spaces
23:32:22 <cabanier> ... offset reference spaces
23:32:28 <marisha> q+
23:32:42 <cabanier> ... and maybe we should add that to the spec
23:32:55 <cabanier> bajones: maybe it makes sense to add a note
23:33:01 <cabanier> ... to the layers API
23:33:16 <cabanier> ada:  you can just teleport around
23:33:43 <cabanier> Brett_: it's the steam deck the perfect inline device
23:33:56 <cabanier> bajones: any handheld device, yes
23:34:26 <cabanier> ... if all you're looking for is rendering something inline, yes. But you can just do it with the standard web APIs
23:34:36 <cabanier> Brett_: so you can write a polyfill
23:34:48 <cabanier> bajones: yes but likely I'd be the only user
23:35:06 <cabanier> ... if we deprecate it, give it a long lead time to keep supporting it.
23:35:23 <cabanier> ... give console warning, create a polyfill, etc
23:35:49 <cabanier> ... reach out to developers to tell them to stop
23:36:20 <cabanier> ... in the case of the sample, inline just goes away
23:36:52 <ada> q?
23:36:52 <yonet> ack alcooper
23:36:53 <Zakim> alcooper, you wanted to talk about native support
23:37:22 <cabanier> alcooper: we should be careful removing features that have openxr counterparts
23:37:32 <ada> ack ada
23:37:32 <Zakim> ada, you wanted to ask about what if a future device
23:37:32 <yonet> ack ada
23:37:35 <cabanier> ... if the thing I needed are secondary views
23:37:49 <cabanier> ... and webxr removed support
23:38:06 <cabanier> ada: what if we remove it and suddenly a popular device supports it
23:38:27 <cabanier> ... it = multiple views
23:38:32 <cabanier> ... will it just work?
23:38:45 <cabanier> bajones: there are devices like that like Varjo
23:39:14 <cabanier> ... but they support render them to just 2 views
23:39:46 <cabanier> ... so part of the reason this was introduced
23:40:20 <cabanier> ... some devices have a very large view with 4 large displays but even those render to 2 and then break it up in 4
23:41:49 <cabanier> ... there is a lot of content that will just break if there are more than 2 views
23:42:12 <Brett_> +q
23:42:40 <Brandel> I'm muddy on how this relates to https://developer.mozilla.org/en-US/docs/Web/API/OVR_multiview2, but it seems related
23:43:00 <yonet> ack cabanier
23:45:25 <cabanier> cabanier: (unbounded reference space issues)
23:45:44 <cabanier> bajones: I'd love to have the discussion to hash this out
23:46:10 <cabanier> ada: in the early days, we added it for hololens but it was never shipped
23:46:53 <cabanier> ... but now with ML and Meta implementing it, we need to go over the issues.
23:47:15 <cabanier> idris: we got customer requests to implement
23:47:47 <yonet> ack marisha
23:48:05 <ada> zakim, close the queue
23:48:05 <Zakim> ok, ada, the speaker queue is closed
23:48:26 <cabanier> marisha: an admin question, for inline session, I find a bunch of code on github that is using it
23:48:35 <cabanier> ... how do you make decision on what's being usedf
23:48:57 <cabanier> bajones: every time a browser is removing a feature, we look at the metrics
23:49:08 <cabanier> ... we should get a pretty clear idea
23:49:27 <cabanier> ... add deprecation warnings
23:50:15 <cabanier> ... and if we get feedback, we might keep it in
23:50:24 <yonet> ack Brett_
23:50:58 <cabanier> Brett_: if we remove secondary views, would caves be removed from the spec?
23:51:27 <cabanier> bajones: those devices might just budget and do it within their own implementation
23:51:36 <cabanier> ... and ship their own custom implementation
23:53:51 <bbbbbbbbbbbbb3563> bbbbbbbbbbbbb3563 has joined #immersive-web
23:53:55 <atsushi> topic: unconference
23:54:29 <atsushi> subtopic: Splats are the new mesh
23:58:25 <atsushi> [Nick going through slide]
23:58:53 <bajones> q+
23:59:17 <Brandel> Zakim, open the queue
23:59:17 <Zakim> ok, Brandel, the speaker queue is open
00:01:03 <atsushi> rrsagent, publish minutes
00:01:05 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/25-immersive-web-minutes.html atsushi
00:08:52 <bajones> q+
00:14:32 <bbbbbbbbbbbbb3563> bbbbbbbbbbbbb3563 has left #immersive-web
00:29:20 <ada> ack bajones
00:29:45 <nick-niantic> 8w.8thwall.app/splat-cactus
00:30:18 <nick-niantic> 8w.8thwall.app/splat-avp <-- Includes workaround for AVP gamma issue
00:39:48 <atsushi> rrsagent, bye
00:39:48 <RRSAgent> I see no action items