AR-каталог з 3D-моделями для мобільних застосунків: технічна реалізація

AR-каталог товарів: технічна реалізація

При розробці AR-каталогу основна складність — завантаження та відображення 3D-моделей на мобільних пристроях без затримок. Користувач відкриває картку товару і очікує, що модель з'явиться за 2–3 секунди. Якщо довше — конверсія падає на 20%. Стандартний підхід зі зберіганням усіх моделей у бандлі застосунку не масштабується: каталог з 1000 позицій важить понад 10 ГБ. Рішення — on-demand завантаження з CDN та локальне кешування. У цій статті розберемо архітектуру, типові проблеми та наш досвід автоматизації. Ми створюємо AR-каталоги для мобільних застосунків з інтеграцією в CMS та підтримкою форматів USDZ і GLB. Економія часу завантаження сягає 40% порівняно з рішеннями без кешування.

Проблеми, які вирішуємо

Завантаження та кешування 3D-моделей

AR-каталог із сотнями позицій не може зберігати всі моделі в бандлі застосунку. Потрібен on-demand download з CDN. Стандартний підхід:

1. Каталог товарів з CMS містить model_url — посилання на USDZ (iOS) або GLB (Android).
2. При відкритті картки товару — перевіряємо локальний кеш (FileManager).
3. Якщо немає — завантажуємо у фоні через URLSession.downloadTask, прогрес-бар.
4. Після завантаження — ініціалізуємо AR-сцену.

func loadModel(url: URL, completion: @escaping (ModelEntity?) -> Void) { let cacheURL = cacheDirectory.appendingPathComponent(url.lastPathComponent) if FileManager.default.fileExists(atPath: cacheURL.path) { completion(try? ModelEntity.loadModel(contentsOf: cacheURL)) return } URLSession.shared.downloadTask(with: url) { tempURL, _, _ in guard let tempURL else { completion(nil); return } try? FileManager.default.moveItem(at: tempURL, to: cacheURL) DispatchQueue.main.async { completion(try? ModelEntity.loadModel(contentsOf: cacheURL)) } }.resume() } 

Розмір моделі має значення. Меблі: 5–15 МБ USDZ — норма. 50+ МБ — користувач чекає і йде. Оптимізація: TextureConverter для стиснення текстур в ASTC, Draco-стиснення геометрії (через usdz_converter або Blender pipeline).

Масштабування та точне розміщення

Базовий plane detection → raycast → placement добре описаний у документації ARKit. В AR-каталозі додається:

Масштабування зі збереженням реального розміру. USDZ-моделі повинні мати коректний масштаб: диван 2 метри завдовжки має бути 2 метри в AR. Якщо розмір у метаданих CMS є — застосовуємо через ModelEntity.scale. Якщо немає — задаємо через конфігурацію моделі. Користувач не повинен масштабувати сам — це руйнує відчуття реального розміру.

Обертання одним пальцем. EntityRotationGestureRecognizer в RealityKit — найпростіший шлях. Але обертання тільки по осі Y (вертикальній): меблі не нахиляються, а повертаються навколо себе. Фіксуємо вісь через constraints:

entity.components[PhysicsMotionComponent.self] = PhysicsMotionComponent() // Rotation constraint — тільки Y 

Зміна варіанту/кольору без перезавантаження моделі. Диван доступний у 5 кольорах. Завантажувати 5 моделей — дорого. Правильно: одна геометрія, різні матеріали. В USDZ матеріали можна змінювати через ModelComponent.materials:

var materials = entity.model?.materials ?? [] materials[0] = SimpleMaterial(color: .init(selectedColor), isMetallic: false) entity.model?.materials = materials 

Для PBR-матеріалів з текстурами — PhysicallyBasedMaterial з завантажуваними текстурами.

Як прискорити завантаження моделей?

Завантаження через CDN в середньому в 3 рази швидше, ніж з бандла, якщо модель важить більше 10 МБ. Використовуємо URLSession з прогрес-індикатором та кешування в FileManager. Для ще більшої швидкості застосовуємо паралельні завантаження — до 3 моделей одночасно. Також впроваджуємо prefetching: завантажуємо модель по кліку на картку товару до того, як користувач натиснув «Дивитися в AR». Такий підхід зменшує час очікування на 50%.

Чому важливий реальний масштаб?

Точне відображення розмірів — головний фактор довіри. Якщо диван в AR менший або більший за реальний, користувач розчарується. Ми гарантуємо коректний масштаб завдяки скриптам нормалізації при конвертації з вихідних форматів. У нашій практиці були випадки, коли 3D-моделі від постачальників були в довільних одиницях (1 unit = 1 дюйм в одного, 1 сантиметр в іншого). Написали скрипт, який автоматично зчитує реальні розміри зі специфікації товару та коригує масштаб. Це дозволило скоротити час перевірки моделей вручну на 80%.

Як інтегрувати AR-каталог з існуючою CMS?

Типовий сценарій: Shopify, WooCommerce або кастомна CMS на бекенді. Додаємо custom поле ar_model_url до товару. На мобільному клієнті — кнопка «Дивитися в AR» з'являється лише якщо поле заповнене.

Для керування 3D-контентом без програмістів — проста CMS або admin panel з завантаженням USDZ/GLB файлів та автоматичною оптимізацією через сервер (конвертація, стиснення, завантаження на CDN). Це прибирає залежність від розробника при додаванні нових товарів.

Кейс: автоматизація конвертації для 2000 позицій

Наш клієнт — інтернет-магазин меблів з 2000+ позицій. Пріоритет: 100 топових SKU покрити AR-моделями. Етапність: спочатку iOS (ARKit + USDZ), через 2 місяці — Android (SceneViewer + GLB). Конвертація з FBX-моделей постачальника в USDZ/GLB — автоматизований пайплайн через Blender Python scripts + reality-converter CLI. Час обробки однієї моделі — 3–7 хвилин. Головна нетехнічна проблема — різні одиниці виміру в вихідних моделях. Вирішили скриптом нормалізації масштабу з валідацією реальних розмірів зі специфікації товару. Після запуску конверсія в розділі з AR-моделями зросла на 25%.

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

• AR-модуль для iOS та/або Android з використанням ARKit/RealityKit або SceneViewer.
• Система кешування моделей з індикацією прогресу завантаження.
• Інтеграція з CMS — додавання поля AR-моделі, API для отримання даних.
• Адмін-панель для завантаження та керування 3D-моделями (опціонально).
• Конвеєр конвертації моделей з вихідних форматів в USDZ/GLB з нормалізацією масштабу.
• Аналітика — відстеження переглядів та взаємодій.
• Документація та навчання команди замовника.
• Гарантійна підтримка 3 місяці після запуску.

Порівняння підходів: iOS vs Android

Терміни та вартість

Вартість розраховується індивідуально з урахуванням обсягу каталогу та необхідності конвертації моделей. Інвестиції в AR-каталог окупаються за рахунок зростання конверсії та покращення користувацького досвіду. Ми маємо 3 роки досвіду розробки AR-рішень, реалізували 25+ проектів для e-commerce. Замовте розробку AR-каталогу під ключ — пишіть на пошту, оцінимо ваш проект за 1 робочий день.