Parallel evaluation wisdom



I haven’t been able to find a good, solid base for how to properly take advantage of the new parallel system, and I’m sure some of you gods have a nugget or two to share on it. The docs give general advice like “don’t connect anything in an arm to a leg” (visionary, I know), and give some pretty good information on how it interacts with other factors like GPU processing, but in terms of actual granular rigging practice, they’re sparse.

For example, say I’m working with a live curve, and I need to sample 100 positions on it, using pointCurveInfo nodes. Under the new rules, those nodes will all be evaluated concurrently, giving pretty decent speed - but at what point does the original node become a bottleneck, trying to serve many connections at once? Would it be more efficient to first pass the curve information to (say) 10 dummy shape nodes, with each serving 10 pcis?

I’d really like to hear any experience that anyone has in optimising for the new world - doesn’t seem like the major studios are prioritising it yet


Raffaele over at Cult of Rig had some really good notes on why and how.


Also check out this article. I link it every time someone asks about parallel eval. This is the first resource I based off of.

I found this whole process really frustrating on a previous project. Even as we made big gains in speed, we would experience horrible bugs like limbs popping (sometimes caused by compound attribute connections. ie. .colorRGB to .translate instead of .colorR to .translateX, etc.) and geometry not following the rig.

So 80% of the time, I kept getting tickets that the rigs were slow again, and it was just the animators turning off parallel eval, to avoid all these Maya bugs.

Another thing to watch out for is nodes which block parallel eval. For example the TDs on a project put a particle under the render camera to track the camera motion/velocity. But that particle disabled parallel eval. So taking advantage of parallel also becomes a bit of a holistic studio cooperative effort, frought with bugs.

rigidBody dynamics also blocked it, as of 2017.

Here is a script I wrote that queries and disables blocking nodes (it doesn’t disable the nodes, it disables parallel from trying to evaluate them, thus blocking everything else from parallel). Animators could run this to speed up their animation scenes, until we could finish optimizing the rigs, cameras and scene files:

# Find the nodetype by who is blocking parallel evaluation. Then disable each type 
import pymel.core as pm
import maya.mel as mel

blockingNodes = mel.eval('evaluator -name "dynamics" -valueName "disabledNodes" -query;')
# This returns strings for MEL later. Needs to be Pythonified and de-MELLED.
blockingTypes = [str(pm.PyNode(x).type()) for x in str(blockingNodes).split('\n') if x]

for eachType in blockingTypes:
    mel.eval('evaluator -name dynamics -c "disablingNodes=none";')
    mel.eval('evaluator -name dynamics -c "handledNodes={}";'.format(eachType))
    mel.eval('evaluator -name dynamics -c "action=evaluate";')


Oh yeah, and if you have geometry which is keyed in visibility, then if you turn the visibility off, and then on again, sometimes the geometry will no longer refresh until you do a “GPU kick”, which is Autodesk’s official suggestion to turn parallel eval off and back on again. (as of Maya 2017. I haven’t done tests in 2018 yet.)