Channels
Last updated
Last updated
The source code, configuration files, and support files for a channel are stored in a directory that has the following structure:
The top directory is the root directory for the channel. The root directory is typically named after the channel.
Under the root are the channel definition file and these sub directories:
/.devcontainer
/packages
/data
/docs
/mappings
/graphs
These are described in more detail in the following sections.
The channel definition file is a YAML text file that specifies how the channel is to be configured. The name of the file is the name of the channel.
The channel definition file has several sections. Here is an example of a basic channel definition file:
The “channel” section specifies channel attributes. Two channel attributes are supported - “type” and “base”.
The “type” attribute specifies the execution environment for the channel. Currently, two types of environments are supported - “blender” and “python”. If the channel type is set to “blender”, then the interpreter is executed as a script inside of the Blender application and nodes can call the Blender api. If the channel type is set to “python” then the interpreter is executed as a normal Python script.
The “base” attribute is used with channel inheritance. The base attribute specifies the channel file that will function as the base for this channel. See Additional channel configuration below for details.
The “add_setup” section specifies the function(s) that will be executed before the graph is interpreted. Typically these functions perform setup operations such as deleting the default cube object that is created when Blender is first run, enabling the Cycles rendering engine, enabling GPU rendering, and any other setup tasks required.
The “add_setup” section is specified as a list of Python modules. Before the graph is interpreted, each module is searched for a function named “setup” which is executed. These functions are executed in the order that they are listed.
In this example, the channel type is set to “blender” and there is no inheritance. The “testpkg1.lib.channel_setup” module will be searched for a “setup” function which will be executed before graph interpretation.
The “add_packages” section specifies the list of Python packages that will be searched for nodes to add to the channel. By default when a package is added to the channel, all nodes in that package are added. In the above example, the nodes in Python package “testpkg1” will be added.
Additional sections can be added to a channel definition for more complex channels.
The “add_nodes” section allows the inclusion of specific nodes from a package without including the full package. Here is an example:
The “add_nodes” section is a list. Each entry specifies a node to be added.
The “package” attribute is required. It specifies the package the node will be drawn from.
The “name” attribute is required. It is the class name of the node to be included.
The “alias” attribute is optional. It specifies a new class name for the node when it is used in the channel.
The “category” attribute is optional. It overrides the GUI menu category for the node that was specified in the node’s schema definition.
The “subcategory” attribute is optional. It overrides the GUI menu subcategory for the node that was specified in the node’s schema definition.
The “color” attribute is optional. It overrides the GUI menu color for the node that was specified in the node’s schema definition.
In the above example, the “SweepArange” node is selected from the “anatools” package and it is given an alias of “Xyzzy”. Graphs in this channel can reference a node of this class by specifying a nodeClass of “Xyzzy”. The GUI menu category for the node is set to “Tools”. The GUI menu subcategory is set to “Parameter Sweeps”. The color of the node will be the hex value "#0C667A".
The “rename_nodes” section allows a node class to be given a new name. Here is an example:
The “rename_nodes” section is a list. Each entry specifies a node class to be renamed. The “old_name” attribute specifies the old class name and the “new_name” attribute specifies the new class name. In this example, the “Render” node class is renamed to “Grue”. Graphs in this channel can reference a node of this class by specifying a nodeClass of “Grue”.
The “default_execution_flags” section is only relevant when a channel is run locally from the command line. They do not affect operation in the cloud service. The purpose of this section is to specify default flag values that will used when those flags are are not included on the “ana” command line. Here is an example:
The “default_execution_flags” section is a dictionary. The key for each entry is an execution flag and the value is the default value for that flag. In the above example, the default or “--graph” is set to “graphs/my_test_graph.yml” and the default for “--interp_num” is set to 10.
Sometimes channel configurations can get complex. If you have defined a complex channel and would like to create a new channel that is similar but with only a few minor changes then channel inheritance might be useful.
A channel can inherit attributes from a previously defined channel by specifying the previously defined channel as its base. When this is done, all of the attributes (nodes, default flags, etc) defined in the base channel are also defined in the new channel. The new channel can then add additional attributes or remove attributes that are not needed. Note that the channel definition file for the base channel must also be stored in the channel root directory.
Here is an example of channel inheritance.
In this example, the base channel is defined in the file “myoriginal.yml”. For purposes of this example, assume the base channel has three packages - “testpkg1”, “testpkg2”, and “testpkg3”.
The “add_packages” section adds a new package called “mynewpkg” to the channel.
The “remove_packages” section removes “testpkg2” from the channel. None of the nodes defined in that package will be in the channel.
The “remove_setup” section removes the “testpkg2.lib.channel_setup” module from the list of setup modules.
The “remove_nodes” section removes the “Render3” node from the channel.
