Тестування стабільності AR-трекінгу в різних умовах освітлення
Користувач ставить віртуальний об'єкт на стіл, а той висить у повітрі — це не баг, а втрата трекінгу через освітлення. Ми стикаємося з цим на кожному другому проєкті. Сонячне світло під кутом 15°, флуоресцентне мерехтіння 100 Гц, темна кімната з точковим LED — кожен сценарій ламає трекінг по-своєму. Багаторічний досвід (понад 30 проєктів, 5+ років на ринку) дозволяє передбачити ці сценарії та усунути їх до релізу. Зв'яжіться з нами для детального аудиту вашого проєкту.
Чому трекінг втрачається при поганому освітленні?
Алгоритми Visual Inertial Odometry (VIO), на яких побудовані ARCore та ARKit, використовують feature points — характерні точки в кадрі — для обчислення положення камери. При освітленості нижче ~50 лк кількість надійних точок різко падає, і система компенсує втрату за рахунок IMU. Це працює, поки IMU не накопичує дрейф. На практиці — 3–4 секунди в поганому світлі, і якір «спливає» на 5–8 см. В іграх це катастрофа: об'єкт висить у повітрі замість поверхні.
Пересвіт також критичний: пряме сонячне світло створює зони з saturated пікселями, де feature extraction не працює. ARKit повідомляє про це через ARCamera.TrackingState з reason .insufficientFeatures, ARCore — через TrackingFailureReason.INSUFFICIENT_LIGHT. Пороги спрацьовування різняться, але обидва дають можливість показати користувачеві попередження.
Флуоресцентні лампи — окремий клас болю. На частотах 50/60 Гц вони створюють мерехтіння, яке сенсор фіксує як регулярні перепади експозиції. Візуально це майже непомітно, але алгоритм бачить, як feature points «дихають» між кадрами, та інтерпретує це як рух камери. Згідно з документацією Apple, ARKit використовує VIO та детектує нестачу освітленості через ARCamera.TrackingState.
Як ми тестуємо різні типи освітлення?
Стандартна матриця тестів включає три осі:
- Рівень освітленості: темна кімната (~10–30 лк), офіс (~300–500 лк), похмура вулиця (~1000–5000 лк), пряме сонячне світло (>50 000 лк).
- Тип джерела: точковий (LED), лінійний (флуоресцентна лампа), дифузний (хмари), змішаний (вікно + стеля).
- Динаміка: статика, тіні, що проходять, зміна день/ніч, миготливе світло.
Для кожного сценарію фіксуємо: час до втрати трекінгу, максимальний дрейф ARAnchor за 60 секунд, кількість подій .limited, час відновлення.
Інструментарій: кастомний overlay в Unity AR Foundation з виведенням стану сесії в реальному часі, запис через ReplayKit (iOS) або MediaProjection (Android).
| Умова освітлення | Очікувана поведінка трекінгу | Типовий сценарій втрати |
|---|---|---|
| < 50 лк | Часті .limited (insufficientFeatures) |
Через 5–10 сек |
| 50–300 лк | Нестабільний, залежить від текстури поверхні | При русі камери |
| 300–5000 лк | Робочий діапазон | Втрата при пересвіті |
| > 20 000 лк (пряме сонце) | Saturated frame, повна втрата | Негайно |
Детальніше про методику
Тестування проводиться на реальних пристроях з різними камерами (останні моделі iPhone та Galaxy). Ми використовуємо димовані LED-панелі для точного встановлення рівня освітленості та спектрометр для верифікації.Порівняння ARCore та ARKit при низькому освітленні
| Параметр | ARCore | ARKit |
|---|---|---|
Поріг переходу в .limited |
~30 лк | ~50 лк |
| Реакція на мерехтіння | Довше утримує трекінг | Частіше переходить у .limited |
| Використання IMU при втраті feature points | Агресивна фільтрація зсуву | Швидке сповіщення через .insufficientFeatures |
ARCore утримує трекінг на 30% довше ніж ARKit в умовах мерехтіння, що важливо для додатків з довгими сесіями.
Що робити, якщо трекінг збоїть на сонці
Зазначимо: коли трекінг нестабільний у конкретному діапазоні — це задача для UX. Декілька прийомів:
- Включення
ARWorldTrackingConfiguration.environmentTexturingдопомагає ARKit краще розуміти оточення, але збільшує споживання пам'яті. На iPhone 12 і старше це виправдано. - Для поганого світла — примусовий plane detection з
ARPlaneDetectionModeта якорі до площин замість feature points. Так стійкіше. - На Android — налаштування
Config.FocusMode.FIXEDзнижує «розмиті» кадри при швидкому русі в низькому освітленні.
Неправильна оцінка освітлення обходиться в додаткові тижні QA та до 20% бюджету на переробку. Своєчасне тестування дозволяє заощадити до 40% бюджету на етапі оптимізації, що для середнього проєкту становить близько $2000–$5000.
Як провести тестування AR-трекінгу: покроковий план
- Зберіть ТЗ: цільові платформи, версії ОС, моделі пристроїв, типові умови використання, допустимий дрейф якорів.
- Підготуйте тестове середовище: регульовані світильники, штори, набір таргетів з різною текстурою.
- Проженіть матрицю сценаріїв, фіксуючи метрики: час до втрати трекінгу, дрейф ARAnchor, події
.limited. - Проаналізуйте результати: визначте критичні пороги освітленості для кожної платформи.
- Внесіть корективи в конфігурацію AR-сесії та UX-обробку станів.
Що входить у роботу
- Розробка тестової матриці під вашу специфіку (платформи, пристрої, типові сценарії).
- Проведення тестів на iOS/Android з фіксацією метрик.
- Документування результатів: пороги дрейфу, рекомендації з конфігурації сесії.
- Інтеграція обробки станів трекінгу в код проєкту.
- Навчання команди: міні-документація та code review.
Гарантуємо якість тестування з першої ітерації завдяки сертифікованим фахівцям з AR (досвід роботи з ARKit та ARCore понад 5 років).
Процес роботи
Збираємо ТЗ: цільові платформи, версії ОС, моделі пристроїв, типові умови використання, допустимий дрейф якорів. Готуємо тестове середовище: регульовані світильники, штори, набір таргетів з різною текстурою. Проженяємо матрицю сценаріїв, фіксуємо метрики, готуємо звіт з порогами та рекомендаціями. При необхідності правимо конфігурацію AR-сесії або додаємо UX-обробку критичних станів.
Терміни — від 2–3 днів для однієї платформи до 2–3 тижнів для повного покриття з ітераціями. Для невеликих проєктів вартість тестування стартує від $500, для комплексних — до $3000. Замовте консультацію — оцінимо ваш проєкт за 1 день. Працюємо під ключ.