Anchors keep content in place on re-entry
Aliases: world map · persistent pose · re-entry localization
What it is
Yesterday a note was stuck to the kitchen doorframe. Today, putting the headset back on, the note should still be on that door — not in whichever direction the nose pointed at boot. A spatial anchor binds content to re-identifiable structure in the room, not to this session’s origin. The session origin is allowed to change every launch. The anchor’s job is to make re-entry mean something other than re-placing.
It answers whether, on the same device, walking into the same place next time, the position is still there. It is not the multi-user, multi-device, multi-day operations layer.
Why it happens
A tracking origin is arbitrary: wherever the headset wakes is a temporary zero. If a virtual object only stores coordinates against that zero, the next zero rotates and the object rotates with it. An anchor, at placement, stores a local appearance signature (features, a mesh patch) and a pose relative to that signature. On re-entry the system first finds the signature in the current view, then re-hangs the object at the stored pose. A hit means the note on the doorframe is the same note. A miss leaves the system holding old coordinates that no longer meet the room.
So “keeping place” is not finished when coordinates hit disk. It is a closed loop: store a signature → match again → hang again. Without the rematch, the numbers on disk are last session’s leftover.
Studying it
The standard move is exit and re-enter: place several objects, record distance and heading against real landmarks (a handle, a socket), kill the app or doff the headset, wait, launch again, and measure translation and yaw error of each object against the same landmark, plus how many were found. HoloLens spatial anchors and ARKit World Maps are accepted on this loop.
Independent variables: time away, whether observation at placement was enough, heading at re-entry. Dependent variables: translation error, yaw error, rematch success rate.
Hiding an object behind you and turning back inside one session measures tracking continuity, not re-entry.
Where it stops holding
One-shot experiences that openly do not have to be there next time do not need anchors; forcing persistence only dumps stale objects at the next boot. A fully dark room, or one whose features are covered by a drape, has no signature to match, so re-entry fails — that is a missing structure this time, not a broken concept. A pause inside the same session (a phone call) usually still sits in the current origin and should not be treated as re-entry. A 3DoF device has no position, so an anchor cannot keep the translational sense of “on that door.”
Applying it
- Write as anchors only objects that must still be there next time. Do not persist one-shot demos or body-following tools.
- At placement, force a look-around or a dwell on the target surface so the signature is usable. Do not promise a find after a glance.
- On re-entry, find the anchor before showing the content. If it cannot be found, do not dump the object near the current origin and pretend it is still there.
- How to check: stick it to a doorframe, quit, reopen from the other end of the room. Still on that frame is a pass. Appearing dead ahead of the boot heading means it was bound to the session origin.