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

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

Розробка AR-додатків рідко ламається на демо і майже завжди — на реальному об'єкті. У демонстрації рівний стіл, добре світло й повільний рух камери, тому все тримається.

У полі сцена поводиться інакше: втрата трекінгу сцени трапляється на однотонній стіні, при різкому повороті пристрою або в приміщенні з відблисками й дзеркальними поверхнями.

Камера перестає розпізнавати оточення, система координат збирається заново — і об'єкт, який щойно стояв на столі, від'їжджає від поверхні на сантиметри, а іноді й на метри.

Другий клас збоїв — дрейф 3D-об'єктів. Прив'язка до якоря без регулярної звірки з розпізнаною геометрією накопичує помилку: об'єкт повільно «пливе» вздовж площини, змінює масштаб і нахил.

На короткому сеансі це непомітно, на довгому — розходження стає очевидним, і жодна акуратна 3D-модель це не компенсує. Причина майже завжди в архітектурі сцени, а не в контенті: якір виставлений один раз і більше не перевіряється.

Третій — перегрів пристрою. Камера, рендеринг і розпізнавання працюють одночасно й безперервно, тепловий бюджет середнього апарата закінчується швидше, ніж здається. Система спочатку знижує частоту кадрів, картинка починає відставати від руху руки, а потім додаток закривається.

На флагманських пристроях проблема замаскована, тому її легко пропустити на етапі тестів і отримати на парку звичайних телефонів.

Усі три збої лежать в одній площині — у тому, як влаштований цикл сесії, вибір якорів і бюджет навантаження на кадр. Далі розбираємо, як це закривається на рівні архітектури та профілю пристроїв, а не косметичними правками.

Що змінюється після впровадження: п'ять вимірюваних ефектів

Перший ефект — утримання віртуального об'єкта в кадрі. Раніше модель сповзала з точки прив'язки при повороті камери: якір губився, і об'єкт доводилося ставити заново.

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

Другий — стабільність трекінгу в реальних умовах: слабке освітлення, однотонні поверхні, різкі повороти пристрою. Запас за цими сценаріями закладається на прототипі, тому у звіті видно не усереднену цифру, а частку сесій, де трекінг не втрачався жодного разу і об'єкт не «з'їхав».

Третій і четвертий — час холодного запуску AR-режиму та відгук на дію користувача. Перший перехід у камеру вкладається в пару секунд, бо моделі й текстури довантажуються фоном і не блокують сцену.

Відгук на дотик — частки секунди: для примірки або наведення на об'єкт затримка читається як «зламалося», а не як «повільно».

П'ятий — частка пристроїв, де функція працює передбачувано: це парк, що пройшов перевірку на живій збірці, а не список з документації.

Тут же закривається цілий клас відмов — розсинхрон положення камери та віртуальної сцени, через який додаток показує об'єкт повз ціль або йде в темний екран.

Варіанти реалізації: нативний модуль, рушій або веб

Три підходи відрізняються не якістю картинки, а тим, куди вбудовується доповнена реальність і яку ціну ви платите на супроводі.

Нативний AR-модуль спирається на платформні набори — ARKit і ARCore: доступ до трекінгу площин, оцінки освітлення й камери повний, але логіка дублюється під кожну платформу.

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

Гібридну схему беруть, коли веб-сцена закриває швидкий вхід, а нативний модуль бере на себе важкі сцени всередині додатка. Такий варіант дорожчий у підтримці, тому межу між гілками ми фіксуємо до старту розробки — інакше розходження поведінки спливає вже в користувачів.

Етапи роботи: від постановки задачі до передачі

Етапи впровадження AR будуємо так, щоб технічні ризики знімалися раніше, ніж у проєкт піде основна частина роботи: найдорожче — помилка в схемі сцени, виявлена на фінальній збірці. Тому перші кроки — про сценарій і геометрію, а не про код.

