«В двух книгах Книга первая ООО Арт Хаус медиа Москва 2007 Цыпцын Сергей. Понимая MAYA Издательство ООО Арт Хаус медиа, 2007 В двух книгах/ М. Издательство ООО Арт Хаус медиа, 2007 1428 с. ISBN 978-5-902976-03-5 Эта ...»

Итак, для любого объекта всегда существует мировое пространство (world space), пространство объекта (object space) и локальное пространство (local space, или пространство родительского объекта). Есть еще параметрическое пространство, определенное для NURBSкривых и поверхностей, но о нем мы поговорим в соответствующей главе.

Сброс и заморозка (Reset и Freeze).

Новое место рождения объекта. Разворот локальных осей Любой объект где-то рождается, то есть создается. Если в результате безумных перемещений и поворотов, вы «угнали» объект в какое-нибудь экзотическое положение и хотите его быстро вернуть в место рождения и к прежним размерам, можно выполнить операцию Modify->Reset Transformations. Это аналогично «вбиванию» в Channel Box нулей для атрибутов trans­ late и rotate и единиц для атрибутов scale. (В Option Box операции Reset Transformations есть соответствующие галочки для каждого из этих атрибутов.) Операция Modify->Freeze Transformations тоже «вбивает» нули и единицы в Channel Вох, но при этом не меняет положение объекта. Иначе говоря, Freeze Transformations определяет текущее положение (плюс повороты и размер), как новое место рождения объекта. В результате выполнения этой операции объект остается на месте, в Channel Box у него появляются одни нули и единицы а локальные оси смотрят вдоль мировых осей, то есть как будто объект только что был созданье этом месте, так что он будет возвращаться в это положение после Reset Transformations. Операция Freeze Transformations часто используется для разворота локальных осей в нужном направлении (в Option Box этой операции также есть соответствующие галочки для translate, rotate, scale).

Связи между атрибутами. Работа с Connection Editor.

Полное имя атрибута. Типы атрибутов. Совместимые атрибуты.

Красивые и настоящие имена атрибутов После того, как мы рассмотрели «родовую» связь между transform и shape, можно с облегчением вздохнуть и поговорить о «нормальных» связях, то есть о связях между атрибутами объектов.

Создайте несколько цилиндров, разбросайте их в пространстве или откройте файл trainStart.ma. Попробуем соединить вращения двух колес.

Для связывания между собой атрибутов объектов чаще всего используется Connection Еdi tor. Откройте Windows=>General Editors=>Connection Editor. Две панели открывшегося окна служат для отображения атрибутов объектов. В отличие от Attribute Editor, объекты надо загружать в Connection Editor вручную.

Выберите первое колесо (wheel_1) и нажмите кнопку Reload Left, затем выберите второе колесо |wheel_2) и нажмите кнопку Reload Right.

В обеих панелях Connection Editor появятся атрибуты объектов. Количество отображаемых лоумолчанию атрибутов может слегка подавлять неподготовленных исследователей...

Весьма разумно спрятать огромное количество служебных атрибутов, для этого в меню Connection Editor снимите галочки Left Display=>Show Non-Keyable и Right Display=>Show Non-KeyаЫе. Это приведет к тому, что в панелях останутся только анимируемые атрибуты, которые нас как раз и интересуют.

Раскройте с обеих сторон аттрибуты Rotate, нажав на плюс рядом с именем атрибута.

Выберите слева RotateX, а затем RotateX справа.

В момент выбора RotateX справа произошло связывание атрибута rotateX объекта wheel_ с атрибутом rotateX объекта wheel_1.

Отвязать атрибут (то есть «отсоединить» его, сделать независимым) можно, снова нажав на RotateX справа. Повторное нажатие как бы переключает состояние «связанности».

Проделайте операцию связывания для атрибутов rotateY и rotateZ обоих цилиндров. При выборе атрибутов слева в правой панели подсвечиваются атрибуты, связанные с ними.

Курсивом в Connection Editor выделяются атрибуты, имеющие связи с другими атрибутами.

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

Совет. Взрослые мальчики вместо Connection Editor могут использовать MEL команду connectAttr. Тогда не понадобится открывать окна, выбирать нужные объекты, загружать их в соответствующие части Connection Editor - достаточно выполнить всего одну команду и получить тот же результат! Нужно только знать точные имена объектов и атрибутов. Для случая описанных выше вращений колес команда будет выглядеть следующим образом:

connectAttr -f wheel_1.rotateX wheel_2.rotateX;

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

желтый цвет значений атрибутов в Channel Box. (Желтый обозначает прямую связь с атрибутами другого объекта.) Это ключевой момент для понимания сути происходящего: мы связали не два объекта, а атрибуты объектов. Можно сказать, что вращение второго колеса связано с вращением первого, но нет смысла говорить, что второй объект присоединен к первому, если не уточнять, каким способом и через какие атрибуты он связан с ним.

Не закрывайте Connection Editor, выберите оба колеса и откройте Hypergraph, в меню которого выполните Graph=>lnput And Output Connection.

Для того, чтобы быстро наехать на выбранные объекты, нажмите клавишу f. Отъехав немного, вы увидите оба колеса, связанные стрелками-связями.

Наведя курсор мыши на любую из этих стрелок, можно прочитать «расшифровку» этой связи.

Слева всегда обозначен «источник» (в данном случае wheel_1.rotateX), а справа - «принимающий»

атрибут (в данном случае wheel_2.rotateX).

Напомню, что wheel_2.rotateX - это полное имя атрибута, состоящее из имени объекта и имени атрибута, однозначно определяющее значение атрибута в сцене.

Связь можно выбрать, щелкнув по ней мышкой, а затем удалить, нажав клавишу Delete. Это равносильно разъединению атрибутов в Connection Editor. Выбирать много связей одновременно нельзя, поэтому придется щелкать и удалять каждую из них.

Совет. Двойной щелчок по связи вызывает Connection Editor с загруженными в него соответствующими объектами.

Вернемся в Connection Editor. Опытным путем можно установить, что атрибут Scale слева нельзя присоединить к атрибуту ScaleX или TranslateY справа. Дело в том, что эти атрибуты несовместимы. Оказывается, атрибуты объектов могут быть разных типов. В данном случае scaleX или translateY это простые числовые атрибуты (double), a scale - это «тройной» атрибут, то есть набор из трех чисел (double3). Атрибуты могут быть простыми числовыми, составными (compound, то есть содержащими наборы данных), строковыми (string, то есть содержащими текст), матрицами и пр. Количество типов атрибутов исчисляется десятками, и их можно найти в описании команды setAttr.

Как нетрудно убедиться, в Connection Editor можно соединить только совместимые между собой атрибуты. К типам атрибутов мы еще вернемся, а сейчас нас интересуют простые числовые атрибуты, или атрибуты, содержащие три числа.

Для взрослых. Можно всегда посмотреть тип атрибута с помощью команды SetAttr с флагом - type, например:

getAttr -type wheel_1.scaleX;

getAttr -type wheel_1.scale;

getAttr -type phong1.color;

getAttr -type phong1.colorR;

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

Отсоединение не поможет вернуть колесо на место, так как разъединится только связь между атрибутами, но последние значения атрибутов останутся неизменными. Для отмены неудачных экспериментов лучше воспользоваться Undo. Можете соединить между собой атрибуты Scale и убедиться в Hypergraph, что цвет связи в Hypergraph зависит от типа соединяемых атрибутов.

Примечание. Составные атрибуты (Compound attributes) - например, Rotate содержат в себе простые атрибуты RotateX, RotateY, RotateZ. Такая организация сделана для удобства соединения групп атрибутов между собой. То есть соединение атрибутов Rotate двух объектов между собой почти равносильно последовательному соединению пар атрибутов RotateX, RotateY, RotateZ этих же объектов. «Почти» означает, что соединение «тройных» атрибутов Rotate имеет более высокий приоритет, чем попарное соединение RotateX, RotateY и Ro Некоторая чехарда с маленькими и большими буквами в названиях атрибутов связана с т м е, что реальные имена атрибутов всегда начинаются с маленькой буквы (rotateY, visibility). Но в Соn nection Editor, Attribute Editor и даже в Channel Box имена атрибутов отображаются в «эстетичном»

стиле, то есть с большой буквы. Сильного вреда это не приносит, однако при использовании MEl команд, работающих с атрибутами, необходимо использовать реальные имена, так как применение -красивых» имен, запомненных при работе с интерфейсом, приводит к сообщениям об ошибке.

Настоятельный совет. Установите в Channel Box режим отображения реальны длинных имен атрибутов, чтобы глаз привыкал к настоящим именам, «как взрослых»: Channels=>Channel Names=>Long.

Чтобы быстро соединить вращение первого колеса со всеми остальными, загрузите в левую панель первое колесо, если оно еще не там.

Потом выберите все остальные колеса и нажмите Reload Right.

Далее, выбрав Rotate слева, прощелкайте все Rotate справа.

Покрутите первое колесо, остальные должны вращаться синхронно с ним.

В Hypergraph снова выполните Graph=>lnput And Output Connection. Теперь от первого колеса исходят несколько связей с остальными объектами. Интуитивно понятно, что от одного атрибута могут исходить несколько связей, но входящая в него связь может быть только одна.

Для взрослых. В некоторых случаях (например, при использовании Set Dhven Key), возникает ситуация, когда несколько атрибутов влияют на один атрибут. В зтих случаях автоматически создается нода blendTwoAttr (смеситель атрибутов), на вход которой подаются значения входящих атрибутов, а выход присоединяется к зависимому атрибуту. Тем не менее, входящая в атрибут связь всегда может Непрямые связи. Функция Set Driven Key.

Определение интеллектуальных зависимостей между атрибутами без программирования. Расширение сознания.

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

Создайте полигональную сферу.

Откройте Connection Editor и загрузите ее в левую панель.

