OpScript

The scene graph locations are specified using the Collection Expression Language (CEL). The CEL parameter options are available by clicking Add Statements.

For more information, refer to the CEL Reference document found on the documentation HTML page (accessed through Help > Documentation) or the CEL Statement Widget Type in Common Parameter Widgets.

• Edit in <editor>... - opens an external editor, as set up in the Preferences under externalTools > Editor, for editing the OpScript node's Lua script without blocking Katana's user interface. Katana monitors the text files you are editing, and when it detects that they have changed, it updates the OpScript node accordingly.

• lua - contains the lua script to run.

Determines when the script is run:

• immediate - the script is run at the locations specified in the applyWhere parameter as it is evaluated at this node's point in the node graph.

• deferred - the script is set up by this node but won't actually be run until a later node in the node graph, as specified by the applyWhen parameter.

Enables multi-sampling of the opArgs user parameter to Op Args.

If enabled, allows multiple inputs to be connected to this OpScript node.

Determines where the script is run:

• at all locations - at all the locations in the node graph.

• at specific location - at only the location specified by the location parameter. If this location doesn't exist, it is created automatically.

• at locations matching CEL - at only those locations in the node graph that match the CEL statements.

Controls how input ports on the node are mapped onto the inputs of the underlying Op. This parameter is only meaningful when the node has one or more invalid input ports - a port that is not connected to an output port or is connected to an output port that doesn't provide data.

When set to only valid, any invalid input ports of the node are skipped when determining which inputs to pass to the underlying Op.

When set to by index, all input ports of the node are represented in the list of inputs the Op sees; invalid inputs are represented as an Op of type no-op.

The location to create, if it doesn't already exist. Otherwise, the scene graph location at which the script is run.

The location parameter options are available by clicking the dropdown menu.

For more information, refer to the Scene Graph Location Widget Type in Common Parameter Widgets.

Determines when the script is run:

• during op resolve - the script and its arguments are added as attributes to be executed later by an OpResolve node. If the Op isn't run by an explicit OpResolve node placed in the node graph, it is automatically run at render time by the implicit resolvers.

• during material resolve - the script and its arguments are added as attributes under the material.ops group attribute. This is primarily intended for material scene graph locations, allowing the material to specify a procedural process that is run at every location that the material is assigned to. The script is run as part of the material resolve process, and is executed just after the initial values for the material shader are created at the location. Examples of its use include randomizing or procedural control over shader parameters.

• during katana look file resolve - the script and its arguments are added as attributes under the ops group attribute and are evaluated by a LookFileResolve node or by the first implicit resolver if no LookFileResolve node is present.

Deferred OpScripts are added as group attributes within the ops group. By default, the name of the node is used for the sub-group. Since node names must be unique in project, the resulting attribute name can change. In nearly all cases, that doesn't matter. For cases in which it does, you can specify a fixed name to use.

Sets the name of the attribute group beneath ops to use for describing this deferred script.

Specify a space-delimited list of strings to indicate that this script should only be resolved by Op resolvers that contain at least one matching "resolveId." This is an advanced feature for greater control over order of evaluation.

A useful resolveIds is implicit_prepocess, which runs at the first implicit resolver, before other implicit resolvers, such as MaterialResolve and ConstraintResolve are run.

When applying in a non-immediate state, enabling this results in the script running at every location beneath the assigned locations. In general this is more efficient than using an equivalent recursive CEL statement.

You can also override the ops.*.recursiveEnable attribute anywhere deeper in the tree to exclude evaluation at those locations. This is similar to the behavior of the visible or light linking attributes.

Execution is disabled for locations at or below this CEL statement. For large scene hierarchies, this is often less expensive than enabling evaluation at a larger number of leaf locations to avoid applying it to a smaller subset.

The scene graph locations are specified for the disableAt parameter options by clicking Add Statements.

For more information, refer to the CEL Reference document found on the documentation HTML page (accessed through Help > Documentation) or the CEL Statement Widget Type in Common Parameter Widgets.

When applying in a non-immediate state, enabling this results in the script running at every location beneath the assigned locations. In general this is more efficient than using an equivalent recursive CEL statement.

You can also override the ops.*.recursiveEnable attribute anywhere deeper in the tree to exclude evaluation at those locations. This is similar to the behavior of the visible or light linking attributes.