tags: [vr-ar]
Тестування стабільності трекінгу у різних умовах освітлення AR
AR-трекінг ламається не від поганого коду — він ламається від поганого світла. Це одна з тих проблем, яку неможливо відтворити на столі розробника в комфортному офісі. Сонячне світло, що б'є в вікно під кутом 15 градусів, флуоресцентні лампи з мерциканням на частоті 100 Гц, темна кімната з одним точковим джерелом — кожний з цих сценаріїв ведеться по-різному, та ARCore з ARKit реагують на них зовсім по-різному.
Чому трекінг втрачає якорі саме там, де ви не очікуєте
Алгоритми visual inertial odometry, на яких побудовані ARCore та ARKit, використовують feature points — характерні точки в кадрі — для обчислення положення камери у просторі. При освітленості нижче ~50 лк кількість надійних feature points різко падає, та система починає компенсувати втрату даних за рахунок IMU. Це нормально, поки IMU не накопичує дрейф. На практиці — 3–4 секунди у погано освітленій зоні, і віртуальний об'єкт «уплив» на 5–8 сантиметрів. У ігровому контексті це катастрофа: гравець дивиться на стіл, очікує бачити фігурку там, куди поставив, а вона висить у повітрі.
Окрема історія — пересвет. Прямий сонячний світ або потужний прожектор створюють зони з насиченими пікселями, у яких feature extraction не працює від слова совсім. ARKit обробляє це трохи краще через ARCamera.TrackingState з reason .insufficientFeatures, що хоча б дає можливість показати користувачу попередження. ARCore через TrackingFailureReason.INSUFFICIENT_LIGHT та INSUFFICIENT_FEATURES — аналогічно, але пороги інші.
Флуоресцентні лампи — окремий клас болю. На частотах 50/60 Гц вони створюють мерцання, яке camera sensor фіксує як регулярні перепади експозиції. Візуально це майже непомітно, але алгоритм трекінгу бачить, як feature points «дишать» між кадрами, та інтерпретує це як рух.
Як будується методика тестування
Стандартна матриця тестових сценаріїв для AR-трекінгу включає кілька осей:
За рівнем освітленості: темна кімната (~10–30 лк), офіс зі штучним світом (~300–500 лк), вулиця в пасмурний день (~1000–5000 лк), прямий сонячний світ (>50 000 лк).
За типом джерела: точковий (LED-лампочка), лінійний (флуоресцент/LED-панель), дифузний (пасмурне небо), змішаний (вікно + потолочний світ).
За динамікою: статичне освітлення, проходящі тіні, смена день/ніч через штору, мигаючий джерело.
Для кожного сценарію фіксується: час до втрати трекінгу, максимальний дрейф ARAnchor за 60 секунд, кількість подій .limited у ARCamera.TrackingState, поведінка при повернені в нормальні умови (час відновлення).
Інструментарій: кастомний overlay у Unity AR Foundation з виводом ARSession.state, ARCamera.currentTrackingMode, numberOfTrackedImages — все у real-time на екрані тестового пристрою. Плюс запис через ReplayKit (iOS) або MediaProjection (Android) для подальшого аналізу.
Що робимо з результатами
Якщо трекінг нестабільний у конкретному діапазоні освітленості — це не просто баг у звіті, це задача для проектування UX. Кілька стандартних рішень:
Включення ARWorldTrackingConfiguration.environmentTexturing допомагає ARKit краще розуміти окремження, але жує пам'ять. На iPhone 12 та новіше це компромісс.
Для сценаріїв з поганим світом — принудовий перехід на plane detection з ARPlaneDetectionMode та anchor-и, привязані до площин, а не до feature points. Значно стійкіше, але вимагає плоских поверхонь у кадрі.
Для Android — настройка Config.FocusMode.FIXED замість AUTO у ArSession знижує кількість «розмитих» кадрів при швидкому русі у низькому освітленні.
| Умова освітлення | Очікувана поведінка трекінгу | Типичний сценарій втрати |
|---|---|---|
| < 50 лк | Часті .limited (insufficientFeatures) |
Через 5–10 сек |
| 50–300 лк | Нестабільний, залежить від текстури поверхні | При русі камери |
| 300–5000 лк | Робочий діапазон | Втрата при пересвіті |
| > 20 000 лк (прямо сонце) | Насичений кадр, повна втрата | Одразу |
Процес роботи
Збираємо ТЗ: цільові платформи (iOS/Android, версії ОС, конкретні моделі пристроїв), типичні умови використання приложення (приміщення/вулиця), допустимий дрейф якорів у мілліметрах.
Готуємо тестову обстановку: світильники з диммером, шторы, набір таргетів з різною текстурою поверхні. Якщо тестуємо image tracking — окрема матриця за контрастом маркерів.
Прогоняємо матрицю сценаріїв, фіксуємо метрики, готуємо звіт з конкретними порогами та рекомендаціями. Якщо потрібно — правимо конфігурацію AR-сесії або додаємо UX-обробку критичних станів трекінгу.
Строки — від 2–3 днів для однієї платформи та базового набору сценаріїв до 2–3 тижнів при повному покритті обох платформ з ітераційними виправленнями.
Вартість розраховується індивідуально після аналізу вимог та складу тестової матриці.