Loop of Bones, each with a "Locked Track" Constraint, results in one bone bugging out #95466

New Issue

Robert Schultz · 2022-02-03T11:50:18+01:00

Robert Schultz commented

2022-02-03 11:50:18 +01:00

System Information
Operating system:
Graphics card:

Blender Version
Broken: 3.01

I have an armature with several bones, with each bone having no parent. Each of these bones has a "Locked Track" constraint such that it is looking at the bone ahead of it, forming a loop. The bones also have the "follow path" constraint and are animated around some curve. What happens is that one of the bones always shows some strange behavior when time is moved forwards or backwards. Dragging the timeline back and forth results in it momentarily misaligning from pointing at the bone ahead of it, but then it realigns a split second later. However, if I then alt+scroll to move time, the bugged bone remains in it's misaligned state, at least until I drag the timeline again, and then it realigns.

On the python side of things, this buggy behavior carries over. Using bpy.context.scene.frame_set(), and then taking the bone's matrix data for export, gives the misaligned position/rotation. And it's only when I call bpy.context.scene.frame_set() a second time that it gives the correct aligned position/rotation.
So to be clear, this is what I have to do to go the next frame and not have it result in the wrong output:

bpy.context.scene.frame_set(frame_num)
bpy.context.scene.frame_set(frame_num)

Exact steps for others to reproduce the error
Here's a blender file with a simple set up of 6 bones animating around a circular bezier curve:
Looped Locked Track Bug Example.blend
I've named the problematic bone "Bugged Bone".

