Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: правильное хранение переменных в ассете
Форум .:3DCenter.ru:. > Пакеты 3D моделирования > Houdini
VUX
Есть желание запустить код в секции ассета всего один раз. Например юзер скачал ассет - при первом создании ассет копирует из себя файл (майский скрипт) в указаную папку - и код больше не должен исполняться.

Сейчас оно работает примерно так. В ассетовом евенте On Created такое:
Код
section = kwargs['node'].type().definition().sections()["firstCreation"]
if not section.contents():
    folder = hou.ui.selectFile(file_type=hou.fileType.Directory)
    content = kwargs['node'].type().definition().sections()["mhpFile"].contents()
    section_file = file(folder + 'c: /mhp.py', "w")
    section_file.write( content )
    section_file.close()
    section.setContents('1')

Походу если секция "firstCreation" пуста - то оно исполняеться и в секцию пишеться "1".
Есть ли более нормальные методы хранения переменных в ассете?
Zipper
Цитата(VUX @ 27/10/2012, 23:02) *
Походу если секция "firstCreation" пуста - то оно исполняеться и в секцию пишеться "1".


Не совсем понял.
Юзер создал ассет, код отработал, чего еще надо то? В след раз при создании ассета, можно просто проверить, лежат ли файлы где нужно и какие нужно., если лежат, ничего не делаем....
Есть еще PreFirstCreate эвент, он отработает один раз, и даже при старте гудини, в уже созданных экземплярах, редко когда нужно.

Писать пересенные в ассет на хранение можно, но это не совсем правильно. Ассет должен инициализировать себя в момент создания экземпляра. В пределах одной сессии хранить любые данные можно например в Node.setUserData()., в которую можно писать последовательность битов:
pickle.dumps() и pickle.loads(), если нужно писать объект посложнее сторки. Но это только в пределах одной сессии. Перманентное хранение я если честно не пробывал, но уверен способы есть, хотя, опять-же - это не совсем верно по логике гудини.
VUX
Цитата
это не совсем верно по логике гудини.
согласен.

Вообще я придумал по другому. В секции гудини храниться какбы майский скрипт (там функции для отправки заданого майского обекта в алембик). При создании экземпляра (или гдето еще) ассет проверяет есть ли в мае в памяти одна из функций (словарь locals()) и если нет то содержимое секции записываеться во временный файл. Потом он считываеться маей (commandPort и execfile) и удаляеться. Питоновским tempfile не получаеться наверно изза кодировок. Идея в том что ассет который сотрудничает с маей все хранит в себе и при инсталяции ассета всюработу делает гудини - а от маи только требуеться открытие порта. PreFirstCreate почемуто не работал - нада проверить - может чтото упустил...

ПС. Алексей спасиба за толковые советы. Они меня наталкивают на правельный путь. Давно осознавал мощь гудини - но только сейчас проникшись глубже в ассеты (автоматизацию процесса) я продолжаю офигевать. Все таки в мае написание хотябы приближенных ассетов это теоретически возможно, а на практике если за это серьозно взяться - то можно превротиться в зомби и толку очень мало когда есть уже такой мощный механизм в гудини. Я забираю свои слова по поводу реальности реализации подобного в мае )
VUX
вот шо у меня пока получилось. Для тренировки то шо нада. Я уже наигрался с гонянием сетки в реальном времени. Теперь решил сделать чтото более практичное.
Еще добавлю кнопки для бейка геометрии, для синхронизации с майской сценой, и извлечения отдельных обектов (delete sop + merge) одним нажатием. Вроде должно быть удобно.
Попозже буду делать отдельный ассет для обратной отправки геометрии в маю

http://youtu.be/epMCNHSZPAM?hd=1
Zipper
Цитата(VUX @ 28/10/2012, 14:41) *
вот шо у меня пока получилось. Для тренировки то шо нада. Я уже наигрался с гонянием сетки в реальном времени. Теперь решил сделать чтото более практичное.
Еще добавлю кнопки для бейка геометрии, для синхронизации с майской сценой, и извлечения отдельных обектов (delete sop + merge) одним нажатием. Вроде должно быть удобно.
Попозже буду делать отдельный ассет для обратной отправки геометрии в маю

http://youtu.be/epMCNHSZPAM?hd=1


Рад помочь ) Интересный инструмент кстати! У нас вот например моделинг и анимация в мае, а рендеринг в гудини. Так вот в процессе работы над моделью, моделлер может быстро прыгать в гудини, одним кликом обновлять геометрию, и делать тестовый рендер например. Практично.
Удачи в разработке!
VUX
С удовольствием отдам когда оно будет иметь законченый вид.
Не былобы алембика - не былобы такой универсальности (курвы, нурбсы, поли, группы) и удобства.
VUX
гудини как IPR-render для маи smile.gif
http://youtu.be/dSLObcqmuvs?hd=1
VUX
Дабы не плодить тем задам еще вопрос здесь:

