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

[Paul_Winex]

А зря. Если в школе хотя бы Паскаль учил - разобраться с МЕЛом по стандартной хэлпе труда не составит.

В школе Паскаль учил, графику на паскале делал, сам себе С++ и DirectX учил. Максу скрипты писал. Мел даже проще. В данной ситуации в МЕЛе я пока на старте и готов бы всё сделать самостоятельно, но всё упирается в свободное время. Тут лишь спросил о готовых решениях или готовности кого-то сделать это решение в данный момент. Ну и будущее наступает через 2 недели. Будут каникулы праздничные, может поотстанут все от меня. Вот и потыкаю. Тем более добрые люди помогли намеками да советами. Уже знаю откуда копать.

 

[Nocturnal]

Уважаемые форумчане!
я некоторое время изучал MotionBuilder, затем взялся за майю. я так привык к МоВи, что начал майку под его хоткеи перекраивать. Частично удалось - например, прогон анимации (Alv+V отдыхает). Никак не получается сделать Jog (знающие МоВи меня поймут).
Мне бы хотелось узнать: какие скрипты/плагины используются в реальных проектах по персонажной анимации? И используются ли вообще?
Например, отзеркаливание позы персонажа. Или вставка позы относительно определенного эффектора.
И еще - как можно доработать майский Motion Trail? Это ведь форменное извращение.

 

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

Вопрос несколько абстрактный, ответ получится таким же.
1. я не знаю, что такое Jog, так как не знаю МВ
2. какие плагины/скрипты используются в реальных проектах? Эммм... разные, более конкретно сложно ответить. Ригинг без скриптов практически не возможен, а тзеркаливание позы персонажа и подмешивание поз в свою очередь сильно завязаны на риг. В целом что-то реальное без скриптов вообще не делается, так как Майя в целом про то, что можно и нужно постоянно допиливать то, что есть из коробки.
3. как можно доработать Motion Trail - написать свой или попробовать найти что-то уже сделанное. В любом случае вопрос надо конкретизировать - сейчас вот так, а надо вот так и так.

 

[Nocturnal]

MotionTrail.
Сейчас вот так:
- он получается или набором локаторов, или сплошной линией.
- по обновлению нареканий нет: или по запросу, или при изменении кейфреймов, или постоянно. Это надо оставить.
Необходимо так:
- та же сплошная линия, но с кадрами, и чтобы ключевые кадры выделялись.
- кадры на линии трейла должны отображаться сферами, кубиками (для скорости отрисовки) или локаторами.
- естесственно, хочется выбирать цвет для трейла, фреймов и кейфреймов.
- ну и последнее: нужно, чтобы трейл отображался только во временном диапазоне, установленном в Range Slider. Или хотя бы имел параметры framesPrev и framesFwd, означающие на сколько фреймов назад/вперед он должен быть отрисован.
Все эти действия хотелось бы регулировать в процессе работы.
Нашел парочку скриптов на краше, но в них много чего не хватает
Это уже попахивает не скриптингом, а плагинописанием.
-------------
Jog.
Это интересная вещь, работает примерно так:
зажимается опр. клавиша (у меня "z") + левая кнопка мыши. затем мышь тянется влево (воспр. Назад) и вправо (воспр. Вперед). Чем дальше тянется от места начала срабатывания, тем быстрее проигрывается анимация. Самое интересное: оно проигрывает сабфреймы, т.е. не только то, что на кадрах, но и МЕЖДУ ними. Можно анимацию интерактивно прокрутить очень медленно или очень быстро - одним движением мыша.
Это проще попробовать в кайдаре. Там Jog висит на кнопке "J".

 

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

Я вернулся.

Про Motion Trail - в принципе, можно сделать прототип скриптами, но это точно будет бажить. Основная проблема - это связка анимационных кривых и их 3d представления с возможностью переносить изменения как из анимации в 3d, так и наоборот. Думаю, что это хороший реквест, но сильно сомневаюсь, что его когда бы то ни было реализуют в Maya. Последние версии доделок чего-то существующего до хорошего качества содержат по минимуму.

