Поддержка кроссплатформенности между различными XR устройствами

id: 228 slug: cross-platform-xr-device-support title_ru: "Поддержка кроссплатформенности между различными XR устройствами" tags: [vr-ar]

Поддержка кроссплатформенности между различными XR устройствами

Написать VR-игру под Quest 3 — это одна задача. Запустить её же на Pico 4, HTC Vive XR Elite и PC через SteamVR без переписывания взаимодействий — совсем другая. Разница в API контроллеров, системах трекинга рук, разрешениях дисплеев и производительности GPU делают кроссплатформенный XR одной из самых трудоёмких задач в мобильном геймдеве.

Где ломается кроссплатформенность на практике

Самая болезненная точка — маппинг инпутов. Meta Quest использует OVRInput с кнопками PrimaryButton, SecondaryButton, PrimaryIndexTrigger. SteamVR (OpenVR) работает через Action System с файлом actions.json. OpenXR унифицирует это через Input System с InputActionAsset, но конкретные пути к кнопкам различаются: /user/hand/left/input/trigger/value для OpenXR — и это ещё относительно стандартно, но grip/pose на разных HMD имеет разный физический смысл и сдвиг позиции.

Второй кейс — hand tracking. На Quest рука трекается через OVR Hand API с суставами OVRSkeleton.BoneId.Hand_Index1. На Pico — через SDK с другим именованием и другим количеством суставов в иерархии. XR Hands (пакет com.unity.xr.hands) решает эту проблему через абстракцию XRHand с XRHandJointID, но поддержка конкретных устройств зависит от версии пакета и нативного провайдера.

Третья — пространственные якоря и Scene Understanding. Meta Spatial Anchors API, ARKit Anchors, OpenXR Spatial Anchors Extension (XR_EXT_spatial_entity) — это три разных API с разной степенью зрелости. Если приложение использует сохранение позиций объектов в реальном пространстве, архитектуру нужно строить с абстракцией над anchor API с самого начала, иначе потом рефакторинг займёт недели.

Архитектурный подход к XR-кроссплатформенности

Основа — OpenXR + Unity XR Plugin Management. OpenXR покрывает Quest (через Meta OpenXR), Pico (PicoXR OpenXR), SteamVR, Windows Mixed Reality. Для каждой платформы подключается соответствующий OpenXR Feature Package, но логика взаимодействий остаётся общей.

Стек:

• XR Interaction Toolkit — высокоуровневые интерактивные компоненты (XRGrabInteractable, XRRayInteractor, XRDirectInteractor)
• Unity Input System с InputActionAsset — единый маппинг инпутов, отдельный binding для каждой платформы
• XR Hands — если нужен hand tracking
• AR Foundation — для AR-функций на мобильных устройствах

Ключевой паттерн — Device Abstraction Layer: все обращения к нативным SDK оборачиваем в интерфейсы (IHandTrackingProvider, IAnchorService, IHapticFeedback). Это позволяет подключать платформенные реализации через DI без изменения игровой логики.

Из конкретного кейса: в проекте с поддержкой Quest 2/3 и Pico 4 проблема возникла с haptic feedback — Meta OVR SDK поддерживает амплитуду и частоту вибрации (OVRInput.SetControllerVibration(frequency, amplitude)), а стандартный OpenXR путь через XRControllerWithRumble не давал нужной точности на Meta. Решили через feature detection: при старте проверяем наличие Meta-специфичного OpenXR Extension XR_FB_haptic_amplitude_envelope, и если он доступен — используем нативный путь, иначе — стандартный OpenXR.

Тестирование на нескольких устройствах

Полноценное тестирование требует физические устройства. Но значительную часть итераций можно закрыть через:

• XR Device Simulator в Unity — для базовой проверки логики без HMD
• Link/Air Link для Quest — запуск в PC режиме для быстрого цикла итераций
• OpenXR Runtime Switcher — переключение между SteamVR и Oculus runtime на PC для сравнения поведения

Матрица тестирования фиксирует: версию ОС HMD, версию рантайма OpenXR, режим трекинга (6DoF/3DoF), работу с/без hand tracking, производительность (FPS, тепло, GPU время).

Этапы работы

Анализ целевых платформ. Определяем список устройств и функций (hand tracking, passthrough, spatial anchors, мультиплеер). От этого зависит выбор SDK и объём работы.

Аудит существующего проекта (если уже есть кодовая база). Выявляем платформозависимые вызовы, оцениваем объём рефакторинга.

Архитектура абстракций. Проектируем Device Abstraction Layer, выбираем конкретные пакеты и версии.

Реализация и настройка Input Actions. Маппинг для каждой платформы, тестирование в XR Device Simulator.

Тестирование на железе. Прогон на каждом из целевых HMD, профилирование GPU/CPU.

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