Page MenuHome

Implement cyclic extrapolation as F-Curve option and make it smooth.
AbandonedPublic

Authored by Alexander Gavrilov (angavrilov) on Aug 14 2017, 9:00 PM.

Details

Summary

Previously cyclic extrapolation of F-Curves has been implemented
as a modifier that alters the evaluation of the curve after its
handles are already determined. This sounds reasonable, but in
practice means that auto handles at the end points of the loop
are not aware of the loop and are placed horizontally as normal.
This causes a hiccup in the animation and the animator is forced
to always manually modify these handles for every curve.

In order to make auto handle placement aware of the loop it is
necessary to either add hacky interaction between the F-Curve
itself and its modifiers, or replace the simplest and most common
uses of the modifier with an option of the F-Curve itself.

This change adds two new modes for the existing F-Curve extrapolation
setting that implement looping without any restrictions on frame range.
The auto-handle placement code is made aware of them to achieve smooth
transition. The modifier is kept for backward compatibility and cases
when its advanced settings are necessary.

Since the new auto handle behavior is only applied to the new options,
this is fully backward compatible.

Diff Detail

Repository
rB Blender
Branch
cyclic-extrapolation
Build Status
Buildable 767
Build 767: arc lint + arc unit

Event Timeline

This is an alternative to D2783 that doesn't involve hacky interactions between curves and modifiers.

I've mixed feelings on this approach:

  • On one hand, this patch seems simpler, with less stuff needing to be modified.
  • On the other hand, this duplicates functionality, while also regressing Blender back to an earlier design (i.e. the predecessor of the current modifier-based approach), along with all the flaws that that approach had.

Personally, I slightly prefer the other approach (if we can smooth out the kinks with it), but this approach is also ok in the worst case.

Took into account some of the feedback on the other version of the patch.

As I mentioned in the email, hackiness of the other patch isn't merely
because of the code - that approach fundamentally breaks the abstraction
of the modifier by taking its presense into accound when calculating
handles. A nice little modifer that makes the curve cyclic by merely
adjusting evaluation time sounds good theoretically, but in practice
it turns out that this is not enough to make a _convenient_ cyclic
animation feature.

Btw I wonder how many people actually use all the options of the
modifier, especially given that there isn't a convenient way to change
them in bulk. Just one bone is 3 to 10 curves, so most people won't
bother using things that can only be manually set one curve at a time.
@Nathan Vegdahl (cessen) mentioned it would be even better to be able to configure
cyclicity at _action_ level.

Why no reply for almost a month?

After a discussion in IRC it seems D2783 is the way to go, at least for now.