This section explains API classes and methods used to add custom evaluators to Maya. Custom evaluators let users override how DG nodes are scheduled and executed by the evaluation manager. If you're unfamiliar with the scene evaluation changes introduced in Maya 2016, see the Improving Performance with Parallel Evaluation whitepaper at http://www.autodesk.com/maya-docs for a more detailed summary.
This section contains a brief review of how the evaluation manager builds, partitions, and schedules the evaluation graph, followed by an introduction to new API classes, and then closes with a simple example to motivate usage of new API classes; see the devkit for additional examples.
The Evaluation Manager (EM), introduced in Maya 2016, improves playback and manipulation performance by supporting concurrent evaluation of dependency graph (DG) nodes.
The EM uses specialized evaluators to enable customized handling of different parts of the scene. Maya 2016 includes 3 such evaluators:
|Deformer||Takes advantage of GPU hardware to deform dense geometry more quickly|
|Dynamics||Detects if the scene contains unsupported legacy dynamics and disables parallel evaluation|
|Prune Roots||Groups animation curves during evaluation to reduce node-scheduling overhead|
The EM performs 3 key steps when evaluating your scene: graph construction, graph partitioning, and graph scheduling, each described below.
Unlike classic Maya evaluation, the EM does not rely on dirty propagation to determine what to evaluate at every frame. Instead, the EM builds an evaluation graph (EG) that encodes dependencies between DG nodes.
During EG construction, a list of plugs is built for each animated node. This list contains all plugs required by downstream dependents on a given node, guaranteeing that all upstream dependencies are up-to-date whenever a specific node is evaluated.
Once the EG is built, the EM must calculate how different parts of that graph will be evaluated. To do this, enabled evaluators are allowed to claim ownership for node sub-graphs, in priority order. To claim nodes, evaluators must mark nodes as being of interest.
During traversal, any node-level cycles with 1 or more outputs connected to 1 or more inputs are grouped into clusters by the EM. Sub-graphs claimed by different evaluators are also added to clusters.
Clusters are evaluated together as a single unit and are mutually exclusive (that is, an evaluation node can belong to one cluster at most). Hence, the set of all clusters provides a partitioning of the EG.
Clusters are layered in a hierarchy such that if the current cluster fails to evaluate a node, control is passed to the parent cluster. In decreasing order of priority, cluster layers are:
|Custom||Layer for custom evaluator clusters. Once a node is in a custom evaluator's cluster, that evaluator takes responsibility for its evaluation.|
|Cycle||Layer for DG node-level cycles (for example, constraints, and so on,) that often require special evaluation to ensure correctness.|
|Base||The default, no cluster, layer. Nodes are evaluated directly without special treatment.|
After partitioning, the EM must schedule nodes for evaluation in the correct order. Nodes are scheduled so that upstream nodes are evaluated before all dependents. Beyond this, it's not possible to guarantee any particular order of evaluation.
For example, in the simple graph,
node A always evaluates before B. For a more complex graph,
although A is guaranteed to be evaluated before B and C, there are no guarantees about the exact timing of evaluation for B and C. Depending on the scheduling type of B and C, they could be evaluated simultaneously.