Реализация Cloud Anchors для мультипользовательского AR

Реализация Cloud Anchors для мультипользовательского AR

Два iPhone в одной комнате. Пользователь A ставит AR-объект на стол. Пользователь B видит тот же объект на том же столе, в той же позиции — в реальном времени. Без QR-кодов, без маркеров, без предварительной калибровки.

Это Cloud Anchors — технология, где анкор создаётся локально, загружается в облако, а другие устройства загружают его и локализуются относительно него.

Два пути: ARCore и ARKit

Google ARCore Geospatial API и Cloud Anchors — кросс-платформенное решение. Работает на iOS через ARCore SDK для iOS и на Android нативно. Анкоры хранятся на серверах Google, живут от 1 дня до 365 дней в зависимости от настроек.

Создание анкора:

// iOS, ARCore SDK
let anchor = garSession.createAnchor(at: transform)
garSession.hostCloudAnchor(anchor, ttlDays: 30) { cloudAnchorId, error in
    // cloudAnchorId — строка, передаём другим участникам через свой backend
}

Разрешение анкора на другом устройстве:

garSession.resolveCloudAnchor(cloudAnchorId) { anchor, error in
    // anchor.transform — позиция в мировом пространстве этого устройства
}

Apple Shared AR через ARKit + MultipeerConnectivity — работает только между Apple-устройствами, без внешнего сервера. Устройства обмениваются ARWorldMap напрямую через локальную сеть. Ограничение: нужен один «хост», который сохраняет карту и раздаёт участникам.

Для продакшн-приложений с кросс-платформой — ARCore Cloud Anchors. Для Apple-only и офлайн-сценариев — MultipeerConnectivity.

Главные проблемы мультипользовательского AR

Синхронизация состояния сцены. Cloud Anchor даёт общую систему координат. Но данные о том, кто что разместил, куда переместил, что удалил — это ваш слой. Нужен realtime-канал: Firebase Realtime Database, Supabase Realtime, или собственный WebSocket. Типичная схема: событие objectPlaced(anchorId, modelId, transform) → broadcast всем участникам → каждый применяет локально.

Drift между устройствами. Два iPhone локализуются относительно Cloud Anchor независимо. Погрешность позиционирования — 1–5 см при хорошем освещении. При плохом освещении или слабой текстурированности поверхностей — до 10–15 см. Для игровых приложений приемлемо. Для промышленных (разметка оборудования, сборка) — нет.

Время разрешения анкора. resolveCloudAnchor может занимать 2–10 секунд, пока устройство не соберёт достаточно feature points для совпадения с облачным анкором. В это время нужно показывать состояние GARCloudAnchorState.taskInProgress и не позволять пользователю взаимодействовать со сценой.

Лимиты API. Google Cloud Anchors: 1000 бесплатных resolve-операций в день, потом платно. При активной аудитории этот лимит достигается быстро — нужно считать заранее.

Архитектура кросс-платформенного AR-мультиплеера

Устройство A (iOS/Android)
  → создаёт Cloud Anchor → получает cloudAnchorId
  → отправляет cloudAnchorId на backend (REST/WebSocket)

Backend (Firebase / собственный сервер)
  → хранит cloudAnchorId + метаданные сессии
  → рассылает события участникам

Устройство B (iOS/Android)
  → получает cloudAnchorId
  → resolveCloudAnchor → строит общую систему координат
  → получает события → применяет изменения локально

Кейс: AR-квест в торговом центре, 8 одновременных участников. ARCore Cloud Anchors на точках интереса (вход, отдел, касса). Каждый якорь — задание с виртуальным объектом. Синхронизация через Firebase Realtime Database: событие «игрок X нашёл объект Y» → объект исчезает у всех. Задержка между событием и обновлением у всех участников — 150–300 мс через LTE.

Что входит в работу

• Интеграция ARCore SDK для iOS или настройка MultipeerConnectivity для Apple-only
• Создание и разрешение Cloud Anchors с обработкой ошибок и таймаутов
• Реализация realtime-синхронизации состояния сцены
• UI для статусов: ожидание участников, разрешение анкора, десинхронизация
• Тестирование с реальными устройствами в условиях разного освещения

Сроки

Стоимость рассчитывается индивидуально после обсуждения требований к архитектуре и целевой аудитории.