Skip to content
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

No way to detect if a feature is enabled for a session. #64

Open
Maksims opened this issue Apr 14, 2021 · 1 comment
Open

No way to detect if a feature is enabled for a session. #64

Maksims opened this issue Apr 14, 2021 · 1 comment

Comments

@Maksims
Copy link

Maksims commented Apr 14, 2021

Currently, there is no way to detect if anchors feature has been enabled for the session.

Some other APIs provide some way to detect a feature, e.g. plane-detection throws an exception when trying to access detectedPlanes property, which I've argued is not a good API design here: immersive-web/real-world-geometry#30

Regardless of anchors feature been enabled or not on the session, XRFrame has a property trackedAnchors that always returns a Set-like object.

For consistency across APIs, it would be best to not return Set, but either throw an exception as in plane-detection, or better to be null if the feature is not available on the session.

That way, the developer has a graceful way to detect if anchors feature is enabled or not.

@bialpio
Copy link
Contributor

bialpio commented Jun 10, 2021

Currently, there is no way to detect if anchors feature has been enabled for the session.

This was discussed in immersive-web/webxr#952 - the spec describes a way to query the features that have been enabled on a session through Permissions API. Unfortunately, I don't think this is currently implemented in Chrome. ☹️ With that said, I wouldn't mind adding additional XRSession property that would contain features enabled for a session, but that would mean we have 2 ways of achieving the same thing, so I doubt it will end up happening.

At this point, changing how trackedAnchors behave would be a breaking change so I'd be very hesitant to adjust this, but I agree that detectedPlanes should behave consistently with them, thanks for catching this mismatch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants