Given this approach of XRAnchor
only representing explicit app-created freespace anchors, having a list of tracked anchors seems harmless to me.
XRFrame.trackedAnchors
does feel lower value than is implied by the code in the anchors explainer, as there is no per-anchor ID or other data beyond the anchorSpace
to tie a given XRAnchor
back to any set of app content. The app itself will need to remember for each anchored scene object it creates which anchor that object is attached to... at which point the app could just loop over its own list of those anchors and poll for isLost
or such.
Note that the for
loop over trackedAnchors
at the bottom stops after getting each XRAnchor
's pose
- it's not clear what the next line of code would be for the app to make productive use of that pose
, unless it was already maintaining an equivalent trackedAnchors
map from scene node to anchor itself:
let previousFrameAnchors = Set();
function onXRFrame(timestamp, frame) {
frame.session.requestAnimationFrame(onXRFrame);
const trackedAnchors = frame.trackedAnchors;
for(const anchor of previousFrameAnchors) {
if(!trackedAnchors.has(anchor)) {
// Handle anchor tracking loss - `anchor` was present
// in the present frame but is no longer tracked.
}
}
for(const anchor of trackedAnchors) {
// Query most recent pose of the anchor relative to some reference space:
const pose = xrFrame.getPose(anchor.anchorSpace, referenceSpace);
}
previousFrameAnchors = trackedAnchors;
}
The primary way I could see an app productively using trackedAnchors
is if it set its own additional attribute on each XRAnchor
to store the list of its root scene objects whose poses need to be updated each frame:
for(const anchor of trackedAnchors) {
// Query most recent pose of the anchor relative to some reference space:
const pose = xrFrame.getPose(anchor.anchorSpace, referenceSpace);
for(const sceneNode of anchor.attachedSceneNodes) {
// Adjust the pose of each scene node attached to this anchor.
sceneNode.setTransform(pose.transform);
}
This seems like a reasonable pattern, although it would rely on a promise that the UA will return the same XRAnchor
instance on subsequent frames when XRFrame.trackedAnchors
is enumerated, rather than returning a new equivalent XRAnchor
instance that lost that extra data.
I'll file a new issue around specifying that the UA must retain any extra data on an XRAnchor
when it's enumerated moving forward.
Originally posted by @thetuvix in #11 (comment)