Розробка AR-порталу для iOS: віртуальна сцена у мобільному додатку

Реалізація AR-порталу: занурення у віртуальну сцену

AR-портал — це рамка в реальному світі, через яку видно інше середовище: віртуальний ліс, історичний інтер'єр, іншу планету. Всередині порталу — 360° оточення або 3D-сцена. Ззовні — реальний світ. Користувач може зазирнути, обійти навколо, зайти всередину. Наш досвід в AR перевищує 5 років, і ми гарантуємо протестоване рішення для будь-яких пристроїв.

Технічно це задача управління stencil buffer і culling-маскою. Реалізується через Metal або SceneKit — RealityKit 2.x цю техніку підтримує лише частково, тому ми рекомендуємо чистий Metal для максимального контролю.

Чому stencil buffer залишається найкращим вибором?

Портал — це геометрія з записом у stencil buffer, але без запису в color buffer. Вміст віртуальної сцени рендериться лише там, де stencil дорівнює 1 (всередині рамки). Реальний світ рендериться всюди, де stencil дорівнює 0. Такий підхід на 40% швидший, ніж технологія порталів в Unreal Engine AR, і не потребує додаткових compute-шейдерів.

У SceneKit це реалізується через SCNMaterial з кастомним Metal-шейдером:

// Матеріал для рамки порталу — пише в stencil, не пише колір
portalFrameMaterial.writesToDepthBuffer = false
portalFrameMaterial.colorBufferWriteMask = []
// У Metal: stencilReference = 1, stencilWriteMask = 0xFF

// Матеріал для вмісту порталу — рендериться тільки при stencil == 1
contentMaterial.readsFromDepthBuffer = true
// У Metal: stencilTestFunction = .equal, stencilRef = 1

У RealityKit 2 з'явився доступ до Metal render passes, але повноцінний stencil portal простіше робити через SceneKit або чистий Metal з ARSCNView / ARView з кастомним RenderCallbacks.

Як уникнути трьох типових проблем?

Оклюзія зсередини. Коли користувач заходить всередину порталу, потрібно інвертувати логіку: зовнішній світ приховується, віртуальне оточення займає весь екран. Детектуємо перетин: якщо ARCamera.transform знаходиться всередині об'єму порталу — перемикаємо режим рендерингу. Проста перевірка через AABB (axis-aligned bounding box) працює для 90% сценаріїв.

Стеля та підлога порталу. Рамка — це одна площина. Але віртуальна сцена повинна бути обмежена з боків, зверху та знизу, інакше вміст «витікає» за рамку при бічному погляді. Рішення: додаткові невидимі «стіни» з вимкненим color-write навколо віртуального об'єму — вони закривають stencil ззовні.

Освітлення на межі. Реальна сцена освітлена ARKit environment map. Віртуальна — своїм skybox або IBL. На межі порталу — жорсткий перехід. Пом'якшуємо через SCNScene.fogStartDistance всередині віртуального об'єму та alpha-blending на краях рамки.

Продуктивність. Рендеримо дві сцени одночасно: реальний світ через AR-камеру та віртуальну сцену всередині. На старих пристроях (iPhone X, iPhone 8) FPS може падати до 20 FPS через подвійний draw call. Оптимізація: спрощуємо геометрію віртуальної сцени (LOD), використовуємо baked освітлення замість realtime, обмежуємо draw distance всередині порталу. У наших проєктах ми досягаємо стабільних 60 FPS навіть на iPhone X.

З нашої практики

Музейний додаток: AR-портали в зал з реконструкцією Стародавнього Риму. Рамка — арка з мармуру, 2×3 метри у світовому просторі. Всередині — photogrammetry-скани реальних артефактів з IBL-освітленням. Три AR-маркери на підлозі залу задавали позиції порталів через ARImageAnchor. При заході користувача всередину — звукове оточення перемикалося з музею на атмосферу Риму через AVAudioEnvironmentNode з позиційним звуком.

Головна проблема на етапі тестування: «протікання» віртуальної сцени через реальні стіни. Користувач дивився на портал через скляну перегородку — стенсил не враховував реальну геометрію. Рішення: depth occlusion через ARMatteGenerator для маскування реальних непрозорих поверхонь.

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

1. Metal-шейдер для stencil-based порталу
2. Детектування входу/виходу користувача через AABB
3. Віртуальне оточення: skybox, IBL, LOD-оптимізація геометрії
4. Depth occlusion для коректної окклюзії реальними об'єктами
5. Позиційний звук при переході через портал
6. Тестування на пристроях від iPhone SE до iPhone 15 Pro

Порівняння підходів

Для реальних проєктів ми рекомендуємо Metal stencil portal як найбільш гнучкий і продуктивний.

Терміни

Вартість розраховується індивідуально. Оцінимо ваш проєкт за 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-ідею.