Custom evaluator overview

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.

Introduction

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:

Evaluator	Details
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

Evaluation Manager Review

The EM performs 3 key steps when evaluating your scene: graph construction, graph partitioning, and graph scheduling, each described below.

Graph Construction

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.

Graph Partitioning

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:

Layers	Details
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.

NOTE:Clusters are created and destroyed during graph construction and scheduling. If the graph is invalidated, clusters will be destroyed. Custom evaluators should rely only upon cluster initialize and terminate callbacks and never cache pointers to the previous cluster. Currently, each cluster is represented and scheduled as a single unit, allowing custom evaluators to handle nodes as desired.

Graph Scheduling

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.

NOTE:If a node is frozen, even if scheduled, its evaluation is skipped.

Custom Evaluator API