You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Access to real-world-geometry brings up the questions of permissions and levels of permissions and how they might work in practice.
The implementation I am working toward has 3 levels of permissions, with the UA also supporting a "reduced information" (lite) mode.
An app can request one of these progressive levels (each includes the previous):
minimal, basic WebXR: spatial tracking, hitTesting, creating anchors from absolute matrices or hitTest results
world sensing: real-world-geometry, illumination, detection and tracking of well-defined things the platform supports (images, objects, QRCodes, etc), world relocalization maps, etc
camera / sensor data: originally this was "camera" access, but it includes, I think, access to any of the low level sensors a device might have.
There are questions, obviously. How can we standardize on some of the sensing bits. Where do things like eye trackers and other invasive sensors (like "affect" sensors, or facial tracking of the user in an HMD for creating their avatar elsewhere) fit?
For both the "minimal" and "world sensing" levels, there is a "limited" option, which (for our iOS app) has the user select a plane; that is the only world structure that gets exposed, or hit test against.
Finally, we are displaying the current state in the URL bar (when it's exposed), akin to the HTTPS icon or camera or microphone icon on a browser. Clicking on it brings up a detailed permissions sheet, where specific information can be turned on/off, including the most basic access. The web page is NOT notified of these changes; the data just stops flowing. The user can change this at any time.
This relates to the real-world-geometry in two ways:
I am adding an option to request session, called "worldSensing". If true, when the user is asked for permission to use XR, it also includes permission to use "worldSensing". The advantage of doing this is that the user only gets one permission request, instead of getting a WebXR permission and then a worldSensing permission. We have not decided yet what to do about failure: does the user have the option to say "yes" to "webxr" but "no" to world sensing? Or does the webpage need to deal with requestSession failing, and then request a session with less access (or display and error?)
if the app requests anything requiring worldSensing later, and didn't put worldSensing in the original request, we could trigger a new permission. Apps might do this if they want to wait until the user does something that requires world sensing, if they don't require it all the time. It would be nice if there was a way for the app to provide a string or description of why they want this. if not, pages can display info before they request (since they know it's going to trigger one).
Thoughts?
The text was updated successfully, but these errors were encountered:
Over in https://github.com/immersive-web/real-world-geometry I posted an issue discussing when and how to ask for permissions for access to real-world-geometry (immersive-web/real-world-geometry#7). Posting this here to track it on this site too.
Issue contained this text
Access to real-world-geometry brings up the questions of permissions and levels of permissions and how they might work in practice.
The implementation I am working toward has 3 levels of permissions, with the UA also supporting a "reduced information" (lite) mode.
An app can request one of these progressive levels (each includes the previous):
There are questions, obviously. How can we standardize on some of the sensing bits. Where do things like eye trackers and other invasive sensors (like "affect" sensors, or facial tracking of the user in an HMD for creating their avatar elsewhere) fit?
For both the "minimal" and "world sensing" levels, there is a "limited" option, which (for our iOS app) has the user select a plane; that is the only world structure that gets exposed, or hit test against.
Finally, we are displaying the current state in the URL bar (when it's exposed), akin to the HTTPS icon or camera or microphone icon on a browser. Clicking on it brings up a detailed permissions sheet, where specific information can be turned on/off, including the most basic access. The web page is NOT notified of these changes; the data just stops flowing. The user can change this at any time.
This relates to the real-world-geometry in two ways:
Thoughts?
The text was updated successfully, but these errors were encountered: