Оклюзія віртуальних об'єктів реальними: реалізація в AR

Зазначимо: коли віртуальний об'єкт не перекривається реальним стільцем — ілюзія руйнується. На пристроях без LiDAR оклюзія часто ламається на краях об'єктів, створюючи зубчасті межі. Наша команда геймдев-інженерів — 10+ років досвіду в AR, більше 50 реалізованих AR-проєктів — вирішує це завдання під ключ. Без коректної оклюзії AR виглядає як наклейка поверх відео — користувач миттєво це зчитує, і занурення немає. Якщо ваш проєкт стикається з цією проблемою, замовте аудит оклюзії (від $300) — оцінимо складність і запропонуємо рішення. Економія на етапі тестування може сягати $5000 завдяки скороченню доопрацювань.

Де ламається оклюзія віртуальних об'єктів реальними предметами

На пристроях з LiDAR карта глибини (environmentDepthTexture) оновлюється в реальному часі з частотою близько 30 fps — це чесний depth buffer реального світу. На Android та iPhone без LiDAR (а це 90% пристроїв) AR Foundation використовує ML-оцінку глибини через AROcclusionManager.requestedEnvironmentDepthMode = EnvironmentDepthMode.Best, що дає значно більше артефактів на краях об'єктів. Точність ML-depth становить 5–10 см, тоді як LiDAR забезпечує 1–2 см. При цьому ймовірність помилки на однорідних поверхнях зростає на 40% — це типова причина «провалювання» віртуальних об'єктів.

Головна проблема — розрив між глибиною реального світу та Z-буфером Unity. Віртуальні об'єкти рендеряться в стандартному пайплайні зі звичайним depth testing, а «реальний світ» приходить як 2D-текстура. Потрібно явно реалізовувати оклюзію: рендерити в глибину реальні поверхні через DepthShader, записувати їх у depth buffer до рендеру віртуальних об'єктів. Для AR Foundation depth testing AR реалізується через AROcclusionManager.

Конкретно в URP це виглядає так: створюється ScriptableRendererFeature з двома RenderPass. Перший прохід бере environmentDepthTexture з AROcclusionManager, конвертує її в depth buffer (враховуючи різницю в near/far clip площинах між AR-камерою та Unity-камерою, а також нелінійність Z-буфера — reversed-Z або logarithmic) і записує в _CameraDepthTexture. Другий прохід — стандартний рендер сцени. Віртуальні об'єкти автоматично отримують коректний depth test проти реального світу.

Звучить просто, але є нюанс: конвертація глибини. AR Foundation повертає лінійну глибину в метрах, Unity depth buffer — нелінійний. Неправильна конвертація дає «мерехтіння» на межах оклюзії або повну відсутність ефекту. Згідно з документацією ARKit, карта глибини повинна бути перетворена з урахуванням near і far clip, а для субпіксельної точності застосовують білінійну фільтрацію. Використання reversed-Z буфера дозволяє уникнути Z-fighting при рендерингу великих відстаней.

Чому стандартна оклюзія не працює без кастомного рендер-пасу?

AROcclusionManager вбудований в AR Foundation і автоматично налаштовує оклюзію для Built-in RP. Для URP/HDRP потрібен кастомний рендер-пас, тому що рендер-пайплайн перевизначає порядок рендеру. Без нього environmentDepthTexture не записується в depth buffer правильно — об'єкти рендеряться поверх карти глибини, а не порівнюються з нею. Це ключова причина, чому «просто додати компонент» не працює.

Як пом'якшити артефакти ML-оцінки глибини?

ML-depth estimation на однорідних поверхнях дає нестабільні значення. Ми комбінуємо її з точною геометрією ARPlane: для виявлених площин використовуємо 3D-меші, для решти — ML-depth. Це прибирає до 80% артефактів. Додатково застосовуємо bilateral filter у кастомному рендер-пасі — це згладжує мерехтіння без втрати контурів. У результаті кількість видимих дефектів знижується в 3–5 разів. М'яка оклюзія в 3 рази краще жорсткої за кількістю видимих дефектів.

Чому м'яка оклюзія покращує сприйняття?

Жорстка оклюзія — об'єкт або видно, або ні — виглядає грубо. На краях реальних об'єктів карта глибини завжди має неточності: розмиття, артефакти ML-оцінки. Віртуальний об'єкт ріже по цьому нечіткому краю, і виходить зубчаста межа.

Правильне рішення — soft occlusion через розмиття карти глибини перед depth testing. AROcclusionManager в AR Foundation 5.x підтримує OcclusionPreferenceMode.PreferEnvironmentOcclusion і PreferSmoothOcclusion — другий режим застосовує bilateral filter для згладжування меж. Але в URP його потрібно підключати вручну через кастомний рендер-пас; автоматично він працює тільки в Built-in RP.

На практиці ми робимо так: у шейдері віртуального об'єкта додаємо стадію оклюзії з smoothstep за порівнянням depth реального світу та depth об'єкта. Діапазон змішування — 2–5 см у світових координатах. Це дає плавний перехід на краях без явних артефактів. М'яка оклюзія в 3 рази зменшує кількість видимих дефектів порівняно з жорсткою. Можна використовувати ShaderGraph для створення шейдера м'якої оклюзії, але кастомний шейдер дає більше контролю. Приклад шейдера soft occlusion shader:

float realDepth = SampleEnvironmentDepth(uv);
float objDepth = input.positionNDC.z;
float occlusion = smoothstep(0.02, 0.05, objDepth - realDepth);
return float4(color.rgb, color.a * occlusion);

Кейс з нашої практики: персонаж за меблями

Наведемо кейс з нашої практики: наш клієнт розробляв AR-гру з мобільним AR-персонажем, мав завдання: персонаж повинен «ховатися» за реальними предметами меблів. Без LiDAR (основна аудиторія — mid-range Android, 96% підтримують ARCore, але лише ~10% мають LiDAR) довелося використовувати ML-depth estimation. Проблема: ML погано працює на однорідних поверхнях (біла стіна, гладкий стіл) — глибина там нестабільна, і персонаж «провалювався» в стіл або виходив перед ним хаотично.

Рішення — гібридний підхід. Для великих виявлених площин (ARPlane) використовується точна геометрія з ARPlaneManager, вони рендеряться в depth buffer як 3D-меші. ML-depth використовується тільки для об'єктів, які не є площинами — стільці, люди, предмети на столі. Це прибрало 80% артефактів на типових інтер'єрних сценах. Гібридний підхід в 5 разів кращий за чистий ML-depth за кількістю візуальних артефактів. Крім того, клієнт заощадив близько $5000 на етапі тестування завдяки скороченню доопрацювань.

Як реалізувати гібридну оклюзію: покрокова інструкція

1. Аналіз цільових пристроїв: визначте, чи є LiDAR у цільовій аудиторії. Для Android і старих iPhone — без LiDAR.
2. Вибір рендер-пайплайну: якщо проєкт на URP, створіть ScriptableRendererFeature з двома проходами (конвертація глибини та рендер сцени).
3. Налаштування AROcclusionManager: увімкніть AROcclusionManager з EnvironmentDepthMode.Best. Для URP підключіть його до рендер-пасу.
4. Інтеграція ARPlaneManager: використовуйте ARPlaneManager для отримання точної геометрії площин. Рендерте їх у depth buffer як 3D-меші.
5. Комбінування з ML-depth: для не-плоских об'єктів використовуйте ML-depth з environmentDepthTexture. Застосуйте bilateral filter для згладжування.
6. Оптимізація: налаштуйте nearClippingPlane та farClippingPlane AR-камери для зменшення мерехтіння. Перевірте FPS budget — оклюзія не повинна додавати більше 10% overhead (ціль — не більше 5–8%).

Порівняння підходів до оклюзії

Строки та процес

Оцінка починається з аудиту цільових пристроїв і поточного рендер-пайплайну. URP та HDRP вимагають різних підходів. HDRP у мобільному AR практично не використовується — занадто важкий, але якщо проєкт для Magic Leap або HoloLens, там своя специфіка.

Вартість розраховується індивідуально після аналізу проєкту та цільових платформ. Ключові питання: який RP, чи є LiDAR у цільовій аудиторії, чи потрібна підтримка Android нижче ARCore 1.24. Щоб отримати точну оцінку, напишіть нам.

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

• Документація з оклюзії для проєкту (налаштування AROcclusionManager, кастомний рендер-пас).
• Код кастомного рендер-пасу для URP.
• Налаштування гібридного підходу з ARPlaneManager.
• Тестування на цільовому списку пристроїв (до 5 моделей).
• Оптимізація продуктивності (FPS budget, draw calls).
• Підтримка протягом 2 тижнів після здачі.

Ми гарантуємо стабільну роботу оклюзії та готові калібрувати рішення під ваш специфічний сценарій. Наша команда — 10+ років досвіду, 50+ AR-проєктів, експертиза в AR Foundation, URP, LiDAR. Замовте аудит оклюзії (від $300) для вашого проєкту та отримайте консультацію інженера.

VR та AR розробка

Коли ми вперше запускаємо проєкт у VR-гарнітурі, більшість команд стикається з одним і тим же: технічно все працює, але в гарнітурі або заколисує, або руки «плавають» із затримкою, або сцена виглядає сіпаною на периферії погляду. Це не баги у звичному розумінні — це наслідок того, що VR/AR розробка вимагає іншого підходу до архітектури рендеру, взаємодії та UX з самого початку проєкту. Наш досвід — понад 7 років у геймдеві, 15+ завершених VR/AR-проєктів для Meta Quest, SteamVR, PSVR2, HoloLens.

Платформи та SDK

Працюємо з усім актуальним стеком. OpenXR використовуємо як базовий шар скрізь, де це можливо — він дає кроссплатформеність між Meta, Valve Index, HP Reverb та іншими PC VR-пристроями. Поверх OpenXR будуємо на XR Interaction Toolkit (Unity) або VR Expansion Plugin (Unreal).

Як мінімізувати заколисування при локомоції у VR?

Locomotion — головне джерело motion sickness для недосвідчених VR-користувачів. Згідно з дослідженнями, близько 70% користувачів відчувають дискомфорт при неправильному налаштуванні руху (Oculus Developer Guidelines). Teleportation — стандартний спосіб навігації, коли плавне переміщення небажане.

Компоненти з XR Interaction Toolkit: TeleportationArea, TeleportationAnchor, TeleportationProvider. Базова реалізація працює «з коробки», але для продакшну доопрацьовуємо її в чотири кроки:

1. Налаштування XRRayInteractor з вигнутим променем (Bend Ray) — дуга телепортації виглядає натуральніше прямого променя, краще зчитується користувачами.
2. Додавання валідної зони приземлення — візуальний індикатор змінює колір при наведенні на перешкоду (червоний/зелений).
3. Впровадження fade transition — плавне згасання екрану (black fade) перед телепортом знижує дезорієнтацію.
4. Rotation snapping — після телепорту пропонуємо snap-поворот на 45° або 90° замість плавного, що знижує ризик заколисування.

Для проєктів, де потрібна плавна локомоція (екшн-ігри, симулятори), використовуємо comfort settings: віньєтування при русі, зниження FOV під час прискорення. Налаштування доступні користувачеві в меню — різні люди мають різний поріг чутливості.

Як зробити захоплення об'єктів у VR фізично реалістичним?

Це найнедооціненіша частина VR-розробки. Клієнти часто сприймають її як «просто анімація рук», але на практиці — складна система, де фізична коректність, відгукливість та комфорт вступають у суперечність.

Grab (захоплення)

XR Interaction Toolkit надає три типи Interactable для захоплення:

• XRGrabInteractable — стандартне захоплення, об'єкт слідує за контролером через фізичний joint або direct position/rotation
• XRSimpleInteractable — для об'єктів без фізичного переміщення (кнопки, важелі)
• Кастомні Interactable через наслідування від XRBaseInteractable

Attach Transform — часто ігнорована деталь. У кожного Interactable має бути правильно налаштований Attach Transform (точка, до якої рука «прилипає»). Без нього рукоятка пістолета опиниться по центру меша, а не там, де її тримають.

Для зброї та інструментів з дворучним захопленням — окрема система TwoHandGrab: ведуча рука визначає позицію, друга — орієнтацію. XR Interaction Toolkit підтримує це через XRTwoHandGrabInteractable або кастомну логіку з двома Attach Points.

Throw (кидок)

Чому velocity smoothing критичний для реалістичного кидка? Проблема в тому, що Rigidbody.velocity в момент відпускання контролера відображає миттєву швидкість, яка часто некоректна через дискретизацію трекінгу. Користувач робить швидкий рух зап'ястям — а об'єкт летить вдвічі повільніше.

Рішення: velocity smoothing за останні N кадрів (типово 5-10 кадрів, ~80-160 мс при 60 Гц) перед відпусканням. XR Interaction Toolkit робить це через VelocityEstimator. Додатково застосовуємо velocity scaling multiplier — невелике множення швидкості (1.2-1.5x) робить кидки суб'єктивно більш задовільними. Кутову швидкість (для об'єктів, які мають крутитися в польоті) також усереднюємо аналогічним чином.

AR: Plane Tracking та робота з оточенням

AR додає інший клас проблем — роботу з реальним, непередбачуваним оточенням. AR Foundation — кроссплатформенний шар поверх ARKit та ARCore. Більшість базових функцій (plane detection, raycasting, image tracking, face tracking) доступні через єдиний API.

Plane Detection

ARPlaneManager виявляє горизонтальні та вертикальні площини. Практичні нюанси:

