AR-сканирование плоскостей в мобильном приложении под ключ

Реализация AR-сканирования плоскостей в мобильном приложении

Мы часто сталкиваемся с ситуацией: клиент хочет разместить виртуальный диван в комнате, но приложение показывает «плавающий» объект без чёткой привязки к полу. Пользователь разочарован, а разработчик упирается в ограничения платформенных SDK. Стабильное определение плоскостей — ключ к убедительному AR. Без него любой AR-объект воспринимается как инородный элемент. Мы научились доводить plane detection до состояния «стоит как настоящее» за 5-8 дней.

Платформенные API и их реальные ограничения

ARKit (iOS). ARWorldTrackingConfiguration с planeDetection: [.horizontal, .vertical]. ARKit возвращает ARPlaneAnchor с ARPlaneGeometry — mesh плоскости, который обновляется по мере сканирования. Проблема: на первых секундах ARKit возвращает маленький прямоугольник, который агрессивно меняет размер и ориентацию. Если разместить объект сразу — он «прыгнет» при следующем обновлении.

Решение — минимальный confidence threshold и debounce на обновления. ARPlaneAnchor не имеет явного поля confidence, но размер плоскости (extent) служит косвенным показателем зрелости: не показывать UI для размещения, пока extent.x < 0.3 и extent.z < 0.3 метра.

ARCore (Android). Plane с TrackingState.TRACKING и PlaneType.HORIZONTAL_UPWARD_FACING / VERTICAL. ARCore дополнительно предоставляет Plane.getSubsumedBy() — когда две плоскости сливаются в одну. Это ломает логику, если якоря были привязаны к исходным плоскостям — нужно переносить Anchor на subsuming plane.

Vertical planes. ARKit стабильно определяет вертикальные плоскости на текстурированных поверхностях (стена с обоями — хорошо, монотонно белая стена — плохо). ARCore с vertical detection работает ещё менее уверенно. Для продуктов, где критична навеска на стену (картины, полки), лучше использовать комбинацию plane detection + LiDAR (iPhone 12 Pro+) для достройки недостающей геометрии.

Как LiDAR меняет правила игры?

На устройствах с LiDAR (iPhone 12 Pro, 13 Pro, 14 Pro, 15 Pro, iPad Pro) ARKit строит dense mesh окружения через ARMeshAnchor. Plane detection с LiDAR работает принципиально иначе: плоскости выводятся из mesh, а не из визуального SLAM. Это даёт:

• Детектирование плоскости за 1-2 секунды вместо 5-10
• Стабильные границы даже на монотонных поверхностях
• Корректное определение ступеней, пандусов, наклонных плоскостей

Для приложений, где LiDAR-устройства — основная ЦА (профессиональная съёмка, ремонт, строительство), переключение между ARWorldTrackingConfiguration и конфигурацией с sceneReconstruction: .mesh даёт качественный скачок.

Почему плоскость "прыгает" и как это исправить?

Основная причина — размещение объекта до того, как плоскость стабилизировалась. Confidence threshold и debounce решают проблему на 80%. Проверенный подход:

1. Не показывать кнопку размещения, пока размер плоскости не превысит 0.3 метра по каждой оси.
2. При обновлении плоскости плавно перемещать якорь с анимацией (например, SCNAction в SceneKit или UIView.animate в RealityKit).
3. Использовать ARWorldTrackingConfiguration.isAutoFocusEnabled для улучшения качества кадра.

Визуализация прогресса сканирования

Пользователь не знает, что нужно «поводить» камерой — нужна чёткая подсказка. Типовые паттерны:

• Анимированный сканирующий луч из нижней части экрана
• Outline плоскости, который «растёт» по мере обнаружения
• Текстовая инструкция с автоскрытием после первого успешного detection

Для отрисовки границ плоскости в RealityKit — ModelEntity с wireframe материалом, привязанный к PlaneAnchor. В SceneKit — SCNNode с SCNGeometry из ARPlaneGeometry.boundaryVertices. В ARCore Scenekit/Filament — собственный меш из Plane.getPolygon().

Типичные проблемы в production

Плоскость «ломается» при сильном движении камерой — tracking state переходит в LIMITED(.excessiveMotion). Нужно блокировать размещение объектов и показывать предупреждение, а не крашиться.

На тёмных поверхностях (тёмный ламинат, чёрный ковёр) ARKit и ARCore теряют features для визуального SLAM. Предупреждение через ARCamera.TrackingState.Reason.insufficientFeatures — обязательно обрабатывать и сообщать пользователю.

Что входит в работу

• Тестирование на целевых устройствах с оценкой стабильности
• Оптимизация под LiDAR (если поддерживается)
• Реализация multi-plane selection (возможность выбора плоскости касанием)
• Сохранение ARWorldMap для повторного использования сцены
• Документация по интеграции и настройке
• Гарантия стабильной работы: мы даём 30 дней безплатной поддержки после сдачи

Сравнение методов визуализации

Apple ARKit documentation: ARKit Plane Detection Google ARCore documentation: Plane Detection

Сроки ориентировочно

