New F-Curve Smoothing mode in review for 2.8 (with 2.79 RC test build)

There has already been discussion of this in this thread, but now that I have 10 posts and can use links according to rules I thought it’s better to create a new thread to avoid confusion with the addon.

http://i.imgur.com/MxLhuvU.png

It’s quite obvious that automatic handles for bezier curves in blender leave much to be desired, so as a start I picked up an old patch by Benoit Bolsee that improves F-Curve smoothing, and mostly rewrote the code to clean it up and add more features.

Since I’m not an animator, I need feedback to evaluate the design and address concerns about breaking backward compatibility: are there cases where it would break old animations or workflows, how significant is the improvement and so on.

Test build:

Although this change is proposed for 2.8, I upload a build based on master (i.e. compatible with upcoming 2.79) to GraphicAll (Windows / Linux) for ease of testing.

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 setting is located below the curve color selection box. Curves created in this build get it enabled by default. The option supports Copy To Selected and Alt-click to set it on all selected curves.

Key technical 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.

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

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

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 might (but obviously shouldn’t) 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.

Moved from Latest News to Blender and CG Discussions

As I said in the other thread, this is a really huge feature for animators and saves them a ton of time. Usually with other 3D programs you always have to alter most of the tangent handle in your animation. This eliminates a huge amount of work tweaking because it basically does what you would have to do 80% of the time, automatically. So far, for me it works about 80-90% of the time without any tweaking. Other more discerning animators might feel like it’s more like 25-50% of the time but that’s compared to 0% of the time! That’s huge! And the results are buttery smooth in my opinion.

As I said in the other thread too, this needs to be the default behavior. I know Ton has seen mentioned about getting it into Master sooner than later but I just wanted to voice how good this actually is so that it isn’t forgotten.

It’s also worth mentioning that I compared the results with Maya, Max and Modo and all of them produce the identical worthless default behavior. see: Link. I think is a pretty large contributing factor to the whole reason why animators have come to think of working on computers as “fighting” it to do the right thing. With this patch, there is much less need for fighting.

Thank you and have a nice day.

Are the cases that still need tweaking bad curves, or just the computer not being intelligent enough to guess some intended detail that wasn’t expressed through keyframes? Is changing handles necessary, or can it be tweaked by adding more in-between keys in the problem area to specify the desired motion better?

The error can be reduced using the CGI Graphics i guess…, Click Here to know more…

Updated the test build with latest changes from master.

Maybe I misunderstand where the handle types are meant to be set but I prefer to use one default for everything, then either add keyframes and/or tweak the curves to get the desired result.

That being said, here are some visuals showing comparison (using Motion Trail/motion paths in 3d)

Automatic Clamp is only slightly different like it pushes the curve out a little more


However, Automatic really sticks out in an undesired way



Maybe that’s intentional and you’re supposed to use it in manually specified areas but if you do it like I do (everywhere) things are gonna look wonky.

A different way to look at that is that it is adding anticipation and follow-through to transitions between stationary and rapid movement for free. There aren’t enough keyframes to define the motion better.

When you try circular motion, it actually doesn’t add quite enough curve to form a circle, although it is way better than the original curves. Note that it’s mathematically impossible to achieve a perfect circle with cubic bezier curves in any case; it can only be an approximation.

Edtion,
your argumentation is a bit unclear to me.

  • the curves are quite undersampled, maybe it’s better to make the animation longer to see what’s happening to the curves.
  • you didn’t mark which one is new/old - I guess red is old
  • please specify what is undesired on the new behaviour and how you would imagine desired behaviour?
  • please show how your curves actually look in the graph, since your images are a bit misleading, since they don’t show correctly the spatio-temporal relations…

I’d rather not. This is the file >> !F-Curve_Anim.blend (92.4 KB)

I assumed angavrilov was replying to me and understood already what was happening.
No, red is Exp. F-Curve Smooth.

While the issue (end-result) is displayed clearly and visually in the second image in 3D View, the curve in Graph Editor for the Z axis displays the same wonky result.

If I were to try to describe in text what I think is happening and what’s wrong with it, it would be: it offshoots the curve in the opposite direction before going forward to the next keyframe, like anticipation (in animation) for the curves.

