Ускоряя Maya, послесловие. Скрипты для ускорения работы в Maya.

[Лекс Дарлог (DRL)]

Готово.
2 дня назад VFXi встал, я эти 2 дня дорабатывал и правил текст.
Несколько раз отредактировал, но это всё равно самая первая, довольно сырая версия обзора:
Всё о файлах кастомизации: plugins, scripts, prefs

Тут, на рендер-ру, спойлеры не поддерживаются. Поэтому здесь продублирую позже и сильно сокращённую версию.

Для коллег, разбирающихся в вопросе - там же обращение. В самом низу.

 

[Михаил Фоменко]

Спасибо огромное. Прочитал, все разложено по полочкам. Еще раз прочитаю и все правильно установлю. (понравился способ с модулями). Отличный гид по установке скриптов и плагов! Ответил бы там, да все никак не дойдет письмо с подтверждением мыла.

 

[Лекс Дарлог (DRL)]

Да, форум-то они запустили, но пока в сильно-пресильно тестовом режиме. Львиная доля функционала не пашет. Со стилями - вообще беда.

 

[Дмитрий damat Астапкович]

DRL, статья отличная, спасибо. От себя добавлю, что еще можно написать о:
- хоткеях
- userNamedCommands
- setVar/getVar
- символьных ссылках на папку с Maya для Dropbox

 

[Михаил Фоменко]

А что еще можно сказать о хоткеях? С ними тоже какие-то "трюки" есть?

 

[Дмитрий damat Астапкович]

можно расписать, из чего состоят хоткеи и как они хранятся. Можно же, например, написать свой скрипт для хоткея прямо в Hotkey Editor и потом позвать его, например, с полки

 

[Лекс Дарлог (DRL)]

damat,
мысль хорошая. Правда, меня и так сейчас беспокоит получившийся объём. Ломаю голову, как можно сократить.
Боюсь, если по теме префов попытаться туда запилить вообще всё, что, по моему мнению, должен знать любой майщик - как бы это не смутило новичков. Я всё-таки старался по максимуму дистанцироваться от голого МЕЛ'а. Предположительно, человек, владеющий мелом, умеет сам читать майские доки. А, стало быть, всё описанное мной уже знает.

- userNamedCommands

всё, что я о них знаю - это то, что они врапперы для userRunTimeCommands. И что вместе они как раз и образуют хоткеи (в смысле "как и где это хранится").

- символьных ссылках на папку с Maya для Dropbox

вот это не понял вообще.

 

[Дмитрий damat Астапкович]

в Dropbox можно синхронизировать не только те папки, которые находятся в самом Dropbox: http://wiki.dropbox.com/TipsAndTricks/SyncOtherFolders. Это позволяет замапить всю дефолтную папку Maya в Dropbox

 

[Лекс Дарлог (DRL)]

ОК, это и правда полезное. Сам внимательно ознакомлюсь, запилю.

В предыдущем посте я много чего дописал. Перечитай, если не видел.

 

[Александр Чернега]

По поводу хоткеев:

1) Настроить хоткей так, что бы допустим при нажатии на Q включался один инструмент, а при двойном клике на Q активировалось другой. (сообщение №346, №347, + №350)
2) Можно настроит так, что бы при нажатии на одну кнопку, в разных окнах совершались разные действия. Плюс, можно добавить меню. То есть при быстром нажатии и отпускании совершается действия, а при зажатии +LMB открывается маркинг меню.

К примеру:

[b]Хоткей Press[/b]
global float $startTimer; 
$startTimer = `timerX`; 

//modelPane
string $currentPanel = `getPanel -withFocus`; 
string $panelType = `getPanel -typeOf $currentPanel`; 
if ($panelType == "modelPanel") 
{
Название меню, которое будет открываться в перспективе и ортографических окнах.
К примеру:
Mode_Vertex_Press;
}

//HyperShade
if (`getPanel -wf` == "hyperShadePanel1") 
{ 
То же самое, только в окне редактирования материалов
}

//UV Texture Editor
if (`getPanel -wf` == "polyTexturePlacementPanel1") 
{ 
}

[b]Хоткей Release[/b]

if (`popupMenu -exists tempMM`) { deleteUI tempMM; }
global float $startTimer;
if (`timerX -startTime $startTimer` < 0.5)
{

//modelPane
string $currentPanel = `getPanel -withFocus`; 
string $panelType = `getPanel -typeOf $currentPanel`; 
if ($panelType == "modelPanel") 
{
Команда которая будет выполняться после быстрого нажатия на кнопку, в перспективном и ортографических окнах. ;
}

//HyperShade
if (`getPanel -wf` == "hyperShadePanel1") 
{ 
То же самое, только в окне редактирования материалов;
}

//UV Texture Editor
if (`getPanel -wf` == "polyTexturePlacementPanel1") 
{ 
}
}

