Hey there,
I was wondering if anyone is also in the situation to get aquainted with the new Evaluation Manager mechanisms introduced to the API in 2016. There is this simple example called “simpleEvaluationnode” to illustrate the preEvaluation method but what it does not show is how the bookkeeping of expensive calculations can be handled on non-trivial attributes, like compound arrays. What would de interesting to know is how they would differentiate between a necessary and unnecessary calculation. Right now I fail to see how this example serves the purpose as there is an attributeAffects relationship set between input and output attributes in the initialize method. In this case one wouldn`t bother to use setDependentsDirty anyway, right? So if anyone has some more info bits they could share I would highly appreciate it.
Thanks and cheers,
Jan
MPxNode::preEvaluation
So far my observation is that preEvaluation gets called when changing time by scrubbing, playback or just jumping around in the timeline, but not when manipulating attributes on a node, by setting values in the channelbox for example.
Edit: as soon as an attribute has at least two keys the preEvaluation of the Evaluation Manager kicks in, just like stated in that Parallel Maya pdf on page 3.
So I got this to work and now my test rig is actually 6 times faster in Parallel mode than it is in DG mode, which is quite nice. I still have a problem with the fact that AD devs assume that attributes only get keyed when their values change. While from a logical standpoint totally valid, I have seen thousands of keys on attributes that never change. It is simply what animators do when they block out the animation they key ALL attributes and rarely have I seen folks who would then clean up those redundant keys moving forward on production rigs.
Bear in mind a couple things:
EM only kicks in in play mode (timeline clicks count as play), and so do its circumstances, while manipulation is still happening in DG mode (which is why you often need to do stupid things such as plug checking both a compound and its members because EM and DG differ in those regards).
The keying requirement is obnoxious, but they needed to start somewhere to figure out the eval scheme since the more traditional/previous methods would either be inefficient or unreliable.
Are you still having issues with pre eval or does it make sense now? And yes, the book-keeping is entirely up to you.
Hey JacO, thanks for chiming in, I understand now why you called this thing a ballsy move in another thread; ) yeah I understand they needed to start somewhere and that what its looks like. My main issue is now less the preEval thing which as you say only kicks in during playback/scrubbing but more the "traditional" side of things. They may say it is the good ol DG as we know it, but I don´t believe it since the main issue I am facing now is loading time of scenes. Scenes that took maybe 4-5 seconds to load in 2015 require about 10 min. with no code change and 2 min. with the new “optimization” I am still in the process of checking out what causes the actual bottleneck, meaning why are there so many recomputations of certain nodes when the old bookkeeping worked just fine and the new one does not really seem to catch the curve ball, yet. But once the EM kicks in I am really happy to have a fairly complex rig at 60 fps.
That’s a peculiar change to come from just implementing pre-eval, and in theory there should be no significant calls to it until play anyway.
Is it possible the pre-eval dirties easily or allocates a lot more often than the book-keeping you were doing before?
As a test try and set those nodes to frozen, save, then load, and see if it still takes that long (if it does then chances are there’s something going on graph wide rather than with those pre-evals alone).
I just compared the values between DG and Parallel mode on the rig that I am using and that is where I saw this perforamnce increase. Now I am getting around 30 fps in DG and around 65 fps in parallel mode. I compared it now to Maya 2015 with same animation and same VP2 settings and it seems that 2015 is actually around 5fps faster at the moment at around 70fps. :surprised
Next to implementing the preEval method I also disected my rig and found some constraints to be the heavy hitters in regards to performance clutches as they query worldMatrices here and there which I try to replace with alternatives that work in local transformation space. So when I compare the scene load time now down to 40 seconds which is not great but at least I am making some progress.
What is a real bummer is that the “old” DG in 2015 is actually more than twice as fast as the new DG and a little faster than the new Parallel mode. Certainly I am not building your typical maya rig but still there is enough vanilla maya DG stuff that could shine a little bit more with the new fancy Parallel stuff. This observation also underlines to me that the DG mode in 2016 is not the same as in 2015.
Next I think trying to see what different schedulingTypes will yield performance-wise.
Buexe you should jump over to the maya beta and talk tirectly to the developers there is a lot going on.
I guess this turns out to be more of a performance optimization thread but anyway, I just found out that the new “Hide during Playback” button in the Display Editor in 2016 was the source of the difference in playback performance I mentioned earlier. Using this to hide objects during playback is not as fast hiding the layer altogether, which in my case makes about 5 fps of a difference.
Thanks, Oglu. So after further optimizations in my rig structure ( less constraints and removing cyclic connections as stated in the pdf ). I get now the following results:
All characters are referenced, each character has no smooth preview, shaded with, no anti-aliasing or other fancy VP2 stuff, simple animation keys on all attributes ~4000 ), poly count per character is around 7000 vertices
DG mode
1 character ~17fps
2 characters ~15fps
3 characters ~13fps
4 characters ~12fps
Parallel mode
1 character ~80fps
2 characters ~50fps
3 characters ~40fps
4 characters ~30fps
So the parallel mode seems to serve its purpose here. Another observation I made is that turning off the visibility of a character`s objects via display layers is not the same as removing them from the scene. For example if I remove all but one character in the DG mode I get a playback performance of around 42 fps while only ~17 fps when the other characters are hidden.
So far so good…