Тестирование стабильности AR-трекинга в разных условиях освещения
Пользователь ставит виртуальный объект на стол, а тот висит в воздухе — это не баг, а потеря трекинга из-за освещения. Мы сталкиваемся с этим на каждом втором проекте. Солнечный свет под углом 15°, флуоресцентное мерцание 100 Гц, тёмная комната с точечным LED — каждый сценарий ломает трекинг по-своему. Многолетний опыт (более 30 проектов с трекингом) позволяет предсказать эти сценарии и устранить их до релиза. Свяжитесь с нами для детального аудита вашего проекта.
Причины потери трекинга при плохом освещении
Алгоритмы 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 |
Что делать, если трекинг сбоит на солнце
Отметим: когда трекинг нестабилен в конкретном диапазоне — это задача для UX. Несколько приёмов:
- Включение
ARWorldTrackingConfiguration.environmentTexturingпомогает ARKit лучше понимать окружение, но увеличивает потребление памяти. На iPhone 12 и старше это оправдано. - Для плохого света — принудительный plane detection с
ARPlaneDetectionModeи якоря к плоскостям вместо feature points. Так устойчивее. - На Android — настройка
Config.FocusMode.FIXEDснижает «размытые» кадры при быстром движении в низком освещении.
Неправильная оценка освещения обходится в дополнительные недели QA и до 20% бюджета на переделку. Своевременное тестирование экономит до 40% бюджета на этапе оптимизации.
Как провести тестирование AR-трекинга: пошаговый план
- Соберите ТЗ: целевые платформы, версии ОС, модели устройств, типичные условия использования, допустимый дрейф якорей.
- Подготовьте тестовую среду: регулируемые светильники, шторы, набор таргетов с разной текстурой.
- Прогоните матрицу сценариев, фиксируя метрики: время до потери трекинга, дрейф ARAnchor, события
.limited. - Проанализируйте результаты: определите критические пороги освещённости для каждой платформы.
- Внесите коррективы в конфигурацию AR-сессии и UX-обработку состояний.
Что входит в работу
- Разработка тестовой матрицы под вашу специфику (платформы, устройства, типичные сценарии).
- Проведение тестов на iOS/Android с фиксацией метрик.
- Документирование результатов: пороги дрейфа, рекомендации по конфигурации сессии.
- Интеграция обработки состояний трекинга в код проекта.
- Обучение команды: мини-документация и code review.
Процесс работы
Собираем ТЗ: целевые платформы, версии ОС, модели устройств, типичные условия использования, допустимый дрейф якорей. Готовим тестовую среду: регулируемые светильники, шторы, набор таргетов с разной текстурой. Прогоняем матрицу сценариев, фиксируем метрики, готовим отчёт с порогами и рекомендациями. При необходимости правим конфигурацию AR-сессии или добавляем UX-обработку критических состояний.
Сроки — от 2–3 дней для одной платформы до 2–3 недель для полного покрытия с итерациями. Стоимость тестирования одной платформы — от 500 до 1500 у.е. Закажите консультацию — оценим ваш проект за 1 день. Работаем под ключ.