Розроблення системи взаємодії з фізичними кнопками в іграх
Натиснути кнопку в VR пальцем – це не те саме, що кліки мишею або натиснути X на геймпаді. Фізична кнопка повинна уходити під натиском, чинити опір, повертатися назад. Палець не повинен проваливатися крізь поверхню. І спрацьовувати кнопка має саме у той момент, коли користувач очікує – не раніше, не пізніше.
Це три окремі технічні завдання, та кожна має свої грабли.
Фізика натиску: чому коллайдери не вирішують завдання самі
Перший інстинкт – поставити на кнопку Collider, поймати OnTriggerEnter та активувати кнопку. Проблема: триггер спрацьовує при будь-якому проходженні через зону, не при натиску. Якщо палець входить у коллайдер збоку – кнопка натиснута. Якщо рука проходить поряд з дотиком краю – теж натиснута.
Фізична кнопка потребує спрямованого натиску. Логіка: кнопка активується тільки при русі в напрямку осі натиску (зазвичай локальний -Y). Це означає перевірку не OnTriggerEnter, а позиції "пальця" вздовж осі кнопки у кожному Update.
В XR Interaction Toolkit підхід: кнопка – це XRBaseInteractable з кастомним компонентом PhysicalButton. Відслідковується float pressDepth = Vector3.Dot(fingerPosition - buttonSurface, buttonAxis). Поки pressDepth < threshold – pressed state. При pressDepth > releaseThreshold – released. Гістерезис між двома порогами запобігає bouncing.
Візуальна та тактильна зворотний зв'язок
Кнопка має рухатися. Простий спосіб – Lerp позиції кнопки між restPosition та pressedPosition на основі pressDepth. Але простий Lerp не дає ощущення фізичного опору – кнопка рухається лінійно незалежно від зусилля.
Більш правильний підхід: spring-damper симуляція. Кнопка – Rigidbody з isKinematic = false, на неї діє spring force від ConfigurableJoint з лінійним рухом по одній осі. JointDrive.positionSpring та JointDrive.positionDamper визначають характер відклику. Це дозволяє пальцю буквально "штовхати" кнопку з фізичним опором – кнопка не уходит миттєво на максимум, а вимагає зусилля.
При активації – XRBaseController.SendHapticImpulse(0.8f, 0.03f) для короткого "щелічка" в контролері. Без haptics фізичні кнопки ощущаються німими.
Проблема "привида пальця"
В Meta Quest без Hand Tracking (з контролерами) "палець" – це віртуальний промінь або невелика sphere прив'язана до позиції контролера. Реального пальця нема. Кнопку натискають кінчиком контролера або указівним пальцем у hand-model.
З Hand Tracking (Meta Hand Tracking SDK / OpenXR Hand Interaction Extension) пальці є – та це краще, але й складніше. Кожний палець – joint position, без фізичного коллайдера. Потрібно додавати маленькі sphere коллайдери на fingertip joints (ThumbTip, IndexTip) та правильно налаштовувати їх physics layer – щоб вони взаємодіяли з кнопками, але не конфліктували між собою й не з тілом аватара.
Layer матриця – обов'язкова: HandColliders vs. PhysicalButtons = Detect, HandColliders vs. HandColliders = Ignore, HandColliders vs. Environment = Ignore (інакше пальці застревають у стінах).
Масштабування системи
Коли кнопок у сцені багато (панель керування, клавіатура), оптимізація важлива. Не утримувати Update() на кожній кнопці – використовувати Physics.OverlapSphere у менеджері, що раз на кадр перевіряє найближчі кнопки до позицій рук та активує перевірку тільки на них.
Для клавіатур – окремий підхід: PhysicalKeyboard менеджер з grid-based detection, без індивідуальних коллайдерів на кожній клавіші.
Терміни: одна фізична кнопка з full feedback – 1–2 дні; система з 10–20 кнопок з Hand Tracking інтеграцією – 1–2 тижні. Вартість розраховується індивідуально.