» Blender 2.79 + Smoothed F-Curves
Updated 23:00 October 18th, 2017
1
(536)  1,661

Smoothed F-Curve Experimental Branch

 

Branch Code


(Green is new branch, Red is current master)

Good and bad handle placement example

 

It's well known that automatic bezier handle placement is in need of significant improvement. This branch tries out one possible way to do it for F-Curves. The idea of this approach is based on a somewhat old patch by Benoit Bolsee, but the actual code has for the most part been rewritten from scratch to improve flexibility and add more features.

 

Since I'm just a programmer with beginner hobbyist level of animation skills at best, I cannot evaluate myself how well these new curves work for real animation work, so I'm looking for feedback from animators. Please comment here or on BlenderArtists.

 

Key ideas:

  • Instead of considering only the two neighboring points when computing auto handles, motion is interpolated by tracing cubic splines with continuous velocity and acceleration through the whole stretch of adjacent Auto key points.

    A very good property of this approach is that adding redundant keys (keyframing interpolated object position without changing it), doesn't change the curve at all, unless other factors like Auto Clamp intervene.
     
  • The intent of Auto Clamp can probably be summarized as: the curve only changes direction at keyframes. To achieve this it has to apply constraints to the position of handles. An obvious one is that handles at extremes must be horizontal.

    A less obvious constraint is that handles cannot overshoot neighboring key points, because that causes the curve to change direction in an S-like shape between keys and even overshoot the extreme like that.

    Discussion Point: currently this restriction on handle overshoot is also applied to Automatic handles that are facing the adjacent Auto Clamp keyframe, because I thought that it may be more logical to enforce the extreme; however it's easy to change if it's confusing or otherwise annoying.

    It does seem to act weird in certain cases, so now restrictions are only applied to auto clamped handles like originally.

  • Vector handles that point at a non-Vector handle are also handled by the algorithm, so instead of pointing directly at the neighboring key, they are modified to achieve zero acceleration curve in the vicinity of the Vector key.

    Discussion Point: it has been suggested that a constant acceleration curve (i.e. parabolic arc) may be more useful for bouncing balls; however Vector originally is a straight line, and a zero acceleration condition makes the curve straight, albeit in an infinitely small vicinity of the key.
     
  • When Cyclic Extrapolation is applied to the curve, and the first and last keyframes are automatic, the curve is smoothed across the cycle boundary so that the loop is as seamless as possible.

    Since cyclic extrapolation is implemented as an f-curve modifier, which normally are supposed to run after handles are already determined, this is something of a hack code-wise, and the F-Curve smoothing code only accomodates the simplest confuguration of the modifier options. Enabling any limits on the number of loop iterations, range of the modifier, or its intensity, disables the new cyclic behavior.

 

Known limitations and bugs:

  • In order to simplify the generic 2D bezier spline used for F-Curves by Blender to a 1D cubic with meaningful and easily computed velocity and acceleration, the handles are always placed at the 1/3 and 2/3 points between keyframes in the time dimension.

    This limitation is so deeply ingrained in the math that it doesn't even consider the X position of handles, including the case when the curve ends at a manual handle that violates this assumption.

    Fortunately, a surprisingly simple addition to the border condition equations allows computing a smooth curve even when it ends at manually modified handles with arbitrary X positions (unless they overshoot the adjacent keys - can't really get a really smooth curve with that). However this is one of the aforementioned cases where inserting new keyframes in the interval between the manual and its nearest automatic key will change the curve.
     
  • Auto Clamp constraints are applied using a heuristic approach not based on any known and mathematically proven way of solving optimization with constraints problems. Thus potentially it might arrive at suboptimal solutions in difficult cases, which normally manifests itself as abrupt significant jumps in handle positions triggered by tiny changes in some point positions.
     
  • The code may act weirdly in complex cases like different types of handles on the two sides of one key point, or when Cyclic Extrapolation is used on a curve that has different handle types on the first and last keyframes.

 

Blender save file compatibility:

 

The changes in this branch obviously break backward compatibility in the behavior of the handles, so they cannot be merged until 2.8. However for ease of testing this branch is currently based on master and is thus compatible with saves done using official nightly builds. Of course, you shouldn't actually save important files with this branch unless you really mean it.

For performance reasons blender only recomputes handle positions when it determines that a curve is or may have been modified. This even makes it possible to transfer the actual curves between versions, provided they are not actually touched in the wrong version. The image above was made by transferring a save file and only triggering an update on the green curve. I haven't tested yet, but it is quite likely that it is possible to use official blender to render an animation that was created and smoothed with this branch.

 

The Cyclic Extrapolation related feature is always applied to the curves (although it will only actually update when the curve is modified). However the new handle smoothing mode needs to be enabled for every F-Curve imported from previous versions. The Smoothed Auto Handles dropdown is located below the curve color selection box. Curves created in this build get it enabled by default. Alt-click works to change it for all selected curves.


Updates: 

 

  08.05.2017: Updated to latest master. Modified equations to support arbitrary X positions in manual handles, plus minor fixes.

  14.05.2017: Updated to latest master. Fixed a small bug.

  22.05.2017: Updated to latest master and enabled CUDA in the build.

  29.05.2017: Updated to latest master.

  31.05.2017: By request, new smoothing mode is now a per-curve option. Auto Clamped doesn't clamp adjacent Auto handles any more. Fixed a bug.

  05.08.2017: Rebased onto 2.79 RC.

  20.08.2017: Updated to 2.79 RC2. Changed setting from a checkbox to a dropdown. Made Alt-click and Copy To Selected work.

  18.10.2017: Updated to 2.79 release. Added display of interpolation and handle type in keyframe icons in dopesheet.

 

 

Just one lonely comment. Leave yours.
14:50 May 8th, 2017
I cannot express my gratitude for this! I animate lots of characters for a game and I do this thing manually for basically every looping animation and for making the movements look more natural and fluid (for non-looping animations I sometimes get away with just setting the curves to automatic, but most of the times when doing so, the moves become too exaggerated and I still have to manually tone them down). And the fact that this works with cyclic extrapolation... you really made my day!
I hope this gets in trunk very soon. Thank you so much!
Feeling talkative?
Log in to leave a comment.