Створення анімованих 3D-моделей для AR із ригінгом та анімацією

При спробі відтворити анімацію в ARKit персонаж «телепортується» між кліпами? Або анімація в GLB працює на iOS, але ламається на Android? Такі проблеми — наслідок неоптимізованого пайплайну анімації для AR. На відміну від звичайної 3D-анімації, тут кожен кадр рендериться на мобільному GPU в реальному часі. Обмеження: до 60–80 кісток для скелетної анімації, 52 blend shapes для лицьової, частота кадрів 12–24 fps для вторинних рухів. Наш досвід — 7+ років і 30+ реалізованих проєктів для iOS та Android. Ми оптимізуємо пайплайн, щоб зберегти якість при мінімальній вазі. Звертайтеся — допоможемо з вашим проєктом.

Чому анімація в AR відрізняється від звичайної?

В AR немає готового середовища з постобробкою. Мобільний GPU зобов'язаний обробляти анімацію в реальному часі — звідси жорсткі обмеження. Зате відкриваються нові можливості: взаємодія з реальним світом, вбудовування в оточення, тактильний відгук. Щоб цим скористатися, потрібно правильно вибрати тип анімації та підготувати модель.

Які типи анімації використовуються в AR?

Skeletal animation (ригінг). Персонажі, тварини, роботи. Скелет із кісток керує деформацією меша. Для AR-персонажів — максимум 60–80 кісток. Більше — вага скінінгу (skin weights) перевантажує GPU на мобільних пристроях.

Блендер-пайплайн для AR-персонажа:

1. Моделювання low-poly меша
2. Ригінг через Armature (автоматичний Rigify або ручний для стилізованих персонажів)
3. Скінінг: Weight Paint Mode — критично виставити ваги коректно, інакше при анімації меш рветься в суглобах
4. Анімація в Action Editor: idle, walk, run, interaction (кожен Action = окремий кліп)
5. Запікання анімації в keyframes (важливо для USDZ — не всі криві підтримуються)

Morph target animation (blend shapes). Обличчя, міміка, деформації без скелета. Face AR фільтри використовують 52 ARKit blend shape коефіцієнти — під них створюємо відповідні morph targets у Blender:

jawOpen → ARKit blendShapeLocation.jawOpen
eyeBlinkLeft → ARKit blendShapeLocation.eyeBlinkLeft

Сумісність 1:1 з ARKit іменами дає автоматичне керування мімікою через ARFaceAnchor.blendShapes.

Procedural animation. Обертання шестерень, коливання листя, пульсація. В USDZ через UsdGeom.Xformable з анімованими xformOpOrder. У RealityKit — через AnimationResource з FromToByAnimation. Не потребує скелета, мінімальна вага.

Порівняння типів анімації

Skeletal animation дає більше контролю, але morph target ефективніше для міміки з вагою вдвічі меншою. Вибір залежить від завдання.

Ключові проблеми при створенні AR-анімації

USDZ та обмеження анімації. USDZ підтримує лише певні типи анімаційних кривих. Blender експортує в USD через стандартний експортер, але Driver-анімації, нелінійний редактор та деякі модифікатори — ігноруються. Потрібно запікати (Bake Action) в keyframes перед експортом:

Object → Animation → Bake Action
→ Only Selected Bones, Visual Keying, Clear Constraints

Після запікання — перевіряємо в Reality Composer або Quick Look на iOS. Те, що виглядає нормально в Blender, може не відтворюватися в ARKit. Офіційна документація Apple рекомендує цей підхід (див. Loading Animations from USDZ Files in RealityKit).

Розмір анімованого USDZ. Анімація додає дані ключових кадрів. 10-секундний walk cycle на персонажі з 60 кісток при 24 fps = 240 ключових кадрів × 60 кісток × transform data. Оптимізація: знижуємо частоту кадрів анімації до 12–15 fps для вторинних рухів (одяг, волосся), основні кістки — 24 fps. Різниця — 20–40% за вагою файлу.

Loop та переходи між кліпами. У RealityKit перемикання між анімаціями:

entity.stopAllAnimations()
entity.playAnimation(walkAnimation, transitionDuration: 0.3, startsPaused: false)

transitionDuration забезпечує плавний перехід. Але для коректного переходу idle→walk→run позиції кісток у кінцевому кадрі одного кліпу повинні бути близькі до початкового кадру наступного — інакше персонаж «телепортується». Ми гарантуємо seamless loops завдяки точному налаштуванню ключових кадрів.

Як правильно експортувати анімацію в USDZ?

Використовуйте запічені keyframes, уникайте Driver-анімацій та модифікаторів. У Reality Composer Pro (Xcode 15+) доступний попередній перегляд. Для конвертації з FBX з анімацією використовуйте reality-converter CLI:

xcrun reality-converter -i character_animated.fbx -o character.usdz

GLB з анімацією — для Android та WebAR. Blender → Export → glTF 2.0 → Format: GLB. Анімації експортуються як animations[] масив у glTF-структурі. Draco-стиснення для геометрії, але не для анімаційних даних (вони не стискаються Draco). Отримайте консультацію, щоб ми допомогли налаштувати пайплайн під ваше завдання.

Кейс з нашої практики

AR-маскот для маркетингової кампанії: пінгвін з 5 анімаціями (idle, wave, dance, point, celebrate). Модель — 8000 полігонів, 42 кістки. Використали Blur AR на iOS, ARCore на Android. Головна складність: один і той самий GLB працював коректно в Chrome WebAR, але dance анімація «ламалася» на Android ARCore — обертання стегон виходило за межі [-π, π] і GLB-парсер ARCore обробляв це інакше. Рішення: нормалізувати всі euler rotation curves у Blender перед експортом через Python script. Після фіксу анімація запрацювала на обох платформах. Зв'яжіться з нами, щоб ми допомогли з подібним завданням.

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

