You need to log in to create posts and topics.

Houdini HDA workflow disscusion (Nested HDA)

I am a big fun of Houdini HDA workflow. Right now I am trying to define a workflow from asset creation to set dressing, finished with the lookdev, lighting. Here is my thought below.

  1. Asset HDA, this can already be achieve by Prism, basically it is the mesh contains the texture and lookdev in a format of Geo level - HDA, with some exposed parm for lookdev/lighting later. For exmaple Rocks and Trees
  2. Setdressing HDA, essentially a container, with xfrom for each asset HDA, The idea for multiple set dressers work on the same set at the same time. for example, 1 person is working on zone A, while another is working on zone B. After using Prism to create container Geo level - HDA for each zone. Here we essentially nested asset HDAs into a container HDA, also at Geo level.
  3. Lookdev/lighting artist import all setdressing HDA, assemble them into the rendering scene via Prism. doing override and lighting/rendering setup.

Here is a problem : if Asset HDA at step 1 has been updated, for example an artist modified a rock, created a new definition of an existing HDA . The lookdev artist will have problem of getting the new rock in his scene, as this new definition of Rock HDA is nested inside Setdressing HDA at step 2, which it hasn't been installed in the Lookdev Houdini scene. In this case how do you resolve this issue ? You can resolve it by import every single asset HDA via Prism in the Houdini scene, but on a large scale scene, when a lot of asset HDA are invovled, its kind of hard to manage.

When the Asset HDA was updated, the Setdressing HDA would need to be updated, too so that the lookdev artist gets the new rock asset. To skip step 2 the artist in step one could overwrite the existing rock HDA with the new version. Then the lookdev artist would have the new rock without the need to update the setdressing HDA first.

A third way would be to have some kind of an HDA manager, which lists you all the currently used nested HDAs and also all previous and newer versions, so the lookdev artist could easily select which HDAs he want to use. That would be the most flexible way, but it would need some work to create a tool like that.

  1. The first one wouldn't work. Even you updated the Setdressing HDA. the lookdev scene wouldnt have the rock updated. because Rock HDA wouldn't have it installed in the current scene. The nested HDA default to version 1. Lookdev artist need to also import the rock HDA in the scene.

The third way is definitely the best. It's something that we have at work. I can try to develop something like that with you together. if you are point me the right direction first.  HDA manager could be a HDA itself at object level, with list of HDA in the scene.

1. I just played around with nested HDAs. It seems like Houdini stores the path to the nested HDAs, but only installs them automatically when the asset type doesn't exist. So you're right, that wouldn't work.

Quick example in case someone else can't follow: Setdressing v1 contains rock v1 and setdressing v2 contains rock2. When setdressing v2 gets installed in a new lookdev scene, Houdini installs rock v2 automatically. When setdressing v1 gets installed, rock v1 will be installed. If setdressing v1 is installed already and setdressing v2 gets installed, Houdini won't install rock v2. Setdressing v2 contains rock v1 then.

After a quick look I couldn't find any Houdini settings that would change that behavior.

It would be great if we would develop a good HDA manager for Prism. I would make it as a separate window like the Houdini Asset Manager, but that's just personal preference. A node would also work fine. I could imagine it as a treeview. The top level items would be the HDAs, that are installed through the State Manager. All nested HDAs are childitems in the treeview. In a second column there would be a dropdown to select the version for all the nested HDAs (only a very first idea)

And also what do you think of changing the HDA naming convention to the standard name space and versioning for example :

[namespace::]node_name[::version].

http://www.sidefx.com/docs/houdini/assets/namespaces.html

That's a good point. I think Prism should use that convention as it keeps the assets more organized. The only little problem I see is that if you install v0002 of an asset in your scene, the existing assets in your scene stay at version v0001. You (or Prism maybe) would have to go through all nodes in the scene and manually update all instances of that asset to the latest definition. In this case an HDA manager would be handy again, which shows you all instances of an asset in the scene with the option to select which definition version you want to use on that instance.

Sure. Isn't that a problem with the current setup anyway ? Prism will notify the user there is a latest version of HDA you can update it if you want to.

Yes HDA manager would help again.

To be honest I'd rather to have Houdini scene always use the latest by default anyway. so maybe we can force it at initiallization to scan HDA and force latest, when open a scene or something. Thought ?

No at the moment you don't have this problem. When you update an asset in the State Manager, Prism will install the updated asset and because the asset name is the same as the previous version of the asset, Houdini will automatically use the updated asset for all existing instances in the scene. So currently you don't need to change the definition of the existing asset instances manually.

When there is a tool in Prism for managing HDAs it will have enough options to handle the HDA workflow in the preferred way of the user, since different users can have different preferences, which are all valid ways of doing it.