Houdini Integration - Create Setup #7 #12
Conversation
Issue #7 POC create_setup() for the Houdini integration. Needs discussion about: - code formatting L7-L54 - node type for the conduct node L20 - file_name L53
Airyzz
left a comment
Airyzz
left a comment
There was a problem hiding this comment.
Looking pretty good so far, thanks!
integration/houdini/scripts/python/ConductPlugin/select_project.py
Outdated
Show resolved
Hide resolved
integration/houdini/scripts/python/ConductPlugin/select_project.py
Outdated
Show resolved
Hide resolved
Devostated
force-pushed
the
hoduiniIntegration
branch
from
e97ee78 to
d682340
Compare
Issue #7 POC create_setup() for the Houdini integration. - select project now available through node and menu bar - load asset(s) shows in the menu after a project was selected - error handling - custom conduct node
Devostated
force-pushed
the
hoduiniIntegration
branch
from
d682340 to
4ea6e1e
Compare
There was a problem hiding this comment.
can you unpack this hda to text format?
There was a problem hiding this comment.
There is an issue with the limited commercial version:
Cannot convert non-commercial HDAs
I still get an output. Here is the download.
LAGMACHINE.Conduct.zip
Repacking says:
Error collapsing library from: LAGMACHINE.Conduct
There was a problem hiding this comment.
fucking proprietary software... looking at the contents of the zip file you provided, I think the node was still successfully unpacked. I can see your OnCreated, OnDeleted scripts and the parms:
LAGMACHINE.Conduct/LAGMACHINE_8_8Object_1Conduct/OnCreated
hou.hscript("ophide Object LAGMACHINE::Conduct")
node = kwargs['node']
try:
node.setName("Conduct")
except:
hou.ui.displayMessage("A Conduct node already exists.", severity=hou.severityType.Message)
Houdini should be able to load the hda directly from unpacked state, so converting back to packed format shouldn't be necessary. Could you see if you can load without converting? if so I think we can go ahead with this
| pSelectedParm: hou.Parm = data_node.parm("project_selected") | ||
| pSelectedParm.set(True) | ||
|
|
||
| projectParm: hou.Parm = data_node.parm("project") |
There was a problem hiding this comment.
I dont think we need to store this, and if we did it would only be a valid path for the person who initially did this. If i opened the project on a machine where the project is stored elsewhere, it wouldn't be accurate anymore
There was a problem hiding this comment.
I agree on the project path.
The pSelected is a check to hide the Select Project button in the Conduct node. I could try taking a different approach, but not sure how worth that it would be.
There was a problem hiding this comment.
maybe could just check if the the current file is saved, if you feel like it also could check that its saved to a valid project location - doing so would have some extra io calls so im not sure if there would be a performance impact.
Generally I would prefer to avoid hidden parms like this where possible, it can be prone to adding weird behaviour
There was a problem hiding this comment.
In my opinion is setUserData() probably the best approach, as you mentioned in the original issue.
There was a problem hiding this comment.
maybe, for me I prefer to store as little information as possible, and to derive this kind of state from elsewhere - the way I see it the more state you are storing, the more chances there are to end up in weird invalid states
There was a problem hiding this comment.
question: is it possible to set this up as two menu items, where each one hides itself by some expression when it shouldn't be available, instead of as one menu item which switches between two states?
There was a problem hiding this comment.
or not necessarily hidden, but im pretty sure there is a way for menu items to be disabled/grayed out based on an expression, which would be preferable i think - it might be more intuitive for me to try and implement it this way in blender too...
There was a problem hiding this comment.
It was definitely the easiest solution instead of having two entries that hide.
But greying out should be easy, assuming there is a native way to grey them out, which Im really confident about.
There was a problem hiding this comment.
Update: I have no idea how to do that.
The only menu item I found that has such feature was the redo/undo function.
It uses following for that:
<menuStripDynamic id="undo_strip">
<value>undo.menu</value>
</menuStripDynamic>No idea where undo.menu is coming from.
Another Menu had , but I didn't manage to get it working, it always told me that it's an unknown command.
While writing this I found following:
"It is not currently possible to dynamically enable and disable user-defined menus/items."
https://www.sidefx.com/docs/houdini/basics/config_menus.html#menu-items
I'm not sure if that is just the top level item in the menu bar or also it's scriptItems
There was a problem hiding this comment.
I could still split that into two <scriptItems> and use an <expression> to en-/disable them accordingly, if you would prefer that.
There was a problem hiding this comment.
ah thats a shame... I think splitting them in to two menus will be less prone to bugs. I can see a scenario where the two expressions for controlling the text and the logic for the single menu become out of sync and lead to unexpected behaviour
There was a problem hiding this comment.
I don't know, it's not much stored. Department, Asset, Shot and if it's imported. Could also just do a check if department exists. Usually try to avoid working with strings as much as possible, that's why I didn't like the idea of hardcoding the conduct node path.
Issue #7
POC create_setup() for the Houdini integration.
Needs discussion about: