Meeting minutes
Initial attempt at a comfortSpace (webxr#1349)
<ada> https://
Ada: Link is to straw-man (person?) proposal to see what is necessary. Defined by UA to be a "good" place
… for hand-interaction content.
… intent is to put standard hand-interaction space in reasonable location of a person in various poses.
… Should be dynamic to account for personal movement.
Brandon: Previously devices should be able to determine "comfort" space.
… Need to determine expectations for how objects are to fit within space (on floor, on wall, on tilted-table)
… Concerned about orgin and placement.
ada: yes, it will be defined as the tabletop position
… I will update the PR
blair: from what brandon said, figuring out the space...
… figuring the volume of reach might be importan
… if people have reduced mobility or are on an airplane
… you can imagine with world mapping, it can infer some of that for you
… the app would get this world mapping without exposing the world
<bajones> +1!
cabanier: my only concern is that this is not supported on the OS level
bajones: +1 on the bounds idea. We already have a volume
… as for the concern, we already have spaces that we just emulate so we can do the same here
… I don't mind the phrasing of comfort space
… but am concerned about the 'on top' phrase
… a desk will be a popular item
… maybe a more popular name would be to use it as a desk space
+1
… but I could go either way on that
ada: do we specify a height for bounded reference space?
bajones: we do not
ada: maybe it should be a bounding box.
… it would imply that it would be a desktop
bajones: openxr defines a playspace as a bounding box
cabanier: maybe putting it on top is a bit too limited
bajones: creating a surface, like a virtual table top
… there doesn't have to be a actual surface
… it would be if the name implied that "you can place things on top of this"
ada: maybe we can define it as a region
… if you have something that would be floating, you would be placing it there
… and it would still be in arms reach of the user
… would it be weird to define a bouding box?
bajones: it's going to be an axis aligned bounding box
blair: if it can be tilted, we'd need more than x/y/width/height
ada: I have enough to update the PR
… I'll keep the name and add the bounding box
… that should enough to help
… mock it out and prototype it
ada: the next issue
First draft for adding a property to XRInputSource to say it's visible elsewhere (webxr#1352)
<yonet> https://
ada: and this one is a bit less theoretical
… I want to add a property if an input should be rendered
… right now it's hard to determine if an input should be rendered
… session type, input type, ...
… this would make it a lot easier for developers
… should this value allowed to change
… is there a scenario where it would switch mid session
… is it a boolean?
… I came up with some bikeshedded names
… and am open to more names
cabanier: this would be a very useful feature
… for instance with depth sensing, you would never want to render controllers
bajones: I don't think this would change dynamically
… we have a pattern from disconnecting and reconnecting input
… we can use the same here
… I'm partial to a boolean
… we might want to indicate if you want to occlude
… in a lot of simple passthrough system, you render over the hands
… I'm not really sure what I expect developers to change
… if the system doesn't do it, there's some visual disparity
… if the system does the right thing, it's more of a quality of life thing
… does anyone have strong feelings about the naming?
ada: does anyone have strong feelings about the naming?
… it should be that if it's not defined, it means always render the controllers
… so false is the default
… having a negative attribute seems wrong
bajones: I agree but otherwise every step is a two step
… first check for the property and then check for false
… so true is that you can opt out of the drawing
ada: if nobody has objections, maybe my PR can be merged
… this can be useful
… I think this is a cool feature