Глава 7
Надежные, удобные для пользователя, гибкие персонажные сборки
Главная проблема персонажной сборки заключается в проверке того, сборка имеет все необходимые аниматорам настройки и возможности и в то же время является удобной для освоения и использования. Также она должна быть достаточно быстрой, чтобы позволять во вьюпорте воспроизведение в реальном времени или приближенное к реальному времени, насколько возможно. Есть много способов достичь этого – сделать сборку одновременно быстрой и мощной, а также включая создание особых сборок для каждого уникального набора задач, которые могут возникнуть в отдельном эпизоде, или построение уникальной сборки, которая делает 100% того, что нужно аниматору, за 90% времени (а в остальное время сборку можно дополнять и отлаживать). Скорость работы сборки даже более важна, если в каждой сцене у вас несколько персонажей. Например, вы добавляете специальное выражение, полагая, что оно будет быстрым, а оно обрабатывается всего несколько раз за кадр, благодаря чему аниматор хочет оторвать вам руки за замедление файла. Другой аспект, влияющий на скорость работы сборки, – это схема, организация управления персонажем и установление атрибутов управления. Мы поговорим о стратегиях улучшения этих аспектов сборки.
Особенности сборки
В общем, окончательное управление и опции сборки будут созданы сообща техническим директором по персонажам и ведущим аниматором. Вот несколько примерных требований Кейта Ланго (Keith Lango) относительно того, что ему нравится, и что не нравится в персонажных сборках:
Скорость: пусть она будет высокой;
Точность: для проверки поместите в сборку модель настолько высокого разрешения, насколько это возможно, без замедления скорости;
Опции: не вынуждайте нас решать проблему лишь одним способом;
Очистите те ограничивающие родительские системы, которыми легче управлять (больше инструментом, чем сборкой);
Запястью, которое следует направлению руки, нужна прямая кинематика даже в режиме инверсной и возможность переключать режимы. Так же создайте корректоры шарнирного соединения (gimbal correctors), которые можно переключать в случае необходимости;
Манипуляторы силуэта, позволяющие совершать такие деформации модели как растяжения. (для мультяшных персонажей);
Настолько гибкое лицо, насколько возможно;
Не бывает лишних ghost-ключей объектов. (Мы это часто видим на руках, когда в управлении нижней частью руки есть ghost-ключи для связанных с ней управляющих элементов, например, запястья, плеча и так далее);
Ясный, гибкий, полный пользовательский интерфейс. Любая попытка убрать беспорядок на экране будет большим благом;
Новая технология: обнаружение столкновений поверхностей в реальном времени (не кэшированная или построенная), отключаемое у каждого объекта. (Одна лишь эта технология может сэкономить студиям десятки миллионов долларов на стандартном высококлассном анимационном фильме, потому что она облегчит большую часть работы отделов, занимающихся устранением пересечений, столкновений, проникновений, плохого скиннинга и так далее.)
Это всего лишь простой пример того, чего хотят аниматоры. Некоторые из просьб бывает очень сложно выполнить, но большинство требований аниматоров примерно одинаковы: сделать быстрее, проще, как можно больше усилить управление и детализацию без снижения скорости и управляемости. Последнее требование обнаружения столкновений в реальном времени довольно разумно, потому что в «Суперсемейке» («The Incredibles») от Pixar скиннинг и настройка мышечных систем для аниматоров проходили почти в режиме реального времени, в том моменте где анимировался персонаж для финального рендеринга, а не персонаж низкого разрешения, который должен был пройти через симуляцию.
Врезка. Если вы работаете с другими программами, такими как Max или XSI, то вы должны по большей части уметь делать все то, о чем говорится в этой главе. Знайте, что в этом пособии мы часто используем группы, а они представляют собой лишь дополнительный узел-трансформы, как локатор или point helper в других программах. Существуют сценарии для Max, которые, например, имитируют групповую функцию Maya путем создания point helper и подчинения ему выделенного объекта. Вам не придется делать это вручную. На рисунке показан процесс риггинга в Max, обладающий большинством свойств риггинга в Maya (рис. 7.1).
@Рис. 7.1. Риггинг персонажа в Max
В Pixar для анимации использовалось собственное программное обеспечение. В Maya мы пока не можем получить мышечную систему в режиме реального времени, но такие программы, как Alias Motionbuilder, – это программные пакеты для анимации в реальном времени. В Motionbuilder еще нет мышечной имитации, но в нем можно проигрывать анимацию прошедшей скиннинг и анимированной модели так, как она будет выглядеть после рендеринга, без создания предварительного просмотра анимации, ради проверки тайминга. Поэтому Motionbuilder отлично экономит время.
Ускорение Вашей сборки
Помимо объективных факторов, которые могут замедлить сборку, таких как множество выражений или деформируемая кожа в файле, существуют и другие факторы, о которых нужно помнить во время создания персонажной сборки и проверки её скорости. Иногда документация и тренировочный материал для традиционных инструментов и сборок остаются без внимания. Если вы как технический директор работаете в одиночку, то вы должны убедиться, что у вас есть документация на сборки. Потому что когда вам понадобится потренироваться или выявить неисправности во время обычной работы, это может застопорить производство.
Изготовление коротких подробных учебных видеороликов – быстрый способ создать тренировочные материалы для ваших инструментов, по которым многие люди смогут учиться, и Вам не придется стоять рядом с ними и показывать, как работать со сборкой. Это преимущество: вы вводите людей в курс насчет инструментов быстрее, чем они бы прочитали документ, и никому не приходится показывать им, как все работает.
Обновление роликов о новейших инструментах также может занимать много времени. Хорошо, если у вас есть несколько роликов для сложных инструментов и есть небольшие, в которые удобно вносить некоторые изменения, например, запись обновлений, рассылаемая аниматорам по электронной почте. Часть вашей работы – исправление и обновление инструментов в течение всего производства, и поэтому нужен центр для предложений, ответов и исправления ошибок. Вы можете просто взять что-нибудь вроде общей крупноформатной таблицы Excel, которую просто и быстро сделать, или вы можете использовать готовую базу данных для отслеживания ошибок (bug-tracking database), например bugzilla с http://www.bugzilla.org, которая позволяет вести работу с большой группой аниматоров и удаленных рабочих. Другой способ создать живой документ по риггингу – сделать сервер WIKI, чтобы люди могли редактировать и обновлять информацию по мере необходимости, при этом без участия автора загружающего обновления контента. Зайдите на http://www.openwiki.com/ за более подробной информацией.
Другое, часто упускаемое из вида, требование к сборке это возможность контроля экспорта\импорта анимационных данных, так же как и любой другой внешней информации помещенной в сборку, в которой ещё не проставлены ключевые кадры. И здесь большинство анимационных систем терпят крушение, но поскольку мы используем двух скелетную систему, мы в любой момент можем переназначить скелет скиннига, анимированному скелету без совершения комплексных перемещений анимационных данных. Другой способ перемещения анимации включает в себя использование редактора Trax, с целью перемещения анимации между файлами сборок; или же использование собственных скриптов, сохраняющих и загружающих анимацию. Несмотря на то, что всё это больше относиться к области производства, чем к области риггинга, об этом должны позаботиться на ранних стадиях процесса.
Врезка. И в XSI, и в Maya имеются очень хорошие опциии экспорта\импорта анимации. В Max (без использования Character studio) есть только один инструмент для загрузки анимации – сценарий Merge Animation. Некоторые проблемы возникают и здесь, если ваши файлы не совсем совместимы; к счастью, это сценарий, который можно редактировать, подстраивая под нужды Вашего производства.
От предварительного скелета к сборке
Теперь, когда предварительный скелет персонажа из главы 6 построен, мы займемся следующей частью сборки. Это настоящий скелет, который вы будете использовать для создания скиннига модели. Этот скелет – основа всех остальных частей сборки. Все это можно автоматизировать, но мы сначала проделаем все операции вручную.
Ориентации сочленений шаблонного скелета выровнены по глобальной системе координат (рис. 7.2). После того, как мы сделаем новый скелет, ориентиры будут выровнены по сочленениям.
@Рис. 7.2. Выровненная по глобальной системе координат ориентация сочленений
Используя инструмент Joint и привязку к точкам (snap-to-point) (v – горячая клавиша) создайте новые сочленения поверх шаблонного скелета, используя его как точную схему для окончательного скелета. Привяжите первое новое сочленение к родительскому сочленению, и затем продвигайтесь вниз по левой ноге, пока не получите новый скелет (рис. 7.3). На рисунке (рис.7.4) показан этот только что созданный нами скелет с видимыми локальными осями вращения или ЛОВ (local rotation axis - LRA), так что вам виден окончательный результат создания новых сочленений. Взгляните на ориентации сочленений: теперь они выровнены по сочленениям, но не постоянны. Ими мы займемся потом, когда закончим остальные сочленения ноги.
Продолжая процесс привязки новых сочленений поверх шаблонного скелета, Вы закончите пальцами ног и привяжете их к новому скелету, завершив построение левой ноги.
@Рис. 7.3. Заново созданные сочленения
Исправляя ЛОВ скелета, в данном случае мы должны убедиться, что все они указывают постоянное направление. В случае с нашим персонажем мы направим ось Y вперед, благодаря чему все данные анимационной кривой оси Z после анимации будут постоянными. Это один из первых шагов к созданию надежного, легко анимируемого скелета. Даже простые системы прямой кинематики должны быть построены так, чтобы их можно было анимировать быстро и рационально.
Есть несколько способов редактировать ориентации сочленений, множество бесплатных сценариев в Web, но в Alias проделали большую работу, обновив их собственный инструмент Orient Joint (Ориентация сочленения) (рис. 7.4).
Врезка. Чтобы ориентировать конечные сочленения так, чтобы они совпали со своими главными сочленениями, просто выставьте параметры инструмента Orient Joint на none («никак»). Тогда LRA совпадут с главными сочленениями. Или можете просто установить ориентацию на нуль в Attribute Editor, но это нужно сделать одновременно для всех сочленений. Еще вы можете установить ориентацию сочленений на нуль с помощью Attribute Spreadsheet (Крупноформатная таблица атрибутов), которая, в отличие от Attribute Editor, позволяет редактировать множество значений одновременно.
@Рис. 7.4. Новый завершенный скелет ноги с отображенными LRA и новый инструмент Orient Joint
Примените один из инструментов ориентации и установите ориентации сочленений так, чтобы ось Y была направлена вперед, а Z указывала на правую сторону персонажа.
После того, как вы настроили ориентации ноги так, что все они обращены в одну сторону, вам, возможно, придется повернуть некоторые из них вручную, чтобы завершить выравнивание сочленений.
Доделайте всю левую сторону скелета так же, как вы делали левую ногу, и убедитесь, что все LRA сочленений настроены правильно.
Меняя настройки Second Axis World Orientation (Глобальной ориентации второй оси) инструмента Orient Joint, можно установить LRA на руках и пальцах. Пальцы рук, ребра и грудную клетку сложнее настроить из-за их необычного ветвления и произвольных углов.
Чтобы LRA родительского сочленения выровнялись с первым сочленением позвоночника, нужно разбить подчинение ноги основанию позвоночника, настроить ориентацию сочленения и потом вновь установить родительскую связь ноги. Вы можете настроить это и вручную, но по-нашему получится немного быстрее.
На рисунке показаны окончательные ориентации сочленений скелета (рис. 7.5).
@Рис. 7.5. Законченная левая половина скелета с отлаженными LRA
Прежде чем зеркально отразить ногу и руку, мы займемся присваиванием имен всей иерархии сочленений. Подбирайте короткие и понятные имена, и не меняйте правила постановки пробелов, строчных букв и номеров в названиях. В этой книге мы постарались использовать короткие подсказки в начале имени, например bn_upArm_L: сочленение это или кость, часть тела, сторона тела.
Теперь мы опустим префикс bn, до тех пор, пока сборка небудет закончена. Пока скелет еще не прошел риггинг, вы можете сделать набор выделений для отдельных сочленений, чтобы упростить выделение и переименование в будущем:
С помощью встроенного инструмента Prefix (Префикс) можно добавить L или R в начало названия каждого сочленения в иерархии, но мы предпочитаем, чтобы это было указано в конце названия, и тут инструмент Prefix нам не поможет. Мы собираемся сделать это с помощью инструмента Rename (Переименовать), который сделал Майк Комет. Он выпустил очень удачный набор Mel-инструментов и плагинов для технических директоров.
После того, как вы добавили суффикс, зеркально отразите руки и ноги и удалите временный скелет.
Врезка. Для именования правых и левых частей есть опция инструмента Mirror (Зеркало), чтобы, например, заменить L на R. Но тогда любое L в названии будет заменено на R; можно заменить _L на _R, и тогда замена затронет только L с подчеркиванием. Это одна из причин, по которым мы оставили префикс bn на потом, когда скелет будет отражен, чтобы инструмент Mirror не переименовал bn_leg_L в bn_Reg_R. Вы также можете применить скрипт Майка Комета rename, чтобы выполнить поиск и замену в отраженном скелете, не обращаясь к опции переименования инструмента Mirror.
Скрипты Майка Комета можно скачать с http://www.comet-cartoons.com.
Последнее, что нужно сделать с этим скелетом – сгруппировать его и назвать новый узел группы pgSkeleton: pg – сокращение от pigGoblin, а Skeleton – то, что содержит группа. Сделав это, мы сохраним независимое от персонажа название скелета, а также убережем имена скелета от влияния различных проблем именования, если в одном файле будут загружены несколько персонажей. Если бы мы установили префикс pg для всего скелета и рига персонажа, то переносить анимацию с одного персонажа на другой стало бы сложнее, удлинились бы имена файлов, предназначенных для экспорта в игровой движок, и стало бы труднее сортировать узлы и работать с ними в Outliner (рис. 7.6).
@Рис. 7.6. Сгруппированный скелет в Outliner
Скрытые имена и редактор Trax
Обновленные возможности редактора Trax в Maya 6 позволяют переносить анимацию со скелета на скелет. Trax можно использовать для перенесения анимации одного и того же скелета в другие файлы, а можно заново отображать или перенаправлять движение на скелет, отличающийся и по размеру, и по пропорциям. Чтобы сделать это и удостовериться, что скелеты по крайней мере совместимы с маппингом в Trax, нужно воспользоваться Joint Labeling (Маркировка сочленений) из меню Skeleton → Retargeting (Скелет → Перенаправление) (рис. 7.7).
На рисунке показаны Joint Labels (Метки сочленений); завершив работу с метками, мы отключим их (рис. 7.8).
Есть ещё несколько вещей, необходимых для хорошей работы Trax, но для основных возможностей перенаправления анимации Вам достаточно и этого.
Мы сосредоточены на создании надежного скелета, который войдет в процесс настройки и станет для нас наилучшей основой. Trax дает нам еще одну причину сохранять постоянную ориентацию сочленений всех скелетов. Ведь для того, чтобы быстро передать схему движения от одного скелета к другому, местные оси вращения должны совпадать или быть очень близки к скелету. Иначе скелет может повести себя непредсказуемо: ноги и руки начнут вращаться в разных направлениях. Это совсем не то, что нам нужно.
Теперь, когда файл скелета готов, мы продолжим работу с файлом сборки, в котором организуем управление и подключим системы, которые в конечном счете будут управлять этим скелетом.
@Рис. 7.7. Отображение названий сочленений в Trax
@Рис. 7.8. Законченные метки сочленений
Врезка. Взглянув на скелет Вы, возможно, подумаете, что он еще не готов, так как у персонажа есть разнообразные ремни, броня и оружие. Вы будете правы, к сборке осталось прикрепить ещё несколько вещей. Но мы посчитали, что всё это будет во вторичном проходе скелета, оставленном на потом, так как всё это не обязательно для основных движений персонажа. Также вам понадобится файл, которым вы могли бы снабдить аниматоров для проверки, и чем скорее, тем лучше. Эти предметы также можно считать элементом симуляции, которая требует несколько иного управления, нежели анимационная сборка.
Файл сборки: геометрия низкого разрешения
Файл сборки сохранен как rig_имяПерсонажа, в данном случае rig_PigGoblin, и в этом файле мы настроим прокси-геометрию (proxy geometry), а также все компоненты сборки, необходимые для анимации.
Так как мы хотим отдать этот файл аниматорам как можно скорее, то для нас нежелательно, чтобы они ждали, пока мы сделаем скиннинг, прежде чем начнут тестирование риггинга или анимацию. Модель низкого разрешения можно создать несколькими способами; это даже можно автоматизировать, как показано в мастер-классе по Maya «Hyper-Real: Body Setup», который сделал Пол Туриот. В этом случае для его скрипта создания геометрии низкого разрешения вам нужна законченная или почти законченная модель, прошедшая скиннинг, но тем не менее скрипт работает очень быстро, если вы хотя бы сделали хотя бы быстрый скиннинг.
Недостаток состоит в том, что для скрипта Вам нужен уже законченный меш, но во многих случаях сборка нужна до того, как модель завершена. Можно ускорить процесс, если моделер построит модель низкого разрешения. Тогда технический директор может прикрепить его к скелету и не дожидаться окончательной модели. Вне зависимости от того, как вы построите прокси-модель, она должна быть разделена на сегменты, воспроизводящие объем персонажа, чтобы аниматор мог знать, возникнут ли проблемы пересечения во время анимации, когда она будет применена к готовой модели. Прокси-модель должна быть очень легкой с как можно меньшим количеством полигонов, но все-таки оставаться как можно ближе к форме финальной модели. Так же в ней должен быть один объект на сочленение, чтобы подчинить или прикрепить его к скелету. Некоторые делают скиннинг геометрии низкого разрешения, но это только приводит к замедлению, что нежелательно.
Врезка. Небольшой совет о прокси-моделях. Чтобы помочь аниматорам сделать их скручивания и вращения наглядными, вы можете провести полосы через отдельные полигоны модели, нанеся на них простые материалы.
Так как скелет для скиннинга и скелет сборки – это отдельные файлы, с файлом сборки мы можем делать все, что угодно. Прокси-геометрия отлично подходит для риггинга Прямой Кинематики. Например, в отличие от всех этих дополнительных узлов-трансформ, путающих нашу иерархию, прокси-объекты могут просто подчинять свои shape-узлы сочленениям. Дополнительные узлы исчезают из главной схемы сцены, и объекты будут выступать в качестве выделяющего манипулятора сочленений, когда вам понадобится анимировать их в ПК.
1. Если вы просто напрямую подчините shape-узлы сочленениям, форма выровняется так, чтобы совпасть с ориентацией сочленения.
2. Чтобы поработать над этим, сначала сделайте модель дочерней по отношению к ноге, заморозьте перемещения, чтобы обнулить модель, и потом подчините shape-узел сочленению. На Web-сайте книги http://www.courseptr.com/downloads есть бесплатный сценарий под названием bcParentShape.mel. В нем используется базовая Mel-команда parent -s -r, выделение сочленения и формы меша.
3. После создания дочерних связей просто переименуйте узлы форм, чтобы они соответствовали сочленениям, к которым прикреплены. Приведем родительское сочленение в качестве примера: имя формы должно быть root_prxy_Shape, чтобы потом вы смогли быстро разобраться в прокси-геометрии. Вы можете прикрепить все shape-узлы к скелету сейчас или подождать, пока сборка будет готова.
4. Последняя отладка пользовательского интерфейса для аниматоров – установление цвета скелета, его левой и правой частей и центра. Некоторым людям нравится делать это с помощью слоев, но мы предпочитаем работать прямо с персонажем, не заботясь о наличии или отсутствии слоев в файле. На рисунке показано, как применять параметры Drawing Overrides к верхнему сочленению иерархии, чтобы раскрасить ее ветви: голубой для середины, зеленый для левой стороны, красный для правой (рис. 7.9). То же самое можно сделать в Max, да и в большинстве 3D пакетов предусмотрен такой способ раскраски. Обратите внимание, что мы выбрали тусклые цвета, поэтому когда мы потом раскрасим элементы контроля анимации, сможем взять более яркие оттенки красного, синего и зеленого. Они будут лучше видны, и их будет проще выделить.
Теперь мы создадим слой для «prxy» геометрии. В поле быстрого выделения (quick-select field) просто напечатайте *prxy*, и будут выделены все части меша, которые можно добавить в новый слой, названный mdl_prxy_PG. Вместо слоя для управления свойствами геометрии prxy можно использовать заданные атрибуты. Чем меньше слоев, тем лучше, потому что они легко выходят из строя и вносят беспорядок в анимацию.
@Рис. 7.9. Раскраска левой и правой частей скелета.
Врезка. Если вы применяете слои в прокси-геометрии, настройки цвета слоя будут перекрывать цвета меша. Если вы не хотите, чтобы это произошло, можете сами задать цвета меша. Можно воспользоваться MEL-командой color -ud # 1-8 или элементом пользовательского интерфейса из меню Display Wireframe Color (Отобразить Цвет Каркаса), чтобы применить цвета к прокси-геометрии. На них не повлияет слой, которому они приписаны. Другая хитрость – проверить, что что-нибудь, например ключевой кадр, соединено с перекрывающим цветом, прежде чем приписывать его слою.
Файл сборки: конструирование и планирование сборки
В зависимости от вашего места в производстве и от того, когда вы приступаете к риггингу, нужно идти навстречу аниматорам, и создавать необходимые для работы сборки компоненты. Однако так почти никогда не происходит, и построение рига, который легко отлаживать и на котором удобно основываться в будущем – цель правильного планирования.
Врезка. Не забудьте, что это файл сборки, так что мы можем дополнять иерархию, добавлять атрибуты, динамику и все, что угодно, потому что настоящий скелет, предназначенный для скиннинга, находится в другом файле. Преимущество простого скелета в качестве базового файла для рендеринга заключается в том, что мы можем смешивать сколько угодно входных данных в скелете для скиннинга, будь то ключевой кадр, данные motion capture или имитации. Разделение файлов также упрощает обновление сборки по эпизодам, протяжении производства, и можно не беспокоиться о каких-либо сбоях в файле для рендеринга или экспорта (если речь идет об игре). Недостаток же состоит в том, что если Вам нужно приспособить скелет для какой-либо цели, то синхронизация файлов двух этих скелетов может быть довольно сложной, и это главное обоснование скриптовой системы сборок, где изменения занимают минуты, а не часы.
Когда Вы только сели создавать сборку, вы можете задействовать свои старые приемы и хитрости. Некоторые вещи требуют новых решений и позволяют экспериментировать с разными интерфейсами для аниматоров. Этот персонаж, в общем-то, – обычное двуногое существо, и поэтому можно воспользоваться некоторыми техниками риггинга, которые были хорошо описаны в первой книге «Inspired 3D Character Setup»; многие техники доступны в форме бесплатных файлов и руководств в Internet. Учитывая особенности нашей сборки, можно на основе этих материалов построить профессиональные элементы интерфейса для гибкости и скорости. При этом для аниматоров он должен быть как можно менее сложным. Это непростая задача, но когда вы поймете основные идеи, вы легко ее выполните.
Изучение Свинячьего Гоблина
При риггинге этого персонажа возникают очевидные сложности, особенно это касается ног. Мы просмотрели огромное количество справочников и изучали работу ноги и стопы человека, но ноги этого персонажа – ноги существа, похожего на свинью, и их пропорции сильно отличаются от пропорций нормальных ступней. Мы понимаем анатомию, и поэтому знаем, что в ноге животного не больше сочленений, чем в человеческой ноге. Это хорошая новость, потому что в таком случае мы можем взять то, что описано в сотнях учебных пособий и что представляет собой реверсную ногу персонажа. Но проблема все-таки в том, что из-за изменений в пропорциях и из-за типа управления ногой, которое мы хотим установить, нормальная реверсная нога, как в сборке персонажа-человека, здесь работать не будет.
Врезка. Различие здесь в том, что для построения стабильной сборки ноги этого персонажа нам нужно запустить IK манипулятор там, где должен быть подъем свода стопы двуногого существа, но у нашего персонажа это больше похоже на лодыжку. Таким образом мы ограничим контроль над этой частью персонажа, который, возможно, хотел бы получить аниматор. В XSI есть очень подходящий ИК решатель под названием «Dog Leg» («Собачья нога»), и в Motionbuilder от Alias тоже есть очень хорошая сборка четвероногого существа. В обоих присутствуют специально написанные ИК решатели, сконструированные для решения особых проблем, которые возникают при риггинге таких персонажей. В Maya нет таких решателей, так что нам придется их сымитировать.
Есть несколько способов настроить эту ногу так, чтобы аниматор имел над ней хороший контроль. Первый и самый простой – просто провести одну цепочку ИК вдоль трех сочленений ноги. Это работает хорошо, но вы не получите по-настоящему полного контроля над этими тремя сочленениями. Жесткость сочленений может помочь в управлении решателем, также хорошо может сработать настройка предпочтительных углов сочленений. Но в обоих случаях есть и недостатки. Проблема настройки жесткости в том, что она замедляет ИК решатели сочленений, ей сложно управлять, и она может привести к блокировке или скачкам сочленений. Предпочтительный угол, в отличие от настройки жесткости, не связан с проблемой замедления, но вам придется установить его раз и навсегда, впрочем Вы также можете и анимировать предпочтительный угол, но лишь слегка, до того, как ИК будет привязана и придет в действие. Так можно поступить, если вам требуется дополнительная гибкость сочленений, но будьте осторожны.
Стандартный метод риггинга реверсной ноги тоже сработает: вы можете настроить ее как обычную ногу, стоящую на пальцах. Только тогда аниматору придется все время анимировать два элемента управления вместо одного; иначе стопа будет выглядеть жесткой и неестественной. Вы не добьетесь ощущения слаженной работы всей мышечной системы, вместо этого вы получите ощущение, что верхняя и нижняя часть ноги разъединены в лодыжке, а это совсем не то, чего мы хотим.
В последнем способе настройки ноги используется смешанная техника, дающая одинаковую работу ИК-решателей всех трех сочленений, чего мы и хотели добиться с помощью первого метода. Но здесь нужно дополнительное управление «гибкостью» («flex») и «силой» («force») лодыжки и колена.
Чтобы рассчитать, как будет работать эта сборка, мы сделали простую и быструю проверку сочленений, не заботясь о том, так ли это всё будет работать на настоящем скелете. На рисунке изображен набросок NURBS-кривой ноги, используемой в скиннинге скелета (рис. 7.10). Проделав это, мы можем наскоро анимировать, чтобы увидеть, не задерживается ли что-нибудь. Так же это быстрый способ обнаружить неправильные или нестабильные действия сборки, так как прошедшая скиннинг кривая отразит такие действия лучше, чем просто сочленения. Так же в Maya запланировано смешивание ИК и ПК, и настал подходящий момент его опробовать. Отметьте, что стопа не настроена, это просто проверка ноги.
Риггинг ноги свиньи
Для начала мы будем работать только с одной стороной, так что скройте сочленение правой ноги (рис. 7.11).
Теперь сделайте дубликат левой ноги и переместите его назад, чтобы ноги не перекрывали друг друга (рис. 7.12).
Удалите prxy-модель и сочленения ноги и пальцев, чтобы это выглядело как на рисунке (рис. 7.13). Эта новая цепочка сочленений станет управляющей для оригинальной цепочки. Раскрасьте ее в ярко-желтый. Теперь её хорошо видно, и вы будете знать, что желтые сочленения принадлежат сборке, а не исходному скелету свиньи. С помощью инструмента Prefix Hierarchy (Иерархия префиксов) мы назовем эту новую цепочку с префиксом ctrl_. Это всего лишь еще один способ сохранить организацию файла, но вы можете использовать любую другую схему присваивания имен (рис. 7.14).
Врезка. Раздел Notes (Заметки) в Attribute Editor поможет в создании сборки. В нем легко хранить заметки и подробности риггинга объектов в независимой от названия форме, так же при необходимости, можно экспортировать эти заметки в отдельный файл с помощью Mel-сценариев. Вы также можете использовать заметки для хранения собственных данных для игр. Эквивалент Notes в Max –User Properties (Пользовательские Настройки). Этим свойством обладают все объекты.
@Рис. 7.10. Быстрый тест ноги
@Рис. 7.11. Скелет и модель приготовлены для риггинга
@Рис. 7.12. Дублированная нога
@Рис. 7.13. Дублированная нога сдвинута назад
@Рис. 7.14. Сборочная нога окрашена, добавлены заметки
Теперь мы добавим наш первый IK Handle в скелет ctrl от верхнего сочленения до нижнего. Назовем его ik_fullLeg_L и запомним, что «эффектор» (effector), созданный вместе с манипулятором, тоже нужно назвать. Переименуйте его в ef_fullLeg_L (рис. 7.15 и 7.16).
Теперь добавьте IK манипулятор в исходную ногу от upLeg_L до середины ноги и еще один от foot_L до лодыжки модели, сочленения ball_L. Назовите их как раньше, ef_имясочленения_L и ik_имясочленения_L (рис. 7.17).
Привяжите ногу ctrl к исходной ноге, чтобы можно было соединить их вместе. Также вы должны привязать манипулятор ik_fullLeg_L к оригинальному положению (ball_L) (рис. 7.18).
@Рис. 7.15. ИК целой ноги
@Рис. 7.16. Переименованные элементы ИК и эффекторы
@Рис. 7.17. Еще две цепочки ИК дадут вам дополнительное управление ногой
@Рис. 7.18. Дублированная нога прикрепляется обратно к бедру
Подчините ik_lowLeg_L сочленению ctrl_lowLeg_L, а ik_foot_L – сочленению ctrl_foot_L с помощью подчинения drag-and-drop в Outliner. После этого манипуляторы станут желтыми. Это означает, что они под правильными сочленениями. Проверьте, выделив и переместив ik_fullLeg_L; два скелета должны двигаться вместе (рис. 7.19). Отмените действие, чтобы вернуть ногу в исходное положение.
@Рис. 7.19. Проверка ИК новой ноги
Чтобы наш риг как можно дольше оставался обнуленным, мы сгруппируем IK манипуляторы так, чтобы подготовить их к анимации и заморозке трансформаций. Не забудьте сначала подчинить/создать группу для них перед тем, как заморозить трансформации, чтобы они не разморозились, если вы снова сделаете их дочерними чему-нибудь, перед тем как Вы измените пространство, в котором они были обнулены.
Выделите ik_foot_L и заморозьте трансформации, чтобы они были на нуле.
Выделите ik_lowLeg_L и сгруппируйте. Точка опоры группы будет находиться в месте нахождения родительского объекта ИК-манипулятора, но нам нужно переместить ее к лодыжке (рис. 7.20 и 7.21).
@Рис. 7.20. Сгруппированный ИК-манипулятор
@Рис. 7.21. Правильное положение центральной точки группового узла force
Переименуйте эту группу в ctrl_force_lowLeg_L, и она станет управляющей для изменения силы (взято у Майка Иснера (Mike Isner)), как только мы немного погодя добавим в нее элемент управления с помощью нашей хитрости подчинения формы.
Снова выделите ik_lowLeg_L и заморозьте его трансформации.
Последнее, что нужно сделать, – проверить, локальная ось вращения ctrl_force_lowLeg_L установлена так, что положительное вращение Z направлено вперед и совпадает с остальными частями сборки. Выделите ctrl_force_lowLeg_L и отобразите его ЛОВ. После этого выделите и согласованно вращайте ЛОВ (привязка вращения (rotation snap on)) до тех пор, пока ЛОВ не повернутся на 180º вокруг X.
То же самое можно сделать с одной лишь помощью Attribute Editor. Сначала установите атрибут Rotate Axis (Вращение оси) на -180 по X. Потом установите атрибут Rotate X (Вращение по X) на 180. Если вы теперь проверите вращение, то увидите, что оно все еще вызывает отрицательные вращения, но это легко исправить, установив Rotate Order (Порядок вращения) ZYX, а не XYZ. Это сработает, потому что мы верно направили ЛОВ; нам лишь осталось изменить то, как матрица вращения соединяет вместе Эйлеровы $$ От термина «Эйлерово вращение» - обозначающего метод специфического угла вращения по осям X Y Z – Прим ред. $$ каналы чтобы получить положительное значение вращения по Z. На рисунке показаны окончательные настройки ctrl_force_lowLeg_L (рис. 7.22).
@Рис. 7.22. Окончательные настройки, включая порядок вращения и Rotate Axis.
Обнуление управляющих элементов
Если вас беспокоит, что поворот на 180 после того, как его зафиксировали и спрятали, остался видимым, то знайте, что это не имеет никаких побочных эффектов. Но давайте рассмотрим еще два способа решения этой проблемы:
1. Первый способ – сгруппировать ctrl_force_lowLeg_L и назвать группу ctrl_force_lowLeg_Zero_L. Она пригодится для ориентации и обнуления настоящих объектов управления.
2. Поверните ctrl_force_lowLeg_ Zero_L на 180º по X и убедитесь, что и Rotation, и Rotate Axis дочерней ей ctrl_force_lowLeg_L теперь обнулены. На этот раз порядок вращения может быть оставлен XYZ. Продолжайте работу с ИК-манипулятором и проверьте также его обнуление. Если вы повернете ctrl_force_lowLeg_L по Z в положительном направлении, то нога должна согнуться (рис. 7.23).
3. Второй способ – использовать отдельное сочленение. Используя сочленение в качестве родительского объекта ik_lowLeg_L, вместо обычной группы, вы сможете использовать Rotate Axis и Joint Orient и зафиксировать Z так, чтобы ее повороты были положительны, а значения вращений оставались нулевыми. При этом Rotate Axis установлено на 180, Joint Orient – на -180, а Rotate Order не тронут. Так мы его и оставим, потому что нужно рассчитать меньшее количество узлов.
@Рис. 7.23. Положительное вращение контроллеров по оси Z, так же как и в ПК скелете.
После того, как вы определитесь с желаемым способом управления атрибутом force, установите пределы вращения, чтобы контроллер силы не мог повернуть ногу за точку отрыва от цепочки другой ноги. Для этого установите Rotation Limit (Предел вращения)- Min: -30 и Max: 45. Вы можете уменьшить или увеличить эти значения так, как вам нужно, но эти значения так же хорошо подходят, предохраняя ногу от крушения, в то же время давая широкий круг движений.
1. Мы сгруппируем контроллер ik_fullLeg_L с самим собой, подгоним точку опоры так, чтобы она совпадала с нахождением ИК-манипулятора, а потом заморозим перемещения группы и ИК-манипулятора.
2. Назовем эту новую группу ik_fullLeg_Zero_L.
3. Теперь спрячем ногу ctrl, пока не закончим риг стопы. Создавая контрольные формы стопы, мы также сделаем контрольную форму узла force.
Врезка. Возможно, вы заметили, что мы пока ничего не заблокировали. Мы оставим это до следующего прохода, зная, что значительные изменения или отладка не потребуются, и не будем тратить время на разблокировку/отображение скрытого, когда находясь посреди процесса построения сборки. Еще одно преимущество ожидания окончания риггинга в том, что можно сохранить или записать в Mel блокировку и скрытие всех атрибутов рига, благодаря чему вы сможете быстро отменить или повторить действие в течение процесса риггинга.
Риггинг ступней свиньи и узлы точек опоры
В этом разделе мы рассмотрим реверсную стопу, которую все знают и любят, но наш подход немного отличается от того, как обычно делается стандартная реверсная стопа.
Как и в любой другой реверсной стопе, нам нужно добавить несколько ИК-манипуляторов сочленениям стопы. Назовем их ik_toe_L и ik_toeTip_L и точно также поступим с конечными эффекторами (end effectors) (такие же имена, но вначале ef вместо ik).
Теперь сгруппируем каждый новый ИК-манипулятор и назовем новые группы так же, как раньше нулевые узлы, например, ik_toe_Zero_L. Привяжите точку опоры группы к месту соответствующего ИК-манипулятора.
В нашем случае кончик пальца будет в основании модели пальца, а не там, где находится ИК-манипулятор, из-за положения сочленения кончика пальца и угла стопы (рис. 7.24).
@Рис. 7.24. Положение точки опоры пальца ноги
Врезка. Благодаря этому отдельному слою сборки, нам не приходится подстраивать положение скелета, чтобы элементы контроля анимации находились в нужных для их корректной работы местах. Если бы нам пришлось сдвинуть скелет, то синхронизация сборочного скелета со скелетом для скиннинга нарушилась бы, что привело бы к проблемам в будущем. Синронизация также может нарушиться из-за изменений в модели после создания скелета или изначально неправильного положения модели или сочленений. В условиях нелинейного процесса производства часть работы каждого технического директора по персонажам – заниматься такими изменениями. Создание сборок с отдельными слоями, работающими со скелетами, позволяет вносить небольшие изменения, не повреждая всю сборку.
В большинстве руководств по реверсной стопе говорится только о настройках управления основными шаговыми движениями, не позволяющими добавить дополнительной гибкости, добавление которой делает управление анимацией более комплексным и создает много дополнительных опций.
Стопа позволяет совершать много движений и так же является базой персонажа. Наблюдая за 3D персонажами, вы можете заметить, что у большинства из них стопа не двигается или не взаимодействует с поверхностью земли как следует. За это отвечают преимущественно аниматоры, но именно Вы должны создать сборку, позволяющую совершать более сложные движения.
1. Создайте родительские связи между ИК-группами, чтобы сначала сделать нормальную иерархию реверсной стопы, а потом по необходимости расширить управление дополнительными группами (точками опоры).
2. Возьмите ik_fullLeg_Zero_L и подчините его ik_toe_Zero_L.
3. Подчините ik_toe_Zero_L элементу ik_toeTip_Zero_L, чтобы получить иерархию как на рисунке (рис. 7.25).
Это позволяет стопе перекатываться вперед, но не без пятки. Мы сгруппируем ik_toeTip_Zero_L и поместим точку опоры этой группы на место нахождения пятки в модели (рис. 7.26).
@Рис. 7.25. Заключительное подчинение ИК стопы
@Рис. 7.26. Положение точки опоры пятки
4. Назовем ее ik_heel_Zero_L. (Несмотря на то, что она не управляет непосредственно ИК-манипулятором, она контролирует все манипуляторы, так что для сохранения оговоренной схемы присваивания имен мы назовем ее ik_heel.) Так как мы выбрали предпочтительную схему вращения скелета персонажа, нужно убедиться, что наши управляющие элементы системы ИК работают таким же образом и на вращении. Мы хотим, чтобы у аниматора была четкая схема вращения любого элемента управления, который может вращаться, так что мы должны помнить об этом и проверять, что у таких элементов, как ctrl_foot_L есть схема вращения, которая соответствует вращению скелета в ПК. В нашем случае положительное вращение Z направлено вперед.
5. Применяя для правильной ориентации вращения такие же техники, как в случае с ctrl_force_lowLeg_L, вы создадите управление стопой с сочленением. Создайте новое сочленение и установите его в начальной точке 0 0 0. Назовите его ctrl_foot_L.
6. Сгруппируйте его и назовите группу ctrl_foot_Zero_L. Привяжите ее к местоположению лодыжки. Если вы заморозите перемещения узлов групп, то они обнулятся, но при этом обнуление передастся дочерним сочленениям, а этого вам не нужно. Вам нужно, чтобы они обе были на нуле.
7. Чтобы основные перемещения сочленения после того, как вы переместите его к лодыжке, были нулевыми, вновь отобразите в Channel Control (Управление каналами) атрибуты rotate pivot translate родительской группы ctrl_foot_Zero_L. Скопируйте значение перемещения в соответствующую графу rotate pivot translate и обнулите атрибут translate. Теперь сочленение будет на нуле и в нужном месте. Просто спрячьте или заблокируйте значения перемещения точки опоры, когда закончите, и сделайте пометку в Attribute Editor Notes (Заметки в редакторе атрибутов), что это место, где производится перемещение объекта. Окончательный результат таков: управляющий элемент стопы обнулен, и его положение совпадает с ПК сочленением. Это пригодится потом, когда вы захотите перенести значения вращения от ПК-сборки к ИК-сборке, также это позволит вам зеркально отразить контроллеры вращения ИК-сборки. Единственное различие в том, что управление ориентировано на прямые углы, так что значение X не выровнено по сочленению, как у настоящего сочленения лодыжки.
8. Нам нужно сделать управляющий манипулятор для этой стопы. Он может быть любой формы. Мы используем сферическую форму: три NURBS-круга дочерние ctrl_foot_L. Вместо этого можно взять кривую в форме стопы, стоящей на земле.
9. Назовите каждую кривую ctrl_Foot_L_Shape (рис. 7.27). Они станут родителем для ik_heel_Zero_L. Лучше, чтобы управляющий элемент стопы располагался на лодыжке, полностью контролируя стопу, когда она над землей, и контролируя другие точки опоры, находясь в контакте с землей. В других персонажных сборках главное управление стопой часто расположено на подъеме свода стопы, а это может вызвать нежелательные или дополнительные движения, которые нужно анимировать по-другому.
10. Наконец, установите порядок вращения на ZYX. Он стабильнее при вращении, потому что значение X потом будет управлять скручиванием ноги, а это поможет удержать колено он непредвиденного скручивания из-за вращений шарнирного соединения (gimbal).
@Рис. 7.27. Новые контрольные формы, подчиненные управлению стопы
Подробнее о реверсной стопе
Следующие шаги и всю иерархию стопы можно упростить, используя возможность анимировать узловую точку опоры, но для совместимости программного обеспечения с потребностями риггинга и для большей гибкости в смешивании поз стопы мы настроим их как обычно, то есть каждая точка опоры будет узлом иерархии.
1. Во-первых, давайте добавим дополнительные узлы, которые нужны для движения стопы с боку на бок. Нам нужны дополнительные узлы, чтобы повернуть стопу, не нарушая связи с ее остальными движениями.
2. Выделите ik_toe_Zero_L и дважды его сгруппируйте. Назовите эти две группы instep_pvt_foot_L и blade_pvt_foot_L (рис. 7.28). Главная точка вращения этих двух объектов должна находиться около подъема свода стопы, так как именно там стопа все время соприкасается с поверхностью. Разместите здесь точки опоры двух узлов, blade_pvt_foot_L – снаружи стопы, а instep_pvt_foot_L – внутри (рис. 7.29). Когда расположение точек вас удовлетворит, и покрутите их, чтобы убедиться, что они качают стопу из стороны в сторону. На этом этапе в стопе много элементов управления, которые, придавая ей большую гибкость, заставляют аниматоров работать со слишком большим количеством узлов и управлять их ключевыми кадрами. Чтобы исправить это, мы воспользуемся идеями Джейсона Осипы - упростим интерфейс, создав джойстиковое управление вращателем стопы (foot roller joystick control).
@Рис. 7.28. Точки опоры в иерархии сборки стопы
@Рис. 7.29. Центральные точки для края и ребра стопы
3. Создайте локатор или нулевой объект, прикрепите его к сочленению лодыжки и заморозьте его перемещения. Назовите его ctrl_foot_roller_L. Это будет наш управляющий узел (рис. 7.30).
@Рис. 7.30. Управление вращателем
4. Для управления всеми узлами вращения стопы от перемещения элемента, управляющего вращателем стопы, мы применим Set Driving Keys. Откройте окно Set Driven Key (Установить управляемый ключ) и возьмите в качестве контроллера ctrl_foot_roller_L. Выделите узлы поворота стопы (рис. 7.31) и загрузите их как управляемые. Перемещение Z у ctrl_foot_roller_L будет управлять движением подъема свода стопы вперед и назад; поворот X – других управляемых объектов.
Врезка. В Max и XSI имеют одинаковую возможность управления атрибутами других объектов через кривые; в Max они называются контроллерами-стабилизаторами (reactor controllers), но требуют больше работы при настройке. В Max 7 интерфейс усовершенствован, а работа со стабилизаторами теперь налажена лучше.
@Рис. 7.31. Управляемые ключи стопы
5. Первый объект, которым вы будете управлять, – ik_toe_Zero_L. Установите ключ так, чтобы при сдвиге контроллера стопы вперед объект поворачивался, изгибая ногу в подъеме и затем в пальцах. Вы можете сделать такие настройки, чтобы стопа изгибалась как угодно сильно и чтобы она реагировала на какой хотите положительный или отрицательный сдвиг ctrl_foot_roller_L по Z. Сохраняйте небольшое и целочисленное расстояние, чтобы было легко управлять и редактировать. В этом случае значение 0.5 для Z у ctrl_foot_roller_L будет поворачивать подъем свода стопы вперед, примерно на 50º по X. При сгибе стопы это можно легко отрегулировать с помощью кривых SDK $$ Под SDK подразумевается Set Driven Key – прим ред. $$. Настройте стопу, чтобы подъем выглядел так, как вам хочется.
6. Теперь свяжите перемещение по X с вращением по Z instep_pvt_foot_L и blade_pvt_foot_L, чтобы нога наклонялась из стороны в сторону. Загрузите ctrl_foot_roller_L, instep_pvt_foot_L и blade_pvt_foot_L в окно Set Driven Key.
7. Установите первый ключ с нулевыми значениями, затем установите ctrl_foot_roller_L на -1 по X, поверните instep_pvt_foot_L на 55º и установите ключ. Точно также поступите с blade_pvt_foot_L, на этот раз со значениями 1 и -55.
8. Подчините ctrl_foot_roller_L ctrl_foot_L. Вы увидите, что стопа скачет из-за значений перемещения, примененных к управлению вращателем; чтобы исправить это, просто заморозьте трансформации элемента, управляющего вращателем, и сдвиг исправится.
9. Теперь с помощью пределов движения в Channel Box ограничьте движение контроллера до 11 юнит сетки (рис. 7.32). Также отметьте, что мы установили предел для Y на 0; это то, что добавляет компоненту сборки дополнительный защитный слой. Простым блокированием и скрытием атрибутов этого не достичь.
Врезка. В 3DS Max пределы – единственный способ убедиться, что объекты заблокированы, потому что блокирование и скрытие атрибутов там не предусмотрено. К сожалению, если вы не используете кости, пределы в Max только включают/выключают блокировку или имеют нулевое значение, и вы не можете устанавливать максимальное и минимальное значения. Классный трюк с maxscript: с помощью скрипта можно запросить данные о пределах объекта, и использовать эти данные для управления типом ключевых кадров объекта. Например, если пределы перемещения и масштабирования объекта включены, то можно установить ключевые кадры только для вращения.
@Рис. 7.32. Ограничение перемещения ctrl_foot_roller_L
10. Теперь вы получили возможность перемещать контроллер по XZ как угодно в пределах квадратной области 11, смешивая основные движения стопы. Это будет нормально работать почти с любой анимацией, но мы должны дать аниматорам возможность управлять сборкой, не спрашивая технического директора по персонажам об изменениях и не копаясь в сборке самостоятельно, чтобы исправить что-нибудь. Мы применим более продвинутые соединения и узлы, чтобы быстро изменять значения текущей сборки и добавлять дополнительные элементы управления, которые могут понадобиться для остальной части стопы.
С помощью узла multiplyDivide вы создадите возможность увеличить степень влияния расстояния от элемента, управляющего вращателем, на значение вращения стопы во всех направлениях. Чтобы сократить количество узлов, создайте только два узла multiplyDivide, а потом используйте X,Y,Z каналы обоих узлов, чтобы задать шесть независимых каналов, не создавая шесть отдельных узлов.
11. Возьмите выходные данные кривой SDK и отобразите их в input1x узла multiplyDivide. Потом возьмите выходные данные и отошлите их в instep_pvt_foot_L. Продолжайте с другими узлами SDK и другими каналами до установления соединений (рис. 7.33 и 7.34). Причина, по которой мы устанавливаем соединение выходных данных от SDK, а не до SDK, такова: мы хотим увеличить конечный результат SDK, а не изменить значение, которое SDK берет от перемещения элементов, управляющих вращателем.
@Рис. 7.33. Чтение выходных данных узла multiplyDivide
@Рис. 7.34. Окончательные соединения узла multiplyDivide
@Рис. 7.35. Заданный атрибут узла формы управляющих элементов
12. Создайте атрибут rollAmp со значением по умолчанию, равным 1, в ctrl_foot_roller_L – в shape-узле элемента управления. Это упрощает доступ, но при этом вне атрибутов, для которых мы хотим установить ключевые кадры (рис. 7.35).
13. Теперь соедините этот атрибут с input2 узлов multiplyDivide, чтобы иметь возможность менять значение одного атрибута и управлять степенью поворота. Меньшие значения заставляют стопу двигаться слабее, позволяя в случае необходимости уменьшить диапазон вращения.
14. Следующий блок ручного управления, который нам нужен, позволяет во время вращения ноги переносить анимацию на пальцы, при остановке свода стопы. И снова, это дополнительное управление продолжит путь shape-узла и не взаимодействует с главными ключевыми кадрами управления анимацией.
15. Добавьте новый атрибут под названием rollBallAdjust с начальным значением 1, как и раньше.
16. С помощью команды
Mel createNode
multDoubleLinear
создайте узел, который подгонит поворот
между движением пальцев и свода стопы.
17. Затем, снова применив команду Mel, соедините translateZ контроллера вращения и input1 у multiDoubleLinear:
connectAttr
ctrl_foot_roller_L.translateZ multDoubleLinear1.input1;
18. Теперь сделайте то же самое для ctrl_foot_roller_LShape.rollBallAdust, соединив его выходные данные с input2 у multiDoubleLinear:
connectAttr ctrl_foot_roller_LShape.rollBallAdust multDoubleLinear1.input2;
19. И наконец, соедините выходные данные multiDoubleLinear с ik_toe_Zero_L_Rotate по X узла SDK. На рисунке (рис. 7.36) показана окончательная схема всех соединений. Обратите внимание, что в этот раз мы добавили узел до SDK, потому что в нашем случае нужно сохранить такое же движение, что и у SDK, но при этом мы хотим контролировать время этого движения.
@Рис. 7.36. Схема узлов управления движением стопы
Врезка. Следующие шаги можно применить к другому локатору и настроить управление стопой как управление вращателем стопы, но в этом случае нам нужно оставить возможность установления ключевых кадров для как можно меньшего количества элементов управления. Основная анимация стопы возможна без обращения к Channel Box, но мы всё-таки устанавливаем в Channel Box атрибуты, к которым обращаемся реже. Они доступны, но не всегда используются в анимации.
20. Есть еще несколько управляющих элементов стопы, которые мы добавим, чтобы сделать возможными скручивающие движения, такие как нестандартное смещение или просто смещение точки опоры свода стопы. И еще мы добавим точку опопры пятки и управление пальцами ног.
21. Создайте три новых собственных атрибута для контроллера вращения стопы. Первым атрибутом будет toeTap, предназначенный для анимации движения сочленения пальцев вверх-вниз; затем добавьте другие два: ballTwist и heelTwist. Когда они будут добавлены в ctrl_fool_roller_L, прицепите их к соответствующим группам, чтобы управлять вращением.
22. Сначала выбирите ik_toeTip_L и сгруппируйте. Назовите группу toe_pvt_L и установите точку опоры для этой группы на подъеме свода стопы (рис. 7.37).
23. Теперь соедините атрибут toeTap c вращением toe_pvt_L по X. Это действие соединит два атрибута, но с одинаковым отображением значения, что сделает атрибут замедляющим поворот ноги. Можно настроить узел unitConversion, который Maya автоматически вставляет между атрибутом и каналом вращения, и увеличить его значение, чтобы меньше изменить атрибут toeTap и сильнее воздействовать на палец ноги.
@Рис. 7.37. Центральная точка пальцев в действии
Выделите узел toe_pvt_L и отобразите соединения в Hypergraph. Вы увидите узел unitConversion. Выделите его и откройте Редактор Атрибутов. Коэффициент конверсии (conversion factor) должен равняться 0,018. Измените его на 0,5, чтобы аниматор мог меньше двигать мышью, получая тот же самый результат. Другой шаг – убедиться, что наши положительные значения анимации все еще работают. Положительные числа должны заставлять пальцы вращаться вверх, но сейчас они вращаются вниз. Чтобы исправить это, поместите знак «-» перед 0,5.
Врезка. Вместо реверсного узла (reverse node) можно использовать узел unitConversion и не мучаться из-за сбоя значения, характерного для реверсного узла. В Maya для работы с соединениями это применяется повсеместно, и технический директор по персонажам должен извлечь из этого выгоду для своих сборок.
Займитесь соединением других атрибутов: ballTwist и ik_toeTip_Zero_L – rotateY, а также heelTwist и ik_heel_Zero_L.
Вы можете настроить столько слоев управления, сколько захочется и понадобится аниматорам, и, если иерархия устойчива и вы понимаете, как дополнять сборку с помощью новых групповых узлов или путем применения математических узлов (math nodes) к слоям при сдвигах, то вы сможете создать очень быструю, стабильную и гибкую сборку стопы или точно так же любой части персонажной сборки. Постарайтесь сами создать новое управление сборкой стопы, которое работало бы поверх текущей системы. Можно сделать все атрибуты индивидуальными, как в других сборках ступней, и с помощью узла plusMinusAverage анимировать сборку только с этими атрибутами, при этом похожий на джойстик контроллер вращения так же будет работать (рис. 7.38).
Врезка. Чтобы избежать дополнительных узлов, постарайтесь расставлять их сразу после узлов multiplyDivide, чтобы соединение устанавливалось между узлами multiplyDivide и unitConversion. Это исключит дополнительные узлы конверсии, размещенные, когда вам было нужно подсоединить узел plusMinusAverage между узлом unitConversion и последним узлом вращения, как, например, toe_pvtP_L.
@Рис. 7.38. Дополнительные атрибуты, встраиваемые в узлы plusMinusAverage, для управления по слоям
Пальцы ног и очистка
До сих пор мы имели дело только с тем, что мы называем грубым управлением (coarse controls) ноги стопы: которые нужны нам для предварительной анимации и постановки поз. Что нам нужно сделать теперь – настроить управление сочленениями пальцев ног, чтобы добиться более тонкого управления.
Чтобы закончить сборку этой стопы, мы добавим поверх уже готового управления ПК несколько автоматических элементов управления пальцами, снова пытаясь по возможности сохранить положение ключевых кадров и стремясь к гибкости для аниматора. Нам также нужно добавить к ctrl_foot_roller shape-узел, который легко выделять (вместо обычного крестообразного локатора), и добавить управляющий объект для узла сгиба или напряжения ноги, который мы уже сделали ранее.
1. Для начала давайте сделаем быстрое управление узлом сгиба ноги. Вам решать, как вы будете управлять им, либо с помощью выделяемого элемента в сцене, либо собственным атрибутом. Мы применим заданный атрибут элемента управления стопы (рис. 7.39).
2. Затем создайте более удобную форму выделения для локатора вращателя стопы. Для этого элемента хорошо работает ориентация подогнанной по размеру управляющей формы из кометовских сценариев (рис. 7.40). Дополнительные атрибуты, которые мы установили для shape-узла, будут скрыты. Это неплохо, потому что они нужны скорее техническому директору, чем аниматору. Просто вернитесь и спрячьте оригинальный локатор. Для ясности назовите его shape-узел xtraAttrs.
3. Чтобы управлять пальцами ног, используйте SDK, соединенные с атрибутами пальцев toe curl и scrunch. Из-за поворотов сочленений каналы в ПК должны оставаться незаблокированными. Вам нужно сделать с этими сочленениями что-то еще, чтобы они заработали с заданными атрибутами.
4. Создайте второй слой сочленений пальцев ног, чтобы установить управление SDK. Скопируйте цепочку bigToe и удалите геометрию сочленений.
5. Создайте суффикс _Layer новой цепочке сочленений. Чтобы ускорить дело, воспользуйтесь cometRename.mel или похожим сценарием переименования.
6. Подчините сочленения пальцев так, чтобы каждому соответствовало управляющее сочленение второго слоя. Над сочленениями добавляется слой, который не дает SDK заблоркировать непосредственно сочленения ПК. На рисунке (рис. 7.41) показаны сочленения нового слоя в правильной иерархии и с правильными именами.
@Рис. 7.39. Атрибут гибкости ноги
@Рис. 7.40. Переименуйте shape-узел; это необходимо для вторичных атрибутов
@Рис. 7.41. Сочленения пальцев по слоям
7. Теперь создайте собственные атрибуты узла ctrl_foot_L и установите управляемый ключ с изогнутой формой, которая вас устраивает. Помните, что лучше дать контроллеру возможность переворачивать сочленения, а аниматору решать, что не подойдет для позы, чем наложить на сборку искусственные ограничения. То же самое проделайте с остальными пальцами. На рисунке (рис. 7.42) показана окончательная сборка с управлением пальцами.
8. Прежде, чем вы продолжите, давайте быстро вычистим Outliner. Выберите pgSkeleton и ctrl_foot_Zero_L и сделайте их дочерними новой управляющей кривой под названием pgWorld. Этот контроллер будет выступать в роли мирового пространства для всех контроллеров вашего персонажа. Он позволит вам перемещать всю сборку целиком в любую область сцены, при это сохраняя нулевые значения (рис. 7.43).
@Рис. 7.42. Окончательные атрибуты пальцев
@Рис. 7.43. Быстрое упорядочение Схемы Сцены с помощью pgWorld
Стопа и нога, скручивание ноги, централизация ИК/ПК контроллеров
Управление коленом этой ноги будет связано с вращением ctrl_foot_L, а атрибут смещения позволит аниматору анимировать скручивание ноги на высшем уровне. Есть множество способов соединить объекты, но в этом случае управляемые ключи позволяют сделать это быстрее, так что мы можем установить два атрибута, управляющих скручиванием ИК:
Чтобы убедиться, что скручивание и поворот предусматривают полное вращение, установите вращение ctrl_fool_L по X на и на плюс, и на минус 360. Точно так же поступите со скручиванием ik_fullLeg_L в ИК и установите для него SDK.
Затем добавьте в ctrl_foot_L атрибут kneeOffset и свяжите его значение со скручиванием ik_fullLeg_L. Снова установите полное вращение, но отобразите значение атрибута между -10 и 10. Для устойчивости/слаженности сделайте так, чтобы положительное значение вашего атрибута поворачивало ногу в сторону от тела. (Можно установить более широкий диапазон, чтобы реакция была не такой быстрой, или удерживать Ctrl при перетаскивании средней кнопкой мыши. Так вы добьетесь более тонкого контроля над значениями.)
Наконец, нам нужно установить переключение ИК/ПК для ноги и сделать так, чтобы в сочленениях ПК была опция принимать или не принимать вращение от тела. (Если вы были на мастер-классе Alias по сверхреалистичному риггингу персонажей, то эта идея о переключении чувствительности ПК для вас не нова.)
Установки ИК/ПК по умолчанию работают в Maya отлично, но они ограничены отдельными ИК манипуляторами, и только в одной цепочке, как, например, в руке. В ноге более сложная конструкция из ИК-манипуляторов и цепочек сочленений, так что нам всё ещё надо позаботиться о ИК/ПК контроллерах, используя ИК/ПК смешивание не требующее использование стандартного скелета с ограничителями.
Сперва создайте в ctrl_foot_L отдельный атрибут IkFk со значением по умолчанию 1 и диапазоном от 0 до 1. Соедините его так, чтобы он управлял всеми ИК-манипуляторами на ноге и стопе, кроме ik_fullLeg_L. Он управляет ctrl_leg и все время будет в ИК.
Теперь выделите все ИК-манипуляторы в сборке ноги и отключите атрибут привязки (snap attribute), так чтобы они не перепрыгнули в конец цепочки сочленений, которой управляют, оторвавшись от объекта управления и вызвав смещение. Проверьте, работает ли это, установив атрибут IkFk на ноль. Тогда вы сможете повернуть ногу, выделив и затем повернув каркас.
Переключение ПК-наследия
Другой шаг, который мы должны сделать, чтобы создать разбитую иерархию ноги, заключается в смешивании восприятия вращения ее родителя и глобального узла.
1. Просто дублируйте сочленение upleg_L и удалите дочерние ему объекты. После этого назовите новое сочленение ctrl_upLeg_ori_L. Именно оно будет управлять передачей вращения ноге в ПК от остального тела.
2. Снова дублируйте новое сочленение и назовите его ctrl_upLeg_ori_Local_L.
3. Дублируйте его снова и назовите ctrl_upLeg_World_ori_L. Подчините его узлу pgSkeleton и сгруппируйте. Назовите новую группу fkWorldOri_GRP. Эта новая группа будет держать все дублированные сочленения, к которым будут прикреплены другие ori сочленения , когда мы их создадим.
4. Подчините upleg_L сочленению ctrl_upLeg_ori_L.
5. Прикрепите ctrl_upLeg_ori_L orient-ограченичителем к глобальному и локальному сочленениям. Установите interp type ограничителя на самый короткий, чтобы предотвратить переворот ноги.
Теперь, когда вы настроили веса между локальным и глобальными настройками, ПК-сочленение либо унаследует движение родительского объекта, либо сохранит свою ориентацию в глобальном пространстве. И снова, нам нужно всего лишь сделать отключение/включение этой опции легким для аниматора.
Продолжая исследовать, важность utility-узлов в сборке, мы применим реверсный узел, чтобы установить переключаемое значение контроллера веса orient-ограничителя:
1. Создайте локатор и назовите его ctrl_fkOri. Этот узел, в конечном счете, будет хранить все созданные вами атрибуты для переключения ПК-наследования всего тела. Добавьте в shape-узел этого локатора свой атрибут. Назовите его legL и задайте по умолчанию нулевое значение.
2. Теперь используйте всевозможные хитрости с родительский объектом, чтобы создать что-то вроде отраженного shape-узла от локатора, в нашем случае, upleg_L, так что когда аниматор выберет ногу для анимации в ПК, он сможет просто установить значение наследования оттуда, без перепрыгивания на другой объект для задания параметров.
3. Мы воспользуемся
командой Mel
parent
-add
-shape
ctrl_fkOriShape
upLeg_L,
чтобы прикрепить shape-узел
локатора к ноге.
4. Теперь соедините атрибут legL c ctrl_upLeg_ori_World_LW0. Затем соедините выходные данные legL с реверсным узлом, а реверсный узел – с ctrl_upLeg_ori_local_LW1.
Всё это работает используя принципы работы персонажного узла в Maya, где вы создаете в одном месте набор атрибутов, работающих по всей сборке.
@Рис. 7.44. Объект содержащий отраженные атрибуты
Врезка. Идея отраженных атрибутов применяется не только в Maya. В Max она очень хорошо работает с отраженными модификаторами и контроллерами. Наслаивая пустые модификаторы и установливая в различных модификаторах различные атрибуты, вы помогаете контролировать - чему можно устанавливать ключевые кадры, а чему нет, и это также помогает аниматорам переходить от грубого управления к точному и не тонуть в его бесконечных слайдерах.
В XSI тоже есть уникальные способы выстраивания атрибутов и их группировки для редактирования во вьюпорте, основанные на объектах, которые вы выделяете, при отсутствии необходимости устанавливать атрибуты прямо на них, чтобы отобразить их.
Зеркальное отражение контроллеров. Риггинг противоположной стороны тела
Так как вся эта сборка только для одной стороны тела, в данном случае, левой, то создание сборки правой ноги подразумевает тот же самый алгоритм с некоторыми изменениями, касающимися вещей типа ориентацией контроллеров, так что поведение ИК-сборки отражается так же, как и ПК-сборки. Мы не будем вновь проходить шаг за шагом весь процесс риггинга другой ноги, а просто выделим новые способы ускорения процесса. Вот один из них: мы применяли сочленения для основных контролирующих объектов, и поэтому их можно отразить с помощью инструмента Mirror Joint (Отразить сочленение), что даст вам возможность отразить поведение, позволяя контроллерам ИК при вращениях действовать отраженным манером:
С помощью инструмента Mirror Joint отразите ctrl_foot_L. Этот инструмент отразит и ориентацию. Потом вам нужно настроить ось вращения, направленную так, чтобы значения по Z были положительными (рис. 7.45). В качестве бонуса под управление попадают все узлы иерархии. Чтобы завершить настройку контроллеров правой стопы, совершите следующие шаги.
Сгруппируйте ctrl_foot_R, назовите группу ctrl_foot_Zero_R, подчините ее pgSkeleton, и совершите то же процесс с обнулением перемещений, как и раньше, используя перемещение центральной точки вращения, с целью смещения и сохранения нулевых значений всех контроллеров.
Выделите дочерние узлы и отобразите LRA, чтобы получить возможность заново выровнять точки опоры контроллеров и заново привязать их к нужной области стопы.
Отразите управляющую ногу и удалите все дополнительные ИК-манипуляторы и эффекторы в иерархии, которые были дублированы; их заменят новые ИК-манипуляторы правой ноги. Добавьте ИК-манипуляторы к правой ноге, присвойте им имена и подчините их соответствующим нулевым узлам.
Убедитесь, что все объекты переименованы в соответствии со стороной тела. Исправляйте L на R (также и в скрытых узлах, таких как конечные эффекторы).
@Рис. 7.45. Первоначальное отражение контроллеров ноги
Настоящее бедствие при попытке отразить такую сборку, как эту, вручную – в том, что вам приходится перестраивать все сети узлов и заново настраивать все соединения SDK, в том числе для положений стопы. Это яркий пример случая, когда отведение некоторого времени на написание скрипта для создания сборки или даже её отдельных компонентов обязательно компенсируется позже, даже если вам нужно сделать сборку всего лишь одного персонажа. С целью как практики, так и того, чтобы убедиться, что основные идеи риггинга ясны, мы продолжим разрабатывать правую сторону сборки вручную.
На рисунке (рис. 7.46) показано текущее состояние сборки двух ступней: верхняя схема показывает все соединения левой стопы, а нижняя – правой, без необходимого риггинга. К счастью для нас, мы можно применить некоторые хитрости, такие как, дублирование большей часть узлов левой стопы и пересоединение их на схеме правой стопы.
Чтобы процесс соединения наших атрибутов был изначально прост, мы соединим их также, как в предыдущей главе, подключая каждый атрибут к нужному соединению. После этого мы дублируем более сложную схему и соединим остальные компоненты сборки стопы:
Дублируйте ctrl_foot_L при настройке дублирования «Дублировать схему входящих соединений» («Duplicate Input Graph»). Это действие приведет к копированию всех соединений, включая наши SDK узлы.
Теперь вы можете подсоединить к этой схеме атрибуты ctrl_foot_L и удалить все узлы, которые были дублированы после этого. Вам будет проще если вы сначала разберетесь с входными данными, потому что с ними работает меньшее количество узлов. Затем можно приступить к выходным данным схемы правой ноги, сочленений стопы и узлов.
В заключение заново подчините shape-узел ctrl_fkOri с помощью Mel-команды
parent-add-shapectrl_fkOriShapeupLegR, добавьте ему наш атрибут LegR и установите соединения для переключения, как мы делали раньше.
@Рис. 7.46. Желанная окончательная схема стопы
Врезка. Вы можете продолжать использовать реверсный узел, пока у него не закончатся входные и выходные данные, чтобы сохранить нумерацию узлов и организацию соединений
Теперь, когда вы закончили с соединениями, разберитесь с дублированными объектами, запустив File → Optimize Scene Size → Options (Файл → Оптимизировать размер сцены → Опции) и отметив все пункты. Перед тем, как запустить это, сохраните файл, просто на случай удаления чего-то, что вам нужно. Тогда вы сможете вернуть всё на место.
На этом этапе побочный эффект риггинга ноги при помощи только атрибута скручивания ИК заключается в том, что мы установили значения полярного вектора (pole vector) ИК на 0 0 0, позволяя ИК свободно вращаться без переворотов. Проблема в том, что поворот бедра или родительского сочленения заставляет ноги поворачиваться, как если бы они управлялись полярными векторами ИК-манипуляторов. Мы исправим это потом, когда создадим управление бедрами.
Рисунок 7.47 показывает окончательный набор отраженных контроллеров и иерархию, которая должна вы должны получить, закончив.
@Рис. 7.47. Законченные контроллеры ноги
Плечи, руки и кисти
Лицо, кисти и руки – одни из самых выразительных части тела. Совместите эти части с широким диапазоном движений плеч, и вы получите очень мощный инструмент коммуникации персонажа (если вы удостоверитесь, что аниматоры смогут управлять этими частями тела). Есть несколько базовых идей, которым должны соответствовать все сборки рук и кистей, чтобы осчастливить аниматоров. Эти основные идеи не включают управление сжатием и растяжением рук, но это можно добавить в конце риггинга.
Вот список существенных аспектов, которые составляют хорошую сборку руки:
Переключение ИК/ПК;
Отделение движения плеча от остального тела в ПК ;
Легкий в управлении локтевой сустав;
Управление запястьем, позволяющее сочетать глобальное и локальное наследуемое вращение кисти, также как и плеча;
Смешанное переключение ИК контроля между глобальным пространством, телом и пространством перемещений верхней части туловища;
Одно дополнительное смешанное пространство для вспомогательного управления кистью, которое можно присоединить к любому объекту, такому как оружие;
Автоматическая ключица под управлением аниматора, отключенная по умолчанию;
Простое и гибкое управление пальцами рук;
Управление основными положениями всей руки и переназначение для наилучшей настройки
Быстрый доступ к системе поз, позволяющий управлять положениями рук и сохранять их, с целью переноса от одной руки к другой;
легкий способ переключения между пространствами перемещений без прыжков и перескоков, также с помощью встроенных в сборку скриптов, либо с использованием полочной кнопки.
Врезка. При построении сборки симметричной части тела, такой как, к примеру, руки, наилучшие варианты - построение каждого компонента для обеих сторон, методом дублирования сборки (не очень много хлопот), или же написать скрипт создания сборки и затем приспособить скрипт к построению отраженной части. Скрипт все-таки лучше, но как правило при коротких сроках построение обеих сторон сборки – лучший выбор. В этом руководстве рассматривается построение сборки только левой руки, но вы можете держать в уме оба варианта. Описанный в руководстве порядок создания сборки не всегда лучше всего работает в производстве.
Настройка руки очень похожа на риггинг ноги, так что большая часть повторяющихся сведений не будет здесь приводиться подробно. Если у вас возникают проблемы, вернитесь за помощью в раздел о ноге.
1. Начав с левой руки, добавьте ИК-манипулятор сочленению upArm_L до wrist_L и назовите его ik_arm_L; потом сгруппируйте его и назовите группу ik_arm_Zero_L (рис. 7.48).
@Рис. 7.48. Сгруппированный ИК-манипулятор руки с присвоенным именем
2. Привяжите точку опоры от ее первоначального положения к положению ИК-манипулятора, а затем заморозьте перемещения на манипуляторе ik_arm_L. Так же нам нужно установить значения полярного вектора на 0 0 0. Спрячьте манипулятор, пока работаете над другими частями руки.
3. С помощью кривых создайте объект, по форме напоминающий локатор, или примените cometScripts для создания объекта. Это будет контроллер положения руки, отображающий манипулятор выделения. Если вы используете такой способ вместо кривой или другого типа объектов выделения, то риг будет настолько упорядоченным, насколько возможно, и поскольку у него будет только одна основная функция – перемещение руки, вам не придется делать так, чтобы она торчала каким-нибудь особым образом. Мы просто хотим, чтобы выделение происходило легко. Постарайтесь увидеть различие между контроллером, который только перемещает, и тем, который и перемещает, и вращает.
4. Назовите его ctrl_arm_L и сгруппируйте. Назовите группу ctrl_arm_Zero_L и привяжите ее к местоположению запястья. Заморозьте перемещения этого узла.
5. Чтобы подключить ik_arm_L к контроллеру, вам нужно создать узел, который будет точечно прикреплен к ctrl_arm_L. Выделите ik_arm_L, сгруппируйте и назовите группу aux_blend_L. Проверьте, что ее точка опоры прикреплена туда же, куда и ik_arm_L, и что ее перемещения заморожены.
6. Создайте контроллер полюсного вектора для руки, с целью управления локтем. Создайте локатор-кривую, как мы делали с запястьем, и назовите его ctrl_elbow_L. Сгруппируйте его и назовите группу ctrl_elbow_Zero_L.
7. Сложность полярного вектора в том, чтобы не вызвать скачок руки, когда вы прикрепляете к ней ИК-манипулятор. Убедитесь, что цель полярный вектора находится в той же плоскости, в которой будет работать ИК решатель. Рука этого персонажа вне оси, и поэтому плоскость трудно отыскать вручную. Мы предпримем следующие шаги, чтобы разместить объект в правильной плоскости.
8. Выделите три сочленения руки – upArm_L, lowArm_L и wrist_L, – а также ctrl_elbow_Zero_L, и установите точечный ограничитель. Центр плоскости ИК для сочленений руки будет найден.
9. Нужно найти вектор направления для перемещения вдоль него группы, так чтобы полярный вектор находился вне руки и не давал ей переворачиваться. Возьмите lowArm_L и ctrl_elbow_Zero_L и установите целевой ограничитель. Когда вы будете перемещать ctrl_elbow_Zero_L по X, он будет перемещаться плоскости ИК-решателя. Когда контроллер попадет на свое место, можно будет удалить ограничители, установить вращения ctrl_elbow_Zero_L на ноль и заморозить перемещения.
10. Теперь прикрепите ik_arm_L к ctrl_elbow_L с помощью ограничителя полюсного вектора. Рука не должна двигаться или дергаться. Если это происходит, то управляющий элемент находился не в той плоскости и должен быть перепроверен. На рисунке 7.49 показано расположение полярного вектора руки, и остальные, подвешенные к руке узлы. Ими вы и займетесь на следующем этапе.
Врезка. Вы также можете установить центральную точку группы в опциях группы, так как это может помочь ускорить ее размещение при группировке одного объекта. Точка устанавливается в центр габаритной рамки группы, а не исходного объекта.
@Рис. 7.49. Полярный вектор локтя.
11. Чтобы немного навести порядок перед тем, как пойти дальше, давайте проверим, что вы подчинили ваши контроллеры узлу pgWorld. Следующим шагом создается система, в которой полярный вектор будет всегда следовать за рукой. Это может показаться странным, но в этой системе можно установить полярный вектор вне персонажа и сделать для него ключевые кадры как для сдвига, чтобы сократить количество случаев, когда во время сложных движений он встает на пути. Мы создадим опцию фиксации его в глобальном пространстве, до тех пор, пока нам не понадобятся его перемещения.
12. Создайте локатор, назовите его ctrl_elbowAttach_L, прикрепите его к вершине upArm_L и подчините shoulder_L. Потом заморозьте перемещения ctrl_elbowAttach_L. Это будет верхняя точка, к которой мы прикрепим следующий контроллер – к этой точке и к локатору запястья.
13. Создайте еще один локатор, назовите его ctrl_elbowFollow_L и прикрепите его к ctrl_elbowAttach_L и ctrl_arm_L. После этого сделайте его дочерним узлу pgWorld.
14. Выделите ctrl_elbow_L, сгруппируйте его и назовите группу ctrl_elbowLocate_L. Затем подчините этот узел родительскими ограничителями локатору ctrl_elbowFollow_L и pgWorld. Это позволит вам чередовать следование за рукой и залипание в глобальном пространстве. По умолчанию установите следование за рукой, но если нужно, можно настроить и залипание в глобальном пространстве.
15. Наладьте все это так же, как мы настраивали другие смешивания ограничителей: с помощью добавления собственного атрибута shape-узлу ctrl_elbow_L. Назовите shape-узел elbow_attrs_L. Добавьте атрибут под названием followArm и установите его значение на float, от 0 до 1, по умолчанию 1. Применив нашу хитрость с реверсными узлами и Connection Editor, подключите атрибут родительскими ограничителями ctrl_elbowLocate_L.
Врезка. Идея полярного вектора или up-вектора, следующего за рукой, может показаться странной, но по сравнению с ее аналогом в глобальном пространстве она дает исключительные преимущества, потому что вектор остается с персонажем, но не мешает движению. Проблема с полярными векторами, которые прикреплены к глобальному пространству или просто сдвигают родительское сочленение персонажа, заключается в том, что они перемещаются тогда, когда вы этого не хотите, но также они дают уверенность в том, что локоть всегда двигается немного в стороне от текущего положения руки. Поначалу локатор, следующий за рукой, может показаться немного странным, но когда вы привыкнете просто настраивать локоть для большей части движений и забывать о нем, то вы машинально будете искать эту возможность в других сборках.
16. У вас есть начатая сборка руки; но чтобы она полноценно заработала, нужно сделать кое-что еще. Следующий шаг – это то же самое, что мы проделали с ногой, чтобы создать переключатель ПК наследования, но только теперь нужно настроить руку. Вспомните, нужно добавить атрибут переключения в ctrl_fkOriShape, назвать его armL и соединить с ограничителями ctrl_upArm_ori_L, чтобы смешать узлы ctrl_upArm_ori_Local_L и ctrl_upArm_ori_World_L. Подчините shape-узел узлу upArm_L с пометкой -add, как в случае с ногой.
17. Проверьте, что вы установили соединения с нужным атрибутом. Для этого установите смешивание ИК-манипулятора руки на 0 и попробуйте повернуть тело персонажа. Если рука по умолчанию двигается вслед за ним, то это хорошо. При установке атрибута armL на 1 она не должна поворачиваться вместе с телом. Если у вас возникли проблемы с этим компонентом рига, обратитесь к разделу о ноге, где мы делали то же самое.
Последний этап настройки руки и кисти: добавление опций и элементов управления конечностью
Рука соединяется в целое, и, как и в случае с ногой, нужно настроить еще несколько элементов, например, смешивание ИК/ПК, скручивание ИК, совмещение локального и глобального пространств, управление запястьем (которое также потребует реакции на локальное или глобальное вращение руки), управление пальцами и, наконец, настроить автоматическую ключицу, которая бы реагировала на подъем руки до определенной точки.
ИК/ПК
Настройте переключатель ИК/ПК, добавив в ctrl_arm_L собственный атрибут и назвав его так же, как в случае с ногой, ikFk. Максимальное значение 1, минимальное 0, по умолчанию 1. Соедините его с ИК ik_arm_L – атрибутом смешивания ИК на ИК-манипуляторе.
Скручивание в ИК тоже несложно. Добавляя атрибуты и устанавливая прямые соединения, вы можете управлять скручиванием руки независимо от полярного вектора. Хитрость здесь в такой отладке узла unit conversion между двумя соединениями, чтобы значение скручивания руки, управляющего скручиванием в ИК, было больше, и вам не пришлось бы далеко прокручивать мышь. Хорошо работает значение узла unitConversion, равное 1 или 1,5.
В некоторых сборках контроль выкручивания поворачивающегося объекта, размещен на плече или локте персонажа, и это работает, наряду с атрибутом скручивания или вместо него, но ключевые кадры распространяются на несколько объектов, и приходится делать много дополнительных выделений и переключать инструменты, так что лучше все-таки работать с атрибутом. Если вы хотите, чтобы скручивание управлялось иконкой, то разместите ее рядом с главным элементом управления руки, чтобы ее можно было быстро выделить, но не вне оси сочленения руки и не сворачивая ее в иерархию руки.
Смешивание пространств и наследующие перемещения руки – отличные вещи для сборки; при настройке рук они используются больше всего, но можно применить их и к настройке ног, если это необходимо. Такие детали нужно настраивать на начальном этапе анимации, в одном или другом пространстве, но так, чтобы смешивание этих пространств происходило гладко.
Использовать текст для целей узлов легко и быстро, к тому же позволяет аниматорам знать, что представляет из себя каждый узел и как он влияет на руку. Создайте небольшой текст, используя шрифт Arial, с заглавными буквами W и L. Появится форма кривой и групповые узлы, которые вы сможете применить для переключения пространства между глобальным и локальным. Управление локальным пространством будет потом привязано к сборке бедер, так как L держит руку в одном пространстве с верхней частью туловища, но вне грудной клетки/плеча, а управление глобальным пространством должно остаться вне пространства персонажа и может быть анимировано, чтобы присоединить его к другому персонажу или сдвинуть руку, если нужно. На рисунке (рис. 7.50) показаны имя и положение глобальной и локальной управляющих кривых. Когда они размещены и названы, вы можете выделить ctrl_arm_Zero_L и прикрепить его родительским ограничителем между двух кривых. Мы настроим собственный атрибут для сочетания глобального и локального контроллеров, как наши переключатели ограничений
Переименуйте shape-узел ctrl_arm_L из curveShape1, как он назван в нашем файле - в xtraAttrs, как мы делали с контроллеров вращения стопы. Добавьте свой атрибут worldLocal и установите по умолчанию глобальное пространство. Так как этот переключающий атрибут не входит в состав основных элементов управления анимацией, то мы установим его на форму, чтобы его по ошибке не анимировали.
@Рис. 7.50. Новые узлы и их правильное размещение в этой части сборки
Автоматическая ключица
Повороты относительно перемещения у наших контроллеров это что-то, к чему нужно подойти несмеша, решая, как аниматор будет взаимодействовать со сборкой. В большинстве случаев перемещение делается интуитивно, и проблем с суставами не возникает, а могут быть легко разобраны и отредактированны в Редакторе Схем (Graph Editor). Так как у нас уже есть хороший скелет в ПК, а модель настроена для анимации ключиц, то можно просто добавить дополнительный слой управления, чтобы сделать автоматическую ключицу и иметь возможность отключить или усилить результат.
1. Начните с выделения и группировки clav_L. Это потом понадобится позже для авто-риггинга (autoRig). Назовите группу ctrl_clav_AutoClav_L. Она будет соединена с вращением с помощью управляемого ключа, основанного на положении ctrl_arm_L.
2. Ctrl_arm_L будет управляющим элементом, а ctrl_clav_AutoClav_L – управляемым. Стандатная процедура SDK – установить ключ для нулевого положения, а потом до предела поднять руку вверх над головой, повернуть узел AutoClav вверх по Y, так чтобы рука и ключица в этой позе хорошо выглядели, и установить следующий SDK ключ. Проделайте то же самое для поворота руки по Z, выставив ее вперед и повернув узел AutoClav вперед по X. Вы можете настроить ключевые кадры и кривые SDK, чтобы добиться лучшего ощущения движения ключицы. На рисунке (рис. 7.51) показаны кривые SDK для ctrl_clav_AutoClav_L.
3. Теперь, когда автоматическая часть ключицы готова, аниматоры хотят получить над ней управление. Примените ту же технику, что и для настройки Roll Amp стопы. Просто добавьте к shape-узлу xtraAttrs узла ctrl_arm_L новый собственный атрибут autoclave (там, где вы поместили атрибут World Local).
4. Теперь примените
команду Mel createNode
multDoubleLinear
и дублируйте новый узел. Выделив их
оба, выделите узел ctrl_clav_AutoClav_L
и перейдите к схеме в Гиперграфе,
чтобы установить соединения. Подключите
узлы multDoubleLinear между
кривыми SDK и значениями
вращения ctrl_clav_AutoClav_L.
Затем возьмите свой autoclave
и присоедините его к открытому слоту
узлов multDoubleLinear (рис.
7.52). Помните, что, поскольку мы добавили
узлы multDoubleLinear после
соединений SDK, мы можем
либо установить их эффект на 0, отключив
автоматическое движение ключицы, либо
увеличить значение, чтобы ключица могла
двигаться более свободно. Вы можете
даже присвоить отрицательное значение,
и плечо будет отходить от руки, когда
вы будете перемещать контроллер вперед.
Это пригодится, если героя будут дергать
за руку, а он будет пытаться освободиться.
@Рис. 7.51. Кривые SDK
@Рис. 7.52. Окончательные соединения узлов
5. Нужно помнить об одной вещи: когда вы переключитесь из ПК в ИК, автоматические ключицы перестанут работать. Но с этой проблемой справиться несложно; нужно просто отключить смешивание значений во время переключения вперед и назад. Хотя большинству аниматоров не нравится, когда автомитизация включена, но иногда так лучше для быстрого блока или игровых движений, когда происходит тесный разворот.
Риггинг лопатки
Чтобы создать сборку лопатки, нужно убедиться, что она удовлетворяет нескольким требованиям. Главное из них – управление деформациями с участием ключицы, и в то же время возможность анимации таких мелких движений, как напряжение, и подкожное движение мышц. Хороший путь к разработке таких деталей сборки – наскоро настроить тестовый файл вне основной сборки персонажа, чтобы проверить некоторые идеи. В маленьком файле вы сможете понаделать чего угодно, не боясь испортить оригинальный файл сборки. После того как вы заставили что-нибудь работать так, как вы хотите, вы можете аккуратно построить это в файле сборки (рис. 7.53).
@Рис. 7.53. Тестовая сборка лопатки.
Взглянув на расположение сочленений в тестовой сборке вы обнаружите, что ключом к тому, чтобы это заработало является точка вращения, находящаяся в центре модели, где при повороте конец сочленения образовывает дугу вдоль поверхности модели. Это имеет значение, потому что лопатка плавает над грудной клеткой, и нам нужно имитировать это движение. Также нужно, чтобы сочленение могло перемещаться при повороте наружу, как когда рука поднимается над головой.
Этот процесс проходит в две стадии. Вы создадите сочленения в файле сборки, а потом перенесете их обратно в файл временного скелета и файл для скиннинга.
1. В файле сборки есть ссылка на модель высокого разрешения, которую мы будем использовать с целью более легкого размещения новых сочленений. Просто спрячьте голову на время, чтобы сконцентрироваться на области грудной клетки и плеч. На рисунке (рис. 7.54) показано положение вращающей мышцы лопатки, на виде сверху, что позволяет поворачивать ее вдоль поверхности грудной клетки.
2. Теперь используя грубую модель лопатки, на которой положение центральной точки скручивания отмечено красной стрелкой, отмасштабируйте и переместите её в то место, где, как вам кажется, должна находиться лопатка персонажа. Когда вы определитесь с размером и местоположением лопатки, поверните конечное сочленение так, чтобы оно выровнялось с центральной точкой ее скручивания (рис. 7.55).
@Рис. 7.54. Положение точки опоры в сборке лопатки
@Рис. 7.55. Положение сочленения лопатки
3. Теперь привяжите новые сочленения поверх этих временных сочленений и закончите концом сочленения ключицы, всего создав три новых сочленения. Назовите их, считая от основания позвоночника, ctrl_autoScap_L, ctrl_autoScap_Attach_L и ctrl_autoScap_END_L. Выровняйте ЛОВ ctrl_autoScap_L, чтобы они совпали с ЛОВ ключицы.
4. Создайте одно отдельное сочленение, которое будет использоваться для скиннинга, и привяжите его к месту расположения точки опоры лопатки. Назовите его scap_L и подчините spineChest. Это сочленение, чтобы двигаться правильнее, будет получать данные как перемещения, так и вращения. Подчините ctrl_autoScap_L сочленению spineChest.. Рисунок 7.56 показывает новые сочленения в сборке и новое сочленение лопатки.
@Рис. 7.56. Сочленение лопатки и сочленения сборки
5. Это сочленение – то, которое вы сохраните и поместите в другие файлы, шаблонный и файл скелета. Не забудьте согласовать ЛОВ с остальным скелетом, положительное вращение по Z вперед, а отрицательное назад. X – ось скручивания, так что она располагается в соответствии с направлением скручивания лопатки под определенным углом. Убедитесь, что у них есть имя для редактора Trax. Зеркально отразите сочленения, когда закончите. Рисунок 7.57 показывает сочленение с правильным выравниванием ЛОВ. Теперь разбейте подчинение, экспортируйте два сочленения лопатки из этого файла и загрузите их в файл скелета и шаблонный файл. Заново подчините их в файле сборки, когда экспорт будет завершен.
6. Добавьте IK манипулятор из ctrl_autoScap_Attach_L в сочленение ctrl_autoScap_END_L, назовите его ik_scap_L, а его эффектор – eff_scap_L. Подчините его сочленению clav_L.
7. Чтобы было видно влияние сборки на сочленение лопатки, присоедините сочленение scap_L к сочленению ctrl_autoScap_Attach_L с помощью родительского ограничителя. Они будут двигаться вместе. После этого просто подчините каркас лопатки сочленению scap_L, чтобы сразу видеть его движение.
8. Чтобы закончить с соединениями и для полного диапазона движений заставить лопатку следовать за ключицей, вы должны настроить соединение поворота и перемещения.
9. Создайте локатор, прикрепите его к месту ctrl_autoScap_L, подчините clav_L и назовите его ctrl_scapPos_Attach_L. Заморозьте перемещения локатора, чтобы обнулить его.
10. Создайте и привяжите к тому же месту другой локатор, названный ctrl_scapPos_L. При повороте ключицы вверх он будет перемещаться по Y. Заморозьте перемещения локатора, чтобы обнулить его.
11. Сгруппируйте его, подчините группу spineChest и назовите новую группу ctrl_scapPos_Zero_L.
12. Подчините ctrl_autoScap_L локатору ctrl_scapPos_L.
13. Прикрепите ctrl_scapPos_L узлу ctrl_scapPos_Attach_L точечным ограничителем, но только по Y. Это позволит лопатке перемещаться вверх по спине, когда ключица будет поворачиваться вверх.
14. Теперь соедините ось Z у clav_L с осью Z у ctrl_autoScap_L. Когда ключица поворачивается спереди назад, лопатка скользит по грудной клетке и дает очень неплохое естественное движение, освобождая аниматоров от необходимости его анимировать.
@Рис. 7.57. Сочленение лопатки и сочленения сборки с выровненными ЛОВ
Врезка. Если у вас установлен пакет Bonus Tools для Maya 6.0.1, то вы можете щелкнуть правой кнопкой мыши с прижатой клавишей Ctrl на выделенном атрибуте в Channel Box и добавить его как управляющий, потом выделить управляемый объект, снова щелкнуть правой кнопкой мыши с прижатой клавишей Ctrl и выбрать из списка New Attribute Driver. Когда закончите, просто удалите их. Это быстрее, чем возиться с Hypergraph или Connecion Editor, когда вам нужны лишь простые прямые соединения.
В Bonus Tools для Maya 6.5 эта функция по умолчанию отключена, но ее можно активировать путем удаления комментария к команде publish в userSetup.mel.
15. Загвоздка в том, что для того, чтобы всё это работало с автоматической ключицей, нужно еще одно соединение. Помните: чтобы сборка была профессионально отлажена, технический директор должен проверить, что все отдельные системы работают вместе; ведь вы создаете инструмент для аниматоров, а не просто список настроек. Когда рука выставлена вперед, должно вращаться сочленениие ctrl_clav_AutoClav_L, а не clav_L, к которому привязаны повороты ключицы вперед-назад.
16. Примените проверенные utility-узлы еще раз, чтобы совместить оба вращения на оси Z ctrl_autoScap_L.
17. Выделите ctrl_autoScap_L и новый узел plusMinusAverage. Отобразите их схему. Соедините вращение по Z clav_L с входом 1D[0] plusMinusAverage, а затем его выходные данные с вращением по Z ctrl_autoScap_L.
18. Теперь для вращения возьмите выходные данные ctrl_autoScap_L и подсоедините их к узлу plusMinusAverage, ко входу 1D[1]. Потом возьмите узел unitConversion, между ctrl_clav_AutoClav_L и plusMinusAverage. Установите его на «-», чтобы узел autoScap поворачивася в правильном направлении, и присвойте узлу unitConversion имя unitCon_clavReverse_L. Так мы будем знать, что он используется в риге, а не просто создан Maya по умолчанию (рис. 7.58)
@Рис. 7.58. Окончательные соединения автоматической ключицы
Если аниматоры потребуют, вы можете добавить управление скручиванием для анимации поворота сочленения лопатки или пойти дальше и приспособить положение ik_scap_L для более интенсивных движений лопатки. Но мы не будем рассказывать об этом в учебнике.
Запястье и пальцы рук
Для управления запястьем и кистью создайте такой же узел, как в случае с лодыжкой, чтобы можно было без проблем отразить повороты одной руки на другую. При этом вращения будут нулевыми.
1. Создайте новое сочленение, сгруппируйте его и привяжите к сочленению запястья. Назовите сочленение ctrl_wrist_L, а группу ctrl_wrist_Zero_L.
2. Контроллер запястья должен совпадать с сочленением запястья, чтобы они поворачивались одинаково. Подчините ctrl_wrist_Zero_L сочленению lowArm_L и заморозьте перемещения. Чтобы сочленение совпало с запястьем, можно сделать разные вещи, но самый быстрый способ – применить новую возможность Maya: кнопка Presets (предварительные настройки) в Attribute Editor. Сперва возьмите сочленение wrist_L и кнопкой Presets сохраните новые настройки. Потом выделите ctrl_wrist_Zero_L и идите в меню Presets → wrist_L → Replace (Предварительные настройки → wrist_L → Заменить). Управляющее сочленение запястья точно совпадет с настоящим сочленением запястья. Остальные настройки запястья будут работать так же, как наследующий риггинг руки и ноги в ПК: запястье должно следовать за рукой, когда она поворачивается, или же оно смешается с глобальным пространством и не будет наследовать вращения руки.
3. Дважды дублируйте сочленение ctrl_wrist_L.Назовите одну копию ctrl_wrist_ori_World_L, а другую – ctrl_wrist_ori_Local_L. Подчините локальный контроллер lowArm_L, а глобальный узел – fkWorldOri_GRP.
4. Прикрепите ctrl_wrist_Zero_L orient-ограничителем к глобальному и локальному сочленениям. (Убедитесь, что ограничение настроено по умолчанию.)
5. Теперь создайте вращающий бокс и подчините его shape-узел сочленению ctrl_wrist_L. Вам нужно будет приспособить порядок вращения к запястью, чтобы оно лучше работало при анимации и риггинге. Так как вращение по X влияет на все предплечье и запястье, именно X должна быть ведущей осью, тогда Z – для движения из стороны в сторону, а Y – вверх-вниз. Такой порядок также поможет избежать блокирования шарнирного соединения, так как оси будут разделены, что полезно в основном для оси, которая вращается последней. В этом случае движение запястья из стороны в сторону ограничено диапазоном его движения. Вот почему для управления запястьем наиболее пригоден порядок вращения YZX. Это также является причиной того, что в сборке создается дополнительный слой сложных сочленений вместо обычного управления сочленением wrist_L непосредственно в ПК. На рисунке 7.59 показана сборка запястья и её контроллер (управляющий объект добавлять все-таки нужно). Можно под одно управление подвести сочленения двух скелетов сборки – запястья и кисти, – чтобы движения кисти были более естественными. На рисунке 7.60 показана иерархия и узлы для переключения ориентации (orient-switching).
Чтобы вращения отображались корректно, нужно будет также изменить порядок вращения сочленений скелета. (Не забудьте точно также изменить файл скелета для скиннинга; это не обязательно, но помогает совместить их.)
@Рис. 7.59. Управляющее сочленение запястья без кривой
@Рис. 7.60. Переключающие узлы в запястье
6. Прикрепление вращения ctrl_wrist_L к bn_wrist_L и ctrl_hand_L будет прямым. Применяя прямые соединения, поверните XYZ контроллера по XYZ сочленений. Небольшое изменение заключается в том, что вы не сможете присоединить ось X сочленения bn_wrist_L, которое не дает скручиванию возникнуть под запястьем, но разрешает использовать оба сочленения в поворотах вверх-вниз и налево-направо. Так устанавливаются места, где запястья поворачивается наружу мимо конца сочленения локтевой и лучевой костей. При анимации это также создаст впечатление скольжения кожи по сочленению.
7. Теперь выделите ctrl_wrist_L и назовите shape-узел xtraAttrs. Создайте заданный атрибут и назовите его wristFollow, значение по умолчанию равно 1. Если его установить на 0, то он отключится. Это элемент управления для смешивания включенного и отключенного наследия вращения. Риггинг будет происходить так же, как с прямым соединением и реверсным узлом (рис. 7.61).
@Рис. 7.61. Собственные атрибуты запястья формы xtraAttrs
Пальцы рук: основанное на положении пальцев управление кистью в ПК.
Простой и самый прямой путь к риггингу пальцев – оставить их в ПК. Кисти требуют намного большего уровня сноровки и большего контроля, чем стопы и пальцы ног. Кисти, так сказать, являются проблемой при анимации из-за большого количества сочленений и множества ключевых кадров, которые нужно настраивать и контролировать. Один из способов обойти это – воспользоваться библиотекой скриптов для кистей, чтобы все атрибуты были установлены и каждый раз вам приходилось бы делать меньше работы по позиционированию. Другой способ – настроить контроллеры с атрибутами (так, как были настроены пальцы ног), контролирующими такие вещи, как изгибы, разброс и так далее.
Уникальный способ работы со сложными наборами сочленений – использовать скрипты для хранения поз и управления ими (таких поз, которые находятся в файле прямо с элементами управления). Мы уже отмечали такие скрипты, как zooTriggered или zooObjectMenu. Очень быстрый способ наполнения zooObjectMenu позами – воспользоваться дополнительными инструментами: сценарии Store Poses (Хранение поз) генерируют наборы команд Mel, которые можно поместить в zooObjectMenu с помощь меню правой кнопки мыши. Это отлично работает, если позы хранятся с персонажем. Полка или собственный Mel-скрипт, хранящийся вместе с персонажем, так же работают очень хорошо. Вариант применения инструмента Store Poses – добавить в zooObjectMenu управляющие элементы для создания и редактирования заданных dagPoses, например, пальцев.
Просто для разнообразия мы настроим несколько собственных атрибутов и покажем вам другой способ взаимодействия с контроллерами кисти. Это путь к ускорению выделения пальцев и работы с ними с помощью скриптов.
Врезка. Пользователям Max отлично подойдет скрипт Pen_Attribute_Holder от Пола Нила (Paul Neale), потому что он позволяет добавлять заданные атрибуты описанному в сценарии модификатору (аналог узла в Maya). С Pen_Attribute_Holder можно также сохранять позы, копировать и вставлять, совмещать влияние позы с помощью атрибутов исходной позы. Последнюю версию вы можете скачать с его Web-сайта http://paulneale.com. Пол Нил – очень талантливый настройщик персонажей, и на его сайте есть примеры и великолепные работы, включая очень хороший тренировочный материал на DVD о риггинге персонажа в Max, который по случайному стечению обстоятельств оказался похож на риггинг, о котором рассказывается в этой книге.
Мы рассмотрим два подхода к этому делу. Первый навеян «Character Rigger’s Cookbook» («Поваренная книга персонажных Риггеров») Стива Теодора с конференции разработчиков игр (Game Developer Conference – GDC). Второй – его вариация с теми же функциями, но более рационализированная и подходящая для многих персонажей.
Врезка. Всю «Character Rigger’s Cookook» вы можете найти на Web-сайте Стива Теодора по адресу http://www.radgametools.com/cookbook/cookbook%20final.html. Это очень широкий взгляд на преимущества и недостатки риггинга. Есть множество примеров из смежного программного обеспечения. Это очень хороший сайт для художников по персонажам любого уровня.
Мы создадим несколько атрибутов на всех пальцах рук и соединим их, чтобы ускорить процесс выделения. Так как они будут основаны на соединениях, изменения имен в скелете не должны на них повлиять.
1. Добавьте первый набор атрибутов ко всем пальцам, исключая конечные сочленения, назовите его selHand и установите его значение на string, чтобы он не был виден в Channel Box.
2. Теперь создайте управляющую форму, которая станет узлом, выделяющим shape-узлы кисти. Использование аннотаций в нашем примере делает пометку и выделение контроллеров более легким. Создайте аннотацию ctrl_wrist_L, а затем подчините аннотацию контроллеру запястья. Назовите его fingerAll_selHand_L. _selHand сообщит сценарию о том, что это тот объект, для которого нужно искать соединения.
3. Добавьте к fingerAll_selHand_L собственный атрибут, как мы делали с пальцами. Назовите его selHand и установите на string.
4. Соедините выход fingerAllsel.selHand с заданными атрибутами всех пальцев вместе – .selHand. Эти соединения позволят управляющему узлу после приведения скрипта в действие найти все объекты, нужные для выделения.
5. Еще один атрибут, который мы должны добавить, – переключение включения/выключения скрипта выделения. Создайте атрибут в pgWorld, назовите его autoSelect и сделайте его логическим (рис. 7.62).
6. Теперь откройте Expression Editor (Редактор выражений). Мы собираемся использовать скриптовый узел (script node), чтобы запустить наш скрипт и оставить его в файле персонажа. Открыв Expression Editor, установите By Script Node Name (По имени скриптового узла) в меню Select Filter (Выбрать фильтр).
7. В графе Script Node Name (Имя скриптового узла) напишите autoSelect и добавьте комментарий «//это наш сценарий автоматического выделения», чтобы можно было щелкнуть по кнопке Create (Создать) и чтобы внутри был текст, с которым будет создаваться узел. Если вы оставите эту графу пустой, то скриптовый узел создан не будет. На рисунке 7.63 показан только что созданный скриптовый узел. Поменяйте Execute ON на Open/Close. Сценарий будет запущен в открытом файле. Тот сценарий, что приведен ниже, нужно поместить в раздел Before («До»)
Окончательный сценарий выглядит так:
//это наш скрипт автоматического выделения
//настраивает скрипт для поиска события,SelectionChanged в Maya
//для получения дополнительных сведений о командах о командах сценария зайдите в файл справки
scriptJob –killWithScene –compressUndo 1 –event “SelectionChanged” “selectHnd”;
global proc selectHnd()
{
if (` getAttr pgWorld.autoSelect` == 1) {
string $selectHnd[];
$selectHnd = `ls –sl “*_selHnd*” “*:*_selHnd*” `;
if (`size $selectHnd`) { select `listConnections .selHand`;
RotateTool;// переключает инструмент на режим вращения после выделения объектов
select –d `ls –sl “*_selHnd” “*:*_selHnd*” `;
}
}
}
Теперь вы можете пойти дальше, добавив дополнительные наборы атрибутов, соединений и условных выражений к задаче вашего скрипта. У вас может получиться манипулятор мульти-выделения (multi-selection handle) для каждого пальца а, например, не всей кисти сразу. Можете воспользоваться этой техникой для создания системы смены ИК – ПК (IK FK swapping system), для создания независимых от имен систем для замены наборов быстрого выделения, и так далее: возможности самые широкие. По сравнению со сценариями zooTriggered это базовая низкотехнологичная версия, но если вы хотите создать такое управление в вашем файле и при этом не хотите писать сценарий, который для этого необходим, то это хороший способ сохранить единое внешнее оформление сборки.
@Рис. 7.62. Кисть с соединенными атрибутами
@Рис. 7.63. Только что созданный скриптовый узел
Врезка. Включение и отключение этого сценария пока не поддерживают ссылки, что вызывает ошибки. Также он не подходит для нескольких персонажей одновременно, так как запрашивает getAttr определенного узла.
Скриптовый узел для нескольких персонажей, поддерживающий ссылки
Мы говорили о том, что нужно убедиться в гибкости вашего плана работы и построения сборки. Предыдущий метод выделения пальцев основывался на работе другого человека и был лишь модифицирован. Он не гибок, потому что был сконструирован специально для наших задач. Это распространенная проблема, с которой должны справляться технические режиссеры по персонажам во время риггинга, пытаясь убедиться, что то, что работает в отдельном файле, подходит и для общего производственного процесса.
Проблема предыдущего
сценария заключалась в том, что в строчке
if
(`
getAttr
pgWorld.autoSelect`
==
1)
{
он искал определенное имя узла, и если
бы это имя именилось, в сценарии произошел
бы сбой. Ссылка на файл или наличие в
файле нескольких персонажей вызовут
изменение имени узла pgWorld.
Как можно это исправить?
Во-первых, воспользуйтесь хитростью Джейсона Шлейфера (Jason Schleifer): примените для соединения fingerAll_selHnd с узлом pgWorld атрибуты .message. Потом вы сможете изменить сценарий так, чтобы он находил pgWorld.autoSelect без имени. Проверив соединение .message от глобального узла к элементам контроля выделения с помощью команды Mel
listConnections, вы сможете потом извлечь имя глобального узла и проверить, работает ли атрибут .autoSelect.Добавьте атрибут message под названием selectors к узлу pgWorld с помощью команды Mel:
addAttr –ln “selectors” –at “message.”
Атрибут selectors соединится с атрибутом world, который будет добавлен в левый и правый узлы fingerAll_selHnd. Выделите каждый из узлов fingerAll_selHnd и запустите Mel:
addAttr-ln“world”-at“message”Теперь нужно соединить атрибут selectors узла pgWorld с атрибутом world узлов fingerAll_selHnd. Воспользуйтесь Connection Editor или Mel-командой connectAttr:
connectAttr pgWorld.selectors fingerAll_selHnd_R.world;
connectAttr pgWorld.selectors fingerAll_selHnd_L.world;
Другое изменение первого метода подключения управления выделением к пальцам состоит в том, что теперь мы будем использовать наборы выделения вместо добавления собственного атрибута к каждому узлу, который нужно выделить.
Возьмите все сочленения пальцев правой руки и сделайте набор быстрого выделения под названием pgSelect_fingers_R. Точно так же сделайте на левой руке.
Добавьте атрибут типа message под названием selectNode к правому и левому узлам fingerAll_selHnd. Соедините этот атрибут с набором выделения, чтобы скрипт мог найти и выделить нужные вам узлы, когда вы обращаетесь к контроллерам.
addAttr –ln “selectNode” –at “message”
Теперь добавьте атрибут селектора к каждому набору выделения, как в случае с pgWorld.
addAttr –ln “selectors” –at “message.”
Подсоедините атрибуты от fingerAll_selHnd_L к pgSelect_fingers_L, и то же самое сделайте на правой стороне.
connectAttr fingerAll_selHnd_L.selectNode pgSelect_fingers_L.selectors;
connectAttr fingerAll_selHnd_R.selectNode pgSelect_fingers_R.selectors;
Врезка. Наборы выделения, как и любые другие узлы в Maya, могут иметь собственные атрибуты. Обычно вы просто соединяете, добавляя собственные атрибуты узлам-трансформам или shape-узлам, но использование наборов выделения для хранения собственных атрибутов открывает перед нами широкие возможности. Например, можно связывать собственные атрибуты с множеством объектов, не устанавливая на них эти атрибуты.
Создайте новый скриптовый узел так же, как раньше, но с новым кодом.
//новый скрипт///////////////////////////////////////////////////////////
//это наш скрипт автоматического выделения
//настраивает работу сценария для поиска события,SelectionChanged в Maya
scriptJob –kws –compressUndo 1 –event “SelectionChanged” “selectNode”;
global proc selectNode()
{
//получаем выделенный узел
string $sel[] = `ls –sl`;
//ищем по узлам заданный атрибут
for($node in $sel)
//проверка, что у объекта есть атрибут
if(`objExists ($node+“.selectNode”)`)
{
//получаем глобальный узел, которому подчинены элементы управления выделением
string $worldCon[] = `listConnections ($node+“.world”)`;
//проверка глобального узла чтобы узнать, хочет ли пользователь, чтобы управление выделением функционировало
if(`getAttr ($worldCon[0]+“.autoSelect”)`== 1)
{
// получаем соединения с наборами выделения, а потом выделяем эти элементы
string $root[] = `listConnections ($node+“.selectNode”)`;
select –add $root;
// отменяет выделение управления выделением
select –d $node;
// переключает инструмент на режим вращения после того, как объекты выделены
RotateTool;
}
}
}
//новый сценарий///////////////////////////////////////////////////////////
Наконец, проверьте нашу систему и убедитесь, что все соединения работают как раньше. Теперь вы можете переименовать pgWorld в ugly, а выделения все равно будут работать, как и предполагалось, независимо от имени. Убедитесь, что, прежде чем продолжать, вы вернули обратно имя pgWorld.
Риггинг головы
Голова этого персонажа немного отличается от других, потому что на нее надет тяжелый шлем с кожаными ремешками. Однако мы будем настраивать эту голову так, как будто на ней нет шлема, потому что никогда не известно, не будет ли он снят. Аниматорам останется только следить за интенсивностью движений головы с надетым шлемом.
Строению головы и шеи персонажа предъявляются некоторые дизайнерские требования. Голова должна иметь возможность переключения между глобальным пространством и пространством тела, как и другие его части. Должно быть единое управление головой и шеей, управление как перемещением, так и вращением. Вы можете сделать так, чтобы голова и шея следовали за целью, которая переключается из локального пространства в мировое, но этот тип управления ограничивает и замедляет работу, так как дает контроль только над вращением.
1. Начните с добавления ИК-манипулятора от сочленения neck до head. Назовите его ik_head и eff_head.
2. Создайте дубликат сочленения головы и назовите его ctrl_head. Затем удалите конечное сочленение и shape-узел. Разбейте подчинение ctrl_head, обнулите его перемещение, чтобы оно передвинулось к исходной точке, и сгруппируйте его. Установите Rotate Order на YZX.
3. Привяжите группу к сочленению head и назовите ее ctrl_head_Zero.
4. Подчините ik_head сочленению ctrl_head, а затем прикрепите orient-ограничителем сочленение head к ctrl_head_oriTarget.
5. Чтобы соединить скручивание головы с управлением шеей, сначала добавьте собственный атрибут neckTwist к shape-узлу ctrl_head. Это будет ограничителем для управления скручиванием шеи. Создайте multiDoubleLinear и присоедините вращение ctrl_head к узлу multiDoubleLinear, а затем к ik_head.twist.
6. Соедините ctrl_head.neckTwist с открытым соединением multiDoubleLinear. Установите neckTwist на 0.5, чтобы поворот шеи сокращался наполовину. Это нужно для того, чтобы при повороте головы из стороны в сторону шея поворачивалась не слишком сильно. Нулевое значение отключит вращение шеи, так же аниматор сможет сам анимировать значение, если потребуется.
7. Теперь управление головой нужно встроить в скелет, чтобы получить возможность переключения вращения между локальным и глобальным пространствами, а также прикрепить контроллеры головы к телу.
8. Создайте две пустые группы. Назовите главную ctrl_head_ori_Local_Zero, а подчиненную – ctrl_head_ori_Local. Создайте еще одну пустую группу под названием ctrl_head_ori_World. Подчините локальный нулевой узел сочленению spineChest, а глобальный узел – fkWorldOri_GRP.
9. Прикрепите ctrl_head_Zero orient-ограничителями к глобальному и локальному узлам, чтобы настроить переключение ориентации. На рисунке 7.64 показана сборка головы перед прикреплением её к основной сборке.
@Рис. 7.64. Голова с прикрепленным объектом управления ориентацией. Обратите внимание, что все ориентации ПК находятся на ней
Чтобы сборка заработала, контроллер головы должен следовать за грудной клеткой. Сгруппируйте ctrl_head_Zero, назовите группу ctrl_head_Attach. Подчините ее spineChest.
Добавьте собственный атрибут head в узел ctrl_fkOriShape, который содержит атрибуты других наследуемых переключателей. Воспользуйтесь Mel командой
Parent-add-shapectrl_fkOriShapectrl_head, чтобы подчинить shape-узел сочленению ctrl_head. Теперь присоедините атрибут head к весам ctrl_head_Zero_orientConstraints.
Теперь вы можете вращать контроллеры спины и главный узел персонажа, при том, что голова сохранит способность переключения следования за телом.
Риггинг позвоночника
Позвоночник вашего персонажа должен быть легким и быстрым для позиционирования без большого количества контроллеров. Аниматор не должен сражаться с ним, чтобы получить хорошие изгибы, или переделывать анимацию при настройке позы. Но позу во время анимации нужно видоизменять. Большинство сборок позвоночника сводятся к двум методам, ИК и ПК, или их смеси. До тех пор пока сделанная в ПК спина персонажа позволяет придавать бедрам любое положение независимо от верхней части туловища и пока у нас есть возможность изолировать голову и руки, то настройка желаемой позы не потребует много работы. Надеясь на аниматоров, вы можете обнаружить, что это всё, что им необходимо.
Кстати, в Character Studio есть ПК-решатель спины, позволяющий выделять разные сочленения позвоночника и аддитивно их вращать. Пользователи Maya, вращая цепочку сочленений или иерархию, считают это само собой разумеющимся. Но в Max эта функция не установлена по умолчанию, поэтому считается продвинутой для Character Studio.
Врезка. Существует скрипт для Max, который предусматривает аддитивное вращение вне Character Studio. Он работает в Max 6 и должен работать в Max 7. Он называется Rotate Chain 1.1, написан Шоном Льюисом (Sean Lewis) и доступен на www.scripspot.com.
При таком числе сочленений в позвоночнике этого персонажа и их расположении наклоны вперед/назад и влево/вправо получаются очень хорошо. Со скручиванием позвоночника возникают проблемы, но разбиение поворота на дополнительные вспомогательные сочленения (helper joints) для скиннинга работает отлично, и к этой операции есть хорошая документация. За подробностями обращайтесь к «Character Rigger’s Cookbook».
В нашей спинной сборке мы используем все преимущества управления вращением с помощью встроенной сплайновой ИК. На эту сборку спины нас вдохновил Дэвид Уолден (David Walden), который сделал очень неплохое руководство по позвоночнику – единственное руководство по продвинутому управлению вращением, которое я видел. В дополнение к этому он автоматизировал его с помощью своих инструментов dwRiggingTools.
Врезка. Скрипты dwScripts можно скачать с http://www.davidwalden.com, и среди них – классный скрипт Attribute Manager (Менеджер Атрибутов) для Maya, который дает вам обширное управление при работе с собственными атрибутами, в том числе уже настроенными. Так же очень хороши его инструменты для скиннинга. Они экономят много времени, взаимодействуя с интерфейсом Maya.
Врезка. В XSI есть очень мощный решатель позвоночника, который работает без сбоев после поворота на 180º. В нем предусмотрена настройка сгибания и гибкости области поясницы, а еще он убирает давление,так что позвоночник не оседает. В Max есть сплайновая ИК, которая хорошо работает с ограниченными приложениями, но переворачивается и меняет положение слишком просто, чтобы быть пригодной для сборки нашего вида, которую мы делаем в Maya. Как бы то ни было, есть несколько возможных альтернатив, когда сплайновый решатель (spline solver) в Max не используется, но действует это как сплайновая ИК.
Требования и дизайн сборки спины
Центр тела включает в себя управление основанием позвоночника, бедрами, позвоночником и влияние на область грудной клетки окружающей позвоночник. В большинстве сборок позвоночника обширное управление дается за счет снижения скорости анимации и контр-анимации (counter-animation) или быстрого грубого размещения без окончательного контроля над спиной. Все это дает аниматору негативный результат. Мы же хотим, чтобы сборка была и быстрым, и мощным.
Основные требования к ригу выражаются такими качествами:
независимое движение, вращение и перемещение бедер и грудной клетки обеспечивает раздельные анимационные реакции;
усовершенствование позы без контр-анимации;
размещение и анимация в ПК для лучшего действия;
при движении талии грудная клетка не двигается, и наоборот;
распределение скручивания как от бедер, так и от грудной клетки (с возможностью анимировать сдвиги скручивания (twist offsets));
сжатие и растяжение спины, которое можно уменьшить или отключить.
Чтобы обеспечить эти функции, воспользуемся сплайновой кривой в Maya в сочетании с продвинутыми параметрами скручивания, ограничителями и utility-узлами.
Врезка. Так
как мы собираемся масштабировать
сочленения позвоночника, нам нужно
удостовериться, что масштабирование
коснется только позвоночника и не
распространится на дочерние сочленения
грудной клетки. Если вы заметили, что
это происходит при ручном мастабировании,
значит, нарушилась синхронизация
локальной оси мастабирования и локальной
оси вращения, и ее нужно восстановить.
Вы должны расцепить все соединения с
сочленениями позвоночника, запустив
на каждом сочленении команду Mel
joint
-e
-zso
и перенастроив их обратно. До углубления
в настройку убедитесь, что ось
мастабирования задана верно с самого
начала. Так же, если у вас есть время,
хорошо бы написать для сборки
вспомогательные скрипты.
Для начала нужно создать второй набор сочленений, который станет ПК скелетом этой сборки. Он должен повторять сочленения спины, так что вы можете создать новые сочленения или просто дублировать их, удалив через spineChest все другие, кроме центральных сочленений тела – spine. Добавьте новым сочленения префикс ctrl и удалите единицу в конце spine1.
Спрячьте ctrl_spine на время настройки ИК на настоящей спине.
Создайте цепочку сплайновой ИК от spine до spineChest, с отключенным Auto Parent Curve (Кривая автоматического подчинения) и количеством делений, установленным на 2. Эта кривая будет перестроена, чтобы бы дать вам возможность ограничить влияние сплайна верхней частью грудной клетки и талией. Назовите цепочку ik_spine; эффектор – effspine, а кривую – ik_spineCurve.
Выделите кривую и щелкните правой клавишей мыши, удерживая Ctrl; появится опция создания кластера кривой. Автоматический скрипт кластера в Maya создает связанные друг с другом кластеры, так что вы можете снять метку отношения (relative flag) на каждом кластере.
Врезка. Самый
быстрый способ сделать это – удалить
проверку отношения (relative
check)
из поставляемого вместе с Maya
скрипта. Скрипт называется clusterCurve.net
и находится в основной директории
скриптов Maya
C:\Program
Files\Alias\Maya6.0\scripts\other.Скопируйте
этот скрипт и поместите его в папку My
Documents\maya6.0\scripts;
затем отредактируйте его, удалив строчку
-relative
из команды группировки.
Теперь давайте создадим контроллеры спины. Эти формы будут управлять перемещением, вращением и скручиванием спины. Создайте первую кривую в форме куба и сгруппируйте ее. Назовите группу ctrl_chest_Zero. Привяжите опорную точку группы к spineMidBack. Заморозьте ее перемещения. Отлаживайте контрольные вершины кривой до тех пор, пока форма не придет в соответствие с телом, как показано на рисунке 7.65.
@Рис. 7.65. Управляющие формы сборки спины и Outliner, показывающая кластеры и ИК-манипулятор
Врезка. Вам может быть непонятно, почему мы разместили управление грудной клеткой так низко на позвоночнике. Мы обнаружили, что большинство сборок со сплайновой ИК работают наилучшим образом, когда элемент управления вращается вокруг точки, где ребра соединяются с позвоночником, а не пограничной точки между шеей и грудным отделом позвоночника. Это дает аниматору больше контроля и снижает необходимость контр-анимации.
Теперь мы будем прикреплять orient-ограничителями сочленение грудной клетки к её контроллеру. Чтобы убедиться, что элемент управления совпадает с сочленением в ПК, мы дублируем чистое сочленение ctrl_spineChest и подчиним его ctrl_chest_Zero.
Назовите кривую ctrl_chest и обнулите ее перемещение. После этого сделайте узел кривой управления дочерним ctrl_chest.
Выделите и сгруппируйте два верхних манипулятора кластера, в данном случае cluster4Handle и cluster5Handle. Отрегулируйте положение центральной точки и назовите группу ctrl_upperBack_Zero. В заключение подчините ее ctrl_chest.
Теперь вы сможете управлять поворотом и перемещением верхней части повоночника, но грудная клетка все еще поворачивается, когда перемещаете ctrl_chest. Чтобы исправить это, прикрепите spineChest orient-ограничителем к ctrl_chest.
Повторите эту процедуру при создании управления бедрами. Просто поменяйте название chest на waist и вместо сочленения грудной клетки используйте для управления сочленение, которое соответствует положению родительского сочленения.
Сгруппируйте последние три кластера, назовите группу ctrl_lowBack_Zero и подчините их ctrl_waist.
Присвойте названия ctrl_Back_Cluster_# всем манипуляторы кластеров спины, считая снизу вверх, с номерами от 1 до 6.
Теперь прикрепите сочленение root точечным ограничителем к ctrl_waist (рис. 7.66).
@Рис. 7.66. Текущее состояние сборки с кластерами подчиненными контроллеру талии
Наконец, нужно прикрепить root к ctrl_waist orient-ограничителем.
Настройте скручивание спины так, чтобы оно происходило при повороте контроллеров позвоночника. Выделите ik_spine и откройте Attribute Editor. В меню IK Solver Attributes → Advanced Twist Controls (Атрибуты ИК-решателя → Продвинутое управление скручиванием) отметьте Enable Twist Controls (Разрешить управление скручиванием) и установите тип World Up на Object Rotation Up (Start/End). В пустых графах World Up Objects введите названия ctrl_waist и ctrl_chest (рис. 7.67).
@Рис. 7.67. Настройка контроллеров скручивания
Последний шаг к работе ИК и ПК состоит в прикреплении orient-ограничителем настоящего сочленения позвоночника к управляющим сочленениям, которые мы дублировали в самом начале. Быстрый способ – взять ctrl_spine и сочленение spine и сделать orient-ограничитель. Потом просто продвигаясь дальше, нажимая горячую клавишу G (повторяет последнюю команду), чтобы завершить прикрепление остальных сочленений позвоночника. (Для пользователей Max: если вы поместите меню Constraint (Ограничение) в меню прямоугольника, то сможете запустить команду сразу; после этого одно лишь выделение верхушки прямоугольника будет повторять последнюю команду, выполненную в прямоугольнике. Но вместо инструментального подхода Max мы рекомендуем скрипт, имитирующий Maya-стиль выделения объектов и их прикрепления.)
Следующая вещь, которую вам нужно сделать – добавить контроллеру грудной клетки некоторые собственные атрибуты, чтобы настроить переключение ИК/ПК. Добавьте в ctrl_chest атрибут ikFK, минимальное значение 0, максимальное – 1, по умолчанию 1. Соедините его с ik_spine.
Сжатие и растяжение спины
Придание позвоночнику способности сжиматься и растягиваться помогает предотвратить разрыв грудной клетки и бедер, а также добавляет дополнительный слой более тонкого или расширенного управления для аниматоров. Есть несколько способов настроить сборку таким образом. Как техническому директору по персонажам, вам придется решить, хотите ли вы, чтобы сочленения спины имели возможность масштабирования или перемещения; чтобы эти изменения были ограничены неким диапазоном или просто показывались цветовым индикатором или как-нибудь по-другому; чтобы их можно было включить или отключить; должен ли размер изменяться как в режиме ПК, так и в режиме ИК. Эта функция, как и любая другая автоматизированная функция сборки, должна включаться и отключаться, независимо от того, как вы ее настроите. (Для игрового движка вам также понадобится узнать, поддерживает ли она масштабирование или перемещение.)
Врезка. В качестве начальной точки хорошо по возможности применять инструменты автоматизации или встроенные инструменты, при этом, применяя к сборке скрипт, нужно убедиться, в том, что вы понимаете, что этот скрипт делает. Скрипт из пакета Bonus Tool создает растяжение, контролируя масштаб с помощью узла дистанции, вместо узла длины дуги. В сочленениях для управления степенью сжатия или растяжения используются пределы масштабирования, в то время как сам масштаб контролируется через узел multiplyDivide (Y и Z реагируют на значение X), а затем через узел plusMinusAverage, где значения от узла multiplyDivide вычитаются, чтобы получить твердое значение масштабирования, равное 1. Запуск этого сценария приводит также к скрытию атрибутов перемещения сочленений позвоночника. Сценарий довольно открытый, и я призываю вас обратить внимание на его строение, чтобы понять, как он работает:
Настройте сжатие и растяжение этой сборки через масштаб сочленений помощью встроенного Bonus Tools → Stretchy IK (Бонусные инструменты → Растягивающаяся ИК). Выделите ik_spine и запустите скрипт; X указывает вниз, так что выберите X в всплывающем меню. (Чем больше вы используете Bonus Tools, тем лучше, потому что среди них есть множество инструментов, которые следовало бы полностью встроить в Maya). Вы также можете воспользоваться сборкой сжимающегося и растягивающегося позвоночника из второй главы, вместо бонусных инструментов.
После запуска скрипта вам нужно кое-что изменить в соответствии с настройкой вашей сборки. Во-первых, нужно разбить родительскую связь локаторов расстояния, потому что эти связи приводят к зацикливанию. Кроме того, нужно присвоить локаторам названия. Назовите их ctrl_ikScaleLow и ctrl_ikScaleUp. Узел дистанции назовите ik_spine_ScaleDistance.
Подчините ctrl_ikScaleLow узлу ctrlWaist, а ctrl_ikScaleUp – ctrl_chest. Это устраняет цикл и передает слежение масштаба на контроллеры спины. Заморозьте перемещения этих двух локаторов.
Как уже упоминалось раньше, нет быстрого способа отключить или приглушить эффект растяжения. Но наша настройка хороша тем, что мы можем управлять размером грудной клетки и бедер вместе или по отдельности.
Создайте новый собственный атрибут shape-узла ctrl_chest под названием squashSretch (если хотите, можете назвать shape-узел xtraAttrs).
Затем создайте новый узел pairBlend. Удерживая Ctrl, выделите узел дистанции и ctrl_chest в Outliner и откройте их схему в Hypergraph (рис. 7.68).
@Рис. 7.68. Новый узел и схема, созданные скриптом растягивающейся ИК
Узел pairBlend будет помещен между входными данными от ctrl_ikScaleUp к узлу ctrl_ikScaleDistance. Наш собственный атрибут squashSretch, управляющий грудной клеткой, будет ведущим для атрибута pairBlend.weight и будет смешиваться с любым значением, заданным в узле pairBlend, при этом узел дистанции будет считать, что расстояние не изменилось. На рисунке 7.69 показано соединение с узлом pairBlend, а на рисунке 7.70 – окончательные соединения pairBlend с узлом дистанции.
@Рис. 7.69. Соединяя узел pairBlend
@Рис. 7.70. Окончательные соединения
Нам нужно добавить значение сочетания по умолчанию (default blend value), чтобы позвоночник считал, что расстояние одно и то же. Выделите узел pairBlend и откройте Attribute Editor. Установите для состояния покоя равные значения (In Translate1) и (In Translate2). Перенастройка растягивающегося позвоночника теперь закончена. Протестируйте его, вытянув спину вверх а затем уменьшив значение атрибута squashSretch. Позвоночник должен вернуться к своей прежней длине, со значениями 1, 1 в спине и значением 1 - масштаба.
Как вы могли заметить, мы работали только с верхним локатором. Это значение сжатия и растяжения работает только с верхней частью спины; управление талией все еще растягивает спину. Эти же процедуры можно применить к нижней части спины. Таким образом, мы получим обширное управление позвоночником в его максимальном растяжении (рис. 7.71). Эффект сжатия и растяжения позвоночника точно так же работает в ПК.
@Рис. 7.71. Верхнее и нижнее соединения с узлом дистанции спины
Врезка. Если вы производили эту настройку в Max, то вы могли вместо инструмента Distance применить инструмент Measure вместе со списком весов контроллеров, чтобы смешивать включение и отключение влияния на размер.
Финальные контроллеры спины и чистка Outliner.
Чтобы завершить сборку спины, вам придется добавить еще одну управляющую форму, которая будет основным контроллером верхней части туловища:
Создайте новый управляющий объект, как и при работе с грудной клеткой и бедрами, с помощью сочленения и кривой. Назовите его ctrl_master и сгруппируйте, чтобы получилась нулевая группа.
Новый контроллер будет находиться не в основании спины, а в центре тяжести. Где именно, догадаться довольно легко, но можно наскоро сделать простое прикрепление. Выделите root и оба бедра, а затем и узел ctrl_master_Zero. Сделайте точечное прикрепление, а сразу после этого – Constrain → Remove Target (Прикрепить → Удалить цель). Узел ctrl_master_Zero теперь будет в центре таза.
Вы даже можете приблизить его к положению на прямой линии с сочленениями бедер, в зависимости от того, как, по вашему мнению, должен работать контроллер. При анимации этот контроллер будет производить такой эффект, как если бы вы попытались наклониться, оставляя ноги и таз в покое. Обратите внимание, что, когда вы откидываетесь назад, таз вращается вокруг того места, где находится углубление для ноги, и поэтому вы не падаете. Это совершенно особое движение, сильно отличающееся от поворота в основании позвоночника, как, например, при выпаде тазом или его скручивании. Эта точка вращения также очень заметна, когда вы садитесь или когда ваш зад находится на твердой поверхности.
Сгруппируйте ik_spine, ik_spineCurve и ik_spine_ScaleDistance. Назовите группу ik_backrig_Grp.
Подчините ctrl_spine, ctrl_Waist_Zero и ik_backrig_Grp узлу ctrl_master.
Так как вы подчинили ik_spineCurve элементу, который также управляет кластерами, двигающими кривую, то вы создали двойной сдвиг. Это легко исправить. Выделите кривую и зайдите в Attribute Editor. Отключите опцию Inherits Transform (Наследуемые Трансформации). Это простой способ сохранить важную для организации геометрию в группах, при перемещении которой возникают проблемы.
С доступным для ctrl_Master диапазоном движений сборке необходим дополнительный управляющий слой, во избежание блокирования шарнирного соединения. Просто сгруппируйте его и назовите новую группу ctrl_Master_Gmbl. Обозначьте текстовый объект в виде кривой (curve text object) буквами gm и подчините его shape-узел группе ctrl_Master_Gmbl.
Создайте дополнительный атрибут shape-узла ctrl_Master под названием gmblCtrl. Задайте логический тип значения. Соедините его собственный атрибут с видимостью curveShapes группы ctrl_Master_Gmbl, чтобы аниматоры могли по необходимости воспользоваться этой группой, но чтобы она была невидима для выделения. Если вы соедините этот атрибут с видимостью управляющего узла-трансформы, то будет скрыт а вся сборка спины целиком (рис. 7.72).
@Рис. 7.72. Завершенная сборка спины с собственными атрибутами для управления шарнирным соединением
Врезка. Возможно, вам понадобится создать такие же дополнительные контроллеры на других частях тела персонажа, например, в запястьях или в любом узле, который должен делать полный поворот на 360º больше, чем по одной оси. Просто следуйте той же процедуре, создавая элементы, управляющие перенастройкой вращения.
Переключение руки между локальным и мировым
Теперь, настроив сборку спины, мы можем снова обратиться к локальному и глобальному узлам руки и подчинить их соответствующим контроллерам, или прикрепить к ним родительскими ограничителями. Глобальный контроллер должен находиться в глобальном пространстве персонажа, так что он останется там, где есть. Локальный контроллер будет прикреплен parent-ограничителем к ctrl_chest. Его можно прикрепить к некоторым другим частям тела, например, к голове, а потом дать пользователю контроль смешивания локального пространства, которое он хочет использовать.
В зависимости от того, какой работы вы ждете от сборки при другом переключении локального и глобального наследования, например, в случаях с руками и головой, можно применить родительский ограничитель. При этом глобальное пространство будет не полностью глобальным узлом, а под ctrl_master. Помните, что все глобальные ориентировки подчинены fkWorldOri_GRP.
Управляемое атрибутом переключение видимости
В этой теме нужно рассмотреть еще несколько переключений видимости. Сделайте так, чтобы значение переключения ctrl_arm_L|xtraAttrs.worldLocal управляло видимостью узлов L и W. Аниматорам нужно предоставлять как можно менее запутанный файл. Это часть конструирования пользовательского интерфейса сборки. В случае с включением/отключением видимости атрибута смешивания нужно убедиться, ясно ли художнику, когда в нем сочетаются глобальные и локальные настройки, а когда он работает с чем-то одним. Применение Set Driven Keys – простой и быстрый способ настроить это, но можно также прибегнуть к помощи узлов с условием. Когда переключатель установлен на 0, работает глобоальное пространство, и L должен быть скрыт; когда на 1, рука находится в локальном пространстве, и должен быть скрыт W. Любое смешанное значение в промежутке между ними делает видимыми и L, и W одновременно.
Чтобы показать, когда аниматор работает в ПК, а когда в ИК, вы проделаете операции такого же типа с ctrl_back, но только с цветами, а не с видимостью, так как спина может управляться и ПК, и ИК одновременно. Изменение цвета может помочь аниматору догадаться, какие ключевые кадры влияют на риг. Управляйте цветом в ctrl_chestShape под Display Overrides с помощью пробного Set Driven Key, чтобы управляющий элемент в режиме ПК переключался от синего по умолчанию на голубой. Отличие небольшое, но его достаточно для быстрой подсказки о настройках управляющего элемента. Поищите атрибут Override Color shape-узла, чтобы сделать SDK.
Эти идеи можно внедрить целиком или же использовать лишь частично; идея обратной связи с аниматором – одна и та же. Чем больше времени тратится на то, чтобы вникать в действия сборки после анимации, тем больше времени займет анимация или исправление неполадок сборки. Последний способ облегчения управления сборкой – контролировать возможность выделяемости объектов, управляя значением переназначения ссылок (reference override value), при этом оставаясь вне слоев, чтобы персонаж сохранял самостоятельность. В этом случае на него можно легко установить ссылку, многократно импортировать в файл или даже сохранить, с тем чтобы отослать на рассортировку анимации.
Дополнительные визуальные индикаторы, например, линии, соединяющие плавающие управляющие элементы (такие, как полярные векторы рук), тоже удобны и легко делаются либо с кластерами и двухточечной кривой, либо с помощью чего-нибудь вроде команды аннотации для создания стрелки (arrow) и текстовых пометок для управляющего элемента.
Врезка. Вот совет для пользователей Maya. У вас есть возможность разобраться с отображением сочленений, ветвящихся в таких местах, как бедра или грудная клетка. Установите Draw Style (Стиль Прорисовки) сочленения, которому подчинены все ветвящиеся узлы, на Box, а не на Bone, и файл визуально будет быстро упорядочен гораздо меньшими усилиями.
В версии 6.5 появилась возможность управлять размером сочленения через файл и через конкретное сочленение, что позволяет произвести упорядочивание и отладку. В версии 6.0 эти настройки были глобальными, от файла к файлу.
Риггинг правой руки
Может показаться странным, что мы откладывали до этого момента риггинг правой руки. Так как сборка руки, из за количества соединений с другими частями сборки это одна из наиболее сложных систем персонажа, проще полностью закончить одну руку и убедиться, что она работает, а потом зеркально отразить ее на другую сторону или скопировать строение с рабочего варианта. В этой книге мы советуем вам создавать последний вариант, чтобы вы лучше понимали процесс риггинга. Тем не менее, вы можете пойти путем отражения части сборки, если вы уверены, что понимаете её устройство.
Для зеркального отражения сборки может потребоваться много работы: настройка соединений между ограничителями, собственными атрибутами и сетью utility-узлов. Как утверждалось вначале, лучше всего по возможности автоматизировать этот процесс. Следующая часть познакомит вас с отражением сборки с помощью Hypergraph и чистого файла для отражения. Пока вы работаете над созданием отражения сборки, лучше избавиться от всего того, что непосредственно не относится к риггингу руки. Первый шаг в отражении сборки руки – взглянуть на все узлы, составляющие руку, и проверить входящие и исходящие соединения компонентов руки:
1. Примените Outliner, чтобы отфильтровать только названия с *arm*; будут показаны все узлы, относящиеся к сборке руки и те узлы, которым они подчинены. Следуйте дальше и удалите все, что не является частью системы руки – ноги, голову, контролирующие ИК и так далее (рис. 7.73).
@Рис. 7.73. Отправная точка для начала отражения руки
2. Так как с правой рукой вы работаете в новом файле, следуйте дальше, ищите в именах L и меняйте на R. Еще вам придется удалить все ограничители и соединения для ваших новых контроллеров. Соединения будут установлены в окончательном файле, и вы должны убедиться, что импортируются только чистые контроллеры, и не один из них не должен внести с собой дополнительные присоединенные к ним узлы. Чтобы избавиться от них, следуйте пунктам меню Edit → Delete All by Type → Constraints (Редактировать → Удалить все по типу → Ограничители) (рис. 7.74).
@Рис. 7.74. Удаление всех ограничителей и других ненужных узлов
3. Затем давайте обратим внимание на простые элементы, как, например, ctrl_worldLocal_arm_R. Так как точки опоры контроллеров не меняются, то для создания отраженной версии вы просто переместите вершины управляющей формы, на восемь юнитов, посредством привязки к сетке.
4. Теперь можно отразить сочленения, включая цели orient-ограничителей.
5. Сгруппируйте все, что осталось в файле, кроме сочленений (вы должны будете разбить дочерние связи контроллеров, основанных на сочленениях), и отрицательно отмасштабируйте по X, чтобы перевернуть все узлы. Чтобы заморозить перемещения, вам нужно разбить все соединения узлов. После этого заморозьте перемещения и разбейте все подчинения этого группового узла. Сохраните этот файл.
6. Загрузите этот чистый файл в файл главной сборки. Начните добавлять ИК-манипуляторы в скелет правой руки и в сборку лопатки. Назовите их так, чтобы имена совпали с именами левых ИК-манипуляторов. Все узлы-трансформ были отражены, поэтому новый ik_arm_R можно подчинить aux_armZero_R, а его – узлу pgWorld (рис. 7.75).
@Рис. 7.75. Новые узлы руки, подчиненные основной иерархии
7. Прикрепите ik_arm_R полярно-векторным ограничителем (pole vector constraint) к ctrl_elbow_R, а aux_blend_R – точечным ограничителем к ctrl_arm_R, точно так же, как с другой рукой.
8. Продолжайте заново подчинять и прикреплять узлы правой руки, пока они не будут идентичны левой руке. Когда это будет сделано, можете подключить все заданные атрибуты и сети узлов. (Иногда вращение или ориентацию отраженных сочленений нужно исправлять или заново приводить в соответствие с первоначальными сочленениями после подчинения, так что следите за тем, чтобы вращения сочленений во время работы оставались нулевыми.)
Это занятие может быть очень утомительным, но знать, как отражать более или менее сложную сборку, полезно. И снова, несмотря на это, что мы делаем акцент на важности скриптов в тех случаях, когда вам нужно сделать больше, чем одну персонажную сборку, или даже одну сборку, которую нужно будет доработать или исправить позднее.
После того, как все узлы подчинены и прикреплены, вы готовы к подключению собственных атрибутов, отраженных вместе с контроллерами.
9. Постепенно продвигаясь глубже, начните с контроллеров кисти. Выберете их и левые, и правые и отобразите их соединения. Это позволит вам увидеть, какие узлы и атрибуты соединены, и вы сможете дублировать utility-узлы левой руки и подключить их к правой. В зависимости от атрибутов, которыми вы управляете, вам, возможно, придется добавить знаки «-» (минус) к узлам unitConversion, чтобы значения атрибутов производили такой же результат.
10. Чтобы сделать возможным автоматическое выделение на правой руке, вам нужно просто добавить узел описания, как и слева, и еще добавить в узел описания руки собственный атрибут selHand типа string и соединить его с пальцами. (Так как вы отразили сочленения, собственные атрибуты уже будут присутствовать в них.)
11. После того, как вы прошли через все это и закончили с соединениями узлов и атрибутов, отобразите схему обеих рук, которая выглядит как рисунок 7.76. Кое-что на заметку: вы можете дублировать узлы Set Driven Keys, но чтобы они работали на правой руке, их значения нужно перевернуть в Graph Editor.
@Рис. 7.76. Совпадающие схемы управляющих элементов обеих рук после соединения вручную
Исправления ноги: избавление от вращения, наследуемого от бедер
Обратившись снова к риггингу ног, мы увидим, что все работает отлично. Всё, кроме вращения, вызванного методом, каким мы настраивали полярный вектор, чтобы нога не переворачивалась. Побочный эффект заключается в том, что родительский узел ноги, заставляет ее вращаться. Колено направляется в противоположную сторону внешнему контроллеру стопы, и аниматоры вынуждены контр-анимировать ногу. Чтобы решить эту проблему, мы собираемся исключить любое вращательное влияние бедер на сочленения ноги:
Создайте пустую группу и подчините ее bn_hips. Назовите ее ctrl_leg_GRP_R.
Нужно привязать групповой узел к вершине сочленения ноги и заморозить перемещения.
Выделите ctrl_upLeg_R и ctrl_upLeg_ori_R. Подчините их ctrl_leg_GRP_R.
Мы не хотим, чтобы вращение бедер влияло на ноги. Чтобы исправить это, начните с создания пустой группы или нулевого объекта.
Назовите его ctrl_legs_Ori; он будет объектом привязки ориентации обеих ног. Подчините его bn_hips и заморозьте перемещения; потом подчините его pgSkeleton. Ориентация необходимая для следующего шага будет выровнена.
Присоедините ctrl_leg_GRP_R orient-ограничителем к ctrl_legs_Ori, который исключит влияние bn_hips на ноги.
Опробуйте систему, повращав контроллеры бедер; верхняя часть ноги должна двигаться, но когда вы поворачиваете бедра влево и вправо, колено должно по-прежнему указывать точно вперед.
Проработав правую ногу, проделайте то же самое с левой, заменяя по необходимости R на L.
Итоговая работа
Когда основные компоненты риггинга завершены и скреплены, файл с функциональной точки зрения готов, но его все еще нельзя передать аниматору, не приведя в порядок. Очистка файла подразумевает выполнение следующих шагов:
Доделайте все видимые объекты для таких контроллеров, как например смешивание ИК/ПК;
Создайте конечные группы и завершите очистку Outliner;
Спрячьте и ограничьте видимость/выделяемость всех объектов, кроме только тех, которые будут подвергнуты анимации;
Заблокируйте и спрячьте все атрибуты, которые не будут анимированы;
Создайте группы выделения как для анимационных контроллеров, так и для атрибутов сборки, которые имеют значение для технического директора по персонажам;
Настройте управляющие элементы так, чтобы автоматически выделялся тот инструмент, который должен к ним применяться: режим вращения, перемещения или и то, и другое;
если нужно, установите заданную систему pickwalk, чтобы аниматоры могли осуществить pick walk up and down, не выделяя не предназначенный для захвата управляющий элемент.
Врезка. Блокируя и скрывая атрибуты, помните, что хорошо бы скопировать и вставить содержимое Script Editor в текстовый файл. Это быстрый способ скрыть и вновь показать все мелкие часты сборки, так что потом вы сможете доработать и наладить сборку, не затрачивая дополнительных и совсем ненужных усилий. В Maya 6 есть возможность фильтровать выходные данные, не включая в них все результаты, информацию, предупреждения или сообщения об ошибках. Так, копируя и вставляя, вы сможете создать очень чистый скрипт.
Видимая обратная связь
Первым этапом очистки станет завершение добавления цветных контроллеров руки, дающих аниматорам знать, что они находятся в определенном режиме. Точно так же мы поступали с контроллерами спины. Так как proxy-геометрия находится на слое, вы должны разбить соединение с переопределением цвета (override color), чтобы связать его с атрибутом IKFK. Это приведет к тому, что модель больше не будет связана со слоем, но вы можете просто переназначить её к слою, так как цвет имеет входящее соединение. Переключение цвета тем не менее будет работать, потому что слой не смог разбить соединение SDK.
Еще один простой способ показать, в каком состоянии находится контроллер, – включить или выключить текст или примечания, в зависимости от значения атрибута. Например, в случае с руками вы можете сделать видимым небольшой текстовый объект рядом с ИК контроллером руки, в котором IK задается ярким цветом, что дает представление о том, в каком режиме находится сборка.
Каким бы образом вы, как технический директор по персонажам, не пожелали бы организовать обратную связь с аниматором, важно, чтобы вы сделали что-нибудь для сообщения состояния сборку, чтобы было легко работать с ним и анимировать.
@Рис. 7.77. Отображение линий
Чтобы сделать простое, наглядное соединение между плавающим контроллером, таким как локтевой, и управляемыми им сочленениями, создайте простую двухточечную кривую. Таким кривым требуются только две вершины, чтобы образовать линию. Создайте кластеры для двух точек кривой и подчините один верхнему сочленению руки, а второй – локтевому контроллеру. Теперь, куда бы вы ни сдвинули локтевой контроллер, система дает очень четкую видимость соединения с управляемой им частью, держа ее отдельно от всего остального. В нашем файле узлы называются ctr_elbowDisplay_L или R.
Приведение Outliner в порядок
Чем лучше упорядочены Outliner и иерархия файла, тем быстрее работа со сборкой и её редактирование и тем проще её анимировать, поэтому нужно убедиться, что все элементы сгруппированы и упорядочены как следует. В Maya изменение порядка в Outliner также служит для управления порядком выделения; например, перенесение узлов ближе к вершине Outliner приводит к тому, что они просчитываются первыми в схеме сцены (scene graph). Это напрямую влияет на то, как элементы выделяются и просчитываются, так что вам нужно постараться и держать контроллеры в иерархии выше, чем все остальные. Рисунок 7.78 показывает единственный возможный способ сгруппировать и упорядочить Outliner. Здесь виден скелет, контроллеры и дополнительные части, которые трогать не надо. Группа контроллеров выше в списке, чем скелет или «неприкасаемые узлы», потому что мы хотим, чтобы контроллеры выделялись первыми, даже если их перекрывают другие объекты.
@Рис. 7.78. Чистка групп в Outliner
Блокировка и скрытие
Завершающая стадия «уборки» включает в себя очистку каждого узла сборки, чтобы анимированы были только те атрибуты, которые должны быть анимированы, а каналы, для которых не должны быть установлены ключи, остались без ключей. Это не удерживает аниматоров от отмены скрытия и блокировки этих атрибутов, но всё же это полезно для предотвращения подобных действий. Если вы можете применить ссылки на файлы в вашей сборке или уже применяете, то все, что вы заблокировали или скрыли, аниматор изменить не сможет, также этот способ защищает кривые и соединения SDK от ошибочного удаления. Еще это выгодно тем, что меньшее количество ключевых кадров означает меньше кривых данных, меньше узлов и меньше соединений, и все это сохраняет скорость работы сборки. Если у некоторых контроллеров способность посмотреть значение атрибута может быть полезной для обратной связи, то не прячьте его, а просто заблокируйте. В хорошо скрытых контроллерах я обычно блокирую атрибуты, а не прячу их. Во всех контроллерах, которые затрагивает аниматор, я блокирую и скрываю атрибуты.
Не забудьте включить и отфильтровать выходные данные Script Editor для всех атрибутов, которые вы заблокировали и скрыли, и объектов, видимость которых вы включили или отключили. Это позволяет очень быстро копировать/вставлять скрипт, чтобы включить или отключить все, что должно быть спрятано или заблокировано, когда вам нужно углубиться в редактирование сборки. Чтобы вновь показать все, вам нужно написать только быстрый цикл for. Он пробежится по всем узлам, сделает их видимыми, покажет и разблокирует основные атрибуты.
После блокировки и скрытия атрибутов нужно заблокировать и скрыть те части сборки, которые не должны быть выделены аниматорами. Быстрый способ – просто сбросить все на отдельный слой, и готово. Трудность тут в том, что первое, что люди делают, когда открывают файл, – отображают все. Аниматоры пользуются скрытием и отображением постоянно, чтобы видеть только определенные части персонажа, и из-за этого нам нужно подойти к скрытию творчески. Чтобы скрыть любой объект и расправиться с проблемой «показать все», нужно проверить, что вы заблокировали атрибут видимости объекта. На некоторых объектах вы должны сначала сделать атрибут видимости видимым в Channel Box, а потом заблокировать его.
На этом этапе вы также можете вернуть обратно всем ярко-желтым сочленениям цвета по умолчанию в соответствии с частями тела, так как они были сделаны желтыми только для того, чтобы нам было проще настраивать объекты. Но все-таки лучше записать это в скрипт отображения мелких деталей, ради возможности вернуть сборку к начальному состоянию.
Также частью очистки модели является проверка того, что аниматоры не выделяют proxy-геометрию, не предназначенную для управления ПК анимацией. Так как все части модели находятся в слое, слой можно держать без изменений, но нужно разбить управляемое слоем соединение, которое позволяет устанавливать значение шаблона или ссылки на каждый объект модели. Ниже приведен простой цикл for, используемый для разрушения всех связей слоя на всех выделенных частях модели.
//убивает соединение слоя
{
string $sel[] = `ls –sl`;
for ($obj in $sel) {
CBdeleteConnection ($obj + “.ovdt”);
}
}
Запустив сценарий, примените контроль каналов, чтобы переместить overrideDisplayType в раздел keyable и установите для него ключевой кадр, чтобы не допустить соединения слоя с ним после того, как мы переназначим модель слою. Таким образом, слой все еще управляет видимостью, но мы управляем типом отображения. Если вы вообще не хотите применять слой, то можете создать главный атрибут proxy-модели, управляющий видимостью всех её частей. Теперь, получив контроль над моделью, установите её как ссылку на все, что не будет использоваться как ПК контроллер.
Чтобы вы могли использовать слои, вы должны сохранять входящие соединения любых узлов, которые будут установлены как ссылки. Мы можем оставить ключевые кадры, но тогда появляется шанс легко удалить их по ошибке. Вместо этого просто установите собственный атрибут в pgWorld –Enum – и сделайте три значения: Normal, Template, Reference. Назовите атрибут prxyViz. Соедините значения с входными каналами атрибута displayOverride proxy-геометрии. Это позволяет нам управлять ими из одной части сборки и не дает управление слою. Чтобы полностью удалить слой из proxy-модели, можно также добавить в pgWorld атрибут видимости prxyVisibility и подсоединить его ко всем атрибутам видимости prxyShape.
Группы выделения и группы персонажей
Создание групп выделения контроллеров может оказаться лучше, чем лишь предположение о том, что группировка и именование сами по себе сделают сборку простой в редактировании. Трудность здесь в том, что, пытаясь держать все в нужных группах, вы можете нажить себе дополнительной работы, с целью добавления большего количества ограничителей или, обдумывая как нужно соединить контроллеры, когда на самом деле узел просто должен быть подчинен части сборки. Так как группы выделения не зависят от иерархии, они представляют собой совершенный инструмент для группировки компонентов сборки. Как минимум, нужно создать группу для каждой системы сборки, например, для сборки всего позвоночника, рук, ног и головы. Это делает файл легко редактируемым для вас или для кого-то ещё, без необходимости просматривать всю иерархию, чтобы найти все компоненты сборки.
Группы персонажа будут настроены как для Trax-совместимости, так и для того чтобы сделать возможной группировку всех данных анимации, независимо от иерархии. И, снова, это очень удобно и освобождает вас от беспокойств по поводу управления ключевыми кадрами, с которыми при большом количестве контроллеров могут возникнуть некоторые проблемы. Это особенно важно при попытке сохранить синхронизацию чего-нибудь вроде переключения ИК/ПК в руке. Мы советуем вам построить группу персонажа или подгруппу из всех узлов, которые нужно анимировать в ИК и ПК, а также других узлов, которые могут повлиять на переключение режимов руки, в том числе локтевой полярный вектор или узлы ключиц. Для настройки подперсонажа также будет хороша и другая группа узлов – пальцы. Это упрощает управление, размещение и установку ключевых кадров для пальцев.
Врезка. Замечание насчет именования: так как некоторые атрибуты называются одинаково и принадлежат узлам, которые так же называются одинаково, нужно убедиться, что узлы, находящиеся на одном и том же уровне, различаются по крайней мере буквами L и R, иначе вы не сможете различить атрибуты. Это легко исправить и потом, если понадобится.
Автоматическое выделение инструмента и настройка прохода выделения
Один из лучших способов сделать работу со сборкой быстрее – настроить контроллеры так, чтобы они автоматически переключались на тот инструмент, который должен с ними использоваться. ПК контроллеры являются вращаемыми, и при их выделении текущий инструмент должен переключаться на Rotate. Перемещаемые контроллеры должны переключать вас на инструмент Move и так далее. Так же в Maya есть мульти-манипулятор, позволяющий вращать и перемещать одновременно и который нужно устанавливать на такие узлы, как контроллеры ног или головы, где один и то же контроллер и вращается и перемещается. Это один из лучших способов визуально усилить представление о том, что конкретный контроллер персонажа из себя представляет.
Применение встроенного в Maya метода требует работы в режиме выделенного манипулятора и предполагает, что вы настроите переключения инструмента в зависимости от объекта с помощью атрибута showManipDefault, который можно установить через Mel или в меню Display в Attribute Editor.
Другой способ сделать это – использовать такой же скрипт, как в сборке руки, когда он видит собственный атрибут и даже может прочитать настройки манипулятора атрибута showManipDefault. Скрипт может напрямую установить инструменты Rotate, Translate или Scale, что избавляет вас от необходимости находиться в режиме выделения. На самом деле, в скрипте сборки руки это выполнялось командой RotateTool.
Врезка. Для пользователей Max существует скрипт под названием SMART SELECT v.0.1, написанный Мартином Ван Херком (Martin Van Herk). Он доступен на http://www.scriptspot.com. Этот скрипт позволяет делать то же самое, что и наш, но текстовые команды, запускающие инструмент Scale, Rotate или Translate, нужно вводить в пользовательских настройках (user properties) объекта. (Пользовательские настройки объекта в Max – это то же самое, что вкладка Notes (Заметки) в Attributes Editor в Maya.)
Вот аналогичный Maya скрипт, размещенный на Highend 3D listserv Шахаром Левави (http://www.levavi.net/). Чтобы воспользоваться им, добавьте собственный атрибут в каждый контроллер сборки (руки, бедра, ноги и т.д.) и назовите его defaultTool.
Это атрибут типа Enum с тремя опциями: 0, 1 или 2 (или move, rotate, scale). После этого добавьте скриптовый узел, который выполняется каждый раз при запуске файла.
В скриптовый узел поместите этот скрипт.
////////////////////////////////////////////////////////////
global proc SL_toolSwitch()
{
scriptJob –e “SelectionChanged” “whichTool”;
}
global proc whichTool()
{
string $gTools = ‘currentCtx’;
string $obj[] = ‘ls –sl’;
if (size($obj) != 0)
{
if (‘attributeExists “defaultTool” $obj[0]’)
{
string $tool = ‘getAttr ($obj[0] + “.defaultTool”)’;
switch ($tool)
{
case “0”:
$gTools = “moveSuperContext”;
break;
case “1”:
$gTools = “rotateSuperContext”;
break;
case “2”:
$gTools = “scaleSuperContext”;
break;
}
}
}
setToolTo $gTools;
}
////////////////////////////////////////////////////////////
На рисунке 7.79 показана окончательная сборка с группами персонажа, окончательными группами и группами выделения.
@Рис. 7.79. Окончательная сборка.
Законченная сборка, на самом деле никогда не может быть законченной. Попав в производство она проходит через изменения и переработки, подвергается тонкой регулировке. Будем надеяться, что идеи, обсуждавшиеся в этой главе и во всей книге, помогут вам создать стабильную, быструю сборку, которая станет твердой основой вашей работы.
