12:28:59 <RRSAgent> RRSAgent has joined #immersive-web
12:29:03 <RRSAgent> logging to https://www.w3.org/2023/09/12-immersive-web-irc
12:29:23 <cabanier> cabanier has joined #immersive-web
12:29:35 <Zakim> Zakim has joined #immersive-web
12:29:43 <cabanier> present+
12:30:25 <yonet> Agenda: https://github.com/immersive-web/administrivia/tree/main/TPAC-2023#agenda
12:31:22 <gombos> gombos has joined #immersive-web
12:32:10 <tidoust> tidoust has joined #immersive-web
12:33:08 <atsushi> atsushi has joined #immersive-web
12:33:26 <etienne> etienne has joined #immersive-web
12:34:41 <gombos> present+ Laszlo_Gombos
12:35:16 <ada> present+
12:35:24 <yonet> topic: https://github.com/immersive-web/capture/issues/1
12:35:33 <etienne> present+
12:35:38 <jfernandez> present+
12:35:45 <alcooper> present+
12:35:56 <bialpio> bialpio has joined #immersive-web
12:36:06 <bialpio> present+ Piotr_Bialecki
12:36:12 <bajones> bajones has joined #Immersive-Web
12:36:49 <cabanier> present+
12:36:49 <bajones> Ada, you're a little quiet on the video stream
12:36:49 <vicki> vicki has joined #immersive-web
12:36:49 <tidoust> present+ Francois_Daoust
12:36:49 <vicki> present+
12:36:51 <dino> present+
12:36:58 <bajones> present+
12:37:56 <etienne> ada: I think this is an important issue for immersive-ar sessions. Right now the only way to capture is to request raw camera access and composite the content on top. Using a very powerful API for a simple capture use case.
12:38:24 <alcooper> q+
12:38:30 <cabanier> q+
12:38:37 <yonet> ack alcooper
12:38:38 <etienne> ... it seems a bit dangerous for users to get used to allowing raw camera access for a simple use case, that the OS would better handle
12:39:39 <etienne> alcooper: something we proposed a while back, we have a repo somewhere and did some thinking about it, we would like to push it more forward
12:39:39 <ada> q?
12:39:39 <bajones> q+
12:39:49 <yonet> ack cabanier
12:39:56 <atsushi> rrsagent, make log public
12:40:00 <atsushi> rrsagent, publish minutes
12:40:01 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/12-immersive-web-minutes.html atsushi
12:40:14 <etienne> cabanier: on the headseet you could end up capturing someone else
12:40:32 <atsushi> meeting: Immersive-Web WG/CG TPAC 2023 Day 2
12:40:35 <etienne> ... there will definitely be a permission prompt needed but maybe also a sound
12:40:43 <atsushi> agenda: https://github.com/immersive-web/administrivia/tree/main/TPAC-2023#agenda
12:40:52 <etienne> ... not aware of anyone asking for this feature
12:41:03 <etienne> ada: did people ask for raw camera access?
12:41:13 <etienne> cabanier: no one except for Nick
12:41:20 <ada> q?
12:41:24 <etienne> ... but people have asked for more information about the environment
12:42:23 <etienne> bajones: it concerns me that people are using raw camera access to capture the session, it's overly complex and requires you to do a lot of compositing
12:42:49 <alcooper> q+
12:42:53 <alcooper> https://github.com/alcooper91/xrcapture
12:42:53 <yonet> ack bajones
12:42:54 <etienne> ... in the past we considered that most systems have an easy gesture to do this kind of capture
12:43:32 <etienne> ... I wouldn't mind looking at the proposal again, but what I recall of that is that it was a way to request capture via the share API, the capture being made by the OS
12:43:49 <etienne> ... I would be very concerned if we had evidence of people using raw camera access for this
12:44:03 <yonet> ack alcooper
12:44:30 <etienne> alcooper: droped the link to that explainer above ^
12:44:37 <etienne> ... can move it to the official repo
12:45:11 <etienne> ... the shape of the API is to start capture and get a handle to an object that you can share but maybe not access, so we wouldn't need as strict of a prompt
12:45:28 <etienne> ... I think AR is really where this makes the more sense, for VR the page is already in control of everything
12:46:06 <etienne> bajones: I will point out that even in VR, if you're using layers it could get non-trivial to composite yourself
12:46:06 <ada> q?
12:46:12 <etienne> ... so it could be an nice feature, even if it's more critical for AR
12:46:34 <etienne> ada: <polling the room>
12:47:19 <etienne> ada: maybe alcooper should move the proposal to the repo
12:47:22 <etienne> alcooper: will do!
12:47:55 <yonet> topic: https://github.com/immersive-web/webxr/issues/1338
12:48:41 <etienne> ada: the issue here is that the input device the user is holding is also being rendered in XR, looking for the best way to tell the session that a control does not need to be rendered
12:48:47 <MichaelWilson> MichaelWilson has joined #immersive-web
12:48:53 <etienne> ... the only other example of this is screen input
12:49:20 <cabanier> q+
12:49:28 <etienne> ... but when you have a tracked pointer, how do you express things like the abscence of squeeze event without a profile
12:49:29 <cabanier> q-
12:49:35 <Brandel> Brandel has joined #immersive-web
12:49:46 <Brandel> present+
12:49:48 <etienne> ... one way to do this would be to send an empty glb file in that case
12:49:53 <etienne> ... that wouldn't render anything
12:50:16 <etienne> ... it could be pretty generic
12:51:01 <ada> ['generic-hand-invisible', 'generic-hand']
12:51:16 <bialpio> q+
12:51:32 <yonet> ack bialpio
12:51:47 <etienne> bialpio: one comment, I think we should have profile names on transient input sources
12:52:01 <etienne> ... we should be sending generic-touch-screen or something
12:52:03 <bajones> q+
12:52:14 <yonet> ack bajones
12:53:14 <etienne> bajones: I think we do communicate profiles for transient input events. in the past we used external signals, like "if the environment mode is not opaque you don't need to render controllers"
12:53:21 <etienne> ... usually a reasonable assumption
12:53:52 <etienne> ... in the case of transient input on a touchscreen, usually in an AR session, we're not opaque
12:54:37 <etienne> ... in this case of this laptop, or for hands, we might be in a VR mode but have an outline for hands. so the render mode is opaque but you shouldn't draw controlelrs
12:55:09 <etienne> ... the input profile with the empty glb is a reasonable way to trick people into doing the right thing
12:55:10 <cabanier> q+
12:55:19 <etienne> ... but I wouldn't mind an explicit signal
12:55:47 <etienne> ... having the profile named something -invisible might be enough of a signal
12:56:19 <etienne> ... I don't need if we need an explicit boolean for that, the input profile string is _probably_ enough
12:56:19 <ada> ack cabanier
12:56:33 <etienne> cabanier: I agree with bajones that this feels slightly hacky
12:57:44 <etienne> ... if the case of the laptop does the WebXR knows that hands are present
12:58:07 <etienne> ... and some experiences render custom controls, but you probably don't want to render them either
12:58:19 <Brandel> q+
12:58:20 <etienne> ... so it sounds better if there was something on the session, or somewhere
12:58:30 <ada> ack Brandel
12:58:33 <yonet> ack Brandel
12:59:09 <bajones> +1
12:59:20 <etienne> Brandel: I think having the specific name -invisible might not be a good fit. is it invisible or independtly rendered?
12:59:30 <etienne> ... it's not that it's invisible is that it's rendered elsewhere
12:59:35 <ada> q?
12:59:35 <cabanier> q+
12:59:39 <etienne> ... (outside of the XR session)
13:00:27 <ada> q?
13:00:32 <etienne> cabanier: I don't know if you saw ??? that does hand tracking with the laptop camera, and in that case you want to say that the input is hands but you don't want to show them
13:00:50 <ada> ack cabanier
13:01:56 <bajones> q+
13:02:12 <yonet> ack bajones
13:02:15 <etienne> ada: commeting on the issue to recap, adding an enum but should we also tweak the profiles?
13:02:31 <etienne> bajones: even if we have an explicit signal it's probably worth doing both
13:03:06 <etienne> ... the worst case scenario is that experiences with custom controllers will render them anyway
13:03:22 <etienne> ... and we can't fully avoid that, but we can make it easy for people
13:04:17 <etienne> ... the input profile could probably be called -invisible, since the asset is, but the explicit signal should be called something else: system-rendered? but the system might _not_ be rendering, you might see the physical thing
13:04:35 <etienne> ... user-visible doesn't sound right either, it's confusing
13:04:43 <etienne> ... I don't know but I like Brandel's point
13:05:03 <etienne> ... the flag shouldn't say "invisible"
13:05:07 <etienne> ada: I'll make a note on the issue
13:05:11 <Brandel> q+
13:05:38 <ada> ack Brandel
13:05:54 <bajones> +100
13:05:59 <etienne> Brandel: I agree on the asset / profile naming, but I would prefer "empty" instead of "invisible"
13:06:29 <yonet> topic: https://github.com/immersive-web/webxr/issues/1338
13:06:56 <yonet> topic: https://github.com/immersive-web/real-world-meshing/issues/3
13:07:32 <etienne> cabanier: in our system and OpenXR, objects in the world can be a plane or a mesh
13:07:36 <bialpio> q+
13:07:39 <etienne> ... or both, but the site doesn't know which plane belongs to a mesh
13:08:09 <etienne> ... the site could look at the space associated with each mesh or plane, and assume the same space means the same object
13:08:29 <ada> ack bialpio
13:08:30 <etienne> ... but there might be a better way to report this
13:09:08 <etienne> bialpio: one thing about using the space: for plane we say that all points in the plane should be at z=0 in the space, which might be a constraint
13:09:42 <etienne> ... also do you need to render both the mesh and the planes, or rendering planes-only gives you a simplified view?
13:09:54 <etienne> ... what will the app be expected to render in those cases
13:10:11 <etienne> ... are the OpenXR bindings any indication?
13:10:34 <etienne> ... for some use cases it might be important to know if the planes are enough or if you need to look at the mesh
13:11:02 <etienne> cabanier: OpenXR gives us all the spaces in the scene, and we can filter them by plane or mesh, they just have different meta data
13:11:06 <etienne> ... but the space returned is the same
13:11:33 <etienne> ... to answer your question the mesh will also describe the plane and be a more precise representation
13:11:44 <bajones> q+
13:12:11 <ada> ack
13:12:16 <ada> ack bajones
13:12:35 <etienne> bajones: I can see scenarios where you would render a mesh, like for occlusions
13:12:38 <bialpio> q+
13:12:50 <etienne> ... but are there scenarios where you would render a plane? or is it just for hit-testing?
13:13:05 <etienne> cabanier: if you have both you might not need the planes at all
13:13:29 <etienne> bajones: if you report both it might be for fallback
13:13:36 <etienne> ... so older experiences still get planes
13:14:21 <etienne> ... but if you request mesh data you probably don't need to mix it with plane data
13:14:21 <ada> ack bialpio
13:14:21 <etienne> bialpio: as far as use cases, for plane detection we were thinking about hit testing and areas
13:14:23 <etienne> ... like "will your object fit"?
13:14:41 <etienne> ... this is a different use-case as meshing
13:15:07 <etienne> ... we should at least give freedom to the implementation
13:15:13 <ada> q+
13:15:18 <etienne> ... but then developers will have to plan for both scenarios
13:15:43 <etienne> ... maybe we could spec something where you can request meshing but fallback to planes?
13:16:00 <ada> ack ada
13:16:04 <etienne> ... how do be helpful for developers?
13:16:27 <etienne> ada: it shouldn't be too complex to generate a bouding box for the mesh
13:16:40 <etienne> s/bouding/bounding
13:16:41 <bialpio> q+
13:17:24 <ada> ack bialpio
13:17:24 <etienne> bialpio: one remark: we had similar conversations while discussing hit test, the "entity type"
13:17:32 <etienne> ... you would get a type with the hit test result
13:17:53 <etienne> ... the idea was to give you a separate opaque object to correlate when hit comes from the same object
13:18:22 <etienne> ... you could use JS equality to know that the mesh comes from the same object as the plane
13:18:29 <etienne> cabanier: yes that was in my proposal
13:19:03 <etienne> bialpio: since it ties to hit-testing we should do something similar
13:19:03 <etienne> cabanier: agreed
13:19:22 <etienne> bialpio: In these past conversations the concern was to tying the spec to a specific sub system
13:19:48 <etienne> ... you could have point clouds, vs plane detection, vs mesh
13:19:54 <etienne> ... but why would the site care
13:20:23 <etienne> cabanier: I wasn't really thinking about hit testing, more about drawing things
13:20:43 <etienne> ... in a way meshes are more modern but not every object has a mesh, a wall wouldn't get a mesh
13:21:08 <etienne> bialpio: that's also related to object annotations on the Meta device
13:21:14 <etienne> ... how would it work for other systems?
13:21:28 <etienne> cabanier: it would probably be the same of systems that scan
13:21:43 <etienne> bialpio: but how to know if a plane is just a simplified mesh?
13:22:07 <ada> q?
13:22:14 <etienne> cabanier: meshes are pretty new still
13:22:29 <etienne> ... but using the space would be _a_ solution for now
13:23:40 <yonet> topic: https://github.com/immersive-web/webxr-hand-input/issues/120
13:24:14 <etienne> cabanier: we talked about this a bit, on the quest pro because controllers are self-tracked we can report both hands and controllers
13:25:16 <ada> q+
13:25:16 <etienne> ... but do we need to expose this as a capability?
13:25:16 <etienne> ... are there any use cases? an obvious one is to use the controller as a pen
13:25:16 <etienne> ... is it worth the effort to expose, and should it be a feature flag?
13:25:16 <ada> ack ada
13:25:59 <etienne> ada: it couldn't be on the same XR input, because the grip spaces would be different
13:26:45 <bajones> q+
13:27:00 <etienne> ada: it generally feels weird (TODO: ada to add some details :))
13:28:00 <etienne> ada: I guess you could have handedness for accessories too
13:28:00 <etienne> ... definitely something we should work on
13:28:00 <etienne> ... we'll have to solve this eventually
13:28:32 <ada> q?
13:28:32 <ada> ack bajones
13:28:32 <cabanier> q+
13:28:32 <leonard> leonard has joined #immersive-web
13:28:51 <etienne> bajones: not use I agree with ada. I think it's reasonable and desirable to have the hand information and controller info on the same XRInput
13:29:03 <etienne> bajones: the "dangling controller" is an interesting edge case
13:29:39 <etienne> ... one thing we discussed in the past: we could provide an estimated hand pose with a controller
13:30:10 <etienne> ... we probably want some sort of signal that this is just an estimation
13:30:31 <etienne> ... and then you can have a case where you get hand poses that are tracked and not estimated
13:31:07 <etienne> ... the only weirdness is in the case where I have a controller + hand pose and I get a select event? what is it?
13:31:25 <etienne> ... I guess the system will use the controller as a higher quality signal for select, but probably OS specific
13:31:36 <ada> q+
13:31:49 <etienne> ... in any case, apart from the "dangling controller scenario", sounds like that should work
13:31:58 <ada> ack cabanier
13:32:28 <etienne> cabanier: one use case where they should be different is quest pro controllers being used as a pen
13:32:33 <etienne> ... because you hold the controller differently
13:32:58 <etienne> ... what bajones said about estimated the hands and rendering them is true, we have an API for that but not in WebXR
13:33:29 <etienne> ... I like ada's proposal of calling this "accessories", it could be a controller or something else
13:34:04 <etienne> ... in OpenXR these are exposed as "extra controllers", I think it makes sense to do the same
13:34:11 <etienne> ada: you mean the hands are extra controllers?
13:34:20 <etienne> cabanier: instead of 2 controllers you just get 4
13:34:39 <etienne> ada: then we might want to have "primary controllers" in your sources list
13:35:24 <etienne> cabanier: today the controllers already disappear
13:35:24 <ada> q?
13:35:24 <ada> ack ada
13:35:33 <etienne> cabanier: but we didn't discuss if we _should_ expose this
13:35:40 <etienne> ada: I think it's interesting!
13:35:51 <etienne> ... it's the kind of things people are going to want to do
13:36:06 <etienne> ... especially in the future with full body detection?
13:36:33 <etienne> ada: what does the room thinks?
13:36:41 <cabanier> +1
13:36:45 <ada> +1
13:36:46 <etienne> ... just do +1 / -1 in IRC
13:36:46 <yonet> +1
13:36:47 <etienne> +1
13:36:55 <bajones> +1
13:37:03 <vicki> +1
13:37:09 <etienne> ada: I think it's worth looking at
13:37:12 <alcooper> +1
13:37:17 <etienne> cabanier: definitely nobody is against it :)
13:37:26 <etienne> ... but is it useful?
13:37:38 <etienne> ada: it is!
13:39:07 <etienne> ada: this is a new PR, as promised! now that Vision Pro was announced
13:39:14 <etienne> ada: it's a small change
13:39:30 <ada> https://github.com/immersive-web/webxr/pull/1343
13:40:03 <etienne> ada: the idea behind this input type, currently named "transient intent"
13:40:23 <etienne> ... was related to gaze tracking
13:40:31 <etienne> ... but it could be useful for general intents
13:41:17 <etienne> ... and it's transient
13:41:26 <etienne> ... the input only exists for the duration of the gesture
13:41:52 <etienne> ... on Vision Pro when you pinch it uses your gaze for the target ray, but then it uses your hand
13:42:47 <etienne> ... it's a bit like tracked pointers but the target ray space comes "out of your face"
13:43:05 <etienne> ... it could be a fit for different input types, like accessibility
13:43:43 <etienne> ... the conversation on the PR addresses some comments from bajones
13:43:52 <bialpio> q+
13:44:13 <etienne> ... he pointed out the the target ray space not updating is not really useful
13:44:55 <etienne> ... one way would be for the developer to provide a depth map of the interactive objects to the XRInput at the start of the event, so that the system knows where you might want to interact
13:45:05 <etienne> ... we could then update the input ray accordingly
13:45:11 <etienne> ... but that's a huge API
13:45:36 <etienne> ... another alternative would be to make the assumption that you probably interacted with something 1-2m away and then estimate
13:46:14 <etienne> ... the last thing would be to modify the target ray space to act as a child of the grip space
13:46:28 <etienne> ... (gestures to explain)
13:47:02 <etienne> ... if the developer attaches to object to the target ray space instead of the grip space it would still work as expected
13:47:11 <bajones> q+
13:47:15 <etienne> ... these are the options I have in mind
13:47:28 <cabanier> q+
13:47:28 <etienne> ... we should discuss and bikeshed the enum itself
13:47:44 <yonet> ack biaplu
13:47:50 <yonet> ack bialpio
13:48:43 <etienne> bialpio: I think I understand why the space is not updated, but poses are a property of the spaces
13:48:54 <etienne> ... and we need to update them even if nothing changed
13:49:18 <etienne> ... the other concern is that we can create hit test subscription out of spaces
13:49:29 <etienne> ada: yes but the input is transient
13:49:42 <etienne> bialpio: need to think about hit testing a bit more
13:49:58 <etienne> ... but we should make sure that the XR system knows the origin of that space at all time during the gesture
13:50:14 <etienne> ... someone might subscribe to the hit test, and we need to know the latest state of the space
13:50:26 <etienne> ada: in this case the third option might work out
13:50:39 <etienne> bialpio: yeah that might be the easiest way for this to work
13:50:50 <vicki_> vicki_ has joined #immersive-web
13:50:50 <etienne> ada: it is important that hit test works
13:51:07 <etienne> bialpio: do we need to spec out that something _should not change_
13:51:12 <etienne> ada: or _might now change_
13:51:25 <etienne> ... for gaze tracking we don't expose continuous gaze
13:51:34 <etienne> ... for obvious privacy reasons
13:51:47 <etienne> bialpio: we could not change it, but keep things open
13:51:51 <etienne> ... it's not guaranteed not to change
13:52:20 <etienne> ada: we should probably say something about solution #3 for cases where it won't update continuously
13:53:25 <ada> q?
13:53:25 <yonet> ack bajones
13:53:28 <ada> ack bajones
13:53:31 <etienne> ... it shouldn't just work well for button presses but also gestures
13:53:43 <etienne> bajones: lots of thoughts
13:53:56 <etienne> ... but first thank you ada!
13:54:13 <etienne> ... not sure I fully understand the concerns about spaces updating or not
13:54:42 <etienne> ... first thing, should this be a "gaze input", we should strive to match the pointer type to what fits it best
13:54:53 <etienne> ... and introducing a new enum as needed
13:55:03 <etienne> ... on Vision Pro it's a gaze input that happens to be transient
13:55:19 <etienne> ... on some platforms in might not be
13:55:45 <etienne> ... to extend it to assistive devices it would be desirable for them to advertise as gaze input
13:55:53 <etienne> ... if there's nothing particular to call out
13:56:09 <etienne> ... as long as there's a reasonable behavior analog
13:56:22 <etienne> ada: just to clarify, you think we should also use gaze like the existing gaze input
13:56:41 <etienne> bajones: yes it's probably okay to have the behavior you described on a gaze pointer
13:56:53 <etienne> ... people don't have that much expectation about how it should behave
13:57:11 <etienne> ... people are using this to inform "should I render something" and "where should I render it"
13:57:30 <etienne> ... same for screen input, when advertised as tracked-pointer people to generate an input that goes with it
13:57:41 <etienne> ... so we should see which behavior we most closely align with
13:57:56 <etienne> ... a transient gaze input is not an issue
13:58:01 <etienne> ada: but it has a grip space too
13:58:14 <etienne> bajones: that's good to refine the behavio
13:58:19 <etienne> bajones: that's good to refine the behavior
13:58:33 <alcooper> q+
13:58:44 <etienne> ... so if you take a system like this (Vision Pro), advertised as gaze but with a grip present
13:58:49 <etienne> ... that's a strong signal for the page
13:59:20 <etienne> ... I do have questions about how this interacts with hand input
13:59:28 <etienne> ... tracked input + transient eye-based input
13:59:37 <etienne> ... what's the grip pose at that point
13:59:43 <etienne> ada: I have experience with this
14:00:02 <etienne> ... the demo I tested this with is a chess game, to see how to interact with fine objects
14:00:10 <etienne> ... the gaze has enough granularity for this to work
14:00:28 <etienne> ... I also built this with pure hand tracking
14:00:37 <etienne> ... and ended up with both on
14:00:58 <etienne> ... but it just worked together pretty well
14:01:18 <etienne> ... for buttons and menu it was nice to just look & pinch
14:01:27 <etienne> ... they just work together very well
14:01:39 <etienne> ... the hand based input didn't generate unwanted squeeze events
14:02:01 <etienne> ... a developer could just use each for different interactions
14:02:03 <dino> q+
14:02:24 <etienne> bajones: just to clarify, in that mode, the hand input gives you full poses but never generates a select event
14:02:27 <etienne> ada: correct
14:02:46 <etienne> bajones: that should be okay, the spec specifies that you need at least one primary input for select events
14:02:55 <etienne> ... the eye-based primary input would be that
14:03:02 <etienne> ... it's transient but that's propably okay
14:03:14 <etienne> ... again thank you for this work
14:03:41 <etienne> ... I want to discuss the manipulation of the ray when you select _again_
14:03:53 <etienne> ... I'm concerned about the automatic parenting of the 2 spaces
14:04:09 <etienne> ... that would be the thing for precise interactions
14:04:26 <etienne> ... but I'm worried that it's contextually sensitive and wouldn't generalize
14:05:25 <etienne> ... it makes a lot of sense to do gaze, pinch, drag
14:05:25 <etienne> ... but then if I <rotates hand on Y> how would the ray pivot?
14:05:25 <etienne> ... there's a lot of nuance to that
14:05:47 <etienne> ... very specific to the application, only appropriate in some cases
14:06:05 <etienne> ... in the chess scenario I might want to pivot the piece in place, rather than swinging it around
14:06:27 <etienne> ... but in the positional audio sample, I probably want to speaker to pivot around my hand
14:06:37 <etienne> ... not sure the browser is the right place to make this decision
14:06:54 <etienne> ada: so maybe we should go back to having the target ray space not update
14:07:27 <etienne> bajones: if it stays static, we loose simple click and drag gestures
14:07:35 <etienne> ... buttons are definitely the interaction that I see most
14:07:55 <etienne> ... I do wonder if you could take the initial eye ray, then lock it to the head
14:08:12 <etienne> ... then the application could opt into something more precise
14:08:20 <etienne> ... not sure if I advocate for that or not
14:08:31 <etienne> ... it would allow the existing applications to work, but weird
14:08:45 <etienne> ada: I would rather having things obviously not work
14:09:15 <etienne> bajones: it's what you get with cardboard but it's expected
14:09:36 <etienne> ... there's a subset of experiences that won't be updated
14:09:49 <etienne> ... it would be sad if they didn't work on shiny new hardware
14:10:03 <etienne> ... but it might be an awkward fallback
14:10:16 <etienne> ada: video intermission
14:10:41 <etienne> ... showing the chess demo
14:13:24 <ada> q?
14:13:26 <ada> ack cabanier
14:13:42 <etienne> cabanier: so what happens if you enable hands at the same time?
14:13:55 <etienne> ada: you get both, but hands don't send select events
14:14:07 <etienne> cabanier: so you get the input source until you let go of the gesture?
14:14:08 <etienne> ada: yes
14:14:22 <etienne> ... they come through as not-handed
14:14:38 <etienne> cabanier: you say it's a hand?
14:14:48 <etienne> ada: currently we say it's a single button
14:14:58 <etienne> ... and not rendering anything
14:15:14 <etienne> ... but this is hardcoded (the not rendering anything part)
14:15:24 <etienne> ... otherwise you get a generic controller rendered doing the pinch
14:15:45 <etienne> ... but if we do what bajones suggested and use gaze it might just work
14:15:49 <ada> q?
14:15:51 <etienne> ... what's the input profile for gaze?
14:16:20 <etienne> ada: we know the line we're looking down, but not the depth
14:16:31 <etienne> cabanier: so you don't know the point in space
14:16:33 <etienne> ada: no
14:16:54 <etienne> cabanier: in openXR there is an extension that gives you that: the point in space you're looking at
14:17:04 <Jesse_Jurman> Jesse_Jurman has joined #immersive-web
14:17:24 <etienne> ada: do you think you would use that if we had it?
14:17:31 <etienne> cabanier: yes I would prefer using that
14:17:44 <etienne> ada: so you'd start the ray from the point you're looking at
14:17:53 <etienne> cabanier: yes that would be the origin of the ray, not exactly sure
14:18:20 <etienne> ada: it might be weird if you're deeper and you want to do a raycast
14:18:33 <ada> ack alcooper
14:18:34 <etienne> ... I can look into that
14:18:51 <etienne> cabanier: if it has hands enabled as well, people are probably going to use that
14:19:11 <etienne> ada: nothing changes with hands enabled
14:19:29 <etienne> ... you get a third input (2 hands + additionals)
14:19:43 <etienne> ... in this case up to 2 extra transient inputs
14:19:53 <etienne> cabanier: how does it work with existing experiences?
14:19:58 <etienne> ada: works pretty well!
14:20:30 <etienne> ... it works well with both hands + the gaze
14:20:55 <ada> ack alcooper
14:20:59 <etienne> ... if you want you can test it with the positional audio demo
14:21:18 <etienne> alcooper: bajones made the suggestion of just using gaze
14:21:32 <etienne> ... it was my first instinct too
14:21:40 <etienne> ... especially with transient clearly in the name
14:21:49 <bajones> q+
14:22:02 <etienne> ... having scrolled through the spec there's a bit of a note about the gaze
14:22:12 <etienne> ... we might want to soften the language
14:22:24 <etienne> ... but adding a new type might add confusion
14:22:38 <etienne> ada: you think it's okay to have 2 simultaneous gaze input?
14:22:52 <etienne> alcooper: that would probably be fine, the spec does a lot for transient inputs already
14:23:32 <etienne> bajones: we already had situations where you can have 2 different select events at the same time
14:23:34 <alcooper> s/a lot/allow
14:23:51 <etienne> ... I don't think it would be a problem having 2 different gazes
14:23:51 <ada> q?
14:24:10 <etienne> ... they will just track until the select is over
14:24:22 <ada> ack dino
14:24:28 <etienne> ... they usually don't do anything specific for "things going on at the same time"
14:24:41 <etienne> dino: who's actually going to ship gaze tracking on the web?
14:24:48 <etienne> cabanier: not sure
14:24:53 <etienne> ... we haven't exposed eye tracking
14:25:05 <etienne> ... I was thinking about it
14:25:10 <gombos> gombos has joined #immersive-web
14:25:17 <etienne> ... quest pro already have hand tracking
14:25:40 <etienne> ... if we introduce a system gesture, it could break some assumptions
14:25:53 <etienne> dino: so you don't yet have plans to provide raw gaze information
14:25:56 <etienne> cabanier: no we don't
14:26:01 <etienne> dino: does anyone?
14:26:09 <etienne> bajones: I'm not sure...
14:26:23 <etienne> ... mozilla advocated against it a while back
14:26:43 <etienne> ... I don't think anyone is planning on it (raw gaze)
14:27:26 <etienne> alcooper: when we say gaze  we're talking about the enum value
14:27:33 <etienne> ... not raw gaze
14:28:18 <vicki> q+
14:28:37 <etienne> bajones: I would imagine that in the case of an eye tracked pointer, you might actually lock to the head at the periphery, not tracking your eyeball
14:28:38 <ada> ack bajones
14:29:02 <etienne> ... looking at the chrome codebase, cardboard doesn't surface an input profile
14:29:51 <etienne> ... but we should still have an input profile for this scenario
14:29:55 <xiaoqian> xiaoqian has joined #immersive-web
14:30:14 <etienne> alcooper: this goes back to the grip space being null if it's not trackable
14:30:20 <etienne> ... since you shouldn't render anything
14:30:23 <ada> q?
14:30:39 <etienne> bajones: if this was anything more than a 1-button input
14:30:44 <etienne> ... you probably want an input profile
14:31:00 <etienne> ... if a single button produces a ray you probably can go away without an input profile
14:31:28 <etienne> ... input profiles should be used for rendering and capabilities
14:31:31 <ada> ack vicki
14:31:33 <etienne> ... we touched on this in the other issue
14:31:48 <etienne> vicki: I think gaze came up previously when we discussed the name
14:32:04 <etienne> ... just want to clarify that this API proposal is not about "Vision Pro input"
14:32:17 <etienne> ... and as dino said no one is implementing gaze tracking
14:32:21 <ada> q?
14:32:21 <cabanier> q+
14:32:35 <etienne> bajones: it's true that gaze is a bit of a misnomer
14:32:51 <etienne> ... it was the name chosen to imply that the input was coming from the user's head
14:33:11 <etienne> ... it's not about the mechanism , how it's being produced
14:33:28 <etienne> ... more of a signal to the dev, don't draw anything at the source!
14:33:38 <etienne> ... it's what it's trying to imply
14:34:05 <etienne> ... so reusing the same name, while uncomfortable, just says it came from the user's head
14:34:23 <etienne> ... it's a hint to the developer
14:34:29 <ada> q?
14:34:33 <ada> ack cabanier
14:34:51 <etienne> cabanier: thinking about how we could implement this without breaking everybody
14:34:57 <etienne> ... very few experiences expect hands
14:35:14 <etienne> ... on quest pro we could do this when hands aren't requested
14:36:03 <etienne> ... it seems that if you do request hands we shouldn't
14:36:12 <etienne> ada: hands on meta quest emits events?
14:36:14 <etienne> cabanier: yes
14:39:16 <xiaoqian> xiaoqian has joined #immersive-web
14:39:18 <leonard> @Ada: I need to leave for the next hour (until 1600 CEDT). I will rejoin after that.
14:46:12 <xiaoqian_> xiaoqian_ has joined #immersive-web
14:54:22 <ada> Channel for the next call is #webapps
14:58:14 <xiaoqian_> xiaoqian_ has joined #immersive-web
15:00:16 <yonet> yonet has joined #immersive-web
15:00:48 <tidoust> tidoust has joined #immersive-web
15:03:04 <bialpio> bialpio has joined #immersive-web
15:04:19 <bialpio> bialpio has left #immersive-web
15:04:36 <yonet> Anyone need the links here
15:04:53 <Brandel> yes please!
15:04:54 <xiaoqian> https://docs.google.com/document/d/1QDqllh8inOcIkTrblERm4HRKYh8Ce9Lu5S7WhOygs_0/edit#heading=h.dajyulgvrhg3
15:05:54 <ada> Zoom: https://w3c.zoom.us/wc/6736011120/join?wpk=wcpk%7B0%7D%26%26%26%26wcpk0a39d36aab24f17be9f1bf6b5792a2d6&_x_zm_rtaid=6bk_xSkOTTOIdMqQCNeA7Q.1694530119754.1552d5b557fefc954976377efe79b6f8&_x_zm_rhtaid=237
15:05:54 <ada> Day 2 minutes: https://docs.google.com/document/d/1QDqllh8inOcIkTrblERm4HRKYh8Ce9Lu5S7WhOygs_0/edit#heading=h.dajyulgvrhg3
15:06:29 <yonet> Discord is webapps
15:06:40 <ada> we are in #webapps
15:07:27 <bialpio_> bialpio_ has joined #immersive-web
15:07:57 <Brandel> ada: following that link takes me to a page
15:08:07 <Brandel> asking for a passcode
15:09:44 <xiaoqian> https://w3c.zoom.us/j/6736011120?pwd=ZjhtNFMzMlFCTWNJTXEwY29hN0V5dz09#success
15:10:49 <alcooper> I joined from the calendar link atsushi sent in email as well: https://www.w3.org/events/meetings/b8653cb3-bf30-491f-908c-25285106d50f/
15:13:13 <atsushi> s|https://w3c.zoom.us/wc/6736011120/join||g
15:13:21 <atsushi> s|https://w3c.zoom.us/wc/6736011120||g
15:16:50 <ada> q?
15:18:05 <atsushi> rrsagent, publish minutes
15:18:06 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/12-immersive-web-minutes.html atsushi
15:19:38 <atsushi> i|topic: https://github.com/immersive-web/capture|Day1 minutes -> https://www.w3.org/2023/09/11-immersive-web-minutes.html
15:20:08 <atsushi> rrsagent, publish minutes
15:20:09 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/12-immersive-web-minutes.html atsushi
15:23:48 <ada> We're heading back to the room!
15:27:33 <bialpio> bialpio has joined #immersive-web
15:31:57 <bialpio> present+
15:33:02 <alcooper> present+
15:40:54 <bialpio> scribenick: bialpio
15:41:06 <yonet> topic: https://github.com/immersive-web/webxr/issues/1339
15:41:06 <cabanier> present+
15:41:13 <yonet> present+
15:41:57 <bialpio> ada: developers need to know where to place their content, cannot assume things about placement now
15:42:33 <bialpio> ... it would be useful to have a space such that when you place things at that space's origin, it'd be in a good spot
15:42:59 <bialpio> ... it'd be interesting to have it be customizable on the fly
15:43:41 <bajones> q+
15:43:45 <bialpio> ... e.g. user could configure it appropriately
15:44:22 <bialpio> ... its value could change per session so that it won't be used for fingerprinting
15:44:33 <bialpio> ... it could also work for someone who's laying down
15:44:49 <bialpio> ... so the interactive content space would shift accordingly
15:45:15 <bialpio> ... and the user wouldn't need to sit up to interact with the content
15:45:30 <bialpio> ... unsure if it needs to be a feature or just sth available by default
15:45:32 <yonet> ack bajones
15:45:57 <bialpio> bajones: curiousity, is it z-space?
15:46:00 <bialpio> ada: dell + z-space
15:46:17 <bialpio> bajones: not sure if right tool for this specific case
15:46:34 <bialpio> ... maybe, but I think they need their own separate space to track in
15:47:23 <bialpio> ... I talked to them previously and they seemed to be OK w/ having to work with content built specifically for their form factor
15:47:42 <bialpio> ... so old content compat may not be too big concern
15:48:18 <bialpio> ... interesting idea, the spot for interactive content will be different for different people
15:48:57 <bialpio> ... concern is that it goes both ways, on one hand if it's explicit space, then there's a wide range of experiences that don't have access to this feature
15:49:08 <bialpio> ... you essentially opt into accessibility feature, which isn't great
15:50:05 <bialpio> ... there may be cases where exposing accessibility feature will be abused in competitive spce
15:50:17 <bialpio> ... but we don't want to allow opting out of accessibility too
15:51:07 <bialpio> ... I like the idea, I like it could be used for accessibility, but we shouldn't want accessibility to rely on this feature
15:52:09 <bialpio> ... if you want this to be truly useful for accessibility, you need to allow to move the viewer space, which could enable cheating in competitive space
15:52:54 <bialpio> ... but apps could implement protections against cheating
15:53:13 <bialpio> ada: they don't have to use the comfort space - they can opt out
15:53:18 <ada> q?
15:53:52 <bialpio> bajones: correct, but we should consider accessibility features separately from spaces (?)
15:53:57 <Brandel> q+
15:54:59 <bialpio> ... I want to make sure we don't conflate it with being an accessibility tool, but this shouldn't be the only way towards accessibility
15:55:33 <bialpio> ada: it will make life better for everyone and also could be used for accessibility
15:56:08 <ada> ack Brandel
15:56:08 <yonet> ack Brandel
15:56:08 <cabanier> q+
15:56:40 <bialpio> Brandel: another aspect of interactable zone which this makes me think of is magic leap device
15:56:40 <bajones> q+
15:57:42 <bialpio> ... it had 2 focal planes - 45cm and 1m
15:57:42 <bialpio> ... in case it's possible to project (?) at 2 different distances
15:57:42 <ada> ack cabanier
15:58:16 <bialpio> cabanier: unsure about our plans, quest has couple modes to acommodate people in different positions
15:58:19 <bialpio> ... there's bed mode, unsure what will happen if you enter WebXR then
15:58:32 <bialpio> ... but it is reasonable that everything tilts
15:58:37 <bialpio> bajones: how do you enable it
15:59:23 <bialpio> cabanier: unsure if it persists, but I'd assume if you enter WebXR in bed mode, it would persist and not force a different space on you
15:59:27 <bialpio> q+
15:59:38 <bialpio> ... maybe there's no local-floor
15:59:58 <bialpio> ... there's an airplane mode with no expectations that you'll move
16:00:26 <ada> ack bajones
16:00:29 <bialpio> ada: I'd be ok if it were up to the user agent to change this space to accommodate the user
16:01:59 <bialpio> bajones: curious about Brandel's scenario - do you have thoughts about how the comfort space (?) may be determined
16:01:59 <bialpio> ... examples would be useful
16:02:16 <bialpio> Brandel: HTC Vive and Quest has fixed focal distance so it may be uncomfortable to have object presented as if it's at 50cm
16:02:34 <bialpio> ... but on ML it could be at different focal distances
16:03:15 <bialpio> ... when varying focal systems come into play it could be possible to leverage those capabilities
16:03:50 <ada> ack bialpio
16:03:50 <cabanier> scribenick: cabanier
16:04:11 <cabanier> bialpio: don't we mandate that y-axis is opposite of the gravity vector
16:04:17 <cabanier> ada: that would still be the case
16:04:36 <cabanier> ... if you're playing building blocks, you might want to move the gravity
16:04:49 <cabanier> bialpio: I was worred if we already backed ourselves into a corner
16:04:59 <cabanier> ... if it's a regular xrspace, we can change it
16:05:10 <cabanier> ... for reference spaces we can not
16:05:17 <cabanier> bajones: no, that's not correct
16:05:49 <cabanier> ... at one point y-axis had gravity but then hololens used it on the space station so we removed it
16:06:02 <cabanier> bialpio: I think we need to check the other modules
16:06:17 <cabanier> bajones: we removed it from the spec. It used to be there
16:06:29 <cabanier> ... (quotes spec)
16:07:20 <cabanier> ... the spec has non-normative text that says how the y axis should work
16:08:08 <cabanier> ... this comfort space should still have a y-axis relative to the other y-axis's of other space
16:08:33 <cabanier> ... I would expect all reference spaces to be aligned
16:08:34 <bialpio> scribenick: bialpio
16:08:54 <bialpio> (https://www.w3.org/TR/webxr-hit-test-1/#:~:text=(towards%20negative%20gravity%20vector).)
16:09:13 <bialpio> ada: will kick the spec process off
16:09:49 <bialpio> cabanier: RE ML & focal planes, one of them was infinity planes and the way the switched is they looked at your eyes to decide
16:10:06 <bialpio> s/infinity planes/infinity plane/
16:10:43 <bialpio> ada: you may want to place it at the focal distance of the headset
16:11:48 <yonet> topic: https://github.com/immersive-web/real-world-meshing/issues/1
16:12:19 <bialpio> bajones: what are ppl using and what features are causing impl difficulties, is it worth complexity if noone is using those, etc.
16:12:37 <bialpio> ... I called out "inline" because they are causing issues for us and their usage is low
16:12:59 <cabanier> q+
16:14:23 <bialpio> ... webxr samples uses them and yonet uses them and maybe a couple other places but for most part it is handled by frameworks where WebXR is just additional mode to switch to
16:14:23 <bialpio> ... perhaps inline is not needed
16:14:23 <yonet> topic: https://github.com/immersive-web/webxr/issues/1341
16:14:23 <bialpio> ... unclear if it's fulfilling the purpose it was designed for
16:14:23 <bialpio> ... may not be worth the complexity
16:15:26 <bialpio> ... e.g. layers stuff caused us to ask how will it interact with inline
16:15:26 <bialpio> ... & we have mostly ignored those questions
16:15:26 <ada> ack cabanier
16:15:26 <bialpio> cabanier: chrome has telemetry, can you share some numbers?
16:15:26 <bialpio> ... is it already published somewhere?
16:15:59 <bialpio> bajones: (looking) unsure what we can share
16:16:16 <bialpio> ... looking at one graph, cannot give numbers
16:16:38 <bialpio> ... very low proportion of sessions
16:16:48 <bialpio> cabanier: maybe they use polyfill?
16:17:43 <bialpio> bajones: low single-digits
16:18:12 <bialpio> ... if used then maybe through libraries & polyfill
16:18:27 <bialpio> ... if we do want to remove it, it'd be a very long process with long deprecation period
16:18:53 <bialpio> ... the problematic case is content that was abandoned
16:19:46 <bialpio> ... so if this is not useful and creating impl. burden then it may make sense to deprecate
16:19:46 <bialpio> ... worst case they'll lose inline preview prior to entering the experience
16:19:56 <bialpio> alcooper: viewer-only sessions may not hit telemetry
16:20:02 <yonet> q+
16:20:09 <bialpio> ... but since it's done blink-side, it means we can polyfill
16:20:30 <Brandel> q+
16:20:43 <yonet> ack yonet
16:20:49 <bialpio> yonet: I use it to lazy-load resources, it may be useful to keep it
16:20:49 <yonet> ack Brandel
16:21:15 <bialpio> Brandel: let's go with first step of deprecation and see who complains?
16:21:37 <bialpio> bajones: there's been a decent chunk of browser ecosystem that didn't implement WebXR
16:21:52 <bialpio> ... so you still had to rely on a polyfill or three.js / babylon
16:22:10 <bialpio> ... but we are approaching the moment where more browsers implement it
16:22:19 <bialpio> ... so now might be the right moment to go with deprecation
16:22:30 <ada> q?
16:23:00 <bialpio> ada: it'd be a good thing to start on it now so that when we launch things we can launch with the right state
16:23:34 <bialpio> ... there were discussions about other kinds of inline or other kinds of sessions
16:24:07 <cabanier> q+
16:24:13 <ada> ack cabanier
16:24:26 <bialpio> cabanier: it could be useful to have inline stereo
16:24:33 <bialpio> ... 3d movie does not need head pose
16:24:52 <bialpio> ... there is already plenty of content that could work in 3d
16:25:37 <bialpio> Brandel: I wonder about whether head pose is going to be needed to make the experience comfortable
16:25:50 <bialpio> ... we haven't fully resolved it yet
16:26:08 <bialpio> bajones: scenarios cabanier pointed out are way simpler cases overall
16:26:23 <bialpio> ... render into 2 views and that's it
16:26:54 <bialpio> ... more interesting case for inline is having punched-through, magic-window-style content similar to what we chatted about yesterday during <model>
16:27:29 <bialpio> ... this could be the thing we want for z-space
16:27:42 <cabanier> q+
16:27:46 <bialpio> ... worth talking about it at some point
16:27:48 <ada> q+
16:28:11 <bialpio> ... but it may be too complicated for someone just wants to display the stereo content
16:28:55 <ada> ack cabanier
16:28:58 <ada> q-
16:29:06 <bialpio> ada: it could be useful to have the simple case that can be upgraded
16:29:27 <bialpio> cabanier: the reason to use WebXR is that there are already frameworks that talk WebXR
16:29:43 <bialpio> ... if you want to watch stereo it'd be good to have curved screens
16:30:04 <bialpio> ... IDK what'd happen if you requested it on a flat screen - would it curve?
16:30:29 <bialpio> ada: you could go from inline into "fullscreen" immersive session
16:30:52 <bialpio> cabanier: it'd be useful but it may not be appropriate for this group - stereo video is pretty messy now
16:31:14 <bialpio> ... it's pretty bad experience now
16:31:21 <bialpio> ada: mentions layers
16:31:27 <bialpio> cabanier: even just video element is messy
16:31:50 <bialpio> cabanier: we tried displaying stereo when in fullscreen but content gets displayed side by side
16:31:58 <bialpio> ada: unsure which group to take it to
16:32:16 <bialpio> cabanier: I don't think there were any mtgs about it during this TPAC
16:32:36 <bialpio> ada: are we pro-deprecating inline? let's make a PR?
16:32:49 <bialpio> ada: untracked inline stereo session would be interesting
16:32:56 <bialpio> cabanier: we need to discuss this more
16:33:27 <bialpio> ada: that's it for today! next round at 11:30 on Fri
16:34:37 <yonet> RRSAgent, make minutes
16:34:38 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/12-immersive-web-minutes.html yonet
16:51:06 <tidoust> tidoust has joined #immersive-web
17:17:17 <xiaoqian> xiaoqian has joined #immersive-web
17:52:02 <cabanier> ada: https://twitter.com/KMkota0/status/1620090836930400257?s=20 -> hands tracking using the camera
18:09:06 <tidoust> tidoust has joined #immersive-web
19:34:41 <Zakim> Zakim has left #immersive-web
21:30:31 <tidoust> tidoust has joined #immersive-web
22:42:00 <myles> myles has joined #immersive-web
23:59:59 <scribe> i/ada: I think this is an important/scribe+ etienne/