Bone driver leading to cyclic dependency (used to work in 2.79) #64793

New Issue

lucas veber · 2019-05-18T13:06:14+02:00

lucas veber commented

2019-05-18 13:06:14 +02:00

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: 7fd015bb70
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:
driven_bone_cyclic_dependency.blend
See the error message in the console

**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: `7fd015bb70` 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: [driven_bone_cyclic_dependency.blend](https://archive.blender.org/developer/F7045163/driven_bone_cyclic_dependency.blend) - See the error message in the console

lucas veber commented

2019-05-18 13:06:14 +02:00

Added subscriber: @LucasVeber

blender-admin commented

2019-05-18 13:06:14 +02:00

#73236 was marked as duplicate of this issue

blender-admin commented

2019-05-18 13:06:14 +02:00

#69101 was marked as duplicate of this issue

blender-admin commented

2019-05-18 13:06:14 +02:00

#72899 was marked as duplicate of this issue

blender-admin commented

2019-05-18 13:06:14 +02:00

#71540 was marked as duplicate of this issue

blender-admin commented

2019-05-18 13:06:14 +02:00

#66883 was marked as duplicate of this issue

blender-admin commented

2019-05-18 13:06:14 +02:00

#65570 was marked as duplicate of this issue

Brecht Van Lommel commented

2019-05-18 13:36:02 +02:00

Added subscriber: @brecht

Sergey Sharybin was assigned by Brecht Van Lommel

2019-05-18 13:36:02 +02:00

Brecht Van Lommel commented

2019-05-18 13:36:02 +02:00

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 commented

2019-05-18 14:02:23 +02:00

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.

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.

lucas veber commented

2019-05-22 14:26:25 +02:00

Added subscriber: @angavrilov

lucas veber commented

2019-05-22 14:26:25 +02:00

@angavrilov , if I may ask, maybe you know a fix for this?

Sergey Sharybin commented

2019-06-07 15:52:07 +02:00

Added subscribers: @aroefer, @Sergey, @JacquesLucke

Sergey Sharybin commented

2019-07-15 16:01:15 +02:00

Added subscribers: @christopher.burns, @mano-wii

Sergey Sharybin commented

2019-11-14 17:14:29 +01:00

Added subscriber: @NizarAmous

Sergey Sharybin commented

2020-01-06 11:17:33 +01:00

Added subscribers: @piotr-14, @lichtwerk, @dr.sybren

Sergey Sharybin removed their assignment 2020-01-06 11:18:07 +01:00

Philipp Oeser commented

2020-01-06 15:17:01 +01:00

Added subscriber: @Chalouek

Alexander Gavrilov commented

2020-01-14 11:36:24 +01:00

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?

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?

Sybren A. Stüvel commented

2020-01-14 15:32:11 +01:00

@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.

@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 commented

2020-01-26 18:02:13 +01:00

Added subscribers: @olsarxd, @EAW

Evan Wilson commented

2020-02-28 01:17:29 +01:00

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Evan Wilson commented

2020-02-28 01:17:29 +01:00

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

driven_bone_cyclic_dependency_fixed_with_self_python_expression.blend

Just a note: using self as a python expression fixes this. (or maybe just quiets it?) [driven_bone_cyclic_dependency_fixed_with_self_python_expression.blend](https://archive.blender.org/developer/F8376517/driven_bone_cyclic_dependency_fixed_with_self_python_expression.blend)

Brecht Van Lommel commented

2020-02-28 14:39:20 +01:00

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)?

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)?

Konstantins Visnevskis commented

2020-05-08 16:34:09 +02:00

Added subscriber: @KonstantinsVisnevskis

Konstantins Visnevskis commented

2020-05-08 16:34:09 +02:00

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.

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.

Sybren A. Stüvel commented

2020-11-16 15:52:46 +01:00

Reclassifying this task from TODO to Design, as the task is not concrete enough to actually start implementation.
See the 2020-11-12 module meeting notes for more information.

Reclassifying this task from TODO to Design, as the task is not concrete enough to actually start implementation. See the [2020-11-12 module meeting notes](https://devtalk.blender.org/t/2020-11-12-animation-rigging-module-meeting/16092) for more information.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Bone driver leading to cyclic dependency (used to work in 2.79) #64793