Digital assets OTL tips and tricks

If you want to nest custom operators within other custom operators, you must ensure all references are valid.

For example, if you have a character that contains:

• a job-wide skeleton set-up operator,

• a character Geometry node

• ...all inside a custom object subnet that has the animation interface

...then all three operator definitions MUST be present at all times or you will have the missing operators show up as being empty.

To fix missing operators, you can install the required OTLs and the operators will automatically fill in (you do not need to restart Houdini).

You can dereference the skeleton and the object at any time, then save the new definition to an OTL archive. This will cause the existing definition for the skeleton and the object not to be used. You can re-establish the reference for the skeleton and the object at any time.

There is some danger to embedding operator types in the hip file, because definitions are only saved in the hip if the scene actually contains an operator of that type. If you accidentally save your hip file without an operator of that type, you've lost your operator definition.

The other option is saving your operator definition to an external OTL file, but installing that OTL to the Current Hip File only. That way any changes you make will always be saved into that external file, so you don’t have to worry about losing them. The disadvantage there is that you don’t get the neat capability of using your old Hip files as a backup mechanism, where each version of the hip file contains a slightly newer version of the operator definition.

vcc (the VEX compiler) has options for creating OTLs directly from .vfl files. They are described briefly in the vcc usage message.

    vcc -m vops.otl shader.vfl
    

This creates a new VOP operator and puts it in vops.otl. This is exactly what Houdini does now when you choose “Create New VOP Type” from the menu of a SHOP or VOPNET operator.

    vcc -l shaders.otl shader.vfl
    

This compiles shader.vfl, and puts the generated dialog script file, .vex file, and the uncompiled .vfl file into shaders.otl. This saves you from having to worry about editing the index file, putting the .ds and .vex files in the right places, and so on. You can also specify on the vcc command line an icon, name, and label for your shader.

With the .vfl file inside the OTL, you can edit it in the Type Properties window .

You can access a variety of file types stored on web servers using http: URLs.

For example, in the File SOP you can use a URL like http://server/file.bgeo to load the geometry from a web server. You can also keep your OTLs on a web server by putting a URL in the OPlibraries file, for example http://server/shaders.otl.

In most cases (COPs being the main exception) you can also access images and textures over HTTP. For example, in a Decal SHOP you could use a URL like http://server/texture.rat. During a render, mantra would get the texture from the server.

The hotl command line utility takes the name of an OTL file and prints information about the operators defined in the OTL. This is the same information that appears when you press on the name of an OTL in the Operator Type Manager window .

The Operator Type Manager provides an interface to edit the contents of an OTL . However, you can also use the otexpand otcollapse HScript commands, or the hotl command-line utility to expand, edit, and re-archive OTL files.

The archive contains the index files (like SHOPsurface or SUBobj), the dialog scripts (.ds files) and other related files like the .cmd creation scripts and the .vex/.vfl files (in the case of VEX operators).

An OTL archive can contain anything you want, including arbitrary scripts, geometry, and image files like .rat textures. You can embed anything that a Houdini OP would normally reference from disk in an OTL file. However, remember that embedding images or geometry could make your OTL very large.