Process Nodes#
Clarisse provides a special class of nodes called Process that is designed to run a specific task such as rendering an image to disk for example. Unlike other Clarisse nodes, process nodes are not directly part of the evaluation graph. They must be run explicitly. To run a process node you can either press its Run action via Attribute Editor in Clarisse or run the process from command line using CNode.
Process nodes can be organized into a process graph of ordered operations and they aren't restricted to rendering. They can be used to execute expensive tasks you wish to compute offline like scene generation and export or baking textures on a scene wide level.
To learn more about how to run a process from command line, please refer to using processes in CNode.
Note
It is possible to extend Clarisse with custom process written in Python. For more information please refer to Script
Merge#
The Merge process allows you to execute an ordered list of processes. This process is very useful if you want to schedule and order the execution of multiple processes. To do so, simply connect the processes you wish to execute as inputs of the Merge process.
Note
The execution of the process is performed following the order of inputs in the list. Make sure to reorder the inputs using the Attribute Editor to set your preferred order of execution.
Image Node Write#
The Image Node Write process evaluates an input Image Node and save it to disk. You must use this process if you wish to save images. To learn more about the Image Node Write please refer here
Image Node Write Deep#
The Image Node Write Deep process evaluates an input Image Render Node and save it to disk. You must use this process if you wish to save deep renders. To learn more about the Image Node Write Deep please refer here
Variable Range#
The Variable Range process executes an ordered list of processes by iterating an input variable on specified range of values. This process can be seen as a for/loop statement. For example, you can use this process to modify the global variable defining the current frame $F
, to drive Image Node Writes to render a sequence of images to disk.
Attribute | Description |
---|---|
Variable | Define the name of the global variable to drive |
Values | Define the range of values that will be affected to the global variable |
Processes | List of processes to execute and optional value range overrides |
Range Syntax#
Numeric Range#
To specify a numeric range you can use the following syntax: start:end%step
Examples#
Iterating from 101 to 150
101:150
Iterating from 101 to 150 with a step of 5
101:150%5
String Range#
To specify a string range you have to specify each value in the order you wish them to be affected: "my first value";...;"my last value"
Examples#
Defining a range for the following values: morning, noon, afternoon, evening, night
"morning";"noon";"afternoon";"evening;"night"
Specifying Multiple Ranges#
It is possible to specify multiple ranges and mix numeric and strings. However, please note that strings are always affected after the numeric ranges. For example:
500:600%10;"morning";200:220;101:150;"night"
In this example, the process will execute child processes from 101 to 150, then from 200 to 220, then from 500 to 600 with a step of 10 and finally "morning"
and "night"
.
Execution Order#
When the Variable Range process is executed, it first changes the current value of the variable and then executes each child process following their order as defined by the Processes list.
However as it is possible to override the values for each process, please note that the execution of some processes may be skipped according to their Override Values. Indeed, if the first child process has an Override Values of 100 while the Values of the process is set to 50:200, the first child process gets only evaluated when the variable gets the value of 100.
This behavior has been specifically designed to render layers that have a different output frame ranges as this can be used to render a static background on a specific frame only for example.
Specifying Value Range Per Process#
It is possible to override the range of values for each process. This is very useful when rendering layers that have a different output frame range. For example, this can be use to specify a static background layer that would be rendered as a single still.
Let's imagine we have a writeBG
Image Node Write rendering a static background. Then writeBG
would be connected to a Variable Range process iterating the entire shot from frame 101 to 155. We would set Values to 101:155
and to specify a single frame for writeBG
, we would set Override Values for writeBG
to 101.
Usage in CNode#
Most of the time Variable Range process will be executed in CNode. They are a good way for example to render all the layers of a shot or a sequence. When rendering over the render farm you will likely want to override values to specify a frame range for each render node.
Specifying per process value range#
To override a variable range for a child process you must use the argument -process_values
. The first parameter of the argument identify the name of the child process while the second one the actual values to override. For example:
cnode my.build -process “build://myVarRange -process_values build://myVarRangeChild3 200:300 build://myVarRangeChild8 50:60”
In this example, the process build://myVarRange
is executed normally except for two of its children build://myVarRangeChild3
and build://myVarRangeChild8
that have new override values.
Enabling/Disabling child processes#
Sometimes, you may want to explicitly enable or disable the execution of child processes from the command-line. In that case you must use the special argument -process_enable
. The first parameter of the argument identify the name of the child process while the second one the actual execution state of the child process. For example:
cnode my.build -process “build://myVarRange -process_values build://myVarRangeChild3 200:300 build://myVarRangeChild8 50:60 -process_enable build://myVarRangeChild1 no build://myVarRangeChild2 no build://myVarRangeChild8 yes”
In this example, the execution of the child processes build://myVarRangeChild1
and build://myVarRangeChild2
is skipped. However, we explicitly enabled the execution of build://myVarRangeChild8
. Note that all other child processes of build://myVarRange
are executed as defined in the process node. In other words, their execution follows what has been set in the build file my.build
.
Variable Set#
The Variable Set process is used to set the values of existing global variables before executing its list of children processes. Once all the children processes have been executed, the values of the global variables are restored to their original values as they were defined prior the execution of the process node.
This process can be seen as a local global variable override that is executed at a point of the process graph. It is very useful when setting up a rendering graph in a build which manages multiple shots with multiple light sets driven by global variables.
Attribute | Description |
---|---|
Variables | Define a list a global variable and their values that will be set right before the node executes its children processes. |
Processes | List of processes to execute and optional value range overrides |
Variables Syntax#
Specifying global variables and their values follow this simple syntax:
MY_VAR_NAME1=MY_VALUE1;MY_VAR_NAME2=MY_VALUE2;...MY_VAR_NAME_N=MY_VALUE_N
It is also possible to specify a global variable and its value on each new line (assuming SHOT
, LIGHTS
, ENVIRONMENT
and QUALITY
have been already defined in the application):
SHOT=42
LIGHTS="noon"
ENVIRONMENT="desert"
QUALITY=1.0
Execution Order#
When executed, the Variable Set process first sets the new global variable values, then executes each child process following their order as defined by the Processes list and finally restore the global variables values to their respective ones that were set before the execution of the node.
Usage in CNode#
Variable Set process can be executed as root process in CNode.
Enabling/Disabling child processes#
It is possible to explicitly enable or disable the execution of child processes from the command-line. In that case you must use the special argument -process_enable
. The first parameter of the argument identify the name of the child process while the second one the actual execution state of the child process. For example:
cnode my.build -process “build://myVarSet -process_enable build://myVarSetChild1 no build://myVarSetChild2 no build://myVarSetChild8 yes”
In this example, the execution of the child processes build://myVarSetChild1
and build://myVarSetChild2
is skipped. However, we explicitly forced the execution of build://myVarSetChild8
. Note that all other child processes of build://myVarSet
are executed as defined in the process node. In other words, their execution follows what has been set in the build file my.build
.
Script#
The Process Script class is an abstract class that let you extend Clarisse with custom processes written in Python. For more information please refer to Extending classes in script topic found in Clarisse SDK documentation.
WriteAbc#
The WriteAbc process allows you to bake the content of an Input Context to an Alembic cache. To bake an Input Context to an Alembic cache, just press Run Process in the Attribute Editor or execute the process using CNode. Please note that WriteAbc exports the current state of the Input Context at the current application frame. To bake an animation, you must plug it into a Variable Range process that iterates on the global variable $F
.
Warning
Geometry Bundles (AlembicBundle and USDBundle) are currently not supported and thus skipped during the export.
Attribute | Description |
---|---|
Input Context | Set the context to export as an Alembic cache. |
Batch Process Mode | Set how the WriteAbc should output the Alembic cache when used in a batch process such as Variable Range . By default Batch Process Mode is set to Single Output File. It is possible to set it to Multiple Output Files and in that case, an animation will result in a sequence of Alembic file caches. |
Filename | Set the output filename |
Export Combiners | Set if combiners should be exported as geometries. When enabled, the node will export any sub-combiners recursively. |
Export Scatterers | Set if scatterers should be exported. |
Scatterer Export Mode | Set the scatterer export mode. When set to Instances as Geometries, all instance are exported as geometries. However, if it is set to Instances as Bounding Boxes, only bounding boxes of instances are exported. |
Export Properties | Enable the export of geometry properties/attributes |
Compatibility Mode | Set the correct export settings when exporting geometry (properties/attributes) so that the output Alembic cache can be read by other packages such as Houdini or Katana. By default, it is set to None so that the Alembic cache is the most optimized in size and in memory when loaded back to Clarisse. |
Fill Sparse Properties | Set if sparse geometry properties/attributes should be filled with zero values. Note that some packages such as Houdini or Katana do not support sparse properties. Filling sparse properties/attributes increases the output file size and the amount of memory used when loaded back to Clarisse. |
Promote To Geometry Parameter | Set if geometry properties/attributes matching Alembic standards types should be exported as Geometry Parameters. If unchecked, all properties are exported as standards properties. |
Bake Indexed Properties | Set if indexed geometry properties/attributes should be baked. Baking Indexed Properties increases output file size and memory usage when loaded back to Clarisse. However, some packages such as Houdini or Katana do not support sparse indexed geometry properties/attributes. |
Batch Process Mode#
The WriteAbc process can be executed from a batch process such as a Variable Range node to bake an animation for example. In that case, you may want to save the output Alembic cache as either a single file or a sequence of files. To do so you can set the Batch Process Mode attribute to control the behavior of the WriteAbc. When set to Single File Output, data is always written/appended to the specified file. However, when set to Multiple Output Files, data is written to a new file after each execution. When you are using this mode, make to use ####/$F
in the Filename attribute or else the output file will be overwritten each time the WriteAbc is executed.
Sequence File Pattern#
The Filename attribute supports a special tag #
to format the output alembic sequence file pattern. This special tag allows you to specify where the current frame should be located in the output filename. This tag is also used to format the number of digits of the output frame number. For example:
/path/to/my/seq.##
outputs to/path/to/my/seq.01
for frame 1 and/path/to/my/seq.159
for frame 159/path/to/my/seq_####_final
outputs to/path/to/my/seq.0001
for frame 1
Warning
In the case you are exporting a single Alembic cache per frame, make sure to add ####
or use $F
variable. Unlike Image Node Write, #####
isn't automatically appended at the end of the filename if it is missing.
WriteUsd#
TODO