Скелетна анімація в іграх. Огляд технік і ресурсів

Anima — це душа, що відрізняє живе від мертвого. Аристотелевская душа — це принцип руху, що проявляється у чотирьох видах: переміщення, перетворення, спадання і зростання. Через майже дві з половиною тисячі років ми використовуємо ті ж категорії в комп'ютерній графіці. Скелетна анімація визначає переміщення, морфінг служить для перетворень, а спадання і зростання це звичайне масштабування. Анімована графіка оживляє образ, вдихає в картинку душу, і це, на мій погляд, навіть важливіше, ніж достовірна гра світла і тіні.

image

Створення якісних скелетних 3D-анімацій сьогодні, мабуть, найбільш важкодоступна для розробників інді завдання. Ймовірно тому так мало інді ігор в 3D, і так багато проектів в стилі піксель-арту або примітивізму, а також бродилок без персонажів у кадрі. Але тепер це співвідношення може змінитися…

Спробуйте порахувати кількість різноманітних анімацій в Uncharted 4. За моїми оцінками там близько години унікальних рухів, не рахуючи лицьовій анімації (850 виразів за словами авторів). Подібні ігри задають фантастичну планку якості.



Приклади анімації Uncharted 4 (>40мб GIF)



Якщо фізичний рендеринг і створення якісно освітлених статичних сцен стають доступні ентузіастам завдяки потужним безкоштовним ігровим движкам та інструментів 3D-моделювання, створення хорошої анімації вимагає обладнання для захоплення рухів і тривалої кропіткої роботи по їх впровадженню. Одна з найбільш доступних систем це костюм neuronmocap вартістю близько $1.5 до без урахування доставки.

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

Все це я згадую для того, щоб оцінити по достоїнству щедрий подарунок від Mixamo. Він буквально відкриває двері на новий рівень для незалежних розробників: компанія Adobe купила Mixamo, і тепер 2.5 тисячі скелетних анімацій для персонажів вони віддають абсолютно безкоштовно "for unlimited commercial or non commercial use":
www.mixamo.com

Ще пів року тому можна було отримати лише виклавши близько $36 000 (ну або спиратив в мережі). Крім анімацій компанія також пропонує безкоштовну версію інструменту для ригинга і скининга персонажів, інструмент для створення множинних рівнів деталізації з мінімальними втратами якості (LOD), генератор персонажів і плагін для захоплення лицьовій анімації.

Приклад анімації Mixamo

Існують і не менш опрацьовані набори анімацій, доступні для придбання ентузіастами. Але такий гігантський і якісний набір вперше виявився доступний абсолютно безкоштовно. Ще одним непоганим джерелом кліпів залишається база анімацій Університету Карнегі — Меллон і її адаптована під Unity версія, проте якість і зміст цієї бази не так гарні.

Крім ручної кадрової анімації та захоплення руху актора, існують і цікаві процедурні методи симуляції рухів: еволюційне моделювання, нейронні мережі, task based locomotion. Що цікаво, на конференції SIGGRAPH 2016 цим непростим технікам приділяють багато уваги. Але широким колам незалежних розробників ці речі поки не доступні, і мені самому хотілося б більше дізнатися про можливість їх реального застосування. Однак сьогодні є і доступні інструменти, симулюють м'язову динаміку (Euphoria Engine і Puppet Master для Unity3d), які дозволяють привнести різноманітні реакції персонажів на обставини.







Отримати якісні та різноманітні анімаційні кліпи це тільки перша частина завдання.
Друга частина полягає в тому, щоб коректно використовувати отримані анімації при управлінні персонажем. Для цього спочатку потрібно вирішити, як взагалі зрушувати персонажа на сцені: на підставі даних самої анімації (1), або на підставі якихось інших міркувань (наприклад, фізики твердого тіла) (2). Тобто, або анімація буде обчислюватися виходячи з довільного (фізичної) руху об'єкта в просторі (2), або сама зміщення в просторі буде виходити з записаної анімації, ігноруючи інші втручання (1).

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

Одним з яскравих прикладів може бути гра Guild Wars 2 де анімація рухів і графіка вже досить гарні, але от великий діапазон можливих швидкостей і напрямків руху персонажа не забезпечений настільки ж великим набором анімації, і персонажі або буксують на місці, або стрибок вперед як по льоду. Та ж проблема довгий час переслідує і ігри на движку Gamebryo (серія TES: Morrowind, Skyrim), та й багато інші.



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

Тому для досягнення реалізму нам у будь-якому разі потрібно гігантський набір різноманітних кліпів з рухами в різних напрямках, з різною швидкістю, і т.п… Крім того, анімаційні кліпи рідко можна використовувати ізольовано, відтворюючи один за іншим. Частіше всього в грі присутня безліч анімацій, між якими не заготовлено спеціальних анімованих переходів. Тому для їх симуляції застосовується плавне змішування через лінійну інтерполяцію поворотів кісток. Для зручного налаштування таких переходів використовується т. зв. кінцевий автомат або машина станів (State machine). У UE і Unity для цього є спеціальні інструменти: Persona і Mecanim. Кожен вузол там це деякий стан скелетної моделі (заготовлений анімаційний кліп або результат їх змішування — Blend Tree). Коли виконані деякі задані умови, здійснюється плавний перехід з одного стану в інше, під час якого обидва надають пропорційне часу вплив на повороти кісток і зміщення об'єкта. Таким чином досягається ілюзія безперервності руху.

