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

[3rr0r]

Добрый всем день.
Сперва, спасибо большое за столь полезную информацию!
И вот вопрос немного не по теме, но по майе все же. Если менять координаты камеры/светильника находясь внутри него , то бишь look through, то анду не работает.
Порой сдвигаю случайно камеру из нее самой, а назад не вернуть.
Майя 2008. Может в новых версиях есть такая возможность? Или как-то это все делается?

 

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

Для возврата в предыдущий вид есть отдельная команда. Ее можно найти в Hotkey Editor: Edit->GoToPreviousView , и с ней же по соседству команду GoToNextView. По умолчанию эти команды живут на кнопках с квадратными скобками [ и ]

 

[3rr0r]

ого! не знал. спасибо!
надо таки прочитать Цыпцина...

 

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

Похоже, загнулась тема... Жаль.
А так замечательно всё начиналось! У меня на неё были такие надежды!

Ну да ладно. Подкину дровишек сам. Конечно, до мега-шедевров damat'а далеко, но чем богаты...
Пару страниц назад я пообещал написать скрипт, выводящий окошко с Input Box'ом из Status Line.
Собственно, наконец-то собрался. Вот: DRL InputBox v1.0.
Теперь в кои-то веки можно напрочь вырубить так бесивший меня Status Line.
Судите сами:

A в xumi кнопка для него прекрасно поселилась на Q+LMB.
Как ставить и использовать - написано внутри.

Хоть скрипт на 90% - копипаста встроенных майских процедур, чтобы заставить работать оставшиеся 10% пришлось изрядно попотеть и поразбираться.
И хоть лично мне сей скрипт кажется вполне полноценным, я всё же не программер, так что предлагаю протестить.

P.S.: всё ещё теплится надежда, что damat не забыл про тему - а просто "на время отлучился".

 

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

damat не успел тебе вчера ответить, что сегодня будет разбираться =)
Собственно, начинаю минут через 10

 

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

Тааак... Из тех багов, в которых ты написал в личку, ни один не повторяется. Либо ты самостоятельно допилил код, либо у нас разные версии Maya: традиционно тестирую на Maya 2008 Ext. 2

Заголовки к полям (label) не отображаются

Все корректно отображется в Help Line

* Иконка выбора текущего режима - тоже.

Работает нормально

Если поменять columnLayout на rowLayout - Майка ругается и напрочь отказывается создавать окно.

Насколько я понял, ты сам разобрался. По крайней мере в том коде, который есть сейчас columnLayout отсутствует

Самое неприятное - после закрытия этого окошка родные поля в Status Line прекращают работать, ругаясь, дескать "Не хватает такого-то элемента в окне statusLineInput_Window".

Все отлично работает, или я не нашел способа повторить баг.


Единственное, где могу подсказать:

Так и не нашёл, как можно само окно назвать по-человечески (чтоб для Майки оно так и было statusLineInput_Window, а в заголовке самого окна выводилось "Status Line fields").

Надо прописать название во флаге title команды window:

window -resizeToFitChildren 1 -title "Status Line fields" InputBox_popup;

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

 

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

То, что я тебе в личку отправлял - самая первая, ужасно кривая попытка.
Поняв, что ты можешь быть в отпуске, я пошёл курить мануал по непонятным командам.
Проблема была проста - совпадали id и адреса объектов интерфейса в моём окошке и оригинальном Status Line. Пришлось переименовать все глобальные переменные, используемые процедурой, и построчно пересматривая код, найти все остальные процедуры, где эти глобалы использовались.

Исходный код выдернут из Maya 2008 sp1 ext 1 (глючит у меня ext 2).

Про Title - спасибо, исправил. Вот версия 1.1 (с норм. заголовком окна).

По пожеланиям:
Лично я считаю, что встроенный Майский инструментарий моделинга ужасно неудобен.
В соседней ветке Deniseich 0-1 выложил скрипты, которые, судя по беглому изучению мануала, решают многие проблемы. Однако, как и во всяких Bonus Tools, львиная доля содержимого пака уже морально устарела, т.к. проблема решена в современных версиях редактора.
Так что мне давно хочется узнать, каким "допилом инструментария" пользуются в крупных студиях.

 

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

