tags: [vr-ar]
Функціональне тестування контролерів різних моделей шлемів
Touch Pro у Quest Pro, Touch Plus у Quest 3, Touch у Quest 2, Index Knuckles, Valve Index, Reverb G2 — у кожного контролера свій набір кнопок, осей, триггерів та хаптики. Приложення, розроблене під Quest 2, при запуску на Quest Pro несподівано втрачає функціонал захоплення, тому що Touch Pro має іншу раскладку та інший haptic API.
Функціональне тестування контролерів — не «перевірили на одному шлемі, працює». Це матричне покриття всіх підтримуваних пристроїв з документуванням кожного кейсу.
Input mapping: де частіше за все рассипається
OpenXR стандартизував input через XR Input Binding Profiles. У Unity з XR Interaction Toolkit та OpenXR Plugin всі контроллерні дії маппяться через InputActionAsset з кількома binding profiles: Oculus Touch Controller Profile, Valve Index Controller Profile, HTC Vive Controller Profile, Windows Mixed Reality Controller Profile.
Часта проблема: binding настроєний тільки для одного профіля. Розробник додав <XRInputBinding path="/user/hand/right/input/trigger/value"> без вказання конкретного профіля — прив'язка застосовується до «дефолтного» контролера та не спрацьовує на Index Knuckles або WMR контролерах.
Правильна настройка: для кожної дії в InputActionAsset додаємо bindings для всіх підтримуваних профілів. XR Interaction Toolkit надає Default Input Actions ассет з преднастроєними мультипрофільними біндингами — хорошою відправною точкою, але вимагає аудиту під конкретний проект.
Специфіка Meta Quest Pro: контролери Touch Pro мають додаткові сенсори (stylus pointer, face buttons capacitive touch). Якщо приложення використовує OVRInput напрямку замість OpenXR Actions, потрібно явно обробляти OVRInput.Controller.TouchPro як окремий тип — інакше деякі кнопки повертають невірні значення.
Hand Tracking як альтернативний input
Quest 2, 3, Pro підтримують Hand Tracking без контролерів. Якщо приложення заявляє підтримку ручного трекінгу, воно має тестуватися окремо — Hand Tracking має інший input pipeline та інші обмеження.
XR Hands Package (com.unity.xr.hands) надає XRHandSubsystem з даними про 26 суглобів кожної руки. Жести реалізуються через XRHandGesture компоненти або кастомну логіку. Проблема: жест «щипок» (pinch) — основний спосіб взаємодії без контролера — спрацьовує з затримкою та має хибні спрацьовування при швидких рухах пальців.
Тест-кейси для Hand Tracking відрізняються від контроллерних: перевіряємо коректність детектування в умовах поганого освітлення, при перекритті рук, при швидких жестах. Фіксуємо відсоток хибних спрацьовувань pinch при звичайній пальцевій активності (набір тексту, почісування носа — все не мають триггерити ігрові дії).
Матриця тестування контролерів
Функціональне тестування ведеться по матриці: пристрої × тест-кейси. Мінімальна матриця для Quest-first проекту:
| Тест-кейс | Quest 2 | Quest 3 | Quest Pro | Index |
|---|---|---|---|---|
| Trigger — захват об'єкту | ||||
| Grip — утримання | ||||
| A/B/X/Y кнопки | ||||
| Thumbstick locomotion | ||||
| Haptic feedback при взаємодії | ||||
| Hand Tracking — pinch select | ||||
| Граничні випадки (розряджений контролер) |
Кожна комірка: Pass / Fail / Not Applicable + опис при Fail. Живий документ, оновлюваний з кожним білдом.
Хаптика: тестування тактильного відгуку
Touch Pro та Touch Plus мають TruTouch haptic system — більш точна вібрація з підтримкою амплітуди та частоти. Touch у Quest 2 — базова вібрація з одним параметром інтенсивності.
API відрізняються: OVRHaptics для нативного Meta, XRBaseController.SendHapticImpulse(amplitude, duration) для OpenXR. На Touch Pro через Meta XR SDK доступний OVRInput.SetControllerVibration з розширеними параметрами. Якщо використовувати тільки базовий OpenXR haptic API, TruTouch на Pro контролерах буде працювати як звичайна вібрація без використання переваг апаратури.
Тест: порівняння хаптики на Quest 2 та Quest 3/Pro при одинакових ігрових подіях. Удар мечем — різна інтенсивність? Очікувано. Хаптика зовсім відсутня на одному пристрої? Баг, фіксимо.
Строки та формат роботи
Функціональне тестування контролерів вимагає фізичного доступу до пристроїв. Якщо у клієнта немає тестових шлемів — обговорюємо використання пристроїв з нашої сторони або оренду.
| Обсяг тестування | Орієнтовні строки |
|---|---|
| Один шлем, базова матриця | 2–4 дні |
| 2–3 моделі шлемів, повна матриця | 1–2 тижні |
| Повне мультиплатформенне тестування | 2–4 тижні |
Результат роботи — test matrix з документованими Fail-кейсами, пріоритетами та рекомендаціями по фіксу. Вартість розраховується після отримання списку підтримуваних пристроїв та обсягу функціональності.