Monday, November 4, 2013

Release Notes for Blender 2.68 and 2.69

It's been a few months since I last made a post highlighting some of the changes to animation-related features in Blender. During that time, we've had 2 (!) major releases. So, it's probably time that we caught up on things a bit :)


Since it has been quite a few months, I may have missed some changes in the following highlights. Also, since it's getting a bit difficult to remember which version exactly some of these changes occurred in, I've just clustered these by category instead.




Important Changes
A number of important changes occurred during these releases which are common causes of confusion, etc. These may also be sources of compatibility problems which may be encountered when moving from older releases.

Python Security - Scripts/Drivers Autorun Changes
Perhaps the change with the biggest impact on the majority of animators/riggers out there are the Python "Autorun" changes.

In short: By default, all features which result in Python code being executed (i.e. scripts for custom operators, scripts for custom UI layouts, driver expressions, scripts for driver features, etc.) are all disabled when files are loaded.  This is perhaps the greatest factor leading to rigs being broken moving from older versions!

This was done to provide greater out-of-the-box security for novice users who may be downloading random files off BlendSwap, PasteAll, or other file sharing websites. However, for riggers and animators, in most cases this results in broken rigs.

The current best practice instead for such users is to:
1) Go to the User Prefs -> File tab
2) Enable "Auto Run Python Scripts"
3) Blacklist a number of directories where "potentially dangerous" files reside - i.e. your downloads folder and/or a few others where you're likely to save and load files downloaded off the internet. In practice though, many will probably just end up skipping this step, though be warned that this carries risks (if you're even slightly security paranoid)...

For more details, see the release notes on this here.


Transform Constraint - Rotation Offsets are now applied (like for locations)
From the commit log (r. 57309)
jpbouza Feature Request: Transformation Constraint now allows applies rotation offsets too (like for location)

This is useful in some cases when Copy Rotation constraints would otherwise be used for this purpose but cannot be used for various reasons. Basically, this works in practically the same way that the Copy Rotation offsets work, including the same weirdness that you'll get when trying to manually rotate these in the 3D viewport using "global" space manipulations ("local/normal" spaces though
still seem to work really nicely).

WARNING: this may potentially break old files with transform constraint setups involving rotation outputs. Please check whether this causes any problems on old files, and report back if there are any issues.

NLA Strip Blending Behaviour Changes
There were two primary bugs here that these changes aimed to address:
1) NLA Animated Influence is ignored if strips below have zero total influence (r. 57333)
2) NLA "Multiply" Blend Mode calculated incorrectly (r. 57345)

Although these bugs have been fixed, a number of related quirks have not been resolved yet. I'll be writing another blog post about those problems sometime soon, but in the meantime, it is highly recommended that when using the NLA that you have a strip at the bottom of the stack (i.e. a "baseline strip") which contains a keyframe for every single property keyed or animated in the strips included in the NLA Stack, and is set to extend over the entire range of the scene's animation.


Such a baseline strip is necessary for two reasons:
1) The fix in 57333 means that Blender now needs to have an initial/default/restpose value for each property to blend the values in the strips above with. While in most cases the Blender provided defaults of 0.0 (or 1.0 in the case of scaling, and potentially other values for those properties for which defaults are currently defined)

2) We currently have some bugs where animation evaluation is "non-deterministic" (i.e. the results are somewhat unpredictable) if you have some properties which are only keyframed in some strips but not others. Namely, when jumping around the timeline, if you don't carefully scrub around such that the initial/default values for some of these properties are set correctly, then you may get incorrect poses.

In both of these cases, ensuring that there is a baseline strip at the bottom of the stack for setting what the "default" values for these properties should be solve these problems.


Driver Creation - Default curves now use keyframes instead
From the log for r. 59757:
Removed failed experiment of creating new drivers with Generator FModifiers. I had hoped that this would make it easier to create drivers that doubled or halved the input values, but that has proved to not be the case, and instead made harder for most users to set things up (as they'd have to remove these first).

Now, when adding drivers from the UI, these get created with two keyframes (at (0,0) and (1,1) for a 1-1 mapping), which can be easily tweaked normally.

However, for backwards compatibility of scripts (notably rigify, and perhaps some others out there), when creating drivers from scripts, they will still get created with Generator FModifiers for now. We can review this situation again for 2.7, but for now it seems ok.

Usability Tweaks
In addition to the above features, here is a list of various tweaks which should make animating and rigging in Blender nicer to work with.

General UI
1) Bugfix [35841] WM_OT_context_[toggle/cycle/etc.] operators dont show shortcut keys in menus (or tooltips) for properties they are used to toggle/cycle through  (r. 58058)

Some properties can be toggled using hotkeys via WM_OT_context_* operators, but these hotkeys aren't really shown anywhere obvious like other hotkeys (i.e. they're not shown in tooltips or menus). Although it is possible to look these   up in the userprefs/keymaps editor, it is quite tricky doing so, and most users  would just assume that since no shortcut is displayed, there simply isn't one at  all.

