Практична розробка AR-механік взаємодії на AR Foundation

Уявіть: користувач наводить камеру на стіл, об'єкт розміщується, але через секунду його зносить на 3 см убік. Або об'єкт промальовується крізь руку — occlusion не працює. Згідно з нашими вимірами, 70% користувачів закривають застосунок, якщо віртуальний об'єкт смикається або «пливе». Це наслідки неграмотної роботи з AR Foundation — абстракцією над ARKit (iOS) та ARCore (Android). За 5 років на ринку AR ми реалізували понад 50 комерційних проєктів: від каталогів меблів до промислових інструкцій. Наш досвід показує, що без ретельного налаштування raycast, якорів та occlusion навіть простий placement розчаровує користувача.

Які механіки ми реалізуємо?

ARRaycastManager.Raycast() — основа розміщення. Стандартна помилка: викликати Raycast кожен кадр в Update без debounce. На складних сценах ARCore витрачає 2–4 мс на raycast — це з'їдає бюджет FPS. Правильно: raycast тільки при зміні позиції пальця з threshold 5–10 пікселів. Якщо площина ще не виявлена (ARCore та ARKit детектують горизонтальні площини за 2–5 секунд на хорошій текстурі, а на однотонному білому столі — ніколи), потрібен feedback UI: індикатор пошуку та інструкція «посуньте камерою над поверхнею».

ARAnchor — це точка, яку AR-система зобов'язується відстежувати та коригувати автоматично. В AR Foundation: ARAnchorManager.TryAddAnchorAsync(pose) повертає ARAnchor, до якого кріпиться контент. Для збереження між сесіями використовуємо ARCore Cloud Anchors (Android) або ARKit WorldMap (iOS).

AROcclusionManager надає depth-текстуру від сенсора. Налаштування: environmentDepthMode = EnvironmentDepthMode.Best, occlusionPreferenceMode = OcclusionPreferenceMode.PreferEnvironmentOcclusion. На Android без LiDAR глибина оціночна — occlusion працює грубо, з артефактами. На iPhone Pro з LiDAR — точно. Без кастомного шейдера стандартний URP Lit не використовує depth-текстуру AR. Потрібен ShaderGraph з нодою AROcclusion з AR Foundation Shader Framework або кастомний HLSL з ручним depth comparison.

Взаємодія через тачскрін — стандартний набір: tap (вибір через ARRaycastManager + Physics.Raycast), drag (переміщення з Lerp-інтерполяцією до нової позиції площини, швидкість 15f в MoveTowards), pinch-to-scale (два пальці, transform.localScale *= scaleDelta з обмеженнями) та rotation (один палець по горизонталі — навколо Y-axis, twist двома пальцями). Для AR rotation краще обмежувати лише віссю Y — обертання по X або Z ламає відчуття «об'єкт стоїть на поверхні».

Чому ARAnchor важливий для стабільності?

Без якоря при покращенні трекінгу об'єкт зсувається на кілька сантиметрів — це руйнує ілюзію. ARAnchor гарантує, що позиція коригується системою. На практиці: при перевідкритті сцени (наприклад, користувач виходив із застосунку) якорі можна відновити через Cloud Anchors або WorldMap. Без якорів користувачі скаржаться на «тремтіння» об'єктів вже на другій хвилині використання. Впровадження Cloud Anchors знижує кількість скарг на нестабільність у 3 рази за нашими даними.

Як досягти стабільного розміщення?

Використовуйте алгоритм з debounce та кешуванням останнього хіта Raycast. Приклад оптимізованого коду:

private Vector2 lastTouchPos; private float lastRaycastTime; private ARRaycastHit lastHit; void Update() { if (Input.touchCount == 1) { Touch touch = Input.GetTouch(0); if (touch.phase == TouchPhase.Moved) { float dist = Vector2.Distance(touch.position, lastTouchPos); if (dist > 5f && Time.time - lastRaycastTime > 0.01f) { PerformRaycast(touch.position); lastTouchPos = touch.position; lastRaycastTime = Time.time; } } } } void PerformRaycast(Vector2 screenPos) { List<ARRaycastHit> hits = new List<ARRaycastHit>(); arRaycastManager.Raycast(screenPos, hits, TrackableType.Planes); if (hits.Count > 0) { lastHit = hits[0]; targetPosition = lastHit.pose.position; } }