Зазначимо: коли ми отримуємо скульпт із ZBrush або Nomad, він виходить із 2–5 мільйонами полігонів. У мобільну гру потрібно 3–8 тисяч. Просто задецимувати через Decimate Modifier у Blender або ZRemesher — не варіант: автоматичні інструменти не думають про анімацію, про UV-розгортку і про те, як меш деформуватиметься під скінінгом. У нещодавньому проєкті для мобільної RPG на Unity (збірка під Android) ми отримали скульпт персонажа з 3.2 млн полігонів. Після ручної ретопології він важив 7 800 трикутників, а всі blend shapes (32 шт.) працювали без артефактів. Ітерації анімації скоротилися на 40%, а вартість доробок на етапі rig — на 30% від бюджету проєкту. Ретопологія персонажів — ключовий етап оптимізації 3D-моделей для мобільних ігор, що робить ассети game-ready та економить ресурси команди.
Чому автоматична ретопологія не підходить для анімації?
ZRemesher та Instant Meshes дають квадратний меш, але не створюють правильних edge loops. На персонажі loops повинні огинати рот, очниці, суглоби — за анатомією, а не за рівномірною сіткою. Якщо edge loop перетинає куточок рота неправильно — при анімації з'являються складки або розриви.
Для мобільного VR на Quest особливо критичні суглоби: плече, лікоть, коліно, зап'ястя. Тут потрібні loops, паралельні осі обертання кістки — це дає правильний розподіл деформації при ваговій розмальовці. Типова помилка після ZRemesher — діагональні loops на лікті, які при згині руки дають трикутні артефакти навіть при хорошому скінінгу. Ручна ретопологія виконується в 3-5 разів якісніше за будь-яку автоматику для анімаційних зон.
Decimation Master у ZBrush зберігає форму краще, але виробляє трикутний меш. Трикутний меш не можна нормально текстурувати через UV-seam без артефактів, і з ним складно працювати при подальших правках. Годиться тільки як проміжний крок для запікання, не для фінального game-ready ассета.
Як розподілити полігональний бюджет по зонах?
Процес починається з визначення полігонального бюджету по зонах. Типовий розподіл для VR-персонажа під Quest:
- Голова + шия: 2000–3000 трикутників (близько 30%)
- Торс: 1500–2500 (20%)
- Руки (кисті — найбільш ресурсоємні): 1500–2000 (20%)
- Ноги: 1000–2000 (15%)
- Другорядні деталі (одяг, аксесуари): залишок бюджету (15%)
Інструменти: RetopoFlow для Blender (найкращий варіант для ручної ретопології з магнітом до поверхні), Maya Quad Draw для тих, хто в Maya-пайплайні. У ZBrush — ZSphere retopology як альтернатива, але повільніше. RetopoFlow у 2 рази швидше Maya Quad Draw для складних персонажів.
Ключові принципи, які порушуються найчастіше:
- Немає трикутників і N-гонів у зонах деформації. Тільки квади. Трикутники допустимі в статичних зонах: підошва, задня частина шиї, нерухомі елементи.
- Edge loops на ротовій щілині та повіках — не стилістичний вибір, це вимога: без них blend shapes для міміки не працюють коректно.
- Щільність сітки адаптивна: на обличчі — вища, на спині — нижча. Рівномірна сітка — ознака автоматики.
Після ретопології — bake normal map з high-poly на low-poly у Marmoset Toolbag або Substance Painter. Це повертає візуальну деталізацію оригіналу без полігональної вартості.
Типові помилки при ретопології
- Використання трикутників у зонах деформації (суглоби, обличчя) — веде до артефактів при анімації.
- Рівномірна щільність сітки по всій моделі — перевитрата полігонів на неанімованих ділянках та нестача на анімованих.
- Edge loops, що не відповідають анатомії — неправильний розподіл деформації.
Що входить у роботу: етапи та deliverables
Ми виконуємо ретопологію в кілька етапів:
- Аналіз скульпту — визначаємо зони анімації, бюджет та складність.
- Ретопологія — будуємо low-poly сітку з правильними edge loops під скінінг.
- Запікання — створюємо normal map, ambient occlusion та інші карти.
- Перевірка — тестуємо деформацію в Unity/Unreal, виправляємо артефакти.
- Здача — передаємо фінальний ассет у FBX/glTF з UV-розгорткою та текстурами.
Ми гарантуємо відсутність трикутників у рухомих зонах та коректну роботу blend shapes. Досвід наших інженерів — понад 5 років у мобільному геймдеві та VR. Інвестиція в ретопологію окупається за рахунок скорочення часу на налагодження анімації — в середньому команди економлять 30% бюджету на етапі rig. Вартість послуги розраховується індивідуально після аналізу скульпту.
Зв'яжіться з нами для оцінки вашого проєкту — надішлемо точні терміни та вартість. Замовте ретопологію та отримайте консультацію з оптимізації ассетів.
Орієнтовні терміни ретопології
| Об'єкт |
Орієнтовні терміни |
| Голова персонажа (тільки голова) |
4–8 годин |
| Повний персонаж гуманоїд |
1–3 робочі дні |
| Персонаж з одягом та аксесуарами |
3–5 робочих днів |
| Складний prop / транспорт |
1–4 робочі дні |
Порівняння інструментів ретопології
| Інструмент |
Тип |
Швидкість |
Якість під анімацію |
| RetopoFlow (Blender) |
Напівручний |
Висока |
Відмінна |
| Maya Quad Draw |
Ручний |
Середня |
Відмінна |
| ZSphere (ZBrush) |
Ручний |
Низька |
Хороша |
| ZRemesher |
Автоматичний |
Висока |
Погана |
Терміни залежать від складності оригінальної скульптури, кількості анімованих зон та вимог до UV. Вартість розраховується індивідуально.
Джерело: Ретопологія — Вікіпедія
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. Базова реалізація працює «з коробки», але для продакшну доопрацьовуємо її в чотири кроки:
- Налаштування
XRRayInteractor з вигнутим променем (Bend Ray) — дуга телепортації виглядає натуральніше прямого променя, краще зчитується користувачами.
- Додавання валідної зони приземлення — візуальний індикатор змінює колір при наведенні на перешкоду (червоний/зелений).
- Впровадження fade transition — плавне згасання екрану (black fade) перед телепортом знижує дезорієнтацію.
- 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-додатку під ключ з гарантією стабільного фреймрейту.