Допустим, что вас мучает параноидаьная идея, состоящая в том, что размер сферы должен влиять на ее же цвет. Цвет сферы определяется атрибутами материала, который ей присвоен. В нашем случае это материал по умолчанию l a m b e r t l. Осталось загрузить его в правую часть Con­ nection Editor.

Проще всего это сделать через Attribute Editor, в котором нужно выбрать последнюю закладку, соответствующую материалу сферы, и нажать внизу кнопку Select. Так как в Attribute Editor отображаются закладки для всех объектов, связанных с выбранным объектом какими бы то ни было связями, то эта кнопка позволяет выбрать конкретный объект, а точнее - ноду (в данном случае материал), соответствующую данной закладке.

Нажмите Reload Right в Connection Editor, чтобы справа появились атрибуты материала.

Затем слева выберите Scale, а справа Color.

Готово! Теперь осталось лишь выбрать Scale Tool и неистово менять размер сферы, наблюдая наличие очевидной зависимости между размером и цветом объекта. Изменение размера вдоль каждой оси может дать интересную трехмерную интерпретацию цветового пространства. Но вся проблема: все это работает в диапазоне размеров от нуля до единицы, а при больших масштабах сфера пересвечивается и становится одинаково белой. Встает вопрос, как сделать связь между атрибутами не такой, мягко говоря, прямолинейной и, грубо выражаясь, не такой тупой?

Представьте, что сфера - это брюхо комара, которое должно при увеличении в размере одновременно краснеть, и даже, быть может, становиться более прозрачным. По-человечески сформулировать задание можно так: если сфера небольшая (например, scale=0.5, то есть «комар голоден»), то цвет ее должен быть темно-коричневый, а если сфера огромная (scale=3.0, то есть «комар сыт»), то цвет ярко-красный.

Чтобы создать такую интеллектуальную связь, быстро воспользуемся функцией Set Driven Key и посмотрим, как это все выглядит в Hypergraph.

В Connection Editor (или в Hypergraph) разорвите связь между Scale и Color.

В Attribute Editor сделайте цвет сферы темно-коричневым.

Нажав правую кнопку на атрибуте Color, выберите в выпавшем меню Set Driven Key.

Откроется окно Set Driven Key, которое похоже на вертикально расположенный Connection Editor. В нижней части, где должен находиться управляемый (driven) или зависимый объект, уже загружен материал lambert1 и даже выбран атрибут colorR.

Выберите сферу и нажмите кнопку Load Driver.

Когда наверху появятся атрибуты сферы, выберите scaleX - именно он и будет «рулить»

цветом. В отличие от Connection Editor, никого соединения еще не произошло.

Смысл функции Set Driven Key состоит в том, чтобы не только выбрать соединяемые атрибуты, но и задать их значения, а потом «Зафиксировать связь» в таком положении (то есть если pSphere1.scaleX=0.5, то lambert1.colorR=0.1), затем изменить значения этих атрибутов и снова «зафиксировать связь» в новом положении (если pSphere1.scaleX=3.0, то lambert1.colorR=0.95).

После этого MAYA будет сама пересчитывать значения scale в значения для color в соответствии с заданной зависимостью.

Подробнее мы поговорим о Set Driven Key в главе про анимацию.

А сейчас установите scaleX сферы равным 0.5, убедитесь, что в верхней части окна Set Driven Key выбран scaleX, а в нижней colorR, и нажмите кнопку Key (зафиксировать).

Теперь сделайте scaleX равным 3.0, а цвет материала ярко-красным (именно в такой последовательности), а потом снова нажмите кнопку Key.

Все! Можно снова выбрать Scale Tool, чтобы изменить размер сферы. Теперь цвет сферы меняется только при изменении scaleX в диапазоне от 0.5 до 3.

Поскольку цвет пока что зависит только от scaleX, пытливые умы могут сами проделать установку Set Driven Key для scaleY и scaleZ, причем выбирая в нижней панели не только colorR, но и colorG, и colorB. А неутомимые исследователи могут повторить эту процедуру еще и для прозрачности материала, то есть для атрибута transparency.

Дальше. Выберите сферу и тут же идите в Hypergraph.

Выполните Input And Output Connection.

Проанализируйте следующую картину: между сферой и материалом теперь находится некая нода (lambert1_colorR), которая «корректирует» зависимость между pSphere1.scaleX и lam­ bert1.colorR.

pSphere1.scaleX сначала попадает на вход (input) этой ноды, которая проводит некоторые вычисления с этим атрибутом, а результат, то есть выход (Output) пойдет уже на lambert1.colorR.

Помните, что «майскую» сцену можно представить себе как поток данных, бегущий по стрелкам-связям в Hypergraph. При изменении атрибутов где-нибудь в середине потока (например, pSphere1.scaleX ) происходит автоматическое обновление всех данных, находящихся •ниже по течению», как указано стрелками. Формально говоря, обновляется нижняя часть дерева зависимостей (downstream graph).

Если выбрать ноду lambert1_colorR прямо в Hypergraph, то, естественно, ее можно рассмотреть в Attribute Editor. Это просто анимационная кривая, которая также является объектом в MAYA, и она ничем не лучше и не хуже остальных объектов. У нее свой набор атрибутов, определяющих ее свойства и свое представление в Attribute Editor. Любопытствующие умы могут рассмотреть ее подробнее в Window->Animation Editors->Graph Editor...

Функция Set Driven Key является мощнейшим средством для задания нужных связей между атрибутами объектов, так как позволяет задавать практически любые зависимости, не прибегая к программированию формул или сложным вычислениям. Более того, эти связи между атрибутами имеют прекрасное визуальное представление в Graph Editor и могут быть интерактивно, отредактированы в любой момент.

Результаты проделанных выше действий сохранены в файле sdk.ma.

Анимация. Связь атрибутов с временем.

Анимационные кривые как объекты сцены.

Анимация и деформация времени Продолжим работу с деревом зависимостей. Посмотрим, что происходит при анимации.

Выберите сферу, встаньте в первый кадр и нажмите shift-r - это поставит ключ на атрибуты scale. Встаньте в двадцатый кадр, измените размер сферы и снова нажмите shift-r.

Встаньте в сороковой кадр, еще раз измените размер сферы и снова нажмите shift-r.

Проиграйте анимацию и обратите внимание, что меняется не только размер объекта, но и цвет материала, хотя от времени зависит только атрибут scale, на который мы ставили ключи.

Вернемся в Hypergraph. Как обычно, нажимаем кнопку Input And Output Connection. Видим, что в наше дерево добавились еще три ноды, которые присоединяются к атрибутам scale сферы.

Это анимационные кривые, задающие зависимость атрибутов scale от времени.

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

Если вы пока еще ориентируетесь в этих дебрях (если же нет, просто откройте файл sdkFirtal.ma), можете проделать следующий эксперимент.

Нажмите shift, а затем перетащите средней кнопкой анимационную кривую pSphere1_scaleY и бросьте ее на ноду pSphere1.

Откроется Connection Editor с загруженными в нужном порядке нодами. Если у pSphere1_ scaleY не видно никаких атрибутов, включите галочку Left Display=>Show Non-КеуаЫе.

Соедините атрибут Output слева (он последний) и атрибут translateY справа.

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

Кроме того, одна анимационная кривая управляет сразу двумя атрибутами, чего невозможно было бы добиться, расставляя ключи традиционным способом. Хотя, как вы понимаете, того же результата (то есть синхронизации scaleY и translateY) можно было бы добиться, соединив scaleY и translater в Connection Editor.

Для взрослых. Пытливые умы наверняка тут же возопят: «А почему мы не видим в Hypergraph связи между анимационными кривыми и временем?». Действительно, время в MAYA тоже является объектом. Его зовут time1, и он имеет атрибут outTime, содержащий значение глобального времени в кадрах. Вы можете разыскать и выбрать его в Outliner, если снять галочку Display=>DAG Objects Only. Можете рассмотреть его в Attribute Editor. Но в Hypersraph его связь с анимационными кривыми не показана, хотя в неявном виде она существует. Точнее говоря, если к атрибуту input анимационной кривой ничего не присоединено, на него в этом случае подается значение timel.outTime. Кстати, вы всегда можете увидеть атрибут input в Channel Box, просто сделав его keyable через Channel Control. Более того, можете ставить на него ключи, тем самым «деформируя» глобальное время добиваясь эффекта искажения времени ( tiте-warping).

Таким образом, можно обозначить концепцию, к которой мы еще не раз будем возвращаться чтобы эффективно работать с объектами и связями в MAYA, необходимо знать тип и назначенин атрибутов этих объектов.

Вот этим мы как раз сейчас и займемся.

Типы атрибутов и их назначение.

Анимируемость и совместимость атрибутов.

Интеллектуальные атрибуты. Мешки чисел До сих пор мы экспериментировали с простыми числовыми атрибутами, которые определют довольно очевидные и вполне «осязаемые» свойства объектов, такие как цвет, размер, положение Есть подозрение, что у любого объекта (точнее, у составляющих его нод) существует еще много всяких атрибутов, определяющих и другие, не столь наглядные свойства. Например, будет ли объект появляться в отражениях или отбрасывать тень - это тоже определяется соответствующими атрибутами. Когда вы прячете объект (Display=>Hide=>Hide Selection), вы всего лишь меняете значение атрибута visibility, который определяет видимость объекта в сцене.

Числовые атрибуты можно условно разделить на некоторые типы в зависимости от типа данных, которыеони содержат: целые числа (integer), числа с плавающей точкой (float) и логические значения (boot) типа on/off (которые на самом деле являются числами 0/1). Об этом необходимо помнить, так как вы можете без труда соединить в Connection Editor атрибут с плавающей точки и целый атрибут, но потеря дробной части при этом будет совершенно предсказуема.

Как правило, числовые атрибуты позволяют себя анимировать то есть менять значение в зависимости от времени. Если вы не видите атрибута в Channel Box, это еще не означает, что его не существует: просто он может быть неанимируемым (non-keyable). Анимируемость (keyable) - это не тип, а скорее статус числового атрибута, который всегда может быть изменен через Windows=>General Editors=>Channel Control.

