Тестирование стабильности трекинга в различных условиях освещения AR
AR-трекинг ломается не от плохого кода — он ломается от плохого света. Это одна из тех проблем, которую невозможно воспроизвести на столе разработчика в комфортном офисе. Солнечный свет, бьющий в окно под углом 15 градусов, флуоресцентные лампы с мерцанием на частоте 100 Гц, тёмная комната с одним точечным источником — каждый из этих сценариев ведёт себя по-разному, и ARCore с ARKit реагируют на них совершенно по-разному.
Почему трекинг теряет якоря именно там, где вы не ожидаете
Алгоритмы visual inertial odometry, на которых построены ARCore и ARKit, используют feature points — характерные точки в кадре — для вычисления положения камеры в пространстве. При освещённости ниже ~50 лк количество надёжных feature points резко падает, и система начинает компенсировать потерю данных за счёт IMU. Это нормально, пока IMU не накапливает дрейф. На практике — 3–4 секунды в плохо освещённой зоне, и виртуальный объект «уплыл» на 5–8 сантиметров. В игровом контексте это катастрофа: игрок смотрит на стол, ожидает увидеть фигурку там, куда поставил, а она висит в воздухе.
Отдельная история — пересвет. Прямой солнечный свет или мощный прожектор создают зоны с saturated пикселями, в которых 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 лк (прямое солнце) | Saturated frame, полная потеря | Немедленно |
Процесс работы
Собираем ТЗ: целевые платформы (iOS/Android, версии ОС, конкретные модели устройств), типичные условия использования приложения (помещение/улица), допустимый дрейф якорей в миллиметрах.
Готовим тестовую среду: светильники с диммером, шторы, набор таргетов с разной текстурой поверхности. Если тестируем image tracking — отдельная матрица по контрасту маркеров.
Прогоняем матрицу сценариев, фиксируем метрики, готовим отчёт с конкретными порогами и рекомендациями. Если нужно — правим конфигурацию AR-сессии или добавляем UX-обработку критических состояний трекинга.
Сроки — от 2–3 дней для одной платформы и базового набора сценариев до 2–3 недель при полном покрытии обеих платформ с итерационными исправлениями.
Стоимость рассчитывается индивидуально после анализа требований и состава тестовой матрицы.