Реалізація LiDAR-сканування в iOS AR-застосунку

Реалізація LiDAR-сканування в iOS AR-додатку

LiDAR-сенсор з'явився в iPad Pro 2020, iPhone 12 Pro і новіше. ARKit використовує його дані через ARWorldTrackingConfiguration з включеним sceneReconstruction — і це змінює все, що стосується якості plane detection, окклюзії об'єктів та швидкості ініціалізації сцени.

Без 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 пристрої.

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-сцени та цільових пристроїв.