DG vs Parallel evaluation update issues

[Sebastian_Wiendl]

Hi everyone,

I have encountered an issue where the values of keyframed parameters are not updated in the Attribute Editor when I am in Parallel mode. DG evaluation mode works fine.

i.e. if I have a keyframed float and step through the timeline one frame at a time, the value in the attribute editor updates as expected in DG mode, but always stays the same in Parallel.

In addition, I have got custom manipulators (inherited from MPxManipContainer) that link to keyframed attributes. For example keyframed manipulator position. Drawing of the manipulators does not take the keyed value at the current frame into account unless I am in DG. Parallel does not work. 

Now, I understand that there are a few similar posts to this out there:

https://forums.autodesk.com/t5/maya-shading-lighting-and/maya-2018-1-bug-shading-parameters-ignore-k... 

https://forums.autodesk.com/t5/maya-forum/maya-2018-update-1-dg-animation-still-broken/td-p/7441411  

When looking at: 

https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2019/ENU/Maya-Rel...  

"Shading parameters ignore keyframes in parallel evaluation MAYA-88014"

I thought, the issue might be solved for me, but it is still there is Maya 2019.

Is there any way to technically solve/circumvent the issue (besides switching from Parallel to DG)?

I'm using C++, python, or mel, hence I don't mind if there is a rather technical solution to the issue.

Also, is there a bug fix on the way?

Any help and info is much appreciated.

Cheers,

Sebastian

[kevin.picott]

Does it happen to work if you disable the invisibility evaluator (that feature is in the Evaluation Toolkit)? Would you be able to post a small scene illustrating the problem?

[Sebastian_Wiendl]

I tried disabling the invisibility evaluator, but that does not seem to have any impact.

I am still struggling getting you a reproducible that does not use company internal code.

In the meantime, is there anything else you can think of that would prevent the attribute editor from updating the values of keyframed attributes in Parallel evaluation mode?

Thanks for your help.

Sebastian

[kevin.picott]

It depends on whether the problem comes from the value not updating or the editor not updating. You could try this command to see if the value is correct in the node:

maya.cmds.dbpeek( op='node', a='datablock' )

If the value is updating correctly can't offhand think of why the attribute editor would not update. If you do a "getAttr" on the attribute do you then get the correct value? What about showing the channel box instead of the attribute editor - does it update?

[Sebastian_Wiendl]

Thanks so much for the suggestions.

Here is what I got:

• maya.cmds.dbpeek( op='node', a='datablock' ) gives me the correct values
• getAttr (python and mel) gives me the wrong values
• Channel Box behaves as Attribute Editor, i.e. wrong.

I did some more testing in the c++ code and when I add a line to the compute function that reads the value of the attribute (via GetDataHandle(...).asFloat()) at every frame, it updates the value (for that attribute) in the Attribute Editor.

But if I don't, it doesn't.

Any ideas?

Cheers,

Sebastian

[kevin.picott]

It sounds like the attribute might be marked as an input in the evaluation graph but your compute method is not using it, therefore it's not getting updated properly. (The evaluation graph calls compute on outputs that are part of the graph and relies on that to pull inputs across from their connections.) Or maybe it has no "affects" relationships at all so nothing is scheduled to compute.

You can dump the evaluation graph contents through the "03) Debugging -> Evaluation Graph Inspection" section of the evaluation toolkit (enabling "Show Plugs" for the "Visualize Graph" option). What I suspect you'll see is your attribute in your node as an input but no corresponding output.

The one thing that doesn't explain is why a getAttr wouldn't return the correct value. If anything I'd expect the dbpeek to show the wrong value and the getAttr to show the right one. Is there any other code modifying this value anywhere that could be overriding the connection value somehow?

The workaround you've added is what the code is expecting. A floating input that doesn't get pulled on in a compute method is unusual, though not unheard of.

[Sebastian_Wiendl]

Thanks a lot for all of the information. I'll need a few days to digest and test some more and will get back to you.

One thing that still does not make much sense to me is why the behavior is different between DG and Parallel Evaluation Mode.

Cheers,

Sebastian

[kevin.picott]

That's fairly easy to describe. The DG operates based on as-needed pull evaluation - nothing evaluates until a request is made for a certain value, and then only the inputs required to generate/update that value are evaluated in turn. e.g. if you requested to evaluate translate the DG would not evaluate rotate as well since it's not required in order to get the translation.

The EM operates with a global evaluation model, gathering everything that needs to evaluate for a frame (since it only evaluates animated entities) and then schedules it for evaluation using a push model; inputs first, then the outputs that use those inputs.

The fundamental change in evaluation model was needed in order to support parallel evaluation - the DG couldn't know in advance which nodes would be requested so scheduling safe parallel evaluation was impossible. The EM restricts itself to animated values to avoid the otherwise prohibitively large number of connections and evaluations that would be in the graph.

Some heuristics, such as the invisibility evaluator, were added as optimizations to prevent evaluations in the EM that  aren't strictly required in order to correctly render the scene. You can see these and other detailed explanations in our parallel evaluation whitepaper - https://knowledge.autodesk.com/support/maya/learn-explore/caas/simplecontent/content/using-parallel-...