Rig slowdown on getAttr(time=1)

[marcuso]

Hi all,

I’ve hit an interesting problem that I hope you can help me with, and have narrowed the problem down to a minimal scene.

• maya_bug2015-2016.ma (39 kb)

In a nutshell:

1. On scene open, the scene is fast
2. On querying transforms at e.g. time=1, the scene is 50x slower (see below)
3. Only happens in Maya <=2016
4. In the scene, ikHandle nodes for the legs, decomposeMatrix for IK/FK switch and driving the meshes with the control rig and switch for toggling IK and FK.
5. With IK deleted (even though it’s hidden and not in use) the scene is quick again.
6. On deleting history for the boxes, the scene is 2x+ faster; they have polyCube and others plugged into it.

(5) is perhaps the biggest clue.

# Source of error
from maya import cmds

nodes = cmds.ls(type="transform")
for node in nodes:
    cmds.getAttr(node + ".tx", time=1)

The lines of Python I’m running are these, notice the time=1 argument; without it, there isn’t a problem. In the videos, notice how the scene is fast until I run the above script, after which it’s 50x+ slower.

What I’m looking for is either…

1. A way to avoid it happening or…
2. A way to escape it after it has happened.

Any ideas?

2015 SP6	2016 EXT1 SP6
2017	2018 Update 4

[marcuso]

Oh, and a few more things.

• The problem only occurs on moving the manipulator. Playback is unaffected.
• The problem appears in Maya 2015 SP3+, SP2 is fine

Mystery!

[stwert]

Is this something you can narrow down by looking at the Profiler? See if you can see exactly what is taking so much time to calculate? Probably in the VP Evaluation section?

[marcuso]

Thanks @stwert, good idea, here’s what it says from moving the character around like in the above gifs.

I’ve highlighted one of many dirty propagations taking 500+ ms.

And here it is before running the lines of Python, 2 ms.

[stwert]

Just a thought, is the evaluation mode set to different modes in your different applications? E.g. is it parallel evaluation in the versions where it remains speedy? I don’t know too much about how dirty propogation works, so I’m not sure I can solve the problem itself, but I wonder if forcing all nodes to be dirty or clean might reset the issue. https://download.autodesk.com/global/docs/maya2014/en_us/Commands/dgdirty.html

[marcuso]

Good thoughts.

1. The problem appears in both 2015 and 2016, 2015 only has one evaluation mode so it’s likely not related to the new parallel evaluation
2. Forcing a refresh did not have any noticeable impact, are there any other commands to try?

cmds.dgdirty("*")
# Result: 1968 # 
cmds.dgeval("*")
# Result: 0 # 
cmds.dgeval(cmds.ls())
# Result: 0 # 
cmds.refresh(force=True)

[marcuso]

Some more clues.

from maya import cmds
cmds.ikSystem(e=True, sol=False)

This “solves” the issue, but then obviously disabled IK.

Also I found that there was 6 choice nodes making a difference.

# "Fix"
for choice in cmds.ls("*Leg1Choice*", type="choice"):
    for connection in cmds.listConnections(choice + ".selector", plugs=True) or []:
        cmds.disconnectAttr(connection, choice + ".selector")
    cmds.setAttr(choice + ".selector", 1)

These nodes are used to choose between IK and FK. What’s interesting is that the problem appear when IK is disabled. However, deleting the ikHandle nodes also restored performance.

My theory is that even though IK is hidden and unused, it’s causing dirty propagation when it shouldn’t.

[EdArt]

Interesting - are the choice nodes between the effector and the joint root?

[marcuso]

So the choice nodes are fed the joint matrices of the IK chain, and the matrices of the FK chain, outputting onto a third chain which is the result of switching between them.

There aren’t any choice nodes going into the IK, or sitting in the midst of the effector and joints. The interesting bit, as mentioned above, is that the choice nodes are all set to output the FK; the IK chain and solver shouldn’t even run, but because the query above queries all transforms, including the hidden IK joints, my guess is that it somehow gets confused.

I’ve worked around the problem temporarily by replacing those choice nodes with wtAddMatrix nodes. Same principle, same usage, but no problem. There are still choice nodes elsewhere, so I expect to run into it again at some point. Since I don’t yet understand why it happens at all, it’s also possible it may happen for nodes other than choice nodes, and nodes other than IK solver-related ones.

Do open the scene and have a play. It’s becoming one of the five wonders of the world over here.