• Page
• Discussion
• View source
• History

From Odwiki

Contents 1 Custom Operators and OTLs 2 The Grand Philosophies of OTLS 2.1 Simple effective systems 2.2 Distribution of your operators 2.3 Encapsulation / Portability 2.4 Inheriting other OTLs 2.5 The concept of scene sharing 3 More technical information 3.1 How Houdini loads OTLs 3.2 Advanced Embedding within OTLs 4 Manipulating OTLs with hscript commands 5 Plugin Development Using the Development Kit

Custom Operators and OTLs

Houdini allows you to create Custom Operators very easily. These operators (we call them HDA's - Houdini Digital Assets) are stored in a special file called an OTL (Operator Type Library) on disk (usually with the .otl extension). Houdini sessions read these OTLs and the operators become available to the user - they appear in the operator menus.

If a user makes changes to an HDA, all Houdini sessions referencing that operator will automatically update to use the latest version. This is because only the published parameters of the HDA is stored in the hip file and the contents of the HDA is referenced from the OTL. The user can elect to not receive these automatic updates (either manually or by configuration) and the OTL will be Embedded into the hip file. After this still, the user has the option of upgrading to the latest version very easily. Most of these operations are handled by the OperatorTypeManager.

There are 2 types of custom operators:

• CustomSubnetOperators
• CustomVEXOperators

There is another way to add custom operators, which is sort of outmoded by the introduction of OTLs, is by means of the IndexFiles.

The Grand Philosophies of OTLS

Simple effective systems

Using CustomOperators will definately change the way you work. At the very least they help you create a quick and effective operation with only some useful parameters exposed to you. For free you get the capability to use that system throughout your scene. You can use it in 20 different objects and you'll only need to tweak and enhance the system in one place. This is when a custom operator is deemed synced - and this can be done by making sure you've Right-Clicked on the operator and chosen "Match Currrent Definition".

Distribution of your operators

The next benefit is that you can "publish" this otl so that it becomes available in all future fresh sessions of Houdini. This is the part of the process labelled "Install Library To...". This seems like a confusing step at first but very quickly it can make sense if you practise a bit. This process basically adds your .otl filename to a file in your HOUDINI_PATH called OPlibraries which Houdini will read upon startup to find out which otls it should load.

Encapsulation / Portability

This entire process really lends itself to operators which have all their resources inside of the operator. If you make the operator totally self-sufficient and clean then it can be re-used in other files and projects to a much more effective degree. As you gain experience with creating these, you'll start designing your operators this way from the outset. Small processes containing a couple of SOPs, all the way to complex character rigs containing hundreds of bones, objects, renderer setups and expressions can be totally encapsulated into a single OTL. Resource files like texture-maps and scripts can also be contained in OTLs.

Inheriting other OTLs

A smart way to work is to break down a process into many smaller steps, all of which can be made into maintainable custom operators. A custom operator may contain many other custom operators. Doing this allows you to possibly improve the quality, features and performance of many operators if you tweak a base operator that it inherited in many custom objects.

The concept of scene sharing

Another way to consider OTLs is that you can effectively be working parallel on the same scenes. This suits larger facilities more but the concept definately applies even to two artists working on the same set of shots. Imagine an artist - a lighter - creates an OTL which contains the lights for a particular scene. Any artist can have this OTL in their scene and be getting these committed changes from the lighter. In a sense, each artist may eventually not have a need to ever save a scene file, instead they could be saving their development to their OTLs. The scene file becomes the thread holding custom operators together. The only things the scene possesses that OTLs don't is the TimeLine, Variables, Takes and a freeform development area. Hipfiles can also include paths to OTLs that are not strictly defined in the abovementioned OPlibraries file, meaning that the scene is free to include any OTL it likes. An extreme usage of OTLs could actually mean that there could even never really be a single .hip file, and that all scene resources are inherited under a master operator. Rendering an image of this scene could just be like opening up Houdini or hscript and creating the operator and then ask it to render itself. (It could contain ROPs that know the rules how to render its objects.)

More technical information

How Houdini loads OTLs

These operator definitions (also known as Houdini Digital Assets or HDAs for short) are stored within a file called an OTL (Operator Type Library). You can store many HDA's inside of one OTL if you wish. Houdini first attempts to find OTL files using the OPlibraries file from the directories found in the HOUDINI_OTL_PATH environment variable. If that doesn't exist, then the HOUDINI_PATH environment variable is used to find the OPlibraries files. The OPlibraries file contains a list of OTLs. Houdini then loads all the OTLs named in these files and adds them to the operator menus.

CustomSubnetOperators can contain other CustomOperators.

There are only 2 types of CustomOperators; Subnet types and VEX types. However, CustomSubnetOperators can contain other CustomSubnetOperators or CustomVEXOperators.

i.e. In the OperatorTypeManager you'll see the entries without any heirarchy. There is no way to state within an OTL that the VEX "belongs" to the Subnet type. In other words, if you wish to copy the subnet operator to another OTL, you're going to have to take care to manually copy the other consistuent types too. So, basically, subnet operators can contain other subnet ops and VEX ops, but it doesn't imply that children nodes are "owned" by the parent subnet.

Advanced Embedding within OTLs

To embed arbitrary information in your OTLs (like geometry files, hscript, expression functions, etc), right-click on your custom operator and choose "Operator Type Manager". This should bring up a new dialog with your operator type highlighted. Right-click on this and choose "Edit Contents..." Click on the Help button in this new window for instructions.

To accesss the files that you have included in your OTL from anywhere in your hip file, use this syntax:

opdef:/OperatorType/NameOfOperator?SectionName

eg: In a shop I can acces the bitmap saved in my otl by typing "opdef:/Shop/MyConstantShader?MyBitmap" in the file field of my shop, so it becomes completely self contained. Note that "SectionName" is not the name of the file you added in your otl, but the name you have given that section. If this syntax is confusing, it is actually based on the way your operator appears in the Operator Type Manager.

In versions of Houdini of 7.0.376 and up, you can refer to the OTL in which the definition resides by using the "." syntax, like so:

opdef:.?SectionName

Manipulating OTLs with hscript commands

• RemovingVEXFromOTL : This describes how to remove the VEX source code from an OTL, leaving everything else, such as the precompiled VEX code. This is useful for distributing a VEX OTL without revealing techniques from the source code.

Plugin Development Using the Development Kit

Using the HoudiniDevelopmentKit / HDK it is also possible to create new operator types by writing C++ code. These are not HDA's/OTL's, but true custom nodes.