Пайплайн інтеграції 3D-ассетів у Unity та Unreal: автоматизація імпорту

Часто в нашій практиці художник віддає FBX-файл, створений у Maya або Blender. Ви імпортуєте його в Unity або Unreal Engine. Модель повернута на 90 градусів, масштаб у 100 разів більший за потрібний, нормалі інвертовані на половині полігонів, а скелет містить 8 додаткових кісток від допоміжних об'єктів у сцені Maya. Це стандартна ситуація без чіткого пайплайну передачі ассетів, що призводить до втрати часу на ручні виправлення та збільшує ризик помилок при інтеграції.

Інтеграція 3D-активів — це не просто «перетягнути файл у Project Window». Це узгодження систем координат, масштабів, форматів скелетів, UV-каналів, naming conventions для матеріалів та коректне налаштування Import Settings під конкретний рушій та платформу. Ми скорочуємо час на інтеграцію до 60% за рахунок автоматизації та чітких регламентів. Економія на інтеграції кожної наступної партії ассетів становить 30–50% порівняно з ручним пайплайном.

Як правильно налаштувати пайплайн інтеграції 3D-ассетів?

Неспівпадіння систем координат

Maya та 3ds Max використовують Y-up, Blender за замовчуванням Z-up, Unity — Y-up, Unreal — Z-up. При експорті FBX із Blender без правильного налаштування Export Axis Convention модель у Unity буде повернута. Для анімованого скелета це означає, що Animation Clips не будуть відтворюватися коректно.

Зайві трансформації та Pivot-проблеми

Художник здає персонажа з Pivot у ногах, пропс — з Pivot у геометричному центрі. В Unreal це критичніше: Static Mesh Pivot впливає на вирівнювання при розміщенні в рівні. Правило: Pivot-точка визначається заздалегідь у техзавданні на ассет.

Матеріали та named slots

При імпорті FBX Unity створює Material Slots за іменами у файлі. Якщо художник називає матеріали Material.001, розібратися потім складно. Перед експортом усі матеріали повинні мати семантичні імена: M_Char_Body, M_Char_Face. Цю угоду закріплюємо в Asset Naming Convention документі.

UV-канали для Lightmap

Unity потребує другий UV-канал для запікання освітлення. Якщо ассет прийшов без UV2 — Unity автогенерує його, і результат часто неоптимальний: overlapping UV islands. Для серйозних проєктів UV2 робимо в DCC (Maya/Blender) вручну.

Налаштування Import Settings під задачу

У Unity Import Settings для Mesh:

• Scale Factor — стандартно 0.01 для Maya/3ds Max (вони працюють у сантиметрах, Unity в метрах). Blender — 1.0 при правильному експорті.
• Read/Write Enabled — вимикаємо для статичних мешів, залишаємо тільки якщо потрібна runtime mesh modification.
• Optimize Mesh — вмикаємо для фінальних ассетів (перегруповує трикутники для кращого cache coherency GPU).
• Generate Colliders — тільки для простих convex мешів. Складну колізію робимо окремим Low-poly Collider Mesh.

Для скинірованих персонажів: Rig → Animation Type = Humanoid (якщо потрібен Avatar і Retargeting) або Generic (якщо кастомний скелет без ретаргетингу). Humanoid має суворі вимоги до ієрархії кісток — усі 15 обов'язкових кісток повинні бути мапповані.

Чому glTF 2.0 кращий за FBX для нових проєктів?

Порівняння форматів:

glTF 2.0 — сучасний відкритий стандарт, нативно підтримується в Unreal 5.1+ та Unity через пакет com.unity.formats.gltf. PBR-матеріали (metallic/roughness workflow) передаються без конвертації. Проблем з масштабом і координатами значно менше, ніж у FBX. Ми рекомендуємо glTF для нових проєктів — це знижує кількість ручних правок на 70%.

USD (Universal Scene Description) актуальний для Unreal Engine з USDZ, пайплайнів з Omniverse та AR (Apple Reality Composer). Підтримує референси на інші USD-файли, що зручно для збірки сцен із модульних ассетів.

FBX — legacy стандарт, але поки що найуніверсальніший. Його проблеми відомі та вирішувані при правильному workflow. Для автоматизації виправлень ми використовуємо FBX SDK.

Процес роботи над інтеграцією ассетів

1. Аудит ассетів — перевірка переданих файлів на відповідність вимогам (vertex count, наявність UV2, імена матеріалів, координати).
2. Розробка Asset Delivery Guide — документ для художників: налаштування експорту, naming conventions, вимоги до матеріалів та полікаунту.
3. Налаштування автоматичного імпорту — пишемо AssetPostprocessor для Unity або Editor Utility Blueprint для Unreal, щоб призначати Import Settings автоматично.
4. Валідація та виправлення проблем — batch-скрипти для виправлення інвертованих нормалей, перейменування матеріалів, вирівнювання pivot.
5. Тестування на сцені — перевірка ассета в рушії: LOD, колізія, анімації, освітлення.
6. Здача та документування — фіксація налаштувань, навчання команди, передача готового пайплайну.

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

Точна вартість розраховується після аудиту ваших ассетів та обраного рушія. Зв'яжіться з нами для оцінки проєкту. Замовте аудит — ми оцінимо економію для вашого проєкту.

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

• Аудит існуючих ассетів та виявлення проблем.
• Розробка та впровадження Asset Delivery Guide.
• Налаштування автоматизованого імпорту через AssetPostprocessor або Editor Utility Blueprint.
• Написання batch-скриптів для виправлення типових помилок (інвертовані нормалі, pivot, naming).
• Тестування пайплайну на пілотній партії ассетів.
• Документація та навчання команди.
• Пост-релізна підтримка (2 місяці).

Наші компетенції

Наша команда має 10+ років досвіду в геймдеві, реалізувала понад 50 проєктів з інтеграції ассетів у Unity та Unreal Engine. Гарантуємо безшовну інтеграцію ассетів будь-якого рівня складності. Досвід підтверджується сертифікатами Unity та Unreal. Знижуємо витрати на виправлення артефактів на 30–50%.

Отримайте консультацію з налаштування пайплайну — пишіть, оцінимо ваш проєкт безкоштовно.

Типові проблеми продуктивності ігор

Проект запускається на топових девайсах розробника без питань. На mid-range Android п'ятирічної давності — 20 fps і перегрів через 5 хвилин. На iPhone 11 — стабільні 60, але на iPhone XR — просідання у важких сценах. Ми стикаємося з цим кожен день. Оптимізація — не «потім», а архітектурне рішення з першого коміту. За 8 років роботи ми провели оптимізацію більш ніж для 50 ігор — від гіперказуалки до AAA на консолях. Гарантуємо: після нашого аудиту ви отримаєте не просто список проблем, а конкретний план з вимірними цілями та термінами. Замовте аудит продуктивності — оцінимо ваш проект за 3 дні і покажемо, як знизити draw calls на 40% без втрати якості.

Як профілювати продуктивність ігор?

Перш ніж оптимізувати — виміряти. Оптимізація без профілювання — вгадування.

Профілюйте на цільовому залізі, а не в редакторі. Editor додає оверхед — цифри з Play Mode не репрезентативні. Розділяйте GPU та CPU bottleneck: на CPU багато draw calls або важка логіка, на GPU — складні шейдери або overdraw. Документація Unity: профілювання на пристрої — обов’язковий крок для мобільних ігор. Типовий час профілювання одного сценарію — 5–8 годин, включаючи збір метрик на 3–5 пристроях різних поколінь. Аналізуємо 10–15 ключових ігрових сценаріїв за 3 робочих дні.

Як зменшити кількість draw calls?

Draw call — команда CPU до GPU «намалюй це». Кожен виклик має overhead незалежно від складності геометрії. На мобільних 200–300 draw calls за кадр — межа. Мета: мінімізувати їх кількість, об’єднуючи геометрію з однаковим матеріалом.

Static Batching об’єднує нерухомі меші при збірці. Вимога: прапорець Static на об’єкті та однаковий матеріал. Ефективний для статичного оточення, але збільшує споживання пам’яті — об’єднаний меш зберігається окремо. Static Batching може знизити draw calls в 3 рази, але збільшує пам’ять на 20% порівняно з іншими методами. У сценах з тисячами статичних об’єктів слідкуйте за пам’яттю через Memory Profiler.

