copylocation constraint lags one frame

On a mechanical rig I have a mesh parented to an armature using vertex groups,(no armature modifier). One bone of the armature revolves the mesh. An empty is parented to the mesh and another bone copies the location of the empty, but upon animation it is always one frame late. I tried searching and found where Theeth had fixed this in an earlier version ( I use 2.42). Time offset didn’t help. Also, I’m new at this so I don’t understand why, when I parent the mesh to the armature I get a choice of “parent to armature”- “parent to object” If the active selection is the armature, how can it parent to the armature? I tried both ways and it looks the same in outliner. Blend file is here if you want to see it.

Hmm, I had encountered this with hooks driving a curve in 2.41 or2.42 I believe…

I played with your file for an hour 2.42a and yes, it’s still the same bug. Send the .blend to the bugtracker:


Hi !
I have also palyed with the file in 2.42a, and I have noticed a very strange thing :
The Rotator (Wheels) is parented to a bone of the armature which is used to rotate the wheel.
The Empties used to move the other bones are vertex parented. Until now, it’s OK.
I have tried to parent a cube to the Rotator object… Surprise ! When you rotate by hand the rotator object around it’s center the cube follows the rotation, but the cube doesn’t rotates with the wheel when the animation is launched !
In V2.42a, I have made a simple file with an armature including a rotating bone used as parent for a cylinder. The bone rotates and makes the cylinder rotate too.
I have parented a cube to the cylinder, and when I start the animation, the cube follows as well.
Did you make the file with Blender V2.43 RC1 or RC2 or any CVS build, or is it a 2.42a file from scratch ?


Oh grief… I hope that really isn’t another nasty case of something that no-longer works. I’m still trying to fix the other one :wink:


Well, I’m sorry, but I fear that it is a bug…

it’s an cyclic update problem ONLY when you jump across frames. When rendering, Blender fixes it by recursively computing location until nothing moves, and then renders. I’ve run into this many times with my inventions. If you want to be sure of bone placement and armatures are being dependent on one another, just do a left-right arrow and it will catch up.

Hi, it is not only that unfortunately !
Try to do what I described in my post here above.
There is a problem with parenting an object to an other which is rotated by a bone animated in pose mode.
The last object parented to the first doesn’t follow the rotation in the animation… There is not only a 1 frame lag! there is no rotation at all in this situation.
The two problems might be linked though, but it’s more serious than we could think…
Well, I have reopened my own file, and I can’t reproduce the parenting bug, but if I parent a cube to the rotator object in the file given by Harley123, the cube doesn’t rotate !
As I still can’t acces for the bugtracker, I hope that someone will check the problem and report a bug…

Ok I spent the better part of this afternoon trying to figure this out and am pretty certain this is not a bug but an unusual method most people really don’t run across … And all I can say is DO NOT NAME YOUR MESH AND THE BONE THAT CONTROLS IT THE SAME . This confuses how Blender sorts out data types and lets you do things which it otherwise would not .
Anyway below is a sort of a log I started writing earlier in the day :

@ ROUBAL : Have you tried replicating the vertex group / empties relationship he has set up as well as constraining the two side bones with with those empties ? I tried a simple set up with a cylinder and an edge on that cylinder as a vertex group and added a hook (in edit mode) and then parented the cylinder to an armature added another bone and constrained it with an empty but the empties do not rotate with the bone only with the cylinder mesh … I can’t figure out how he did this in the first place … He has a mesh object named “rotator” and a bone in the armature also named “rotator” is that what the empties are children of ? …
I managed in another version to parent the empty to the armature bone but only after I renamed it “Cylinder” - before it wouldn’t let me do it i.e. when it was just plain old “bone” ( and it won’t let you again if you rename it back to “bone”- the empty becomes a child of the armature instead by default ) and this time the empty did rotate with the bone but it did not maintain it’s relationship to the vertex group - infact the verticies selected disappeared when I weight painted the mesh for it to be controlled by the bone … So my next question is how are those empties related to the vertex groups ? If you look at the transform properties for the empties now they are parented to the “rotator” is this the mesh or the bone ?
The name confused version had the same wierd jumpiness as his and also had the same problem of a cube parented to the cylinder as you did - i.e. it did not rotate when I rotated the bone only when I rotated the mesh …

@Harley123 :OK I did some more tweaking with the file and this is what I came up with :

  1. rename your “rotator” bone into something else - anything as long as it is NOT a mesh name especially - you are confusing poor Blender …

In fact you should just delete it (just the bone not the armature) and give the mesh a rotation key …
And you do that by :

a) Go in to Top View . Go to frame 1 . select your “rotator” mesh and press the I key and insert a “rot” key frame .
b) With your mesh still selected change the outliner window to the IPO curve editor . Make sure the ipo type selected is"Object" in the window with the little stick figure .
c) You should see RotX, RotY and RotZ with little blue boxes next to them . Select RotZ (with your LMB) .
d) Go into the curve window and Ctrl LMB in the right upper quadrent to add a key . You should see the line “jump up” to where you clicked .
e) From the header under “curve” select “extrapolation mode” and select “constant” . This will make the rotator rotate forever - well as long as the animation is going anyway . The curve will become a straight line .
f) To edit the speed of the rotation press the N key . In the transform properties edit the "Xmax"value to 5 . The smaller the value the faster it will rotate .

This should get rid of the “jumpiness” and the lag as they were it seems cause by the double naming of different object types which allowed you to “parent” empties to a single bone - which is not allowed as a matter of course . I don’t know why but you can do it in your file even now but I can’t in the simple mock ups I made … other then the one I had named “cylinder” for both bone and mesh that is .

  1. your empties really have nothing to do with the vertex groups other then initial location … and they should be made the children of the mesh to keep them in place … Which happens automatically in your case when you delete the “rotator” bone .

e) From the header under “curve” select “extrapolation mode” and select “constant” . This will make the rotator rotate forever

You must set Extrapolation mode to Extrapolation. If you set constant, you will not get a rotation, only a change in the angle when the green line cursor reaches the edge of the curve !
In the original file provided by Harley 123 :
I have renamed the Armature bone Rotator to Rotator-B and parented the Empty to the mesh by ordinary parenting (not Vertex parenting),and applied a rotation to the rotator mesh.
I have also removed all the Ipos from the armature,and the lag between the Rotator mesh and the bone parented to the empty is still here !

Ok so I got that wrong more of a typo then anything but have you been able to repeat the same problem ? I did earlier and it does have to do with the naming thing - the thing is in his file you can still do the odd parenting even when corrected (rename that bone) while when I correct it from my version Blender will not allow me to do it . By the way I had no ipos or animations attached in my version and when I would rotate it manually it did all of the above problems he was having including the “bug” of another mesh not following the parent mesh as you described …

EDIT: Ok I just tested once again my hypothesis . I grabbed one of the so called vertex group parented empties and moved them out into a different location and then animated . There was no effect on the mesh at all - i.e. the empty is simply a child of the mesh/bone and it perfectly rotated with the mesh . There is no way to parent or child an empty to parts of a mesh otherwise then as a hook - i.e. as a modifier . That means that the empties have absolutely no relationship as hooks/empties to the so called vertex groups he is talking about . They are simply child objects of the mesh and thus not linked as hooks to the mesh/vertex group in the usual sense - by which I mean a hook/empty - which can be attached to a vetex group and act as modifiers as to the mesh doesn’t apply here (because it is non existent) . They are simply children of the mesh/bone and will transform according to the parent object and it does not matter if they are supposed to be"linked" as vertex groups because in this case they are not . They are as I said simply locations in space as from my above statement .
ANY modifiers to an object always shows up in the modifier stack in Blender . None of the supposed hooks/empties show up when you select the rotator mesh … other then the virtual armature modifier … no hooks - if the vertex groups had hooks applied they would show up there but - no nothing .

And by the way don’t you think that it is a logical loop (and therefore bad for a stupid machine like a computer which relies basically on an on-off boolean logic ) to insist that the bone/armature that rotates a mesh has hooks/empties that affects parts of the rotating mesh/armature in the first place ?

I mean if you want to call this a bug or problem in the software you can - like I wish I could turn back time and hit the freaking lottery sometimes - but (and by the way I told harley123 in another thread that I thought he was creating said loop) it is really freaking hard to come up with this unnecessary problem …

I personally come from from a somewhat more non-software based education (I am a sculptor with a lot of mechanical engineering interests) but geez what the F… , what is so freaking precious about a rather unnecessary piece of data (the stupid double named bone) ? I mean it doesn’t help you understand the motion/animation any better by having it and you could easily substitute it with a couple of simple mouse clicks anyway ? …

OOOh this is a bug , well you have to have a weird convergence of empties/armatures and mesh (with same name) for this to happen . Well do it . And when you do you will discover that it was an over exuberant noob who wanted to parent in a loop which caused this problem, not Blender - and an odd one at that because very few of us tend to name our meshes and their modifiers the same (I certainly don’t) thus creating the loop in the first place . I mean I understand that hooks/empties are a special case of modifiers because you can assign them in Edit Mode, but even with that you can’t apparently apply them directly to a bone unless you have the nomenclature problem - which is the reason why I don’t think this is a bug, just an odd case . I mean when is it the fault of the programmers when someone takes CG space too literally, when they expect the motion of a thing to be the same as the thing (and name) like it seems in real life ? Notice I said seems because even in real life they really don’t either even if you are a machining a part for whatever purpose they are not called the same any way … so why expect that in software ?

The Empties were Vertex Parented to the Rotator mesh; select Empty, Select Mesh, Tab to Edit mode, Select 3 Verts, Ctrl-P, Vertex Parent. The problem is that the CopyLocation Constraint is evaluated after the Parent heirarchy.


I think that Fligh is right when he says :

The problem is that the CopyLocation Constraint is evaluated after the Parent heirarchy.

For my own, even if I have not been able to reproduce the parenting problem in my last trial, I have noticed it in a blend file made from scratch with only an armature a cylinder an empty and a cube with different names : Armature with Bone, Bone.001, Empty, Cylinder, Cube.
Not two times the same name, and the problem was here (the cube parented to the cylinder didn’t follow the rotation of the cylinder when the animation was played - it did when rotating the bone or the cylinder by hand), the file was made from scratch, and I 've tried with vertex parenting the empty and with simple parenting as well.
I agree with Fligh, in harley123’s file if you move only the vertices around the empty in edit mode, the Empty follows the the selected vertices, so they are Vertex Parented.
I agree also with Vertex Pusher for the fact that simple parenting would work the same in this case, except that the empty could rotate or not on its axis with Vertex parenting, according to the number of selected vertices for parenting (1 vertex : keep location - 2 vertices : Keep also rotation).
—> I forgot : For what I know, Hooks appear in the modifier stack when they exist, but Empties are not displayed in it. The Outliner show them, but doesn’t tell you if they are simply parented or vertex parented. You have to check by hand , by moving vertices of the parent mesh in Edit mode.

sorry for the fuss. I was just following the instructions for the flywheel tutorial in Wiki. Someone offered a simpler solution using the three empties, so I tried that. They are vertex parented to the mesh. I tried a single vertex to use just the location, but I had some problems with it. then I tried using three vertices. I thought the mesh was supposed to be named the same as the bone so the bone would know which group to deform. I have the model working fine now, but I’m going to stir things up again. I want to rotate the entire model in global space while the flywheel is turning. I almost have it, just one more recalcitrant empty to deal with.

For the 1 Frame lag, if your wheel rotates at constant speed, the simplest way of avoiding the lag is to use a small angular offset (displacement of 1 frame forward) in the position of your empty.

I seem to be having a similar problem. I have a piston parented to an arm, which is driven by the rotation of a scoop at the bottom. The piston seems to track okay, but, when I rotate the arm that the piston is joined to, the piston flops back and forth. Could someone please have a look at the .blend file I uploaded and tell me if that is the problem? I’ve got three more pistons to do, so I would like to nip this in the bud. Thanks.

Link to zipped .blend file (276Kb)

The problem you have isn’t what harley123 has . He was trying to use too many armature bones (imo) to rotate a flywheel and I assume to move some pistons (eventually) .

It seems you are just using empties/hooks as pivot points for the various parts and using a three bone armature with IK… And at first I thought that the fact that the object centers on the LScoopRod2_yellow and LScoopRod2_Material_ (both behind the scoop) were way out in space instead of being where they would be in real life i.e. in the centered on the connectRod_yellow part was the problem (because all the other meshes have their centers in their logical place) but it isn’t because I moved them to where they should be … and still the slight jiggling when the scoop rotates …

And when I Ctrl A the whole thing parts fly every where and changes into various scales … I think you might want to fix this before you do anything more . The Piston_yellow mesh I noticed is held in its position by its constraints ! And it seems everything has been moved into position and then made the children of the armature then Empty.001 without Ctrl A (apply scale/rotation) applied .

Remove the parenting relationships with Empty.001 and the armature and then Ctrl A and reapply the parenting . This way all your objects will have correct starting points for transformations relative to each other . As it is now you might wind up with more problems later on …

And this might fix the problem . But I think the pivot point/center for Piston_yellow is off compared to the constraints you linked via Emptyt . But this is almost impossible to do accurately by simply constraining to a single empty you need the pivot point to have a reciprocal relationship via an intermediary point for each part … This is really complicated and the only tutorial that explains it is here .

… the guy who wrote it is German and therefore the “odd” names he gives in his examples unfortunately made me slightly confused … But once you understand what he is talking about you will get a perfectly working accurate rod and piston motion .

Hope this helps .