Рассмотрим теперь некоторые атрибуты, которые не являются обычными числами. Назовем их пока просто данными. (Ну как, заинтригованы?) Создайте полигональный куб и полигональную сферу.

Выберите оба объекта, откройте Hypergraph и нажмите Input And Output Connections.

Сейчас нас интересуют shape- ноды обоих объектов, определяющие их форму.

pCubeShape1 имеет связь с нодой poLyCube1, которую можно также увидеть в закладках Attribute Edi­ tor (помня о том, что в Attribute Editor показываются все ноды, хоть как-то связанные с выбранным объектом). Нода polyCube1, как написано в документации, просто создает полигональный куб в соответствии со своими атрибутами width, height, depth.

Вопрос что значит «создает»? Ведь куб создается операцией Create->Polygon Primitives->Cube или командой polyCube в Script Editor. Дело в том, что нода polyCube1 вычисляет все необходимые данные для построения полигонального куба (координаты вершин, грани и нормали). Можно сказать, что она «вычисляет» куб, а результат этого вычисления (то есть данные, определяющие куб) складывает в один «большой» атрибут, который называется output, и хранит в себе все эти данные в виде, условно говоря, «мешка чисел». При соединении этого атрибута с атрибутом inMesh ноды pCubeShape1, этот «мешок чисел» моментально «приезжает» в ноду pCubeShape1, которая, собственно, и визуализируется на экране. Разумно предположить, что тип атрибута inMesh при этом совпадает с типом атрибута output ноды polyCube1.

Чтобы проверить эти рассуждения, удалите связь между pCubeShape1 и polyCube1 или вообще удалите polyCube1 (только не забудьте потом вернуть все обратно при помощи Undo). Куб не исчезнет, но данные, содержащиеся в атрибуте inMesh и определяющие форму куба, теперь не зависят от ноды polyCube1 и просто имеют какие-то значения.

Но ведь для сферы ситуация аналогична, и «вычислитель» сферы polySphere1 тоже отдает результат своих вычислений в атрибут inMesh ноды pSphereShape1.

Итак, экспериментируем. Скрестим куб и сферу. Нажимаем shift, тащим средней кнопкой мыши ноду polySphere1 и бросаем ее на pCubeShape1.

Открывается Connection Editor с уже загруженными нодами. И слева и справа (в Left Dis play и в Right Display) должна быть галочка в Show Non-Keyable. Слева ищем и выбираем Output, а справа - inMesh.

На экране получаем две одинаковые сферы, а в Hypergraph следующую картину:

Если нас что и смущает, так только названия объектов. Но можно переименовать pCubeShape1 и pSphereShape1 в, например, meshl и mesh2, и тогда все встанет на свои места.

Вычислитель сферы polySphere1 отдает вычисленные данные через атрибут inMesh в ноды mesh и mesh2, которые отвечают за построение и визуализацию полигональных сеток.

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

Выше уже прозвучало неявное определение типов атрибутов. Остается лишь подытожить и сформулировать, что атрибуты бывают разных типов, причем не только числовых, но и более сложных, что непостижимо для обычного, нерасширенного сознания. Чтобы два атрибута можно былосоединить (например в Connection Editor), они должны быть совместимы, то есть принадлежать к одному типу. Именно поэтому при выделении в Connection Editor какого-нибудь атрибута слева, справа становятся доступными лишь совместимые с ним атрибуты, готовые к соединению.

Динамические атрибуты. Статические атрибуты.

Добавление и удаление собственных атрибутов.

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

Все атрибуты, которые вы видите, создав очередной объект, в Attribute Editor или в Channel Box (ну, хорошо: почти все) - это статические атрибуты, которые нельзя ни удалить, не переименовать. Самое удивительное, что к любому объекту (точнее, к любой ноде) можно добавлять свои атрибуты! Они-то и называются динамическими, так как их потом можно удалить или переименовать.

«А зачем это нужно?» - спросят еще недостаточно искушенные умы. Зачем добавлять атрибуты, когда и в существующих разобраться невозможно? Действительно: ведь добавив свой атрибут к объекту, мы просто получим новую цифру в клеточке в Channel Box или числовое поле в разделе Extra Attributes в Attribute Editor.

Это можно сделать, выбрав объект, а затем выполнив Modify=>Add Attribute.

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

Будьте внимательны: атрибут добавляется к выбранному объекту, а не к ноде, закладка которой активна в Attribute Editor. Имя объекта, к которому добавляется атрибут, всегда высвечивается в заголовке окна Add Attribute.

Нажав OK (или Add и Close), вы добавите новый атрибут, который можно будет найти в Attribute Editor в последнем разделе Extra Attributes.

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

Примечание. Чтобы сэкономить время, можно добавлять атрибуты к нодам непосредственно в Attribute Editor. Для этого нужно воспользоваться меню Attributes->Add Attribute... При этом все равно придется помнить, какая нода и какой объект выбраны в данный момент.

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

Зачем навешивать на объект дополнительные данные?

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

Например, вы можете добавить к вашему скелету новый атрибут closeFingers. А затем, с помощью функции Set Driven Key, задать связь между ним и атрибутами rotate всех костей, определяющих пальцы персонажа. Причем задать связь так, что для closeFingers=0 все пальцы согнуты в кулак, а при closeFingers=1 все пальцы выпрямлены. После этого можно анимировать только атрибут closeFingers, чтобы сжимать и разжимать кулак у персонажа. Об этом я еще поговорю подробнее в главе про анимацию персонажей, а сейчас лишь замечу, что добавление собственных атрибутов позволяет привнести в сцену новый уровень абстракции и на приемлемом, •человеческом» языке задать новые понятия для управления персонажами и вообще объектами.

Кроме того, в добавленных атрибутах вы можете хранить свои данные, необходимые вам для последующей работы (например, амплитуду колебаний объекта, анимированного с помощью expression). Вы можете ставить ключи на свои атрибуты, использовать их в expressions, присоединять их к другим атрибутам через Connection Editor и т.д.

Динамические атрибуты проще всего удалить или отредактировать через меню Attribures, находящееся, как нетрудно догадаться, в Attribute Editor.

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

Кроме того, существуют секретные динамические атрибуты. Добавив из вы можете изменить свойства объекта (ноды), к которой эти атрибуты добавлены. Об этом читайте в конце главы.

Изменение порядка динамических атрибутов в ноде. Шаманство Иногда в процессе подготовки персонажа или объекта к анимации приходится добавлять новые динамические (пользовательские) атрибуты. Они, конечно же, встанут в конце списка уже созданных атрибутов. Но такой порядок не всегда удобен.

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

К сожалению, в Мауа нет утилиты для такой работы. Может, написать какой-нибудь скрипт использующий недокументированные команды? Нет, все проще. Можно обойтись и без скрипта.

Было замечено, что если выделить несколько динамических атрибутов в Channel Box и вызвать там же меню Delete Attributes, а затем сделать Undo, то MAYA восстановит эти атрибуты, но только в обратном порядке и в конце списка. Отсюда можно сделать вывод, что любой динамическим атрибут можно перенести вниз, удалив его и восстановив командой Undo. Или вверх, если выбрать все атрибуты до него и повторить операцию удаления и восстановления два раза (второй раз, чтобы восстановить прежний порядок в удаленных атрибутах). Попробуйте сами.

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

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

В Attribute Editor можно заметить, что для каждой такой «типа, сферы» присутствует закладка polySphere1, описывающая входящие атрибуты для вычисления сферы.

Установите subdivisionsAxis=4 и subdivisionsHeight=4, чтобы окончательно превратить сферу в «типа, сферу».

Теперь зададимся таким вопросом: если у полигональной сетки (определяемой нодой pSphereShape1) есть входной атрибут inMesh, то, может быть, у нее есть и выходной атрибут типа outMesh, в котором содержится описание этой сетки. Действительно, изучение Connection Edi­ tor выявляет наличие такого атрибута. Понятно, что содержимое inMesh и outMesh не обязано совпадать: ведь мы могли сетку «помять» или растянуть. Поэтому на выходе будут уже «помятые»

данные, а на входе - оригинальные. (Информация о «помятости» хранится, естественно, тоже в секретных атрибутах ноды pSphereShape1, определяющих координаты вершин.) А что будет, если соединить inMesh одного объекта и outMesh другого? Вперед! В Hypergraph! Нажимаем shift, тащим средней кнопкой мыши ноду pSphereShape1 и бросаем ее на pCubeShape1. В Connection Editor слева выбираем outMesh, справа - inMesh.

Если теперь выбрать у pSphere1 несколько вершин и подвинуть их, то можно увидеть, что аналогичные вершины у pCube1 тоже переместились. Внешне похоже на инстансирование, однако это не инстансирование, потому что ноды shape у наших объектов разные. Если же выбрать и переместить вершины у pCube1, это не произведет никакого впечатления на pSphere1.

Действительно, ведь связь между объектами односторонняя, поэтому перемещения вершин pCubel просто «наслаиваются» на перемещения, унаследованные от pSphere1.

Исследуйте связи в Hypergraph. Теперь это простое дерево, где данные о форме pSphere­ Shape1 передаются через связь outMesh->inMesh в pCubeShape1.

Изменение атрибутов subdivisionsAxis и subdivisionsHight ноды роlуSphere1 по-прежнему влияет на форму обоих объектов: ведь поток данных проходит через них последовательно. Правда, меняется нумерация вершин, поэтому если вы сдвигали точки слишком сильно, то увидите их смещения в новых местах, соответствующих их старым номерам.

Ну, а напоследок выберите рСuЬе1 и примените к нему какую-нибудь операцию полигонального моделирования, например Роlygons=>Smooth. Затем выберите pSphere1 и снова «подергайте» эту фигуру за вершины (смотрите один из возможных результатов на рисунке внизу).

Снова исследуйте Hypergraph, в особенности имена атрибутов, задействованных в связях Ясно, что MAYA для выполнения операции smooth вставила в существующее дерево еще пару нод, отвечающих за эту операцию. Очевидно, что нода polySmoothFace1 просто «ловит» данные, поступающие в атрибут inputPolymesh, производит над ними вычисления, соответствующие операции smooth и выдает результат в атрибут output.

Для взрослых: нода polyTweak1 хранит информацию о том, как мы таскали вершины. Можете в Attribute Editor изменить ее атрибут NodeState на HasNoEffect Теперь, когда сознание у читателя расширено, по-видимому, в достаточной степени, можно приступать к изучению Construction History. Но сначала я хотел бы повторить вывод номер один, только уже в более общем виде.

Снова вывод номер один Еще раз напомню концепцию, к которой мы не раз будем возвращаться: чтобы эффективно работать с объектами и связями в MAYA, необходимо знать тип и назначение атрибутов этих объектов.

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

На практике тип любого атрибута можно, конечно, узнать МЕL командой getAttr -type А тип любой ноды MEL-командой nodeType. Однако, чтобы получить более или менее внятное описание предназначения этого атрибута, понадобится поработать с документацией.

Работа с документацией. Исследование незнакомых объектов.

Источник безграничных познаний Допустим, вы однажды открыли сцену и видите: там незнакомый объект, с которым вам еще не приходилось работать. Или вы сами в новой версии MAYA вдруг ухитрились создать доселе невиданный объект, который совершает нечто неведомое. Что надо делать? Правильно надо изучить его атрибуты. Точнее, выяснить, за какие свойства нового объекта они отвечают и как этот незнакомый объект реагирует на изменение своих атрибутов. Так как все объекты в MAYA состоят из атрибутов и, соответственно, имеют шаблон в Attribute Editor, то банальный «метод тыка» позволяет довольно быстро начать изучение свойств новых объектов.

Например, откройте файл distance.ma.

Попробуйте перемещать объекты. Через минуту становится понятно, что размер сферы зависит от расстояния между объектами. Но каким образом это сделано?

При выбранной сфере в Attribute Editor обнаруживается некая нода howFar, которая имеет всего два атрибута: Point1 и Point2.

В Hypergraph можно распутать связи между сферой и кубом и выяснить, что позиции (атрибуты translate) сферы и куба соединяются с атрибутами Point1 и Point2 ноды howFar, а некий атрибут distance этой ноды соединяется с атрибутами scale сферы. Хотя уже примерно понятно, как работает нода howFar, хотелось бы получить более детальную информацию о тех атрибутах, которые не появляются Attribute Editor.

Примечание. Взрослые мальчики никогда не читают разделов документации, содержащих описание пунктов меню и процесса редактирования объектов. Им нужна лишь описание интересующей их ноды и ее атрибутов. Для этого существует пункт меню Help=>Node And Attribute Reference..., который просто открывает алфавитный указатель на все типы нод, встречающихся в MAYA.

Осталось узнать тип интересующей нас ноды howFar. Проще всего узнать тип ноды в At­ tribute Editor, где в соответствующей ноде закладке слева от имени ноды обозначен ее тип.

В нашем случает тип ноды howFar обозначен как distanceBetween. Поэтому открываем Help=> Node and Attributes Reference... и находим там описание типа distanceBetween. Документация подтверждает нашу догадку: ноды этого типа просто вычисляют длину отрезка между точками, задаваемыми атрибутами Input1 и Input2. А вот описание атрибутов ноды приводит нас к обнаружению еще двух атрибутов, позволяющих перемножать входящие атрибуты на матрицу, то есть вычислять расстояние в другом пространстве.

Таким образом, если вам встречается незнакомая нода или новый атрибут, тип и назначение которых вы хотите узнать, ваш путь лежит в Help=>Node and Attributes Reference. Именно так, с некоторого момента, протекает дальнейшее изучение MAYA.

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

Дальше. Выберите куб или сферу.

Убедитесь, что первая закладка в Attribute Editor всегда имеет тип transform. Вторая закладка, в случае полигональных объектов, имеет тип mesh.

Посмотрите также, что в документации в описании ноды типа mesh есть комментарии к атрибутам inMesh и outMesh, с которыми мы уже экспериментировали.

Обратите внимание на то, что в документации также всегда обозначены типы атрибутов.

Это поможет вам в будущем определять совместимость атрибутов между собой для эффективного соединения их в Connection Editor.

Совет. Указанный раздел документации является основным источником знании о «внутренностях» MAYA и ее реальном устройстве. Чего стоит хотя бы описание ноды transform! Поэтому, по мере накопления опыта работы с MAYA, заглядывайте История (History) Теперь, наконец, можно попытаться разобраться, что такое History. Я попробую дать несколько определений, а вы подберете наиболее понятное вам, соответствующее вашему стилю Интуитивное определение: History - это совокупность объектов и связей, влияющих на форму данного объекта. То есть если форма выбранного объекта зависит от атрибутов других объектов или нод, тогда этот объект имеет History.

Более формальное определение: если нода shape данного объекта имеет входящие связи, влияющие на форму объекта, то эти связи вместе с нодами, участвующими в них, называются His­ tory данного объекта.

Ну и определение «на пальцах»: History то, как мы влияли на форму объекта. Влияли мы при помощи различных операций, а MAYA имеет свойство после многих операций создавать ноды, им соответствующие, и так далее... Круг определений замыкается.

Понятие History иллюстрируется еще и следующим наблюдением. Как правило, перед применением той или иной операции в MAYA можно открыть в меню ее Option Box и задать там параметры применения этой операции (например, куда будет смотреть макушка полигонального конуса или же сколько будет точек у Lattice). После применения операции не надо все делать заново, если захочется изменить некоторые из этих параметров: MAYA обычно создает необходимые ноды, соответствующие этим операциям, а параметры, задаваемые в Option Box, становятся атрибутами объектов, то есть они доступны для редактирования через Attribute Editor. Другими словами, MAYA запоминает наши действия в соответствующие ноды по мере совершения действий, так сказать исторически, то есть они и становятся историей объекта (History).

Пользователи иногда путают термины History и Construction History. Дело усугубляется и тем, что Construction History является частью History, связанной с созданием и изменением формы объекта посредством только операций моделирования. Остальная часть History, не имеющая специального названия, связана с применением деформеров и скининга, также изменяющих форму объектов.

Разберем эти две части History отдельно.

Примечание. Связь с числовыми атрибутами (например visibility), принадлежащими ноде shape, не может рассматриваться как History, так как она не влияет на форму объекта. Ну и, естественно, вышеиспробованные связи между атрибутами transform-нод также не являются отношениями типа History. (Можете проверить, что операция Delete History никак не повлияет на эти связи.) Construction History. Стэк моделирования.

Протоколирование действий и операций.

Конструктивные входы и выходы Понятие Construction History применимо только к геометрическим объектам, то есть к кривым, NURBS-поверхностям и полигональным сеткам (операции работы с subdivision surfaces не имеют Construction History или наследуют последнюю у полигонов).

Прежде всего мы сталкиваемся с понятием Construction History при создании геометрических примитивов. Какой бы объект вы ни создали при помощи меню NURBS Primitives или Polygon Primi­ tives, он будет содержать ноду (имя которой начинается на make для NURBS или на poly для полигонов), которая позволяет изменять внешний вид и свойства поверхностей и кривых уже после их создания. Эта нода и есть простейший пример Construction History.

Проделайте небольшое упражнение (кому неохота, можете открыть файл nurbsHistory.ma).

В новой сцене создайте NURBS-тор. Проделав некоторое количество операций моделирования, посмотрите, как видоизменилась Construction History объектов.

В Channel Box выделите makeNurbsTorusI и задайте End Sweep=180, Minor Sweep=180.

Далее, RMB=>lsoparms. Выберите крайнюю верхнюю и нижнюю изопармы.

Создайте лофт: Surface=>Loft.

Разверните камеру и выберите две торцевые изопармы у лофта и тора.

Снова выполните Surfaces=>Loft.

Повторите для другого торца.

Выберите теперь тор и обратите внимание, какое столпотворение возникло в Channel Box:

Там отображаются названия нод, которые MAYA создала в ходе наших бесхитростных действий. Выбирая разные поверхности, можно даже понять логику распределения этих нод по разделам INPUTS и OUTPUTS в Channel Box. Окончательно прояснить эту логику поможет Hypergraph и кнопка Input And Output Connections. Для одной из торцевых поверхностей дерево зависимостей выглядит примерно так:

Выберите тор, поиграйте с атрибутами makeNurbsTorus1. Очевидно, что MAYA мгновенно перестраивает всю модель в соответствии с изменениями атрибутов тора, как будто бы заново повторяя все проведенные нами операции. В этом и состоит смысл и назначение Construction His­ tory.

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

Можно также сказать, что History для данного объекта - это верхняя часть дерева зависимостей (upstream graph), которая «входит» в объект. (Если в Hypergraph вы используете Options=>Orientation=>Horizontal, это будет, естественно, левая часть дерева.) Удаление History. Отшибание памяти. Разрыв с прошлым Соответственно, MAYA будет помнить и перестраивать всю нашу модель, пока будут сохраняться связи между соответствующими нодами. Понятно также, что разрыв связей не приведет к исчезновению объектов, а лишь нарушит зависимость одних объектов от других. Более того, если в Hypergraph удалить все ноды типа loft и curveFromSurfacelso, поверхности никуда не денутся, они просто не будут больше зависеть друг от друга.

Для удаления зависимостей и всех промежуточных объектов существует специальная операция удаления истории: Delete History.

Если выбрать объект и выполнить Edit=>Delete by Type=>Delete History, для выбранного объекта будет удалена вся входящая (верхняя) часть дерева зависимостей. Очень важно помнить, что в процессе такого удаления истории удаляются лишь входящие связи и ноды, однако влияние самого объекта на другие объекты (если такое существует) останется прежним.

Возникает вопрос: когда нужно удалять историю?

Ответ первый: сохраняйте историю только до тех пор, пока она вам нужна. Если вы используете Construction History для моделирования, редактируя кривую, через которую проходит revolve, или подбирая радиус скругления у операции round, удалять историю надо после того, как вы окончательно завершите работу над формой поверхности, то есть будете уверены, что такое редактирование вам больше не понадобится.

Ответ второй: сохраняйте историю, если вы собираетесь использовать ее в анимации, Например, вы смоделировали занавеску, как лофт, проходящий через несколько кривых, и собираетесь анимировать кривые при помощи динамики волос. Зависимость формы поверхности от образующих ее кривых будет активно использоваться, поэтому сохранение истории в этом случае - вполне адекватное действие Однако пытливые умы нетерпеливо спросят: а зачем удалять историю?

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

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

Во-вторых, Construction History часто вызывает такое явление как «двойные перемещения».

Double Transformation. Двойные перемещения.

Законопослушная MAYA Если вы успели окончательно разорвать все связи и удалили историю на экспериментальном полуторе, откройте заново файл nurbsHistory.ma.

Выберите все поверхности и попробуйте подвигать их в любом направлении. Все разъезжается в разные стороны. Затем выберите только тор и снова перемещайте его произвольным образом. Теперь все в порядке.

Снова выберите все поверхности и подумайте, что происходит в процессе перемещения объектов, имеющих историю. С одной стороны, лофт «помнит» о том, что он был построен через две изопармы тора, и поэтому обязан перемещаться вместе с тором. С другой стороны, лофт ведь тоже выбран, а мы еще тянем его с помощью манипулятора Move Tool. Дабы соблюсти закон, лофт передвигается еще и в соответствии с перемещениями манипулятора, то есть получает двойное перемещение. Аналогичный эффект будет происходить и при использовании Rotate и Scale Tool, поэтому он получил название Double Transformation. Причем это никакая не ошибка и не «глюк»

в данном случае МАУА делает ровно то, что от нее просят, корректно учитывая все связи между объектами.

Чтобы избежать такого эффекта, нужно всего лишь удалить историю, чтобы объекты не наследовали дополнительные трансформации.

Если же вы дорожите историей, но хотели бы без проблем перемещать объекты как одно Целое, сгруппируйте их (Edit=>Group) и перемещайте группу. Так как расположение объектов внутри группы не меняется, то и пересчета зависимостей Construction History не происходит.

Примечание. Иногда можно с самого начала отказаться от использования Construc­ tion History. Для этого на Status Line существует специальная кнопка, Construc­ tion History On/Off, которая позволяет вообще не запоминать последовательные Изысканный Duplicate. Input Graph. Input Connections.

Копирование старых связей.

Дублирование входящего дерева зависимостей При дублировании объекта его History, по умолчанию, не копируется, и у созданной копии объекта нет вообще никакой Construction History.

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

Создайте полигональный куб.

Выполните Polygons=>Smooth.

Снова выберите объект и выполните Edit Polygons=>Extrude Vertex.

Опять выберите объект, далее проделайте Polygons=>Average Vertex.

(Опять-таки, для ленивых имеется файл starObjectHistory.ma.) Предположим, мы хотим получить копию нашего объекта, но в дальнейшем собираемся менять у нее, например, атрибут Subdivision Level в Attribute Editor для ноды polySmoothFace.

Если просто выполнить Edit=>Duplicate с параметрами по умолчанию, новый объект, как только что говорилось, вообще не будет иметь истории.

Однако если в Option Box операции Duplicate включить галочку Duplicate Input Graph (памятливые умы не могут не помнить, что History - это и есть «входящее» дерево) и если скопировать объект, новая копия будет обладать собственной Construction History и иметь аналогичное дерево в Hypergraph.

Теперь можно индивидуально изменять атрибуты Construction History для каждого объекта.

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

Выберите объект и в Option Box операции Duplicate включите галочку Duplicate Input Con­ nections.

После копирования новый объект уже не будет иметь собственную независимую Construc­ tion History, а будет зависеть от истории оригинального объекта.

Теперь в Attribute Editor или Channel Box легко заметить, что у выбранных атрибутов одинаковая история. А изменение Subdivision Level в Attribute Editor одинаково изменяет все скопированные объекты. Полезно также посмотреть на дерево зависимостей в Нуреrgraph, откуда следует, что скопировалась только связь объекта с деревом истории моделирования.

Я хотел бы сразу отметить, что принципы дублирования Input Graph или Input Connections распространяются не только на объекты, имеющие History, но и на все объекты, просто имеющие входящие связи. Так, например, если объект имеет expression, заставляющий его двигаться определенным образом, то при дублировании по умолчанию этот expression просто «отвалится» от объекта; при дублировании Input Graph будет создан новый expression для копии объекта, а при копировании Input Connections один старый expression будет управлять сразу двумя объектами.

(Хотя это может не соответствовать текстовому содержанию самого expression. ) Для взрослых. Это можно легко проверить. Оставьте в сцене один объект, выберите его, в Attribute Editor впишите - в ячейку для translateY - следующий и нажмите Enter. Expression готов. Теперь в Duplicate Option Box включите галочку Duplicate Input Connections и скопируйте объект. Оттащите его куда-нибудь неподалеку и посмотрите в Expression Editor, что хотя формула написана для первого объекта, второй объект прекрасно движется в соответствии с нею.

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

Стэк деформаций и история моделирования Иногда некоторые, более хорошо подкованные индивидуумы, случайно знакомые с понятием «стэк деформаций», начинают воспринимать Construction History тоже как своеобразный стэк моделирования. В принципе это так и есть, за исключением того, что в отличие от деформаций, порядок операций моделирования не может быть произвольно изменен. Посудите сами: если провести лофт через три кривые, а потом пересечь его со сферой, получив замкнутую кривую, го какие операции и в каком порядке здесь можно переставить?! Да, для некоторых операций полигонального моделирования, последовательно передающих данные типа inMesh, outMesh, можно ставить задачу изменения порядка следования нод в дереве зависимостей. Такая задача легко решается (либо при помощи небольшого скрипта, либо ручной переустановкой связей в Нуpergraph), но вряд ли результат перестановки операций, в общем случае, будет предсказуем.

Но давайте разберем этот самый стэк деформаций.

Порядок деформаций. Список операций Применение деформеров также ведет к появлению History у геометрических объектов, так как деформеры воздействуют непосредственно на форму объекта, и, как следствие, на ноду shape.

Займемся «вивисекцией». Если ваш «ежик» еще «жив» (помните? была выше така»

«колючая» фигура), попробуем «поиздеваться» над ним. Если нет, откройте файл starObjectHistory.ma или создайте простой куб.

Выберите объект, навалите на него деформер squash: Deformers=>Create Non Linear=>Squash.

В Channel Box установите factor=3.

Затем снова выберите объект и примените к нему деформер bend: Deformers=>Create Non Linear=>Bend.

В Channel Box установите curvature=2.

Таким образом, мы сначала растянули объект, а затем согнули его. Есть мнение, что если бы сначала объект был согнут, а потом растянут, результат был бы иной. Как поменять порядок деформаций?

Конечно, можно открыть Hypergraph и, проявив паранормальные чудеса смекалки и виртуозное владение мышью, быстро перебросить нужные связи в необходимом порядке. А как быть обычным, «нормальным» людям?

Надо выбрать объект и добраться до плохо описанного в документации окна, в котором есть список всех входящих операций (inputs).

Это можно сделать, поставив курсор над объектом и нажав правую кнопку мыши: в выпавшем меню надо выбрать lnputs=>AU Inputs...

Откроется окно List of input operations for pCube1, в котором представлена вся History объекта в виде списка операций. (Замечу, что Construction History представлена здесь как часть общей History, включающая в себя все операции над формой объекта.) В отличие от Hypergraph, здесь историю следует читать снизу вверх.

Теперь схватите средней кнопкой мыши первый сверху пункт в этом списке - Non Linear(squash1), перетащите его и бросьте на второй пункт: Non Linear(bend1 ).

Порядок следования нод в истории поменялся, а значит поменялся и порядок деформаций -это прекрасно видно на экране.

При перетаскивании, порядок следования операций изменяется так: элемент списка вставляется под тот элемент, на который он был «сброшен». (То есть перед ним, если смотреть снизу вверх, с точки зрения History.) Здесь же вы можете заблокировать действие той или иной ноды, изменяя ее атрибут nodeState.

Можете убедиться, что нельзя поменять порядок нод, относящихся к Construction History, то есть к моделированию (об этом уже говорилось раньше).

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

Загадочный Tweak Нода tweak, автоматически появляющаяся при создании деформеров, хранит в себе информацию о ручном редактировании поверхности путем прямого перетаскивания за вершины.

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

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

В Attribute Editor для каждой ноды также существуют две похожие кнопки, позволяющие не только показывать входящие и исходящие связи (через правую кнопку мыши), но и осуществлять в Attribute Editor навигацию вверх и вниз по дереву зависимостей.

Эти кнопки исключительно удобны при работе с деревом материалов и текстур и позволяют быстро перемещаться по связям.

DAG или не DAG? Терминологические дебри Иногда в интерфейсе и тем более в документации мелькнет аббревиатура DAG. Бывает, встречается сокращение DG. Начинающие диггеры, занявшиеся MAYA, порой думают, что это опечатка. Хотя знание терминологии в этом случае имеет скорее теоретический, чем практический характер, постараюсь прояснить значение этих терминов, а также уместность их употребления.

(Кроме того, вы всегда сможете сделать жутко умный вид и со знанием дела ввернуть в дискуссию пару фривольных сентенций, типа «Ну, я-то всегда контролирую свой DAG» или «Ох, еле-еле распутал чужой DG». Попробуйте. Работает...) Термин DAG (Directed Acyclic Graph) пришел из теории графов и может быть, в принципе, переведен как «направленный непериодический граф». Однако пугаться таких названий не стоит, поскольку DAG -просто «высоколобый» термин для представления иерархии «майской» сцены.

Совокупность отношений parent-child для всех объектов в сцене - это и есть DAG. Еще проще можно объяснить понятие DAG визуально: представление сцены в Hypergraph в режиме Scene Hi­ erarchy - тоже DAG. Запомните навсегда: сам DAG - это не объекты, а представление отношений между объектами!

Слово «направленный» (directed) в данном случае означает, что отношение parent-child имеет направление сверху вниз и однозначно определено. «Непериодический» (acyclic) всего лишь объясняет (для понимающих), что подчиненный объект не может быть родителем своих родителей, то есть направленные отношения parent-child не могут образовывать циклы. Ну и, надеюсь, понятно, что «граф» не имеет никакого отношения к титулованию лиц благородного происхождения, то есть от «графа Толстого» до нашего с вами графа дистанция огромного размера..

Довольно часто встречается термин DAG-object. Совершенно справедливо предположить, что DAG-объект - это просто элемент DAG, то есть любой объект, который может быть «припарентен»

к другим DAG-объектам. Очень просто уяснить разницу между DAG и не-DAG объектами, открыв Outliner и включив/выключив галочку Display=>DAG Objects Only. Таким образом, активно используя любимый «метод тыка», можно сказать, что все объекты, которые можно выбрать непосредственно на экране, то есть в панели камеры, являются DAG-объектами. Пытливые умы уже, видимо, сделали вывод, что DAG-объекты всегда имеют transform-ноду, которая позволяет перемещать их в пространстве и группировать с другими объектами. Любая геометрия, источники света, камеры, частицы, локаторы, флюиды, кластеры - все это DAG-объекты. Соответственно, blendshape, или любой материал, или текстура DAG-объектами не являются.

Если быть совсем въедливым, надо упомянуть термин DAG-node, то есть это нода, входящая в состав DAG-объекта. Реально существует всего два типа DAG-нод: это transform-нода и shapeнода, о которых я уже говорил выше. Transform-нода позволяет группировать объекты, и, км правило, она (если это не пустая группа) имеет подчиненные (child) объекты в виде shape-ноды и других transform-нод. Shape-нода никогда не имеет подчиненных объектов, но всегда имеет хотя бы одного transform-родителя. (Отсюда следует еще одно определение DAG-объекта: как постоянной связки transform+shape.) Благодаря механизму инстансирования, одна shape-нода может иметь несколько;

родителей. Именно поэтому DAG называется графом, так как в этом случае он уже перестает иметь структуру иерархического дерева (в котором у потомк всегда один родитель), а становится произвольным графом. Однако в «майской» терминологии уже прижился термин - хотя, строго говоря, некорректный: «дерево зависимостей», или «дерево истории»: под которым понимается, естественно, произвольной формы граф.

Разберем теперь, что такое DG (Dependency Graph). Как следует из названия - это граф зависимостей, представляющий из себя набор нод и связей между ними. DG тоже являета направленным (directed), так как связи между атрибутами нод однозначно направлены. Но, е отличие от DAG, он может быть цикличным, так как пользователь может устанавливать связи между любыми двумя нодами и в любом направлении. Связи в DG уже не являются иерархическими отношениями, а представляют собой просто потоки данных между нодами, соединяющими входные и выходные атрибуты этих нод. Именно DG отображается в Hypergraph в режиме Input And Output Connections.

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

Примерами DG-нод являются материалы, текстуры, системное время time1, ноды, отвечающие за Construction History, и пр.

Снова погружаясь в тонкости терминологии, можно сказать, что все DAG-ноды являются,в том числе, и DG-нодами, так как transform и shape тоже могут соединяться с другими нодами при помощи Hypergraph или Connection Editor.

Иногда все DG-ноды, кроме transform и shape, называют Non-DAG Nodes. Но здесь лишь подчеркивается то обстоятельство, что такие ноды нельзя сгруппировать или выбрать, а затем перемещать на экране. Материалы и текстуры - основной пример Non-DAG Nodes. Деформеры, глобальное время time1, expressions, blendshape, defaultRenderGlobals и масса других служебных нод - это все Non-DAG Nodes. Некоторые из них изначально присутствуют в любой сцене, некоторые пользователь создает в явном виде (например, материалы или expressions), но большинство из них возникают как служебные или вспомогательные объекты в процессе выполнения тех или иных операций.

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

Примечание. Понятнее всего DAG-терминология описана в документации в разделе «Для взрослых», а именно в описании ноды DAG Node. Во всех остальных разделах можно найти лишь циклические ссылки, притом скороговоркой, с более чем лаконичными разъяснениями.

Циклы в дереве зависимостей и их последствия.

Поднимание себя за уши Если можно соединять атрибуты различных нод Hypergraph в любой последовательности, теоретически возможна ситуация, когда возникают циклы. Другими словами, путешествуя по связям в Hypergraph в направлении стрелок можно вернуться к ноде, с которой начиналось путешествие. Например, если создать три цилиндра, можно без проблем соединить в Connection Editor вращения первого и второго цилиндров (через атрибуты rotate), затем вращения второго «третьего, а затем - третьего и первого. И получится, что все цилиндры управляют друг другом.

Попытка повращать любой объект не приведет к успеху, так как атрибуты rotate всех объектов заблокированы связями с другими объектами. Это похоже на попытку поднять самого себя за уши.

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

Примером «непреднамеренного» создания циклов может служить попытка «приконстрейнить»

родительский объект к одному из своих потомков. В этом случае родитель управляет потомком через иерархию, а потомок управляет родителем через констрейн.

MAYA однако проявляет ангельское терпение, стараясь не «упасть» от таких циклических издевательств и даже сообщает пользователю о наличии циклов в сцене. Поэтому стоит очень внимательно относиться к появлению в Script Editor сообщения типа:

//Warning: Cycle on 'pCube2.rotate' may not evaluate as expected.

// (Use 'cycleCheck -e o f f to disable this warning.) // В случае появления такого приговора следует внимательно пересмотреть связи между объектами и атрибутами, чтобы выявить некорректные зависимости.

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

Expression как нода совершенно произвольного назначения.

Природа expressions. Входы, выходы и сиротливые expressions Я уже упоминал о том, что можно рассматривать ноды как простые вычислители принимающие и передающие данные. У каждой ноды собственные правила, по которым она вычисляет выходные данные. Но если вам вдруг понадобится сделать вычисления по собственным формулам, то создавать собственные ноды можно только с помощью специально обученных людей, знающих C++ и умеющих компилировать плагины. В этом случае, на помощь приходят expressions.

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

Примечание. Если вы смогли дочитать текст до этого места, автор должен от души поздравить вас: вы обладаете завидным мужеством и у вас недюжинная пытливость ума. Правда, дальше, с точки зрения абстрактности и технологичности, материал будет еще хуже... (Или - лучше? Может, крепче?) Главное: я вас честно об этом предупредил.

Давайте посмотрим на expressions как на обычную ноду, которая имеет входы и выходы.

Откройте файл expressionStart.ma.

В нем содержится три объекта и один expression, который удерживает сферу по вертикали посередине между кубами.

В Hypergraph можно увидеть связи между объектами и нодой expression1.

Как следует из диаграммы зависимостей, нода expression1 принимает на вход значения двух атрибутов (pCube1.translateY и pCube2.translateY), вычисляет результат и помещает его на выход (output[0]), который присоединяется к вертикальной координате сферы (nurbsSphere translateY).

Проделаем следующие действия. Попробуем присоединить выход от expression1 еще к шкому-нибудь объекту.

Создайте полигональный тор.

Выберите его и сферу, а затем в Hypergraph выполните Graph=> Input And Output Connec­ tions, чтобы увидеть одновременно и тор, и ноду expression1.

Перетащите ноду expression1 на pTorus1 средней кнопкой мыши, удерживая Shift.

Откроется Connection Editor.

Слева, где находится expression1, выберите Output/Output[0], асправа вы делите TranslateY, присоединив, таким образом, выходное значение от expression1 к вертикальному перемещению юра.

Подергав за кубики, убедитесь, что тор двигается вместе со сферой. Теперь откройте Expression Editor, задайте в нем для удобства Select Filter=>By Expression Name и выберите expression1, чтобы увидеть его Парадоксальная вещь! Формула для expression1 не изменилась и не содержит даже упоминаний про pTorus1, однако тор беззастенчиво двигается вместе со сферой.

Конечно, если кто-то откроет этот файл в первый раз, его очень сильно озадачит поведеия тора (особенно если еще обратиться к Expression Editor). Недоумение не пройдет до тех пор, пока любопытствующий не откроет Hypergraph и не прочитает эту главу. Однако мы сделали именно то, что хотели, причем вручную, устанавливая связи между объектами. Поэтому MAYA не всегда может адекватно трактовать и отображать наши, в общем-то «хакерские», действия в своем интерфейсе.

Конечно, если добавить в expression1 еще одну строку вида:

pTorus1.translateY=(pCube1.translateY+pCube2.translateY)/2;

то MAYA совершенно законно добавит к ноде expression1 еще один выходной атрибут (output[1]) присоединит его к тору.

Таким образом, в нашем случае (как, впрочем, и в любом другом случае), expression работает как простой вычислитель: он принимает данные на входных атрибутах (input[n], их может быть сколько угодно), производит подсчеты и отправляет результат на выходные атрибуты (output[n], и их также может быть сколько угодно).

Проделайте следующий, еще более радикальный эксперимент.

В Hypergraph разыщите expression и аккуратно удалите все его связи с остальным объектами кроме time1.

Теперь откройте Expression Editor и посмотрите на его формулу (для этого может понадобиться нажать кнопку Reload).

Довольно схематическая формула говорит о том, что выход равен полусумме двух входов.

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

.I[0] и.|[1] суть обозначения атрибутов input[0] и input[1], которые, как можно догадаться, присутствуют у ноды expression1. О[0] соответствует имеющемуся атрибуту output[0].