В моем otl находяться:
1. mayaGeometry - python sop
2. geometryToMaya - python sop
3. mayaScene - geometry subnetwork

Мне нада чтобы сопы 1 и 2 могли создаваться только в нетворках типа 3 и ни в каких других.
С вкладкой оператора tools все понятно - но это только для интерактивного создания. Как быть с ручным созданием нод в скриптах?
Zipper
Цитата(VUX @ 29/10/2012, 14:35) *
Дабы не плодить тем задам еще вопрос здесь:

В моем otl находяться:
1. mayaGeometry - python sop
2. geometryToMaya - python sop
3. mayaScene - geometry subnetwork

Мне нада чтобы сопы 1 и 2 могли создаваться только в нетворках типа 3 и ни в каких других.
С вкладкой оператора tools все понятно - но это только для интерактивного создания. Как быть с ручным созданием нод в скриптах?


1 и 2 - являются sop операторами, следовательно они нигде кроме как в sop контексте создаться никак не могут.
А вот чтобы определенные типы операторов могла создавать только в конкретных контекстах, нужно поэкспериментировать с $HDA_TABLE_AND_NAME.... В доках ничего не сказано про эти переменные, не совсем понятно с этим. Возможно правильнее будет опять-же проверять в нужном ли мы контексте, в скрипте, на момент создания ноды.
VUX
Цитата
1 и 2 - являются sop операторами, следовательно они нигде кроме как в sop контексте создаться никак не могут

єто я понимаю - субнетворк 3 тоже соп типа, но я хочу чтобы операторы(1,2) создавались только из под такого субнетворка

Цитата
Возможно правильнее будет опять-же проверять в нужном ли мы контексте, в скрипте, на момент создания ноды.

когда мы просто в скрипте создаем ноду, например hou.node('/obj/someGeometry').createNode('mayaGeometry') (не во вьювпорте или нетворкЕдиторе)
как в таком случае проверить что родитель создаваемой ноды имеет тип соп-нетворк (пункт 3) ?

может я просто много хочу? biggrin.gif
Zipper
Цитата(VUX @ 30/10/2012, 00:51) *
когда мы просто в скрипте создаем ноду, например hou.node('/obj/someGeometry').createNode('mayaGeometry') (не во вьювпорте или нетворкЕдиторе)
как в таком случае проверить что родитель создаваемой ноды имеет тип соп-нетворк (пункт 3) ?


Очень просто:
Например проверить, является ли родитель - соп оператором (например соп ассетом или сабнетом)
Код
n = hou.node('/obj/someGeometry')
parent = n.parent()
if parent.type().category() == hou.sopNodeTypeCategory():
    # Parent is SopNodeType....


Если нам нужно убедиться, что мы находимся внутри геометрического контейнера (например /obj/geo1), то:
Код
if parent.type().category() == hou.objNodeTypeCategory():
    # Parent is ObjNodeType


Можно еще длинным способом:
Код
hou.node('/obj/geo1/subnet1/box1').parent().type().category() == hou.nodeTypeCategories()['Sop']

Скажет нам о том, является ли родитель box1 типом SopNodeType.

Если у тебе нужно разрешить создавать только внутри mayaGeometry (предположу что это ассет разлоченный), то при создании ноды просто проверяем её имя.
Код
if parent.type().name() == 'mayaGeometry' :
    # Do something
VUX
я не правильно обяснил понятие создание в скрипте.
Меня интересовало то что вдруг ктото захочет создать у себя в скрипте ноду строкой hou.node('/obj/notMayaScene').createNode('mayaGeometry'). Она там создасться - но работать будет неправильно.
Думал что может гдето есть у ноды самопроверка (блокировка создание в соп-контексте отличном от типа mayaScene). Наверное такого нет.
VUX

Zipper
Прикольно )) Это кто в чём? Мая в гудини или наоборот? =)
VUX
Цитата(Zipper @ 25/01/2013, 19:48) *
Прикольно )) Это кто в чём? Мая в гудини или наоборот? =)


Это мая внутри в гудини и по максимуму контролируемая из него.

Принцип работы такой (если не вдаваться в подробности):

1. Создается глобальная нода в контексте /obj, управляющая сессией. Именно она запускает маю и держит скрытой (висящей).
2. Далее в геометрическом контексте можно создать mayaGeometry. Эта нода держит в себе редактируемые копии обектов.
То есть. В начале она пуста. Нажимаем E (Edit) -> Открывается мая (она уже открыта, просто окно спрятано), делаете в ней все что угодно с геометрией.
Оттуда (из маи) можно отправлять сколько угодно копий, редактируемой в данный момент, геометрии. Все они хранятся внутри, а слайдером (видно по картинке) можно быстро просматривать\редактировать\удалять\клонировать уже готовые копии.
Мая, может быть открыта "прикрепленной" к гудиньской панели - подстраивается под гудиньский вьювпорт, ну или в фулскрине.
Главное в этом подходе (то что я еще не видел в самописных коннекторах):
1. Нода mayaGeometry - управляет историей копий. Можно редактироватить копию, можно начать с пустой майской сцены, а можно и вход ноды (любую гудиньскую геометрию) отправить в маю. Все оно будет сохранено и вполне наглядно происходит процес многократной обработки геометрии.
2. Работаем в гудини при надобности нажимаем Edit и подредактирываем в мая. Мая как вспомагательный (по большой части моделинговый) пакет\плагин.

3. Еще есть нода mayaScene, которая привязывается именно к майской сцене. Но это уже нада видеть в процессе, например по видео, немного позже.
Zipper
Цитата(VUX @ 27/01/2013, 17:03) *
Цитата(Zipper @ 25/01/2013, 19:48) *
Прикольно )) Это кто в чём? Мая в гудини или наоборот? =)


Это мая внутри в гудини и по максимуму контролируемая из него.

Принцип работы такой (если не вдаваться в подробности):

1. Создается глобальная нода в контексте /obj, управляющая сессией. Именно она запускает маю и держит скрытой (висящей).
2. Далее в геометрическом контексте можно создать mayaGeometry. Эта нода держит в себе редактируемые копии обектов.
То есть. В начале она пуста. Нажимаем E (Edit) -> Открывается мая (она уже открыта, просто окно спрятано), делаете в ней все что угодно с геометрией.
Оттуда (из маи) можно отправлять сколько угодно копий, редактируемой в данный момент, геометрии. Все они хранятся внутри, а слайдером (видно по картинке) можно быстро просматривать\редактировать\удалять\клонировать уже готовые копии.
Мая, может быть открыта "прикрепленной" к гудиньской панели - подстраивается под гудиньский вьювпорт, ну или в фулскрине.
Главное в этом подходе (то что я еще не видел в самописных коннекторах):
1. Нода mayaGeometry - управляет историей копий. Можно редактироватить копию, можно начать с пустой майской сцены, а можно и вход ноды (любую гудиньскую геометрию) отправить в маю. Все оно будет сохранено и вполне наглядно происходит процес многократной обработки геометрии.
2. Работаем в гудини при надобности нажимаем Edit и подредактирываем в мая. Мая как вспомагательный (по большой части моделинговый) пакет\плагин.

3. Еще есть нода mayaScene, которая привязывается именно к майской сцене. Но это уже нада видеть в процессе, например по видео, немного позже.


D.gif
Прикольно! Вот это интеграция =)Жду видео.
VUX
Цитата(Zipper @ 27/01/2013, 22:59) *
D.gif
Прикольно! Вот это интеграция =)Жду видео.


Спасибо. Я долго к этому ишёл.
Уже довольно долго обрабатывал пару реально рабочих принципов построения пайплайна мая<>гудини.
Но чего то не хватало - какой то крепкой завязки одного над другим. Мучялся, думал, и вот оно, то что я ждал - мая работающая под руководством гудини, но в тоже время ничем не отличающаяся от стандартной рабочей маи и приносящая гудини огромную пользу со своей мощной стороны.
Именно поэтому все что я раньше писал на эту тему так и не вышло в свет - я просто искал чего то другого.
Точка заморозки главной идеи наконец то достигнута.
VUX
Придумал проще. Зачем лишние ноды. Нажатие хоткея всетаки проще, если смотреть вплане производительности например моделинга.
1. В гудини нажатие какого нибудь хоткея - например H - показывает такое:


2. Еще раз нажатие показывает такое:


Механизм упрощается до безобразия. Простое удобное перекидывание алембика туда-сюда.

Можно еще както так:
перекидывание геометрии при перемещении мышой с одного пакета в другой - если мая теряет фокус то в гудини автоматом отображаются изменения и наоборот. Или на двух мониторах - переход с одного на другой обновляет геометрию в программе которая под мышой.
VUX
Реализовал синхронизацию (экспорт) в сторону гудини - обратно в маю пока еще только в процессе.
http://youtu.be/JB0OaTe6mDc

Кстати, эти все майские инструменты, если пресмотрется polyExtrude, polyBevel и т.д. тоже хранятся внутри ассета. По сути все хранится в ассете. Ни одного файла, только otl-ка. А от пользователя только потребуется, первый раз при запуске ассета, указать путь к майскому exe-шнику. Ну и предполагается что в мае стоит PyQt.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2019 IPS, Inc.