Dynamic Batching об’єднує меші в рантаймі з жорсткими обмеженнями: менше 900 вертексних атрибутів на меш, однаковий матеріал та масштаб. На практиці ефективний лише для дрібних об’єктів (партикли, UI). В URP за замовчуванням вимкнений — його витіснив SRP Batcher.

SRP Batcher — не класичний батчінг, а оптимізація CPU-overhead при підготовці draw calls. Замість того щоб кожен кадр заново завантажувати uniform-дані шейдера, SRP Batcher кешує їх у GPU-пам’яті та оновлює лише ті, що змінилися. Draw calls залишаються колишніми за кількістю, але кожен займає менше часу CPU — SRP Batcher дає приріст в 2–3 рази по CPU-часу рендеру. Вимога: шейдер має бути сумісний з SRP Batcher (декларувати per-object властивості в UnityPerDraw CBUFFER). Стандартні URP Lit/Unlit шейдери сумісні. Кастомні — перевіряємо в Inspector матеріалу: SRP Batcher compatible: Yes/No. Для ввімкнення переконайтеся, що в URP Asset опція SRP Batcher активна, а для кастомних шейдерів використовуйте макрос UNITY_INSTANCING_BUFFER і декларуйте per-object властивості в блоці CBUFFER_START(UnityPerDraw). Після ввімкнення в Profiler має знизитися час RenderLoop.Draw на CPU.

GPU Instancing — для множини копій одного меша з одним матеріалом (дерева, трава, NPC). Відправляє один draw call з масивом per-instance даних. Вмикається на матеріалі: Enable GPU Instancing. Обмеження: всі інстанси в одному batch повинні мати однаковий матеріал і меш. Graphics.DrawMeshInstanced / Graphics.DrawMeshInstancedIndirect — для процедурного рендерингу без GameObject overhead.

Вибір методу залежить від сценарію: Static Batching підходить для статичного оточення, SRP Batcher виграє в проектах з множиною унікальних матеріалів, GPU Instancing незамінний для масових об’єктів (ліс, натовп), Dynamic Batching — лише для дрібних та рідкісних випадків. На практиці ми комбінуємо все, починаючи з профілювання.

Детальніше про технологію — на Wikipedia.

Чому оптимізація пам'яті критична для мобільних ігор?

Мобільні платформи — жорсткі обмеження по RAM. iOS вбиває додаток при перевищенні пам’яті без попередження (memory pressure kill). Android — аналогічно, але з onLowMemory callback. Цільові бюджети: iOS — <1 GB для сучасних пристроїв, <512 MB для підтримки iPhone 8/X; Android — <800 MB для широкої сумісності (ОС займає 400–600 MB). Типова економія після нашої оптимізації — 30–50% оперативної пам’яті при збереженні якості. Середня економія бюджету на етапі оптимізації — від $3,000 до $8,000 залежно від складності проекту, що підтверджується нашими кейсами.

Addressables та Asset Bundles: як не перевищити бюджет

Завантажувати все одразу при старті — неприйнятно для великих проектів. Addressables (надбудова над Asset Bundles) — система адресованого асинхронного завантаження асетів. Явне вивантаження: Addressables.ReleaseInstance / Addressables.Release. Addressables не вивантажують асети автоматично при знищенні об’єкта. Типова помилка: Addressables.InstantiateAsync у циклі без Release — пам’ять росте до крашу. Reference counting: асет вивантажується тільки коли всі його handles звільнені. Архітектурний патерн: сервіс/менеджер тримає handle завантаженого асета, звільняє при переході між сценами.

Groups та Bundle Strategy: групуємо асети за логікою завантаження. Наприклад, всі асети одного рівня — в один bundle, шарені (UI, шрифти) — в окрему групу з Prevent Updates. Така стратегія економить до 30% пам’яті.

Texture Memory: звідки береться 70% займаного об'єму

