search

immersive-web / anchors

https://immersive-web.github.io/anchors/
Other
50 stars 20 forks source link

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

Open Maksims opened 3 years ago

Maksims commented 3 years ago

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 commented 3 years ago

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.