Реализация базового plane detection с визуальной подсказкой и размещением объекта — от 5 до 8 дней. Доработка под LiDAR, multi-plane selection, сохранение ARWorldMap — ещё 5-7 дней. Стоимость рассчитывается индивидуально, в зависимости от сложности. Получите консультацию — свяжитесь с нами для оценки вашего проекта.

Наша команда имеет 5+ лет опыта в AR-разработке и более 20 успешных проектов. Закажите реализацию под ключ и получите консультацию бесплатно.

Мы разрабатываем AR-приложения на ARKit и ARCore, которые работают стабильно даже в сложных условиях. Наш опыт — 7+ лет в мобильной разработке и 30+ реализованных проектов с дополненной реальностью. Гарантируем: трекинг не потеряется, освещение будет реалистичным, а пользователь не почувствует дискомфорта. Сертифицированные разработчики Apple и Google.

Почему трекинг теряется и как это исправить?

ARKit и ARCore используют VIO (Visual-Inertial Odometry) — совместную обработку данных камеры и IMU. Трекинг срывается в трёх сценариях: освещение ниже ~50 lux, текстурно однородные поверхности (белая стена, стекло) и быстрые движения камеры.

На практике это значит: если продукт предназначен для примерки мебели, добавляем явное UI-предупреждение при ARCamera.TrackingState.limited(.insufficientFeatures). Приложение, которое молча теряет трекинг, получает 2-звёздочные отзывы — мы такое не допускаем.

Обнаружение плоскостей настраивается через ARWorldTrackingConfiguration.planeDetection = [.horizontal, .vertical]. Важно: ARKit продолжает уточнять геометрию плоскостей через ARSCNViewDelegate.renderer(_:didUpdate:for:) — если не обрабатывать обновления, объект начинает плавать при уточнении якоря. Наша команда решает эту проблему на этапе архитектуры, а не при тестировании.

AR Foundation: кросс-платформа с нюансами

Unity AR Foundation — слой абстракции поверх ARKit и ARCore. Он сокращает время разработки на 40% по сравнению с раздельными нативными кодовыми базами. Но некоторые функции (например, ARBodyTrackingConfiguration для body tracking) недоступны и требуют нативного плагина.

Для React Native и Flutter прямой AR Foundation отсутствует. Используем ViroReact (React Native) или ar_flutter_plugin для простых сценариев, но для production-качества — нативные модули с мостом. Гибридный подход: AR-сцена рендерится нативным ARKit/ARCore view, управление из JS/Dart через method channel. Входит в нашу стандартную поставку.

Сравнение платформ: ARKit опережает ARCore по стабильности трекинга и набору функций (на 30% меньше сбоев в сценариях с низким освещением), но AR Core дешевле в поддержке устройств. AR Foundation — компромисс: теряет до 20% производительности на сложных сценах, но окупается единой кодовой базой.

Try-on: примерка товаров через AR

Примерка очков, украшений, косметики — отдельный класс задач. Здесь нужен face tracking, а не plane detection.

ARKit предоставляет ARFaceTrackingConfiguration — 52 blend shape коэффициента для мимики, 3D-меш лица, позиция и ориентация в пространстве. Работает только на устройствах с TrueDepth-камерой (iPhone с Face ID).

Для Android эквивалент — ML Kit Face Mesh Detection или Google ARCore Augmented Faces (Pixel и некоторые флагманы). Для кросс-платформенного try-on используем Banuba Face AR SDK (Banuba Face AR SDK documentation) — покрывает оба устройства, даёт готовые маски и стабильный трекинг даже на mid-range Android.

Качество try-on критически зависит от 3D-моделей товаров. Модели должны быть оптимизированы под real-time: не более 10-15K полигонов для украшений, PBR-материалы с корректными roughness/metallic картами, LOD для дальних дистанций. В рамках нашего подряда мы предоставляем готовые гайды по оптимизации моделей.

Как добиться реалистичного освещения в AR?

ARKit с современными версиями iOS поддерживает Environmental Texturing — автоматическое создание environment map из камеры для реалистичных отражений. Включается через ARWorldTrackingConfiguration.environmentTexturing = .automatic. Без этого металлические и стеклянные материалы выглядят пластиково.

ARCore предоставляет Light Estimation — intensity и color temperature окружающего света, применяемые к шейдеру виртуальных объектов. На практике это разница между объектом, который «вписывается» в сцену, и очевидно наложенной 3D-моделью. Мы гарантируем, что финальное изображение не выдаёт виртуальности.

Что входит в работу

• Архитектура AR-решения (выбор стека, проектирование модулей)
• 3D-пайплайн: оптимизация моделей под real-time, PBR-материалы, LOD
• Интеграция трекинга (плоскости, лица, изображения, объекты)
• Тестирование на 10+ реальных устройствах (iOS и Android)
• Документация по использованию SDK и готовых компонентов
• Поддержка после запуска (1 месяц баг-фиксинга)

Сроки и оценка

Простая AR-сцена с размещением одной 3D-модели на плоскости — 1–2 недели. Face try-on с каталогом товаров — от 6 недель (3D-пайплайн, интеграция трекинга, UI выбора и сохранения). Полноценный AR-шоппинг с облачными якорями и мультиплеером — от 3 месяцев. Оценим проект за 1 день — пишите, обсудим вашу AR-идею.