Оптимизация 3D-моделей для AR (LOD, текстуры, полигонаж)

3D-художник сдал модель кресла — 1.2 миллиона полигонов, текстуры 8192×8192 PNG. В Cinema 4D рендер выглядит отлично. В AR на iPhone — 18 FPS и перегрев за 3 минуты. Мы сталкиваемся с такими кейсами постоянно. Наш опыт показывает: проблема не в приложении и не в ARKit — модель не подготовлена для мобильного GPU. Такая ситуация ведёт к срыву демонстрации клиенту и потере времени. Каждый второй проект по AR-визуализации сталкивается с этим.

Оптимизация 3D-моделей для AR — задача, которая требует понимания архитектуры мобильных GPU. Мы решаем её комплексно: снижаем полигонаж, сжимаем текстуры, настраиваем LOD. Результат — стабильные 60 FPS на устройствах. Это позволяет показывать AR-контент без лагов и перегрева. Клиенты экономят на каждом проекте благодаря снижению времени загрузки и расходов на хранение.

Почему полигонаж важен для AR?

На экране телефона расстояние до AR-объекта — 0.5–3 метра. На этом расстоянии детализация выше 100–150K полигонов визуально неотличима от 50K. Правило практики:

Decimation в Blender: Modifier → Decimate → Collapse с Ratio = 0.05–0.1 для сложных моделей даёт нужный результат без ручной ретопологии. Quadric Edge Collapse Decimation лучше сохраняет форму краёв чем Unsubdivide.

После decimation — обязательная проверка в AR на целевом устройстве, а не только в превью редактора. Силуэт объекта важнее внутренних деталей — декодируем по-другому.

Как выбрать формат текстур?

Самое большое влияние на производительность — текстуры, а не полигонаж. ASTC (Adaptive Scalable Texture Compression) — правильный формат для мобильного AR. Поддерживается всеми ARM Mali и Qualcomm Adreno GPU с середины предыдущего десятилетия. ASTC 6×6 даёт примерно 2.37 bpp против 32 bpp у PNG — в 13 раз меньше памяти GPU при минимальных потерях качества. Подробнее о сжатии текстур читайте на Wikipedia.

ETC2 — универсальный fallback для старых устройств (GLES 3.0+). Хуже ASTC по качеству сжатия, но поддерживается шире.

Никогда не используйте PNG/JPEG в текстурах AR-сцены. PNG декодируется в полный RGBA8888 — для текстуры 2048×2048 это 16 MB GPU-памяти. ASTC 2048×2048 — около 2 MB.

Генерация ASTC через astcenc (командная строка):

astcenc -cl input.png output.astc 6x6 -medium 

В Xcode Asset Catalog: добавляем текстуру, устанавливаем Compression = Lossy → автоматически ASTC на iOS. На Android — компиляция через Android Studio или в CI через texturetool.

Размер текстур. Правило: размер текстуры пропорционален видимой площади объекта на экране. Для объекта занимающего 20% экрана — текстура 512×512 даёт неотличимый от 2048×2048 результат. Mipmap обязателен: SceneKit и ARCore автоматически используют уровень mipmap соответствующий размеру отображения.

Реализация LOD для AR

В отличие от игровых движков, ARKit SceneKit не имеет встроенного LOD-менеджера. Реализуем через SCNLevelOfDetail. Вот пример кода:

let highPolyGeometry = loadGeometry("chair_high.usdz") // 50K полигонов let medPolyGeometry = loadGeometry("chair_med.usdz") // 15K полигонов let lowPolyGeometry = loadGeometry("chair_low.usdz") // 5K полигонов let lod1 = SCNLevelOfDetail(geometry: medPolyGeometry, screenSpaceRadius: 100) let lod2 = SCNLevelOfDetail(geometry: lowPolyGeometry, screenSpaceRadius: 30) node.geometry?.levelsOfDetail = [lod1, lod2] 

