Пространственные якоря в VR: как объект сохраняет место

Пространственные якоря — сохранённые позы в системе координат реального пространства, к которым приложение привязывает виртуальный контент. Благодаря anchor панель может оставаться над столом, а цифровая метка — возле оборудования даже после того, как пользователь отвернулся, отошёл или перезапустил приложение.

Зачем недостаточно обычных координат

В 3D-сцене объект уже имеет позицию, однако origin XR-сессии способен измениться. Гарнитура восстанавливает своё положение по камерам и карте помещения, а после потери трекинга или нового запуска оценка может немного отличаться. Координата (1, 0, 2) сама по себе не гарантирует прежнее физическое место.

Якорь поручает runtime поддерживать связь между выбранной позой и наблюдаемым пространством. Приложение хранит идентификатор и каждый кадр получает актуальную позу относительно текущей системы координат.

Как создаётся anchor

Типичная последовательность выглядит так:

1. Пользователь выбирает точку на стене, столе или в свободном пространстве.
2. Приложение создаёт pose в координатах текущей сессии.
3. XR-платформа регистрирует пространственный якорь.
4. Виртуальный объект становится дочерним по отношению к anchor либо получает его позу.
5. При необходимости идентификатор сохраняется для следующего запуска.

Anchor не приклеивается к поверхности физически. Его устойчивость зависит от карты, качества повторной локализации и видимых признаков вокруг выбранного места.

Локальные и сохраняемые якоря

Локальный anchor существует в текущей сессии и помогает стабилизировать объект рядом с пользователем. Persisted anchor сохраняется средствами платформы и может быть найден после перезапуска. Поддержка, лимиты и разрешения различаются у Meta, Microsoft, XREAL и других систем.

Если приложение хранит только собственные координаты, это ещё не persistence. Нужна поддержка runtime: сохранить anchor, получить его идентификатор, загрузить и дождаться успешной локализации.

Общие якоря для нескольких устройств

Shared или cloud anchor нужен, когда два пользователя должны видеть объект в одном физическом месте. Одной отправки числовых координат по сети недостаточно: у устройств разные локальные карты и origin.

Система общего якоря связывает наблюдения с общей записью. Устройства локализуют её независимо, после чего приложение синхронизирует состояние объекта. Возможны три разных ошибки: неточная локализация каждого устройства, сетевое рассогласование данных и различие карт окружения.

Общий anchor не заменяет сетевую архитектуру. Он отвечает за пространственное совпадение, а сервер или peer-to-peer протокол — за владение, события и версии состояния.

Откуда берётся дрейф

Виртуальный объект может постепенно смещаться, дрожать или скачком менять положение после восстановления трекинга. Причины находятся во всей измерительной цепочке:

• мало устойчивых визуальных ориентиров;
• темнота или резкая смена освещения;
• зеркала и движущиеся поверхности;
• выбранная область слишком далеко от пользователя;
• гарнитура ещё не восстановила карту;
• anchor расположен на физически подвижном предмете;
• приложение смешивает локальные и мировые координаты.

Подробнее построение карты разобрано в статье о SLAM в VR. Якорь использует пространственную модель, но не делает плохой трекинг точным.

Якорь, плоскость и mesh — разные сущности

Плоскость описывает найденную поверхность, например стену или стол. Scene mesh приближённо воспроизводит геометрию помещения. Семантическая метка сообщает, что объект похож на окно или диван. Anchor хранит устойчивую позу.

Обычно они работают вместе: raycast находит стол, приложение создаёт anchor в точке попадания, затем располагает интерфейс относительно него. Если mesh обновится, разработчик решает, должен ли объект следовать новой геометрии или сохранять исходное место.

Что важно в интерфейсе

Пользователь должен понимать, когда размещение подтверждено, якорь ещё загружается или место потеряно. Нельзя молча показывать объект в origin, если локализация не удалась: это выглядит как реальное перемещение и может быть опасно в рабочем сценарии.

Полезны состояния:

• «сканируем пространство»;
• «место найдено»;
• «якорь недоступен»;
• предложение посмотреть на знакомую область;
• ручное повторное размещение.

Для точной работы у оборудования добавляют визуальную проверку совмещения и не используют виртуальную метку как единственный источник допуска или безопасности.

Практика разработки

Не создавайте отдельный anchor для каждого мелкого элемента. Платформы ограничивают число активных привязок, а близкие объекты проще разместить относительно одного устойчивого родителя. Освобождайте неиспользуемые anchors и храните версию данных рядом с идентификатором.

Обработайте жизненный цикл:

1. проверка поддержки API;
2. запрос разрешений;
3. создание и сохранение;
4. асинхронная загрузка;
5. валидность текущей позы;
6. потеря локализации;
7. удаление устаревшей записи.

Проверяйте проект в нескольких помещениях, после изменения мебели и при повторном надевании гарнитуры. Демо в одной хорошо освещённой комнате не показывает устойчивость решения.

OpenXR и vendor API

Базовый OpenXR унифицирует сессию, пространства и позы, но конкретные функции persistence, scene understanding и sharing могут приходить через расширения производителя. Нельзя считать, что реализация для одной гарнитуры автоматически работает на другой.

Архитектуру лучше разделить: прикладная логика работает с абстракцией якоря, а платформенный слой создаёт, сохраняет и восстанавливает его доступным API. При отсутствии функции должен существовать понятный fallback — размещение только на время сессии или повторная установка пользователем.

Храните платформу и версию формата рядом с идентификатором. Идентификатор одной XR-системы нельзя считать переносимым в другую.

Итог

Пространственные якоря поддерживают связь виртуального объекта с реальным местом, пока система координат XR уточняется и восстанавливается. Локальный, сохраняемый и общий anchor решают разные задачи. Надёжность зависит от трекинга, карты помещения, жизненного цикла и обработки ошибок, поэтому привязку нужно проектировать как измерительную функцию, а не как неизменную координату.