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 — власний mesh з Plane.getPolygon().

Типові проблеми в production

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

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

Що входить у роботу

• Тестування на цільових пристроях з оцінкою стабільності
• Оптимізація під LiDAR (якщо підтримується)
• Реалізація multi-plane selection (можливість вибору площини дотиком)
• Збереження ARWorldMap для повторного використання сцени
• Документація з інтеграції та налаштування
• Гарантія стабільної роботи: ми даємо 30 днів безкоштовної підтримки після здачі

Порівняння методів візуалізації

Документація Apple ARKit: ARKit Plane Detection Документація Google ARCore: 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% менше збоїв у сценаріях з низьким освітленням), але ARCore дешевший у підтримці пристроїв. 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 — покриває обидва пристрої, дає готові маски та стабільний трекінг навіть на 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-ідею.