hi, unfortunately this is known & expected behavior.
The Auto Run Scripts checkbox in User Preferences > File needs to be active before opening files with drivers.
if it's not active the addon will appear not to work & you will be asked to Reload trusted which reloads and allows the file to run the drivers.
This gives the user control over when they want to run drivers or not.
Thanks for report.
Closing as Invalid.
Fri, May 26
Mon, May 22
Seems the current spline IK is not really suitable for such cases.
Mon, May 15
This is use-after-free issue.
This is fixed in 2.79. Now the property is moved to a visible bone laying at the base of the limb.
- New rigs created starting from 2.79 code will work automatically.
- Old rigs should be upgraded re-assigning the rigify-types property in pose mode.
Tue, May 2
I'm still bumping up against this problem. Are there plans to remedy this limitation in 2.8? Even if it breaks older rigs, I'd be glad to have this limitation removed going forward.
Sat, Apr 29
I had the same problem a while ago, here's a video of what was going on: https://www.youtube.com/watch?v=LFoUrE1OHwQ
Apr 18 2017
The problem persists in 2.78c and today's dayly build 4d0d1b5
Apr 17 2017
Apr 15 2017
I am going to mark as resolved then, eventually the new depsgraph will replace the current one.
Apr 13 2017
I can reproduce with legacy depsgraph, but seems to be OK with --enable-new-depsgraph
Mar 28 2017
Since last asking for information it has been 7 or more days, due to the policy of our bug tracker
we will have to archive the report until the requested information is given.
Mar 26 2017
It seems that @ronan ducluzeau (zeauro) clarified the issue, and that there is no bug here after all. Closing.
Mar 24 2017
Mar 22 2017
Mar 21 2017
Mar 15 2017
Eeek, OK, sorry, missed that part of your description somehow :|
Thanks for your reply Bastien,
Mar 14 2017
The file you provided is not the file from the screenshot: There is no object named "Rig" in your file, but this is the active object on your screenshot...
I can't reproduce with attached file
More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.
FBX exporter bakes and applies some simplification to animations (to save some space). Setting Simplify parameter to zero in Animation settings of the exporter should fix that.
Mar 12 2017
This is essentially the same as T49261
Mar 10 2017
I appreciate your in depth response. I wasn't able to use an Image Sequence by baking paint but was able to use the Weight to bake something for an Animated Weight Group. I never knew that was possible and I'll keep experimenting and learning.
Mar 9 2017
Mar 8 2017
There should be no bone constraints buttons for non-armature objects.
Particles emission does not support animated weight groups, animated textures or image sequence textures.
It is a known limitation of current particle systems.
Mar 7 2017
Seems that you "Rig" object is the Mesh, not the armature.
That sounds fantastic. Thank you.
Mar 6 2017
This is very strange...
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.
This is a known issue that's on my todo list for when I get enough time to have another decent look at the NLA evaluation backend.
Doing this, I noticed that you have to zoom out the view at lot more to see the entire bone (when it is created using cm units). It looks like the bone isn't especially thin; it's more that the thickness doesn't automatically scale to match a 100 BU (i.e. 100 BU = 100 "cm", assuming 1 BU = 1 cm) high bone. In other words, BBone sizes are in absolute units (which are not adjusted to deal with the unit scaling stuff).
Mar 5 2017
There is a related problem with cloth physics (maybe with other physics too). Basically the scene scale has no impact on cloth physics at all, meaning the dimensions of the scene remain interpreted as if measured in the default units. The same seems to be happening here.