What's the order of constraint evaluation among multiple objects?

Question

I've seen that Blender will evaluate the constraints in a stack from top to bottom. That's a very clear definition.

But in what order does Blender evaluates multiple constraint stacks? I've not found any explanation on that topic yet.

For example, I have A/B/C 3 cubes, all have a copy-position constraint to limit only Z position. And they form a constraint cycle (A->B, B->C, C->A) I can see in blender that, no matter how I try to move them on Z axis, none of them would move a bit.

Could someone who understands the blender implementation help to clarify this part? or just point me to some code/docs on this?

Any help is appreciated,

Answer 1

The problem not the order of the constraints as much as the cyclic dependency between your objects' constraints. Blender even warns against it in the system console (in Windows, open through the menu Window > Toggle System Console):

Let's see What is happening when you have a dependency cycle of this kind of constraint. First it's best noting that generally, when you add a copy location constraint to an object, you can no longer set the constrained object's location manually. It will get its location values ONLY from the target object.

Let's say we started with these Z positions:

A = 5
B = 3
C = 0

When we add a copy location constraint form A --> B, A will move to from 5 to 3 since its copying its location from B.

A = 3
B = 3
C = 0

Now let's add another constraint from B --> C. B moves from 3 to 0, and since A is copying its location from B, A also moves to 0 (this is the same as if both A and B copied their location directly from C).

A = 0
B = 0
C = 0

Currently the only non-constrained cube is C, so you can still move it wherever you want, and the other two will follow it wherever it goes.

But now you add another constraint, from C --> A. A has a value of 0, which it copies from C. C has a value of 0, which it will now copy from A. Since all cubes are now constrained, you can no longer set their location manually, due to the copy location constraint taking over. And since both A and C have 0, and B copies its location from C, all are stuck in 0 forever and ever ;-)

Bottom line, cyclic dependencies are a bad idea, and if you add a Copy Location Constraint to an object, you can no longer control its location manually.