Initial attempt at a comfortSpace #1349
Conversation
|
/agenda to get feedback |
index.bs
Outdated
| @@ -660,6 +661,8 @@ The <dfn attribute for="XRSession">enabledFeatures</dfn> attribute returns the f | |||
|
|
|||
| The <dfn attribute for="XRSession">isSystemKeyboardSupported</dfn> attribute indicates that the {{XRSystem}} has the ability to display the system keyboard while the {{XRSession}} is active. If {{XRSession/isSystemKeyboardSupported}} is <code>true</code>, Web APIs that would trigger the overlay keyboard (such as [=focus=]) will show the system keyboard. The {{XRSession}} MUST set the [=visibility state=] of the {{XRSession}} to {{XRVisibilityState/"visible-blurred"}} while the keyboard is shown. | |||
|
|
|||
| The <dfn attribute for="XRSession">comfortSpace</dfn> attribute is an {{XRSpace}} which represents a space which will be a sensible place to put content which is designed to be physically interacted with. Most platforms have a limited space in which the user can do interactions, these limits come from the limits of the user's reach and height and also the tracking capabilities of the hardware. Ideally this space can be used by the developer to adjust their experiences to keep the interactive objects in reach. This can be null when hand based interactions don't make sense for the platform e.g. handheld WebXR experiences. This should have some fuzz applied to it each session so that it cannot be used to fingerprint users. | |||
There was a problem hiding this comment.
This should be expressed in terms of native origins, "putting an object in a space" has no meaning, all objects live in all spaces.
We may also wish to discuss if this should be session.comfortSpace or session.getAuxiliarySpace("comfort"), mirroring the XRReferenceSpace APIs.. I'm fine with the former, but I want to flag this.
There was a problem hiding this comment.
Thanks for the feedback, I like getAuxiliarySpace since I don’t want to clutter up session although it would be awkward if we can’t envisage any others.
|
After the meeting today, the result of the discussion is that the space should clarify where the content should be placed in relation to the zero point. The change I will make (when I return from vacation) is to add a 6 item Array for the min-max 3D vectors of an AABB. The min-y value will always be 0 so effectively positive-y will be placed on top of a surface if the comfort space is aligned to a surface. |
|
Does it need to follow the user?? I don't think so |
|
Thinking further I think the min-Y property should only be 0 if the user has the comfort space resting on a desk or similar surface. If it is free floating then it can be negative to let the origin on the space be used for the most comfortable place since for a device where the comfort space is tall developers could place the objects quite low down. Although this would let developers infer that there is a surface they can use which is information which would normally be exposed via the real-world-geometry API. |
|
Another question, if the user is only using a tracked controller in their left hand then swaps hand or activates a second tracked controller, should the bounding box update to reflect this change? |
This PR is an attempt to add a new space to session as discussed in #1339
I was thinking it should probably be null if it's not something that makes sense for the platform. I am not sure if I got the syntax right for that.
What do people think?
Preview | Diff