Підтримка кросплатформеності між різними XR пристроями

Підтримка кроссплатформенності між різними 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, але підтримка конкретних пристроїв залежить від версії пакету та native провайдера.

Третя—просторові якорі та 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: всі обращення до native 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, та якщо він доступний—використовуємо native шлях, інакше—стандартний OpenXR.

Тестування на кількох пристроях

Повноцінне тестування потребує фізичних пристроїв. Але значну частину ітерацій можна закрити через:

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

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

Етапи роботи

Аналіз цільових платформ. Визначаємо список пристроїв та функцій (hand tracking, passthrough, spatial anchors, мультиплеєр). Від цього залежить вибір SDK та обсяг роботи.

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

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

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

Тестування на залізі. Прогон на кожному з цільових HMD, профілювання GPU/CPU.

Вартість розраховується індивідуально після аудиту проекту та списку цільових пристроїв.