Power of Digital Assets can lead to over-design

As TD's building tools to be used in production, we tend to focus only on the immedate task at hand in the limited time we are given. We want to make simple to use tools that are easy to maintain and either perform a specific task or solve a particular problem.

Digital Assets have very powerful traits that help the TD accomplish this task very efficiently. Not only that, but the TD can release tools to a number of users and maintain these tools easily. Making changes to Assets already in use with automatic updates is liberating.

Digital Assets have an easy way of creating parameter interfaces for the user to work with. Wether you know this or not, you are defining the workflow of the Asset through this parameter interface. The design is in our hands. We can structure folders and parameters to reflect desired order of operations (workflow), importance in shaping the result (desired outcome), grouped by similar functionality or a combination of all of the above.

So what's wrong with all of this? The more parameters you pile in and the more functionality you add to the Asset, the more complicated the design of the tool becomes and the more complicated the parameter workflow becomes. There's nothing like the sight of a novice user working with an Asset that has twenty folders and over one hundred parameters. Buttons that execute scripts at seemingly arbitrary points, etc. At that point, there is no such thing as a consistent workflow or structure. The structure of the parameters may have folders in order of process but paramteres in order of functionality or effect. Buttons executing scripts that should be in the thrid folder across nested two folders deep pulled up to the top for no other reason than "the user couldn't find this truly important feature". That comment alone leads to assumptions that we as TD's shouldn't even make!

The user has to learn how to use your tool. How quickly they can do this and how little time you need to devote to teaching them and/or developing the help is in your hands. I like to make the tools behave as much as possible in the Houdini way. Sure there will be times where you need to make a tool that is quite complex but knowing the options is critical to building tools that are not only usable but all the features you want the user to take advantage of may actaully happen withut having to read all the research papers you used to decide what goes where and why.

By stepping back and looking forward and sideways, we may be able to build our tools the first time as a true reuseable tool that is simple to use, easy to maintain and has a workflow consistent to any other tool in Houdini. Nothing new for the user to learn. All they have to learn is Houdini basics.

Establish a clear desired outcome and the steps required to get there

Sounds pretty simple. You need to build a tool that does Condensation Trails. You do the research. You build the network prototypes using simple tubes, spheres, etc. You get the look you are after and then you wrap it all up and build a single Asset.

It's that last step that limits the tools possibilities. You have to keep the user in mind at this final critical step. From her position, she wants a tool that is consistent with other tools she has used and get the job done. By assessing the workflow that the user has to follow, you have a better chance of anticipating the best workflow.

In the case of the ConTrail tool, I chose to separate out the pSurf object which is solely responsible for supplying the Contrail with geometry to emit particles from. The pSurf tool can be self-sufficient generating it's own geometry or it can be parented to another object or fetch geometry from another object.

Adding scalability is real easy now. If we need more geometry to emit particles from, I simply add another pSurf object and add it to the list of possible geometry sources in the ConTrail.

Adding a different tool like BonFire is a lot easier now. I can use the identical method as the ConTrail and have it rely on pSurf Assets. If the user can use ConTrail, they have a much better shot at getting BonFire going as well in a very advanced way using the same methods to scale the effect in the scene.

By looking at your tools as parts to the whole, we can explore the possibilities of objectifying these parts in to tools to be used in the tasks required to achieve the desired outcome. Literally ripping the monster asset apart in to logical parts then seeing how much of it is reusable and what parts define the behaviour.

I call this "A Modular Approach to Tool Design".

What is a Tool?

Multiple Tools to Complete a Task

Scalable Tools

Good Modular design gives us tools that are scalable. Scalability is incorporated througout Houdini so it is a good idea to incorporate it in to our custom Tools. The ConTrail tool makes references to as many pSurf object Tools that you want. By using the standard naming patterns, you can use a simple long list of all the pSurf objects in your scene and the ConTrail will emit particles from all the surfaces in the pSurf objects. You can use "*" wildcards to do automatic expansion of lists of pSurf objects.

The ConTrail tool doesn't even need a specific pSurf tool. You can fetch surfaces from any object. So the ConTrail tool is scalable in it's ability to take in one or more pSurf objects to supply the emitter geometry. It also allows you to reference in any object with a surface but your mileage may vary. The video demonstrates how easy it is to set up a simple scene where copying and pasting 10's or 100's of pSurf objects leads to the ConTrail Asset automatically picking up these additional pSurfs by exploiting simple houdini-standard-convention name space techniques using wildcard expansion "*" in this case.

Tool Design Consistency

Building a suite of tools requires a bit more planning. Each Asset within the suiet of tools with similar behaviour should share a similar interface and viewport behaviour. In the video, the ConTrail Asset and the BonFire Asset both cause the emission of particles. They both share almost an identical parameter interface and viewport behaviour. This consistency allows you to learn one tool then apply that to a second new tool and get expected behavour. It also allows you to swap assets and retain all the parameter settings.

Again this also follows Houdini convention. This is what trained Houdini users would expect.

Jeff's Tip: When naming any custom nodes, it is appreciated by other users if you give the node a Label based on the node's name. Notice in the example above. The node's table name is "my_shop" and the label is "My Shop". Sure even we break the rules. Notice the xform SOP is labelled Transform and I digress.

Please login or register to add comments.