Реализация 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% меньше сбоев в сценариях с низким освещением), но 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-идею.