DRL, ответить на твой вопрос будет довольно непросто, но я постараюсь. Ответ будет довольно общий, но не без конкретики - все "допилы" я условно разделю на 3 части и расскажу про каждую отдельно:

1. улучшения ради пайплайна
Это допиливания на уровне собственного лончера для Maya, как CG Ru или наш NAT. Есть практически во всех студиях, основная задача - исправить систематические баги. Например, у всех наших художников и аутсорсеров все сцены открываются с выставлением проекта, единицы измерения выставляются в сантиметры, ось верх - z и т.д. Это происходит полностью автоматически при помощи скриптов, которые запускаются студийным лончером.

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

Такими штуками мало кто делиться, и причин тому несколько:

- ими непросто делиться. Так, например, я показал просмотрщик мипов текстур: http://www.render.ru/forum/viewtopic.php?post_id=823468#823468. Чтобы нормально отдать его во внешний мир, придется потратить минимум пару часов и придумать, куда складывать текстуру и шейдер, и как это автоматически подключать в скрипте на машинах абсолютно неизвестных мне юзеров. При этом у нас в студии он работает совершенно нормально, так как вписан в общий пак скриптов со своими путями.

- они слишком специфичны. Например, свое относительно серьезное скриптование я начал с того, что написал скрипт, который генерил дороги из одного сплайна для проекта Biker Mice from Mars. Ничего сложного: пачка офсетов кривых, лофт, генерация uv в трех uv сетах, разбивка на объекты, группировка, удаление мусора... наверно, было что-то еще, но сейчас я уже не вспомню. Этот скрипт был нереально полезен в рамках проекта, но был абсолютно не нужен за пределами комнаты, в которой делался проект.

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


2. улучшения инструментов для конкретных задач или конкретных людей

Без них можно жить, но жить будет не очень неудобно. К ним относятся всеможные скрипты, которых много на Creative Crash или в упомянутом паке Дениса. Их направленность сильно зависит от того, что конкретно требуется сделать и обычно они либо пишутся прямо по ходу, либо быстро находятся по ключевым словам в поиске, либо на них посылают на форумах после конкретного вопроса (http://www.cgtalk.ru/forum/showthread.php?t=27595)

Про них сложно рассказывать без привязки к конкретике, лучше всего такие инструменты показывать в больших туторах как общую часть процесса. Например, Молотов в своем making of N0X-2292 для Dominance War показал скрипт, который продвинуто раскидывает объекты по кривой (http://vimeo.com/5738519)

К ним я так же отношу, например, Xumi - работать без него мне крайне непросто, однако 99.99% майщиков даже посмотрев на него, просто проходят мимо. Так же есть Xtools, расширенные marking menu и прочие интерфейсные улучшения, которые нужны далеко не всем.


3. сложные инструменты общего характера (не знаю, как сказать это нормально =)

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

К таким инструментам могу отнести:
- Advanced Skeleton: система для ригинга, которая отлично подходит для геймдева
- File Texture Manager: утилита для работы с файлами текстур и их путями в сцене
- RenderView Extension: сильно улучшенный интерфейс майского рендера в окне
- Layout Tools: сборник инструментов для работы с локациями
- плагины PhysX от Nvidia
- ...

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


Очевидно, что такое разделение довольно условное, но оно довольно точно отражает ситуацию с моей точки зрения.

 

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

damat,
Спасибо за такой подробный ответ.
Теперь я гораздо чётче себе представляю перспективу кастомизации Майки. Плюс наконец-то понял назначение CGRU (как-то даже скачивал, но в итоге так и не врубился до конца).

Правда, в скриптах 1-го класса у меня пока что особой надобности нет. Со 2-ым, можно сказать, разделался (ещё раз спасибо за скрипты).

Так что меня-то больше интересовало, какие "апгрейды" чисто моделингового инструментария (п. 3) обычно используют в серьёзных конторах вроде вашей.
Ясное дело, что всё с того же Creative Crash - но что сортировка по скачиваниям и оценкам, что поиск по ключевым словам там выдают либо безразмерные паки, на одно только изучение которых можно убить полжизни (не говоря уж о сравнении) - либо такие древние скрипты, что удивляешься, как их ешё с сайта не выпилили.
Не пойми меня неправильно - сам я скриптами пользуюсь постоянно. Но раз я больше люблю эффекты/динамику - то и установленны у меня, соответственно, всякие разрушалки, физические движки и т.п. А раз моделю я крайне мало, хотелось "из первых рук" узнать, как допилить инструменты моделинга. Глядишь, так и моделить понравится.

Ну, например:

• в Майке нет снэппинга и алигна к фэйсам, да и вообще снэп к объёктам работает не очень удобно (напр, чтобы прилипнуть к точке на другом объекте, надо его тоже выделить).
• в результате использования Bridge на объекте может появиться невидимая дырка, т.к. появятся 2 ребра, выходищих из одних и тех же точек, и, соответственно, полностью совпадающих:
  
  
  
• Стандартные средства чистки топологии крайне несовершенны. Напр., они абсолютно бесполезны в такой ситуации:
  
  
• Результат Mesh->Reduce (равно как и Simplify Curve в Graph editor) также оставляет желать лучшего - процедура даже не пытается искать экстремумы или перестраивать положение точек ради сокращения числа поликов при той же кривизне.

И т.д., и т.п.
Я имел в виду - чем вы подобные проблемы решаете?


P.S./Offtop: после тестирования xumi я писал, что неудобно исчезновение хоткея для Select Tool. На что ты ответил:

он остается работать на q, понажимай внимательно

Я подумал на кривизну моей винды или инсталляции майки, но теперь проверил при всех возможных условиях - баг остался. По Q действительно вызывается инструмент. Только не Select Tool, а Move Tool.
И всё так же осталась проблема №1 из того же репорта.
Maya 2008 32bit sp1, WinXP sp3.

По идее, не критично - но хотелось уже поставить точку в настройке xumi.

 

[Dark™]

в Майке нет снэппинга и алигна к фэйсам

А как это ты представляешь снэп к фейсу, я чет не могу представить, к вершине еще понятно.

в результате использования Bridge

Не знаю, как в других пакетах работает команда, но даже судя по названию (bridge - мост) команда не должна соединять боковые грани. Для этих целей есть Append и Аdd Divisions, если надо разбить поверхность ребрами.

Стандартные средства чистки топологии крайне несовершенны

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

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

Тоже спорно, программа убирает полики в первую очередь в местах с наименьшей кривизной, да и форму более менее сохраняет с Preserve Vertex positions. Но по эффективности этот инструмент, конечно, не сравнить с отдельными прогами, вроде VizUp.

 

[yursiv]

в Майке нет снэппинга и алигна к фэйсам

А как это ты представляешь снэп к фейсу, я чет не могу представить, к вершине еще понятно.

В майке есть снаппинг по трем вершинам - но шесть вершин выделять - это слишком. Даже скрипт для этого написал что только фейсы выделять. Было бы очень классно иметь инструмент вроде снап тогезе тула - чтоб можно было не делая лишних действий(сделать хилит 1-му объекту, 2-му, выделить фейс на первом, на втором) - просто кликать на двух фейсах и все. В сочетании со снапингом по двум вертексам - можно снапиться как угодно... Только пока реализовано это не очень удобно.

 

[yursiv]

А вообще есть в майке возможность снаппинга к фейсам. Только нашел - раньше не замечал....))

 

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

А как это ты представляешь снэп к фейсу, я чет не могу представить, к вершине еще понятно.

Выбираем мув тул. Выделяем, скажем, вершину. Зажимаем sticky-хоткей (как при x, c, v). И теперь при перемещении вершина стремится оказаться в плоскости ближайшего фейса.
Сейчас подобного достигнуть можно с помощью Align Axis With Face / Edge в мув туле, но всё же это далеко не то.
yursiv, да, про Snap Together забыл. Но несмотря на название это инструмент выравнивания (алигна), а не собственно снэп.

судя по названию (bridge - мост) команда не должна соединять боковые грани.

Да, не должна. Но могла бы. Допустим, нам надо сделать так:

Т.е. соединить 2 ребра, разбив полученный фейс на 7 частей. Ясное дело, что это можно сделать апенд тулом, а потом 6 раз сплит полигон тулом, меняя с 6 до 1 Number of points... Но зачем нам делать то, что программа могла бы выполнять автоматически?

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

Данный конкретный случай - не придуманный, а из рельной практики. Однажды мне дали модель окружения в виде уровня, выдернутого из одной игры. Модель уже была затекстурена, так что менять UV-маппинг было нельзя. Задача - разрушить несколько строений на этом уровне. А теперь - сюрприз! Вся модель состояла из отдельных треугольников, и другого варианта модели не было. Т.е. фейсы совпадали боковыми рёбрами, но это было не одно общее ребро. Ну что - применям Merge Vertices с маленьким Tolerance. Модель становится целой, но в куче мест появляется именно та проблема, которую я показал. Пришлось править топологию вручную, люто извращаясь, чтобы не задеть UV-маппинг. Потому что инструментарий для работы с UV в Майке ещё более недоработан, чем моделинговый.

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

 

[Лексей]

Насчет снапинга к центру фэйса. Я давным-давно решил этот вопрос когда, зажав кнопечку "V - снап к вершинам" подвел к центру фэйса. Вот только подсветка центров фэйсов должна быть включена на этот момент.

 

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

Лексей,
Спасибо за находку. Действительно полезная штука. Только это снэп к центру фэйса (к точке), а не к фэйсу в целом (к плоскости).

 

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

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

 

[yursiv]

про Snap Together забыл. Но несмотря на название это инструмент выравнивания (алигна), а не собственно снэп

А так?

 

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

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

yursiv, тул - он и есть тул. Снэппинг - это прилипание. Т.е. когда в процессе использования какого-то инструмента программа "округляет" твои действия. Напр, в фотошопе - до границ холста, до гайдов, до выделения. А в Майке - до кривых, вертексов, эджей, фейсов...

 

[yursiv]

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

ЗЫ. А сделать живой поверхность,как я понимаю, не устаивает никак - из-за того что доплнительные клики надо делать?

 

[yursiv]

Довольно корявое решение, но может будет полезно....
Это дописываем в userSetup.mel

scriptCtx
    -title "MakeLiveTool"
    -totalSelectionSets 1
    -toolCursorType "question"
    -fcs "select -r $Selection1[1]; makeLive;select -r $Selection1[0];MoveTool;"
    -cumulativeLists true
    -expandSelectionList true
    -setNoSelectionPrompt "Click on mesh to make it Live"
    -setSelectionPrompt "Release MakeLive Hotkey"
    -setDoneSelectionPrompt "Never used because setAutoComplete is set"
    -setAutoToggleSelection true
    -setSelectionCount 2
    -setAutoComplete true
    
    makeLiveToolCtx;

Создаем команду в хоткей эдиторе и вешаем на нее хоткей Press

setToolTo makeLiveToolCtx;

Создаем команду в хоткей эдиторе и вешаем на нее хоткей Release

{
string $sel[] = `ls -sl`;
makeLive; makeLive; 
select -r $sel[0];
}

Пользоваться так -
1 выделяем нужный меш
2 зажимаем хоткей
3 кликаем на поверхности которую нужно сделать живой
4 возюкаем по ней средней кнопкой мыши
5 отпускаем хоткей

Работает только с ОДНИМ выделенным мешем

ЗЫ DRL А ситуацию в картинках хотелось бы все-таки увидеть