Replicating "choice" EM flow

[simon_ridden]

I'm trying to make a custom MPxNode evaluate only selected elements from an array input under Evaluation Manager. The node has an index selector input that decides which array element to use.

In DG mode this can be done by overriding setDependentsDirty() and only marking the output dirty when the dirtied element matches the active index. That gives true lazy evaluation.

Under parallel mode, setDependentsDirty() is never called. Instead preEvaluation() runs, and the system always dirties the parent array plug. You can detect dirtiness in preEvaluation(), but you cannot change it. EM has already built the evaluation graph, so every element of the array input will still be pulled. As a result you must rely on attributeAffects (Which cannot capture which option is "chosen").

So upstream nodes for all array elements are evaluated even when only one is needed. You can skip computation in compute(), but you cannot stop EM from evaluating inputs.

The docs lack any examples showing such "choice" implementations, I'd note the maya "choice" node somehow achieves clean/lazy parallel eval without over-zealous input dirty propagation.

How can a devloper replicate this?

[brentmc · Accepted solution]

Hi,

There is nothing special about the built-in choice node and when it's compute is called it just evaluates the (single) active input connection and copies that value to the output.

It also doesn't override setDependentsDirty and uses attributeAffects to specify the relationship between the inputs and output. It also shandles passthrough for the active input.

Finally, I don't think there is any special handling in EM so it is possible that all the upstream input nodes are evaluated since that is basically how EM works.
So. it is not uncommon for EM to evaluate more nodes that would have been evaluated by DG evaluation but that is usually outweighed by the gains achieved by parallelism.

See https://www.autodesk.com/using-parallel-maya for more details

[simon_ridden]

Perhaps passThrough is the magic sauce here.

The node I was implementing took in inputs - chose 1 - performed operations on that 1 - output new data.

I'm now structuring those "operations" into a separate node and then using the choice node to choose what it operates on. Here's hoping the graph prefers that structure.