Анима – это душа, отличающая живых от мертвых.
Аристотелевская душа – это принцип движения, проявляющийся в четырех видах: движении, преобразовании, уменьшении и увеличении.
Почти две с половиной тысячи лет спустя мы используем те же категории в компьютерной графике.
Скелетная анимация определяет движение, морфинг используется для трансформаций, а уменьшение и увеличение — обычное масштабирование.
Анимированная графика оживляет изображение, вдыхает в картину душу, а это, на мой взгляд, даже важнее, чем достоверная игра света и тени.
Создание высококачественной скелетной 3D-анимации — пожалуй, самая сложная задача для инди-разработчиков сегодня.
Наверное, поэтому так мало инди-игр в 3D, и так много проектов в стилях пиксель-арт или примитивизм, а также приключенческих игр без персонажей в кадре.
Но теперь это соотношение может измениться.
Попробуйте посчитать количество различных анимаций в Uncharted 4. По моим прикидкам, там около часа уникальных движений, не считая лицевой анимации( 850 выражений по мнению авторов).
Подобные игры устанавливают фантастические стандарты качества.
Примеры анимации Uncharted 4 (> 40 МБ GIF) 
В то время как физический рендеринг и создание хорошо освещенных статичных сцен становятся доступными энтузиастам благодаря мощным бесплатным игровым движкам и инструментам 3D-моделирования, создание хорошей анимации требует оборудования для захвата движений и большой кропотливой работы по их реализации.
Одной из самых доступных систем является костюм.
нейронмокап Стоимость около 1,5 тысяч долларов без учета доставки.
Я не смог найти примеров создания анимации хотя бы близкого к этому уровню с использованием ручного покадрового подхода или какой-либо процедурной анимации.
Максимум, что можно сделать вручную, на мой взгляд, это простые удары, быстрые движения и стилизованная мультяшная анимация.
Но как сделать реалистичную ходьбу по лестнице, где столько деталей, связанных с переносным центром тяжести и балансом тела? Воспроизвести их все вручную невозможно.
Может я ошибаюсь, и покажет ли кто-нибудь работу специалистов такого уровня?.
Я вспоминаю все это, чтобы оценить щедрый подарок от Миксамо .
Это буквально открывает дверь на новый уровень для независимых разработчиков: компания Adobe купил Mixamo, а теперь совершенно бесплатно раздают 2,5 тысячи скелетных анимаций для персонажей" для неограниченного коммерческого или некоммерческого использования ": www.mixamo.com Всего полгода назад их можно было получить, всего лишь выложив около 36 000 долларов (ну или продав через Интернет).
Помимо анимации, компания также предлагает бесплатную версию инструмента для оснащения и скининга персонажей, инструмент для создания нескольких уровней детализации с минимальной потерей качества (LOD), генератор персонажей и плагин для захвата лицевой анимации.
Есть не меньше тщательно продуманные наборы анимаций , доступен для покупки энтузиастам.
Но впервые такой гигантский и качественный набор был доступен совершенно бесплатно.
Остается еще один хороший источник клипов база данных анимации Университет Карнеги-Меллон и его версия адаптирована для Unity Однако качество и содержание этой базы данных не очень хорошие.
Помимо ручной покадровой анимации и захвата движений актера, существуют еще интересные процедурные методы имитации движений: эволюционное моделирование , нейронные сети , передвижение, основанное на задачах .
Интересно, что на конференции SIGGRAPH 2016 этим непростым техникам уделяется очень много внимания.
Но эти вещи пока недоступны широкому кругу независимых разработчиков, и мне самому хотелось бы узнать больше о возможности их реального применения.
Однако сегодня доступны инструменты, моделирующие мышечную динамику ( Эйфория Двигатель И Хозяин Марионеток для Unity3d), которые позволяют ввести разнообразные реакции персонажей на обстоятельства.
Получить качественные и разнообразные анимационные ролики – это только первая часть задачи.
Вторая часть — правильно использовать полученные анимации при управлении персонажем.
Для этого сначала нужно решить, как вообще перемещать персонажа в сцене: на основе данных самой анимации (1), или исходя из каких-то других соображений (например, физики твердого состояния) (2).
То есть либо анимация будет рассчитываться на основе произвольного (физического) перемещения объекта в пространстве (2), либо само перемещение в пространстве будет исходить из записанной анимации, игнорируя другие вмешательства (1).
Оба подхода имеют преимущества и недостатки.
В прежние времена, до широкого распространения захвата движений, об этом почти не могло быть и речи — персонажи двигались процедурно, основываясь на каких-то простых принципах, а анимационные ролики просто воспроизводились, чтобы хоть как-то соответствовать этому движению.
Но чем лучше становилась анимация и графика в целом, тем заметнее становилось несоответствие движения ног смещению персонажа, а также неестественность динамики движений.
Ярким примером может служить игра Guild Wars 2, где анимация движения и графика уже достаточно хороши, но широкий диапазон возможных скоростей и направлений движения персонажей не обеспечивается столь же большим набором анимаций, и персонажи либо буксуют, либо скользят. на месте или скользить вперед, как по льду.
Такая же проблема уже давно мучает игры на движке Gamebryo (серии TES: Morrowind, Skyrim) и многие другие.
Реальное движение человека нелинейно – сначала мы наклоняемся вперед, затем выбрасываем ногу и только потом начинаем двигаться, быстро ускоряясь после касания ступней земли, и двигаясь по инерции до следующего шага.
Найти функцию, точно описывающую такое движение, сложно, и редко кто об этом даже задумывается.
Что уж говорить о более сложных движениях – стрейфе, переходах между направлениями, торможениях и поворотах.
Поэтому для достижения реалистичности нам в любом случае понадобится гигантский набор разнообразных роликов с движениями в разных направлениях, с разной скоростью и т. д. Кроме того, анимационные ролики редко можно использовать изолированно, проигрывая один за другим.
Чаще всего в игре много анимаций, между которыми нет специальных анимированных переходов.
Поэтому для их моделирования используется плавное смешивание посредством линейной интерполяции поворотов костей.
Для удобной настройки таких переходов используется так называемый конечный автомат или State Machine. У UE и Unity для этого есть специальные инструменты: Персона И Меканим .
В каждом узле находится определенное состояние скелетной модели (подготовленный анимационный ролик или результат их смешивания — Blend Tree).
При выполнении определенных заданных условий происходит плавный переход из одного состояния в другое, во время которого оба оказывают пропорциональное во времени воздействие на вращение костей и перемещение объекта.
Таким образом достигается иллюзия непрерывности движения.
Состоянием может быть не один клип, а набор клипов, смешанных по одному и тому же принципу (Blend Tree/Blend Space).
Например, вы можете выбрать несколько клипов боковых движений персонажа, смешав их пропорционально вектору нужного движения, и получить движение под любым произвольным углом.
Однако существуют анимации, в которых смешивание приводит к неправильным позам.
Например, когда одна анимация перемещает ноги персонажа вперед, а другая — в сторону, линейное смешивание может привести к тому, что ноги пересекутся друг с другом.
Чтобы этого избежать, нужно тщательно подбирать анимационные ролики, синхронизировать их фазу, длину и скорость или добавлять отдельный клип специально для этого типа движения.
Все это сложная и кропотливая работа.
И чем больше возможных состояний и переходов между ними, тем сложнее их согласовать друг с другом и обеспечить срабатывание всех необходимых переходов, когда это потребуется.
1) Самое очевидное решение — захватить движения реального актера с помощью Motion Capture и связать перемещение персонажа в игре со смещением «корневой кости» в самой анимации — принцип Root Motion. Тогда персонаж будет двигаться точно так же, как двигался актер во время записи.
Выглядит очень реалистично.
Более того, это единственный способ достоверно воспроизвести сложные маневры, такие как выпады, уклонение и парирование атак оружием ближнего боя.
Но этот подход также создает очевидные проблемы.
Допустим, персонаж хочет двинуться к краю обрыва: актер в записи наклоняется, поднимает ногу и делает смелый, длинный шаг по сцене.
И персонаж шагает прямо в пропасть.
Чтобы этого избежать, нужно прервать шаг где-то посередине, но это не только выглядит неестественно, но и затрудняет выбор игроком правильного момента из-за не -линейность движения, что может потребовать длительной подготовки (наклон), а затем резкого уверенного движения (шага).
Вы можете записать несколько вариантов движения.
Скажем так: осторожные маленькие шаги, нормальный и бег.
А затем смешать их по необходимому параметру скорости, который можно увеличивать линейно и предсказуемо.
Но что, если нам нужны боковые движения? Это значит, что на каждый вариант ширины шага нам понадобится еще три-четыре варианта (без зеркальных).
И персонаж должен иметь возможность поворачиваться во время движения.
Это значит, что для каждого варианта нам нужны движения с поворотом.
Что, если поворот может быть быстрым или медленным? Итак, мы еще раз умножаем количество необходимых роликов на два.
Теперь нам нужно движение по наклонной поверхности! И затем мы хотим, чтобы персонаж мог делать то же самое, сидя на корточках.
Итого — всего лишь сотни и тысячи вариантов анимации, которые нужно смешивать и следить за тем, чтобы это происходило правильно и приводило к движениям с нужной скоростью.
И все же во многих случаях управление будет ощущаться «шатким», поскольку инерция актера и наша неспособность предвидеть все возможные человеческие маневры лишат игрока контроля над персонажем.
С этой проблемой, кстати, столкнулись игроки в «Ведьмаке 3», поэтому в одном из крупных обновлений разработчики представили альтернативный вариант управления, при котором анимация быстрее реагирует на управление в ущерб реалистичности.
В шутерах особенно остро становится проблема нелинейного движения: игроку часто приходится заглядывать за угол и быстро возвращаться назад, а момент резкой смены направления может быть самым разным — игроку нужно как можно скорее вернуться за укрытие.
насколько это возможно, и у нас нет возможности заранее предсказать, какую ширину шага он запланировал, и воспроизвести соответствующую анимацию.
Игроку, в свою очередь, будет сложно привыкнуть к ширине шага своего персонажа и скорости этого шага, чтобы вовремя его прервать.
Во-вторых, Root Motion не подходит для онлайн-игр.
Нелинейное движение не только затрудняет игроку прогнозирование скорости, но и лишает нас возможности интерполировать и экстраполировать движение для компенсации задержки в сети, что является очень важным и сложным аспектом в быстрых онлайн-играх.
Если перемещение персонажа задается только анимацией, то сложно аналитически подобрать необходимые параметры конечного автомата (смешивая разные анимации), которые приведут к тому, что персонаж будет двигаться именно в нужном нам направлении и именно с той скоростью, которая нам нужна ( выбрано для компенсации несоответствия).
Если сделать наоборот, чтобы анимация была ориентирована на реальное движение, то при исправлении несоответствия между сервером и клиентом будет легко подобрать наиболее подходящую анимацию, даже если она немного не соответствует реальной.
смещения, этого почти никто не заметит. Поэтому техника Root Motion часто используется в одиночных играх от третьего лица, где управление осуществляется контекстуально — в зависимости от наличия укрытий, препятствий, режима движения или других обстоятельств, и редко используется в сетевом режиме и MMOG. Среди последних заметных проектов с использованием Root Motion: Ведьмак 3 .
Трудно переоценить усилия, вложенные в создание всех его движений.
Пример анимации Ведьмака 3 и ее стрельбы 
2) Другое решение противоположно принципу Root Motion — нужно привести анимацию в максимально точное соответствие произошедшему или запланированному движению.
Тогда решаются многие описанные выше проблемы — движение персонажа можно сделать равномерно ускоренным и предсказуемым с возможностью сколь угодно быстро менять направление.
Но как можно привести в соответствие такому движению нелинейную и инерционную анимацию? Разработчики игры Paragon описали интересный комплексный подход. Его суть в том, чтобы найти и воспроизвести только необходимую серию кадров анимации для достижения необходимого смещения/поворота, пропуская лишние.
И используйте обратную кинематику для изменения ширины шага.
Первая очевидная трудность при сопоставлении анимации с движением заключается в том, что движение уже произошло, а анимация еще не разыгралась.
Поэтому очень полезна система прогнозирования движения, которая вычисляет положение персонажа для следующего кадра.
Затем, зная смещение, которое персонаж должен совершить в следующем кадре, нужно пропустить столько кадров анимационного клипа движения, сколько необходимо для достижения требуемого смещения, и воспроизвести тот кадр, на котором требуемое смещение достигается.
В этом случае анимация будет воспроизводиться с измененной скоростью, чтобы точно соответствовать фактическому перемещению, и эта скорость может быть быстрее или медленнее исходной, поскольку невозможно заставить реального актера поддерживать постоянное ускорение или скорость.
Такой подход позволит сгладить анимацию и привести ее в соответствие с любой сложной процедурной моделью движения, которая меняется в процессе игры (персонаж может выпить какое-то зелье ускорения или быть замедлен врагом).
Обратной стороной, конечно, является то, что анимация может стать менее реалистичной из-за больших изменений скорости.
Однако на практике это дает очень хорошее окно доступных вариаций, в котором нарушения скорости не заметны.
А в сочетании с регулировкой ширины шага с использованием обратной кинематики он охватывает еще больший диапазон.
Но, к сожалению, этот метод довольно сильно ломает привычный подход к анимации, и поэтому мне не удалось найти простой способ его реализации, например, с помощью стандартного анимационного компонента Unity. Unreal Engine также пока не имеет необходимого функционала, но разработчики обещать когда-нибудь перенесу низкоуровневые наработки, сделанные для Paragon, на публичную версию движка.
Основная сложность — найти и воспроизвести нужный кадр на основе реальных данных смещения и вращения.
Для этого авторы предлагают предварительно обработать анимационные ролики и сгенерировать для каждого из них дополнительный блок данных: Distance Curve, в котором будут значения смещения и поворота корневой кости относительно начала или конца анимации.
сохраняться покадрово.
Затем во время семплирования можно выполнить быстрый бинарный поиск нужного кадра, где достигнуты соответствующие параметры смещения и вращения, и воспроизвести его.
Пока можно ограничиться предыдущим подходом и сделать менее точную подстройку скорости анимации под скорость планируемого движения, ориентируясь только на скорость персонажа на последнем кадре.
Самое главное, что теперь есть хороший набор душ для экспериментов! Теги: #unity3d #анимация #государственная машина #gamedev #Разработка игр #unity #unreal engine
-
Teforia – «Умный» Чайник
19 Oct, 24 -
Бесплатная Регистрация Доменного Имени
19 Oct, 24 -
Как Инженеру Выбрать Работу?
19 Oct, 24 -
Мониторинг Мозга
19 Oct, 24 -
Zfconf-2010: Финальная Регистрация
19 Oct, 24 -
Установка Клиента Datastage
19 Oct, 24 -
Jingle Стал Базовым Протоколом Gtalk.
19 Oct, 24
