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. Правило практики:
| Розмір об'єкта | Рекомендований полігонаж | Відстань перегляду |
|---|---|---|
| Невеликий (чашка, телефон) | 5 000–15 000 | 0.3–1 м |
| Середній (крісло, лампа) | 15 000–50 000 | 0.5–2 м |
| Великий (диван, шафа) | 30 000–80 000 | 1–3 м |
| Дуже великий (автомобіль) | 50 000–120 000 | 2–10 м |
Decimation в Blender: Modifier → Decimate → Collapse з Ratio = 0.05–0.1 для складних моделей дає потрібний результат без ручної ретопології. Quadric Edge Collapse Decimation краще зберігає форму країв ніж Unsubdivide.
Після decimation — обов'язкова перевірка в AR на цільовому пристрої, а не тільки в прев'ю редактора. Силует об'єкта важливіший за внутрішні деталі — декодуємо по-іншому.
Як перевірити модель на готовність
- Зберіть модель в Xcode або Android Studio. - Запустіть на пристрої з iOS 15+ або Android 11+. - Переконайтеся, що FPS не падає нижче 50 протягом 10 хвилин. - Перевірте нагрів: корпус не повинен бути гарячим на дотик.Як вибрати формат текстур?
Найбільший вплив на продуктивність — текстури, а не полігонаж. 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 для тестування. Процес розбитий на етапи:
- Аналіз вихідних моделей: виявляємо надлишковий полігонаж, розмір текстур, відсутність LOD.
- Decimation до цільового полігонажу (середнє зниження в 10 разів).
- Стиснення текстур в ASTC/ETC2 з генерацією mipmap.
- Створення LOD-рівнів (до 3 рівнів).
- Експорт в USDZ або glTF з Draco-стисненням.
- Тестування на реальних пристроях (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 тижні з налаштуванням автоматизованого пайплайну. Вартість розраховується індивідуально залежно від складності та обсягу. Зв'яжіться з нами для оцінки вашого проекту — ми підготуємо комерційну пропозицію. Замовте консультацію, і ми безкоштовно проаналізуємо ваші моделі.