Why can't SOME animated objects handle being moved?

The right objects in this picture are all linked duplicates of the left, yet one of them isn’t rotating the correct way:

Does anyone know why this happens? I’m wasting so much time trying to work around this. :weary:

animationgrr.blend (1.2 MB)

Ok, I just noticed something that makes this even weirder… the animation only has a keyframe on the Y axis, yet I can get it to rotate on the Z axis:

Is this yet another example of the screwed up way Blender presents local/world transforms to the user?

What. The. Shit!?


This is what I get when I open your file :

What I see in the first screenshot is when you duplicate the object and scaled it to get a mirrored version, Z axis on the “wrong” part is flipped up/down. The bottom one is oriented differently .

There is probably a simpler, or at least less error prone, way of achieving the same thing.
One is to parent the original objects to an empty where you want the mirroring to append and duplicate all that, then scale the empty to get the mirroring.

You can also take the buggy object and orient it the same way as the one that is working, so they both behave the same way.

Another solution is to rig that a bit, and have intermediate empties without weird scaling and orientation that takes care of the rotation using constraints.
That way only one object is animated and constraints take care of the rest.

The post you mentioned deals with how blender handle’s child coordinate when parenting, and that blender show local coordinates of objects instead of global. How would that be related to your case ?
On that subject, quoting from the post you’ve mentioned :

The manual section on Parenting Objects explains how this works. In short, there is a matrix called the Parent Inverse matrix. It is this matrix that sits between the parent & child transforms, and it is what makes it possible to (un)parent a child without moving it. By using this matrix it’s possible to even parent an already-animated object, without having to update the animation data.

Nothing is screwed up, it’s just different from what you’ve been used to.
I use blender for a long time and I don’t see it as a problem. But I can understand the confusion because blender always show you the local coordinates of objects and you may be confused if you think it’s their world coordinates.

I just discovered that I attached the wrong file. It’s fixed now. Sorry that you wrote all that in vain, and it seems that you posted it before you saw the video I added as well, because you got two things wrong: I don’t scale anything and the animations are parented.

Apart from the obvious “wrong” display of transform values/axises, another thing that made me wonder if it’s related to the thread I posted was this:

I can’t think of what else would cause the behavior I see in the video (but I also don’t know how I managed to cause it, if that’s really the root issue here).

Ok sorry !

I haven’t dived a lot in the file, but maybe the issue lies in the fact that GRRPIVOT and GRRPIVOT.001 have a gimbal lock (https://www.youtube.com/watch?v=zc8b2Jo7mno) .

Open the N panel and try to rotate them from here in X or Z direction : they rotate on the same axis.
When you duplicate and rotate them in Z in fact you apply a world rotation but it’s converted to local coordinates, as X and Z axes are aligned probably blender pick the wrong one.
When rotated, both GRRPIVOT have their rotation changed in X. On OKPIVOT it’s on Z.

It’s not related to parenting, when objects aren’t parented to the “Test” empty it still doesn’t work.

The file is a bit confusing to me because I’d probably do things a bit differently.

One easy fix is to have a master empty that isn’t animated and takes care of the final Z rotation.
That way all pivots rotate the same way in their local space, thanks in fact to the Inverse Parent Matrix that is about on the developer blog :smiley: .
animation_fixed.blend (1.5 MB)

Another approach would be to use a mirror modifer :
animation_mirror.blend (1.5 MB)

Another one is using constraints :
animation_constraints.blend (1.5 MB)
One empty drives all animations.
It’s quite similar to the first solution, but if you need to duplicate these parts a lot it make less empties in the way …

Hopes that helps to clear things a bit even if it’s probably not the perfect answer…

1 Like

Thanks for the explanation!

I guess animation isn’t as straightforward to a beginner as I thought, and now I know why my friend always placed two empties on each thing he wanted to animate.

1 Like