Hello all,

I was wondering what the options are for proper versioning of custom tools in houdini. Let say I create a great tool called color_v1, this is working great and everybody uses it. Some minor changes are made, that dont break backward compatibility and the file is saved over itself all the time.

Now a big change is needed and we come up with color_v2, that provides all the functionality in v1 but much more. However, if we would to overwrite v1 with the new version and load an old scene it would be broken, for that reason, we keep v1 around.

New scenes I only want to use v2. One situation I am trying to avoid is that after 3 years on a show, we have color_v1,2,3,4,5 etc all show up in the tab menu, that becomes very messy.

My first idea is to give them all the same label (color) but different names, so houdini will know the difference when loading old files, the user wont. The only problem I have now that there are 5 entries called color in my menus.

is there an easy way to “flag” an otl not to show itself (I'd prefer not to parse all the otls in on startup and use ophide)?

Also more in general, would there be a better approach to this? And on a related note, are there tools and or rules to determine at what point an hda looses backwards compatibility? I guess sidefx tests most changes before releasing a new build?

Any ideas are appreciated.

Cheers,
Koen

is there an easy way to “flag” an otl not to show itself (I'd prefer not to parse all the otls in on startup and use ophide)?

All entries in the TAB menu are shelf tools. You can edit the tool's context settings to remove the tool from the TAB menu. Usually HDAs carry own tool in their Tools section (editable in the Type Properties).

A more drastic option is to delete the tools for old versions altogether. That's because some user may have actually put such tools on some of their shelves, and editing the tool context won't remove such tools from the user's own shelves.

Sometimes, the HDAs are build so that they don't carry their instantiating tools at all. Instead, the tools are explicitly provided in separate .shelf files. In this case, you could modify the single tool in such .shelf file to instantiate the newest version of your HDA.

For more info you can check shelf tools reference pages in Houdini help, but there is also a technical paper on HDAs and shelf tools that has some useful tips (including versioning):
http://www.sidefx.com/index.php?option=com_content&task=view&id=966&Itemid=132 [sidefx.com]

Hello Rafal,

Thanks for the reply. For us, removing old hda's is not really an option, but I like the idea a lot of splitting the tool creation from the hda definition. This will allow us to expose what is available to the user, without limiting what is available to houdini.

Cheers,
Koen

removing old hda's is not really an option

removing the shelf tool from an old HDA does not delete the HDA. The HDA (operator definition) will still exist and you can instantiate it, for example in textport with “opadd tbl/opname”. It's just that the shelf tool that used to do the instantiation will no longer be available on the shelf or in the TAB menu.

But splitting tool script from HDA definition is indeed less maintenance, since you just need to worry about one tool, rather than a few versions of the same tool (that come with different version of the HDA).

oh, and to automatically generate a default tool for an HDA, you can check out
createDefaultNodeTypeTools() and other related functions
in cd $HH/scripts/python/defaulttools.py

Hello Rafal,

Thanks for the reply. The “createDefaultNodeTools()” seems very useful. Yes I think I want to come up with a nice system to have the tool definition live separate from the otl. As you say, that way w can have all the otls around we want, and still keep the gui nice and clean for the user.

Am I correct in thinking that this is also now how most of the default houdini tools are installed (for example the only definition of the “box” sop is in the tool installed on the shelf, not as a section on the otl?)

I have a feeling we can create a great way to manage custom tools using these options/

Thanks,
Koen

Hi All:

These are the exact same questions and issues that we had at R+H for some time. We ended up building an internal system (RHDA System) that essentially functions like cvs to check in and check out our tools. The major hurdle was in defining the concepts of major and minor revisions. Here's how we define those.

Major Revision - It is a Major Revision if the digital asset is no longer backwards compatible. This includes fundamental changes in the architecture of the tool or it's use. Major revisions are also made when redefining an asset, sourcing across shows, and developing for a new major release of Houdini. When creating a Major Revision, a new operator type is created. As such, Major Revisions are not immediately imposed on users. Rather, users need to Change Type in order to get them. This is to protect them from updates that are not backwards compatible.

Minor Revision - It is a Minor Revision if the digital asset is backward compatible because the changes are nominal. This includes non-destructive changes to the tool such as bug fixes, new functionality, and parameters. Be aware that when Minor Revisions are made, those changes become immediately distributed to the show. As such, it is advisable to publish Minor Revisions early in the day wherever possible, so you can revert changes if bugs are found.

So, minor revisions are automatically propagated. Major revisions require a conscious change. We also have a quick reversion scheme that allow us to revert to a minor revision through our RHDA interface.

Lastly, you can use the OPmenu script to ophide major revisions from the tab menu. We opted to make our system non-destructive, so we don't delete any assets. This is so that an old file can be opened without any errors.

We've thought these issues through pretty deeply here at R+H and have come up with a robust and easy to use system. It took us a lot of work, but the benefits have been enormous. I would encourage SESI to create a similar system within the Houdini architecture, since this issue comes up a lot.

Am I correct in thinking that this is also now how most of the default houdini tools are installed (for example the only definition of the “box” sop is in the tool installed on the shelf, not as a section on the otl?)

Yup, you are totally correct. Pretty much all HDAs that ship with Houdini have their instantiating shelf tool defined separately in .shelf files (eg, ObjectTools.shelf). These .shelf files are automatically generated using the same createDefaultNodeTypeTools() I mentioned earlier. Our main reasoning was that if we decide to change the generic default shelf tool script, it is going to be easier, if all such tools were automatically generated.

There are also a few special hand-edited shelf tools in ExtraShelfTools.shelf which instantiate some of the shipped HDAs. But Houdini loads them on startup and knows not to automatically generate any default tools if there is already there (eg, sop_clip, which also sets up some parameters on the created node).

However, storing the shelf tool with an HDA (as a section), is also correct; though it may be more maintenance for multi-version assets. After all, all newly created HDA definitions generate their default tools and save them in their section. Then, such HDA can be distributed around together with its tool.