This commit introduces a slightly hacky fix which basically amounts to checking if a property can be set by any of the few operators which are used for this purpose. In order to keep this from being too sluggish, I've currently limited this to only working on Editor (e.g. "Show Seconds" in Anim Editors) and ToolSettings (e.g. "Use Proportional Edit") properties.

There are still some corner cases that would be nice to solve too (i.e. the
Pivot Type enum menu/dropdown should really be able to show the hotkeys which have been assigned for each of those items, since they're by-and-large quite hidden and obscure), though being able to show some of these is perhaps better than not showing any!

3D View
1) Apply Scale for Empties (r. 59755)
It is now possible to use "Apply Scale" for Empties. While Empties don't exactly have any Object data attached to them which can be used for supporting "true" apply scale (i.e. with non-uniform scaling), they do have a drawsize value which controls how large the empties are drawn (before scaling). This works by taking the scale factor on the most-scaled axis, and combines this with the existing empty drawsize to maintain the correct dimensions on that axis at least.

Core Assumptions:
1) Most scaled empties have uniform scaling anyways (i.e. most empties used for bone shapes)
2) On balance, preserving non-uniform scaling of empties after apply scale is not as important as not being able to do it at all


NLA Editor
1) It is now possible to add strips to AnimData blocks with no existing tracks (r. 57312)
As a convenience feature for those who are loading in action libraries and using these to quickly block out things in the NLA editor, it is now possible to add strips to AnimData blocks without first manually creating empty tracks to add these strips to. Simply ensure that such empty AnimData blocks are selected (Hint: click on the action line of the affected AnimData block to do so), and try to add a strip normally.


2) Bugfix: When clicking on a channel name in the channel list while still in tweakmode, this will now result in tweakmode being exited instead of going into a weird limbo-land where channel selection has changed (but tweakmode is still active but not drawn). (r. 57907)



Graph Editor
1) 'Show Debug' now enabled for all newly created drivers. For most users, it is useful to be able to see this to help figure out what's going on. (r. 59757)

2) Preserve active curve when using AKEY to toggle selection status of keyframe verts (r. 59756)
Previously, every time you toggled the selection of all keyframes (using AKEY),
the active curve would get deselected and deactivated. However, this was a pain when trying to tweak the shape of a particular curve, as doing this would cause that curve to either fade into the background or into the jumble of other
curves.

3) Bugfix: When deleting all keyframes from F-Curves, don't delete the F-Curve if it has a driver (r. 59761)

4) Bugfix [#35744] FCurve select changes on Graph Editor Resize, as selection state was lost due to buggy recalc/sync flags being used. (r. 57905)

5) Bugfix [#35668] Tooltip for Euler Discontinuity Filter was misleading (r. 57411)
The tooltip seemed to hint that this tool is able to resolve all manner of  gimble-lock situations by untangling the curves (i.e. performing some kind of  equivalent-angles resolution, keeping in mind the nearest situations nearby). However, this tool currently only performs corrections for the most basic case when large jump+flip discontinuity artifacts appear in euler rotation curves as a result of rotation values getting clipped to +/- 180 degrees, which arises when these rotation curves are the result of baking some physics sim or so.

6) Bugfix [#35643] Animated textures are invisible in Graph Editor if it is not linked via material (r. 57332)
Textures linked to modifiers are now shown in the AnimEditor channel hierarchy under object level now (i.e. on same level as ob-data, shapekeys, and  object's action). This makes it possible to edit such animation data without having to ensure that these textures are also linked to the object's material so that they will appear.

As a side-effect of how this is implemented, if playback is slower on scenes
following this commit, disable the "modifier" filter under the filtering settings in the relevant animation editor header. In particular, it may be beneficial to disable this when you've got scenes with meshes that have many modifiers (but none of these have any linked data with settings which can be animated), as Blender will still try to go through all those modifiers checking for anything to show.

3 comments:

  1. Lots of great stuff, now i understand why my drivers where behaving differently yesterday, right on!

    ReplyDelete
  2. Thanks for the detailed info. I should probably ask this elsewhere, but when creating a driver on a mesh (say for shapekeys), controlled by a bone, is there a way of keeping the driver curves displayed for ease of debugging? Seem to remember in 2.4 you could pin the curve display…

    Anyhow thanks for all your continued work.

    ReplyDelete
    Replies
    1. Well I think I answered my own question, as you do. If I deselct the 'only selected channels' arrow, then turn visibility off for the other channels that achieves what I want. I suppose a pin control might be nice though ;)

      What I'd find really useful with more complex rigs, is being able to select a channel in the dopesheet, and have the corresponding bone automatically selected too. It seems to work in reverse, but this would save me lots of time…



      OK http://www.caminandes.com/development/improving-blender/ tells me this is already done :) Guess I'll get a nightly build, and stop spamming your blog. :-/ Cheers.

      Delete