1. Розбір сценарію. Фіксуємо, куди дивиться камера, що користувач робить руками і яку дію вважаємо успіхом. На виході — вимірюваний критерій приймання, а не «має виглядати ефектно».
2. Схема сцени. Розкладаємо якорі, опорні площини, зони взаємодії та масштаб об'єктів щодо зросту людини. Схема сцени стає спільним документом для дизайну, розробки й приймання.
3. Прототип AR-функції. Збираємо мінімальну версію на одній моделі пристрою: перевіряємо, що сценарій відтворюється в реальному приміщенні, а не лише на тестовій розмітці.
4. Трекінг і оклюзія. Налаштовуємо розпізнавання поверхонь, перекриття віртуальних об'єктів реальними та поведінку сцени при втраті трекінгу — це визначає, чи «тримається» картинка при русі й слабкому світлі.
5. Перевірка на парку пристроїв. Прогоняємо збірку на різних поколіннях камер і різній продуктивності (ARKit і ARCore поводяться в одному й тому самому приміщенні по-різному). Фіксуємо, де просідає стійкість.
6. Приймання. Проходимо чек-ліст за сценаріями й пристроями, звіряємо з критеріями з першого кроку, оформлюємо протокол із відомими обмеженнями.
7. Передача. Віддаємо вихідники, схему сцени, політику оновлень та інструкцію з додавання нових моделей — команда замовника може розвивати AR-блок без нас.

Що передаємо на руки: збірка, схеми, регламенти

Передача — це не архів з вихідниками, а набір артефактів, за якими ваша команда або наші інженери підтримки відтворюють збірку, правлять сцену й оновлюють контент без розбору чужого коду. Нижче — що входить до комплекту за AR-модулем.

• Робоча збірка — зібрані варіанти додатка під цільові платформи, конфігурація середовища та скрипти, якими збірка повторюється з нуля на чистій машині.
• Схема сцени — ієрархія вузлів, прив'язка якорів і точок розміщення, логіка розпізнавання площин і поведінка об'єктів при втраті трекінгу.
• Правила доступу до контенту — ролі й права: хто публікує та знімає моделі, де лежать вихідники, як влаштовані версіонування й відкат публікації.
• Документація з AR-модуля — точки розширення, контракти між шарами, залежності платформних компонентів і порядок їх оновлення.
• Регламент оновлення моделей — вимоги до форматів і оптимізації, перевірки перед публікацією, порядок заміни контенту без перезбирання додатка.
• Інструкція для підтримки — типові відмови, на що дивитися в журналах, як відкотити додаток і повернути попередню версію сцени.
• Матриця доступів — де зберігаються ключі підпису й акаунти публікації, хто власник, як вони передаються при зміні підрядника.

Комплект оновлюється при кожній зміні модуля: якщо правка не відображена в схемі сцени або регламенті, передача вважається неповною.

Кейс: примірочна в додатку — що було до і після

У додатку мережі одягу Модний дім примірка була окремим екраном, до якого доходив один покупець із семи. Сцена з речами відкривалася 4–5 секунд, модель «плавала» відносно тіла, а при повороті камери обривалася; у торговій залі при слабкому світлі трекінг губився майже одразу.

За логами: 62% сесій примірки закінчувалися помилкою, середня тривалість — 8 секунд, додавань до кошика з примірочної майже не було.

Що перебудували в сцені та трекінгу

Речі перезібрали під мобільний вивід: спрощена геометрія та заздалегідь підготовлені текстури замість важких вихідних моделей — вага сцени впала в рази, перший кадр з'являється помітно раніше.

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

Поріг освітленості виставили за вимірами в реальних залах: замість повідомлення про помилку додаток підказує, куди стати. Це прибрало найчастіший сценарій відмови — покупець не кидав примірку, а доводив її до кінця.

Метрики до і після

Частка успішних сесій примірки — з 38% до 94%. Час до першого кадру — з 4–5 секунд до 1,5.

Середня тривалість примірки зросла з 8 секунд до півтори хвилини, частка додавань до кошика після примірки — втричі, а повернення з причиною «не підійшло за посадкою» знизилися приблизно на чверть.

Чим AR-примірка відрізняється від 3D-прев'ю на сайті

3D-прев'ю живе всередині екрана: модель обертається на нейтральному фоні, а масштаб користувач добудовує сам — чи стане предмет поруч із диваном, чи підійде за висотою до полиці.

