Output files and file attributes on PDG work items are assigned tags so that PDG can identify their file types. A tag determines what application is used to open a file from the attribute pane, as well as which cache handler(s) to run when checking for an existing file on disk. You can register custom tags with the PDG pdg.TypeRegistry and use them with built-in nodes. You can also register custom cache handling functions written in Python in order to manually control PDG’s caching mechanism.

Custom tags added through the Type Registry automatically appear in the tag chooser drop-down on any nodes that have a parameter for setting the file tag.

Custom file tags are registered through the PDG Type Registry. You can do so on-demand from the Python Shell, or by adding a registration script to the the $HOUDINI_PATH/pdg/types directory. When Houdini starts, PDG automatically loads all scripts and modules from the pdg/types directory on the Houdini search path. For example, you can create a script to load custom tags and save it as $HOME/houdini18.0/pdg/types/custom_tags.py. Inside of the script file you’ll need to define a registerTypes function, which is called automatically when PDG loads the script.

def registerTypes(type_registry):
    type_registry.addTag("file/geo/collision")
    type_registry.addExtensionTag(".py, "file/text/pythonscript")
    type_registry.addTagViewer(".bgeo.sc", "gplay")

There are two API methods that you can use to register a custom file tag:

• The first is pdg.TypeRegistry.addTag, which directly adds the tag to the global list. No association is made with any file extensions.

• The second method is pdg.TypeRegistry.addExtensionTag, which lets you use your custom tag with a particular file type. A mapping is made from the file extension to the tag in addition to adding the tag to the global list. PDG will then automatically use your custom tag for any files that have that extension, unless the call to add the file explicitly specifies a different tag.

You can also supply the name of a viewer application for a particular tag. The viewer application determines how to open file links in the work item’s pane. If you specify a viewer application, PDG will use it to open the file. Otherwise, it falls back to opening the directory that contains the file. You can add custom viewers using the pdg.TypeRegistry.addTagViewer method.

Many nodes in PDG support disk caching. If the expected output files for a work item already exist on disk, then that work item is able to cook from cache instead of re-running. You can enable caching per node, and you can configure it to either always read, always write, or read from cache only if the files exist.

Internally, PDG verifies that cache files exist by checking if they're found on disk. This may not be suitable for all applications or all types of files. For example, this would not be suitable if your output files are stored on a cloud storage system or if you want to do extra file validation as part of the cache check.

As an alternative, you can verify the existence of cache files by registering a custom cache handler in the same way that custom file tags are registered (as described in the previous section). For example, you can create a script that defines your custom cache handlers and save it as $HOME/houdini18.0/pdg/types/custom_handlers.py.

import os

def simple_handler(local_path, raw_file, work_item):
    print(local_path)
    return pdg.cacheResult.Skip

def custom_handler(local_path, raw_file, work_item):
    # Skip work items that don't have the right attribute
    if work_item['usecustomcaching'].value() == 0:
        return pdg.cacheResult.Skip
    try:
        if os.stat(local_path).st_size == 0:
            return pdg.cacheResult.Miss
        return pdg.cacheResult.Hit
    except:
        return pdg.cacheResult.Miss

def registerTypes(type_registry):
    type_registry.registerCacheHandler("file/geo", custom_handler)
    type_registry.registerCacheHandler("file/geo/usd", simple_handler)

Each cache handler is passed three arguments: the local path to the cache file, the raw pdg.File object, and the pdg.WorkItem that owns the file. The file object contains all of the metadata associated with the file, such as its raw path and file tag.

Cache handlers are registered for a particular file tag. In the above example, a file tagged as file/geo/usd would first be checked using the simple_handler. Since that handler returns the pdg.cacheResult.Skip return code, the cache system then moves on to the next possible handler which is file/geo. That handler verifies that the file has a non-zero size, but it only does so if the work item that owns the file has the usecustomcaching attribute set. If both handlers return Skip, then PDG’s built in cache checking mechanism is used instead.

As soon as a handle returns pdg.cacheResult.Hit or pdg.cacheResult.Miss, handler evaluation stops and that result is used. The most specific matching tag pattern is always evaluated first.