**System Information** Operating system: Graphics card: **Blender Version** Broken: 3.01 I have an armature with several bones, with each bone having no parent. Each of these bones has a "Locked Track" constraint such that it is looking at the bone ahead of it, forming a loop. The bones also have the "follow path" constraint and are animated around some curve. What happens is that one of the bones always shows some strange behavior when time is moved forwards or backwards. Dragging the timeline back and forth results in it momentarily misaligning from pointing at the bone ahead of it, but then it realigns a split second later. However, if I then alt+scroll to move time, the bugged bone remains in it's misaligned state, at least until I drag the timeline again, and then it realigns. On the python side of things, this buggy behavior carries over. Using bpy.context.scene.frame_set(), and then taking the bone's matrix data for export, gives the misaligned position/rotation. And it's only when I call bpy.context.scene.frame_set() a second time that it gives the correct aligned position/rotation. So to be clear, this is what I have to do to go the next frame and not have it result in the wrong output: ``` bpy.context.scene.frame_set(frame_num) bpy.context.scene.frame_set(frame_num) ``` **Exact steps for others to reproduce the error** Here's a blender file with a simple set up of 6 bones animating around a circular bezier curve: [Looped Locked Track Bug Example.blend](https://archive.blender.org/developer/F12843454/Looped_Locked_Track_Bug_Example.blend) I've named the problematic bone "Bugged Bone".

Robert Schultz commented

2022-02-03 11:50:18 +01:00

Added subscriber: @Robert-Schultz

Philipp Oeser commented

2022-02-03 12:17:27 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-02-03 12:17:27 +01:00

Changed status from 'Needs Triage' to: 'Archived'

Philipp Oeser closed this issue

2022-02-03 12:17:27 +01:00

Philipp Oeser commented

2022-02-03 12:17:27 +01:00

This is a dependecy cycle:

Dependency cycle detected:
  OBArmature With Bugged Bone/Bugged Bone/BONE_CONSTRAINTS() depends on
  OBArmature With Bugged Bone/Bone1/BONE_DONE() via 'Locked Track'
  OBArmature With Bugged Bone/Bone1/BONE_READY() via 'Ready -> Done'
  OBArmature With Bugged Bone/Bone1/BONE_CONSTRAINTS() via 'Constraints -> Ready'
  OBArmature With Bugged Bone/Bone2/BONE_DONE() via 'Locked Track'
  OBArmature With Bugged Bone/Bone2/BONE_READY() via 'Ready -> Done'
  OBArmature With Bugged Bone/Bone2/BONE_CONSTRAINTS() via 'Constraints -> Ready'
  OBArmature With Bugged Bone/Bone3/BONE_DONE() via 'Locked Track'
  OBArmature With Bugged Bone/Bone3/BONE_READY() via 'Ready -> Done'
  OBArmature With Bugged Bone/Bone3/BONE_CONSTRAINTS() via 'Constraints -> Ready'
  OBArmature With Bugged Bone/Bone4/BONE_DONE() via 'Locked Track'
  OBArmature With Bugged Bone/Bone4/BONE_READY() via 'Ready -> Done'
  OBArmature With Bugged Bone/Bone4/BONE_CONSTRAINTS() via 'Constraints -> Ready'
  OBArmature With Bugged Bone/Bone5/BONE_DONE() via 'Locked Track'
  OBArmature With Bugged Bone/Bone5/BONE_READY() via 'Ready -> Done'
  OBArmature With Bugged Bone/Bone5/BONE_CONSTRAINTS() via 'Constraints -> Ready'
  OBArmature With Bugged Bone/Bugged Bone/BONE_DONE() via 'Locked Track'
  OBArmature With Bugged Bone/Bugged Bone/BONE_READY() via 'Ready -> Done'
  OBArmature With Bugged Bone/Bugged Bone/BONE_CONSTRAINTS() via 'Constraints -> Ready'
Detected 1 dependency cycles

So in essence that bugged bone cannot be evaluated properly because its transform depends on itself...
Those dependency cycles usually show in symptoms like you described : one-frame delays, weird behavior when hopping to startframe etc.

Dependency cycles are not bugs though, please come up with another way to rig this.
Will close.

This is a dependecy cycle: ``` Dependency cycle detected: OBArmature With Bugged Bone/Bugged Bone/BONE_CONSTRAINTS() depends on OBArmature With Bugged Bone/Bone1/BONE_DONE() via 'Locked Track' OBArmature With Bugged Bone/Bone1/BONE_READY() via 'Ready -> Done' OBArmature With Bugged Bone/Bone1/BONE_CONSTRAINTS() via 'Constraints -> Ready' OBArmature With Bugged Bone/Bone2/BONE_DONE() via 'Locked Track' OBArmature With Bugged Bone/Bone2/BONE_READY() via 'Ready -> Done' OBArmature With Bugged Bone/Bone2/BONE_CONSTRAINTS() via 'Constraints -> Ready' OBArmature With Bugged Bone/Bone3/BONE_DONE() via 'Locked Track' OBArmature With Bugged Bone/Bone3/BONE_READY() via 'Ready -> Done' OBArmature With Bugged Bone/Bone3/BONE_CONSTRAINTS() via 'Constraints -> Ready' OBArmature With Bugged Bone/Bone4/BONE_DONE() via 'Locked Track' OBArmature With Bugged Bone/Bone4/BONE_READY() via 'Ready -> Done' OBArmature With Bugged Bone/Bone4/BONE_CONSTRAINTS() via 'Constraints -> Ready' OBArmature With Bugged Bone/Bone5/BONE_DONE() via 'Locked Track' OBArmature With Bugged Bone/Bone5/BONE_READY() via 'Ready -> Done' OBArmature With Bugged Bone/Bone5/BONE_CONSTRAINTS() via 'Constraints -> Ready' OBArmature With Bugged Bone/Bugged Bone/BONE_DONE() via 'Locked Track' OBArmature With Bugged Bone/Bugged Bone/BONE_READY() via 'Ready -> Done' OBArmature With Bugged Bone/Bugged Bone/BONE_CONSTRAINTS() via 'Constraints -> Ready' Detected 1 dependency cycles ``` So in essence that bugged bone cannot be evaluated properly because its transform depends on itself... Those dependency cycles usually show in symptoms like you described : one-frame delays, weird behavior when hopping to startframe etc. Dependency cycles are not bugs though, please come up with another way to rig this. Will close.

Robert Schultz commented

2022-02-03 12:26:04 +01:00

But I can arrive at the correct solution by doing:

bpy.context.scene.frame_set(frame_num)
bpy.context.scene.frame_set(frame_num)

Seems unnecessary to shut down this issue so readily, when the solution is right there.

I think what I'm arguing is that that this shouldn't be considered a dependency cycle, even if whatever you've posted there says it is. Call that a false positive or whatever.

At each frame each bone is rotated to "look at" the position of the bone ahead of it, so there shouldn't be any problems, no? Like the rotation of bone_1 depends on the position of bone_2, and so on down the line, so where exactly is the cycle in dependency?

But I can arrive at the correct solution by doing: ``` bpy.context.scene.frame_set(frame_num) bpy.context.scene.frame_set(frame_num) ``` Seems unnecessary to shut down this issue so readily, when the solution is right there. I think what I'm arguing is that that this shouldn't be considered a dependency cycle, even if whatever you've posted there says it is. Call that a false positive or whatever. At each frame each bone is rotated to "look at" the position of the bone ahead of it, so there shouldn't be any problems, no? Like the *rotation* of bone_1 depends on the *position* of bone_2, and so on down the line, so where exactly is the cycle in dependency?

Philipp Oeser commented

2022-02-03 12:39:19 +01:00

This is because you are evaluating twice then (which gets rid of the one-frame delay).
It is not suitable to evaluate twice generally (since this would ruin performance).

This is because you are evaluating twice then (which gets rid of the one-frame delay). It is not suitable to evaluate twice generally (since this would ruin performance).

Robert Schultz commented

2022-02-03 12:50:06 +01:00

Right, but what I'm getting at is the existence of some underlying shortcut or optimization, not that Blender should literally do my work-around.

Right, but what I'm getting at is the existence of some underlying shortcut or optimization, not that Blender should *literally* do my work-around.

Philipp Oeser commented

2022-02-03 12:54:59 +01:00

In #95466#1300913, @Robert-Schultz wrote:
I think what I'm arguing is that that this shouldn't be considered a dependency cycle, even if whatever you've posted there says it is. Call that a false positive or whatever.

At each frame each bone is rotated to "look at" the position of the bone ahead of it, so there shouldn't be any problems, no? Like the rotation of bone_1 depends on the position of bone_2, and so on down the line, so where exactly is the cycle in dependency?

In this particular case, yes, rotation is dependent on position (and in your particular case this could solve properly because position is not actually constrained), but the dependency graph is not fine-grained enough to distinguish translations and rotations. So there are other constraint-setups which indeed would be unsolvable (when position would also be affected in the chain).

In #95466#1300940, @Robert-Schultz wrote:
Right, but what I'm getting at is the existence of some underlying shortcut or optimization, not that Blender should literally do my work-around.

Not sure I understand. You are requesting the optimization if I read this correctly? If the dependency graph would be more fine-grained this could indeed be optimized, but this would then really be a feature request (and not a bug in the current behavior)

> In #95466#1300913, @Robert-Schultz wrote: > I think what I'm arguing is that that this shouldn't be considered a dependency cycle, even if whatever you've posted there says it is. Call that a false positive or whatever. > > At each frame each bone is rotated to "look at" the position of the bone ahead of it, so there shouldn't be any problems, no? Like the *rotation* of bone_1 depends on the *position* of bone_2, and so on down the line, so where exactly is the cycle in dependency? In this particular case, yes, rotation is dependent on position (and in your particular case this *could* solve properly because position is not actually constrained), but the dependency graph is not fine-grained enough to distinguish translations and rotations. So there are other constraint-setups which indeed would be unsolvable (when position would also be affected in the chain). > In #95466#1300940, @Robert-Schultz wrote: > Right, but what I'm getting at is the existence of some underlying shortcut or optimization, not that Blender should *literally* do my work-around. Not sure I understand. You are requesting the optimization if I read this correctly? If the dependency graph would be more fine-grained this could indeed be optimized, but this would then really be a feature request (and not a bug in the current behavior)

Robert Schultz commented

2022-02-03 13:31:37 +01:00

I am satisfied, thank you for your response and time, good luck!

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Loop of Bones, each with a "Locked Track" Constraint, results in one bone bugging out #95466