However, prior to finishing this reply, I performed some more tests and my observation is that this observes the entire curve and keyframes, or several keyframes and a distance/falloff between them, then makes a guess as to how the result is should be interpolated, whereas the regular Automatic guesses between 3 keyframes.

The problem is that it makes too many exaggerated guesses. It’d be great as an additional option but it’s too much for it to outright replace Automatic. If it were replaced, people would have to completely relearn/reguess how Blender would be creating [Automatic] in-betweens.

I was making another test to see what would happen if i have an object move on a single line forward (nothing) but then jump up on one keyframe (then I did some more tweaks) and as expected, it went wonky.

So, here’s a picture of a graph with all the keys at the same value but with one frame making a change.



adding frames helps manage the exaggeration but it still works too…interpolated

You know what, actually I think what’s happening is it’s trying to make an S-Curve through the keyframes to fit the curve, and that my issue is that it’s less predictable when thinking about it as keyframes, and not as a curve.

Well, cases where you don’t want any overshoot is precisely why there is an Auto Clamped mode, which is actually the normal default.

What the pure auto solver does is trace a cubic spline with continuous acceleration through the points, i.e. such a curve that if you sit on the object it would never jerk under you. The result is the only solution under this restriction, and auto clamp actually does its thing by allowing jumps in acceleration.

I think I see where things are getting weird. So, I may be totally wrong about but “Automatic” is different than default “Bezier” interpolation. Instead of changing handle type to “Automatic”, set is to interpolation to “Bezier.” The resulting curves are just smoother looking and feeling by default. You’re right that it’s using more than the next and previous keys to figure out the curvature but that’s what’s needed in order to produce smooth curves with Bezier mode. Obviously, that sends “Automatic” mode into an tizzy.

I have to say, as an animator I don’t ever use Automatic mode. I think if you asked Hjalti and other professional Blender animators, they would probably say the same.

However, I do realize that if you asked them they would most likely tell you that they never use any interpolation till the end anyway. But even in that situation this still give you smoother curves with less hassle out of the gate.

I do think you might be right that this should be a new interpolation type on it’s own so that if for some reason, you don’t like or are not used to the new mode, you are not just sh*t out of luck. :wink:

For my tastes though, this should be the default interpolation method.

Yes, absolutely the latter. sometimes you would want a longer or shorter ease and would need to tweak the tangents to get the desired results.

Most animators would just add a breakdown. In this case, since the interpolation is smoother, it still give better results.

From what I’ve been told by someone better at math, this kind of oscillation problems are kind of unavoidable with polynomial interpolation due to Runge phenomenon or something of that kind, and that it could be a lot better if it could be approximation instead, like how nurbs curves work :slight_smile:

Overall, in this approach Auto is for cases where you want smoothest motion even if it means some overshoots and oscillations, while Auto Clamp is when you want maximum control.

Incidentally, in that case above, you can squash the oscillation by adding a well placed keyframe to guide how the curve departs from the horizontal line. You need an extra keyframe there to provide space for acceleration to ramp up from zero.

Edit: like this to be precise. Red is auto clamp, blue full auto, and green is full auto with extra keys.

Attachments


If you make the curve go through a point then it’s interpolation. It’s not that nurbs curves don’t interpolate it is that they are Non Uniform, the ‘nu’ in ‘nurbs’ that allows nurbs to avoid the Runge phenomenon

Well, nurbs don’t directly pass through any of the control points, do they. That’s what was meant by approximation rather than interpolation. Unfortunately, animation requires interpolation.

If you need an extra keyframe it seems like the whole point is defeated… I was beginning to be sold on the idea but the latest pictures posted here are kind of frightening. :smiley:

You need an extra keyframe when for some reason you insist on getting a clamped motion without using Auto Clamped keyframes (which are the default type, mind you).

P.S. Avoiding the need for more keyframes or changing handle types to match the situation is not the goal. The goal is to remove the need to use completely manually set Aligned or Free handles in order to simply get smooth curves. Currently that is required.

I propose adding this to a new item called [Auto Smoothed]

Both as for being proposed for 2.8, as well as the current test-build.
I’d rather not always save and reload in regular builds to see how these differ, and I want them to be different options.