Про Jog - вещь действительно интересная. Не очень понятно, в каких пределах играется анимация, но это уже детали. Остальное, если говорить с ходу, реализовать вроде как можно, хотя в своей практике с драгами (drag) серьезьно не работал. Могу помочь с написанием, если возьмешься.

 

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

Макс Благай куда-то запропастился, я уезжаю в командировку. К сожалению, Xumi для 2011 пока остается где-то впереди.

 

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

В книге "Maya F1" Король Геннадий описывает создание скрипта, который замещает процедуру Delete. Этот скрипт проверяет, есть ли в выделении эджи и если есть - выполняет вместо простого удаления операцию Delete Polygon Edge.
Скрипт для меня стал просто "must-have'ным", но у него было 3 существенных недостатка:

• Даже если в выделении были только эджи, скрипт после их удаления выполнял основную команду delete. В результате в истории после каждого удаления эджей появлялась ещё 1 нода - deleteComponent, которая, по сути, удаляла "ничего". И меня, как ярого сторонника порядка, обилие этих "мусорных" нод жутко бесило.
• Скрипт не совсем корректно работал, если выбраны были одновременно эджи и вертексы на одном объекте.
• Скрипт был составлен таким образом, что если нажать delete вместе с Shift, то будет выполнено стандартное удаление. Но он почему-то не делал этого при нажатии Shift+Ctrl, Shift+Alt, Shift+Ctrl+Alt.

На днях меня эти 3 бага вконец достали, и я слегка переписал его. Теперь процедура работает через сеты. Собственно, код (увы, местный двиг форума убирает табуляции):

	/*
	filterExpand фильтрует выделение: 32-рёбра, 31-вершины, 34-фейсы.
	getModifiers возвращает, какие служеб. клавиши зажаты.
	*/
	string $edges[] = `filterExpand -sm 32`;
	int $mods = `getModifiers`;
	// Если рёбра выбраны и не нажата клавиша Shift:
	if (`size $edges` > 0 && $mods != 1 && $mods != 5 && $mods != 9 && $mods != 13) {
		string $set = `sets -name DRL_tmpDelSet`; // Создаём сет с оригинальным выделением
		polyDelEdge -cv true $edges; // Удаление рёбер. cv  - CleanVertices.
		
		if (`sets -q -s $set` > 0) { // Удаление оставшегося
			select -r $set;
			delete;
		}
		
		select -r -ne $set; // Выбираем созданный сет для последующего удаления
	}
	
	delete; // Стандартное удаление либо удаление созданного сета

Как устанавливать:

• Идём в папку установки Майи и ищем там файл doDelete.mel.
• Копируем его в скриптовую папку в префах. Напр., <maya_preferences>/2008/scripts.
• Открываем его оттуда текстовым редактором.
• Листаем в самый конец, там где заканчивается процедура doDelete.
• Заменяем строчку "delete;" на тот код, что я дал выше.
• Сохраняем.

Я не в курсе, отличается ли этот файл в различных версиях Майи, поэтому описал процесс "пропатчивания", а не дал готовый скрипт.

Для 2008-ой версии файл выглядит так: http://multi-up.com/440712

 

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

Вдогонку:

Опять же, на днях, оформил пару очень простых, но крайне полезных процедурок: DRL ls и DRL Cast-Receive. Сам я их в том или ином виде использую давненько, но вчера допилил их до "общеупотребимого вида".

