Самый технический шаг при подготовке к производству – пожалуй, подготовка четкой системы управления файлами, поскольку при создании движений и других игровых систем может потребоваться огромное количество файлов.
Список файлов анимации, экспортированных в движок
Общепринятые правила наименования файлов
Прежде всего стоит продумать систему наименования большого количества файлов анимации, над которыми часто работают самые разные специалисты – аниматоры, программисты и дизайнеры. Им приходится искать эти файлы среди длинных алфавитных списков, особенно в больших проектах. Цель любых правил наименования сводится к тому, чтобы наилучшим образом упорядочить группы связанных анимаций так, чтобы их можно было легко найти и чтобы по их названию было понятно, для чего предназначен тот или иной файл.
Лучший способ добиться такой четкости и понятности – группировать и называть файлы анимации сначала по персонажу (типу скелета), затем по типу анимации, затем по отдельной анимации, двигаясь от более абстрактного уровня к более конкретным описаниям. Ниже приведен пример простых названий файлов с тремя дескрипторами (описаниями групп), упорядоченных по алфавиту; в их названиях сначала указывается тип скелета, затем тип действия и в конце – конкретное действие.
Распространенная система именования файлов анимации, рассортированных по алфавиту
Не поддавайтесь искушению использовать слишком много сокращений (например, fw, bk, lt и rt для направлений движения)[6], поскольку в данном случае ясность и понятность важнее краткости. Добавляя к названиям файлов цифры, ставьте ноль перед числами 1, 2, 3 и т. д., чтобы не возникали проблемы с упорядочиванием файлов с числами после десяти (иначе файлы с добавлением к их названиям 1, 10 и 11 после упорядочивания могут оказаться перед файлами с добавлением 2, 3 и 4; к тому же так можно поддерживать одинаковую длину названий для аккуратного списка).
Самый ясный и популярный способ разделения дескрипторов – использовать нижнее подчеркивание; вместо подчеркивания можно использовать дефисы, но они читаются чуть хуже. Другой популярный способ – это так называемый верблюжий регистр (выделение отдельных слов заглавными буквами, например CamelCase), но он менее читаем из-за возможной путаницы букв с вертикальными элементами (t, d, f, h, k, l, b), не говоря уже о распространенной путанице между строчной L и заглавной i (l и I). Что касается пробелов, то их вообще не стоит использовать ни в названиях анимационных, ни в названиях экспортируемых файлов, поскольку они могут нарушить структуру ссылок на папки.
Большинство движков воспринимают не все символы, особенно знаки препинания, поэтому следует заранее узнать, какие символы недопустимы. Кроме того, иногда движки устанавливают произвольное ограничение на количество символов в имени файла. Стоит поинтересоваться у программистов движка, имеется ли в нем подобное ограничение, а также узнать, можно ли увеличить длину имени, потому что длинные названия по сравнению с сокращениями лучше описывают содержимое файла или ассета, и поэтому по возможности их лучше не сокращать.
Организация папок
Следующий шаг после названия файлов – организация их в структуру папок, которая должна быть понятна всем, кто захочет эти файлы найти. Как и правила именования, структура папок зависит от типа проекта, поэтому для начала стоит поинтересоваться, сколько ожидается отдельных файлов, как их можно сгруппировать, и, что очень важно, сколько предполагается в проекте уникальных анимаций персонажей и сколько общих для нескольких персонажей.
Если, допустим, все анимации каждого отдельного персонажа должны быть уникальными, а количество персонажей невелико, то имеет смысл просто сгруппировать все анимации в папке с именем персонажа (возможно, даже общей для хранения файлов модели).
Рекомендуемая структура папок для хранения файлов анимации в программе DCC
Однако, как это чаще всего бывает, анимации, общие для нескольких персонажей, требуют именования папок верхнего уровня в соответствии со скелетом, для которого они созданы, поэтому в качестве папки верхнего уровня будет использоваться имя скелета, а анимации будут храниться отдельно от моделей.
Альтернативная структура хранения файлов анимации разных персонажей
Однако такая структура неплоха только при прежнем условии, что скелетов несколько, а анимаций немного. Если для каждого персонажа имеется свой скелет, и если для каждого скелета или персонажа разрабатывается множество анимаций, то лучше упорядочить папки по типам движений с расчетом на то, что каждый тип (бой, навигация, подъем и т. д.) потребует действительно много анимаций.
Подгруппы папок для каждой из систем
В конечном счете выбор структуры папок обусловливается теми же соображениями, что и выбор правила наименования файлов, то есть они должны быть хорошо читаемыми и позволять быстро находить нужные файлы. Важно отметить, что для сокращения поиска и сокращения длинных адресов файлов лучше отдавать предпочтение неглубоким структурам папок.
Чтобы папки с файлами анимации не засорялись временными файлами, которые в любом случае не войдут в окончательную игру, для сохранения порядка стоит сохранять такие файлы в папке с названием «_test» или другими подобными названиями. Часто бывает, что некие файлы сначала используются в игре, а затем удаляются; их стоит не стирать, а перемещать в папку с названием «_cut» («вырезано») или подобным названием, чтобы их можно было легко восстановить без того, чтобы рыться в системе контроля версий. Префикс в виде нижнего подчеркивания «_» позволяет отображать эти папки в верхней части списка файлов.
Организация ссылок на файлы
Важный этап подготовки файлов к полноценному производству – это правильная настройка ссылок. Хотя эта функция доступна не во всех DCC, она является важной особенностью Maya, позволяющей вносить изменения во все анимации без пакетной обработки отдельных файлов (к которой прибегают в случае отсутствия такой функции). Поддержка ссылок – это возможность встраивать ссылку на один файл в другой, так что файл анимации будет содержать только ссылку на модель и риг, а не их уникальную копию.
Пакетная обработка, или «групповая обработка», – это запуск сценария для выполнения повторяющейся задачи в отношении нескольких файлов внутри папки, что значительно сокращает время и усилия, затрачиваемые на выполнение такой задачи вручную. Аналогичным образом для автоматизации повторяющихся задач в рамках одной сцены могут использоваться скрипты. Это может быть как простая привязка одного объекта к другому в определенном временном диапазоне, так и очистка всей сцены от лишних элементов, которые вызвали бы проблемы с экспортом. Чем сложнее процесс автоматизации (обычно требующий большего количества переменных), тем более сложный инструмент может потребоваться аниматору для взаимодействия с ним.
Поддержка ссылок позволяет техническому аниматору работать параллельно с игровым аниматором, вносить необходимые изменения в риг и видеть, как они автоматически отражаются во всех созданных к этому времени файлах. Скорее всего, при этом потребуется заново экспортировать все измененные файлы, в чем поможет пакетный скрипт экспорта.
В итоге получаются файлы анимации, содержащие только ключи и параметры анимации, что значительно сокращает их размер. При большом количестве анимаций это огромный плюс и экономия получается экспоненциальной.
Ссылки на файл рига внутри разных файлов анимации
Ссылки могут указывать не только на риги, но и на другие файлы, что позволяет обновлять несколько анимационных сцен с помощью всего лишь одной «мастер-сцены» с такими общими элементами, как геометрия окружения. Это очень удобно для длинных или сложных сцен, когда, например, один аниматор работает над сценой на борту корабля, к которому привязаны персонажи, а собственно анимацию корабля разрабатывает другой аниматор.
Экспорт
Как только будут созданы некоторые файлы анимации со ссылками на риги персонажей, пусть даже с предварительной или временной анимацией, техническому аниматору следует проконтролировать весь рабочий процесс и посмотреть, как эта анимация (и этот персонаж) отображается в игре. Это важно не только для того, чтобы убедиться, что движок правильно воспринимает риги и анимацию, но и для того, чтобы определить возможные задачи в общем процессе, на которые уходит слишком много времени. Любая неоправданно долгая задача на этом этапе может замедлить и даже загубить весь проект, так как будет тысячекратно повторяться во множестве итераций над множеством персонажей, особенно в крупном проекте на много лет.
Экспорт в Unreal из Maya
Формат экспортируемых данных
Экспорт анимации в видеоиграх мало изменился с момента появления 3D. По сути, он сводится к созданию экспортируемых файлов, которые, если рассматривать их по частям (через текстовый редактор), содержат списки значений вращения и/или положения костей всего скелета для каждого экспортируемого кадра. Единственным существенным изменением стал размер этих файлов, поскольку память (и процентное распределение общего объема памяти игры) для анимации увеличивается с ростом количества костей.
Форматы экспортируемых анимационных файлов часто зависят от игрового движка конкретной студии, хотя с повсеместным распространением в индустрии формата «.FBX», ставшего синонимом таких популярных движков, как Unreal и Unity, появилась определенная стандартизация. Хотя все типы экспортируемых данных имеют общий набор данных о костях, каждый из них имеет свои особенности и правила сбора этих данных, о чем должен знать аниматор.
Правила экспорта в движок
Игровым аниматорам нужно выяснить у технических аниматоров, какие правила обязательны, и придерживаться их.
Аниматорам-новичкам, только что приступившим к работе над проектом, в студии или на движке неплохо будет поинтересоваться следующими вопросами.
• Как задавать временной диапазон?
• Как задаются персонажи, если в сцене их несколько?
• Что можно и что нельзя нарушать в риге?
• Как экспортируются камеры и реквизит?
• Учитывается ли масштабирование костей? (Позиция и вращение обычно задаются, хотя если ключевые позиции не указаны, то они иногда игнорируются.)
• Какие дополнительные данные, например морфинг, может читать и экспортировать движок?
• Какие дополнительные или пропущенные элементы сцены могут привести к неудачному экспорту?
Большинство этих вопросов обычно задают только в том случае, если экспорт не работает, поэтому этим полезно поинтересоваться заранее в целях отладки.
Иногда экспорт проходит успешно, но анимация выглядит не так, как в DCC. В этом случае важно понять, почему движок может прочитать данные неправильно. Почти всегда оказывается, что причиной этому ошибка пользователя, а не какие-то ограничения экспорта. Поэтому техническим аниматорам и программистам движка следует как можно быстрее наладить безошибочный процесс экспорта, тем самым облегчив труд аниматоров.
Сжатие анимации для экономии памяти
На определенном этапе рабочего процесса, либо при экспорте, либо при сборке движком ассетов в игре, экспортированные файлы анимации будут подвергнуты сжатию в целях уменьшения занимаемой ими памяти, что, в свою очередь, к сожалению, приведет к снижению качества анимации в игре.
Стоит заранее узнать, как можно менять настройки сжатия каждой анимации, а не ждать конца проекта, когда время будет дорого стоить. Если учитывать ограничения памяти на протяжении всего проекта, то, возможно, ближе к окончанию работ и не придется снижать общее качество анимации за счет тотального сжатия всех ресурсов.
Разделение анимации
Нередко бывает так, что из одной сцены экспортируют несколько отдельных анимаций, то есть делают так называемую нарезку; так легче управлять несколькими действиями, необходимыми для одного движения или системы. Это также важный прием для создания плавных переходов между двумя состояниями или циклами, когда все соответствующие анимации хранятся в одной сцене и можно манипулировать кривыми, приводя их друг к другу. Экспортировать несколько анимаций из одной сцены довольно просто, достаточно установить временные диапазоны экспорта так, чтобы они следовали друг за другом, при условии, что все они экспортируются из одной сцены.
Одна анимация, разрезанная на несколько частей для экспорта
В приведенном примере переход transition_a_to_b может прервать цикл cycle_a в любой точке, но важно, что цикл cycle_b начинается в конце transition_a_to_b, поэтому получится согласовать скорость окончания анимации перехода с началом сycle_b.