Lack of refresh in proxy animation of a linked group
Closed, ArchivedPublic


Open Linked.blend
Move selected bone with G
Cancel with Esc
the parented Object stays behind (lack of refresh?)

some info (but dunno if it is all related to the bug)

created two objects and assigning them to their respective groups ("Cone" and "Cylinder")
This objects are then moved to hidden layers
Dupligroups are created for each group in layer 1 and a new "All" group is created for this two dupligroups
A two bone armature is created and added to "All" group
Bone level parenting is done for the two dupligroups ("Cone" and "Cylinder")

linked "All" group and instanced in scene
proxy made for the armature


To Do

Proxy feature is dead simple, it just works for an armature in a group and refreshes own internal group objects on editing.
Group instances inside groups wasn't looked into for this... it was only added to allow making advanced primitive catalogs (for Plumiferos city design :)

Didn't check the zip though, but the avove situation should work fine. If not, then we have a real bug!

indeed, I dont think this is related to groups in groups. maybe its just a lack of refresh on cancel. I don't notice any lag or print to terminal about any cycle so it's probably trivial to fix


recall seeing this problem once before, in that case the issue was that the depsgraph doesnt sort the dupligroup as it does for the scene so the evaluation order is wrong.

There is a lag, but it is hard to see when dragging the bone around. Try typing in a number instead, e.g. G, 5.

Added a new test case that demonstrates a similar problem with linked groups. If a group containing animated objects is linked to from another file, constraints targeting objects in that group will lag by one frame. To see this, open constraintLinkedGroup.blend and step through the animation. Two other tests are provided that do not show the bug; details below. contents:
- constraintAssets (not a test) Three empties, animated in different ways: AnimatedOb is keyframed; Parent1 uses a ChildOf constraint to follow AnimatedOb; Parent2 uses a FollowPath constraint to travel along a Bezier curve.
- constraintLinkedGroup (bug) The animated objects from constraintAssets are linked in as a group. Three local objects use ChildOf constraints to follow the 3 linked moving objects.
- constraintLinkedObject (no bug) As above, but the assets are linked as plain objects, not as a group.
- constraintGroup (no bug) This is a self-contained file. It is set up the same as constraintLinkedGroup, except that the group is on a different layer in the same file, not linked to from another file.

I'm happy to open a new bug for this if you think it's a separate issue.

I can confirm this bug. I have a character with eyebrows which are curves hooked onto empties (default option) which are then parented to armature bone controls. When the character is linked, the eyebrows are indeed one frame behind and therefore sink into the head as the character rushes forward. This is true not only for the 3D view, but also affects the final render.

In an attempt to create a clean example I think I've discovered one of the key elements to reproducing this odd one frame lag. I inadvertently renamed the empties (the hooks) of a curve which was in the blend of a linked character. This broke the links to these curves (on opening the scene file) and Blender complained that it was unable to find a certain list of lib items (the empties). I saved the file at this point and voila - the empties were working but now without the lag. I need to test this more, though I think the problem is caused when an already linked character rig is modified to have hooks etc (or any such modifier?) after the initial act of linking. So, if I have a character, link it to a scene .blend, and then go back and add bezier curve eyebrows with hooks to the armature... those will have lag. The process of linking needs to be repeated after the eyebrow hooks are included as part of the character group.

I could blame my workflow, but I think Blender should be able to work with this as the point of linking is so that characters can be continuously updated.

Alex: you are setting up a relationship from a local object to an object inside of a linked group (that object is not in the scene graph). That's a known issue with our animation/dependency system. Such relationships are not being solved (only a relation between object and the group instance itself would be valid).

It's a known issue in our todo. I will collect all of them and seek for solutions - hopefully quick ones to bypass lags now, but it really needs a complete new depsgraph.

I've added this as reference in our wiki:

Ton Roosendaal (ton) closed this task as "Archived".Oct 21 2012, 3:55 PM

Thanks Ton. I'm attaching another blend file to see if this helps observe the issues. Again, this is happening whenever the supplied file (link_lag.blend) is linked (by group) to a new file. If you link, make proxy, and then move the character around in pose mode, the lag occurs. This does not happen if the file is appended; only when linked.

