Кастомні VFX-частинки для мобільних AR: оптимізація під Unity

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

Від імерсивних застосунків до ігрових світів і 3D-сцен

Наша виділена команда для VR/AR/MR-розробки, Unity-продакшну і 3D-моделювання та анімації — з власними кейсами і презентаціями.

Відвідати персоналізований сайт
Показано 1 з 1Усі 242 послуг
Кастомні VFX-частинки для мобільних AR: оптимізація під Unity
Середній
~1-2 тижні
Часті запитання

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

Які етапи розробки гри?

Останні роботи

  • image_games_mortal_motors_495_0.webp
    Розробка гри для компанії Mortal Motors
    1421
  • image_games_a_turnbased_strategy_game_set_in_a_fantasy_setting_with_fire_and_sword_603_0.webp
    Покрокова стратегія у фентезі сеттингу With Fire And Sword
    954
  • image_games_second_team_604_0.webp
    Розробка ігри для компанії Second term
    575
  • image_games_phoenix_ii_606_0.webp
    3D-анімація – тизер для гри phoenix 2.
    637

Уявіть: ви запускаєте AR-гру з ефектом вибуху на 2000 частинок. На iPhone 13 — 45 FPS, на Adreno 618 — 22 FPS. Знайома ситуація? Ми 5+ років займаємося мобільною AR-розробкою і знаємо, як вичавити максимум з обмеженого заліза. У цій статті розберемо, чому стандартні системи частинок «просаджують» і як це виправити.

Чому продуктивність падає в AR-частинках?

Overdraw — головний ворог на мобільних GPU. Кожна напівпрозора частинка перекриває попередню, і GPU виконує blending для кожного перекриття. 500 частинок з Alpha Blend в режимі Overlay — це потенційно 500 × (середнє перекриття) операцій blending за фрейм. На тайлових GPU (Adreno, Mali) overdraw >3x в зоні ефекту — помітний удар по GPU time.

Рішення — Additive blending замість Alpha Blend там, де це можливо. Additive не читає destination buffer — тільки пише додавання, що швидше. Для вогню, світіння, магічних ефектів — ідеально. Для диму та реалістичних хмар — Additive виглядає неприродно, там потрібен Alpha Blend з обмеженою кількістю частинок.

Collision з AR-поверхнею — дорога операція. Particle System → Collision → Type: World з Collision Quality: High змушує кожну частинку проходити фізичний raycast кожен фрейм. 1000 частинок з World Collision = 1000 raycasts/фрейм. На мобілі це катастрофа.

Для AR-сцен краще працює Collision Type: Planes — задаємо кілька площин вручну, що відповідають AR-поверхням. Площини оновлюємо від ARPlane компонентів з AR Foundation при виявленні нових поверхонь. Не всі фізичні деталі, але продуктивність в 10 разів краща.

Draw Calls від багатьох Renderer-ів. Кілька Particle System з різними матеріалами — це кілька Draw Calls, які не батчаться. GPU Instancing для Particle System вмикається через Material.enableInstancing = true, але працює тільки коли частинки не прозорі або Additive — для Alpha Blend GPU Instancing неефективний через вимогу сортування.

Як ми оптимізуємо системи частинок під мобільні AR-ігри?

Покроковий план оптимізації:

  1. Аналіз поточних ефектів і виявлення вузьких місць через Profiler.
  2. Вибір стратегії blending: замінюємо Alpha Blend на Additive де можливо.
  3. Оптимізація collision: перехід на Planes Collision замість World.
  4. Об'єднання матеріалів і включення GPU Instancing.
  5. Профілювання на цільових пристроях і фінальне налаштування.

Visual Effect Graph (VFX Graph) — обчислення частинок на GPU. Ідеальний для PC і консолей, але на мобілі підтримка обмежена: вимагає Compute Shader, який доступний тільки на Metal (iOS A12+) і Vulkan (Android API 28+). Старі пристрої не потягнуть. Якщо таргет — mid-range Android, VFX Graph не підходить.

Burst Compiler + Job System для CPU частинок. Якщо частинки керуються скриптом (не стандартною Particle System), можна перенести логіку на IJobParallelFor з Burst. Це дає 5–15x прискорення обчислень порівняно з Mono, звільняючи головний потік.

LOD для систем частинок через ParticleSystemRenderer.maxParticleSize і динамічне зниження emission.rateOverTime залежно від відстані до AR-об'єкта. На дистанції >3 метрів від AR-маркера знижуємо кількість частинок вдвічі — непомітно візуально, але знижує overdraw.