• Ініціалізація займає час — користувач повинен оглянути приміщення, поки система будує карту. Потрібен явний onboarding з інструкцією «повільно водіть камерою по поверхнях».
• Площини нестабільні — їх межі та позиція оновлюються в міру накопичення даних. Об'єкти, розміщені на площині, потрібно прив'язувати через parenting до ARPlane, а не до світових координат.
• Злиття площин — два виявлені сегменти підлоги можуть злитися в один, що рухає якір. Для критичних якорів використовуємо ARAnchor замість прямої прив'язки до площини.

Оптимізація для VR: фреймрейт та комфорт

VR вимагає стабільного високого фреймрейту. Близько 60% часу розробки в мобільному VR йде на оптимізацію, а не на функціонал — ретрофіт у два рази дорожче правильної архітектури з першого спринту.

Single Pass Instanced Rendering

Головна оптимізація рендеру у VR. Без неї сцена рендериться двічі (для кожного ока), що подвоює draw calls. Single Pass Instanced рендерить обидва ока за один прохід через instancing: geometry обробляється один раз, шейдер отримує два view/projection matrix через GPU instancing. Вмикається в Unity через XR Plug-in Management > Rendering Mode: Single Pass Instanced. Важно: кастомні шейдери повинні підтримувати SPI — стандартні URP/HDRP шейдери підтримують, кастомні HLSL вимагають правки (UNITY_SETUP_STEREO_EYE_INDEX_POST_VERTEX та пов'язані макроси). Застосування цієї техніки скорочує кількість draw calls на 40-50%.

Foveated Rendering

На Meta Quest доступний Fixed Foveated Rendering (FFR) — зниження роздільної здатності на периферії кадру, де гострота сприйняття нижча. Налаштовується через OVRManager або Meta XR SDK:

OVRManager.fixedFoveatedRenderingLevel = OVRManager.FixedFoveatedRenderingLevel.High;
OVRManager.useDynamicFixedFoveatedRendering = true;

Dynamic FFR автоматично підвищує рівень при просадці фреймрейту — зручніше фіксованого в сценах зі змінним навантаженням.

IPD та Comfort Settings

IPD (Inter-Pupillary Distance) — відстань між зіницями, впливає на сприйняття глибини. На програмованому рівні в більшості пристроїв доступне лише читання IPD (OVRPlugin.GetSystemDisplayFrequency), фізичне налаштування — на гарнітурі. Для додатків з точним позиціонуванням (медичні симулятори, тренінги) враховуємо IPD у розрахунках масштабу сцени.

Haptics

Тактильний фідбек — недооцінений інструмент. Навіть простий вібраційний відгук при захопленні об'єкта або попаданні значно підвищує відчуття присутності. В середньому інтеграція тактильних патернів займає 30–80 годин на проєкт.

XR Haptics через OpenXR:

var hapticImpulse = new UnityEngine.XR.HapticCapabilities();
InputDevice device = InputDevices.GetDeviceAtXRNode(XRNode.RightHand);
device.SendHapticImpulse(0, amplitude: 0.5f, duration: 0.1f);

Для складних патернів (тактильна «текстура» поверхні при дотику, наростаюча вібрація при натягу тятиви лука) використовуємо Meta Haptics Studio — дозволяє дизайнити haptic-кліпи візуально.

Що входить у розробку VR/AR-додатку

При замовленні проєкту під ключ ми надаємо:

• Архітектурний документ з описом стеку, логіки рендеру та системи взаємодії
• Робочий прототип (MVP) для тестування на цільовому пристрої
• Інтеграцію необхідних SDK (Meta XR, OpenXR, AR Foundation та ін.)
• Оптимізацію під цільові частоти 72/90/120 Гц з профілюванням draw calls та FPS
• Тестування на фізичному обладнанні (Quest, SteamVR, HoloLens) із залученням користувачів
• Повну документацію по збірці, деплою та підтримці
• Навчання команди замовника (воркшоп по роботі з XR Toolkit)
• Гарантійну підтримку протягом 1 місяця після здачі

Що впливає на вартість та терміни

VR/AR проєкти дорожчі за звичайні ігри аналогічного обсягу. Ітерації повільніші — кожну правку потрібно тестувати в гарнітурі, емулятор не передає реальний досвід. Motion sickness змушує переробляти частину концептуальних рішень після першого плейтесту. Оптимізація займає суттєву частку часу — для мобільного VR (Quest) до 60-70% циклу. Для проєктів під Quest починаємо оптимізацію з першого спринту.

Отримайте консультацію по вашому проєкту — оцінимо задачу, стек та терміни. Замовте розробку VR/AR-додатку під ключ з гарантією стабільного фреймрейту.