The coordinate anchor decides whether the volume is device-fixed or relocates with the body

What it is

The geometry of an interaction volume has to live in some coordinate frame. The coordinate anchor decides where the box is nailed: to the screen, the sensor, or the room (device-fixed); or to the user’s head, chest, or waist (body-anchored), so the box travels when the person moves. The same spatial volume, with a different anchor, reverses where input counts after one step. The anchor is a placement policy, not the size of capture range.

Why it happens

A device anchor writes the containment test in world coordinates or at a fixed depth along the screen normal, which fits people working around an immovable object. A body anchor writes it in the torso or head’s local frame, which fits walking, sitting, turning. XR adds a window anchor: the volume is nailed to a virtual panel that itself may be world-locked or head-locked. Choosing the wrong anchor chooses the wrong thing for the user to remember: a device anchor asks them to remember a place in the room; a body anchor asks them to remember a patch of air relative to their chest. If the sensor only reports coordinates relative to itself, a body anchor also needs a stable skeleton root; a jump in the root drifts the whole volume through the room.

Studying it

After one successful action, have participants sidestep, turn, or sit, then repeat the same gesture. Compare device-fixed and body-anchored volumes: record where they put the hand, whether they return to the original stance, success count, and spoken explanation. Independent variables include distance moved, whether the screen stays visible, and whether root-node estimates are deliberately noised. Among dependent measures, isolate “the person went where the anchor defines, but the system’s anchor was no longer there”—that is an anchor error, not a gesture error.

Where it stops holding

When a seat, a queue, or a cockpit already pins the body, the two anchors nearly coincide in behavior and arguing type pays little. Room-scale full-body applications often run both a device anchor (room center) and a body anchor (a near-field menu that travels); which one owns which class of input must be declared. With several people sharing one screen, a body anchor gives each person a private patch and a device anchor gives one public patch; mixing them undeclared puts two spaces in a fight over one hand. On cheap skeletons whose root is unstable, a body anchor amplifies jitter into a shaking volume.

Applying it

• Freeze the anchor in one sentence in the design note: nailed to screen, room, chest, or head. Do not draw a translucent box with no coordinate frame.
• In the debug view, draw both the device box and the body box (even if only one is live) so an installer can see where the box goes when someone walks.
• Acceptance must include “do once, walk two steps, do again.” On failure, ask which anchor was walked, before tuning the recognizer.

Related

• Same group: C4.21.2 A device-fixed anchor requires the user to remember and return to the same physical location · C4.21.3 A body-anchored volume keeps the operating experience consistent after the user moves · C4.21.4 When the anchor is recomputed—at engagement or by continuous following—affects consistency
• Adjacent: C4.20 Interaction volume versus capture range · C4.10 Sensing volume and interaction distance
• Search: coordinate anchor · world-locked · body-locked