Page MenuHome

Bone driver leading to cyclic dependency (used to work in 2.79)
Confirmed, NormalPublicTO DO


System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 419.67

Blender Version
Broken: version: 2.80 (sub 69), branch: master, commit date: 2019-05-18 09:53, hash: rB7fd015bb70b2
Worked: 2.79b

Short description of error
When the scale transform value of a bone is driven by its rotation value, a cyclic dependency is reported in the console (and it slows down script execution).
This scenario used to work in Blender 2.79 without cyclic dependency.

Exact steps for others to reproduce the error

  • Open the following blend file, it just contain a bone with a driver: rotation.x -> scale.y:

  • See the error message in the console

Event Timeline

Brecht Van Lommel (brecht) lowered the priority of this task from 90 to 80.

As far as I know this case is not considered a bug. While in some situations it might work, in general there is an actual dependency cycle here both in 2.79 and 2.80.

lucas veber (lucky3) added a comment.EditedMay 18 2019, 2:02 PM

It would be sad if it's not considered as a bug. Most 3D softwares out there can do this... it would be quite a limitation for rigging :'-(
Blender riggers were so happy to hear that 2.8 dependency graph is supposed to be more powerful than Blender 2.79 one... In this case it would be a regression.

The dependency graph should treat any properties with a driver as separate evaluation nodes (like with custom properties), or treat the driver evaluation nodes themselves as representing it.

I.e. when another driver depends on such property, it should depend on the introduced placeholder node, or the driver node that actually generates the value, instead of depending on the nodes that actually evaluate the bone and don't influence the value of the property in any way. In general, it may be that all dependencies on 'animatable' properties should depend either on the input driver (if exists), the animation node, or just COW if it's not animated at all - but never on the bone nodes, because if the property is actually influenced by evaluating the bone, it should not be animatable.

There already is code to track which properties are animated, so it probably should not be that difficult to extend that system to this use?

@Alexander Gavrilov (angavrilov) I agree, that would be a good way to go.

As it stands now, however, this seems to be a known limitation of the current design, rather than a bug. When I rotate the bone in the example blend file, the scale is updated via the driver as well, so in a sense it "works". The fact that 2.79 didn't detect/complain about this is a different thing.

Evan Wilson (EAW) changed the task status from Needs Developer to Reproduce to Confirmed.Feb 28 2020, 1:17 AM

Just a note: using self as a python expression fixes this. (or maybe just quiets it?)

I commented about this in another bug report (not sure which one). But I think part of the problem here is that we have no clear distinction between transform values before and after constraint evaluation.

We should have a transform channel input variable setttings that lets you use the transform before or after constraints Then you don't need to use RNA paths for this kind of setup at all.

For the RNA path in this file, I think that should be considered the transfrom before constraints, and probably the relation here is set up assuming it's the value after constraints (which would be a cyclic dependency in general)?

Yeah, this is quite limiting in rigging. Having one transform channel dependent on another one is quite common - a jaw hinge or even simple rolling action. Having to create multi-bone rig for that seems wasteful.
It works however for some reason to use Self pointer (which often is an invaluable saver btw). But unfortunately, it requires allowing script execution regardless of what it tries to access, and that is a source of problems in collaborative projects, not to mention safety.

I'm totally blabbing here, but could a transformation channel driver that is not referring to any external (other object) variables be evaluated immediately after the transformation at all times? I don't know if it is possible, but from rigger's logic there's no use in treating driver as a separate evaluation node in case like this. I mean - if someone creates a loop this way - there's nothing anyone could do about that anyway.