Более расширенные (в кодовом плане – мутные) возможности

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

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

 

[Дмитрий damat Астапкович]

мы тут немного не про в хоткеях, но пост однозначно в тему ... темы =) спасибо

ps контекстная и оконная зависимость в полный рост используется в Xumi

 

[Лекс Дарлог (DRL)]

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

По поводу затеянного мной топика - обсудим завтра в скайпе, если не против.

всем:
да, VFXi лежит, и я с этим ничего поделать не могу. Он запустился ещё не в совсем рабочем режиме, так что это нормально. Если у кого горит - могу лично кинуть текст. Только учтите: он с BB-кодами, и в чистом виде совершенно нечитаем.

Другая тема.
Дим,
на грядущем ЦГивенте будешь что-нибудь докладывать на тему? Мечусь между "ехать - не ехать", и твоё выступление однозначно склонило бы чашу весов к первому варианту.

 

[Лекс Дарлог (DRL)]

Александр Чернега,
Несколько замечаний по поводу твоего скрипта.

• Глобальные переменные по МЕЛ-стандартам начинаются с маленькой буквы g. Т.е., в твоём примере нужно использовать переменную $gStartTimer. На работе самого скрипта никак не скажется, а вот нарушение стандартов - не есть гуд. К тому же, я с недавних пор вообще всем своим глобальным переменным начал приписывать свой ник в начале. Во избежание конфликтов. Ник у меня довольно короткий, и с ним переменная по-любому будет уникальной. Покопавшись в чужих скриптах, понял, что это общая практика.
• Использовать несколько конструкций if для выбора - нехорошо. Тогда уж хотя бы if ... else if ... else. А ещё лучше - case-break.

• if (`getPanel -wf` == "hyperShadePanel1")

  У меня сейчас Майя не запущена, но мне кажется, что такое сравнение - это совсем нехорошо. Сравнивать по идее надо с типом панели (как в первый раз), а не с её названием, которое в принципе может быть каким угодно.
• В данном конкретном случае (маркинг-менюха при нажатии, иначе выполнить команду) имхо надо реализовать вообще без timerX'а. Так же, как это сделано во views. А именно: менюху создаём сами, командой popupMenu. В этой команде добавляем флаг -postMenuCommand . Он позволяет выполнять какую-то команду, если менюха была отображена. В качестве значения этого флага пишем "$мояПеременная = 1". $мояПеременная - это int, в котором сохраняем, была ли показана менюха. Потом, в команде при отпускании проверяем: если менюха вызвана не была - тогда выполняем команду. В коде самой менюхи, после команды popupMenu, чтоб жестко не прописывать в самом скрипте все кнопки, достаточно сделать source файла попап-менюхи.

То есть с учётом всех корректировок код на нажатие будет выглядеть так:

...

popupMenu
-pmc "global int $gМояПеременная; $gМояПеременная = 1"
...все остальные нужные флаги...
-markingMenu 1
tempMM;

switch ($panelType) {

case "modelPanel":
source "файлМаркинМенюхиДляВьюпорта.mel";
break;

case "другойТипПанели":
source "файлДругойМаркинМенюхи.mel";
break;

... и т.п.
}

На отпускание:

...
global int $gМояПеременная;
if (! $gМояПеременная) {

нужные;
команды;

}

$gМояПеременная = 0;

 

[Лекс Дарлог (DRL)]

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

• без иконок можно прожить, к тому же из-за них меню xumi долго выводится;
• без пресетов - уже сложнее, но думаю можно решить через подменю;
• нативные OptionBox'ы, как по мне - так даже удобнее, чем задерживать мышь над кнопкой ксуми;
• а баги ксуми порядком поддостали.

