Limitations

Connections to String Parameters

A custom operator cannot connect directly to a string parameter. To read or write to a string parameter from a custom operator connect to the object (for example a CustomProperty or CustomProperty) that owns the parameter.

Blocked Methods and Properties

• Certain methods and properties are blocked in the context of custom operators (the same is true of legacy and runtime operators). You must never attempt to change the value of the input or read elements of the scene that are not connected as inputs.

  If you need to know whether the method or property you want to use is safe for custom operators you can refer to the individual reference page for that item. It will be marked with an asterisk (*) beside its name if it can be safely used.

Commands Cannot Be Used

• You must never try and call a command from inside an operator, unless that command does not affect scene data at all (for example PickObject).

• Commands that generate geometry or scene objects (such as CreatePrim and AddNull) as well as any command that changes topology or adds items to a cluster, etc. are strictly off-limits, as they change scene data and may destabilize Softimage.

Topological Changes

• Topological changes are not allowed for custom operators, since this type of change can destabilize the integrity of the geometry.

Restrictions on Scene Time

• You cannot read the scene graph at any other time than the time at which the operator is being evaluated. However, as a workaround you can cache the data inside the operator, if the scene is carefully evaluated from beginning to end. See the ParticleOp example for a demonstration of how you can implement this kind of workaround.

• You cannot assume that the time the operator is evaluated at is the current time as set by the Playback Controls or that there is only one evaluation per frame. You can use OperatorContext.Time or OperatorContext::GetTime to get the current evaluation time.

Setting Up Deformer Connections

• Deformer operators must define their input and output connections within the same port group.

• There is no way to get bounding box information on branch/grouped geometry for deform.

Multiple Connections in Port Groups

• It is recommended to keep connections unambiguous by using one port for each port group if possible. For dynamic operators, you can define one port with many instances. See Static versus Dynamic Operators for more information.

Issues with Persistence

• One of the many uses for custom operators is to write a custom particle simulation. The particle types defined for a scene are stored in the "Scene.ParTypes" container. Remember that although you can connect to "Scene.ParTypes", the connection will be lost when the scene is reloaded.

Working in Branch or with Groups

• Objects added or removed from a group or hierarchy are only automatically connected to or disconnected from a custom operator if and only if the custom operator defines an output port that writes to a primitive. This is a known limitation of the group/branch operator functionality.

• If a PortGroup defines a Filter and the operator supports branch group connections, then the filter must include the group filter. This ensures that the ApplyOp command or the Operator.Connect method will validate the input objects when applying the operator to an object in branch or on a group object.

• The group/branch flag only works for IO ports on a Primitive.