Совершенно очевидно, что если вы, орудуя мышкой и используя Connection Editor, присоедините «а входы (input[n]) ноды expression1 какие-либо атрибуты кубиков, а выход (output[0]) также лрисоедините к нужному атрибуту сферы или тора, то expression снова заработает определенным вами образом, и MAYA, с большой долей вероятности, даже правильно отобразит его формулу в Expression Editor.

Данный эксперимент, позволяет представить expression как ноду совершенно общего назначения, с произвольным количеством входов и выходов. Конечно, такой радикальный взгляд на природу expressions несколько необычен, но в целях привыкания к логике MAYA попробуйте иногда представлять их именно так.

Вопросы мироздания и философии. Единство и борьба противоположностей. Expressions против Nodes. Кто главный? Элементы маразма. Области применения противоположностей Материал изложенный далее, требует некоторой подготовки, поэтому если вы пока еще морально не готовы столкнуться с малопонятными вещами, можете пропустить остаток главы. Кроме того, уровень абстракции и обилие общих рассуждений могут нанести психический урон незакаленным творческим натурам. Если же вы действительно готовы разобраться во внутренностях MAYA читайте дальше! Ну, а тем, кто метит в технические директора или в разработчики, изложенное н ж следует выучить наизусть.

У некоторых пытливых умов может возникнуть резонный вопрос: в чем принципиальная разница между expressions и нодами? Когда применяются одни и когда другие? Если и те и другие представляют из себя «ящик» с несколькими входами и выходами, которые можно присоединять «другим объектам, то кто из них имеет преимущество? На первый взгляд, может показаться, что преимущество у expressions, так как ноды представляют собой «черный ящик», алгоритм работы которого изменить невозможно, а формула, по которой работают expressions, легко редактируется.

Однако все не так просто.

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

Главное преимущество expressions в том, что они могут быть практически мгновенно созданы заново или отредактированы. Алгоритм их работы прозрачен и задается формулой на языке MEL, которую можно копировать или менять. Но вот на этом преимущества expressions заканчиваются. Дальше начинаются ограничения...

Во-первых, совершенно непонятно, как должны выглядеть expressions, создающие, например, процедурные примитивы типа polySphere. Как написать формулу на MEL, которая берет на входе радиус и количество граней, а на выходе выдает полигональную геометрию, остается только догадываться. Можно, конечно, вычислить на основе этих данных координаты всех вершин для сферы и дальше, через команду polyCreateFacet, пересоздавать всю поверхность, однако делать это надо будет в каждом кадре или при изменении любого входа (ну, хотя бы радиуса сферы), боюсь, это, возможно, даже будет работать. Но, как уже догадались читатели, работать чудовищно медленно. Отсюда вытекает основное ограничение expressions низкая производительность.

Во-вторых, поскольку ехрressions пишут на языке МЕL который является интерпретируемым), выполняются они медленно. Конечно, «медленно» - понятие условное, так что вычисление положения сферы между двумя кубиками займет время, которое вы едва ли сможете заметить на экране, визуально. Однако когда это касается не одной, а сотен или тысяч вычислительных операций в каждом кадре, производительность expressions становится ощутимо недостаточной (в главе, посвященной MEL, есть пример попытки создать деформер, и там обозначены границы применения MELc точки зрения производительности).

Ноды написаны на языке С++ и откомпилированы для каждой операционной системы.

Скорость вычисления данных внутри них (то есть производительность нод) в десятки, а то и в сотни раз быстрее, чем выполнение команд для expressions. Поэтому их главное преимуществ.

- скорость, тогда как главное ограничение тот факт, что пользователь никак не может измени»

алгоритм работы конкретной ноды. Точнее, может... Но для этого надо изучить язык С++ запрограммировать на нем новую формулу, скомпилировать ее под имеющуюся операционную систему и затем подключить к MAYA как плагин...

Области применения expressions и нод можно приблизительно обрисовать так.

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

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

Конечно, можно нарушать эти «обывательские» правила и вместо expressions собирать нужную формулу при помощи соответствующих нод.

Откройте, например, файл noExpressionStart.ma.

В нем вместо expressions используется нода plusMinusAverage1, которая вычисляет среднее значение для двух входящих атрибутов (для этого атрибут operation для нее установлен в Average). Вы можете рассмотреть сцену подробнее в Hypergraph и убедиться, что она работает точно так же, как сцена expressionStart.ma, использующая expression.

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

nurbsSphere1.translateY=(pCube1.translateY*0.25*pCube2.translateY*0.75) Надо думать, что в случае использования нод вам придется туго (посмотрите результат в файле noExpressionMulti.ma).

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

Например, создайте цилиндр.

Потом откройте Hypershade и создайте ноду samplerlnfo: Create=>General Utilities=>Sampler info. В сцене появится новый объект samplerlnfo1, отвечающий за доступ к информации об объектах непосредственно в процессе рендеринга. Обычно его соединяют с другими утилитами для анализа «вычисления цвета или других свойств в каждой точке поверхности.

Но вы можете открыть Expression Editor и просто создать expression типа:

if(samplerlnfo1.pointWorldY>0)lambert1.diffuse= noiselsamplerlnfo1.pointWorldY*10)+1;

Смысл его заключается в том, что все точки на поверхностях с материалом lambert1 будут окрашиваться в некий рисунок, если их вертикальная координата положительна. Иными словами, таким образом вы кладете, некую текстуру на канал diffuse, причем рисунок этой текстуры определяете по формуле в своем expression. (Пример сохранен в materialWithExpression.ma.) Для взрослых. Отсутствие возможности скомпилировать текстуру или материал, определенный с помощью expression, всегда вызывало у меня чувство горечи идосады.

Сейчас, когда на смену «родному» рендереру программы MAYA пришел великий men­ tal ray со своим языком описания шейдеров, эта горечь немного смягчилась. Однако идея использовать expression для написания материалов, согласитесь, неплохая.

После таких экстремальных рассуждений, дадим волю рукам и -поковыряемся» во внутренностях MAYA ради обнаружения секретных или недокументированных нод, которые могут принести пользу. Но сначала обсудим еще один секретный атрибут любой ноды, встречающейся в Загадочный атрибут Node State. Состояние ноды.

Блокировка действия некоторых нод. Обновление экрана и оптимизация интерактивной производительности Если вы не очень любопытны, этот раздел можно и не читать, однако не исключено, что здоровое любопытство и желание «во всем дойти до самой сути» не дает вам спокойно спать, пока вы не узнаете, для чего же предназначен совершенно мистический атрибут Node State, встречающийся у каждой ноды и мозолящий глаза в каждой закладке Attribute Editor в разделе Node Behavior.

Раз мы договорились рассматривать любую ноду в MAYA как некоторый вычислитель, было бы логично иметь возможность временно выключать и включать этот вычислитель.

Например, вы смоделировали супер-телескоп с помощью некоторого количества операции Loft, Extrude и других. Благодаря неубитой Construction History все работает, как часы, и форма телескопа меняется при редактировании исходных кривых, лежащих в основе всей модели Однако может статься, что модель выполнена столь изысканно, что довольно долго приходится ждать пересчета поверхности после изменения кривой. А нужно, скажем, временно отменить этот, пересчет, отредактировать все нужные кривые, а затем снова включить обновление поверхности Есть такое дело! Для этого достаточно разыскать в Attribute Editor закладки для операций Loft и Extrude и установить для них Node State=Blocking. Правда, после этого поверхности эти перестанут не только обновляться, но и вообще показываться на экране. Если же вы хотите, чтобы поверхности не исчезали, а только перестали обновляться, надо установить Node State=Waiting-Normal.

Другой пример можно привести на основе применения деформеров или скининга.

Предположим, вы привязали поверхность к костям и деформировали ее с помощью скелета. Если выбрать поверхность, то в закладках Attribute Editor будет присутствовать нода типа skinCluster, отвечающая за деформации поверхности скелетом. Если установить для нее Node State=Blocking, то поверхность тут же вернется к своему недеформированном состоянию, то есть скининг перестанет вычисляться, и сколько бы вы не шевелили скелет, поверхность не будет изменяться, пока вы не установите Node State=Normal.

Внимательные экспериментаторы заметят, конечно, что при попытке установить Node State=Blocking для скининга MAYA выдает сообщение:

Warning: skinCluster1 (Skin Cluster Node): Blocked is not supported on deformers. Switching to Has No Effect.

А затем сама устанавливает Node State=HasNoEffect.

Честно сказать, на данном этапе даже мне не хочется углубляться в такие дебри и объяснять, в чем разница между этими понятиями.

Однако чтобы вы все-таки почувствовали разницу, хотя бы интуитивно, откройте файл expressionStart.ma (или любой другой содержащий expression), выберите сферу и найдите закладку expression1 в Attribute Editor.

Установите в ней Node State=HasNoEffect.

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

Однако если установить Node State=Blocking, expression не только не будет вычисляться, но и приниматься во внимание. Теперь он полностью заблокирован, и сферу можно передвигать по вертикали вручную.

Советую запомнить только два значения атрибута Node State. Это Normal и Blocking. Если нужно временно заблокировать работу некоторой ноды, достаточно установить для нее Node State=Blocking. В тех случаях, когда значение Blocking не поддерживается данной нодой, MAYA сама изменит его на HasNoEffects.

Как можно догадаться, для некоторых типов нод изменение значение атрибута Node State не имеет ни смысла, ни эффекта. Сколько бы вы ни меняли его значение материалов или тектстур, этю не отразится на рендеринге. Просто шаблон окна Attribute Editor предполагает отображение этого атрибута для всех типов нод, даже для тех, которые его не используют. Точно также, для некоторых типов нод имеет смысл только лишь одно значение: либо Blocking, либо HasNoEffect.

Для того, чтобы быстро заблокировать все ноды определенного типа во всей сцене, есть специальный пункт меню: Modify=>Evaluate Nodes. Он позволяет установить Node State=Blocking Д я перечисленных в нем типов нод.

Кстати, использование атрибута Node State настолько полезно, что для многих типов нод он по умолчанию является анимируемым. И, выбрав какие-нибудь expression или констрейн, можно обнаружить, что этот атрибут присутствует в Channel Box и готов к анимации.

