-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
detectedPlanes throws exception, detection of feature availability is not graceful #30
Comments
I'm in process of changing it to make the behavior consistent with anchors API (i.e. |
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 21, 2021
OT feedback from plane detection API yielded a good point about inconsistency between trackedAnchors and detectedPlanes behavior on an XRFrame. Changes: - detectedPlanes should now behave the same way as trackedAnchors - they will be empty even if the feature was not enabled on a session, feature detection is not intended via those attributes - clarified that anchorsData can be null coming from mojo & started returning null when the feature is not enabled (same as OpenXR impl) - null data coming from mojo for planes & anchors is treated as if the data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_ basically short-circuits the logic that would've cleared them if received data was empty) - add WPT for anchors API to ensure that the frame's `trackedAnchors` are empty irrespective of the feature status - add internal WPT for anchors API to ensure that frame's `trackedAnchors` are empty even if data coming from the device was null Plane detection spec change still pending. API feedback thread: immersive-web/real-world-geometry#30 Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 22, 2021
OT feedback from plane detection API yielded a good point about inconsistency between trackedAnchors and detectedPlanes behavior on an XRFrame. Changes: - detectedPlanes should now behave the same way as trackedAnchors - they will be empty even if the feature was not enabled on a session, feature detection is not intended via those attributes - clarified that anchorsData can be null coming from mojo & started returning null when the feature is not enabled (same as OpenXR impl) - null data coming from mojo for planes & anchors is treated as if the data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_ basically short-circuits the logic that would've cleared them if received data was empty) - add WPT for anchors API to ensure that the frame's `trackedAnchors` are empty irrespective of the feature status - add internal WPT for anchors API to ensure that frame's `trackedAnchors` are empty even if data coming from the device was null Plane detection spec change still pending. API feedback thread: immersive-web/real-world-geometry#30 Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 22, 2021
OT feedback from plane detection API yielded a good point about inconsistency between trackedAnchors and detectedPlanes behavior on an XRFrame. Changes: - detectedPlanes should now behave the same way as trackedAnchors - they will be empty even if the feature was not enabled on a session, feature detection is not intended via those attributes - clarified that anchorsData can be null coming from mojo & started returning null when the feature is not enabled (same as OpenXR impl) - null data coming from mojo for planes & anchors is treated as if the data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_ basically short-circuits the logic that would've cleared them if received data was empty) - add WPT for anchors API to ensure that the frame's `trackedAnchors` are empty irrespective of the feature status - add internal WPT for anchors API to ensure that frame's `trackedAnchors` are empty even if data coming from the device was null Plane detection spec change still pending. API feedback thread: immersive-web/real-world-geometry#30 Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587 Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Alexander Cooper <[email protected]> Commit-Queue: Piotr Bialecki <[email protected]> Cr-Commit-Position: refs/heads/master@{#894892}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 22, 2021
OT feedback from plane detection API yielded a good point about inconsistency between trackedAnchors and detectedPlanes behavior on an XRFrame. Changes: - detectedPlanes should now behave the same way as trackedAnchors - they will be empty even if the feature was not enabled on a session, feature detection is not intended via those attributes - clarified that anchorsData can be null coming from mojo & started returning null when the feature is not enabled (same as OpenXR impl) - null data coming from mojo for planes & anchors is treated as if the data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_ basically short-circuits the logic that would've cleared them if received data was empty) - add WPT for anchors API to ensure that the frame's `trackedAnchors` are empty irrespective of the feature status - add internal WPT for anchors API to ensure that frame's `trackedAnchors` are empty even if data coming from the device was null Plane detection spec change still pending. API feedback thread: immersive-web/real-world-geometry#30 Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587 Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Alexander Cooper <[email protected]> Commit-Queue: Piotr Bialecki <[email protected]> Cr-Commit-Position: refs/heads/master@{#894892}
blueboxd
pushed a commit
to blueboxd/chromium-legacy
that referenced
this issue
Jun 23, 2021
OT feedback from plane detection API yielded a good point about inconsistency between trackedAnchors and detectedPlanes behavior on an XRFrame. Changes: - detectedPlanes should now behave the same way as trackedAnchors - they will be empty even if the feature was not enabled on a session, feature detection is not intended via those attributes - clarified that anchorsData can be null coming from mojo & started returning null when the feature is not enabled (same as OpenXR impl) - null data coming from mojo for planes & anchors is treated as if the data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_ basically short-circuits the logic that would've cleared them if received data was empty) - add WPT for anchors API to ensure that the frame's `trackedAnchors` are empty irrespective of the feature status - add internal WPT for anchors API to ensure that frame's `trackedAnchors` are empty even if data coming from the device was null Plane detection spec change still pending. API feedback thread: immersive-web/real-world-geometry#30 Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587 Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Alexander Cooper <[email protected]> Commit-Queue: Piotr Bialecki <[email protected]> Cr-Commit-Position: refs/heads/master@{#894892}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Jun 27, 2021
…ors & detectedPlanes, a=testonly Automatic update from web-platform-tests WebXR: align the behavior of trackedAnchors & detectedPlanes OT feedback from plane detection API yielded a good point about inconsistency between trackedAnchors and detectedPlanes behavior on an XRFrame. Changes: - detectedPlanes should now behave the same way as trackedAnchors - they will be empty even if the feature was not enabled on a session, feature detection is not intended via those attributes - clarified that anchorsData can be null coming from mojo & started returning null when the feature is not enabled (same as OpenXR impl) - null data coming from mojo for planes & anchors is treated as if the data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_ basically short-circuits the logic that would've cleared them if received data was empty) - add WPT for anchors API to ensure that the frame's `trackedAnchors` are empty irrespective of the feature status - add internal WPT for anchors API to ensure that frame's `trackedAnchors` are empty even if data coming from the device was null Plane detection spec change still pending. API feedback thread: immersive-web/real-world-geometry#30 Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587 Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Alexander Cooper <[email protected]> Commit-Queue: Piotr Bialecki <[email protected]> Cr-Commit-Position: refs/heads/master@{#894892} -- wpt-commits: e6036168a8a3142188cdbe31aa4ca3a9da09ffb0 wpt-pr: 29445
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this issue
Jul 16, 2021
…ors & detectedPlanes, a=testonly Automatic update from web-platform-tests WebXR: align the behavior of trackedAnchors & detectedPlanes OT feedback from plane detection API yielded a good point about inconsistency between trackedAnchors and detectedPlanes behavior on an XRFrame. Changes: - detectedPlanes should now behave the same way as trackedAnchors - they will be empty even if the feature was not enabled on a session, feature detection is not intended via those attributes - clarified that anchorsData can be null coming from mojo & started returning null when the feature is not enabled (same as OpenXR impl) - null data coming from mojo for planes & anchors is treated as if the data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_ basically short-circuits the logic that would've cleared them if received data was empty) - add WPT for anchors API to ensure that the frame's `trackedAnchors` are empty irrespective of the feature status - add internal WPT for anchors API to ensure that frame's `trackedAnchors` are empty even if data coming from the device was null Plane detection spec change still pending. API feedback thread: immersive-web/real-world-geometry#30 Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587 Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Alexander Cooper <[email protected]> Commit-Queue: Piotr Bialecki <[email protected]> Cr-Commit-Position: refs/heads/master@{#894892} -- wpt-commits: e6036168a8a3142188cdbe31aa4ca3a9da09ffb0 wpt-pr: 29445
mjfroman
pushed a commit
to mjfroman/moz-libwebrtc-third-party
that referenced
this issue
Oct 14, 2022
OT feedback from plane detection API yielded a good point about inconsistency between trackedAnchors and detectedPlanes behavior on an XRFrame. Changes: - detectedPlanes should now behave the same way as trackedAnchors - they will be empty even if the feature was not enabled on a session, feature detection is not intended via those attributes - clarified that anchorsData can be null coming from mojo & started returning null when the feature is not enabled (same as OpenXR impl) - null data coming from mojo for planes & anchors is treated as if the data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_ basically short-circuits the logic that would've cleared them if received data was empty) - add WPT for anchors API to ensure that the frame's `trackedAnchors` are empty irrespective of the feature status - add internal WPT for anchors API to ensure that frame's `trackedAnchors` are empty even if data coming from the device was null Plane detection spec change still pending. API feedback thread: immersive-web/real-world-geometry#30 Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587 Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Alexander Cooper <[email protected]> Commit-Queue: Piotr Bialecki <[email protected]> Cr-Commit-Position: refs/heads/master@{#894892} NOKEYCHECK=True GitOrigin-RevId: a91618bd1ef01173aac3e018f8c5f3429fd031e5
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, it is possible to detect if the platform supports Plane Detection by checking the availability of
XRPlane
inwindow
.Once the session has started, and the first
XRFrame
is provided byXRSession
, the only way to check ifplane-detection
feature is available, is to attempt to getdetectedPlanes
fromXRFrame
, and try/catch to identify if it is available.Most other APIs have a better way to detect availability and do not follow try/catch pattern.
It would be more graceful if
detectedPlanes
would equalnull
if the feature is not available, instead of throwing an exception when checking the value of it. Especially while it is not a function, but a property.Current approach (by the spec):
Proposed approach:
The text was updated successfully, but these errors were encountered: