Houdini digital asset workflow ?

#1 · 30. December 2018, 12:05

Hi,

I was wondering what is the correct workflow for houdini digital asset and prism ?

to create a digital asset on houdini, we need to first specify a library location, doing so, you loose the purpose of prism to manage asset itself.

do prism can actually handle the asset creation itself ? I tried to export a subnetwork using prism job in the .hda format but I get a segmentation fault from houdini and crash without any log.

#2 · 7. January 2019, 21:55

Sorry for the late reply, but now I'm finally back from the holidays.

Prism deals with HDAs in two situations. The first one is in the StateManager. You can export subnets as hda files with the export state and import them then in other scenes. Prism handles them similar like other exported files. You were right, there was a bug in the current Prism version when exporting .hda files, but I just fixed it on github so it should work now.

The second situation where Prism deals with hda files is when Prism starts or the Prism project changes. Then Prism looks in the project HDA folder and installs all .hda files in there. The project hda folder is this one: \04_Assets\HDAs in your Prism project. This folder doesn't get created by default so you need to create it manually. These hdas are only available in Houdini when the Prism project is the active one. If you change the Prism project, the project HDAs of the old project get uninstalled when you open the new project.

When I have finished tools from previous projects or downloaded from the internet I place them in the project hda folder, so every artist in the project has access to them immediately. When I have a rig or a tool, which gets developed and versionized I would export it through the StateManager so Prism takes care of the versioning.

#3 · 7. January 2019, 23:52

I see, that funny because I was actually putting my HDA into "04_Assets\Houdini" , was pretty close.

I'll give a try with the new version you fixed, thanks !

#4 · 7. January 2019, 23:59

Mh probably I should create the folder by default. I didn't do it because not everyone who uses Prism uses Houdini. But it's better to have an empty folder, which not everyone needs than having a hidden feature which no one knows it exists.

#5 · 9. February 2019, 16:09

Hi, sorry to resurect this after a while, I haven't tried to export a subnetwork since then using the state manager.

so, I wanted to know if that would be possible for prism to deal with digital asset differently than the rest of the DCC app.

houdini come with a powerfull Digital Asset system that lets you synchronised an asset on every scene, letting you also do modification on that asset from anywhere and keep that updated.

with prism, if you want to export a subnetwork using the export state, it create a offline file and that basically remove the power of a digital asset.

second solution is to export digital asset in the 04_workflow/Hdas, but then, you defeat the purpose of prism as a pipeline manager, and you end up stacking pile of library into a single folder.

what I would like to propose is that prism would manage digital asset versionning, when you export a subnetwork or a digital asset, prism will save the subnetwork/digital asset as a digital asset. keeping the feature of houdini to edit that asset at any time.

there come the question then : prism don't handle the asset version anymore right ?

that where it could actually shine : exporting the asset again would create a new version of that digital asset (using namespace or asset versionning).

this way, the user would be able to do minor update to a digital asset no matter where is it on the pipeline, and if a 'bigger' update is required, he would have to export a new state from the original scene.

I understand that for some pipeline, modifying an HDA from another scene is not recommended, mostly in studio environement, but prism is also a tool that can be used by freelanced and single artist like me, removing certain feature like editing digital asset is a real bummer, having to return to the original scene, make the update, and exporting the hda again just remove a big part of what make houdini awesome.

#6 · 10. February 2019, 15:09

Quote from SciMunk on 9. February 2019, 16:09

with prism, if you want to export a subnetwork using the export state, it create a offline file and that basically remove the power of a digital asset.

...

what I would like to propose is that prism would manage digital asset versionning, when you export a subnetwork or a digital asset, prism will save the subnetwork/digital asset as a digital asset. keeping the feature of houdini to edit that asset at any time.

Not sure if I understand you here. What do you mean with offline file? If you have a subnet and you set the Export State type to ".hda" you can connect the subnet with the export state. This will create a .hda file during the publish. If you create an import state and import the .hda file with Prism it will be installed and you can modify the hda from any location.

The only problem I see at the moment is that the subnet is is saved as a hda, but it's not converted to a digital asset in the current scene. So to edit the type properties of that hda you need to import it, change the type properties and save the node type. I'll have a look if that can be changed.

Also the second question about asset versioning isn't really clear to me. Do you mean to have the option to save multiple versions of the asset definition inside the same .hda file instead of creating a new .hda file on every publish? Maybe you can give an example.

I agree that it's up to the end user how they want to handle hda modifications. Prism won't force a restrictive workflow for that.

#7 · 13. February 2019, 13:06

Quote from SciMunk on 13. February 2019, 13:06
I'll try to explain.

the way prism currently handle HDA is by saving a snapshot of the subnetwork that we export using the export state, this hda have no relation with the original subnetwork that have been exported. When you import this prism state on on another scene, you import a basic subnetwork that cannot be updated dynamically using houdini digital asset feature. For that, you have to go back to the original scene, update the original subnetwork, and export it again as a new version.

What I propose is take advantage of both prism and digital asset this way :

when the user want to export a subnetwork (or DigitalAsset) for the first time using prism export state, prism will convert the subnetwork into a digital asset and save it using the default prism path. If the subnetwork is already a digital asset, then change the library location to prism path.

when you import this state onto a new scene, prism will 'Install' that library like would do an user to install a digital asset.

this way, the imported digital asset can be edited from the target scene and update any instance of it in any other scene, the houdini way, no problem here.

now say the digital asset need to have a major update of it internal, the correct workflow would be to create a new version of the asset by using houdini versioning or namespace.

this is where I see 2 solution for that :

either the asset maker must go back to the original scene containing the export state for the digital asset, update the internal of the asset, and then use prism export state to create a new version of the asset (in the same .hda), this will avoid breaking any scene containing the older version of the asset that cannot be updated because it could potentially broke the scene.
on target scene that curently use the asset the 'import state' can now be used to update the asset to last version, or to keep it where is it if the artist don't want to break anything.

second way is that the import state is also capable of acting as an export state for digital asset; meaning that it don't matter where the digital asset have been created, if it is loaded in houdini, prism can export a new version of that digital asset like in the first solution.
that would give a seamless integration of houdini for prism that give enough freedom for artist/studio to decide of their workflow

some small feature that could be added on a prism export state for digital asset:

blackbox the digital asset : using houdini blackbox feature, prevent any user that will import the digital asset from modifying the asset, so only the original scene/artist has the capability to update it.

put the asset in 04_workflow/HDAs : if an asset gonna be used extensively as part of a studio/artist pipeline, make this asset accessible at anytime.

hope all of this was clear enough!

I'll try to explain.

the way prism currently handle HDA is by saving a snapshot of the subnetwork that we export using the export state, this hda have no relation with the original subnetwork that have been exported. When you import this prism state on on another scene, you import a basic subnetwork that cannot be updated dynamically using houdini digital asset feature. For that, you have to go back to the original scene, update the original subnetwork, and export it again as a new version.

What I propose is take advantage of both prism and digital asset this way :

when the user want to export a subnetwork (or DigitalAsset) for the first time using prism export state, prism will convert the subnetwork into a digital asset and save it using the default prism path. If the subnetwork is already a digital asset, then change the library location to prism path.

when you import this state onto a new scene, prism will 'Install' that library like would do an user to install a digital asset.

this way, the imported digital asset can be edited from the target scene and update any instance of it in any other scene, the houdini way, no problem here.

now say the digital asset need to have a major update of it internal, the correct workflow would be to create a new version of the asset by using houdini versioning or namespace.

this is where I see 2 solution for that :

either the asset maker must go back to the original scene containing the export state for the digital asset, update the internal of the asset, and then use prism export state to create a new version of the asset (in the same .hda), this will avoid breaking any scene containing the older version of the asset that cannot be updated because it could potentially broke the scene.
on target scene that curently use the asset the 'import state' can now be used to update the asset to last version, or to keep it where is it if the artist don't want to break anything.
second way is that the import state is also capable of acting as an export state for digital asset; meaning that it don't matter where the digital asset have been created, if it is loaded in houdini, prism can export a new version of that digital asset like in the first solution.
that would give a seamless integration of houdini for prism that give enough freedom for artist/studio to decide of their workflow

some small feature that could be added on a prism export state for digital asset:

blackbox the digital asset : using houdini blackbox feature, prevent any user that will import the digital asset from modifying the asset, so only the original scene/artist has the capability to update it.
put the asset in 04_workflow/HDAs : if an asset gonna be used extensively as part of a studio/artist pipeline, make this asset accessible at anytime.

hope all of this was clear enough!

#8 · 14. February 2019, 0:31

Quote from RichardF on 14. February 2019, 0:31
Yeah, it's all clear now.

You are right, that the original subnet had no connection to the created .hda file. I changed that a few days ago. Now the source subnet gets converted to a hda in the source scene, so it is connected to the new .hda file and you can edit it also from any target scenes. So that point is already done.

Once a subnet is converted to an hda it is not possible to tell whats the source scene of that hda. So I need to add the option to connect existing hdas to an export state and export them as a new version. Then it doesn't matter if it's the source scene or if it was imported into another scene and connected to an export state there.

To your point 1:

I would add an checkbox to the export state, when a hda is connected, which lets the artist choose if they want to save the new version to the same hda file or to a new one. That way every team has the most flexibility how they want to structure their hda workflow.

Currently the import state installs hdas, but it doesn't keep track of the instances of that hda in the current scene. After the import state imported/installed an hda the artist can create instances of that hda manually in the nodeview. Maybe the artist wants to have multiple instances but from different versions of that hda. That would be a bigger feature if the import state should manage all the different versions of all instances in the scene.

To your point 2:

I won't add an export button on the import state because it would be too confusing. What would be possible is a "create export state for loaded hda" button on the import state. But that would be the same as if you would create an import state to load an hda, create an instance in the node view, create an export state and connect that instance to that state. I don't think it's really necessary to add a button for that on the import state.

The blackbox and project hda points are good ideas for options on the hda export state. I guess you mean 04_Assets/HDAs

Yeah, it's all clear now.

You are right, that the original subnet had no connection to the created .hda file. I changed that a few days ago. Now the source subnet gets converted to a hda in the source scene, so it is connected to the new .hda file and you can edit it also from any target scenes. So that point is already done.

Once a subnet is converted to an hda it is not possible to tell whats the source scene of that hda. So I need to add the option to connect existing hdas to an export state and export them as a new version. Then it doesn't matter if it's the source scene or if it was imported into another scene and connected to an export state there.

To your point 1:

I would add an checkbox to the export state, when a hda is connected, which lets the artist choose if they want to save the new version to the same hda file or to a new one. That way every team has the most flexibility how they want to structure their hda workflow.

Currently the import state installs hdas, but it doesn't keep track of the instances of that hda in the current scene. After the import state imported/installed an hda the artist can create instances of that hda manually in the nodeview. Maybe the artist wants to have multiple instances but from different versions of that hda. That would be a bigger feature if the import state should manage all the different versions of all instances in the scene.

To your point 2:

I won't add an export button on the import state because it would be too confusing. What would be possible is a "create export state for loaded hda" button on the import state. But that would be the same as if you would create an import state to load an hda, create an instance in the node view, create an export state and connect that instance to that state. I don't think it's really necessary to add a button for that on the import state.

The blackbox and project hda points are good ideas for options on the hda export state. I guess you mean 04_Assets/HDAs

#9 · 17. February 2019, 14:02

Quote from RichardF on 17. February 2019, 14:02
Soo, I just updated Prism. It has a powerful and flexible HDA workflow now and I think I addressed all your points. You can use the automatic update function in Prism to try it out. Let me know if there are still things, which could be improved.

Here is a description of the new HDA workflow in Prism:

Creating new HDAs
- All nodes, which can be saved as an HDA (usually subnets) can be connected to a Prism export state
- During the publish of the State Manager a new .hda file gets created in the usual Prism export folder structure
- The subnet gets converted to the HDA type
- The taskname of the export state is used as the name of the HDA definition

Updating existing HDAs:
- To overwrite an existing HDA definition use the "Save Node Type" option in the context menu of a HDA instances
- To create a new HDA definition based on an existing HDA you can connect HDA instances to a Prism export state
- During the publish a new .hda file gets created with an incremented version
- The new HDA definition name is the same as the name of the connected HDA
- The taskname of the state is only used for the folder structure of the new .hda file

Saving a new definition in an existing .hda file:
- On the export state there is an option to save a new HDA definition to an existing .hda file
- This option is only available if a HDA instance is connected to the export state and not a subnet
- During the publish no new file gets created
- A new asset definition gets created in the .hda file of the connected HDA instance
- The name of the new HDA definition is the same as the name of the connected HDA appended with a version number ("_1", "_2", ...)

Importing HDAs:
- HDAs can be imported with an ImportFile state in the State Manager
- This will install all HDA definitions in the selected .hda file
- New instances of the installed HDA can be created like usual nodes in the node graph
- Alternatively the "Create Node" button on the import state creates a new instance, when the current node graph is in the correct context for the HDA

Updating imported HDAs:
- To update an HDA, which was saved to a new file, browse the import state to the new version to install it
- The new HDA version gets set as the current definition, which will update all instances of that HDA in the current scene to the new version
- The previous HDA version is still installed. You can switch between different versions by selecting a different version:
1. in the import state in the Prism State Manager
2. in the Houdini Asset Manager
3. from the Asset Bar in the Parameters pane (if enabled in the Asset Manager configuration)
- If an updated version was saved into the same HDA, use the context menu of the HDA nodes to change the node type to the new definition ("Actions -> Change Type...")
- No update on the import state is required in that case

