AR-каталог товаров: техническая реализация
При разработке AR-каталога основная сложность — загрузка и отображение 3D-моделей на мобильных устройствах без задержек. Пользователь открывает карточку товара и ожидает, что модель появится за 2–3 секунды. Если дольше — конверсия падает на 20%. Стандартный подход с хранением всех моделей в бандле приложения не масштабируется: каталог из 1000 позиций весит более 10 ГБ. Решение — on-demand загрузка с CDN и локальное кэширование. В этой статье разберём архитектуру, типичные проблемы и наш опыт автоматизации. Мы создаём AR-каталоги для мобильных приложений с интеграцией в CMS и поддержкой форматов USDZ и GLB. Экономия времени загрузки достигает 40% по сравнению с решениями без кэширования.
Проблемы, которые решаем
Загрузка и кэширование 3D-моделей
AR-каталог с сотнями позиций не может хранить все модели в бандле приложения. Нужен on-demand download с CDN. Стандартный подход:
- Каталог товаров из CMS содержит
model_url— ссылку на USDZ (iOS) или GLB (Android). - При открытии карточки товара — проверяем локальный кэш (
FileManager). - Если нет — скачиваем в фоне через
URLSession.downloadTask, прогресс-бар. - После загрузки — инициализируем 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
| Критерий | iOS (ARKit + RealityKit) | Android (SceneViewer + ARCore) |
|---|---|---|
| Формат модели | USDZ | GLB |
| Простота реализации | Высокая (родные SDK) | Средняя (зависит от версии Google Play Services for AR) |
| Доступные жесты | Встроенные распознаватели | Через Sceneform / SceneView |
| Производительность | Отличная на устройствах с A12+ | Хорошая на устройствах с ARCore-сертификацией |
Сроки и стоимость
| Функциональность | Сроки |
|---|---|
| Базовый AR-viewer для одного товара | 1–2 недели |
| AR-каталог с кэшированием и вариантами цветов | 4–6 недель |
| Полная система с CMS, аналитикой и iOS+Android | 3–5 месяцев |
Стоимость рассчитывается индивидуально с учётом объёма каталога и необходимости конвертации моделей. Инвестиции в AR-каталог окупаются за счёт роста конверсии и улучшения пользовательского опыта. Свяжитесь с нами для консультации и предварительной оценки. Закажите разработку AR-каталога — получите решение, которое повысит конверсию.
Советы по подготовке 3D-моделей
- Используйте единицы измерения метры.
- Убедитесь, что модель имеет правильную ориентацию (ось Y вверх).
- Оптимизируйте количество полигонов: для мебели ~50k треугольников.
- Сжимайте текстуры до 2K.
- Тестируйте модели на реальных устройствах.