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 get XRPose for just created Anchor. #65

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

No way to get XRPose for just created Anchor. #65

Maksims opened this issue Apr 14, 2021 · 1 comment

Comments

@Maksims
Copy link

Maksims commented Apr 14, 2021

The current spec defines createAnchor method on XRFrame, which returns a promise.
When a new anchor has been created, there is no way at that moment (in a callback) to getPose of an Anchor, as XRFrame is outdated.

Taking into account that Spec states that Anchors might persist between sessions, I would assume that trackedAnchors is subject to change during a session. Similar to what plane-detection spec does with detectedPlanes property.

It is useful to know when Anchor is created or failed to create (as well as reasons for a fail). But it might be confusing to a developer, that anchor is not "usable" in a callback, but only after the next XRFrame is available.

@bialpio
Copy link
Contributor

bialpio commented Jun 21, 2021

Correct, this was done by design. The WebXR spec allows querying poses (XRFrame.getPose()) only while a frame is active. TL;DR: for when the frames are active is roughly "during a rAFcb and input source events". In order for us to provide a way for a newly created anchor to be useable right away (which means that XRAnchor.anchorSpace can be queried for a pose) would be to use an event-based approach (something like onAnchorCreated() that would specify that the frame gets activated during the handling of this event), but Promises are the recommended for asynchronous API design.

Taking into account that Spec states that Anchors might persist between sessions, (...)

If this is something that the spec allows, it's a bug in the spec and was definitely not intentional. We explicitly did not want to start considering persisting anchors across sessions at this time. Can you point me to the place in the spec that allows this to happen?

(...) I would assume that trackedAnchors is subject to change during a session. Similar to what plane-detection spec does with detectedPlanes property.

That is right, and if an app does not care to be notified that an anchor got created, it could just ignore the promise returned from createAnchor() call & handle the new anchor when it first shows up in trackedAnchors. Handling the promise offers the application an opportunity to initialize some resources outside of rAFcb (or handle anchor creation errors), but the app does not need to take advantage of that.

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