Реализация LiDAR-сканирования в iOS AR-приложении

Реализация LiDAR-сканирования в iOS AR-приложении

Мы в TrueTech разрабатываем LiDAR-встраивание для iOS AR-приложений с 2019 года. За это время реализовали 20+ проектов, где точное сканирование пространства стало ключевым — от примерки мебели до навигации внутри помещений. Наш опыт позволяет гарантировать стабильную работу на устройствах с LiDAR и корректный fallback для остальных.

LiDAR-сенсор появился в iPad Pro, iPhone 12 Pro и старше. ARKit использует его данные через ARWorldTrackingConfiguration с включённым sceneReconstruction — и это меняет всё, что касается качества plane detection, окклюзии объектов и скорости инициализации сцены. По нашим замерам, LiDAR-сессия стартует в 10 раз быстрее, чем плоскостное детектирование на нон-LiDAR устройствах.

Без LiDAR ARKit определяет горизонтальные плоскости за 2–5 секунд, вертикальные — ещё дольше. С LiDAR получаем меш окружения за доли секунды. Это не маркетинг — это разница между «AR-объект появляется сразу» и «пользователь машет телефоном 10 секунд перед тем, как что-то произойдёт».

Где конкретно ломается LiDAR-интеграция

Первая проблема — ARMeshGeometry даёт слишком плотный меш. Типичный фрейм: 50 000–200 000 вершин на комнату средних размеров. Если передавать это напрямую в SceneKit или RealityKit без LOD и culling, FPS проседает уже на A14.

Решение: используем ARMeshAnchor и ARMeshGeometry.faces для разреженного меша, а для отображения — ModelEntity с MeshResource.generate(from:) только для видимых секций. ARView в RealityKit умеет делать это через sceneUnderstanding.options с флагом .occlusion — он активирует только необходимый subset меша для расчёта окклюзии, не рендеря весь.

Вторая проблема — raycast в LiDAR-режиме. ARRaycastQuery с типом .estimatedPlane работает иначе, чем .existingPlaneGeometry. На устройствах с LiDAR правильный путь: ARRaycastQuery(origin:direction:allowing:.estimatedPlane, alignment:.any) с последующим уточнением через меш. Если добавить .existingPlaneGeometry как fallback — получаем двойные хиты и артефакты размещения.

Третья — sessionWasInterrupted. Когда пользователь сворачивает приложение, LiDAR-сессия сбрасывает накопленный меш. При восстановлении нужно вызвать session.run(configuration, options: [.removeExistingAnchors, .resetSceneReconstruction]) — без .resetSceneReconstruction старые ARMeshAnchor-и накладываются на новые с дрейфом.

Как мы строим LiDAR-пайплайн

Используем RealityKit 2 как основной рендер-слой: он напрямую интегрирован с ARKit 5+ и использует Metal для рендеринга мешей без CPU-оверхеда SceneKit. Конфигурация:

let config = ARWorldTrackingConfiguration()
config.sceneReconstruction = .meshWithClassification
config.environmentTexturing = .automatic
config.frameSemantics = [.personSegmentationWithDepth]
arView.session.run(config)

meshWithClassification включает классификацию поверхностей (пол, стена, потолок, окно, дверь) — это позволяет фильтровать ARMeshAnchor по ARMeshClassification и реагировать только на нужный тип поверхности. Для приложений с расстановкой мебели или навигацией в помещении это критично.

Для окклюзии объектов за реальными предметами включаем:

arView.environment.sceneUnderstanding.options = [.occlusion, .physics]

.physics добавляет коллизии AR-объектов с реальными поверхностями — AR-куб падает на стол и не проваливается сквозь него.

Кейс: приложение для примерки мебели, iPhone 13 Pro. Без LiDAR-окклюзии диван «висел» поверх ног пользователя при съёмке себя. С .occlusion ноги корректно перекрывают AR-объект. Время инициализации плоскости — 0.3 секунды против 4.2 секунды на нон-LiDAR устройстве.

Как реализовать LiDAR-сканирование: пошаговый план

1. Проверка доступности LiDAR. Вызовите ARWorldTrackingConfiguration.supportsSceneReconstruction(.mesh). Если true — используйте LiDAR-путь, иначе — plane detection.
2. Настройка конфигурации. Включите .meshWithClassification и .environmentTexturing.automatic. Для захвата глубины добавьте .personSegmentationWithDepth.
3. Рендеринг с окклюзией. В RealityKit включите sceneUnderstanding.options = [.occlusion, .physics]. Для пользовательского рендеринга используйте ARMeshAnchor с LOD.
4. Raycast с LiDAR. Используйте .estimatedPlane с alignment: .any. При отсутствии LiDAR — fallback на .existingPlaneGeometry.
5. Обработка прерываний. В sessionWasInterrupted вызовите перезапуск с опциями removeExistingAnchors и resetSceneReconstruction.

Что LiDAR даёт по сравнению с plane detection

Fallback для устройств без LiDAR

LiDAR есть только с iPhone 12 Pro. Для широкого охвата пишем два пути:

if ARWorldTrackingConfiguration.supportsSceneReconstruction(.mesh) {
    // LiDAR path
} else {
    // Plane detection fallback
    config.planeDetection = [.horizontal, .vertical]
}

Это не просто if — это разные UX-сценарии. На нон-LiDAR устройствах показываем индикатор «наведите на поверхность», на LiDAR — сразу предлагаем разместить объект.

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

• Настройка ARWorldTrackingConfiguration с sceneReconstruction и классификацией поверхностей
• Реализация окклюзии и физики через RealityKit sceneUnderstanding
• Оптимизация рендеринга меша (LOD, frustum culling, разреженный меш)
• Корректный raycast с LiDAR и fallback для нон-LiDAR устройств
• Обработка прерываний сессии и восстановление состояния
• Тестирование на реальных устройствах (iPhone 12 Pro+, iPad Pro)

Сроки

Стоимость рассчитывается индивидуально после анализа требований к AR-сцене и целевых устройств. Свяжитесь с нами для консультации — мы поможем оценить объём работ и предложим оптимальное решение. Получите расчёт за 1 день.

Мы разрабатываем 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-идею.