Anima - это душа, отличающая живое от мертвого. Аристотелевская душа - это принцип движения, проявляющегося в четырёх видах: перемещение, превращение, убывание и возрастание. Спустя почти две с половиной тысячи лет мы используем те же категории в компьютерной графике. Скелетная анимация определяет перемещение, морфинг служит для превращений, а убывание и возрастание это обычное масштабирование. Анимированная графика оживляет образ, вдыхает в картинку душу, и это, на мой взгляд, даже важнее, чем достоверная игра света и тени.
Создание качественных скелетных 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), генератор персонажей и плагин для захвата лицевой анимации.
Получить качественные и разнообразные анимационные клипы это только первая часть задачи.
Вторая часть заключается в том, чтобы корректно использовать полученные анимации при управлении персонажем. Для этого сначала нужно решить, как вообще сдвигать персонажа в сцене: на основании данных самой анимации (1), либо на основании каких-то иных соображений (например физики твердого тела) (2). То есть, либо анимация будет вычисляться исходя из произвольного (физического) движения объекта в пространстве (2), либо само смещение в пространстве будет исходить из записанной анимации, игнорируя иные вмешательства (1).
У обоих подходов есть достоинства и недостатки. В прежние времена, до массового использования захвата движений, вопрос об этом почти не стоял - персонажи двигались процедурно, на основании каких-то простых принципов, а анимационные клипы просто проигрывались для некоторого соответствия этому движению. Но чем лучше становилась анимация и графика в целом, тем заметнее становилось несоответствие движения ног и смещения персонажа, а также неестветсвенность динамики движения.
Одним из ярких примеров может быть игра Guild Wars 2 где анимация движений и графика уже достаточно хороши, но вот большой диапазон возможных скоростей и направлений движения персонажа не обеспечен столь же большим набором анимаций, и персонажи либо буксуют на месте, либо проскальзывают вперед как по льду. Та же проблема долгое время преследует и игры на движке Gamebryo (серия TES: Morrowind, Skyrim), да и многие другие.
Настоящее движение человека нелинейно - сначала мы наклоняемся вперед, затем выбрасываем ногу, и только потом начинаем движение, быстро ускоряясь после соприкосновения стопы с землей, и двигаемся по инерции до следующего шага. Подобрать функцию, точно описывающую подобное движение, сложно, и редко кто вообще об этом задумывается. Что уж говорить о более сложных движениях - стрейфе, переходах между направлениями, торможением и поворотами.
Поэтому для достижения реализма нам в любом случае потребуется гигантский набор разнообразных клипов с движениями в различных направлениях, с различной скоростью, и т.п… Кроме того, анимационные клипы редко можно использовать изолированно, воспроизводя один за другим. Чаще всего в игре присутствует множество анимаций, между которыми не заготовлено специальных анимированных переходов. Поэтому для их симуляции применяется плавное смешивание через линейную интерполяцию поворотов костей. Для удобной настройки таких переходов используется т.н. конечный автомат или машина состояний (State machine). В UE и Unity для этого есть специальные инструменты: Persona и Mecanim . Каждый узел там это некоторое состояние скелетной модели (заготовленный анимационный клип или результат их смешения - Blend Tree). Когда выполнены некоторые заданные условия, осуществляется плавный переход из одного состояния в другое, во время которого оба оказывают пропорциональное времени влияние на повороты костей и смещение объекта. Таким образом достигается иллюзия непрерывности движения.
Состояние может быть не одиночным клипом, а смешанным по тому же принципу набором клипов (Blend Tree / Blend Space). Например из клипов движений персонажа в стороны можно выбрать несколько, смешав их пропорционально вектору желаемого движения, и получить движение под любым произвольным углом. Однако существуют такие анимации, для которых смешивание оборачивается некорректными позами. Например когда одна анимация двигает ноги персонажа вперед, а другая вбок, линейное смешивание может привести к пересечению ног друг с другом. Чтобы этого избежать нужно тщательно подбирать анимационные клипы, синхронизировать их фазу, длину и скорость, либо добавлять отдельный клип специально для данного вида движений. Все это сложная и кропотливая работа. И чем больше возможных состояний и переходов между ними, тем сложнее привести их в согласие друг с другом, и проследить за тем, чтобы все нужные переходы срабатывали когда это требуется.
1) Самым очевидным решением является захват движений реального актера при помощи Motion Capture и привязка смещения персонажа в игре к смещению «корневой кости» в самой анимации - принцип Root Motion. Тогда персонаж будет двигаться ровно так, как двигался актер во время записи.
Выглядит очень реалистично. Более того, это единственный способ достоверно воспроизвести сложные маневры вроде выпадов, уворотов и паррирования атак холодным оружием.
Но этот подход несет в себе и очевидные проблемы.
Допустим, персонаж хочет подвинуться к краю обрыва: актер на записи наклоняется, поднимает ногу и делает смелый широкий шаг по сцене. А персонаж шагает прямо в пропасть… Чтобы этого избежать, нужно прервать шаг где-то посередине, но это не только выглядит неестественно, но и затрудняет игроку выбор нужного момента из-за нелинейности движения, в котором может быть долгая подготовка (наклон), а затем резкое уверенное движение (шаг). Можно записать несколько вариантов движений. Допустим: осторожные маленькие шаги, нормальные, и бег. А затем смешать их по параметру требуемой скорости, который можно увеличивать линейно и предсказуемо. Но что если нам нужны движения в стороны? Значит для каждого варианта ширины шага нам нужны еще три-четыре варианта (за вычетом зеркальных). А еще персонаж должен уметь поворачивать во время движения. Значит для каждого варианта нам нужны движения с поворотом. А если поворот может быть быстрым и медленным? Значит еще раз умножаем число необходимых клипов на два. А теперь нам нужно движение по наклонной поверхности! А потом нам захочется, чтобы персонаж умел делать тоже самое вприсяди. Итого - просто сотни и тысячи вариантов анимации которые нужно смешивать и следить за тем, чтобы это происходило корректно и приводило к движениям с нужной скоростью. И все равно, во многих случаях управление будет ощущаться как «ватное», поскольку инерция актера и наша невозможность предусмотреть все возможные человеческие маневры будет лишать игрока контроля над персонажем. Эту проблему, к слову, прочувствовали на себе игроки в The Witcher 3, поэтому в одном из крупных обновлений разработчики внедрили альтернативный вариант управления, где анимация быстрее отзывается на управление в ущерб реализму. В шутерах же проблема нелинейности движения обретает особенно выраженный характер: игроку часто приходится выглядывать из-за угла и быстро уходить обратно, и момент резкой смены направления может очень отличаться - игроку требуется как можно скорее вернуться обратно за укрытие, а у нас нет возможности предсказать заранее, какой ширины шаг он планировал и проиграть соответствующую анимацию. Игроку, в свою очередь, будет трудно привыкнуть к ширине шага, которую делает его персонаж, и к скорости этого шага, чтобы прервать его вовремя.
Во-вторых, Root Motion плохо годится для сетевых игр. Нелинейность движения не только затрудняет игроку предсказание скорости, но и лишает нас возможности интерполировать и экстраполировать движение чтобы компенсировать сетевую задержку, что является очень важным и сложным аспектом в быстрых сетевых играх. Если смещение персонажа задается только анимацией, то трудно аналитически подобрать нужные параметры машины состояний (смешивающей разные анимации), которые приведут к движению персонажа в точно нужном нам направлении и с точно нужной нам скоростью (выбранных для компенсации расхождения). Если же сделать наоборот, так, что анимация будет ориентироваться на фактическое движение, то при коррекции расхождения между сервером и клиентом легко можно будет подобрать наиболее подходящую анимацию, и даже если она будет чуточку несоответствовать фактическому смещению, этого почти никто не заметит.
Поэтому техника Root Motion используется часто в одиночных играх от третьего лица, где управление осуществляется контекстуально - в зависимости от наличия укрытия, препятствия, режима движения или других обстоятельств, и редко применяется в сетевом режиме и MMOG.
Из последних заметных проектов, использующих Root Motion, можно выделить The Witcher 3 . Трудно переоценить усилия, вложенные в производство всех его движений.
Пример анимации The Witcher 3 и ее съемки
2) Другое решение обратно принципу Root Motion - нужно приводить анимацию в наиболее точное соответствие с произошедшим или планируемым движением. Тогда многие описанные выше проблемы решаются - движение персонажа можно сделать равноускоренным и предсказуемым с возможностью сколь угодно быстрой смены направления. Но как привести нелинейную и инерционную анимацию в соответствие с таким движением? Интересный комплексный подход описали разработчики игры Paragon. Суть его заключается в том, чтобы находить и проигрывать только нужную серию кадров анимации для достижения требуемого смещения/поворота, пропуская лишние. И использовать инверсную кинематику для модификации ширины шага.
Первая очевидная трудность при приведении анимации в соответствие с движением, в том, что движение уже произошло, а анимация еще не проиграна. Поэтому очень пригодится система предсказания движения, вычисляющая положение персонажа для следующего кадра. Затем, зная смещение, которое должен осуществить персонаж за следующий кадр, нужно пропустить столько кадров анимационного клипа движения, сколько будет нужно чтобы достичь требуемого смещения, и проиграть тот кадр, на котором требуемое смещение достигнуто. В таком случае анимация станет воспроизводиться с измененной скоростью, так, чтобы точно соответствовать фактическому смещению, и эта скорость может быть быстрее или медленнее оригинальной, поскольку невозможно заставить реального актера поддерживать постоянное ускорение или скорость. Данный подход позволит сгладить анимацию и привести в соответствие с любой сложной процедурной моделью движения, меняющейся во время игры (персонаж может выпить какое-нибудь ускоряющее зелье или оказаться замедлен противником). Недостатком, разумеется, является то, что анимация может стать менее реалистичной из-за сильных изменений в скорости. Однако на практике это дает очень хорошее окно доступных вариаций в котором нарушения скорости незаметны. А вкупе с поправками ширины шага при помощи инверсной кинематики, покрывает еще больший диапазон.
Но, к сожалению, этот метод довольно сильно нарушает привычный подход к анимированию, и поэтому я не смог найти простого способа реализовать его, например, с использованием стандартного анимационного компонента Unity. В Unreal Engine также пока нет необходимого функционала, однако разработчики обещают когда-нибудь перенести низкоуровневые наработки, сделанные для Paragon, в общедоступную версию движка. Основной сложностью является поиск и воспроизведение нужного кадра на основании данных о фактическом смещении и повороте. Для этого авторы предлагают делать пре-процессинг анимационных клипов и генерировать для каждого из них дополнительный блок данных: Distance Curve, в котором будут покадрово сохранены значения смещения и поворота корневой кости относительно начала или конца анимации. Затем, в ходе выборки, можно производить быстрый бинарный поиск нужного кадра, где достигнуты соответствующие параметры смещения и поворота, и воспроизводить его.
Пока же можно ограничиться прежним подходом, и делать менее точную подгонку скорости анимации к скорости планируемого движения, ориентируясь только на скорость персонажа за последний кадр. Самое главное - неплохой набор душ для экспериментов теперь имеется!
Теги:
- unity3d
- анимация
- машина состояний
- геймдев
Начиная работать аниматором для игр, мне пришлось учиться на своих ошибках. Первые анимации для проекта PersianWars я старался делать наиболее приближенными к реальности, что, как не удивительно для меня, в игре выглядело очень плохо.
Введение.
Был даже момент, когда заказчику не понравились первые пробные анимации. Попробовал несколько утрировать движения и добавил анимацию одежды, это помогло очень хорошо, даже настолько, что заказчиком, был задан вопрос: это у вас новый аниматор?
Основное правило: неважно как это сделано, главное как это смотрится!!!
Это правило относится не только к анимации, а ко всему, что можно увидеть в игре.
В игре типа стратегии, или РПГ, где персонажи основную часть времени находятся на очень отдаленном расстоянии, надо соблюдать следующие подправила:
Правило первое, движения должны быть размашистыми: например, представьте себе, как бьют молотком по гвоздю… Правильно, молоток в замахе доходит до уровня уха, затем резкий удар, при этом, тело немного отклоняется назад, и скручивается. Для игр же, слово немного не подходит, если вы делаете стратегию, этого движения просто не будет видно, для более крупных планов, оно будет казаться куцым, недоделанным. Значит надо сильнее прогнуть тело, сильнее его скрутить, и замах сделать более длинным.
Правило второе, детальней надо, детальней:
Если вы делаете спрайтовую игру, то здесь все решается несколько проще. Достаточно сделать развевающуюся одежду, как анимация оживет, и заиграет новыми красками. Как сделать одежду развивающейся, решать вам, а мы в Персидских Войнах использовали, SimCloth. Вот несколько анимаций для затравки.
С 3D игрой все несколько, сложнее, не каждый движок позволяет делать анимацию одежды, да и не каждую одежду получиться анимировать. Как правило, это связано с ограничением, по количеству костей. Вот один из примеров анимации одежды для 3D движка:
Здесь анимация «юбочных висюлек» сделана отдельными костями. Я, последовательно проверяя на пересечения висюлек с ногами и телом каждый кадр, поворачивал каждую косточку, затем перепроверял, поворачивал, где нужно. Можно было бы соврать, и сказать, что анимация всего остального делалась бипедом, но это не так, ее делал другой человек, и по одному ему ведомым причинам, обычными костями. Отмечу, что в Максе, кости для «висюлек» все же использовать не стоит, сделайте лучше боксы, управлять ими более просто, и они менее глючны, по сравнению с одиночными косточками. Мне пришлось переделывать кости для висюлек, т.к. они по загадочным причинам не двигались совсем, а потом сводить многокадровые анимации из нескольких файлов, чтобы в них не менялся скелет.
3D Анимация.
Если у вас ранее был опыт создания классической анимации или 2Д компьютерной анимации, то вы знаете, что анимация - это кадры, меняющиеся с некоей частотой. В классической анимации вы должны были прорисовать каждый кадр, в 2Д компьютерной тоже, если это не простые перемещения плоскостей, или заранее запрограммированные эффекты. В 3Д анимации, как для игр так и для видео роликов, можно проставить только ключевые кадры, между которыми программа сама просчитает (интерполирует) необходимое движение между ключевыми кадрами.
Траектория и скорость этого движения зависит от выбранного вами типа интерполяции, для видео клипов можно использовать любые типы интерполяции, например: интерполяция по Безье, линейная, квадратичная и т.д. Однако для игр, как правило, используется линейная интерполяция. Из названия видно, что скорость изменения положения, вращения или масштабирования, при такой интерполяции меняться не будет. Вот и первый нюанс анимации для игр, если выгрузчик считывает не каждый кадр анимации, а только ключевые, то при необходимости изменения скорости движения, придется добавлять ключи. Даже в том случае, когда у вас нет необходимости менять скорость движения, но в программе у вас установлена не линейная интерполяция, результат при выгрузке может несколько отличатся от исходной анимации. По идее, это должно ложится на совесть программистов, но зачастую, переделывать приходится все равно вам. Благо в этом нет ничего сложного. Лечится расстановкой ключей в каждом кадре.
Существует также несколько типов анимации персонажей, это: морфинг (некоторые ее называют вертексная), анимация по частям тела (назовем это объектная), и костная (скелетная).
В чем их отличие?
Морфинг – для этой анимации создается несколько 3Д моделей, являющиеся ключевыми кадрами, после чего программа интерполирует положения вершин треугольников, составляющих модель в новую форму, затем в следующую и т.д.
Объектная – основные куски персонажа (голень, бедро, ступня, тело и т.д.) представляют из себя отдельные объекты, связанные или не связанные иерархией. И имеют собственную анимацию.
Костная – создается скелет, который деформирует целую модель, или ее часть.
Анимация для игр.
Рассмотрим процесс создания анимации персонажа для 3D игры, особенности анимации для различных игровых жанров, и некоторые особенности анимации для спрайтовых игр.
Какой пакет выбрать для анимации?
Если вы раньше не работали в 3Д программах, то тем более нет никакой разницы, а если работали, то анимацию лучше делать в том пакете, с которым работали до этого.
Особой разницы в пакетах для создания 3Д анимации нет, принцип один и тот же везде: есть модель, скелет и ключевые кадры. И из основных пакетов для 3Д моделирования и анимации, можно при необходимости перенести в другой пакет.
А раз разницы никакой нет, то для примера возьмем 3D Studio MAX r6.
Какой тип анимации выбрать?
Это напрямую зависит от того, какую анимацию поддерживает ядро вашей игры (движок).
Если же вы еще не определились, какую же анимацию поддерживать, то я приведу некоторые плюсы и минусы для всех типов:
Морфинг. Плюсы: позволяет создавать, анимированные ткани, волосы, и деформировать сетку модели как вам это нужно. Минусы: после 700 треугольников занимает больше памяти нежели остальные типы (количество занимаемой памяти для костной, зависит от количества костей). Необходимо делать отдельные анимации, для каждой модели. Практически невозможно перевести в другой тип анимации.
Объектная. Плюсы: наиболее мало занимающая анимация, простота замены частей, например рука в перчатке или без нее. Поддерживается практически всеми движками, в той или иной степени. Минусы: при анимации персонажа, на крупном плане, скорее всего, будут видны стыки объектов. Очень сложно сделать анимацию одежды или косичек из-за стыков, или сильного увеличения памяти занимаемой анимацией. Переводится в другой тип, через костную анимацию.
Костная. Плюсы: простота создания непосредственно анимации, простой перевод в любой тип анимации. Простота использования «Моушен кэпчура». Минусы: не очень простая привязка к костям. Ограничение по количеству костей (не всегда, но очень часто). Медленнее обрабатывается движком, чем другие типы.
Поскольку наиболее легко усваиваемым способом подачи информации является информация в примерах, то рассмотрим костную анимацию, как наиболее просто переносимую в другие типы.
Итак, у нас есть модель девушки, для нее необходимо сделать анимацию.
Для начала выберем каким скелетом нам пользоваться. Делать ли его вручную или использовать бипед.
Я выбираю бипед. Потому как, на мой взгляд, это наиболее удобный в управлении скелет, мало того у него уже настроена инверсная кинематика.
Что значит наиболее удобный?
Это означает отсутствие лишних управляющих элементов, при такой же работоспособности, возможность использовать как обратную, так и прямую кинематику одновременно, и кучу дополнительных и очень полезных инструментов, таких как, например, копирование ключей и вставка их на противоположную конечность, копирование трека с другого бипеда в сцене, сохранение и загрузка анимации, даже с несовпадающего по пропорциям бипеда.
Бытующее мнение, о якобы маленькой гибкости бипеда, неверно в корне, да, конечно, сделать бипедом анимации змеи не просто хотя и можно на самом деле. Но ведь он придуман как раз для анимации персонажей имеющих несколько конечностей. Вот достаточно яркий пример универсальности бипеда - анимация дракона. В ней используется бипед, с добавленными 4мя костями, это нижняя челюсть, язык, и по одной дополнительной косточке на крылья, добавленных из-за ошибки моделлера.
Итак, я выбираю бипед. Если вы все же считаете, что делать этого не стоит, ну что ж настраивайте свой скелет, принципы анимации и привязки от этого не поменяются.
Скелет выбрали теперь надо его подогнать под модель.
Делится советами, которые помогут быстрей и эффективней создавать качественную анимацию.
Кого угодно можно научить ис пользовать 3D-приложение для создания анимации, а также манипулировать кривыми, IK или блендшейпами. Но это еще не сделает его аниматором, поскольку настоящая анимация состоит из множества составляющих.
Совет №1: Блокинг ключевых поз
Сфокусируйтесь на важных движениях персонажа, помня о "полной анимационной картине"
Не пытайтесь моментально, когда дело доходит до анимации, проработать каждое движение персонажа. Если вы будете постоянно фокусироваться на каком-то одном моменте, вы не будете видеть всю картину целиком, создавая при этом неестественно выглядящую анимацию.
В анимации каждое движение должно быть гармоничным, поэтому очень важно видеть всю картинку целиком, фокусируясь на ключевых позах.
Совет №2: Копипаст ключей
В некоторых случаях, например, при работе над циклами ходьбы или бега, не имеет смысла отдельно прорабатывать зеркальные позы. Поэтому можно схитрить и, например, банально скопипастить ключи с левой ноги на правую. При этом помните, что в первую очередь вы делаете это, чтобы ускорить сам процесс работы.
Совет №3: Использовать надежный ригг
Хорошая 3D-анимация зависит не только от таланта аниматора, но и от качества используемого им ригга. Быстрый базовый ригг позволит вам создать базовую анимацию. Поэтому ригг необходимо настраивать под ваши конкретные узкоспециализированные нужды. Непрофессиональный ригг только доставит вам лишние проблемы. Также аниматор не должен иметь возможность редактировать констрейны и прочие системы, поскольку это просто «убьет» ригг.
Самый лучший ригг тот, который позволяет аниматору анимировать, не задумываясь о ненужных для него вещах. Так круто, когда ты просто берешь персонажа и двигаешь его в сцене, ключуя, не задумываясь о всяких технических штуках, когда тебе не нужно каждые 5 минут писать риггеру, спрашивая, почему это руку персонажа разнесло на пол экрана.
Совет №4: Заставьте тангенты работать
Анимация - это не только ключи. Только с их помощью довольно сложно контролировать анимацию. Также если понаставить ключей в каждом кадре, сцена станет перегруженной, анимацию будет очень сложно редактировать, движения персонажа будут при этом неестественными.
Перед тем, как психануть из-за того, что у вас получается неестественная анимация, поэкспериментируйте с анимационными кривыми и тангентами. У каждого ключа есть тангент, который можно настроить, с помощью него можно также контролировать промежуточные кадры.
Совет №5: Пусть приложение работает за вас
Даже если вы работаете в самом дорогом 3D-приложении последней версии, вы все также делаете анимацию традиционным образом. Перемещение джоинтов и назначение ключей довольно трудоемкое занятие, поэтому пусть за вас работает программа.
Особенно это применимо к вторичной анимации, поскольку с помощью динамики можно просчитывать волосы, одежду или хвост персонажа. Считаться это будет автоматически, что позволит вам сосредоточиться на ключевой анимации.
Совет №6: Используйте прокси-модель, чтобы облегчить вьюпорт
При работе над ключевыми движениями лучше использовать лоупольную прокси-модель, вместо хайпольной
Хайпольная модель может подвесить вьюпорт, поскольку она должна деформироваться и перемещаться в сцене с помощью скелета или других сложных деформеров. Это становится особенно заметно, если вы проигрываете анимацию в режиме реального времени.
При работе над ключевыми позами и базовыми движениями, спрячьте хайпольную модель и анимируйте облегченный прокси-вариант. Это может быть как упрощенная версия персонажа, так и пара кубиков с нужными пропорциями. Такой подход позволит тщательно проработать базовые движения, которые вы затем примените к хайпольной модели.
Совет №7: 3 кита хорошей анимации: подготовка, действие и реакция
Планируйте анимацию с учетом 3 фаз: подготовки, действия и реакции
При работе на секвенциями или анимацией в целом, не забывайте о 3 важных фазах: ожидание, действие и реакция. Практически каждое движение содержит в себе какую-то толику каждой этой фазы.
Например, перед тем как прыгнуть, вы сгибаете ноги в коленях, или отводите руку назад перед тем, как что-то бросить. Это фаза подготовки. Прыжок или бросок — действие. Реакция - сгибание коленей или движение рук после приземления. Этот же подход применим и к лицевой анимации. Для достижения эффекта комичности можно преувеличить все движения или мимику.
Совет №8: Посмотрите на происходящее глазами персонажа
Не бойтесь записывать себя на камеру
Лучший референс для аниматора - видео. Возможность постоянно просматривать его, ставить на паузу, проигрывать в замедленном режиме позволит проработать движения персонажа очень детально.
И это не ново. Серьезные анимационные студии всегда снимают актеров, озвучивающих персонажей, когда они читают текст. Затем это видео передается аниматору, который при анимации персонажей будет опираться на поведение актера и его выражение лица.
Такой подход доступен не всем из нас, поскольку мы не обладаем безграничными возможностями киностудии. Однако мы можем встать со стула и, хотя бы, записать видео того, как мы ходим или ведем себя. Попробуйте сами воспроизвести сцену, над которой работаете, неважно каким это тяжелым или сложным вам кажется. Это поможет вам быстрее разобраться с блокингом и создать более качественную анимацию.
Совет №9: Используйте зеркало
Лучший ваш референс - вы сами
Закончив работать над анимацией тела персонажа, переходите к его лицу. Правильней всего анимировать лицо в конце. Это очень важная часть анимации. На этом этапе нужно создать естественную мимику, которая убедит зрителя, что персонаж действительно испытывает те, или иные эмоции.
Купите себе маленькое зеркало и смотрите на себя во время работы, скорчите себе в него пару рож. Для создания качественной анимации, нужны хорошие референсы, а какой референс может быть лучше вас самих?
Совет №10: Используйте анимацию повторно
Библиотека с анимациями поможет вам работать быстрее и эффективней
Это совет применим ко всем областям CG-индустрии. Его также можно использовать и в анимации.
На создание качественного цикла ходьбы или бега уйдет не один и даже не два часа работы, поэтому создав его однажды, используйте его и в последующих проектах. Сфокусируйтесь на ключевых позах, затем проработайте их детальнее, сделайте более разнообразными, а персонажа, тем самым, уникальным.
И, напоследок. Помните, что лицо нужно анимировать в последнюю очередь
Ранее уже упоминалось, как важно работать над персонажем в целом, путем блокинга определяя ключевые позы, затем уточняя их. Но это относится только к анимации тела персонажей, поскольку мимикой следует заниматься в самую последнюю очередь.
В этом уроке мы хотим рассказать об основных этапах создания анимированных персонажей с помощью программы Flash на примере разработки персонажа игры «Учимся играя» и аватара для Web-сайта.
Персонаж компьютерной игры
Согласно сценарию игры «Учимся играя», все действия в ней выполняет главный персонаж Колобок (рис. 1), который перемещается по полю (рис. 2) в поисках алмаза.
Смысл данной игры заключается в том, что играющий должен выбирать путь к цели (алмазу), называя по имени предметы, расположенные справа, слева, сверху и снизу от клеточки, где стоит Колобок, осуществляя, таким образом, перемещения персонажа вверх-вниз, вправо-влево. Например, для того, чтобы Колобок переместился на одну клеточку вниз, в меню на рис. 2 нужно выбрать слово «orange». Правильно выбирая названия в меню, играющий может подвести персонажа к заветному алмазу.
Тот же самый принцип лег в основу нескольких тематических игр. Так, на рис. 3 показан вариант игры, посвященный изучению дробей 1 .
1 Программа содержит 12 тем для изучения («Форма. Цвет. Число», «Времена года», «Часы», «Птицы», «Животные», «Устный счет», «Геометрические фигуры», «Римские цифры», «Дроби», «Палитра художника», «Английский язык», «Нотная грамота»).
В создании игры принимали участие Александр Прохоров, Михаил Морозов, Дмитрий Быстров, Елена Андрианова, Андрей Вязников. Более подробную информацию об игре можно получить по адресу: http://computergames.com.ru/54/7217.html .
Как следует из вышеописанного сценария, одной из задач при разработке игры было создание персонажа Колобок и анимации его перемещений.
В качестве примера показана анимация перемещений Колобка сверху вниз: анимация 1 .
На первом этапе создаются эскизы внешнего вида героя (рис. 4) , а также эскизы его перемещений и основных действий (рис. 5).
Параллельно делаются эскизы, в которых показывается, как персонаж будет выглядеть в разных темах игры. В частности, на рис. 6. показан эскиз к теме «Астрономия», а на рис. 7 эскиз к теме «Дроби».
В данном случае внешний вид Колобка определяется не только эстетическими, но и техническими соображениями как создать героя, чтобы его можно было легко анимировать.
На рис. 8 видно, что персонаж состоит из отдельных элементов.
2 Данная работа выполнялась Еленой Адриановой.
Это позволяет задать перемещение каждого элемента (руки, ноги, брови, глаза и т.п.) по отдельности. Таким образом, вместо того, чтобы многократно перерисовывать персонаж в разных положениях, достаточно задать автоматическую анимацию элементов, из которых он состоит.
Рассмотрим подробнее, из чего сделан наш герой. Папка «Части», показанная на рис. 9, содержит 12 элементов (в основном это мувиклипы), из которых состоит Колобок. Например, левая нога Symbol 4d (рис. 9), правая рука Symbol 7d (рис. 10) и т.п.
При этом отдельные элементы, такие как Symbol 12d (рис. 11), уже заключают в себе анимацию движения бровей и глаз и тоже состоят из отдельных элементов.
В частности, мувиклип Symbol 12d состоит из отдельных составляющих: брови (Symbol 34) (рис. 12), левый глаз (рис. 13). В свою очередь, мувиклип, изображающий левый глаз, базируется на мувиклипе «глаз» (рис. 14).
Таким образом, герой как бы собирается из отдельных деталей конструктора.
Для того чтобы показать, как перемещаются отдельные элементы, из которых состоит Колобок, во время ходьбы, обратимся к рисунку, где показан цикл ходьбы в режиме Оnion Skinning (калька). Из рис. 15 видно, что во время ходьбы у него перемещаются не только руки и ноги, но практически все элементы, из которых он состоит. При этом все элементы анимированы в режиме автоматической анимации движения (Motion Tweening) и только руки (вернее линии, которые соединяют кисти рук с телом) анимированы в режиме автоматической анимации формоизменения Shape Tweening (на рис. 8 эта анимация задана в слоях Layer 5 и Layer 7).
На рис. 16 показано, как создается анимация при движении персонажа влево . При этом задействованы многие общие элементы, используемые при анимации движения персонажа вниз.
Аналогично анимируются движения Колобка при движении вправо и вверх.
Для того чтобы разнообразить движения персонажа, добавляются различные периодически повторяющиеся жесты. Например, Колобок прикладывает во время ходьбы руку ко лбу или, глядя на зрителя, грозит пальцем (рис. 17).
Основные варианты движения Колобка можно наблюдать в данном ролике .
Некоторые жесты персонажа появляются в ответ на действия игрока. Например, когда играющий долго думает, колобок начинает зевать. Если ответ неверен, персонаж недовольно морщится и т.д.
Для того чтобы лучше разобраться в том, как анимирован данный персонаж, можно обратиться к исходному fla-файлу .
Аватар для сайта
Часто оживить Web-сайт помогает персонаж, который взаимодействует с посетителем. Самый простой пример это тестирование на сайте, при котором, помимо устных комментариев (или вместо них), результат ответа оценивается путем отображения настроения аватара.
Рассмотрм пример создания подобного персонажа.
На начальном этапе выбирались те настроения героя, которые должны быть задействованы по сценарию, и художник делал соответствующие наброски (рис. 18).
Далее изображения доводились до чистового вида в программе Photoshop. При этом создавался шаблон с постоянными контурами лица, в который вписывались необходимые для передачи данного настроения черты. Цвет лица при этом также менялся (рис. 19).
После этого во флэш был сделан следующий интерактивный ролик . В этом ролике мы отразили лишь шесть кадров, то есть использовали только часть изображений, показанных на рис. 18. Но для того, чтобы понять принцип, этого вполне достаточно. Рассмотрим более подробно, как создать подобный ролик.
В первом кадре помещаем изображение лица «грустный» по команде File => Import=> Import to stage , а затем переводим его в векторный вид по команде Modify=> Bitmap=> Trace Bitmap .
Затем применительно к первому кадру записываем строчку кода stop(); рис. 20.
Данный код указывает, что программа не должна переходить к следующему кадру до тех пор, пока пользователь не выполнит некоторое управляющее действие.
Так, верхняя кнопка будет содержать код, показанный на рис. 21.
Второй и последующие кадры создаются при помощи команды Insert Keyframe. Данная команда создает на каждом вводимом кадре все элементы с предыдущего кадра, так что нам остается только заменить картинку с очередным выражением лица.
Для более подробного знакомства с данным роликом можно обратиться к исходному
