16:44:59 <RRSAgent> RRSAgent has joined #immersive-web
16:44:59 <RRSAgent> logging to https://www.w3.org/2021/10/15-immersive-web-irc
16:45:05 <Zakim> Zakim has joined #immersive-web
16:45:11 <atsushi> zakim, list agenda
16:45:11 <Zakim> I see nothing on the agenda
16:45:18 <atsushi> rrsagent, make log public
16:45:33 <atsushi> agenda: https://github.com/immersive-web/administrivia/tree/main/TPAC-2021
16:45:48 <atsushi> meeting: Immersive-Web WG/CG (extended) group call - Oct/2021, Day 2
16:46:32 <atsushi> agenda+ New proposal ideas?
16:46:39 <atsushi> agenda+ Potential AR feature - point clouds
16:46:47 <atsushi> agenda+ Allow dynamic frame timing
16:46:55 <atsushi> agenda+ Feasibility and desirability of persisting anchors
16:47:05 <atsushi> agenda+ Discussion: HTMLModelElement
16:47:14 <atsushi> agenda+ Provide statistics to help guide performance
16:47:24 <atsushi> agenda+ Review WebGPU API design
16:47:32 <atsushi> agenda+ A feature that toggle stereo on runtime.
16:47:40 <atsushi> agenda+ Discussion with OGC Geo Pose Standard Working Group
16:47:45 <atsushi> zakim, list agenda
16:47:45 <Zakim> I see 9 items remaining on the agenda:
16:47:46 <Zakim> 1. New proposal ideas? [from atsushi]
16:47:46 <Zakim> 2. Potential AR feature - point clouds [from atsushi]
16:47:46 <Zakim> 3. Allow dynamic frame timing [from atsushi]
16:47:46 <Zakim> 4. Feasibility and desirability of persisting anchors [from atsushi]
16:47:46 <Zakim> 5. Discussion: HTMLModelElement [from atsushi]
16:47:47 <Zakim> 6. Provide statistics to help guide performance [from atsushi]
16:47:47 <Zakim> 7. Review WebGPU API design [from atsushi]
16:47:47 <Zakim> 8. A feature that toggle stereo on runtime. [from atsushi]
16:47:47 <Zakim> 9. Discussion with OGC Geo Pose Standard Working Group [from atsushi]
16:58:29 <bialpio> bialpio has joined #immersive-web
16:58:49 <bajones> bajones has joined #Immersive-Web
16:59:03 <cabanier> present+
16:59:23 <atsushi> rrsagent, publish minutes
16:59:23 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/15-immersive-web-minutes.html atsushi
17:02:22 <lgombos> lgombos has joined #immersive-web
17:02:42 <bajones> present+
17:02:52 <bajones> (Come at me zakim!)
17:02:52 <cabanier> did I call into the right meeting?
17:03:07 <Nick-8thWall> Nick-8thWall has joined #immersive-web
17:03:19 <bajones> Rik, it should be: https://mit.zoom.us/j/98308045638?pwd=cHdaZzJlc3k1YlFpeGpJNjdhb2cxZz09
17:05:38 <cabanier> thanks. I think I dialed yesterday's first
17:05:40 <alcooper> present+
17:05:48 <atsushi> present+
17:07:28 <cwilso> present+
17:07:33 <bialpio> present+
17:08:23 <bialpio> heads-up, looks like the calendar at w3 already lists our today's mtg as "past event" so if you don't see it, go to "View past events"
17:09:04 <alexturn> alexturn has joined #immersive-web
17:09:46 <atsushi> ah, that's an existing issue, that we cannot view an event which is running. not in upcoming nor in past...
17:09:53 <atsushi> (has fixed??)
17:09:58 <cwilso> scribenick: cwilso
17:10:17 <atsushi> zakim, list agenda
17:10:17 <Zakim> I see 9 items remaining on the agenda:
17:10:18 <Zakim> 1. New proposal ideas? [from atsushi]
17:10:18 <Zakim> 2. Potential AR feature - point clouds [from atsushi]
17:10:18 <Zakim> 3. Allow dynamic frame timing [from atsushi]
17:10:18 <Zakim> 4. Feasibility and desirability of persisting anchors [from atsushi]
17:10:18 <Zakim> 5. Discussion: HTMLModelElement [from atsushi]
17:10:19 <Zakim> 6. Provide statistics to help guide performance [from atsushi]
17:10:19 <Zakim> 7. Review WebGPU API design [from atsushi]
17:10:19 <Zakim> 8. A feature that toggle stereo on runtime. [from atsushi]
17:10:19 <Zakim> 9. Discussion with OGC Geo Pose Standard Working Group [from atsushi]
17:10:21 <RafaelCintron> RafaelCintron has joined #immersive-web
17:10:22 <ada> https://github.com/immersive-web/proposals/issues/71
17:10:50 <ada> https://github.com/immersive-web/proposals/issues/70
17:11:24 <cwilso> ada: this is the new proposals idea issue - anything we might want to add to the new charter, or keep in the background.
17:12:01 <cwilso> ... something I already added is supporting 3d screen based hardware; do we want to add that to our charter.
17:12:24 <cwilso> ... does anyone want to suggest new things?
17:13:11 <bialpio> q+
17:13:17 <ada> ack bialpio
17:14:19 <cwilso> piotr: should we think about working on point clouds?  native apis have some capabilities about this; seems like it falls under RWG already, so probably don't have to add to charter explicitly
17:14:27 <atsushi> i|https://github.com/immersive-web/proposals/issues/70|topic: New proposal ideas?
17:14:32 <atsushi> rrsagent, publish minutes
17:14:32 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/15-immersive-web-minutes.html atsushi
17:14:49 <cwilso> nick: I would be generally supportive of point clouds; we do have a whole session to discuss later
17:15:02 <atsushi> s|Rik, it should be: https://mit.zoom.us/j/98308045638?pwd=cHdaZzJlc3k1YlFpeGpJNjdhb2cxZz09||
17:15:03 <atsushi> rrsagent, publish minutes
17:15:03 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/15-immersive-web-minutes.html atsushi
17:15:33 <cwilso> ada: how do people feel about adding 3D screen support, like dSpace etc
17:15:35 <alexturn> present+
17:15:42 <cwilso> q+
17:15:50 <alexturn> q+
17:15:52 <Leonard> Leonard has joined #Immersive-web
17:16:04 <cwilso> bajones: if something isn't in the charter, can we talk about it?
17:16:04 <Leonard> present+
17:16:29 <cwilso> ada: not off the table; ...
17:16:36 <Leonard> q+
17:16:51 <cwilso> nick: for 3d displays, seems like the views api would support this?
17:17:01 <ada> ack cwilso
17:17:04 <bajones> q+
17:18:13 <ada> ack ack alexturn
17:18:16 <ada> ack alexturn
17:18:28 <ada> q+
17:18:55 <cwilso> chris: if something isn't in the charter - not mentioned int he scope - it's probably not covered by the patent policy.  If you want the group to own it, you should probably make sure it's covered in the charter.
17:18:57 <ada> ack Leonard
17:19:21 <cwilso> alexturn: mentioning zspace thing - I would be supportive of adding that.
17:19:52 <cwilso> leonard:can the charter be less specific?
17:21:33 <ada> ack bajones
17:21:56 <cwilso> cwilso: charter can be vague - you're essentially licking the cookies, whether you are eating them or not (by putting them in deliverables)
17:22:13 <cwilso> ... Members may object to the charter because of that expanded scope, though.
17:22:50 <atsushi> q+ for (just comment...) we list some potential specs in current charter as under incubarion in IWCG, and I feel ok if we could include potential ones like them (at least) with one line of target area(s)...
17:23:04 <cwilso> brandon: it feels awkward to say we're going to put in the charter an entire new category of devices in order to potentially add one new flag.
17:23:15 <ada> ack ada
17:23:29 <cwilso> ... it's probably rolled into 3d css or the like,.
17:23:37 <Nick-8thWall> q+
17:24:11 <cwilso> ada: so maybe we should not have a specific deliverable, but say we're going to support immersive devices like immersive display technologies.
17:24:12 <cwilso> +1
17:24:16 <ada> ack atsushi
17:24:16 <Zakim> atsushi, you wanted to discuss (just comment...) we list some potential specs in current charter as under incubarion in IWCG, and I feel ok if we could include potential ones like
17:24:19 <Zakim> ... them (at least) with one line of target area(s)...
17:24:57 <cwilso> atsushi: in current charter we have several lines of incubation, so I feel it's better to include emerging areas through incubation.
17:25:19 <cwilso> ada: that's a good idea.
17:25:31 <cwilso> ... we do have a lot more flexibility through the community group.
17:25:40 <cwilso> ...CG isn't covered by our charter.
17:25:44 <cwilso> q+
17:25:54 <ada> ack Nick-8thWall
17:26:54 <cwilso> nick: mostly +1 to brandon, such a small patch on the existing spec (maybe not even a patch, just in implementation).  Understand process in general, but maybe let others know we have this covered.  It's basically mostly done - you might initially implement it as a desktop session.
17:26:56 <ada> ack cwilso
17:27:24 <ada> q+
17:27:25 <alcooper> q+
17:27:29 <Leonard> q+
17:28:42 <ada> ack ada
17:29:09 <cwilso> cwilso: should put in the charter; it's not a big deal, but we want to ensure it's in scope for patent policy reasons.
17:29:35 <cwilso> ada: this hardware didn't exist last charter, so we should like this cookie.
17:29:42 <cwilso> s/like/lick
17:30:11 <ada> ack alcooper
17:31:02 <cwilso> alexcooper: expanding scope is good; I think we shouldn't say we don't need to update the spec at all, devs probably need to have more information.  Non-normative notes, at least.
17:31:17 <cwilso> ... rendering to these different devices might be a little bit different
17:31:22 <ada> q?
17:31:24 <ada> ack Leonard
17:32:11 <alcooper> s/alexcooper/alcooper
17:32:14 <cwilso> leonard: two items:  audio; input from users' environment (note privacy concerns), and audio output (may be covered?). and 2, haptics.
17:32:23 <laford> laford has joined #immersive-web
17:32:24 <laford> +q
17:32:36 <ada> ack alcooper
17:32:40 <ada> present+
17:33:03 <cwilso> laford: on haptics, openxr does have support for haptics, but it's not that exciting - buzz-at-freq-for-time
17:33:11 <cwilso> ada: do we want to add haptics?
17:33:44 <cwilso> cwilso: isn't this covered by gamepad?
17:34:02 <cwilso> alcooper: yes, seems sufficient for our scenarios
17:34:09 <cwilso> ada: what audio would we need?
17:34:15 <cwilso> leonard: don't know
17:34:25 <atsushi> q+ for (just comment, no voice needed) non-normative notes are free from IP and we usualy state just as "Other non-normative documents may be created such as:" in charter
17:34:33 <ada> ack laford
17:34:50 <cwilso> laford: haptics is a volatile rabbithole.
17:34:52 <ada> ack atsushi
17:34:52 <Zakim> atsushi, you wanted to discuss (just comment, no voice needed) non-normative notes are free from IP and we usualy state just as "Other non-normative documents may be created such
17:34:53 <cabanier> q+
17:34:55 <Zakim> ... as:" in charter
17:35:04 <ada> q+ to mention haptic wear hardware
17:35:27 <ada> ack cabanier
17:35:29 <cwilso> atsushi: non-normative notes are free from IP commitment, so other documents could be created (that aren't Recommendations, and don't imply Patent Policy)
17:35:42 <ada> ack ada
17:35:42 <Zakim> ada, you wanted to mention haptic wear hardware
17:36:04 <cwilso> cabanier: we did request enhancing haptics on gamepad, but didn't get much traction
17:36:25 <dino> dino has joined #immersive-web
17:36:56 <cwilso> ada: one thing I've heard g4merZ talk about is haptic devices - like haptic suits or gloves.
17:37:05 <bajones> q+
17:37:10 <ada> ack bajones
17:37:57 <cwilso> brandon: I don't have visibility in every market, but I don't see too many efforts in haptic suits or gloves that are credible yet.
17:38:31 <cwilso> ...what is relevant is more full-body-tracking.  You can kind of stitch together today with the Vive tracking pucks.
17:38:48 <cwilso> ... I don't know what we would need to represent that
17:39:19 <cwilso> ... Also facial recognition, lot of research in pulling skeletons out of this data...
17:39:25 <cabanier> +1
17:39:29 <cwilso> ... in a totally non-creepy and non-threatening way...
17:39:46 <cwilso> ... seems more realistic than haptics
17:40:03 <cwilso> ... might want to add full-body-tracking to the charter
17:40:09 <laford> q+
17:40:21 <ada> ack laford
17:40:22 <cwilso> ada: I note we have loads more discussion before we send this charter in for approval.
17:40:50 <cwilso> laford: full-body tracking sounds like part of a subset of human understanding, which seems good to add.
17:41:04 <cwilso> OK, and on to issue 71
17:41:08 <atsushi> zakim, take up agendum 2
17:41:08 <Zakim> agendum 2 -- Potential AR feature - point clouds -- taken up [from atsushi]
17:41:12 <cwilso> scribenick: laford
17:41:34 <laford> bialpio: Last gaps between web and native APIs we have
17:42:03 <laford> bialpio: Is there much interest? Or is it too low level? No concrete proposals atm but we can work towards exposing info about point clouds underlying XR systems use to derive higher level features
17:42:09 <Leonard> q+
17:42:11 <laford> bialpio: What does the group think?
17:42:13 <ada> ack Leonard
17:42:25 <laford> Leonard: point clouds are potential GB in size
17:42:40 <laford> Leonard: how do you deal with that much data in memory or on the network?
17:42:52 <laford> Leonard: Is the tech fully ready yet?
17:43:02 <Nick-8thWall> q+
17:43:25 <laford> Leonard: Geospatial people are working on static point clouds. Apple consumer devices have lidar point cloud
17:43:38 <laford> Leonard: consumer may be in the order of hundreds of MB
17:43:48 <laford> Leonard: ISO is working on point cloud streaming
17:43:56 <yonet> yonet has joined #immersive-web
17:44:05 <ada> ack Nick-8thWall
17:44:07 <laford> Leonard: Idea is good, its a dangerous area to unwittingly wander into
17:44:25 <yonet> yonet +
17:44:27 <laford> Nick-8thWall: For us having a basic data structure would be useful
17:45:03 <laford> Nick-8thWall: our curved image target tracking within an immersive session requires extracting feature points so having access to a precomputed set of feature points directly would make our implementation much easier / cheaper
17:45:12 <yonet> present+
17:45:19 <Leonard> q+
17:45:22 <laford> Nick-8thWall: we could build curved tracking on point cloud and image texture api much more cheaply than raw
17:45:24 <ada> ack Leonard
17:45:41 <laford> Leonard: Is this data point cloud lidar or something separate?
17:46:06 <laford> Nick-8thWall: The point cloud collected by the device for tracking, whether lidar or image feature detection etc...
17:46:20 <bialpio> q+
17:46:27 <laford> Leonard: Would be useful to structure it in such a manner to not deal with data sets but device collected data
17:46:42 <ada> ack bialpio
17:47:16 <laford> bialpio: should look at it through the context of xr session. Would be a matter of exposing the data that xr systems are tracking currently to synthesize the higher level features
17:47:24 <laford> bialpio: would preclude working on big datasets
17:47:35 <Leonard> +1 for device tracking at the moment
17:47:37 <laford> bialpio: could be a point of simplification for the API
17:47:45 <laford> bialpio: only looked at it through the lens of AR
17:47:51 <laford> +q
17:47:54 <alexturn> q+
17:48:03 <laford> bialpio: is there an OpenXR equivalent
17:48:21 <laford> bialpio: how would this be implemented on as many devices as possible?
17:48:23 <ada> ack laford
17:49:18 <ada> ack alexturn
17:49:28 <laford> laford: no mechanism in OpenXR, for WMR devices it may be part of the secret sauce
17:49:41 <Jared_> Jared_ has joined #immersive-web
17:49:48 <laford> alexturn: Not necessarily the secret sauce but may just have been something we did not want to give out
17:50:19 <laford> alexturn: dont want devs taking too hard a dependency on the specifics on the point cloud
17:50:29 <laford> alexturn: e.g. training an ML model on hardware A and it doesn't work on hardware B
17:51:07 <laford> alexturn: Perhaps for ARCore/Kit it has stabalized enough to not worry about this?
17:51:47 <laford> alexturn: for hit-test apps that would have been agnostic may lock themselves in by choosing point cloud
17:52:05 <laford> alexturn: do user agents have to pretend they have the wrong type of data for compat?
17:52:33 <ada> q?
17:52:48 <laford> alexturn: may be approaching the point of technology specific but could accelerate algorithm development e.g. Nick's algo
18:02:15 <yonet> yonet has joined #immersive-web
18:04:15 <yonet_> yonet_ has joined #immersive-web
18:04:15 <ada> https://github.com/immersive-web/webxr/issues/1233
18:04:31 <laford> cabanier: Want to talk about optimizing how we deal with frame rendering
18:05:04 <laford> cabanier: in Oculus we get all poses and ask for a new texture. If not free, have to wait.
18:05:23 <laford> cabanier: OpenXR has a way to solve this
18:05:36 <laford> cabanier: with webxr layers you could kind of mimic it but its not explicit
18:06:30 <laford> cabanier: Oculus also has "phase sync". Which adjusts the display time based on your rendering overhead to minimize latency
18:06:45 <atsushi> i|https://github.com/immersive-web/webxr/issues/1233|topic: Allow dynamic frame timing|
18:06:46 <laford> cabanier: need to know the rendering stages though
18:06:49 <atsushi> rrsagent, publish minutes
18:06:49 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/15-immersive-web-minutes.html atsushi
18:07:01 <alexturn_> alexturn_ has joined #immersive-web
18:07:07 <laford> cabanier: could make it explicit for layers
18:07:35 <laford> cabanier: Would like to experiment with it
18:07:49 <laford> cabanier: is it already working on android?
18:07:59 <laford> q+
18:08:00 <ada> q?
18:08:03 <ada> ack laford
18:08:40 <RafaelCintron> q+
18:08:42 <laford> laford: Cass Everitt big driver of this on the OpenXR side
18:08:53 <bajones> q+
18:08:54 <ada> ack RafaelCintron
18:09:24 <laford> RafaelCintron: No objections in principle. Will need to restructure things to get pose data separate from rendering data
18:09:29 <alexturn_> q+
18:09:36 <laford> RafaelCintron: In a browser architecture, how much difference will it make?
18:09:38 <ada> ack bajones
18:09:42 <alexturn_> q-
18:09:46 <laford> RafaelCintron: If it is affective, seems like a win
18:09:48 <alexturn> q+
18:10:04 <laford> bajones: Right now there is separate mechanisms in the layers API for headpose and texture. Would that be sufficient?
18:10:53 <Nick-8thWall> q+
18:11:24 <laford> bajones: Feels like something that ideally should be best practice
18:11:43 <laford> cabanier: Could be a normative note?
18:12:30 <laford> bajones: having a note "if you spread out these calls backends may be able to rendering" seems like the basic step we should do here
18:12:38 <laford> * optimize rendering
18:13:33 <laford> Nick-8thWall: One thing to be aware of; We depend on the order of threejs operations. If these things get change in a material way, we'd want to make sure our experiences aren't broken
18:13:55 <laford> cabanier: Should be optional as to not break existing experiences
18:14:30 <laford> Nick-8thWall: The threejs implementation is a little too turn-key with no ability to manually drive it. Have to hook into the threejs systems that are restrictive
18:14:46 <ada> ack Nick-8thWall
18:14:57 <laford> Nick-8thWall: If we are rethinking threejs / webxr APIs maybe we should give more control to external apps and leave rendering to threejs
18:15:50 <laford> Nick-8thWall: example: "responsive scale", where experience are layed out in front of you where the dev intends them to be. We rely on threejs to update its own structures based on webxr poses, and we have to MITM them before threejs uses them
18:16:20 <laford> Nick-8thWall: Were they separate and control fell to WebXR this would be more convenient
18:16:38 <bajones> q+ to speak to three.js integration a bit
18:16:40 <ada> ack alexturn
18:17:42 <laford> alexturn: Worth pushing to see how far you can get. OpenXR is general based on how much runtimes want to optimize. Tricky to update pose half way through the frame causing a synchronous round trip all the way up and down the stack
18:18:07 <laford> alexturn: potentially an API for apps to ask for update poses. Things may be different in WebXR due to Asynchronicity
18:18:08 <cabanier> q+
18:18:09 <ada> q?
18:18:13 <ada> ack bajones
18:18:13 <Zakim> bajones, you wanted to speak to three.js integration a bit
18:18:57 <laford> bajones: Responding to Nick: Threejs does not directly control the direction of threejs. I agree that threejs is a little too turn-key.
18:19:47 <laford> bajones: the threejs devs like this and like the API to be opinionated. Coordination based on large scale restructuring may be tricky but they could be pursuaded
18:20:04 <ada> q?
18:20:04 <RafaelCintron> Ada, have you heard of Babylon.JS?
18:20:18 <ada> RafaelCintron:of course :)
18:20:25 <ada> I also like PlayCanvas
18:20:36 <ada> There is also wonderland
18:20:42 <ada> ack cabanier
18:21:16 <laford> cabanier: Replying to Alex: Used to offer getting updated poses during lifetime of frame, Didn't that go away in OpenXR?
18:21:45 <laford> alexturn: When you call xrLocateSpace you get the latest answer based on the time, so for the same time may get a more update pose later
18:21:58 <laford> alexturn: can leverage this for rendering by calling it at a later time
18:22:24 <laford> alexturn: we rely on locate space being instant, whereas in WebXR there is a whole process model that changes the dynamic
18:23:19 <laford> alexturn: xrFrame is more of the explicit model we used to have. Could see an xrFrame API for "getUpdatedPositions" which gives you a new xrFrame
18:23:39 <ada> q?
18:24:39 <ada> topic: Feasibility and desirability of persisting anchors
18:24:44 <ada> https://github.com/immersive-web/anchors/issues/69
18:25:04 <cabanier> scribenick: cabanier
18:25:25 <cabanier> ada: anchors are amazing and I want to share them
18:25:34 <cabanier> ... or hold onto them and share them later
18:25:46 <cabanier> ... some platforms have shareable anchors
18:26:02 <cabanier> ... they could be stored in the browser and used later
18:26:02 <Leonard> 1+
18:26:07 <alexturn> q+
18:26:08 <Nick-8thWall> q+
18:26:08 <bajones> q+
18:26:08 <Leonard> q+
18:26:13 <ada> ack alexturn
18:26:40 <cabanier> alexturn: there are transient anchors for making things more stable
18:26:59 <cabanier> ... there are persistent anchors for use across sessions
18:27:18 <cabanier> ... and there are shared anchors which have a cloud backend which are hard to standardize
18:27:38 <cabanier> ... unless UAs support all backends, it would be hard to standardize
18:28:11 <cabanier> ... magic leap lets you find the nearest anchor and you find the nearest post to that anchor
18:28:19 <ada> q?
18:28:22 <ada> ack Nic
18:28:22 <cabanier> ... MS lets you create an anchor and use it
18:28:40 <ada> q+ to ask about just leaving the anchor list populated
18:28:42 <cabanier> Nick-8thWall: I was going to say the same thing that alexturn said
18:29:16 <cabanier> ... the cloud based spatial location is more application level and not so much within the browser's scope
18:29:37 <cabanier> ... there are use cases for multi session but it seems less of a use case
18:29:51 <ada> q?
18:29:54 <cabanier> ... I don't think it's the highest priority
18:29:54 <ada> ack bajones
18:30:24 <cabanier> bajones: I was going to ask alexturn and Nick-8thWall to ask what OpenXR is doing
18:30:38 <cabanier> ... we want to get them on the same page
18:30:55 <cabanier> ... fundamentally it will be hard to standardize on our level
18:31:08 <ada> q?
18:31:11 <ada> ack Leonard
18:31:15 <cabanier> ... because it is very platform dependent
18:31:36 <ada> q?
18:31:38 <ada> ack ada
18:31:38 <Zakim> ada, you wanted to ask about just leaving the anchor list populated
18:31:46 <cabanier> Leonard: could the developer turn off anchors
18:32:04 <alexturn> q+
18:32:09 <cabanier> ada: are persistent anchors a stepping stone to shareable ones?
18:32:49 <ada> ack alexturn
18:32:50 <cabanier> ... if you have anchors enabled and you go to the same domain, you can find them again
18:33:23 <Nick-8thWall> q+
18:33:26 <cabanier> alexturn: we could find something that could be persistent across sessions
18:33:54 <cabanier> ... I don't know if it's trickier for phone based AR
18:33:55 <bialpio> q+
18:34:11 <cabanier> ... sharing is much more difficult
18:34:57 <cabanier> ... for instance we have different APIs for persistent and cloud API
18:35:08 <ada> q+ to suggest that maybe this is not the path
18:35:10 <cabanier> ... persistent anchor are a native API
18:35:20 <ada> ack Nick-8thWall
18:35:43 <cabanier> Nick-8thWall: I could walk through to the computer vision
18:36:01 <cabanier> ... if there's a key attached to an opaque blob
18:36:12 <cabanier> ... what does the blob contain?
18:36:27 <cabanier> ... there's a bunch of tech that goes into that re-identification
18:36:42 <cabanier> ... there are image level hashes to re-identify scenes
18:36:52 <cabanier> ... a lot of these technologies have magic
18:37:14 <cabanier> ... for instance google and MS use very similar technology
18:37:28 <cabanier> ... so their token might not be understood by each other
18:37:41 <cabanier> ... (point clouds)
18:37:53 <cabanier> ... even being future compatible with yourself is hard
18:38:11 <cabanier> ... so sharing across devices and vendors is hard
18:38:28 <ada> q?
18:38:29 <cabanier> ... even across session that are hard problems to be solved
18:38:35 <ada> ack bialpio
18:38:50 <cabanier> bialpio: talking about the 3 tiers
18:39:15 <alexturn> q+
18:39:18 <cabanier> ... on arcore you always need to go to the cloud to persist something
18:39:33 <cabanier> ... it seems that there is something that's browser level
18:39:49 <ada> ack alexturn
18:39:53 <cabanier> ... but the big unknown is to find a way to works everywhere
18:40:10 <cabanier> alexturn: local persistence skips the vendor problem
18:40:16 <bialpio> q+
18:40:19 <cabanier> ... and that over time things change
18:40:36 <cabanier> ... we don't hand the blob and just store things internally
18:40:58 <cabanier> ... in that world, there's more a chance that we have a common API
18:41:08 <ada> ack ada
18:41:08 <Zakim> ada, you wanted to suggest that maybe this is not the path
18:41:11 <bialpio> q-
18:41:13 <cabanier> ... right now we don't have a great way to share across
18:41:29 <cabanier> ada: it seems that persistence isn't the route towards sharing
18:41:38 <cabanier> ... and not that useful of a feature at all
18:42:06 <cabanier> ... last time we talked about this, we said we didn't want to share
18:42:11 <cabanier> ... and this hasn't changed
18:42:39 <alexturn> q+
18:42:40 <cabanier> ... maybe for the next version of anchors we could define a meta format
18:42:54 <cabanier> ... is this something that we want to do?
18:43:01 <ada> ack alexturn
18:43:03 <cabanier> ... or should we wait
18:43:13 <cabanier> alexturn: at the moment all the formats are opaque
18:43:27 <cabanier> ... my suspicion is that this is churning
18:43:51 <cabanier> ... we can't promise compat
18:43:51 <bialpio> q+
18:44:03 <cabanier> ... until things stabilize
18:44:18 <cabanier> ... there was a body that was trying to align this across vendors
18:44:22 <ada> ack bialpio
18:44:27 <cabanier> ... but I don't think we're at that point yet
18:44:40 <cabanier> bialpio: we might want to think about the use cases
18:44:52 <cabanier> ... I'm pretty excited about marker tracking
18:45:09 <cabanier> ... so you can localize multiple people at the same time
18:45:21 <cabanier> ... it can certainly help with thatr
18:45:29 <ada> q?
18:46:00 <yonet_> https://www.openarcloud.org/
18:46:03 <cabanier> alexturn: openarcloud.com was the group but it doesn't seem to have updated since 2019
18:46:19 <cabanier> s/openarcloud.com/openarcloud.org
18:47:52 <yonet_> RRSAgent, make minutes
18:47:52 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/15-immersive-web-minutes.html yonet_
18:50:54 <yonet_> chair:yonet_
18:51:25 <yonet_> topic: HTMLModelElement https://github.com/immersive-web/proposals/issues/69
18:53:03 <idris_> idris_ has joined #immersive-web
19:01:50 <dino> i will be there in 5 minutes
19:02:37 <dino> sorry that i'm late
19:06:04 <yonet_> Zakim, pick a victim
19:06:04 <Zakim> Not knowing who is chairing or who scribed recently, I propose alexturn
19:06:11 <dino> present+
19:06:55 <alexturn_> alexturn_ has joined #immersive-web
19:07:11 <yonet_> scribenick:alexturn_
19:07:26 <alexturn__> alexturn__ has joined #immersive-web
19:07:39 <alexturn__> scribenick: alexturn__
19:08:02 <alexturn__> dino: Recently, we made an explainer proposal for a <model> tag
19:08:21 <alexturn__> dino: The idea is to promote 3D models to be at the level of image and video on the web
19:08:30 <alexturn__> dino: Obvious issues are which file format to support, how to get consistent rendering
19:08:39 <alexturn__> dino: We still think this is a really good idea
19:08:39 <Leonard> q+
19:09:04 <yonet_> ack Leonard
19:09:06 <ada> q+ to ask about the charter
19:09:11 <alexturn__> dino: One thing we think this is useful for is as a WebXR layer - might be useful as an easy way to put a 3D model into WebXR as a layer
19:09:15 <bajones> q+
19:09:27 <alexturn__> Leonard: In general, in concept this is a good idea
19:09:30 <lgombos_> lgombos_ has joined #immersive-web
19:09:35 <alexturn__> Leonard: Helps folks incorporate 3D into regular web pages
19:09:46 <alexturn__> Leonard: Still a tremendous number of problems trying to display a simple model
19:10:05 <alexturn__> Leonard: Differences in look across browsers could be an issue
19:10:17 <alexturn__> Leonard: Wish to see a WebComponent similar to the model-viewer component Google has
19:10:19 <cabanier> q+
19:10:31 <alexturn__> Leonard: I think this is good to implement as a WebComponent but not as a web element
19:10:31 <alexturn__> q+
19:10:32 <yonet_> ack ada
19:10:33 <Zakim> ada, you wanted to ask about the charter
19:11:18 <alexturn__> ada: To Leonard's point, I actually think the lack of consistency across browsers is a feature, not a bug
19:11:29 <alexturn__> ada: Browsers can adapt the content to the limitations of the system
19:11:47 <alexturn__> ada: A developer in WebGL may not pay attention to the specs on a low-power device and could miss devices that can otherwise handle that content
19:12:16 <alexturn__> ada: Dean, do you think this would be a good thing to go into the charter?
19:12:24 <alexturn__> dino: I would love to see this go into the charter.
19:12:32 <alexturn__> ada: Cool!
19:12:39 <yonet_> ack brandon
19:12:47 <yonet_> ack bajones
19:12:52 <alexturn__> bajones: Agree that this belongs in the charter.
19:13:08 <dino> I'll wait until everyone speaks and then try to answer :)
19:13:11 <alexturn__> bajones: I've been somewhat vocal in my disagreement with this proposal online - I just want to be clear about the goals we're achieving here.
19:13:11 <dino> q+
19:13:25 <alexturn__> bajones: Not sure if a full tag is what we should do first here.
19:13:50 <alexturn__> bajones: Agreed that WebGL is hard!  I know it well and also find it difficult building compelling content.
19:14:10 <alexturn__> bajones: I do wonder whether the folks who would use this <model> tag are comparing it to the model-viewer component
19:14:31 <alexturn__> bajones: Should just be one include as the difference
19:14:45 <alexturn__> bajones: Whereas model-viewer has a lot of extra capabilities vs. what this proposal gets you
19:15:07 <alexturn__> bajones: If we move forward here, let's focus on the delta in what you can get compared to model-viewer today
19:15:14 <alexturn__> bajones: Ease of use is not likely one of those
19:15:38 <alexturn__> bajones: Better performance, faster parsing, better battery life could be key advantages here
19:15:50 <alexturn__> bajones: Not sure if we have these numbers yet.
19:16:19 <yonet_> ack cabanier
19:16:21 <alexturn__> bajones: Knowing the key advantages is important here
19:16:23 <Nick-8thWall> q+
19:16:32 <alexturn__> cabanier: One key advantage is that you could get the models to actually show up in 3D
19:16:53 <yonet_> https://modelviewer.dev/
19:17:00 <alexturn__> cabanier: WebXR needs permission prompts to get head poses - <model> would solve those issues.
19:17:09 <alexturn__> cabanier: Cross-origin stuff could be solved here
19:17:14 <Leonard> q+ ... lighting, etc.
19:17:22 <alexturn__> cabanier: Scrolling can be difficult to handle smoothly - native handling could solve that
19:17:40 <alexturn__> cabanier: How big can it be?  Is it constrained to a little area?  OS could manage constraints there
19:17:53 <alexturn__> cabanier: This would start simple but could solve issues over time
19:18:01 <yonet_> ack https://modelviewer.dev/
19:18:13 <cabanier> alexturn__: I agree with Brandon
19:18:17 <ada> alexturn__: to the points which cabanier was making, one key difference is the user viewing it on a headset or a falt display
19:18:18 <yonet_> ack alexturn__
19:19:09 <ada> ... what benefit are we getting from the component, for flat displays the benefits are ux like battery and performance. But for immersive hardware it's a huge ux benefit because it can actually have depth
19:19:32 <RafaelCintron> q+
19:19:45 <ada> ... what if people want to drag things out like you can with images in web browsers today. You could then do that with the model without the page needing to understand it
19:20:02 <ada> can drag it to other applications or to your desktop
19:20:16 <ada> s/can/... can
19:20:23 <yonet_> ack dino
19:20:35 <Leonard> q+
19:20:37 <ada> ... there are many benefits we can add in the flow of the page for a 3d model
19:20:59 <yonet_> ack ..., lighting, etc.
19:21:24 <yonet_> ack lighting
19:21:33 <yonet_> ack ...
19:21:39 <yonet_> ack etc.
19:21:46 <alexturn__> dino: Alex and Rick said many of the things I was thinking here.
19:23:07 <alexturn__> dino: Definitely useful for headsets - even for phones, folks have asked us for 3D models within 2D WebViews within AR scenes.
19:23:24 <bajones> q+
19:23:34 <laford> q+
19:23:38 <yonet_> ack Nick-8thWall
19:23:49 <dino> q+
19:23:57 <alexturn__> dino: Consistent rendering is a key thing to solve - MaterialX could help here as it tries to tackle that
19:24:18 <alexturn__> dino: Battery life and dragging out of the page are interesting too
19:24:52 <alexturn__> Nick-8thWall: Scenario of embedding 3D content within floating 2D WebView is indeed interesting
19:25:14 <alexturn__> Nick-8thWall: Coming at this from a different perspective on the developer side
19:25:34 <alexturn__> Nick-8thWall: I generally want to give power to developers here - if developer can do it or browser can do it, I want to give power to developers
19:25:49 <alexturn__> Nick-8thWall: Developers rarely want to stop at simple 3D content - they want interaction as well
19:26:00 <alexturn__> Customization is important too, even for a simple viewer
19:26:09 <alexturn__> Nick-8thWall: Customization is important too, even for a simple viewer
19:26:19 <cwilso>  q+ to address the two elephants in the room.
19:26:31 <alexturn__> Nick-8thWall: If we prematurely put things behind a <model> interface, we may cut off experimentation in that regard
19:27:00 <alexturn__> Nick-8thWall: Is there another session type here as a looking-glass immersive session
19:27:17 <alexturn__> Nick-8thWall: Could that be done programmatically?
19:27:40 <alexturn__> Nick-8thWall: In terms of efficiency, I think there's a tendency to lean on these concerns too much
19:27:51 <alexturn__> Nick-8thWall: We've seen great strides in SIMD in WebAssembly over time
19:28:10 <alexturn__> Nick-8thWall: The web tends to get more efficient over time, whereas the perf concerns at the beginning of a standards process fade over time
19:28:31 <yonet_> ack RafaelCintron
19:28:36 <alexturn__> Nick-8thWall: I would always advocate for tech that lets better products get built rather than a cookie-cutter mold
19:28:52 <bialpio> q+
19:28:55 <alexturn__> RafaelCintron: Dean shared a lot of my points
19:29:05 <cwilso> q- later
19:29:24 <alcooper> q+
19:29:49 <alexturn__> RafaelCintron: Permissions are simpler here - all you have to do is let things pop out, rather than allowing scene understanding, etc.
19:30:09 <alexturn__> RafaelCintron: Accessibility can be better too - can have special modes that browsers support such as wireframe mode that don't require pages to participate
19:30:19 <alexturn__> RafaelCintron: None of this should replace anything that exists
19:30:22 <yonet_> ack Leonard
19:30:38 <alexturn__> Leonard: Several people have mentioned lighting - we've looked at this extensively in Khronos
19:30:58 <alexturn__> Leonard: In Commerce, people want the product to look exactly right - not just lighting but tone-mapping after rendering
19:31:17 <alexturn__> Leonard: Without a reference here, I'd be very concerned
19:31:33 <alexturn__> Leonard: Folks at Google have talked about getting the tone mapping exactly right with model-viewer
19:31:51 <alexturn__> Leonard: People have talked about VR vs. AR - AR lighting is trickier
19:32:10 <alexturn__> Leonard: Point lighting vs. other lighting can be an issue with PBR
19:32:33 <alexturn__> Leonard: Format evolution can be another concern if some browsers don't support newer model formats
19:32:48 <yonet_> ack bajones
19:32:52 <alexturn__> Leonard: If we can't have a path forward for model formats, feels way premature
19:33:02 <alexturn__> bajones: Glad Leonard brought up the lighting work in Khronos
19:33:26 <alexturn__> bajones: A lot of work to take PBR from glTF and add extensions for lighting that retailers find important and ensure it appears consistent in multiple renderers
19:33:44 <alexturn__> bajones: We have tests to ensure that three.js and Google's Filament and Babylon are all within tolerance
19:34:01 <alexturn__> bajones: This is important work that is already being done and it'd be a mistake to not lean on that
19:34:40 <alexturn__> bajones: The model format that this thing hinges off of is going to be enormously important
19:34:50 <alexturn__> bajones: If we end up in a situation where browsers can pick and choose which formats to choose and not have at least one shared format, that will be strictly worse than where we are today
19:35:10 <alexturn__> bajones: It would be a very sad state of affairs if one browser supports one format and one supports another and not have one unified format
19:35:19 <alexturn__> bajones: We don't want to repeat the mistakes of video tags past
19:35:46 <alexturn__> bajones: Even if we have the <model> tag, we should make sure we can still experiment in that same space with lower-level primitives
19:35:47 <cabanier> q+
19:36:00 <dino> dino has joined #immersive-web
19:36:02 <alexturn__> bajones: We did talk about having inline sessions with some level of head-tracking
19:36:21 <alexturn__> bajones: Has some issues and limitations around permissions
19:36:39 <alexturn__> bajones: Also would create problems rendering outside the bounds of the page
19:36:59 <alexturn__> bajones: Would be good to make sure we can still experiment outside the bounds of the tag
19:37:16 <alexturn__> laford: Just wanted to voice support for the concept in general - really like the idea
19:37:21 <yonet_> ack laford
19:37:43 <alexturn__> laford: Rather than having WebGL separate from the DOM - having 3D models be part of the 2D DOM
19:38:01 <alexturn__> laford: Even just having the ability to saying this is inline 3D content and seeing what browsers do with that
19:38:14 <alexturn__> laford: Phones will treat it differently than desktop and different than headsets
19:38:30 <alexturn__> laford: Moving content around can be enabled if everyone knows what is going on with the tag
19:38:32 <yonet_> ack dean
19:38:37 <yonet_> ack dino
19:38:48 <alexturn__> dino: Just to be clear, this is definitely not trying to replace model-viewer or WebGL or anything like that
19:39:07 <Nick-8thWall> q+
19:39:08 <alexturn__> dino: I did research the model-viewer's excellent research into lighting in the explainer
19:39:12 <yonet_> yonet_+
19:39:17 <ada> q+
19:39:19 <yonet_> q+
19:39:34 <alexturn__> dino: The lighting problems mentioned apply to WebGL viewers as well - we need to explore this no matter what
19:39:35 <yonet_> q-
19:39:52 <alexturn__> dino: Understand the need for a single format - video has one today even if not in the spec
19:40:11 <alexturn__> dino: Not mentioning glTF just an oversight
19:40:42 <alexturn__> dino: Even if you look at these different scene formats, they are fairly similar and I could imagine an API level here
19:40:57 <yonet_> ack bialpio
19:41:13 <alexturn__> dino: The explainer proposal would be just a start
19:41:58 <alexturn__> bialpio: The permissions benefit only works if we don't let the app read back things that could be dangerous
19:42:08 <dino> good points bialpio! Internally we joke about this as "VRML5"
19:42:11 <alexturn__> bialpio: Might start simple but could grow into something very complicated to support
19:42:12 <yonet_> ack cwilso
19:42:12 <Zakim> cwilso, you wanted to address the two elephants in the room.
19:42:31 <alexturn__> cwilso: Happy to see that one of the elephants in the room was brought up around formats
19:42:45 <alexturn__> cwilso: Building standards is for improving interoperability - need a baseline of support
19:43:11 <alexturn__> cwilso: If we come up with a <model> tag that can't be used consistently everywhere, we haven't made things more consistent
19:43:27 <alexturn__> cwilso: Also worth noting that if we propose a new tag, this will ultimately just be a proposal to the WHATWG HTML WG
19:43:34 <yonet_> ack alcooper
19:43:38 <alexturn__> alcooper: Kind of wanted to go back a little bit to WASM and SIMD
19:43:47 <dino> +1 to what cwilso said. Can incubate here, but would have to go to WHATWG eventually.
19:44:02 <alexturn__> alcooper: Looked into face mesh support in the WebXR APIs and a lot of developers told me the perf gains wasn't worth the tradeoff
19:44:04 <alexturn__> q+
19:44:35 <alexturn__> alcooper: A lot of people brought up other things we just can't do that might be better tradeoffs
19:44:52 <yonet_> ack cabanier
19:45:34 <alexturn__> cabanier: Just want to note around performance that we are still adding things to the spec to fix performance - that will still be the primary gotcha for years to come
19:46:10 <alexturn__> cabanier: For inline models, each session would need its own full-screen buffer - may be a non-starter
19:46:10 <alexturn__> q-
19:46:34 <alexturn__> cabanier: Video tag has had format gotchas, but it wasn't fatal - things go on even with less common formats also supported
19:46:48 <alexturn__> cabanier: Just to have 3D content pop out, I don't think we need permission prompts there
19:46:50 <yonet_> ack Nick-8thWall
19:46:57 <alexturn__> Nick-8thWall: Just want to respond to a few things
19:47:03 <bajones> re: Rik's comment about performance and needing fullscreen contexts - that would only be the case if you were rendering above the page. You could still do a lot of interesting work rendering behind it though a cutout window that's bounded to the canvas.
19:47:29 <bialpio> re Rik: correct, my point was that you need to stay declarative if you want to skip permission prompts
19:47:29 <alexturn__> Nick-8thWall: To the point about performance not being there, just want to thank you for doing the work to improve perf for everyone - it does pay off for the community!
19:47:43 <alexturn__> Nick-8thWall: Heard some conversations about declarative vs. imperative
19:47:54 <bajones> Also, certain limitations of WebGL won't carry over the WebGPU where, for example, you'll be able to have a single device driving multiple canvases.
19:48:14 <alexturn__> Nick-8thWall: Heard the permissions issues around imperative APIs
19:48:25 <alexturn__> Nick-8thWall: Ease of use is not really an issue since you can wrap declarative APIs around imperative APIs
19:48:30 <alexturn__> q+
19:48:39 <alexturn__> Nick-8thWall: Just want to make sure we're honest there about the benefits
19:49:01 <alexturn__> Nick-8thWall: Nobody believes we're here to remove WebGL/WebXR
19:49:22 <alexturn__> Nick-8thWall: If there are things the browser can do in a privileged way, that can hold back innovation and land us on suboptimal solutions
19:49:40 <alexturn__> Nick-8thWall: In the same way the web evolved from <image> to <canvas>, that should be the way we look here
19:50:09 <alexturn__> Nick-8thWall: If we have some way to make things interactive, we can allow more innovation
19:50:19 <alexturn__> Nick-8thWall: Need to be careful not to privilege innovation in browser over innovation in developer
19:50:21 <yonet_> ack ada
19:50:45 <yonet_> ack alexturn__
19:50:46 <dino> alexturn__: Great discussion. I think we'd benefit from a clustering of topics
19:51:05 <dino> alexturn__: there is a spectrum of how convincing they are. i agree ease of use is the least convincing.
19:51:50 <dino> alexturn__: and yes, perf might be transient. the most important ones to me are about user experience. with bucketing of topics we might be able to easily identify these things. the explainer should do this.
19:52:33 <dino> alexturn__: e.g. img v canvas - even though canvas is a superset, it hasn't replaced img.
19:52:43 <dino> alexturn__: i suspect there is room for both approaches
19:53:34 <dino> ada: one big advantage we get from this is better accessibility. a gltf that has been marked up in a way that can be exposed to a screen reader would be a significant benefit.
19:54:11 <dino> ada: also, the ability to add annotations and click events into a <model> (like image maps) makes a lot of sense
19:54:24 <bajones> q+ to mention that model-viewer does have accessibility support and hotspots
19:54:54 <dino> laford (via chat): image -> canvas === model -> webgpu / webxr
19:54:54 <dino> Image: User interpretation of content, with all the browser bits and pieces (events, accessibility etc...)
19:54:54 <dino> Canvas: Developer wants this to behave and look a specific way so sacrifices the benefits of the tag
19:54:54 <dino> Analogously a basic model tag is the image and WebGPU / WebXR is the Canvas
19:55:33 <dino> ada: e.g. click on a entity that has some identification, that can be exposed to the accessibility system
19:55:39 <bialpio> (from meet chat): <video> is to WebCodecs as <model> is to WebXR ?
19:55:44 <bajones> +1
19:55:46 <cabanier> +1
19:55:54 <laford> +1
19:56:03 <RafaelCintron> +1
19:56:04 <dino> +1
19:56:12 <bialpio> +1
19:56:16 <alexturn__> +1
19:56:24 <Leonard> What Ada just said implies (to me) that one or more example Web Components really should be developed first
19:56:30 <ada> +1
19:56:32 <Leonard> +1 for charter inclusion
19:56:50 <alexturn__> WebCodecs is sort of halfway between - I liked Dino's idea of perhaps having an API breakdown of a scene loader format which could then allow "model codecs" still with the benefits of the <model> tag
19:56:55 <alcooper> +1
19:57:19 <alexturn__> q+
19:57:31 <dino> bajones: <model-viewer> does support ids, hot-spots, etc. It loses some of that information when handing that off to the AR view on iOS.
19:58:08 <dino> yonet_: what formats does <m-v> support>? what would happen if i uploaded a CAD file?
19:58:30 <dino> bajones: mostly glTF. it's based on three.js so maybe you could show other models.
19:58:40 <dino> bajones: given a huge file, it will try...
19:59:28 <ada> q+
19:59:28 <Nick-8thWall> q+
20:00:01 <yonet_> ack bajones
20:00:01 <Zakim> bajones, you wanted to mention that model-viewer does have accessibility support and hotspots
20:00:48 <dino> laford (from chat): XR Scene Markup may find its time soon if it ends up being a markup mapping of stable formats like GLTF and USDZ
20:01:54 <yonet_> ack alexturn__
20:01:54 <bajones> Leonard: the game is https://spookyball.com
20:02:18 <bajones> Source is at https://github.com/toji/spookyball
20:02:25 <Nick-8thWall> "Your browser doesn't appear to support WebGPU. (Scary!) This game requires WebGPU support." =(
20:02:53 <bajones> And the model I mentioned specifically is https://github.com/toji/spookyball/blob/main/media/models/graveyard-compressed.glb
20:03:11 <bialpio> alexturn__: <model> tag can become another backend to <model-viewer>
20:03:13 <yonet_> ack ada
20:03:52 <alexturn__> ada: Do any of the model loaders support progressive loading?
20:04:21 <alexturn__> ada: Like progressive JPEG?
20:04:39 <alexturn__> Leonard: Models have a front and back - a smart loader could decide not to load the back faces
20:04:56 <alexturn__> Leonard: Turns out the biggest thing to avoid loading is the textures more than vertices
20:05:15 <bajones> https://doc.babylonjs.com/divingDeeper/importers/progressiveglTFLoad
20:05:21 <alexturn__> ada: Could we load the small texture sizes and small vertex detail first?
20:05:39 <alexturn__> Leonard: Can certainly do that work - generalized 3D case is tough to solve
20:06:31 <alexturn__> bajones: Posted a link to Babylon's progressive glTF loading based on the MSFT_lod extension
20:06:47 <alexturn__> bajones: Can also go grab specific mip levels manually in an imperative approach
20:06:55 <yonet_> ack Nick-8thWall
20:07:10 <alexturn__> Nick-8thWall: Around different model formats, one thing we find popular is different hologram-type formats
20:07:29 <alexturn__> Nick-8thWall: At least 4 separate formats we support now
20:07:43 <alexturn__> Nick-8thWall: Capture and streaming formats
20:07:53 <alexturn__> Nick-8thWall: If they're not part of the standard, they'd lose out
20:08:03 <alexturn__> Nick-8thWall: Having an ability to have different players would be very useful
20:08:14 <alexturn__> bajones: Can you explain what you mean by "holographic"?
20:08:19 <alexturn__> Nick-8thWall: Volumetric video formats
20:08:25 <alexturn__> Nick-8thWall: Capture of a person played back in 3D
20:08:43 <alexturn__> Nick-8thWall: Microsoft HCAP format based loosely on glTF
20:08:53 <Leonard> MPEG (within ISO) is currently working on standardizing things like that.
20:08:59 <yonet_> topic: Provide statistics to help guide performance https://github.com/immersive-web/webxr/issues/1203
20:09:23 <Leonard> Thank you for all of the discussion -- very enlightening
20:10:11 <yonet_> topic: Review WebGPU API design at TPAC https://github.com/immersive-web/WebXR-WebGPU-Binding/issues/3
20:10:23 <yonet_> RRSAgent, make minutes
20:10:23 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/15-immersive-web-minutes.html yonet_
20:10:27 <alexturn__> ada: Dean, any additional topics for the charter?
20:10:36 <alexturn__> ada: Ahh, schucks - he had to drop
20:11:56 <Nick-8thWall> Here are some examples of non-gltf:
20:11:59 <Nick-8thWall> https://www.8thwall.com/playground/hcap-relight
20:12:12 <Nick-8thWall> https://www.8thwall.com/playground/ply-loader
20:12:24 <Nick-8thWall> https://www.8thwall.com/playground/tetavi-threejs
20:12:40 <Nick-8thWall> https://www.8thwall.com/playground/depthkit-aframe
20:12:55 <Nick-8thWall> https://www.8thwall.com/playground/threejs-8i
20:31:31 <yonet_> Zakim, choose a victim
20:31:31 <Zakim> Not knowing who is chairing or who scribed recently, I propose bialpio
20:31:36 <bajones> Slides! https://docs.google.com/presentation/d/1wXzcwB-q9y4T5VL9sKRhAWz_2nvwAWdFtTvVgk43rlk/edit#slide=id.p
20:32:39 <bialpio> bajones: want to go back to yesterday's discussion about projection matrices / viewports
20:32:46 <yonet_> scribenick: bialpio
20:33:20 <yonet_> PR with a link to the 3DModel Schema definition: https://github.com/google/model-viewer/pull/2853
20:33:22 <bialpio> ... new proposal to bridge the differences
20:33:43 <bialpio> ... this is a part of layers API since WebGPU is only going to work w/ layers
20:34:23 <bialpio> ... we can have both the viewport and projection matrix on XRSubImage
20:34:38 <bialpio> ... we end up with 2 projection matrices, one from layers and one from XRView
20:34:52 <bialpio> ... we may deprecate the XRView one
20:35:23 <bialpio> ... we also have layers that don't have projection matrix, it can be null there
20:35:35 <bialpio> ... may be a bit weird but not terrible
20:36:12 <bialpio> ... alternative would be to put a new method on the Web[GL/GPU] bindings that returns the matrix
20:36:39 <bialpio> ... alternative "solution" is to say that this is a problem and provide the developers with the math that has to happen
20:36:57 <bialpio> ... but that is not nice
20:36:59 <cabanier> q+
20:37:08 <bialpio> ... what do people think?
20:37:20 <yonet_> ack cabanier
20:37:26 <bialpio> cabanier: I prefer optional attribute on XRSubImage
20:37:45 <RafaelCintron> q+
20:38:01 <yonet_> ack RafaelCintron
20:38:19 <bialpio> RafaelCintron: thanks for solving, not particularly opinionated, we need to decide what to do when people use the original one
20:38:32 <bialpio> ... ok to add a warning for that
20:38:55 <alcooper> q+
20:38:56 <bialpio> bajones: we should be able to add a warning when we see WebGPU being used
20:39:28 <bialpio> ... the worst case scenario is if that warning gets ignored is that the site lost half of its depth precision
20:39:44 <cabanier> q+
20:39:50 <bialpio> ... mild enough failure that it should be sufficient to just nudge developers
20:39:56 <yonet_> ack alcooper
20:40:07 <bialpio> alcooper: any reason to prefer nullable vs returning identity?
20:40:30 <bialpio> bajones: identity is the wrong thing for all the non-projection layers
20:41:07 <bialpio> ... 2 main buckets: I have a pre-rendered content that I'm copying onto a layer or I'm actually doing the rendering but it's not aligned with the scene and has its own proj matrix
20:41:33 <bialpio> ... there's not really a good matrix that we can hand out
20:41:56 <bialpio> cabanier: agree w/ Brandon
20:41:59 <yonet_> ack cabanier
20:42:42 <bialpio> ... could we make the warning more aggressive? i.e. maybe remove the attribute if we detect a dev is using WebGPU?
20:42:57 <bialpio> bajones: yes, but that would be a breaking change, but worth considering
20:43:24 <bialpio> ... consequences of using the wrong matrix are mild so maybe that's too big stick to use
20:43:43 <bialpio> cabanier: consequences are mild so you won't be able to easily see you're doing the wrong thing
20:44:16 <bialpio> ... even though it's a breaking change to the spec, but it won't break any existing content (because you need to take extra steps for this to trigger)
20:44:38 <bialpio> bajones: will send a PR against layers spec
20:45:04 <bialpio> ... next thing: retrospective / post-mortem on layers spec
20:45:38 <bialpio> ... for the most part seems to be well-aligned, question to Rik: how is the rollout going? any issues?
20:46:19 <bialpio> cabanier: we have not seen too much usage, we're seeing media layers being used
20:46:31 <bialpio> ... a-frame supports layers so some samples pop up
20:46:55 <bialpio> ... most issues we're seeing are not related to the spec (i.e. lack of multisampling, some multisampling doesn't work with foveation)
20:47:21 <bialpio> ... if you use projection layers things are slower compared to vanilla WebXR so focusing efforts there
20:47:39 <bialpio> bajones: hoping to address lack of layers in chrome
20:48:09 <bialpio> ... clarification on issues w/ multisampling: is this an issue with something in the driver level?
20:48:23 <bialpio> cabanier: we use GL_EXT_multisampling (?) extension
20:48:52 <bialpio> ... if you use that you lose foveation (bad for performance) and we'd like to have both, but that's not currently possible
20:49:38 <bialpio> bajones: let's discuss further; with WebGPU multisampling is something that the user needs to explicitly set up
20:50:19 <bialpio> ... there may be some concerns, because if foveation is supposed to happen on a multisampled buffer, we don't have a solution for that
20:50:41 <bialpio> cabanier: porting layers to OpenXR, not finished but working on it
20:51:17 <bialpio> bajones: OpenXR is used for desktop, Chrome and Edge should go through the same path
20:52:00 <bialpio> cabanier: we're hooking into same code, not ready to share yet but hopeful that it'll be possible soon
20:52:48 <bialpio> cabanier: we can chat during weekly call
20:53:16 <yonet_> The OGC GeoPose Standard Working Group (SWG) is the correct name, however, it is not a W3C working group. It is a SWG of the Open Geospatial Consortium, with whom W3C has a liaison.
20:53:18 <bialpio> ada: would be good to discuss what we want to talk about with Geo
20:54:16 <bialpio> ... are we interested in it? are we just sitting on it?
20:54:16 <yonet_> https://www.ogc.org/projects/groups/swg
20:54:34 <Leonard> GeoPose spec for comments:  https://mail.opengeospatial.org/lists/lt.php?tid=fR5RAlIEAQdSBR1SBQhTSFADVA4ZCQdXBRlfUwUFCwADUQlRXFRKBlIFUVAFXFZIVw9SAhkEBQdXGQBSUlMVBlQBBQdcAQBWBAJRGVALVlJdVgcEGVIJBlQZDQcFUhUPBFsIGVZbBQZTUQkBBwpTBw
20:54:49 <bialpio> ada: any interest?
20:55:09 <bialpio> Leonard: I'm interested, mostly coming from Khronos
20:55:28 <Leonard> Comments on spec -  https://github.com/opengeospatial/GeoPose
20:55:41 <bialpio> ada: early WebXR decisions may have been made with the assumption that we may need geopose alignment
20:56:03 <bialpio> ... looks like we don't expect any work to be done in this area
20:56:14 <bialpio> cabanier: are we committing to anything?
20:56:24 <bialpio> ada: no, just checking where we are and where they are
20:56:48 <bialpio> ... is there anyone with a tiny interest in geoalignment?
20:56:56 <bialpio> yonet: maybe hololens
20:57:22 <bialpio> ada: not comfortable with representing the group's interest in that forum
20:58:14 <bialpio> bialpio: question re persistent / shared anchors - can this be related?
20:58:27 <bajones> Sorry, I have to drop off just a little bit early to pick up kids from school.
20:58:37 <bajones> Great discussion, everyone! Thanks!
20:58:46 <bialpio> ada: not necessarily, mostly about landmarks poses
20:59:06 <bialpio> cabanier: I can ask around if there are people working on something
20:59:44 <bialpio> ada: would be good idea for someone to show up to the meeting and share the status
21:00:15 <bialpio> Leonard: some devices can already support something related with GPS being available
21:00:40 <RafaelCintron> q+
21:00:44 <bialpio> ada: should we remove geo alignment from our charter? no work has happened in 2 years
21:00:54 <yonet_> ack RafaelCintron
21:01:14 <bialpio> RafaelCintron: personally no opinion, Alex Turner will have the most context
21:01:36 <bialpio> ada: I'll add a proposal to remove geoaligment from the charter
21:03:07 <bialpio> bialpio: double-check the timezones
21:03:19 <bialpio> Leonard: updated invite coming soon
21:05:35 <bialpio> yonet: minutes should be available in administrivia
21:05:54 <bialpio> Leonard: let's summarize action items on the issues that have been discussed
21:06:12 <bialpio> ada: any objections to skipping the upcoming meeting?
21:06:26 <bialpio> ... next one would be Nov 2
21:08:20 <bialpio> ... if you need a meeting, email the chairs and ask
21:08:49 <bialpio> ... that's it!
21:09:59 <yonet_> RRSAgent, make minutes
21:09:59 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/15-immersive-web-minutes.html yonet_
21:10:28 <yonet_> RRSagent, make log public
21:10:28 <ada> thanks, i almost forgot
21:10:45 <yonet_> Go to bed, thanks
23:59:59 <scribe> i/alexturn__: I agree with Brandon/scribe: cabanier/
23:59:59 <scribe> i/alexturn__: to the points which cabanier was making/scribe: ada/
23:59:59 <scribe> i/dino: Alex and Rick said many of the things/scribe: alexturn__/
23:59:59 <scribe> i/alexturn__: Great discussion. I think we'd benefit from/scribe: dino/
23:59:59 <scribe> i/Leonard: the game is https/scribe: bajones/
23:59:59 <scribe> i/alexturn__: <model> tag can become another backend/scribe: bialpio/
23:59:59 <scribe> i/ada: Do any of the model loaders support progressive/scribe: alexturn__/
23:59:59 <scribe> i/bajones: want to go back to yesterday's discussion/scribe: bialpio/