Open raviramachandra opened 4 years ago
If an underlying system knows that the tracking of an anchor may be regained, it should not communicate that the tracking of an anchor is lost - the anchor can still be considered tracked but not localizable (i.e. the XRFrame.getPose(anchorSpace, refSpace)
will keep returning null for as long as the system does not know where the anchor is). I can add a note for that in the spec draft, since it's more relevant to the implementers that this is the intended behavior.
The cases that I am thinking are, when a person wearing headset moves from one room to another. The anchors set on the original room are lost and a new set of anchors appear in the entered room. The user can move back to original room and regain those anchors.
When the person leaves the room, the user agent will not have to report that the anchors lost tracking. They will still show up in the trackedAnchors
set, but the application will not be able to obtain poses for them. For best experience, the user agent should only report that an anchor is no longer tracked if it is certain that the anchor tracking is lost forever. To me it's similar to input sources - the XRInputSource object will be alive for as long as the controller is connected, but it doesn't mean that we'll always know where it is - XRFrame.getPose()
can always return null.
@bialpio thanks for the clarification. Would you be able to put this in the explainer.md ?
What @bialpio describes matches how spatial anchors work today on HoloLens as users walk between rooms, and so that behavior would be what our developers expect.
When the underlying system looses tracking of an anchor, should the 'App' continue to preserve the XRAnchor object, So it can re-associate with the 'scene node' it was associated with when the system re-gains tracking of the anchor.
Can we add a scenario in the explainer.md to provide guidance in such cases.