This project is read-only.

Import Functions

Jan 13, 2012 at 10:35 PM

Всем здрасьте.

Без лишних слов сразу к вопросу.

Возможно ли вычленить из плагины Бардака функции импорта и сделать отдельную .mll-ку строго по импорту?

Речь о том, чтобы возможно было без конфликтов одновременно включать в Майе официальные пару .mll-ок и Бардаковскую.

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

P.S. В любом случае спасибо за бескорыстную работу. По-крайней мере лично я вовсю пользуюсь вашими трудами и слежу за обновлениями. Когда трудишься и твои труды кому-то нужны, то это самая приятная благодарность.

Jan 14, 2012 at 3:40 PM
Edited Jan 14, 2012 at 7:15 PM

Поизучал про майю

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

Так что или включать бардаковский для импорта и отключать при экспорте. Или доработать бардаковский, чтобы нормально экспортировал.

 

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

Jan 14, 2012 at 11:02 PM
Edited Jan 14, 2012 at 11:04 PM
abramcumner wrote:
...включать бардаковский для импорта и отключать при экспорте...

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

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

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

Jan 15, 2012 at 6:50 PM

Мне кажется ГСЦ просто поменяли формат смуз груп в ЗП - надо дизассемблировать офф. плагины и изучать. Поменять конечно могли и из-за каких-то ошибок. Но в ТЧ никаких граненостей нет после бардаковских плагинов.

Ну и надо, чтобы RedPython скомпилировал тестовый плагин с убранным haveWriteMethod. Вдруг все заработает как надо :)))