Implement a new automatic handle algorithm to produce smooth F-Curves.

Authored by Alexander Gavrilov (angavrilov) on Oct 17 2017, 8:06 PM.



The legacy algorithm only considers two adjacent points when computing
the bezier handles, which cannot produce satisfactory results. Animators
are often forced to manually adjust all curves.

The new approach instead solves a system of equations to trace a cubic spline
with continuous second derivative through the whole segment of auto points,
delimited at ends by keyframes with handles set by other requirements.

This algorithm also adjusts Vector handles that face ordinary bezier keyframes
to achieve zero acceleration at the Vector keyframe, instead of simply pointing
it at the adjacent point.

Original idea and implementation by Benoit Bolsee <>;
code mostly rewritten to improve code clarity and extensibility.

Diff Detail

rB Blender

Ok, here are just a few general comments looking over the code. I'm going to assume that all the math/logic is fine, and that you'll handle any issues that crop up from that :)

For me, the biggest blocking issue is the allocate_arrays() thing.

Another general comment is to just go through checking on brace placement and spacing around operators (as per the style guide)


Where do these particular numbers come from?


Everytime I see this function and the buffer it produces, it seems over complicated.

Thinking about it again today, here's an alternative option you could consider:

  • Define a new struct, and have all the arrays as members of the struct
  • Define 2 functions to manage this struct - one to allocate the arrays (effectively replacing this one), and another to call whenever you need to do an early exit and free it.

Otherwise, I suggest leaving a comment above this function explaining what the heck is going on, and why we ended up with this :)


I'm tempted to put each term on a separate line, to make it easier to see the structure here, e.g.

float state = (a[i] * h[... % count] +
                    b[i] * h[i] +
                    c[i] * h[... % count]

On separate lines.


We have a convention with the math lib to indicate output variables with the r_ prefix (and/or often putting it first/last). In this case, that may help make it easier to notice that it's an output value and not just another one of the inputs.


One last thought: How likely is it that we're going to need to have other functions supplied here? (i.e. do we really need to keep these as function pointers). Given that this is only called once, we can probably get away with hardcoding things now - if experimenting with methods in future, simply #ifdef'ing the function bodies of the methods used would probably be sufficient to switch out the code for testing)

Fixed some of the code style problems.

This revision is now accepted and ready to land.Nov 1 2017, 12:29 PM
This revision was automatically updated to reflect the committed changes.