• Первая (DRL_ls) призвана исправить некоторую "недоделанность" Майской команды ls. А именно: у стандартной команды нет ключа, позволяющего вывести список всех потомков от заданных объектов. Ну то есть самая банальная задача: вывести все шэйп-ноды под выбранными трансформами - становится недетским испытанием. Синтаксис процедуры:
  

  string $list[] = DRL_ls(string $objects[], string $keys);

  где $objects - массив объектов, к которым применяется процедура,
  а $keys - параметры команды ls (напр., $keys = "-sl -dag")
  Если аргументы оставить пустыми (DRL_ls({},"");), то в качестве активных объектов будет взято текущее выделение, а в качестве ключей - "-sl -o -s". Т.е. процедура вернёт все шейп-ноды, находящиеся под выбранными трансформами. Стоит, правда, понимать, что процедура работает для всей иерархии. Т.е., если один полигональный объект припаренчен к другому, то выполнение процедуры на родителе выведет оба шейпа - и родителя, и потомка. По идее, процедуру надо было назвать DRL_hierarchical_ls, но я сократил, т.к. другого ls'а у меня нет.
• вторая (DRL_castReceive) позволяет скопом включать/выключать для всех выделенных объектов галки "Cast-" и "Receive Shadows", т.к. мне такое приходится делать часто.
  Синтаксис:
  

  DRL_castReceive $value;

  Где $value - это 1 или 0 для включения и выключения галок соответственно.

Для второй процедуры требуется первая.
Установка - обычная (скинуть в папку со скриптами).

Собственно, скрипты: http://multi-up.com/440751

P.S.: DRL_castReceive прекрасно расположилась в xumi на s+MMB. Как 2 пресета к кнопке.
P.P.S.: на какие файлообменники лучше кидать, чтоб оно дольше прожило?

 

[Paul_Winex]

P.P.S.: на какие файлообменники лучше кидать, чтоб оно дольше прожило?

на clip2net тебе дается 100 мб под аккаунт. лежит скока надо пока сам не удалишь. Маловато конечно но если скрипты хватить то хватит. Ну и вообще программулька удобная. Про надежность сервиса не отвечаю, не такой уж старый чтоб гарантии давать.

 

[Dark™]

самая банальная задача: вывести все шэйп-ноды под выбранными трансформами

А команда listRelatives -shapes чем не подходит?

Файлы лучше хранить на Dropbox. 2 гига бесплатно под личные файлы навсегда, а если пройти квест, то можно получить еще 1 гиг.

 

[Paul_Winex]

Dropbox зачетный!

 

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

А команда listRelatives -shapes чем не подходит?

Ну что сказать... дурная голова (незнание команд) ногам (рукам) покоя не даёт.
Хотя у команды ls есть прекрасные ключи ака флаги, которых у listRelatives нет. Так что и мой скрипт пригодится.
За наводку на listRelatives спасибо, вот исправленая версия
DRL_castReceive: http://dl.dropbox.com/u/22103610/Maya/scripts/DRL_castReceive.mel
Теперь скрипт включает/выключает тени только для шейп-нод непосредственно под выбранными трансформами. ИМХО, так даже лучше.

 

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

Feature-Request для xumi:

Добавить поддержку правой кнопки мыши.

Имеется в виду, чтоб при зажимании хоткея и ПКМ появлялась ещё одна менюшка. Имхо, все 4 новых менюхи имет смысл сделать контекстно-независимыми (как при СКМ).
Дело в том, что у меня уже все 6 контекстно-независимых менюх забиты под завязку. 2 из них, а также A+ЛКМ при пустом выделении, полностью состоят из сабменю. Сабменю 3-го уровня работает некорректно, так что не вариант.

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

 

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

Ещё один feature-request:

Если выбран объект типа "transform" (группа) - чтобы ксуми детектила среди потомков первый попавшийся не-трансформ и выдавала соответствующую ему менюшку. Имеется в виду комбинация A+LMB.
Потому что сам по себе трансформ контекстно-зависимых команд не имеет. К нему, как правило, применяются операции, соответствующие потомкам.

 

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

Всем привет =)

Забавно, что стоило уехать, у все заработало =)

Про реквест независимых меню:
1. есть субменю
2. независимость сделана доволно просто - посмотри код, можно сделат и для других кнопок легко
3. имхо контекстная зависимость - это одна из основних фишек кзуми

Сорри, что на транслите, по-другоме пока никак.

Dark:
Дим, думаю, не против если переведу это через translit.ru =)

P.S. Надеюсь, еще вернешься? =)

 

[Paul_Winex]

Я вновь вернусь к вопросу о рендере из CameraSequenser'а. Посмотрел как его прокачали в новой вайе 2012.
http://area.autodesk.com/maya2012
Там решили эту проблему путем переброса всех параметров анимации с разных камер на одну. Удобно конечно в некотором смысле. Но остается два вопроса:
- создаваемая камера просто перескакивает в пространстве (плюс анимация других атрибутов) пока движется основной макский таймслайдер. А что если в секвенсоре шоты пересекались по времени или были растянуты так же по времени?
- как быть с векторным пассом при перескоке камеры с одной точки в другую?

так что пока решение посредственное помоему.

 

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

Конечно вернусь =) Офигенный сервис

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

 

[Paul_Winex]

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

Отлично, составлю список

 

[Dark™]

Уточню: Дима сейчас на GDC в Сан-Франциско, до 4 марта, насколько понял, надо успеть =)
Вообще, если есть вопросы, то, естественно, их лучше сжать до нескольких конкретных, чтобы не грузить никого.
Задам пару:
1) Они упомянули multi-threaded nParticle collisions и ICE. Стоит ожидать настолько крутых ускорения и возможностей, как в видюшках от Softimage, в самой Maya?
2) Собираются ли они устранять старые слабые стороны майа, связанные с моделированием и рендером (их множество, думаю, многие найдут парочку), нежели улучшать какую-то одну стороны пакета, делая его все более специализированным.

 

[Paul_Winex]

Мои вопросы как недостаточно опытного пользователя Maya (потому может тупые )
1) Поддержу рейтинг вопроса об multi-threaded nParticle collisions и ICE!
2) Будут ли они делать удобный вывод на рендер из CameraSequenser для тех кто его активно использует?
Здесь замечу поподробней. Решение комбинировать все камеры из секвенсера в одну камеру имеет больше минусов чем плюсов.
+ Теперь у нас есть (ну мы вроде как уже в 2012 майе) одна камера которая сочетает в себе все шоты.
- а что если шоты в секвенсоре пересекались по времени? Как тогда будет выглядеть собраная камера?
- что если придется (а наверняка придется) что-то подправить? Мы вынуждены пересоздавать камеру заново. Это особенно не удобно если она подвергалась дополнительному редактированию. Я бы еще понял в этом плане решение навешать констрейнов и связей с исходными камерами, которые оперативно поправляют общую камеру вместе с изменениями в секвенсоре.
- знаю что как-то вопрос с VectorPass решают и используя одну камеру с перескоками в пространстве, но всё это не совсем успешные компромисы. Если у нас есть секвенсор, собирающий камеры (шоты) в одну последовательность, то вопрос о таких вещах должен отпасть, так как это уже не одна камера с перескоками.
В Render Settings есть выбор камер для рендера но они завязаны на один промежуток времени. Нужно лишь сделать менеджер куда вносить параметры каждого шота как отдельный "слой", а параметры его уже сделали в секвенсоре в Shoе PlayList, осталось эти данные направить в Butch и поочередно рендерить. То естьв этом ShotPlayList не хватает кнопки RENDER! с некоторыми дополнительными настройками.
3) Каковы планы насчет Iray в Maya? В демках не заметил рекламы, видимо до сих пор не встроили. Понимаю что смысл его не так вилик в майе сколько в максе, но всё же было бы приятно.

Больше не могу выдавить вопросы, последний уже почти от балды. В майе всё есть остальное (на данный момент) Вот если бы спросили про макс, я бы накатал толмуты, а тут только основное - физикс и мультиядерность динамики, превью партиклов и флюидов во вьюпорте 2.0 (может есть уже, не стал писать) и наболевший секвенсор. Если в Автодеске этим не займутся, я сажусь за MEL

Большое спасибо Дмитрию за возможность посредственной свзи с Автодеском, даже если и не удастся у них что-то выяснить