Поэтому, может запилим общими силами своё дополнение (на чистом МЕЛе, безо всяких плагинов), реализующий собственно этот интерфейс генерации своих менюх? Обычных ММ, без иконок. Но именно через контекстный интерфейс, как в ксуми.
Там кода будет довольно много - потому что, подобно xumi, нужно будет самим работать напрямую с файлами конфигурации. А в Майе это, мягко говоря, не очень удобно делать. К тому же, придётся писать свои ГУЙи с драг-н-дропом кнопок в него; контекстными условиями, при котором выводится та или иная менюха, и т.п.
Я об этом давненько задумываюсь, потому что ксуми - да, хорош (спасибо Диме) - но просто безбожно глючный. Даже когда привыкнешь ко всем его ограничениям - всё равно напрягает. А после того, как узнал, что серьёзно ксуми точно не будет допиливаться, решил, что да, надо написать свой ксуми. Без преферанса (иконки и пресеты), но с девицами (отсутствие багов, мгновенное отображение, поддержка бесконечной вложенности, зависимость контекста также от режима Майи и окна, и т.п.).
Но в одну харю я боюсь, что не осилю. Да и не программист я, поэтому желательно делать с кем-то, кто разбирается в теоретических вещах: оптимальное число операций в цикле, эффективное использование переменных, и т.п.

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

 

[Михаил Фоменко]

По поводу преференсов... Попытался сделать, как расписал DRL, но ничего не пашет.
Сейчас распишу подробнее на примере трех плагинов, которые попробовал поставить, а именно: displaceD, dRaster NEX (известно, где лежит) и spPaint3d_2011.1.

Начал я с того, что перенес папку префов на D:\MayaFolder\MayaPrefs и создал глобальную переменную среды MAYA_APP_DIR (Значение D:\MayaFolder\MayaPrefs).
В этой папке есть следующие папки:
-2012-x64;
-addons (которую создал я);
-projects;
-scripts;
-файл mayaLog.
В папке addons я создал три папки в соответсвии с названиями плагинов (displaceD, NEX и spPaint3d_2011.1). По поводу NEX: при установке он не спрашивает путь и устанавливается сам в C:\Program Files (x86)\dRaster. Так он работает, но мне ведь нужно, чтобы можно было все переносить и т.д. (в этом-то и суть) и я вырезал и вставил соответствующие файлы из C:\Program Files (x86)\dRaster в D:\MayaFolder\MayaPrefs\addons\NEX. (Так, наверняка, делать нельзя, но другие плагины ведь тоже все равно не работают... Об этом ниже).
Возьмем первый плагин. В созданную мною папку D:\MayaFolder\MayaPrefs\addons\displaceD я положил файлы, которые относятся к этому плагину. Теперь там папки plug-ins и scripts. В первой лежит сам плагин DisplaceD.mll.
В папке D:\MayaFolder\MayaPrefs\2012-x64 в файле Maya.env я прописал следующее: MAYA_MODULE_PATH = $MAYA_APP_DIR/2012-x64/modules/2012-x64/modules; и создал соответственно папку D:\MayaFolder\MayaPrefs\2012-x64\modules, в которой поместил два файла: displaceD.module и dRaster_NEX.module. В первом прописал: + displaceD 2012 x64 D:/MayaFolder/MayaPrefs/Addons/displaceD. Во втором: + NEX 2012-x64 D:/MayaFolder/MayaPrefs/addons/NEX/2012-x64
Но... Ничего не работает. displaceD Maya вообще отказывается видеть в списке плагинов, которые надо погрузить (plug-in manager), а NEX видит, но говорит: "The drInit.mel file could not be loaded. Please reinstall NEX and try again"...
А файл этот лежит в папке D:\MayaFolder\MayaPrefs\addons\NEX перед папкой 2012-x64.
Остается смириться с тем, что NEX при переносе всегда надо будет устанавливать заново? А если будут еще подобные плаги? Это печально...
По поводу spPaint3d_2011.1. Это вроде бы для 11 версии, но на 12 я проверял, плагин выполняет свои функции. Вроде критичных багов мною обнаружено не было. Короче, раньше он работал. Так вот в его папке D:\MayaFolder\MayaPrefs\addons\spPaint3d_2011.1 есть папки help (на нее пофиг), prefs и scripts. Надо как-то из prefs вытаскивать папку icons и класть куда-то (она там одна)? Как вообще быть? Еще в папке D:\MayaFolder\MayaPrefs\addons\spPaint3d_2011.1\scripts есть один mel файл и два файла *.py. И в руководстве по установке на креативКраше сказано, что укажите, мол, правильно environment variables для python (PYTHONPATH). С чем это едят?
Ребят, что я сделал не так?

 

[Михаил Фоменко]

