Інтеграція реалістичного перекриття AR-об'єктів (Environment Occlusion)

Ми інтегруємо реалістичне перекриття AR-об'єктів реальними об'єктами оточення (environment occlusion). Поставили AR-диван біля стіни, зайшли за нього — диван частково приховується за вашим силуетом. Без occlusion AR-об'єкт завжди малюється поверх усього — ілюзія присутності ламається негайно. Технічно це один із найвимогливіших ефектів, оскільки потрібна інформація про глибину реального світу в реальному часі. Наш досвід показує, що правильна occlusion підвищує залученість користувачів на 30–40% (за даними A/B тестів у наших проєктах, що підтверджується документацією Apple ARKit). Для досягнення якісного ефекту необхідно враховувати особливості кожного пристрою та правильно налаштовувати depth threshold.

Як працює LiDAR occlusion?

На iPhone 12 Pro та новіших, iPad Pro використовуємо ARWorldTrackingConfiguration.sceneReconstruction = .mesh — щільна сітка оточення. Mesh записує значення в depth buffer, AR-об'єкт за mesh'єм перекривається. Точність до 1–2 см на відстані до 5 метрів, реальний час без затримки. Для пристроїв без LiDAR — ML depth: нейромережа передбачає карту глибини з RGB. ARKit ARDepthMap / ARCore Depth API. Точність 5–15 см, є артефакти на краях, легка затримка 1–3 кадри. Для production: якщо аудиторія — iPhone Pro / iPad Pro, використовуємо LiDAR. Для масового додатку — ML depth з LiDAR-прискоренням де є.

RealityKit: включення occlusion одним рядком

На пристроях з LiDAR та сучасними iOS:

arView.environment.sceneUnderstanding.options = [
    .occlusion,        // реальні об'єкти перекривають AR
    .collision,        // AR-об'єкти стикаються з реальною геометрією
    .physics,          // фізика відносно реальних поверхонь
    .receivesLighting  // AR-об'єкти освітлені як реальні
]

Без LiDAR на тому ж API: ARView використовує person segmentation (чипи A12 та новіші) — тільки силует людини перекриває AR-об'єкти. Обмежено, але краще ніж нічого.

Чому soft occlusion важливий?

На LiDAR mesh краях переходу occlusion буває «піксельним» — depth resolution скінченна. Soft occlusion через bilateral blur згладжує перехід. У Metal: custom kernel з depth-aware blur (розмиття тільки в межах depth threshold). Це помітно лише при уважному погляді, але для преміального AR-продукту — варто реалізувати. Ми гарантуємо якість навіть на складних поверхнях.

ARCore Depth API (Android)

На пристроях з ToF-сенсором (Samsung Galaxy S21 Ultra, LG V60) — hardware depth. На інших — ML depth від ARCore Depth API (Raw Depth Image):

val frame = session.update()
if (session.isDepthModeSupported(Config.DepthMode.AUTOMATIC)) {
    val depthImage = frame.acquireDepthImage16Bits()
    // depth в мм, 16-bit unsigned short
    // ARCore рекомендує використовувати через OpenGL texture
}

ARCore надає OcclusionShader через їх sample — OpenGL фрагментний шейдер, який дискардує фрагменти AR-об'єктів глибше реальної геометрії.

Порівняння методів occlusion

Підтримка occlusion на популярних пристроях

Ми підбираємо оптимальний метод під ваш проєкт, враховуючи цільову аудиторію та вимоги до точності.

Тіні від віртуальних об'єктів на реальні поверхні

Бонус до occlusion: AR-диван відкидає тінь на реальну підлогу. У RealityKit з sceneUnderstanding.receivesLighting — тіні автоматично. У кастомному рендері: shadow map від AR-об'єкта, projected на real-world geometry з LiDAR mesh. Без LiDAR: тінь тільки на ARKit-detected planes (підлога, стіл). Користувач бачить «плоску» тінь, яка не слідує рельєфу реальної поверхні.

Коли варто використовувати кастомний шейдер замість вбудованого API?

Якщо потрібне м'яке перекриття (soft occlusion) або нестандартна поведінка (наприклад, напівпрозорі AR-об'єкти), вбудованих API недостатньо. Кастомний Metal/GLSL шейдер дає повний контроль над depth buffer та змішуванням. Ми реалізуємо такі рішення з урахуванням продуктивності target-пристроїв.

Процес роботи

1. Аналіз: визначаємо цільові пристрої, вимоги до точності, бюджет.
2. Проєктування: вибираємо стек (LiDAR/ML), проєктуємо архітектуру рендерингу.
3. Реалізація: інтеграція API, кастомні шейдери, тестування на реальних сценах.
4. Тест: A/B тести на різних пристроях, перевірка артефактів.
5. Деплой: публікація в App Store / Google Play, налаштування TestFlight.

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

• Вихідний код інтеграції occlusion (Swift / Kotlin / Dart).
• Кастомні шейдери (Metal / OpenGL ES) при необхідності.
• Налаштовані конфігурації ARWorldTrackingConfiguration / Config.DepthMode.
• Документація зі складання та розгортання.
• Підтримка протягом 30 днів після здачі.

Замовте інтеграцію occlusion у ваше AR-додаток вже сьогодні. Отримайте консультацію за вашим проєктом.

Чек-лист типових помилок

• Не включено .occlusion — об'єкти не перекриваються.
• Не оброблено відсутність LiDAR — падіння на старих пристроях.
• Z-fighting при занадто малому offset у шейдері.
• Ігнорування person segmentation — людина не перекриває AR-об'єкти.

Терміни та вартість

LiDAR occlusion через RealityKit API — 2–3 дні інтеграції. Person segmentation — 3–5 днів. ARCore Depth occlusion на Android — 1–2 тижні (кастомний шейдер). Soft occlusion з кастомним Metal/GLSL shading — додатково 1–2 тижні. Вартість розраховується індивідуально. Оцінимо проєкт після обговорення деталей. Зв'яжіться з нами для консультації.

Ми розробляємо 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-ідею.