модель персонажа для unity3d

Как выполнить настройку анимированной модели персонажа в Unity3D?

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

И импортируем в проект:

Открываем в окне Project папку с персонажем, находим его модель, переносим в сцену.

Поскольку это модель из магазина AssetStore, она полностью настроена и готова к введению в игру. Тем не менее, важно убедиться, что всё настроено верно:

2. Во вкладке Animation у данной модели нет собственных анимационных клипов. Именно поэтому мы возьмем их с сайта mixamo.com:

Эти анимации можно свободно скачать, что мы и сделаем сейчас.

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

Я подготовил вот такой сет анимаций. Он включает в себя:

Обязательно выберите все файлы с анимациями и во вкладке Rig переключите их в режим Humanoid:

Пора настроить импорт каждой анимации в проект. Выделяем,например, walking и переходим во вкладку Animation:

1.Назначаем ключи старта и окончания анимации (поскольку каждый файл анимации идет отдельным файлом, обычно эти ключи автоматически стоят верно).

3.Устанавливаем галочку LoopTime- этот включенный параметр зацикливает анимацию при воспроизведении.

Аналогичным образом настраиваем остальные анимации. Не забываем нажимать Apply для того чтобы применить все изменения анимационного клипа.

Теперь в сцене выделим персонажа. Давайте посмотрим на компонент Animator, который присутствует на нем. Нам важны два поля:

Если Вы всё делаете, как и я – проблем с аватаром возникнуть не должно.

2. Controller – Это то, с чем мы и будем работать дальше. Анимационный контроллер – это своего рода схема, в которой мы определим, как именно воспроизводятся анимации, в каком состоянии какие из анимаций смешиваются друг с другом. Если сказать проще, то именно в контроллер мы будем отправлять сигнал о том, какая анимация должна воспроизводиться в данный момент. Но обо всём по порядку.

Давайте создадим анимационный контроллер: Правой кнопкой мыши кликаем в окне проекта. Create – Animator Controller.

Получится вот такой файл, я назвал его PersonAnimatorController:

Кликаем по нему дважды, откроется вкладка Animator:

Это и есть окно, в котором мы установим алгоритм работы наших анимаций. Давайте сразу создадим 3 состояния (ПКМ – Create State – Empty):

Выделив одно из состояний (например, idle), в окне Inspector мы можем заметить, что поле Motion сейчас пустое. Сюда необходимо поместить анимационный клип (тот, которому мы настраивали ключи Start-End, устанавливали Loop pose, и т.д.).

Поэтому, не снимая выделение с выделенного элемента, в окне Project находим файл с анимацией Idle, и из него перетаскиваем АНИМАЦИОННЫЙ КЛИП в поле Motion в окне инспектора.

Таким же образом устанавливаем клипы в остальные состояния (walk, run).

Теперь в левой части окна Animator переходим во вкладку Parameters:

Создаем Int – параметр, назовем его “state”. Это переменная, которая будет определять, в каком состоянии сейчас находится аниматор персонажа (какое из наших трёх состояний воспроизводится в данный момент). Этим параметром в будущем мы будем управлять из скрипта.

Теперь необходимо создать переходы между состояниями.

Кликаем на Idle правой кнопкой, жмем на Make Transition, после чего наводим курсор на состояние Walk.

Сразу сделаем переходы между всеми состояниями, и туда, и обратно.

Теперь переходим к настройке каждого перехода. Первый переход:

Выделяем его, смотрим в правую часть окна Animator:

Has Exit Time – снимаем галочку. Этот параметр, при включенном состоянии, сначала ждет, пока текущая анимация отыграет полностью, а уже после – совершает переход в другое состояние. Нам это не нужно, т.к. переходы у нас будут в конкретные моменты, когда наша переменная state меняет своё значение.

В Conditions добавляем условие перехода:

Дословно это выглядит так: “Если state = 0”. Если представить это в виде кода:

То есть, выбранный переход сработает в том случае, когда значение state будет равно “1”.

Обратный переход из Walk в Idle настраиваем так (не забываем во всех переходах отключать Has Exit Time):

По аналогии, нужно сделать переходы:

Idle – Run (state equals 2)

Run – Idle (state equals 0)

Walk – run (state equals 2)

Run – Walk (state equals 1)

Не забудьте выделить персонажа в сцене и переместить созданный анимационный контроллер в поле Controller в компоненте Animator:

Теперь, если запустить игру и, выделив персонажа, в окне аниматора поменять значение state, мы увидим, что анимации воспроизводятся:

