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
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.
The text was updated successfully, but these errors were encountered:
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.
The current spec defines
createAnchor
method onXRFrame
, 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, asXRFrame
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 whatplane-detection
spec does withdetectedPlanes
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.
The text was updated successfully, but these errors were encountered: