System to evaluate and update objects for editing and animation.
Fri, Mar 24
Fixed in T50995, thanks for the report!
Mon, Mar 20
Will have a look.
Sat, Mar 18
I tried this on both mac and windows and found it to behave the same.
Wed, Mar 15
Tue, Mar 14
More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.
Mon, Mar 6
As I guessed before opening the file (and confirmed afterwards), it looks like you're running into several things here:
- If you've got cyclic dependencies, expect to see errors if you do not strictly advanced the timeline in forward order, and/or if you ever cancel transforms.
- The Transition track assumes that the channels you've got keyed on strips A and B both have the same set of channels to blend between.
- Make sure that if there are some channels which you only key in a "later" occurring strip that you've got that property keyed in some low-down strip that spans the entire timeline. For example, to avoid trouble with controls glitching out (i.e. usually scaling to zero) you'll typically want to ensure that at the bottom of the stack you've got a "Rest Pose" strip that has a keyframe for the "default" value for every property you have/will keyframe anywhere in that NLA stack, and that this strip is set to extend forward and back.
Feb 27 2017
Sculpt mode avoids flushes as much as possible in order to keep best performance and less amount of lack when sculpting.
*Any* of dependency cycle will cause non-deterministic update of your rig. It might or might not work.
Feb 16 2017
This is update issue… Actually, with new depsgrah (--enable-new-depsgraph option from command line), shrinkwrap constraint also updates in Edit mode e.g.
Feb 10 2017
I think all current patches in master are staged for 2.79.
2.78b had a very specific set of fixes that were allowed for a 'b' release. I would suggest using a buildbot version at the moment or be patient for 2.79 which is due in a couple of months.
I checked in the daily build from today, and it does work correctly. Why was this pulled from the official release? Any chance it can be patched back in?
I just checked this in the official 2.78b release on OS X and the bug is back. Did it not get checked into main? We were relying on this fix for a bunch of shots. :(
Feb 2 2017
Jan 31 2017
Jan 27 2017
Jan 25 2017
Switching back to needs triage
Jan 24 2017
Here's a file demonstrating the issue..
Thanks for the report.
Jan 6 2017
@Adam W. Parker (adamwparker) please add comments rather than editing original report to answer other comments, otherwise it’s very hard to tell what has been answered or not!
Dec 28 2016
I remember fixing related issue. Since there are multiple ways such a driver is created please attach simple .blend file with your particular driver which fails.
Dec 27 2016
Nov 21 2016
Nov 17 2016
Nov 13 2016
To clarify, it wasn't that the daily build broke it, I tried first in 2.78 and know there was working being done on depsgraph so grabbed the latest build to check.
Nov 11 2016
Not sure this is a bug or expected behavior? @Sergey Sharybin (sergey), will let you handle this one. ;)
Nov 10 2016
Nov 3 2016
Oct 24 2016
Oct 23 2016
Jul 13 2016
Similar issue was reported by artists here in the studio, so apparently it was fixed in rB527674b.
Jul 7 2016
Didn't check in details yet, but new depsgraph issues goes to me!
Jul 6 2016
I correct myself: it does move... but it is not visible until release the movement and move it again. In that moment, the object's new place is visible.