$MAYA_APP_DIR/2012-x64/modules/2012-x64/modules; - это я ошибся. Сейчас исправил на $MAYA_APP_DIR/2012-x64/modules; И еще ошибся в пути с названием папки addons. Сейчас все с маленькой. Все правильно. (Почему нельзя редактировать пост больше одного раза?...) Так же создал в D:\MayaFolder\MayaPrefs глобальную папку modules и Maya.env, чтобы попробовать установить CPS Tools 4.03. Залил в эту папку файлы, прописал в глобальном Maya.env MAYA_MODULE_PATH = $MAYA_APP_DIR/modules; и... CPS установился и работает. Я вроде суть понял, даже чутка разобрался в том, как оно все должно быть и как весь этот механизм функционирует. Но почему по-прежнему не работают вышеуказанные плагины? Я в тупике :-(

 

[Лекс Дарлог (DRL)]

1. Пиши проблемы по пунктам, так проще в них разбираться.
2. Не надо пытаться сделать всё сразу, делай по этапам. Перенёс папку настроек - запустил, проверил, что работает - забэкапил префы - идём дальше. То же самое при установке каждого плагина: забэкапил - установил одно дополнение - проверил, что работает - снова забэкапил.
3. По поводу dRaster NEX.
   Многие мега-супер-пупер крутые платные дополнения ставятся по-извратски, и используют какие-то пути, которые Майя сама по себе не видит. Причём помимо прочего для лицензирования могут использовать реестр, храня при этом свои параметры в глубоко-преглубоко зарытом разделе. Например, рендермен (тот ещё монстр).
   Конкретно NEX ставится вроде бы по-нормальному: он создаёт в папке самой Майи (в Program Files), в подпапке modules свой файл, указывающий на C:\Program Files (x86)\dRaster\maya\2009. Но вот в чём беда - есть ещё один мел-файл "drInit.mel", который лежит уровнем выше. Не знаю, как Некс его подгружает, но он явно нужен. Я как-то пытался перенести некс, но сам тогда был ещё зелёным в этом вопросе, и забил. Просто поставил на всех компах в C:/Program Files, а файл модуля так и оставил в самой Майе (что, вообще-то, нехорошо). Сами настройки некс хранит в моей папке префов - так что вроде норм. Но раз уж пошла такая пьянка...
   Прежде чем переносить дополнение в папку префов, надо посмотреть, как оно о себе сообщает самой Майе. Есть 4 способа:
   • Добавляет файл модуля в папку самой Майи (так ведут себя большинство инсталляторов).
   • Добавляет файл модуля в папку с префами (самый умный способ, но я ещё не видел ни одного инсталлятора, который бы так себя вёл).
   • Хранит сам файл модуля в своей папке (где-то в Програм Файлс). А Майе сообщает об этом файле, используя env var MAYA_MODULE_PATH (как правило - добавляя свой путь в эту переменную непосредственно в операционке).
   • Втупую прописывает все свои пути в env-var'ы MAYA_SCRIPT_PATH, MAYA_PLUG_IN_PATH и т.п. Самый тупой способ. Вроде, так себя вёл рендермэн.
   Суть - в том, что надо сперва узнать, какие именно папки аддон скармливает Майе, и лишь потом копировать.
   В случае с НЕКСом - заходим в папкаМайи/modules - и что видим? Файл dRaster.txt. Открываем. Что там? Путь C:\Program Files (x86)\dRaster\maya\2009.
   Соответственно, копировать надо содержимое не всей папки некса, а именно этой. Но, как я упоминал, есть злосчастный drInit.mel, лежащий уровнем выше. Поэтому попробуй так: скопировать содержимое папки c:\Program Files (x86)\dRaster\maya\ (т.е. этот файл и папку, соответствующую версии) в D:\MayaFolder\MayaPrefs\addons\NEX.
   Потом перемести файл dRaster.txt из папки Майи/modules в папку префов/modules. И измени его, чтоб он указывал на D:/MayaFolder/MayaPrefs/addons/NEX/2009 (или какая там у тебя папка версии).
   Если заведётся - отлично, значит НЕКС использует относительные пути при обращении к файлу drInit.mel. Если нет - значит НЕКС дурак, и о том, как установить его в переносимую папку префов, надо спрашивать их техподдержку (если есть лицензия, а она конечно же у всех нас есть, честно-честно). Если по каким-то причинам в техподдержку писать не хочется, можно ещё попробовать вручную засорсить этот скрипт из userSetup.mel вот так (буквально):
   

   source "../drInit.mel";

   Если и это не запашет - увы, не судьба. Самому сейчас переносить некс - времени нет, только ближе к выходным будет.
4. Про displaceD.
   Во-первых, не понял, зачем ты сделал это:
   
   В папке D:\MayaFolder\MayaPrefs\2012-x64 в файле Maya.env я прописал следующее: MAYA_MODULE_PATH = $MAYA_APP_DIR/2012-x64/modules/2012-x64/modules;
   Непонятно, зачем внутри 2012-x64/modules создавать ещё одну 2012-x64, а в ней ещё одну modules. Это раз.
   Два: Майя по умолчанию читает содержимое подпапки modules в каждой папке настроек (глобальной / для спец. версии). Так что ничего в env var MAYA_MODULE_PATH дописывать не надо - просто создай соответствующий файл модуля в MayaPrefs\2012-x64\modules или MayaPrefs\modules.
   
   В первом прописал: + displaceD 2012 x64 D:/MayaFolder/MayaPrefs/Addons/displaceD
   Синтаксис указан неверно. пробел - разделитель значения. У тебя получается: плагин displaceD, версия 2012, папка - x64 и ещё какая-то хрень. А пути "x64" вообще не существует (ни в виндах, ни в юниксах), вот оно и ругается. И вообще, версия плага не 2012, а 1.12b (смотри историю на странице плага).
5. Про spPaint3d.
   А с чего ему не работать? Там только файлы питона и мела. Скомпилированного ничего нет. Он будет спокойно работать на всех версиях Майи начиная с той, для которой написан.
   По поводу PYTHONPATH - ничего указывать не надо. Повторяю, если ты устанавливаешь аддон модулем, то Майя автоматом подцепляет все нужные подпапки. Это автор описал, если бы мы устанавливали 2-ым способом из моего топика. Когда мы подключаем файл модуля, Майя при старте САМА добавлет все нужные пути в соответствующие им переменные окружения. В этом-то и соль подключения через модули.
6. Общая рекомендация: перечитай более внимательно мой топик (текст я тебе кидал).
7. про редактирование поста - на рендер-ру какая-то непонятная система. Пост нельзя редактировать то ли по истечении определённого времени, то ли после того, как хотя бы кто-то его уже прочитал.

 

[Михаил Фоменко]

DRL, спасибо тебе. Теперь все окончательно устоканилось в сознании и все, о чем я писал выше - работает на отлично.
Говоря о NEX... Сделал, как ты сказал (точнее повторил, т.к. первый раз делал так же), т.к., считай, разорвал плагин на две части. Основная часть теперь в моих префах, а другая с файлом drInit.mel, иконкой и файлом unins000.exe и unins.dat осталась в C:\Program Files (x86)\dRaster\NEX... И так он подключается и работает. Значит использует относительные пути, да... Но ведь это ж не выход. Все равно ведь получается, чтобы перенести префы на другой комп, мне отдельно надо будет копошиться с этим файлом, который остался на С и дополнительно впихивать все эти файлы в папку C:\Program Files (x86)\dRaster\NEX на всех компах, на которых придется работать, к примеру. Потому что через source "" он не подключается.

 

[Лекс Дарлог (DRL)]

unins000.exe и unins.dat - это файлы деинсталлятора. В принципе, если разобрать unins.dat - то можно будет узнать, как плагин сообщает местоположение файла drInit.mel. Вот только я не знаю, что за формат у этого файла и как его можно прочитать. Инсталлер/анинсталлер - вроде популярный. Вот только я в них совершенно не разбираюсь.
Возвращаясь к теме - это проблема конкретно этого плагина. Создатели сделали интеграцию в Майю не совсем стандартным способом, и это их вина.
НЕКС, конечно, хорошее дело. Но вот такое отношение к пользователям порой выбешивает. Мол, если тупой юзер - ты и так не знаешь, куда оно встало и как работает. А если продвинутый - десять раз мозг вывихнешь, прежде чем понять, как наш плаг можно кастомизировать. Но это не наша проблема, тебе надо - ты и парься.

 

[Дмитрий damat Астапкович]

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

DRL, скорее всего, ты не прав относительно unins.dat - плагин может брать информацию откуда угодно (локальный файл или реестр). Но ты полностью прав, что это все проблемы - это проблема конкретного плагина.

Если говорить совсем в общем, то любой продвинутый плагин состоит из:
- mll файла, который содержит нестандартные ноды/фичи (в т.ч. регистрация, например)
- mel файл(-ы) для юзер интерфейса
- локальных userPrefs, которые, например, помнят о накликанных комбобоксах/галочках и прочем

В принципе, конкретно плагину должно быть все равно, где лежит mel - если процедуры, объявленные в нем, уже объявлены (сделан source) - он просто вызывает mel-код, часто это просто вызов процедуры с параметрами.