Чому AR-прев'ю NFT ламається в мобільному застосунку
AR-прев'ю NFT — найцінніший за враженням екран застосунку: користувач уже відкрив картку, навів камеру — і побачив сірий квадрат замість арту.
Перший збій майже завжди на боці вітрини: токен є, а метадані посилаються на файл, який віддається то із затримкою, то з помилкою, і застосунок не вміє відкотитися до статичного прев'ю.
Завантаження 3D-моделі додає другу проблему. Вихідники збирають під настільний перегляд: важкі текстури, десятки тисяч полігонів, жодного рівня деталізації. На мобільному з'єднанні така сцена йде 6–10 секунд, і користувач іде раніше, ніж побачить арт.
Доповнена реальність у застосунку ламається на прив'язці до поверхні. Пристрої по-різному розпізнають площину, по-різному тримають масштаб і тіні, тому та сама модель на різних телефонах опиняється то в повітрі, то всередині столу.
Помилки прив'язки до поверхні користувач читає як брак продукту, хоч це різниця в калібруванні камер і в наборі датчиків.
Продуктивність мобільного застосунку страждає останньою в ланцюжку: режим перегляду тягне за собою всю сцену, декодування та решту логіки екрана — застосунок гріється, губить кадри і закривається системою. Розбираємо, як це закривається.
Що дає прев'ю в доповненій реальності: ефект у цифрах
Прев'ю в доповненій реальності змінює механіку картки: замість статичного зображення користувач отримує об'єкт, який можна обійти й роздивитися у себе в кімнаті. Час до першого кадру ми тримаємо в межах часток секунди — модель показується прогресивно, поки довантажуються деталі.
Конверсія картки зростає з зрозумілої причини: рішення ухвалюється на місці, без питання «а як це буде в мене». Частка переходів у перегляд і далі — у покупку або підписку — збільшується, бо ключовий сумнів знімається за пару секунд.
Залученість користувачів теж вимірювана. Сесія перегляду довша, ніж у статичної картки: об'єкт обертають, наближають, роблять знімки й повертаються до них пізніше — повторні відкриття йдуть без додаткового трафіку.
Стійкість до слабких пристроїв закладена в архітектуру: ми готуємо кілька рівнів деталізації моделі й перемикаємо їх за можливостями конкретного телефона. Частка успішних сесій перегляду на бюджетних моделях відрізняється від флагманів у межах похибки, а не в рази.
Заодно зникає цілий клас відмов під час завантаження моделі: обірваний потік даних, застаріле посилання на файл, несумісний формат більше не перетворюються на чорний екран.
Застосунок перевіряє модель заздалегідь і або показує прев'ю, або пропонує статичну версію — без глухого кута для користувача.
Формати перегляду: порівняння режимів та їхніх обмежень
Формат перегляду визначає, де вважається кадр — на пристрої гостя чи на нашому боці, — і що саме людина бачить на екрані. Від цього залежать точність посадки об'єкта на поверхню, поведінка тіней і те, на якому парку пристроїв сцена запуститься без сюрпризів.
Чотири режими нижче відрізняються не якістю картинки, а тим, що ми можемо гарантувати: глибину сцени, відгук на рух, охоплення підтримки пристроїв.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Нативний модуль | Основний сценарій у застосунку: стабільний трекінг, робота з датчиками, повноекранна сцена | Потрібне встановлення й оновлення через магазин застосунків, зростає розмір збірки |
| Вебперегляд за посиланням | Разові покази, лендінги, запуск із чужого пристрою за пару секунд | Усе вирішує браузер: частина датчиків недоступна, посадка об'єкта менш стійка |
| Хмарний рендеринг (потокова передача кадру) | Важкі сцени з відбиттями та складним світлом, слабкий пристрій на руках | Чутливий до каналу зв'язку, відгук на обертання з'являється із затримкою |
| Перегляд без камери | Пристрої без підтримки доповненої реальності, десктоп, шеринг у месенджері | Немає прив'язки до реальної кімнати, сцена подається як об'ємна модель |
Режими не виключають одне одного: нативний модуль закриває основний шлях, вебперегляд страхує старі моделі та вхід за посиланням. Перед запуском ми заміряємо час старту сцени й частку пристроїв, де режим відпрацював без збоїв, і лише потім фіксуємо матрицю підтримки.
Порядок впровадження: від розбору моделей до передачі
Етапи впровадження вибудовуємо так, щоб кожен крок спирався на перевірений попередній, а не на припущення. Спочатку розбираємо, що вже є на боці замовника, і лише потім проєктуємо сцену й пишемо код — інакше переробка коштує дорожче, ніж аудит.
- Аудит моделей і метаданих. Дивимося полігонаж, текстури, одиниці масштабу, відповідність моделі токену. Частина колекції йде на оптимізацію, частину відсіюємо відразу.
- Схема сцени. Фіксуємо масштаб, точку появи предмета, освітлення, фон і поведінку при обертанні — це контракт між дизайном і розробкою.
- Збірка модуля прев'ю. Перегляд, завантаження за ідентифікатором токена, кеш моделей і стани «завантажується / не вдалося» — окремо від логіки самого застосунку.
- Перевірка на пристроях. Проганяємо на слабких і сильних апаратах, різних діагоналях і версіях системи: стабільність кадрів, споживання пам'яті, поведінка при нагріванні та зміні мережі.
- Відмови та граничні ситуації. Недоступний шлюз, пошкоджена модель, відмова в доступі до камери — у кожного випадку свій екран і зрозуміла дія для користувача.
- Документація. Вимоги до моделей, схема сцени та інструкція з підключення нової колекції силами команди замовника.
- Передача рішення. Розбір з інженерами замовника, доступи, навчання та узгоджений період супроводу після релізу.
Що залишається у вас після здачі: конфігурації та документація
Після здачі залишається не лише зібраний застосунок, а й усе, що потрібно, щоб AR-прев'ю NFT жило без нас. Передаємо сцени, моделі, схеми обміну даними з блокчейн-шаром і правила, за якими команда додає нові предмети. Без цього перший же новий токен — розбір чужого коду навмання.
- Моделі та матеріали. Предмети під мобільний рендеринг: розумна щільність сітки, запечені текстури, чисті матеріали — прев'ю відкривається на середньому пристрої без просідань.
- Конфігурація сцени. Освітлення, оточення, масштаб і точки прив'язки до площини задані файлами: новий предмет стає в кадр передбачувано, без підгонки під кожну модель телефона.
- Документація з інтеграції. Схема обміну з блокчейн-шаром: як отримуємо метадані токена, де і як довго кешуємо медіа, що показуємо при недоступності вузла.
- Доступи до сховища. Ключі до репозиторію моделей і роздачі контенту заведені на ваші акаунти, права на публікацію відокремлені від прав на правку.
- Інструкції для команди. Порядок додавання нового предмета та чек-лист приймання: що перевірити на пристрої до випуску, які параметри вважаються браком.
- Регламент оновлення. Версіонування моделей і сцен, вікно сумісності зі старими версіями застосунку та порядок відкату, якщо оновлення погіршило кадр.
Артефакти лежать у вашому репозиторії й розраховані на інженера, який відкриє їх за пів року без автора поруч.
Кейс: як прискорили відкриття моделі на слабких смартфонах
AR-прев'ю — той самий сценарій, що в маркетплейсів на кшталт OpenSea: покупець у картці лота наводить камеру й бачить об'єкт в інтер'єрі, не виходячи із застосунку.
На пристроях початкового рівня сценарій розвалювався: модель або не відкривалася, або з'являлася так пізно, що користувач встигав закрити картку.
У цьому кейсі мобільного застосунку ми перезібрали підготовку та завантаження асета й заміряли результат на одній і тій самій вибірці сесій.
| Метрика | До | Після |
|---|---|---|
| Час до першого кадру | 6–8 с | 1,5–2 с |
| Успішні перегляди на пристроях початкового рівня | 62% | 96% |
| Вага завантажуваних матеріалів | 1× | у 3,5 раза менше |
| Сесії, перервані на відкритті моделі | 24% | 4% |
Що саме змінили в завантаженні
Відмовилися від очікування повної моделі: першою приходить полегшена копія геометрії та текстури зниженої якості, а повний набір підтягується у фоні вже під час перегляду.
Кеш на пристрої тримає останні відкриті об'єкти, тому повторний вхід у картку майже миттєвий, а розпакування не блокує інтерфейс.
Навантаження на пристрій обмежили бюджетом: кількість джерел світла, частота оновлення сцени та роздільна здатність тіней задаються політикою під клас пристрою, а не єдиними налаштуваннями для всіх.
Це прибрало клас відмов, за якого застосунок закривався через пам'ять: такі збої приходили пачками саме з бюджетних моделей — тепер вони поодинокі й прив'язані до конкретних пристроїв, а не до сценарію перегляду загалом.
Чим відрізняється перегляд моделі від накладання на камеру?
Це два різні режими з різними вимогами до даних моделі. У 3D-перегляді камера облітає об'єкт на нейтральному фоні: сцена повністю керована, прив'язка до поверхні не потрібна, а масштаб підбирається під екран.
У режимі накладання на камеру модель стає в реальну сцену, і всі параметри — від одиниць вимірювання до світла — перестають бути довільними.
Масштаб моделі в AR задається в реальних одиницях, а не «на смак». Якщо арт вивантажений без коректних одиниць, об'єкт або висить у повітрі, або йде під поверхню.
Ми калібруємо геометрію за еталоном — при перенесенні між пристроями розмір залишається однаковим, а не «приблизно схожим».
Точність прив'язки — окремий шар роботи. Площина визначається за текстурою та світлом, тому на однотонній стіні або глянцевому столі модель дрейфує й прослизає.
Допомагають якорі на стійких ознаках і згладжування траєкторії: тремтіння зникає, але з'являється інерція відгуку на рух.
Освітлення в сцені вирішує, чи повірить користувач картинці. У 3D-перегляді достатньо однієї студійної схеми, в AR потрібно оцінювати реальну освітленість і підлаштовувати джерела та тіні, інакше модель читається як наліпка на відео.
Для вітрини в маркетплейсах на кшталт OpenSea зазвичай достатньо 3D-перегляду: він передбачуваний і не залежить від камери. Накладання на камеру — окремий сценарій: приміряти арт до своєї стіни.
Тримаємо обидва на одному файлі моделі з різними профілями світла та масштабу, щоб не дублювати асети.
Часті технічні сумніви щодо інтеграції в застосунок
Перед стартом замовники перевіряють ті самі місця: скільки важить модель, що побачать власники старих телефонів, як оновлюється колекція після дропу і який обсяг правок чекає вже випущений застосунок. Відповіді фіксуємо в проєктному документі до початку робіт — щоб вони не спливли на прийманні.
Скільки важить модель і що із завантаженням?
Сцену збираємо під мобільний бюджет: обмежуємо полігонаж, стискаємо текстури, геометрію віддаємо в glTF. Модель арт-об'єкта залишається в межах одиниць мегабайт, відкривається за 1-2 секунди й далі береться з кешу.
Що побачать власники старих пристроїв?
Нижню межу підтримки визначаємо за парком телефонів, а не за останніми моделями. На слабкому залізі вмикаємо полегшену сцену та статичне прев'ю замість живого рендера, перевіряємо на реальних пристроях — емулятор просідань не показує.
Як оновлюються колекції після нового дропу?
Каталог і моделі вітрина отримує із сервера, тому новий випуск з'являється без публікації в сторах. Асети версіонуються: стара збірка працює зі своїм набором, нова підтягує свіжий.
Як прев'ю поводиться всередині вітрини?
Модель завантажується у фоні й не блокує прокручування — користувач гортає каталог, поки сцена готується. Там, де AR-режим недоступний, показуємо статичний рендер і перехід до сторінки володіння, щоб вітрина не виглядала порожньою.
Скільки правок потрібно в самому застосунку?
Інтеграція зводиться до екрана вітрини та точок переходу — переписувати основний код не потрібно. На актуальній гілці правки торкаються кількох екранів; на старій кодовій базі спочатку оновлюємо її, інакше зростає ризик помилок на пристрої.
Обговоримо задачу: оцінимо обсяг робіт і запропонуємо план
Опишіть задачу в тому вигляді, у якому вона є: сценарій використання, на яких платформах і моделях пристроїв має працювати AR-прев'ю, звідки підтягуються зображення та метадані токенів, чи потрібен офлайн-перегляд і що вже реалізовано в застосунку.
У відповідь ми надсилаємо не загальну презентацію, а розбір під ваш випадок: де достатньо готових модулів, а де потрібна власна логіка відображення та підготовки моделей.
- Оцінка задачі — які роботи входять в обсяг, що вже закрито вашою командою і що беремо на себе.
- Розбір варіантів — вбудований модуль доповненої реальності проти відображення через браузерний шар: чим відрізняються за якістю картинки, швидкістю запуску та трудомісткістю підтримки.
- План робіт за етапами та строками — від прототипу з однією моделлю до релізу, з контрольними точками й показом проміжного результату.
- Склад команди — хто саме веде проєкт: інженер мобільної розробки, фахівець із тривимірної графіки, тестувальник на реальних пристроях.
- Порядок передачі — що переходить вам: вихідний код, налаштування збірки, схема завантаження моделей і формат додавання нових токенів.
- Ризики та припущення — де можливі затримки: перевірка в магазинах застосунків, підготовка моделей на боці замовника.
Почніть з короткого опису — цього достатньо, щоб повернутися з оцінкою та запропонувати план. Якщо задача ще не сформована, розкладемо її на етапи разом.
