Но в данном случае мы модифицируем скрипт так, чтобы, скажем, при нажатии shift, delete вызывал старую процедуру и игнорировал наш сетап. Но ведь delete у нас нет в хоткей эдиторе, соответственно, нет возможности привязать его к шифту. Тут нам поможет еще одна полезная мел команда - “getModifiers”. Все, что она делает, -это возвращает индекс зажатого в данный момент модификатора/ов. Например, если во время вызова getModifiers был зажат шифт, процедура вернет 1, если контрол - 4 и.т.д. Выложите getModifiers на свободный шелф и понажимайте на нем при разных зажатых модификаторах, обратите внимание на result, который при этом выдается. Воспользуемся этой замечательной процедуркой:

global proc doDelete()

{

string $sel[] = ls -sl -dagv;

skinClusterPreDelete($sel);

if ( size ('filterExpand -sm 32') > 0 && 'getModifiers' != 1 )

//добавили обязательное условие - шифт ве зажат

polyDelEdge -cv true;

delete; Тут &&    -    and    говорит,    что оба условия должны выполняться одновременно (противоположное по смыслу выражение || - OR: одно из условий должно выполняться). Таким образом, если шифт зажат, оператор if не выполнит свою процедуру, так как одно из обязательных условий не выполняется (“!=” интерпретируется как “не равен”). Сохраняем скриптик, тестим и наслаждаемся…

Умные (context sensitive) хоткеи и marking менюшки.

Принцип такого сетапа прост, но очень эффективен. Идея в том, чтобы заставить одну единственную клавишу выполнять кучу разных действий в зависимости от того, как и когда мы ее нажимаем. Помните marking menu для создания примитивов? Я повесил его на клавишу х (привязкой к сетке пользуюсь редко). Что если на эту же клавишу навесить еще одно маркинг меню? Скажем, если мы работаем с полигонами, - меню с основными poly операциями? Такие как глобальный merge вершин (я обычно перемещаю вершины друг к другу зажатой клавишей v, а потом применяю глобальный merge, который мерджит все близлежащие ребра), mirror, soft/hard edge, move component, localTools, delete history и т.д., и т.п. Помним так же про extrude? Что если нажатие-отпускание клавиши х будет экструдить еджи/ фейсы/вершины, а нажатие той же клавиши + левой кнопки мыши будет вызывать разные маркинг менюшки в зависимости от того, с чем мы работаем? Более того, можно привязать все это к текущему режиму. В режиме Modeling имеем одни менюшки/ действия, в режиме Animation - другие, в Dynamics

-    третьи… Ну, и в довесок можно узнать, где мы сейчас работаем, скажем, в перспективе использовать одно, в UV эдиторе - другое, а в гипершейде - третье…

Технические вопросы: В первую очередь, требуется разное поведение скрипта при разных условиях. Это мы уже умеем делать - с помощью логического оператора if. Еще скрипт должен вызывать несколько разных маркинг менюшек. Также нужно собрать “Экструдер” - процедуру, умеющую экструдить все типы компонентов. Ну и самое важное - нужно каким-то образом определить, как именно мы нажимали на наш хоткей, было ли это быстрое нажатие-отпускание или вызов маркинг меню. Ну и не помешает процедурка, узнающая текущий режим в майке (Animation и т.д.).


⇐ вернуться назад | | далее ⇒