Page MenuHome

Drivers in Armature layer or in Bone Layers lock linked armature
Closed, ResolvedPublic

Description

Ubuntu 13.04 64 bits

Hash: 17a4ba2

I've attached a sample blend file with 2 Armatures that belong to 2 different groups that are called as follows:

armature_layers
bone_layers

Well, the name of the group correspond to where I have added a driver in the armature. So, one armature has a driver in the armature layer properties, and the other one has it in the layer properties of one of its bones.

Now, If you link these groups into a new blend file and make a proxy of each armature, you'll notice that in the latest GIT, everything gets locked, that is, you can't move any bone in pose mode, and not even the empty of the group. I've come to the conclusion that these drivers, which were working perfectly well with linked rigs in 2.69, are the cause of the problem in GIT.

Event Timeline

Juan Pablo Bouza (jpbouza) created this task.
Juan Pablo Bouza (jpbouza) raised the priority of this task from to Needs Triage by Developer.

Trying to attach the blend file again. Guess it didn't work last time

I can see the difference, however both 2.69 and latest Git find dependency cycles in this file:

Dependency cycle detected:
  Bone_Layer depends on bone_layers_proxy through Proxy.
  bone_layers_proxy depends on Bone_Layer through Driver.

Dependency cycle detected:
  Armature_layers depends on armature_layers_proxy through Proxy.
  armature_layers_proxy depends on Armature_layers through Driver.

Maybe @Sergey Sharybin (sergey) knows if dependency cycles are handled different now in the threaded depsgraph, but these cycles can give problems in various situations and should be avoided.

That's what i'm fighting right now.

Currently all the objects from the cycle are not updated. which is a real bummer. However, i don't know yet what would be the correct order of update in such situation.

Sergey Sharybin (sergey) triaged this task as Confirmed, Medium priority.Jan 10 2014, 9:58 AM