Project HDAs:
- An option on the export state lets you save the HDA in the project HDA folder instead of the usual export structure
- The default location is "/04_Assets/HDAs" in the current Prism project
- Project HDAs are installed immediately after export and during startup, when you launch Houdini. No need to import them in the State Manager.

Blackboxes:
- HDAs can be saved as Blackboxes when the option on the export state is checked
- This will create HDAs, which cannot be edited and the content cannot be viewed
- A Blackbox HDA cannot be saved or converted back to an editable HDA
- When you export a subnet as a Blackbox, the subnet won't be converted to the new Blackbox HDA, it stays editable.
- When you export a HDA as a Blackbox, the new definition will be set as the current definition. Set the previous definition as the current one to access the HDA contents

Soo, I just updated Prism. It has a powerful and flexible HDA workflow now and I think I addressed all your points. You can use the automatic update function in Prism to try it out. Let me know if there are still things, which could be improved.

Here is a description of the new HDA workflow in Prism:

Creating new HDAs
- All nodes, which can be saved as an HDA (usually subnets) can be connected to a Prism export state
- During the publish of the State Manager a new .hda file gets created in the usual Prism export folder structure
- The subnet gets converted to the HDA type
- The taskname of the export state is used as the name of the HDA definition

Updating existing HDAs:
- To overwrite an existing HDA definition use the "Save Node Type" option in the context menu of a HDA instances
- To create a new HDA definition based on an existing HDA you can connect HDA instances to a Prism export state
- During the publish a new .hda file gets created with an incremented version
- The new HDA definition name is the same as the name of the connected HDA
- The taskname of the state is only used for the folder structure of the new .hda file

Saving a new definition in an existing .hda file:
- On the export state there is an option to save a new HDA definition to an existing .hda file
- This option is only available if a HDA instance is connected to the export state and not a subnet
- During the publish no new file gets created
- A new asset definition gets created in the .hda file of the connected HDA instance
- The name of the new HDA definition is the same as the name of the connected HDA appended with a version number ("_1", "_2", ...)

Importing HDAs:
- HDAs can be imported with an ImportFile state in the State Manager
- This will install all HDA definitions in the selected .hda file
- New instances of the installed HDA can be created like usual nodes in the node graph
- Alternatively the "Create Node" button on the import state creates a new instance, when the current node graph is in the correct context for the HDA

Updating imported HDAs:
- To update an HDA, which was saved to a new file, browse the import state to the new version to install it
- The new HDA version gets set as the current definition, which will update all instances of that HDA in the current scene to the new version
- The previous HDA version is still installed. You can switch between different versions by selecting a different version:
1. in the import state in the Prism State Manager
2. in the Houdini Asset Manager
3. from the Asset Bar in the Parameters pane (if enabled in the Asset Manager configuration)
- If an updated version was saved into the same HDA, use the context menu of the HDA nodes to change the node type to the new definition ("Actions -> Change Type...")
- No update on the import state is required in that case

Project HDAs:
- An option on the export state lets you save the HDA in the project HDA folder instead of the usual export structure
- The default location is "/04_Assets/HDAs" in the current Prism project
- Project HDAs are installed immediately after export and during startup, when you launch Houdini. No need to import them in the State Manager.

Blackboxes:
- HDAs can be saved as Blackboxes when the option on the export state is checked
- This will create HDAs, which cannot be edited and the content cannot be viewed
- A Blackbox HDA cannot be saved or converted back to an editable HDA
- When you export a subnet as a Blackbox, the subnet won't be converted to the new Blackbox HDA, it stays editable.
- When you export a HDA as a Blackbox, the new definition will be set as the current definition. Set the previous definition as the current one to access the HDA contents

#10 · 17. February 2019, 18:01

Hi!

Damn that was a quick update!

I did some experiment with the export task, everything work great overall! I'll try convert most of my current asset using the export manager to do more test.

the only thing I noticed is that updating an HDA using the 'change type' method make the node forget about the content of any editable subnetwork located inside the HDA, where using prism 'import new version' using multiple .hda file work cleanly. that probably more a houdini concern, but maybe there is a way to make both behavior work the same ?

Another point, I'm not totally sure if this is by design :

Creating a new export state on an HDA that was imported using the import State, and executing that HDA create a new .hda where the scene/taskname is located in the project instead of the original HDA location. Maybe a checkbox could propose the user to save the file under the orignal path of the imported HDA ?

Thanks for doing this functionnality so fast !

Join our discord community

Houdini digital asset workflow ?