Вы можете заметить, что персонаж немного смещается и разворачивается. Это происходит, потому что мы не настроили смещение и поворот за счёт анимации. Делается это в окне импорта каждого файла анимации, во вкладке Animation. Обычно я настраиваю анимации так, чтобы они никак не влияли на перемещение или поворот. Установите флажок во всех опциях Bake Into Pose.

А так же Based Upon в Original.

Теперь создадим скрипт, чтобы управлять анимациями персонажа по нажатию на клавиши.

Называем его PersonController. Перетяните скрипт на персонажа, чтобы он отобразился в списке компонентов под компонентом Animator:

Открываем скрипт. Пишем код:

Теперь, если запустить игру, персонаж начнет реагировать на нажатия на клавиши.

На этом пока всё. Это базовый механизм настройки персонажа, аниматора, и простой способ воспроизвести анимации. На основе этого принципа можно анимировать многие игровые объекты, не только персонажей. Но для того, чтобы сделать качественное смешивание анимаций и не превратить Анимационный контроллер в мешанину из огромной кучи состояний и переменных, которыми сложно управлять, когда их много – существуют очень удобные инструменты смешивания в Animator (BlendTree), а так же возможность создать машину состояний внутри одного состояния. Но об мы расскажем в отдельной статье.

Источник

Импорт 3D-моделей в Unity и подводные камни

Представляем третью статью нашего цикла о работе с 3D-моделями в Unity. Предшествующие статьи: «Особенности работы с Mesh в Unity» и «Unity: процедурное редактирование Mesh».

В мире компьютерной графики существует множество форматов представления 3D-моделей. Некоторые из них позиционируются как универсальные, другие — как оптимизированные под конкретные задачи или платформы. В любой сфере мечтают работать с универсальным форматом, но реальность говорит нам «нет». Более того, из-за такого зоопарка получается порочный круг: разработчики «универсальных» инструментов придумывают свои внутренние форматы для обобщения предыдущих, увеличивая популяцию и плодя средства преобразования форматов. Так появляется проблема потери или искажения данных при конвертации. Проблема стара как мир (мир IT, конечно), и она не обошла стороной импорт моделей в Unity.

В этой статье мы расскажем о некоторых трудностях, с которыми приходится сталкиваться при работе с моделями в Unity (особенности функционирования ModelImporter, разница представлений 3D-объектов и др.), а также о том, какие инструменты мы создали, чтобы эти трудности преодолеть.

Особенности работы ModelImporter

Напомним, что для API видеокарт минимальный и единственный трехмерный примитив — это треугольник, в то время как геометрия в FBX, например, может быть представлена в виде четырехугольников. Современные 3D-пакеты для создания моделей, как правило, допускают различные уровни абстракции, но и там рендер результата происходит посредством треугольников.

При этом многие инструменты заточены на работу именно с четырехугольниками, что подталкивает 3D-художников использовать этот примитив как основной. В таких случаях в ТЗ часто требуется триангулировать модель перед внедрением. Если триангуляцию не сделали, соответствующий модуль Unity в стандартном режиме выполняет ее автоматически при добавлении файла. Из-за этого появляются ошибки, поскольку алгоритмы триангуляции в разных пакетах реализованы по-разному. При выборе диагонали для разбиения четырехугольника возникает неоднозначность, отсюда большинство проблем, которые можно разделить на две группы.

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

Сюзанна, триангулированная в Blender (Quad Method: Beauty) и в Unity (автоматически при импорте)

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

Самокат здорового человека и самокат курильщика

Проблемы второй группы встречаются в текстурной развертке. Например, у нас есть четырехугольник с достаточно тупым для возникновения ошибки углом. При предварительном просмотре в 3D-пакете он разбивается одной из диагоналей на два вполне себе складных треугольника.

Исходный полигон

Полигон, триангулированный в Blender

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

Полигон в Unity с треугольником, близким к вырожденному (правый треугольник практически неотличим от отрезка)

Причиной проблем, связанных с вырожденностью полигонов, являются погрешности в вычислениях с плавающей запятой, а также особенности пиксельной интерполяции при рендеринге. С такими треугольниками происходит черт-те что: они дергаются, каждый кадр меняют цвет. Крайне малая величина поперечного сечения создает сложности при обработке света, из-за чего части динамических объектов могут мерцать. Да и в недетерминированности запекания карты освещения тоже нет ничего хорошего.

Я 3D-пакет, я так вижу

В 3D-моделировании часто возникает разница между фактическим количеством вершин и их количеством в 3D-пакете. Суть проблемы заключается в информации, которая требуется для обработки видеокартой. Структура данных для вершины предопределена и включает в себя позицию, нормаль, касательную, координаты текстурной развертки на каждый канал и цвет. То есть в одну вершину две нормали не запихнуть.

Для некоторых художников же не всегда очевидно, что вершина определяется не только своей позицией. Моделлеры прекрасно знают понятия Hard/Soft Edges и UV Seams, но не все осознают, каким образом они реализованы программно. Дополнительно сбивают с толку 3D-пакеты, которые в стандартном режиме показывают количество вершин как количество уникальных позиций.

Так, обычный примитив Cube геометрически представим 8 вершинами. Однако чтобы корректно передать отражение света от каждой грани и правильно наложить текстуру, в каждом углу куба необходимо по 3 вершины с одинаковой позицией, но разными нормалями и текстурными координатами, поскольку в каждом из углов сходится по 3 ребра. Этому моменту посвятили небольшой блок документации. Там же можно посмотреть примеры.

Метрики куба в Blender

Метрики куба в Unity

Хватит это терпеть!

Столкнувшись с этими и подобными проблемами, мы решили создать инструмент анализа и валидации моделей при импорте в проект Unity. Иначе говоря, кастомный валидатор, который на запрос «Ешь!» ответит: «Не буду! Переделывай», — или выплюнет наборы предупреждений и значений различных параметров, оповещая о том, что ему что-то невкусно.

Для анализа и проверки мы разработали следующий функционал:

Подсчеты количества уникальных позиций вершин, Hard Edges, UV Seams и раскрашенных вершин — необходимы для проверки соответствия задуманной художником модели той, что была импортирована в Unity. Этот функционал также позволяет следить за соблюдением требований к оптимизации модели (например, чтобы количество вершин не превышало определенное значение). Из-за все той же особенности 3D-пакетов, которые показывают по факту количество уникальных позиций, бывают случаи, когда метрика числа вершин в редакторе моделей удовлетворяет этому ограничению, однако после внесения файла в проект может оказаться, что это не так.

Вычисление AABB и его центра — позволяет определить смещение модели относительно начала ее собственной системы координат. Это необходимо для предсказуемого позиционирования ассетов, которые инициализируются в сцене уже во время работы приложения. Так, AABB здания по-хорошему должен иметь minY = 0, а какой-нибудь люстры, которая крепится к потолку — maxY = 0.

Выход координат вершин UV-развертки за диапазон 0.0–1.0 — в большинстве случаев (например, если текстура должна тайлиться на модели) предусмотрен. Часто такой подход используется для представления в сцене множества низкодетализированных мелких объектов (растительности) и/или находящихся вдалеке, а также замощения больших однородных объектов (зданий). В случае тайлинга значениям координат конкретного UV-канала просто обрезают целую часть на уровне шейдера, если Wrap Mode текстуры установлен в Repeat.

Представьте теперь, что вы уложили текстуру в атлас (и накрыли одеялком :3). В шейдер будут приходить уже преобразованные координаты, соответствующие атласу (x * масштаб + смещение). Никакой целой части на этот раз вероятнее всего уже не будет и обрезать будет нечего, а модель залезет на чужую текстуру (одеялко оказалось маленьким). Эта проблема решается двумя способами.

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

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

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

В опытном коллективе незамеченные на базовой развертке ошибки попадают в проект чуть чаще, чем никогда. Другое дело, когда меняются условия использования уже готового контента.

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

Пример базовой UV-развертки с наложениями (показаны красным)

Однако затем мы решили не использовать эти модели как динамические, а расставлять их в качестве статичного декора на уровне. Для оптимизации, как известно, освещение статических объектов в сцене запекают в специальный атлас. Отдельного UV2-канала для карты освещения у этих моделей не было, а качество работы автоматического генератора в Unity нас не устраивало, поэтому мы решили как можно чаще использовать базовую текстурную развертку для запекания.

Здесь и возникли явные проблемы с корректностью освещения. Очевидно, что лучи, попадающие какой-нибудь статуе в глаз, не должны создавать блики на пятой точке на затылке.

Некорректно запеченное освещение модели (слева) и исправленное (справа)

Unity при формировании карты освещения в первую очередь пытается использовать UV2-канал. Если он пустой, то используется основной UV, если и этот пуст, то извините, нате вам исключение. Запечь модели в карту освещения без предварительно подготовленного UV2 в Unity можно двумя способами.

В качестве первого Unity предлагает автоматическую генерацию UV2 на основе геометрии модели. Это быстрее, чем делать вручную, к тому же данный инструмент можно настраивать с помощью нескольких параметров. Но даже несмотря на это, итоговое наложение светотени часто неудовлетворительно для высокодетализированных объектов из-за швов и затеканий в неположенных местах, к тому же упаковка частей такой развертки не самая эффективная.

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

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

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

Источник