Анализ технических ограничений целевых AR устройств для игр

Анализ технических ограничений целевых AR устройств для игр

Разрабатывать AR-игру без анализа целевых устройств — значит проектировать в вакууме. То, что отлично работает на HoloLens 2 с x86 процессором и 4 GB RAM, окажется нереализуемым на Meta Quest 3 в passthrough-режиме, а то, что работает на Quest 3, может не запуститься на бюджетном Android-смартфоне с ARCore. Анализ технических ограничений — это первый технический документ, который должен появиться в AR-проекте, до любого проектирования архитектуры.

Почему AR-устройства отличаются сильнее, чем кажется

На первый взгляд: все AR-устройства показывают виртуальный контент поверх реального мира. На практике: они делают это принципиально разными способами, и эти различия диктуют возможности и ограничения на уровне физики устройства.

Optical see-through (OST) — HoloLens 2, Magic Leap 2. Стёкла буквально прозрачные, дополненная реальность накладывается оптически. Следствие: невозможно отобразить непрозрачный контент (нельзя «закрыть» реальный объект виртуальным), цвета воспринимаются иначе (тёмные оттенки практически невидимы на фоне реального мира), field of view ограничено (HoloLens 2 — около 52°). Для игр это означает: весь контент должен быть достаточно ярким и контрастным, механики не могут основываться на окклюзии реальных объектов виртуальными.

Video see-through (VST) — Meta Quest 3, PICO 4 в AR/passthrough режиме, мобильные AR. Камера снимает реальный мир и рендерит его вместе с виртуальным контентом. Преимущество: полный контроль над compositing, можно делать окклюзию. Ограничение: latency между реальным миром и его видеоизображением (на Quest 3 — около 12–15 мс), цветовые артефакты на краях объектов, качество пассрута зависит от камеры устройства.

Мобильный AR (iOS ARKit, Android ARCore) — VST через основную камеру смартфона. Ограничения: отсутствие глубины (нет стереозрения), трекинг только через SLAM на одной камере, точность размещения объектов ~1–2 см, нет haptic feedback уровня контроллеров.

Ключевые технические параметры для анализа

Трекинг возможности. Что умеет устройство из коробки: plane detection, image tracking, object tracking, face tracking, hand tracking, spatial anchors, scene understanding (mesh reconstruction)?

ARKit на iPhone 12+ поддерживает LiDAR-сканирование, что даёт mesh реального мира и позволяет виртуальным объектам «прятаться» за реальными поверхностями через occlusion. ARCore не имеет depth sensor на большинстве Android-устройств и использует моnocular depth estimation — значительно менее точный.

Compute budget. AR требует параллельной работы: камера + SLAM + рендер + игровая логика. На Snapdragon 888 это вполне работает при правильной оптимизации. На Snapdragon 680 (бюджетный сегмент) SLAM-алгоритм ARCore уже занимает 20–30% CPU, и для игровой логики остаётся значительно меньше. Анализ должен включать конкретные CPU/GPU бюджеты для каждой целевой платформы.

Memory constraints. Текстуры для AR-игр часто не компрессируются так агрессивно, как в обычных играх, потому что они накладываются на реальный мир и артефакты компрессии заметнее. На устройствах с 2–3 GB RAM это создаёт давление.

Display характеристики. FOV, refresh rate, pixel density — для OST устройств критично. HoloLens 2 имеет ~60 Гц refresh rate и ограниченный FOV, что влияет на то, какие эффекты и анимации будут выглядеть приемлемо.

Формат анализа

Результат работы — технический документ с матрицей возможностей по устройствам и список constraint'ов, которые должны быть учтены в архитектуре.

Типичная структура матрицы: устройство × возможность (hand tracking, plane detection, occlusion, spatial anchors) × статус (supported / not supported / limited) × ограничения и SDK-зависимости.

На основе этой матрицы определяется minimum viable platform — устройство, ограничения которого задают нижнюю планку для проекта, и premium experience — что доступно на более мощных платформах.

На практике при анализе для мобильной AR-игры с мультиплеером выяснилось, что ARWorldMap (iOS-only API для sharing spatial anchors) позволяет двум iPhone в одном пространстве видеть одинаково расположенные объекты. Android-аналог через ARCore Cloud Anchors требует подключения к серверу Google и добавляет latency 500–2000 мс на синхронизацию. Это фундаментально меняет дизайн мультиплеерной механики: on-device sync для iOS работает почти мгновенно, cloud-based sync для Android требует совершенно другого UX-подхода.

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