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, в котором будут покадрово сохранены значения смещения и поворота корневой кости относительно начала или конца анимации. Затем, в ходе выборки, можно производить быстрый бинарный поиск нужного кадра, где достигнуты соответствующие параметры смещения и поворота, и воспроизводить его.

Пока же можно ограничиться прежним подходом, и делать менее точную подгонку скорости анимации к скорости планируемого движения, ориентируясь только на скорость персонажа за последний кадр. Самое главное — неплохой набор душ для экспериментов теперь имеется!
Поделиться с друзьями
-->

Комментарии (29)


  1. myxo
    24.06.2016 16:56
    +3

    «Одна из самых доступных систем это костюм neuronmocap стоимостью порядка $1.5к без учета доставки.»

    А почему сложно самому сделать подобный костюм? Ну то есть на взгляд дилетанта — это просто костюм с метками + камеры + софт фиксирующий движения меток и переводящий их в 3D.

    А лицевую анимацию уже вроде можно снимать с камеры

    Заголовок спойлера
    ps. А пост — годнота.


    1. id_skrynnik
      25.06.2016 09:58

      Да, качественную лицевую анимацию можно сделать с помощью Blender 3D. Софт бесплатный, нужна только камера и прямые руки (и меш с хорошей топологией). Однако, чтобы сделать moution capture потребуется множетсво камер, а камеры снимают в инфракрасном спектре, как раз его и излучают маркеры на костюмах. Поэтому и получается сразу готовый скелет.


      1. dzikar
        25.06.2016 12:30

        Ик камеры недороги и плюс не излучают. Там софт сам стоит бешеных денег, а не костюм. Ну и камеры вносят толику ценника…


        1. Eugeny1987
          27.06.2016 11:48

          Камеры не дороги?
          www.optitrack.com/hardware от $599 за штуку


      1. evocatus
        25.06.2016 21:28

        Обойтись ИК-фильтром на камеру не получится?


  1. JeriX
    24.06.2016 17:58
    +1

    Классный пост! Отдельное оргомное спасибо за ссылки на бесплатные паки анимаций!


  1. Idot
    24.06.2016 18:08
    +1

    Насчёт Ragdoll, очень часто при анимации забывают учесть, что человек от боли, как правило, скручивается в позу эмбриона, и потому чаще всего оказывается упавшим вперёд.


  1. lorc
    24.06.2016 18:16
    +3

    А почему в качестве гифки для привлечения внимания у вас анимация сделанная методом ротоскопирования?


    1. dnnkeeper
      24.06.2016 20:05
      +1

      Поскольку это иллюстрация к тезису об одушевлении мира при помощи анимации. Но я сам тоже задумывался, уместна ли она в шапке. Решил, что хотя бы желание задать этот вопрос в комментариях привлечет читателей, так что оставил, и не прогадал ;)


  1. mamkaololosha
    24.06.2016 20:01
    +3

    Статья ни о чём. Поверхностный обзор. Потом приходят эксперты после таких статей и ни одной конкретной задачи решить не могут. Как использовать — нет. Проблемы — нет. Решения — нет. Ничего нет.


    1. dnnkeeper
      24.06.2016 20:03

      Не стану спорить, именно так она и названа — обзор техник и ресурсов. Если тема интересна, могу рассказать глубже о практических решениях, которые довелось использовать при разработке контроллера персонажа. Пока же это просто конспект который может оказаться полезен тем, кто только начинает работать с 3д анимацией.


    1. questor
      26.06.2016 00:17
      +1

      Знаете, а мне понравилось. Я не собирался ни становиться экспертом в теме, ни решать конкретных задач. Просто пролистал по диагонали картинки, впечатлился современными технологиями — и всё. Воспринимаю статью как некий общеобразовательный научпоп, самый трэшовый из которого отселили с хабра.


  1. art_virt
    24.06.2016 20:32
    +1

    Хм…
    Что же, кому интересно, основная качественная анимация делается:
    1. Мокап с чисткой. До чистки мокапа, даже на проф оборудовании, всё гораздо хуже. И в любом случае приходится работать над преувеличением действий, движений.
    2. Работа по референсу (https://vimeo.com/134156149) — аниматор снимает себя или коллег на видео, а затем используя приблизительный тайминг и позы работает над анимацией.
    3. На «скиле» — не всегда есть возможность снять референс, или использовать его (к примеру, передвигающийся за счет инерции, сундук). В таком случае аниматор создаёт на камеру приблизительно лучшие на его взгляд позы, а потом работает над таймингом, брейкдаунами (промежуточные позы) и прочими странными словами. Ну и конечно же, есть специалисты, которые не любят использовать «копирку» — мокап или видео-референс.

    Для CG, и для фильмов — очень часто используют Mocap ввиду скорости работы.
    Для мультиков (та же Зоотопия \ Зверополис) — делают в основном по второму варианту.
    В игрострое все методы популярны.

    Это если кратко :)


    1. dnnkeeper
      24.06.2016 20:52

      Вот в компании Pilot TV утверждают, что даже чистка в основном не требуется:

      В этом месяце, кстати, появилось много интересных видео и интервью от этой компании.
      Подумываю, не написать ли им о сотрудничестве и создании какого-то базового ассета для энтузиастов игростроя на котором можно было бы быстро делать игры с красивой боевой системой, например.


      1. art_virt
        24.06.2016 21:18
        +1

        Есть безумное количество ассетов (к примеру в магазине Unreal Engine)

        Основная проблема с вашей идеей — представьте двух персонажей. Один пузатый, с короткими руками, отдышкой. Второй — высокий, накачанный, да еще и выполненный в cartoon-стилистике. Проблемы возникают сразу, как только вы перейдёте от походки к, скажем, вставанию со стула. Или киданию мяча. Стрельба из двустволки станет визуальной пыткой же для всех игроков (как минимум руки проходят сквозь ружьё, неправильно достаёт и вставляет патроны и далее по списку)

        Переключение на IK систему спасёт положение мало.
        Мокап — отличная база, но её нужно стараться разрабатывать под «своих» персонажей. Аналогией можно взять Skyrim, где просто нет толстых, у всех одинаковая структура тела. Увы, это бросается в глаза многим игрокам. Что уж говорить о инди-разработках, которые иногда хотят взять оригинальностью…

        Либо делать индивидуально под каждого перса, снимая по 10-20 дублей — либо молиться всем великому древу, из которого были сделаны первые костыли, что всё будет как надо…


  1. WeslomPo
    24.06.2016 21:55
    +5

    В статье нет упоминания про ikrig recap от ubisoft


    1. dnnkeeper
      25.06.2016 01:43

      Очень классная штука, я увидел ее уже после того, как написал статью, но так и не смог разобраться в ее особенностях. Презентация не дала понять в чем фишка. Как сделан анализ окружения? Как именно устроены правила коррекции целевых точек кинематики? Попробую разобраться. Буду рад услышать пояснения или гипотезы об устройстве этой системы.
      PS: Кстати автор, судя по имени, имеет русские корни, вдруг он есть на хабре?


    1. netgoblin
      25.06.2016 15:27
      +1

      Эта технология изобретена в Autodesk и называлась Human IK. Ubisoft использовали её в играх серии Assassins.s Creed с первой серии.
      www.autodesk.com/products/humanik/overview


      1. Chaos_Optima
        27.06.2016 15:33

        Не совсем, IK вообще давно изобретён. recap в данном случае просто переносит анимации с одного скелета на другой с учётом ik


        1. netgoblin
          27.06.2016 18:08

          Не так. Речь шла не про IK, а про технологию Human IK, которая позволяет персонажу взаимодействовать с объектами окружающей среды. В качестве примера игра Assassins's Creed: главный герой при передвижении в толпе отталкивает от себя идующих навстречу пешеходов. Да что там говорить, весь паркур в игре построен на этой технологии.

          А сама технология, судя из названия, работает в связке с инверсной кинематикой. Детали на сайте Autodesk.


  1. CTAPOBEP
    25.06.2016 01:23
    +1

    > Но как сделать реалистичную ходьбу по лестнице, где очень много деталей, связанных с переносном центра тяжести и балансом тела?

    Интересно, кто-нибудь пытался делать подобную анимацию, просчитывая ее в реальном времени в физическом движке? Какие при таком подходе могут быть принципиальные сложности?


    1. dnnkeeper
      25.06.2016 01:36

      Нужна хорошая мускульная модель, как я понимаю. Физического движка твердых тел недостаточно. Мы ловко напрягаем мускулы при ходьбе и хитро переносим центр тяжести так, чтобы достичь нужной скорости, удобства и экономии сил. Смотри ссылки про эволюционное моделирование, там есть мускульная модель и в целом всё получается почти как надо.
      Можно еще инверсной кинематикой вносить поправки в обычную ходьбу, поскольку она очень похожа на движение по ступенькам (так и делают в играх). Но все наши маневры которые чуть сложнее ходьбы вперёд уже плохо поддаются анимированию вручную, даже такие тривиальные как ходьба по ступеням и неровной поверхности, а уж тем более — движения во время боя. Так что мокап, на мой взгляд — самое действенное решение еще на многие годы вперёд.


    1. netgoblin
      25.06.2016 15:34

      Что касается непосредственно самой хотьбы, то корректировка шагов относительно поверхности выполнется с применением IK (inverse kinematics). Вот, например, как это реализуется в игровом движке UE4 — https://docs.unrealengine.com/latest/INT/Engine/Animation/IKSetups/
      В первую очередь, необходима настройка IK для ног — связваются ступня и бедренная кость. Затем, во время хотьбы производится проверка — из ступни рисуется луч вертикально вниз до пересечения с ближайшей плоскостью. И наконец, выполняется корректировка шага с учетом расстояния до «земли».


  1. GubkaBob
    25.06.2016 02:10
    +2

    оффтоп.

    играл в elders scroll, почти во все. нигде не напрягала графика. так что если выбор между анимацией и геймплеем — я за геймплей. даже с иногда скользящим эльфом.


  1. kahi4
    25.06.2016 14:05
    +1

    Кто-то на кафедре писал диплом, в котором гексапод обучал ходить генетическим алгоритмом. Там была достаточно примитивная, но способная передвигаться математическая модель робота, нейронная сеть, которой ставилась цель «дойти до точки» и сотни тысяч поколений. Обучили.

    Это я к тому, что мне кажется перспективным вариант создания достаточно хорошей математической модели персонажа (с проработкой основных мышц и скелета, сейчас это просчитывать не сложно), которая будет управляться нейронной сетью. Саму сеть в данном случае есть смысл обучать не генетическим алгоритмом, а учителем по тому же motion capture. Скорее всего, в первых потугах персонаж будет спотыкаться и падать, придется придумывать какие-то уловки чтобы избегать подобных проблем, но когда-то это направление вырастет до самого правдоподобного для применения в играх. Ведь это открывает и возможность реагировать на травмы в разных частях тела, адаптироваться под изменение физиологии (взял в руки что-то тяжелое, например) и подобное.
    (хотя чисто математически это будет попросту интерполяция между движениями, которым ее обучили, но не важно).


  1. jorgen
    30.06.2016 21:53
    +3

    Сам работаю над процедурной анимацией. Говорят, получается неплохо. Здесь — двуногий шагающий робот. Может смотреть в одну сторону, а идти в любую другую. При этом слушается мышь в ран-тайме без всяких нейронных сетей или приготовленных заранее анимацией. Толкать его тоже можно в любую сторону — реагирует адекватно. Кушает отдачу от выстрелов. У ходьбы куча параметров, походки размеры конечностей, пропорции, и т.п., всё настраивается.



    Тут движения немного гипертрофированы, но это эффекта ради.
    Есть и четырёх-, шести- ногие, тоже симпотно бегают.


    1. dnnkeeper
      01.07.2016 03:01
      +1

      Отличный робот. Но для робота и неудивительно что процедурная анимация хорошо работает, ибо это и есть ожидаемая природа его движений. С биологическими же тварями процедурка выглядит гораздо менее натурально.


      1. jorgen
        01.07.2016 09:02

        Я тоже этого ожидал. Однако по моему опыту, сделать анимацию живого существа выходит проще, чем именно робота. Первые же тесты показали что голый алгоритм без настроек — уже скорее жив.

        Мне кажется, одень тут шкурку животного и будет не плохо. Может быть мне ещё придётся поработать чтобы оно было более робототм :)
        Кроме того у ребят выше по комментам — и люди и животные анимированы.


  1. netgoblin
    01.07.2016 03:09

    В программе 3dsmax есть модуль CAT для генерации процедурной анимации ходьбы / бега. На мой непрофессиональный взгляд анимации выглядять вполне натурально. Модуль позволяет настраивать любое количество костей / суставов. Можно за пару кликов анимировать любое существо: змею, кошку, человека, тарантула.