Texture Sheet Animation замість кількох текстур. Один Sprite Sheet 512x512 з 16 кадрами анімації замість 16 окремих текстур — один Material, одна texture sample, працює в рамках одного Draw Call.

Наш досвід: AR-гра для iOS з ефектами магії на AR Foundation. Спочатку три Particle System на один ефект з Alpha Blend, World Collision, Sub-Emitters — iPhone 12 тримав 45–50 FPS замість цільових 60. Після переходу на Additive + Planes Collision + об'єднання в один Renderer з Texture Sheet — 60 FPS stable. Візуальна якість знизилася незначно, що пройшло непоміченим у плейтестах. Правильна оптимізація економить час і бюджет проекту.

Інтеграція з AR Foundation

Частинки повинні коректно взаємодіяти з AR-оточенням:

  • Позиціювання ефектів на ARPlane через Pose з ARRaycastHit
  • Occlusion: частинки повинні ховатися за реальними об'єктами. Реалізується через ARKit/ARCore Occlusion (AROcclusionManager) — при включеному Human/Environment Occlusion частинки автоматично маскуються глибиною реального світу
  • Освітлення: AREnvironmentProbeManager генерує Light Probe з оточення в реальному часі — частинки з Lighting Mode: Scene Color підхоплюють реальне освітлення, що покращує вписаність ефекту в AR-сцену

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

Етап Результат
Аналіз вимог Список ефектів, цільові пристрої, вимоги до visual fidelity
Технічне проєктування Вибір Particle System vs VFX Graph, стратегія по overdraw, collision approach
Розробка ефектів Створення з оптимізацією «з нуля», не переробка під обмеження post-factum
Профілювання Unity Profiler + Xcode Instruments / Android GPU Inspector на цільових пристроях
Інтеграція з AR Foundation Прив'язка до AR-поверхонь, occlusion, освітлення
Документація та навчання Вихідники, інструкція з налаштування, консультація команди

Вартість розробки розраховується індивідуально після обговорення списку ефектів і цільових пристроїв. Гарантуємо підтримку протягом місяця після здачі проєкту.

Кількість ефектів Орієнтовні терміни
3–5 базових ефектів 1–2 тижні
10–15 ефектів з AR-інтеграцією 3–5 тижнів
Складні системи з GPU Instancing і VFX Graph 1–2 місяці

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

Unity Particle System Optimization

VR та AR розробка

Коли ми вперше запускаємо проєкт у VR-гарнітурі, більшість команд стикається з одним і тим же: технічно все працює, але в гарнітурі або заколисує, або руки «плавають» із затримкою, або сцена виглядає сіпаною на периферії погляду. Це не баги у звичному розумінні — це наслідок того, що VR/AR розробка вимагає іншого підходу до архітектури рендеру, взаємодії та UX з самого початку проєкту. Наш досвід — понад 7 років у геймдеві, 15+ завершених VR/AR-проєктів для Meta Quest, SteamVR, PSVR2, HoloLens.

Платформи та SDK

Працюємо з усім актуальним стеком. OpenXR використовуємо як базовий шар скрізь, де це можливо — він дає кроссплатформеність між Meta, Valve Index, HP Reverb та іншими PC VR-пристроями. Поверх OpenXR будуємо на XR Interaction Toolkit (Unity) або VR Expansion Plugin (Unreal).

Платформа SDK / Framework
Meta Quest 2/3/Pro Meta XR SDK, OpenXR
PC VR (SteamVR) SteamVR Plugin, OpenXR
PlayStation VR2 Sony PSVR2 SDK
HoloLens 2 Mixed Reality Toolkit (MRTK)
ARKit (iOS) AR Foundation + ARKit XR Plugin
ARCore (Android) AR Foundation + ARCore XR Plugin
WebXR Unity WebXR Export

Як мінімізувати заколисування при локомоції у VR?

Locomotion — головне джерело motion sickness для недосвідчених VR-користувачів. Згідно з дослідженнями, близько 70% користувачів відчувають дискомфорт при неправильному налаштуванні руху (Oculus Developer Guidelines). Teleportation — стандартний спосіб навігації, коли плавне переміщення небажане.

