Introduction

Threw this page we will see what you should look into when creating OTL/HDA tools.

Evaluate the need

Before starting any HDA, check if no other tool does similar operation and if those other tools could be improved to achieve what you want.

Naming

A tool name should be descriptive of what the tool can do. Users usually remembers of nodes by what to do with them. For new users, it will intuitively tell them what they could do with it. To be descriptive, the name should start with a verb (ex: split_faces, prepare_cloth_for_simulation) or be a Noun (ex: Face Splitter).

The name should be easily understandable by everyone. That's why its advise to avoid abbreviation or made up name.

Avoid using the same name as an other HDA.

Functionality

Create HDA should be re-usable by other users, in other shows and setup. If your tool can only be used in really specific situation, consider just making a Template or a simple sub-network. If your setup is only composed of a single node, look into making a Preset.

Simple HDA are easier to use in other places. It is better to do one operation very well than multiple average one.

If you cannot describe your HDA in a single simple sentence, it must certainly be too complicated.

Easy to use HDA have more chance to be used by others. Avoid complicated inputs requirement such as specific attributes on input geometries.

Cleanup the HDA content by removing any unused nodes. Rename the nodes to describe what they are doing. Optionally add some sticky notes if needed. All that will be useful to you or others when updating future version of the tool.

Cleanup generated geometry by removing groups and attributes created for internal use only.

Interface

User shouldn't have to dive inside of your HDA. Only in rare exception editable node should be used. The user should never have to unlock your HDA to interact with it.

Promote every important parameters to the top level of your HDA. Users should never have to unlock the HDA to interact with it. Rename parameters with descriptive names so user can naturally know what the parameter does. Set parameters default value so your HDA work almost straight away when created! Setting value ranges will also help the user to understand within which value are considered correct.

Keep the parameter organized. Most of the time you should be able to organized by:

• Sorted by what parameters need to be changed first
• Then sorted by what are the most important parameters
• Grouped by functionality (ex: all the parameters modifying a specific noise)

Separators and Folders should be used when you start to have many parameters to organize them in groups

Look into disabling or hiding parameters if they won't influence your setup under specific cases.

Help

Always write some documentation for your HDA.

Writing some documentation of the parameters is the quickest and easiest way for users to know what a parameter does. Even if the parameter might seem pretty explicit for yourself, it might not be for others. Just type a few words on what the parameter is changing and its influence on the setup.

If possible, write an help page to provide information on how to use the HDA. Help pages can be created on the HDA itself or on Confluence.

An help page should contain the following information:

• Description about what the tool does
• Explanation on how to use the tool
• Optional - Special use cases/scenarios
• Optional - Description of the expected inputs
• Optional - Parameters help

Others

Here are few extra elements to improve your HDA.

• Right most input is expected to be the manipulated output geometry.
• Setting a name for your node inputs and outputs will help users to know how to connect it.
• If your HDA is not supposed to work in some condition, try to catch potential errors and raise descriptive message to the user (HDA Message Node + Error SOP)
• Try to organize your HDA by setting in which menu to find it. It will allow users to find it more easily if they do not know the name.
• Set an icon on your tool representing what it does. This will make it easier to see in your scene graph or the node type list and easier to remember. Feel free to use Houdini default icons.
• Document your Python Module. If your tool rely on a lot of python, speak with a TD to maybe integrate it to some packages