Текстури — основний споживач пам’яті. Аналіз через Memory Profiler: вкладка All Of Memory → Texture2D — одразу видно список найважчих текстур. На практиці ми знаходимо текстури з завищеним Max Size (4096 для мобільної іконки — типова помилка). Заходи: Mipmap для 3D-текстур (ввімкнути), для UI (вимкнути); Streaming Mipmaps для open world — завантажує mip-рівні по мірі наближення камери. Красовська проблема: текстури, на які посилаються невикористовувані Materials, залишаються в пам’яті — Memory Profiler покаже reference chain. Видаляйте зайві матеріали. Після заміни всіх текстур формату RGBA32 на ASTC 6×6 на Android економія досягає 60% без втрати якості.

GC Allocations: як усунути фризи в Hot Path

C# garbage collector в Unity — stop-the-world. Якщо за кадр алоційовано багато heap-пам’яті, GC-пауза викликає видимий фриз. Ціль: нульові алокації в hot path (Update, FixedUpdate, рендер). Типові джерела: string конкатенація в Update (замінюємо на StringBuilder), LINQ в hot path (ручні цикли з предалоційованими списками), GetComponent<T>() кожен кадр (кешуємо в Awake/Start), boxing value types при передачі в object параметри. Після профілювання за допомогою Unity Profiler ми знижуємо алокації в hot path на 95% — фризи зникають.

Як відсікти зайві 40% draw calls? LOD та Culling

LOD Group — перемикання на спрощену геометрію при віддаленні об’єкта від камери. Стандарт для 3D оточення: LOD0 (100%), LOD1 (30–50% трикутників), LOD2 (10–15%), Culled. Для мобільних поріг Culled ставимо агресивніше — менше малюємо за кадр. LOD знижує draw calls на 40–60% залежно від кількості об’єктів.

Occlusion Culling — Unity не рендерить об’єкти за стінами. Вимагає запечені occlusion дані. Для indoor сцен знижує draw calls на 20–40%.

Frustum Culling працює автоматично — об’єкти поза FOV камери не рендеряться. Але draw call на перевірку все одно відбувається. Для сцен з тисячами об’єктів — кастомний spatial partitioning (Quadtree, Octree). В одному з проектів впровадження оклюзійного калінгу та LOD знизило загальну кількість draw calls з 2800 до 450 на Android.

Оптимізація VR: як утримати 72 FPS на Quest 3

VR — окремий клас задач. Фреймрейт 72/90 Hz не можна порушувати, інакше motion sickness. Додатково до стандартних методів: Single Pass Instanced Rendering — рендер для обох очей за один прохід (знижує draw calls в 2 рази); Fixed Foveated Rendering (Quest) — зниження роздільної здатності на периферії; Late Latching (Quest 3) — оновлення позиції контролера максимально пізно перед рендером; Dynamic Resolution в URP/HDRP — автоматичне зниження роздільної здатності рендера при просадці fps. Для Quest профілюємо через OVR Metrics Tool — показує CPU/GPU time прямо в гарнітурі. Після застосування цих методів частота кадрів на Quest 2 стабілізується на 72 FPS навіть у сценах з 1.5 млн полігонів.

Які етапи оптимізації та терміни?

Ми пропонуємо комплексну послугу «під ключ»:

1. Профілювання на цільових пристроях — збір метрик (FPS, draw calls, пам’ять, GC). Аналізуємо 10–15 ключових сценаріїв за 3–5 робочих днів.
2. Звіт з пріоритетами — які проблеми критичні, які можна відкласти. Пріоритети виставляємо на основі впливу на ігровий досвід.
3. Впровадження оптимізацій — батчінг, LOD, Addressables, шейдери, occlusion culling. Середній цикл впровадження — 2–4 тижні.
4. Повторне профілювання — замір покращень. Типовий приріст FPS — 30–60% на мобільних пристроях.
5. Документація — рекомендації по підтримці та подальшій розробці.
6. Навчання команди — як не допустити регресу. Проводимо воркшопи з профілювання та оптимізації.

Завдяки запобіганню переробок на пізніх етапах замовник отримує значну економію. Отримайте консультацію — ми безкоштовно оцінимо ваш проект і покажемо потенціал оптимізації. Звертайтеся, щоб дізнатися точні терміни та вартість для вашого стеку.