Для взрослых. Большие дяди, естественно, хотели бы знать, что означают значения типа Waiting-Normal. Сам термин Waiting (ожидание) означает: MAYA ожидает какого-то события, чтобы вернуться в установленное состояние.

Например, Waiting-Normal означает: MAYA ждет события, чтобы вернуться в состояние Node State-Normal.

Но что это за событие? Оно определяет, как и когда MAYA обновляет дерево зависимостей междуобъектами (и, вчастности, History). Поумолчаниюзависимости обновляются (а экран перерисовывается) прямо во время перетаскивания или изменения мышкой каких-нибудь объектов, от которых зависят другие объекты.

Однако это поведение можно изменить, например, для слабых, «истощенных»

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

Делается это через окно Windows=>Settings/Preferences=>Performance Settings.

Если в этом окне задать Refresh On=Release, обновление зависимостей и перерисовка экрана будут происходить только после отпускания кнопки мыши, вслед за перетаскиванием чего-нибудь в панели камеры. При Refresh On=Demand обновления истории и зависимостей вообще не будет, пока вы не нажмете кнопку Update которая появится в правом нижнем углу экрана.

Отпускание кнопки мыши или нажатие кнопки Update и есть то самое событие, которого -ожидает- значение Node State=Waiting-Normal, чтобы вернуться в состояние Normal. Так как по умолчанию это событие не определено Refresh On=Drag), вы можете использовать Node State=Waiting-Normal, для того, чтобы не обновлять поверхности, имеющие Construction History, но при этом и не прятал Секретные коды, секретные ноды. Создание нод вручную Далее я хочу привести несколько примеров •ручной» работы с нодами для решения тех или иных задач. Под термином «ручная» работа я подразумеваю соединение, при необходимости, какого-то количества входных и выходных атрибутов с помощью Connection Editor или же создание «вручную» некоторых, мало изученных нод, не используя основное меню MAYA.

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

Если вы знаете тип ноды, которую хотите создать (например, нашли ее описание в документации или подсмотрели у приятеля), то всегда можете выполнить команду createNode «nodetype»

где-nodetype» - это тип ноды, который вам известен.

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

Кроме того, иногда имеет смысл применять ноды «не по назначению». Например анимационные кривые вместо текстуры ramp или основания волос (ноды follicles) вместо констрейнов. Всем этим практическим вопросам будет посвящен дальнейший материал.

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

Попробуйте, например, создать плоскость и назначить на нее материал, а в качестве текстуры цвета выбрать fractal.

Выбрав текстуру и открыв атрибуты фрактала в Attribute Editor, добавьте к ноде fractal через меню Attributes=>Add Attributes свой атрибут с именем resolution и значением по умолчанию, равным 96.

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

Особенно часто такие секреты используются при рендеринге и в частности при использовании mental ray.

Выберите mental ray в качестве основного рендерера.

Разыщите в Outliner и выделите ноду mentalrayGlobals, а затем добавить к ней четыре динамических атрибута:

regionRectX=0, regionRectY=0, regionRectWidth=300, regionRectHeight=300.

Посмотрите теперь, что будет происходить при рендеринге сцены с помощью mental ray, Закрепление одного объекта на поверхности другого Рассмотрим простую задачу. Как «посадить» один объект на поверхность другого, так чтобы пивот первого намертво приклеился к поверхности второго. При этом хотелось бы, чтобы «приклеенный» объект еще и смотрел какой-нибудь своей осью по нормали к поверхности, на которой он «сидит».

Как и положено в MAYA, способов решения такой задачи как минимум десять. Однако среди них нет ни одного, позволяющего выбрать два объекта, а затем выполнить пункт меню типа «Закрепить первый объект на поверхности второго, но быстро!». Например, Geometry Соn straint делает не совсем то, что нужно. Приконстрейненный объект будет свободно скользить по поверхности, а это не входит в условия задачи.

«Официальный» путь заключается в следующем: нарисовать кривую на поверхности, запустить объект по этой кривой (Animate=>Path Animation=>Attach to Path), остановить его в нужном месте и удалить анимацию с движения по пути. Путь хоть и исключительно гибкий и эффективный (создаются всего две ноды: кривая и motionPath), однако пугающий своей, скажем так, противоестественностью.

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

Посмотрим, однако, как это «неофициально» делает сама MAYA, когда ее просят об этом неявным образом.

Рисование скриптами. Geometry Paint. Секретные заклинания Создайте в новой сцене сплайновый тор (Create=>NURBS Primitives=>Torus).

Увеличьте его как следует (scale=7).

Теперь создайте сплайновый конус.

Переименуйте его в tree.

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

Теперь выберите тор и возьмите в руки инструмент рисования скриптами: Modify=>Paint Script Tool. Как и в случае с другими инструментами рисования, следует открыть его Option Box.

В появившихся настройках инструмента следует открыть последний раздел Setup и в первом же поле Tool Setup Cmd ввести «секретное заклинание»: geometryPaint. А далее, с чувством глубокого удовлетворения нажать Enter...

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

Кроме того, обязательно должно появиться окошко с конкретными настройками для данного скрипта. Коль скоро заданный нами скрипт осуществляет рисование объектами по поверхности, прежде всего в поле Geometry надо ввести название объекта, которым мы будем рисовать поверхности тора.

Введите в поле Geometry строку tree, то есть название конуса.

Кроме того, в разделе Options включите галочку Align (выровнять) и выключите опции Group и Isolate. (Остальные опции легко исследовать «методом тыка»: помните, что во время рисования можно контролировать не только размер, но и поворот и смещение объектов.) Если поверхность тора по-прежнему выбрана, проведите по ней один, какой-нибудь, но гениальный, штрих. Должна возникнуть дорожка из конусов. Трудно, конечно, устоять перед таким продвинутым инструментом, однако не увлекайтесь сейчас новыми штрихами, это можно будет сделать позже.

Выберите Select Tool и загляните в Outliner. Там должны появиться новые объекты, выбрав тор и встряхнув его, можно убедиться, что конусы приклеились к нему намертво. Более того, деформировав конус на контрольные вершины вы можете увидеть, что они не только не отклеиваются, но и смотрят по нормали к поверхности тор. При этом никаких вспомогательных объектов типа кривых или констрейнов в Outliner не появилось.

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

Прежде всего, можно заметить еще в Attribute Editor, что в закладке transform атрибуты translate и rotate помечены желтым, то есть имеют входящие связи от других объектов. Там же, в Attribute Editor, присутствуют некоторые закладки с загадочными именами типа nurbsTorus1Geom188Loc и nurbsTorus1Geom188Align.

В этих закладках можно определить тип этих нод, pointOnSurfacelnfo и rotateHelper, соответственно.

Как следует из документации к ноде pointOnSurfacelnfo, на вход к ней подается информация о поверхности и два числа, U и V координаты, которые однозначно определяют точку на поверхности. На выходе нода вычисляет трехмерные координаты этой точки, нормаль и касательные к поверхности в этой точке. U и V координаты можно найти в Attribute Editor в виде двух атрибутов: Parameter U и Parameter V, изменяя которые можно заставить конус перемещаться вдоль поверхности.

Таким образом, как следует из Hypergraph, нода pointOnSurfacelnfo, созданная для каждого конуса, вычисляет трехмерные координаты точки на поверхности тора, заданные атрибутами Раrameter U/V, и подает результат вычислений на атрибуты translate конуса, что заставляет его всегда «приклеиваться» своим пивотом к поверхности. Тут, вроде все, понятно, за исключением быть может, связи между поверхностью тора и нодой pointOnSurfacelnfo.

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

В конце концов следует применить метод пристального взгляда в Hypergraph. Выбрав конус и показав его связи в окне Hypergraph, можно сделать следующие выводы:

Нода rotateHelper служит для того, чтобы развернуть объект перпендикулярно поверхности в данной точке. На входе она принимает от ноды pointOnSurfacelnfo вычисленные координаты нормали и одной из касательных в точке поверхности. Эти коодинаты подаются на ее входные атрибуты uр и forward. Получив два направления, «вверх» и «вперед», нода rotateHelper вычисляет три значения вращений, на которые надо развернуть объект, чтобы он смотрел своей локальной осью Y вдоль направления «вверх» (uр), а своей локальной осью X - вдоль направления -вперед»

Howard). Три этих значения для вращений просто присоединяются на выходе к атрибутам rotate для конуса, чтобы он развернулся своей макушкой по нормали к поверхности, а осью X вдоль поверхности.

Таким образом, чтобы «посадить» один объект на поверхность, можно использовать следующие три способа.

Первый способ: «нарисовать» объектом по поверхности, как было показано выше, затем удалить ненужные объекты и, с помощью атрибутов Parameter U/V у ноды pointOnSurfacelnfo, привести объект в нужное место на поверхности.

Второй: можно сделать все вручную, создав две ноды pointOnSurfacelnfo и rotateHelper с помощью команд createNode pointOnSurfacelnfo;

createNode rotateHelper;

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

Примечание. Нода rotateHelper - не «родная» для MAYA, а реализованная в виде плагина. Чтобы она создавалась и работала без проблем, надо в окне Plugin Man­ ager включить галочку напротив плагина rotateHelper.

Третий способ: если работа с нодой rotateHelper вас пугает, достаточно создать и присоединить, как положено, ноду pointOnSurfacelnfo для закрепления объекта на поверхности, а для ориентации его по нормали можно воспользоваться Normal Constraint.

Остается, правда, открытым один довольно серьезный вопрос. Нода pointOnSurfacelnfo работает только со сплайновыми поверхностями. А как же закрепить объект на полигональной сетке? Можно скачать с сайта www.alias.com соответствующий Bonus Tools Pack, расширяющий стандартные возможности MAYA. В состав этого дополнения входят такие ноды, как pointOnMeshlnfo и pointOnSubdlnfo, реализованные, как плагины. Однако количество усилий в этом случае, похоже, превысит разумные пределы.