AR-примірка це припущення знімає: камера показує приміщення, додаток розпізнає площину й ставить об'єкт туди в реальних пропорціях.

Технічно різниця — у прив'язці до поверхні. Додаток визначає площину, відстежує положення пристрою в просторі, підлаштовує масштаб і враховує освітлення, тому об'єкт не плаває й не провалюється, а тінь лягає під ніжки. Це й відповідає на питання «а чи влізе», на яке обертова модель відповісти не може.

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

Меблі, великогабаритна техніка, декор і все, що приміряється «на собі», потребують прив'язки до поверхні: там вирішує габарит.

Поведінка користувача відрізняється. Прев'ю збільшує глибину перегляду й кількість порівнянь, AR-примірка — частку тих, хто дійшов до замовлення, і знижує повернення «не підійшло за розміром».

Плата — зайві кроки: дозвіл на камеру, наведення на поверхню, очікування розпізнавання, і частина аудиторії на них відсіюється.

Тому ми не ставимо вибір «або». У типовому сценарії прев'ю закриває вхід до каталогу, а AR-примірка — етап рішення за позиціями, де важливий габарит; розподіл задається за категоріями, і вже від нього рахується решта архітектури додатка.

Технічні сумніви: пристрої, світло, точність

Обмеження сцени задає не код, а зв'язка камери, інерційних датчиків і платформних бібліотек. Нижче — чотири питання, які найчастіше спливають на прийманні, і те, як ми закриваємо кожне.

Що відбувається при слабкому освітленні?

Камера не знаходить характерні точки: сцена «пливе», об'єкти тремтять і зміщуються. Ми виводимо індикатор якості трекінгу, просимо додати світла й переводимо об'єкт у режим прив'язки до площини замість покадрового суміщення. Нижче порога освітленості показуємо зрозуміле повідомлення, а не артефакти.

Наскільки точні вимірювання в сцені?

Похибка залежить від дистанції та текстури поверхні: поблизу за розміченою площиною це одиниці сантиметрів, на дальніх і однотонних ділянках зростає.

Там, де точність критична, ми обмежуємо робочу зону й вводимо еталонну мітку відомого розміру — так помилка не накопичується під час обходу.

Чи працює сцена без мережі?

Розпізнавання й трекінг рахуються на пристрої, тому в офлайні сцена запускається й тримається. Мережа потрібна для контенту й аналітики: матеріали пакуємо в локальний кеш, події накопичуємо й надсилаємо пачкою при появі зв'язку. Важкий контент довантажується фоном у зоні Wi-Fi, щоб у полі користувач не чекав завантаження.

Обговоримо задачу й повернемося з оцінкою та планом робіт

Щоб оцінка AR-проєкту була предметною, а не «на око», нам потрібні ввідні щодо задачі: що розпізнаємо, за яких умов це має працювати й на яких пристроях.

Доповнена реальність чутлива до сценарію — трекінг за маркером, за площиною та за координатами дає різну трудомісткість і різні вимоги до контенту, який доведеться готувати.

Що надіслати для старту:

• опис сценарію: що користувач бачить у камері й що відбувається після розпізнавання;
• список пристроїв і мінімальні версії мобільних систем, які потрібно підтримати;
• матеріали — моделі, фото, відео, креслення; якщо їх немає, так і напишіть, джерела контенту обговоримо окремо;
• 2-3 додатки-референси й пояснення, що саме в них подобається з погляду поведінки;
• обмеження: дата події або запуску, вимоги щодо доступів до даних, наявна інфраструктура;
• чи є готовий додаток, у який AR вбудовується, чи збірка йде з нуля.

Окремо уточнимо те, що зазвичай спливає вже в роботі: як поводиться сцена при слабкому освітленні, чи потрібна робота без мережі, що відбувається при втраті трекінгу й як додаток поверне користувача в сцену.

У відповідь повернемося з планом робіт: склад команди з ролями, етапи та їхня тривалість, що робимо на кожному етапі й у який момент ви приймаєте результат. Окремим пунктом — ризики сценарію та запас на них. Опишіть задачу у вільній формі — далі розберемося по ходу діалогу.