Please or Register to create posts and topics.

Houdini HDA Management

Hello Richard,

I noticed an option in the state manager to save a new definition in an existing HDA, and weirdly it does not seems to work for me. What is it supposed to be ?

We currently also have issues when we use nested HDAs (HDA in HDA, such as an asset HDA in a setdressing HDA), I recorded a video to show you the issue here : https://vimeo.com/461734243

Have you thought about using the namespaces to save a new version of the same HDA ? It would be really interesting to be able to switch the versions of an HDA from the state manager. For now we can change the HDA file itself but not the version of an HDA, and I'm not sure that it is how SideFX thought about it, and it causing some issues for us as shown in the video.

This link is really useful regarding HDA and their management : https://jurajtomori.wordpress.com/2018/07/02/houdini-tip-assets-versioning-workflow/

Tell me if I can be of any help !

Thanks,

ValDo

EDIT 1 : Adding a small video to explain the issue

Hey @valdomenhirfx,

sorry that it took a while to reply. Big thanks for the video, that makes the problem obvious to understand.

After looking into this I decided to rewrite most of the HDA related code in Prism.

Now in v1.3.0.32 there is an "Install HDA" and "Save HDA" state in the State Manager. The "ImportFile" and "Export" state are still supporting HDAs, but that will be removed in the future.

The default versioning of HDAs is using the namespace version as you mentioned and recommended in the SideFX docs. That should solve many issues.

There are still some things that might need improvement, but I wanted to give you the option to test the current implementation. Consider it as WIP, but have a look if it solves your issues or if you have some feedback.

BTW, finally it's possible to delete states with the "delete" key 😉

 

@magnus FYI the above. And some more technical details for you:

You can create Prism HDAs now easily through Python. First you can generate an outputpath like this:

import hou
from PrismInit import pcore

node = hou.node("/obj/subnet1")
pathData = pcore.appPlugin.getHDAOutputpath(node=node, task="rig")
path = pathData["outputPath"]

The path depends on the location of your current scenefile in the Prism project. Then you can use this path to create an HDA, but obviously you can also use any other custom path:

pcore.appPlugin.createHDA(node=node, outputPath=path, typeName="asset_char_rig", convertNode=True)

The new Save HDA state uses these both functions with different arguments to save HDAs from the State Manager.

These are all the possible arguments for the getHDAOutputpath() function with their defaults:

node=None,
task="",
comment="",
user=None,
version="next",
location="global",
saveToExistingHDA=True,
projectHDA=False

And these are the possible arguments for the createHDA() function:

node,
outputPath="",
typeName="prism_hda",
label=None,
saveToExistingHDA=False,
incrementVersion=True,
blackBox=False,
allowExternalReferences=False,
projectHDA=False,
setDefinitionCurrent=True,
convertNode=False

That should give you even a more options than you'd have through the State Manager at the moment. Feel free to ask if something is missing or you'd like more examples.

Hello Richard !

First of all, thank you so much for taking care of this issue, it will enable us to be way more efficient whilst we work in Houdini !

I recorded a video to explain you a "small" behavior that could be easier to understand, let me know what you think about it :

https://vimeo.com/466475886

The part where the HDA is not connected anymore might be because I switched the version manually, so it might not be important at all 🙂

Again, thank you so much !

Hey ValDo,

I fixed the error on update and the disconnecting HDA.

Also I added a namespace prefix to the operator type name to keep the HDAs separate from the default assets and other tools. The default prefix is "prism", but it can be changed or removed by setting it to "" in the project config.

And I made a change to the versioning: The operator type version is now in sync with the filepath version. So every time you publish a new HDA it will be saved as a new .hda file under a new version and also the operator type version gets incremented. I removed the "Save new HDA version in existing HDA" option from the state. This makes it clear now which version is available when you install an HDA through the State Manager.

There is still the open question how existing nodes in your scene should behave. Currently existing nodes keep their operator type version when you install a new HDA version through the State Manager.

I could automatically update all node instances to the new version or simply uninstall the old HDA version. But that sounds a bit risky if in some cases you want to keep some assets on the old version.

Maybe I could add a button on the InstallHDA node to update all existing instances or even better show a dialog with a list of all instances in the scene and their version so you can decide which one you want to update.

Which workflow would you prefer?

Hello Richard !

It's so good to see that ! It will enable us to be so effective !

I could automatically update all node instances to the new version or simply uninstall the old HDA version

I think that updating all node instances to the new version could be great, so if a user need to go back to an old version he can use the operator drop down menu on a specific node, what do you think about that ?

Maybe I could add a button on the InstallHDA node to update all existing instances or even better show a dialog with a list of all instances in the scene and their version so you can decide which one you want to update.

I understand what you think about, but I'm not sure if it is the best path. I think that if an update is pushed by another dept, the artist know that he has to pick it up, if he/she has a good reason not to update it, he/she will wait to use the lastest version. If needed, the artist can always roll back to a previous version for all the instances (using the version selection of the state manager) or for a specific node using the operator drop down menu.

What do you think about that ?

Yeah I agree, for most cases that would be the preferred behavior.

I changed that in v1.3.0.36 so that all instances get updated to the newly installed version. If there is the need for it I can add additional options in the future to not update all existing instances.