Lack of refresh in proxy animation of a linked group #27694

Closed
opened 2011-06-19 10:17:29 +02:00 by Daniel Salazar · 26 comments
Member

%%%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)

Source.blend:
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.blend:
linked "All" group and instanced in scene
proxy made for the armature%%%

%%%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) Source.blend: 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.blend: linked "All" group and instanced in scene proxy made for the armature%%%
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Member

%%%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!%%%

%%%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!%%%
Author
Member

%%%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

cheers!%%%

%%%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 cheers!%%%

%%%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.%%%

%%%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.%%%

%%%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.

constraintBug.zip 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.%%%

%%%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. constraintBug.zip 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.%%%

%%%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.%%%

%%%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.%%%
Member

%%%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:
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Animation#Dependency_Graph%%%

%%%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: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Animation#Dependency_Graph%%%
Member

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'

%%%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 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.%%%
Member

%%%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!%%%

%%%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.%%%

%%%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.%%%
Member

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

%%%Lance: mail me, ton at blender.org, 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.%%%

%%%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.%%%

%%%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.%%%
Author
Member

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

%%%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.%%%

%%%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).%%%

%%%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: GroupLag2.zip%%%

%%%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: GroupLag2.zip%%%
Author
Member

%%%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.

cheers%%%

%%%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. cheers%%%
Member

%%%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.%%%

%%%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.%%%
Author
Member

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

%%%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 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?%%%
Member

%%%Hi,

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.

Log:
http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=53715

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

%%%Hi, 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. Log: http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=53715 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.%%%

%%%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.%%%
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#27694
No description provided.