To reproduce: Start a new Blender file (I'm using Blender 2.64a) and link in the rig as follows:

File => Link => link_lab.blend => Group => Edubase
The character appears. Select the rig (floating eye controller)
Object => Make Proxy => Armature. Eyes should now close (rested position)
On the "Object Data" tab (stick figure), under "Display" choose "X-Ray"
Activate Pose mode for the rig and select the body controller (the oval ball in the middle of the white box) and move it around.

As you do, the eye mesh seems to lag behind the movement, sometimes disappearing inside the head.

My observations seem to indicate it's linked hooks which have the slow update (lag) problem.

Thanks, we'll use this as a reference for future code work!

Lance: hey, what happened now with your 2.5 manual? It suddenly disappeared from the radar... we sold it very well in our shop but never could order more!

Yeah I know. I'm not sure how much I should say (in public eye) versus the publisher on that. Beginning Blender went out of print fast (paper copy) even while it was still #1 on Amazon in the 3D Animation category. At that point I started getting one or two people tracking me down to ask why and I contacted the publisher to urgently reprint but they simply refused to do so. Their only reason was that Beginning Blender was in colour and therefore somehow difficult / expensive to push another print. This made no sense to me and all I could see is further sales not happening after all the hard work (and some very unexpected personal cost). Not fair after the pressure and deadlines they'd previously pushed.

I am however entertaining the idea of writing a second edition; all the new features (and one or two changing layouts) really do call for an sizeable update by now (as in completely rewriting areas). After the pressure I was under with first edition I'd likely work very quietly on my own at first and then see whether the publisher is interested only once it's practically complete. If they are interested in a 2nd edition, perhaps that will see the paper copy "out there" once again. If not - perhaps I could repackage the update elsewhere? I better write it first though.

I'm very glad you're aware of the book Ton. In the last minute rush I'd overlooked adding you to the Acknowledgements and I'd always wished I'd had.

Lance: mail me, ton at, to discuss optimal publishing of a 2.6 book.

Lance: this is not really a bug. You've set up your rig incorrectly. Check your thread on Blender Artists.
Basically, you didn't include the lattices in your dupligroup. There are more issues, but we can discuss on BA.

Beorn Leonard: Your solution (thank you) on BA has not worked for me as yet (perhaps I misread it?) If the solution is resolved I will also say so in here to stop devs working on it.

I'm happy you found a solution to your problem but this was my bug report and now it's closed without a solution?

Daniel Salazar - it's not "solved" as yet. Indeed the file Beom Leonard posted on BA appears to work for my case, but I"m still looking into what he did and why. This may be one of those bugs which has a work around, and could nevertheless still be a bug when comparing what should happen against what does happen.

At this point (until I look more into Beom's fix) I think there is a lag bug related to how Blender handles linked dupligroups / layers. We both seem to be using these and if I'm not mistaken, Beom's solution seems to involve tweaking those areas. If everything has to be brought to the same layer (or all be on visible layers), the the problem is still less than ideal.

Interesting. The work around (proper workflow) for this seems to include these conditions:

* Any empties & lattices etc used in the rig must also be added to the import / export group (fair enough)
* In object mode, the armature must be moved to a layer which is not visible. (I have no idea why this is important)
* Sometimes things still seem to lag (other rigs where I have been trying this). In these situations, empties etc should be recallibrated by reassigning their Relations (under the Object tab) to another layer and then back again.

With these three changes I believe the linked file should actually work (no lag). I'm still not sure why, especially with the last two conditions. Those seem very odd to me from end-user perspective (and a likely bug).

Daniel Salazar, with respect you your original thread, I've applied the above rules as a workaround "fix" to your original file. Simply by moving the armature to another layer completely (in the original file), the link actually works without the lag (this was rule 2, last post). It seems to work (as a workaround) although I'd have to explain why to anyone, and therefore still think there's a bug present.

See new file:

When I create a bug report i create it a certain way for a reason It's not super useful to start looking for work arounds on an extremely simplified file like the bug report file. Of course you'll find one. I would at least like to know (by a coder) why my bug report was closed.


There are a lot of reports in the tracker about similar issues - that's the link to wiki.

I'm serious we want to solve it with the depsgraph project - but believe me, it might become as big as our 2.5 recode... taking a year or more to complete.
Unless we find simple bypasses in code to make more common cases work. That I will check on first - after i'm more familiar with the code again.

Thank you for the reply. Awaiting the mighty depsgraph recode :)

I hope I haven't over-spammed this bug report (sorry Daniel).

Just wanted to add what Beorn Leonard said in the Blender Artist thread: that Daniels and my examples are likely not the same.
The "fix" I offered Daniel was to put the Armature on another layer. I'm not sure why this works but it did.
In my case, the lag seems to have been caused moreso because I failed to add the empties and lattices to the group.

I seemed to have varying and insonsistent results when playing with this; earlier when I'd added empties to the group it didn't work - not sure why. Perhaps I forgot to add the lattice as well?


I've added a hack in blender to allow artists to give objects manual additional updates, to solve lags. Only for frame changing.

Works on constraintLinkedGroup.blend with using 'extra object update' on the cones.


This is not an excuse to not fix depsgraph, but it's too annoying to longer live with this crap :)

I'm experiencing the same problem with my scene. I have many characters, linked unto a main scene. All of the characters have multiple cloth objects, that lag. Rigs that control partly directly the mesh, partly deforming mesh with deforming mesh modifier. The deforming parts lag also. Had some vertex hooks that lagged also but redid them all as bones, which fixed that problem. Still haven't figured out how to fix the deforming mesh or cloth lag. Sometimes some cloths work, sometimes don't.

Tried out Ton's hack, but the problem remains.

Add Comment