screenSpaceRadius — радиус bounding sphere в экранных пикселях. При значении 100 — модель занимает около 200×200 пикселей. Числа подбираются под конкретный объект эмпирически. Подробнее — в SCNLevelOfDetail.

На Android ARCore с Filament LOD реализуется через MaterialInstance swap или через RenderableManager.Builder.boundingBox() для culling.

USDZ / glTF: правильный формат для AR

USDZ (iOS, macOS) — контейнер на основе OpenUSD от Pixar. Содержит геометрию, материалы, анимации, физику. Поддерживает AR Quick Look без кода. Reality Converter (macOS-приложение от Apple) конвертирует из FBX/OBJ/glTF в USDZ с одновременной оптимизацией текстур.

glTF 2.0 (Android/Cross-platform) — открытый стандарт, нативно поддерживается Filament и Sceneform. glb — бинарный вариант, предпочтителен для AR (один файл вместо нескольких). Оптимизация через gltf-pipeline:

gltf-pipeline -i model.gltf -o model_opt.glb \ --draco.compressMeshes --draco.quantizePositionBits 14 

Draco compression (Google) уменьшает размер геометрии в 5–10 раз за счёт сжатия с потерями. Качество регулируется quantizeBits — 14 бит достаточно для большинства AR-объектов.

Выбор формата зависит от платформы: USDZ — нативная поддержка AR Quick Look, малый размер, но только iOS. glTF + Draco — кроссплатформенность, сильное сжатие, но нужен загрузчик. Для кросс-платформенных проектов чаще выбирают glTF, для iOS-экосистемы — USDZ.

Как мы это делаем: стек и процесс

Мы используем Blender для decimation, astcenc для сжатия, Xcode и Android Studio для тестирования. Процесс разбит на этапы:

1. Анализ исходных моделей: выявляем избыточный полигонаж, размер текстур, отсутствие LOD.
2. Decimation до целевого полигонажа (среднее снижение в 10 раз).
3. Сжатие текстур в ASTC/ETC2 с генерацией mipmap.
4. Создание LOD-уровней (до 3 уровней).
5. Экспорт в USDZ или glTF с Draco-сжатием.
6. Тестирование на реальных устройствах (iPhone и Android).

Более 5 лет опыта в AR-разработке и более 200 успешных проектов подтверждают: такой подход гарантирует результат. Пример из практики: крупный мебельный бренд хотел показать каталог в AR. Исходные модели весили по 200 МБ. Мы снизили полигонаж до 30K, сжали текстуры в ASTC, добавили LOD. Финальные модели — 15 МБ, AR-сцена работала на 60 FPS даже на iPhone X. Экономия на хранении и передаче — около 30 000 ₽ в месяц для каталога из 50 моделей.

Источник: отчёт проекта для мебельного бренда.

Чек-лист для самостоятельной проверки

• Полигонаж < 100K для средних объектов.
• Текстуры сжаты в ASTC или ETC2.
• Размер текстур ≤ 1024×1024 для объектов не первого плана.
• Настроены LOD (минимум 2 уровня).
• Формат — USDZ (iOS) или glTF (Android).

Что входит в работу

В рамках услуги мы предоставляем:

• Анализ исходных моделей и отчёт по оптимизации.
• Decimation, сжатие текстур, создание LOD-уровней.
• Экспорт в USDZ/glTF с Draco-сжатием.
• Тестирование на целевых устройствах (iOS/Android).
• Документацию по пайплайну и рекомендации для дальнейшего использования.
• Обучение вашей команды работе с оптимизированными моделями.

Сроки и стоимость

Оптимизация одной модели занимает от 0.5 до 1 дня. Для каталога из 20–50 моделей — 1–2 недели с настройкой автоматизированного пайплайна. Стоимость рассчитывается индивидуально в зависимости от сложности и объёма. Свяжитесь с нами для оценки вашего проекта — мы подготовим коммерческое предложение. Закажите консультацию, и мы бесплатно проанализируем ваши модели.