GenericOp

Specifies the type of the Op to run, for example, AttributeSet.

Add a new opArgs parameters from the Add dropdown list. The available options are described in greater detail in Adding User Parameters.

• Number

• String

• Group

• Number Array

• String Array

• Float Vector

• Color, RGB

• Color, RGBA

• Button

• Toolbar

• TeleParameter

• Node Drop Proxy

If enabled, adds a 'system' opArg containing information from the graph state time slice, such as frame and shutter timings. This is only necessary for some Ops.

Determines when the Op 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.

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.

When executionMode is set to immediate, 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.

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 valid 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.

For more information on the location widget parameters, see Common Parameter Widgets.

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.

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.scenegraphLocationModifers 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 are executed just after the initial values for the material shader are created at the location. Examples of its use include randomizing or building procedural control over shader parameters.

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

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.

The name of the attribute group under which to store the Op type and args.

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 valid 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.

When applying in a non-immediate state, enabling this results in the Op 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 applyWhen is set to during op resolve, you may specify a space-delimited list of strings to indicate that this Op 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 Op 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.