Стан може бути не поодиноким кліпом, а змішаним за тим же принципом набором кліпів (Blend Tree / Blend Space). Наприклад кліпів рухів персонажа в сторони можна вибрати декілька, змішавши їх пропорційно вектору бажаного руху, і отримати рух під будь-яким довільним кутом. Однак існують такі анімації, для яких змішування обертається некоректними позами. Наприклад, коли одна анімація рухає ноги персонажа вперед, а інша вбік, лінійне змішування може призвести до перетину ніг один з одним. Щоб цього уникнути потрібно ретельно підбирати анімаційні кліпи, синхронізувати їх фазу, довжину і швидкість, або додавати окремий кліп спеціально для даного виду рухів. Все це складна і копітка робота. І чим більше можливих станів та переходів між ними, тим важче привести їх у відповідність один з одним, і простежити за тим, щоб всі потрібні переходи спрацьовували коли це потрібно.

2-D змішування анімацій руху

1) Найбільш очевидним рішенням є захоплення рухів реального актора за допомогою Motion Capture і прив'язка зміщення персонажа в грі до зміщення «кореневої кістки» в самій анімації — принцип Root Motion. Тоді персонаж буде рухатися рівно так, як рухався актор під час запису.

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

Але цей підхід несе в собі очевидні проблеми.

Припустимо, персонаж хоче посунутися до краю обриву: актор запису нахиляється, піднімає ногу і робить сміливий широкий крок по сцені. А персонаж крокує прямо в прірву… Щоб цього уникнути, потрібно перервати крок десь посередині, але це не тільки виглядає неприродно, але і ускладнює гравцеві вибір потрібного моменту з-за нелінійності руху, в якому може бути довга підготовка (нахил), а потім різке впевнений рух (крок). Можна записати декілька варіантів рухів. Припустимо: обережні маленькі кроки, нормальні, і біг. А потім змішати їх по параметру необхідної швидкості, який можна збільшувати лінійно і передбачувано. Але що якщо нам потрібні рухи в сторони? Значить для кожного варіанту ширини кроку нам потрібні ще три-чотири варіанти (за вирахуванням дзеркальних). А ще персонаж повинен вміти повертати під час руху. Значить для кожного варіанту нам потрібні руху з поворотом. А якщо поворот може бути швидким і повільним? Значить ще раз множимо число необхідних кліпів на два. А тепер нам потрібно рух по похилій поверхні! А потім нам захочеться, щоб персонаж вмів робити теж саме вприсяди. Разом — просто сотні і тисячі варіантів анімації які потрібно змішувати і стежити за тим, щоб це відбувалося коректно і призводило до рухів з потрібною швидкістю. І все одно, у багатьох випадках управління буде відчуватися як «ватяну», оскільки інерція актора і наша неможливість передбачити всі можливі людські маневри буде позбавляти гравця контролю над персонажем. Цю проблему, до речі, відчули на собі гравці в The Witcher 3, тому в одному з великих оновлень, розробники впровадили альтернативний варіант управління, де анімація швидше відгукується на управління в збиток реалізму. У шутерах ж проблема нелінійності руху набуває особливо виражений характер: гравцеві часто доводиться визирати з-за рогу і швидко йти назад, і момент різкої зміни напрямку може дуже відрізнятися — гравцеві потрібно якомога швидше повернутися назад за укриття, а у нас немає можливості передбачити заздалегідь, якої ширини крок він планував і програти відповідну анімацію. Гравцеві, у свою чергу, буде важко звикнути до ширині кроку, яку робить його персонаж, і до швидкості цього кроку, щоб перервати його вчасно.

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

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

З останніх помітних проектів, що використовують Root Motion, можна виділити The Witcher 3. Важко переоцінити зусилля, вкладені у виробництво всіх його рухів.

Приклад анімації The Witcher 3 та її зйомкиАктор виконує руху відьмака

Кадри з гри Відьмак 3

2) Інше рішення назад принципом Root Motion — потрібно приводити анімацію в найбільш точну відповідність з подією або планованим рухом. Тоді багато описані вище проблеми вирішуються — рух персонажа можна зробити рівноприскореним і передбачуваним з можливістю скільки завгодно швидкої зміни напряму. Але як привести нелінійну та інерційну анімацію у відповідність з таким рухом? Цікавий комплексний підхід описали розробники гри Paragon. Суть його полягає в тому, щоб знаходити і програвати тільки потрібну серію кадрів анімації для досягнення необхідного зсуву/повороту, пропускаючи зайві. І використовувати инверсную кінематику для модифікації ширини кроку.



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

Але, на жаль, цей метод досить сильно порушує звичний підхід до анимированию, і тому я не зміг знайти простого способу реалізувати його, наприклад, з використанням стандартного анімаційного компонента Unity. В Unreal Engine також поки немає необхідного функціоналу, проте розробники обещают коли-небудь перенести низькорівневі напрацювання, зроблені для Paragon, у загальнодоступну версію движка. Основною складністю є пошук і відтворення потрібного кадру на підставі даних про фактичне зміщення й повороті. Для цього автори пропонують робити пре-процесинг анімаційних кліпів і генерувати для кожного з них додатковий блок даних: Distance Curve, в якому буде збережено покадрово значення зсуву і повороту кореневої кістки відносно початку або кінця анімації. Потім, в ході вибірки, можна проводити швидкий бінарний пошук потрібного кадру, де досягнуті відповідні параметри зсуву і повороту, і відтворювати його.

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.