Компоненти з XR Interaction Toolkit: TeleportationArea, TeleportationAnchor, TeleportationProvider. Базова реалізація працює «з коробки», але для продакшну доопрацьовуємо її в чотири кроки:

  1. Налаштування XRRayInteractor з вигнутим променем (Bend Ray) — дуга телепортації виглядає натуральніше прямого променя, краще зчитується користувачами.
  2. Додавання валідної зони приземлення — візуальний індикатор змінює колір при наведенні на перешкоду (червоний/зелений).
  3. Впровадження fade transition — плавне згасання екрану (black fade) перед телепортом знижує дезорієнтацію.
  4. Rotation snapping — після телепорту пропонуємо snap-поворот на 45° або 90° замість плавного, що знижує ризик заколисування.

Для проєктів, де потрібна плавна локомоція (екшн-ігри, симулятори), використовуємо comfort settings: віньєтування при русі, зниження FOV під час прискорення. Налаштування доступні користувачеві в меню — різні люди мають різний поріг чутливості.

Деталі реалізації: Kinematic vs Physics-based movement

При захопленні об'єкта ключовий вибір — Kinematic (миттєве слідування за рукою) або Physics-based (утримання через Joint). Перше відгукливе, але об'єкти проходять крізь стіни. Друге дає реалістичні колізії, але при швидких рухах joint «розтягується» — потребується velocity damping та max joint force.

Як зробити захоплення об'єктів у VR фізично реалістичним?

Це найнедооціненіша частина VR-розробки. Клієнти часто сприймають її як «просто анімація рук», але на практиці — складна система, де фізична коректність, відгукливість та комфорт вступають у суперечність.

Grab (захоплення)

XR Interaction Toolkit надає три типи Interactable для захоплення:

  • XRGrabInteractable — стандартне захоплення, об'єкт слідує за контролером через фізичний joint або direct position/rotation
  • XRSimpleInteractable — для об'єктів без фізичного переміщення (кнопки, важелі)
  • Кастомні Interactable через наслідування від XRBaseInteractable

Attach Transform — часто ігнорована деталь. У кожного Interactable має бути правильно налаштований Attach Transform (точка, до якої рука «прилипає»). Без нього рукоятка пістолета опиниться по центру меша, а не там, де її тримають.

Для зброї та інструментів з дворучним захопленням — окрема система TwoHandGrab: ведуча рука визначає позицію, друга — орієнтацію. XR Interaction Toolkit підтримує це через XRTwoHandGrabInteractable або кастомну логіку з двома Attach Points.

Throw (кидок)

Чому velocity smoothing критичний для реалістичного кидка? Проблема в тому, що Rigidbody.velocity в момент відпускання контролера відображає миттєву швидкість, яка часто некоректна через дискретизацію трекінгу. Користувач робить швидкий рух зап'ястям — а об'єкт летить вдвічі повільніше.

Рішення: velocity smoothing за останні N кадрів (типово 5-10 кадрів, ~80-160 мс при 60 Гц) перед відпусканням. XR Interaction Toolkit робить це через VelocityEstimator. Додатково застосовуємо velocity scaling multiplier — невелике множення швидкості (1.2-1.5x) робить кидки суб'єктивно більш задовільними. Кутову швидкість (для об'єктів, які мають крутитися в польоті) також усереднюємо аналогічним чином.

AR: Plane Tracking та робота з оточенням

AR додає інший клас проблем — роботу з реальним, непередбачуваним оточенням. AR Foundation — кроссплатформенний шар поверх ARKit та ARCore. Більшість базових функцій (plane detection, raycasting, image tracking, face tracking) доступні через єдиний API.

Plane Detection

ARPlaneManager виявляє горизонтальні та вертикальні площини. Практичні нюанси:

  • Ініціалізація займає час — користувач повинен оглянути приміщення, поки система будує карту. Потрібен явний onboarding з інструкцією «повільно водіть камерою по поверхнях».
  • Площини нестабільні — їх межі та позиція оновлюються в міру накопичення даних. Об'єкти, розміщені на площині, потрібно прив'язувати через parenting до ARPlane, а не до світових координат.
  • Злиття площин — два виявлені сегменти підлоги можуть злитися в один, що рухає якір. Для критичних якорів використовуємо ARAnchor замість прямої прив'язки до площини.
Деталі Image Tracking

ARTrackedImageManager — для маркерів. Якість трекінгу безпосередньо залежить від якості reference image. Зображення з високою частотою деталей та контрастними краями (як QR-код, але красиво) трекаються надійніше, ніж гладкі логотипи. ARCore Geospatial API — для outdoor AR з прив'язкою до реальних координат (точність до 10 см у добре картованих зонах).

Оптимізація для VR: фреймрейт та комфорт

VR вимагає стабільного високого фреймрейту. Близько 60% часу розробки в мобільному VR йде на оптимізацію, а не на функціонал — ретрофіт у два рази дорожче правильної архітектури з першого спринту.

Пристрій Цільовий Hz Критичний поріг
Meta Quest 2 72 / 90 Гц < 72 Гц — помітно
Meta Quest 3 90 / 120 Гц < 90 Гц — помітно
Valve Index 90 / 120 / 144 Гц < 90 Гц — помітно
PSVR2 90 / 120 Гц < 90 Гц — помітно

Single Pass Instanced Rendering

Головна оптимізація рендеру у VR. Без неї сцена рендериться двічі (для кожного ока), що подвоює draw calls. Single Pass Instanced рендерить обидва ока за один прохід через instancing: geometry обробляється один раз, шейдер отримує два view/projection matrix через GPU instancing. Вмикається в Unity через XR Plug-in Management > Rendering Mode: Single Pass Instanced. Важно: кастомні шейдери повинні підтримувати SPI — стандартні URP/HDRP шейдери підтримують, кастомні HLSL вимагають правки (UNITY_SETUP_STEREO_EYE_INDEX_POST_VERTEX та пов'язані макроси). Застосування цієї техніки скорочує кількість draw calls на 40-50%.

Foveated Rendering

На Meta Quest доступний Fixed Foveated Rendering (FFR) — зниження роздільної здатності на периферії кадру, де гострота сприйняття нижча. Налаштовується через OVRManager або Meta XR SDK:

OVRManager.fixedFoveatedRenderingLevel = OVRManager.FixedFoveatedRenderingLevel.High;
OVRManager.useDynamicFixedFoveatedRendering = true;

Dynamic FFR автоматично підвищує рівень при просадці фреймрейту — зручніше фіксованого в сценах зі змінним навантаженням.

IPD та Comfort Settings

IPD (Inter-Pupillary Distance) — відстань між зіницями, впливає на сприйняття глибини. На програмованому рівні в більшості пристроїв доступне лише читання IPD (OVRPlugin.GetSystemDisplayFrequency), фізичне налаштування — на гарнітурі. Для додатків з точним позиціонуванням (медичні симулятори, тренінги) враховуємо IPD у розрахунках масштабу сцени.

Haptics

Тактильний фідбек — недооцінений інструмент. Навіть простий вібраційний відгук при захопленні об'єкта або попаданні значно підвищує відчуття присутності. В середньому інтеграція тактильних патернів займає 30–80 годин на проєкт.

XR Haptics через OpenXR:

var hapticImpulse = new UnityEngine.XR.HapticCapabilities();
InputDevice device = InputDevices.GetDeviceAtXRNode(XRNode.RightHand);
device.SendHapticImpulse(0, amplitude: 0.5f, duration: 0.1f);

Для складних патернів (тактильна «текстура» поверхні при дотику, наростаюча вібрація при натягу тятиви лука) використовуємо Meta Haptics Studio — дозволяє дизайнити haptic-кліпи візуально.

Що входить у розробку VR/AR-додатку

При замовленні проєкту під ключ ми надаємо:

  • Архітектурний документ з описом стеку, логіки рендеру та системи взаємодії
  • Робочий прототип (MVP) для тестування на цільовому пристрої
  • Інтеграцію необхідних SDK (Meta XR, OpenXR, AR Foundation та ін.)
  • Оптимізацію під цільові частоти 72/90/120 Гц з профілюванням draw calls та FPS
  • Тестування на фізичному обладнанні (Quest, SteamVR, HoloLens) із залученням користувачів
  • Повну документацію по збірці, деплою та підтримці
  • Навчання команди замовника (воркшоп по роботі з XR Toolkit)
  • Гарантійну підтримку протягом 1 місяця після здачі

Що впливає на вартість та терміни

VR/AR проєкти дорожчі за звичайні ігри аналогічного обсягу. Ітерації повільніші — кожну правку потрібно тестувати в гарнітурі, емулятор не передає реальний досвід. Motion sickness змушує переробляти частину концептуальних рішень після першого плейтесту. Оптимізація займає суттєву частку часу — для мобільного VR (Quest) до 60-70% циклу. Для проєктів під Quest починаємо оптимізацію з першого спринту.

Отримайте консультацію по вашому проєкту — оцінимо задачу, стек та терміни. Замовте розробку VR/AR-додатку під ключ з гарантією стабільного фреймрейту.