Nesting custom operators
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.
Saving in HIP vs. installed OTL file
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.
VEX operators in OTLs
vcc (the VEX compiler) has options for creating OTLs directly
.vfl files. They are described briefly in the vcc usage
vcc -m vops.otl shader.vflThis 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.vflThis compiles shader.vfl, and puts the generated dialog script file,
.vexfile, and the uncompiled
.vflfile into shaders.otl. This saves you from having to worry about editing the index file, putting the
.vexfiles in the right places, and so on. You can also specify on the vcc command line an icon, name, and label for your shader.
.vfl file inside the OTL, you can edit it in the Type
Properties window .
HTTP file reference support
You can access a variety of file types stored on web servers using
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
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.
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
Expanding OTL archives
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
.vfl files (in the case of
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.