• Low-poly модель з ригінгом та скінінгом
• Набір анімацій (як мінімум idle + 2-4 базових)
• Експорт у USDZ та GLB з перевіркою в ARKit/ARCore
• Документація з керування анімаціями
• Тестування на реальних пристроях
• Підтримка протягом 2 тижнів після здачі

Строки та вартість

Вартість розраховується індивідуально. Базові 3D-моделі без анімації — окремо. Замовте оцінку вашого проєкту — ми запропонуємо оптимальне рішення.

Ми розробляємо AR-додатки на ARKit та ARCore, які працюють стабільно навіть у складних умовах. Наш досвід — 7+ років у мобільній розробці та 30+ реалізованих проєктів з доповненою реальністю. Гарантуємо: трекінг не загубиться, освітлення буде реалістичним, а користувач не відчує дискомфорту. Сертифіковані розробники Apple та Google.

Чому трекінг втрачається і як це виправити?

ARKit та ARCore використовують VIO (Visual-Inertial Odometry) — спільну обробку даних камери та IMU. Трекінг зривається в трьох сценаріях: освітлення нижче ~50 lux, тектурно однорідні поверхні (біла стіна, скло) та швидкі рухи камери.

На практиці це означає: якщо продукт призначений для примірки меблів, додаємо явне UI-попередження при ARCamera.TrackingState.limited(.insufficientFeatures). Додаток, який мовчки втрачає трекінг, отримує 2-зіркові відгуки — ми такого не допускаємо.

Виявлення площин налаштовується через ARWorldTrackingConfiguration.planeDetection = [.horizontal, .vertical]. Важливо: ARKit продовжує уточнювати геометрію площин через ARSCNViewDelegate.renderer(_:didUpdate:for:) — якщо не обробляти оновлення, об'єкт починає плавати при уточненні якоря. Наша команда вирішує цю проблему на етапі архітектури, а не при тестуванні.

AR Foundation: кроссплатформа з нюансами

Unity AR Foundation — шар абстракції поверх ARKit та ARCore. Він скорочує час розробки на 40% порівняно з окремими нативними кодовими базами. Але деякі функції (наприклад, ARBodyTrackingConfiguration для body tracking) недоступні та вимагають нативного плагіна.

Для React Native та Flutter прямого AR Foundation немає. Використовуємо ViroReact (React Native) або ar_flutter_plugin для простих сценаріїв, але для production-якості — нативні модулі з мостом. Гібридний підхід: AR-сцена рендериться нативним ARKit/ARCore view, управління з JS/Dart через method channel. Входить у нашу стандартну поставку.

Порівняння платформ: ARKit випереджає ARCore за стабільністю трекінгу та набором функцій (на 30% менше збоїв у сценаріях з низьким освітленням), але ARCore дешевший у підтримці пристроїв. AR Foundation — компроміс: втрачає до 20% продуктивності на складних сценах, але окупається єдиною кодовою базою.

Try-on: примірка товарів через AR

Примірка окулярів, прикрас, косметики — окремий клас задач. Тут потрібен face tracking, а не plane detection.

ARKit надає ARFaceTrackingConfiguration — 52 blend shape коефіцієнти для міміки, 3D-меш обличчя, позицію та орієнтацію в просторі. Працює лише на пристроях з TrueDepth-камерою (iPhone з Face ID).

Для Android еквівалент — ML Kit Face Mesh Detection або Google ARCore Augmented Faces (Pixel та деякі флагмани). Для кроссплатформенного try-on використовуємо Banuba Face AR SDK — покриває обидва пристрої, дає готові маски та стабільний трекінг навіть на mid-range Android.

Якість try-on критично залежить від 3D-моделей товарів. Моделі мають бути оптимізовані під real-time: не більше 10-15K полігонів для прикрас, PBR-матеріали з коректними roughness/metallic картами, LOD для далеких дистанцій. В рамках нашого підряду ми надаємо готові гайди з оптимізації моделей.

Як досягти реалістичного освітлення в AR?

ARKit з сучасними версіями iOS підтримує Environmental Texturing — автоматичне створення environment map з камери для реалістичних відображень. Вмикається через ARWorldTrackingConfiguration.environmentTexturing = .automatic. Без цього металеві та скляні матеріали виглядають пластиково.

ARCore надає Light Estimation — intensity та color temperature навколишнього світла, що застосовуються до шейдера віртуальних об'єктів. На практиці це різниця між об'єктом, який «вписується» в сцену, та очевидно накладеною 3D-моделлю. Ми гарантуємо, що фінальне зображення не видає віртуальності.

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

• Архітектура AR-рішення (вибір стеку, проектування модулів)
• 3D-пайплайн: оптимізація моделей під real-time, PBR-матеріали, LOD
• Інтеграція трекінгу (площини, обличчя, зображення, об'єкти)
• Тестування на 10+ реальних пристроях (iOS та Android)
• Документація з використання SDK та готових компонентів
• Підтримка після запуску (1 місяць баг-фіксингу)

Строки та оцінка

Проста AR-сцена з розміщенням однієї 3D-моделі на площині — 1–2 тижні. Face try-on з каталогом товарів — від 6 тижнів (3D-пайплайн, інтеграція трекінгу, UI вибору та збереження). Повноцінний AR-шопінг з хмарними якорями та мультиплеєром — від 3 місяців. Оцінимо проєкт за 1 день — пишіть, обговоримо вашу AR-ідею.