Meeting minutes
<ada> I am running a little late
<ada> can someone paste the URL for the call here?
<ada> nevermind naseemshah isn't online right now
<bajones> I'll look at it ASAP!
webxr-hand-input#32 Allow caching of XRJointPoses
scribe Leonard0
Manish: not cache poses (XR & XRViewer) because some content may break
… https://github.com/immersive-web/administrivia/blob/master/meetings/cg/2020-07-28-Immersive_Web_Community_Group_Teleconference-agenda.md
… Hand has ~25 joints/hand which could overwhelm the system that needs to created & destroyed every frame
… Rik propose allows browsers to cache XR joint poses to reduce load
… This would come with the warning that the objects may or may not stay around
Brandon: Agrees, but like Manish, not very happy.
… 2 other interact with cache and not always with consistent settings
… Possibility of comparing the frame N & N+1 may cause some problems with "measured" velocity
Manish: Some conditions are not related to real movements
Rik: Some things change nothing to very little over time.
Alex: Share concern that semantics are changing. Hand joints are "medium" data. Meshes are "large" data.
… Joint comparison may fail because of UA differences. Want it either every frame or all frames, nothing in-between
… However, it may not work through multiple (other) APIs
<yonet> bialpio
Bialpio: Can the caching state be signaled through API state? Need to be concerned with timing or values
<Zakim> bajones, you wanted to also ask about consolidating volumes of pose queries to a single call
Brandon: Likes signaling. Getting hand poses causes some internal delays (Runtime to native interface).
… Suggests a means for getting a list of poses and output a predetermined data structure
Manish: Agrees with Brandon. OpenXR aligns with Brandon's suggestion - returns a struct with all hand-joints
… works on shared structure that gets reused
Alex: OpenXR did a constant check against use cases and "actual" code. Engines preferred to use bulk data structure
… though, acknowledged that it was cumbersome for people developers
… More likely use WebXR over OpenXR, but still could use bulk
Ada: [lots of background noise - missed most of this]
<Zakim> ada, you wanted to like that idea
Manish: JavaScript can do most everything that can be done through OpenXR -- the APIs can be similar
Alex: Wants to consider UAs returning subsets of joints. Does not want to limit innovation
<ada> sorry about my noisy mic: I was suggesting that by having a split API it would enable the high perf use case of using the buffer to enable displaying the hand model but also allow developers to query individual joints in a way they would expect for things like physics or interactions.
Alex: use extra or removed joints. You get everything or nothing. Some joints may be marked as unavailable or emulated
Leonardo: would any of these decisions have a bad impact on someone who is disabled
… or has attachments or something that would make them not fit the humanoid model
Leonardo: Would any suggestions compromise use for disabled or
Alex: Has thought through some level of accessibility. Level of API should be separate from user abstraction -- that would be the UA job
Brandon: Alex covered most issues. Similar conversations about accessibility: Can provide data for website
… to do the right thing; however, websites may not choose to do so (ignore accessibility)
<Manishearth> https://github.com/immersive-web/webxr-hand-input/issues/11
Brandon: Probably allow UA to be configured to allow a user to specifically configure their own environment
Manish: (See link above). No specific answers. 2 concerns:
… 1: Application should be written so they can get a hand representation according to user's desire
… 2: Gesture apps should have fall-back gestures (missing digits, etc.)
Alex: Caution to wait before going beyond core. Native side may have further divergence. Believe APIs should be
… base-level agreement. Only go beyond when requested and/or needed.
… Allow the API to return the "standard" actions, but "enlightened" apps could access the details
Manish: Agrees with Alex
Alex: Double-check with Rik. Wants to make sure that unneeded legacy is not carried forward
anchors#55 Should move discussion and API for "creating anchor from hitTestResult" to hit-test API
Diane: Anchor depends on Hit-Test (APIs)
… Move from Anchor to Hit-Test explainer so that Anchor is stand-alone and Hit-Test contains all dependencies
Piotr_(Bialpio): Concerned that Hit-Test is marked as release. If Anchor is moved, then a clarification would be needed
… Like to delay move until Anchor and HT are at same level of maturity
Diane: Asking of level of maturity of Anchors. Doesn't want to go forward until the change is moved
Piotr: Anchors go out in V85 (stable in about a month - 25 Aug)
Brandon: This scenario probably going to be encountered more frequently.
… Probably benefit WG figuring out how to handle the general case for the future
Aysegul: Continue discussion on GitHub.
Manish: Item for WG. Ada to handle