[Bf-animsys] proposal: Better F-Curve auto handle calculation

Thu Aug 10 21:14:54 CEST 2017

On Wednesday, 9 August 2017 23:19:06 MSK Nathan Vegdahl wrote:
> Specifically, having a single checkbox to enable the new behavior
> seems short-sighted: if better interpolation approaches show up in the
> future, we'll have to add additional checkboxes, and it will turn into
> a weird mess of checkboxes that really should be a single enum.  So
> before merging, PLEASE change the checkbox to an enum/dropdown.  It
> doesn't hurt anything if we don't get anything additional in the
> future, but it prevents an awful confusing mess if we do.

So I have made a version with an enum instead of a flag and put it here:

https://developer.blender.org/diffusion/BS/history/smooth-fcurves/

I have also merged a few of the commits so only two are left. Now I wonder
how best to submit this for code review as these are technically two separate
features, but the code changes depend on each other. Differential doesn't
really deal with multicommit branches that well...

Another question is whether this is going into master, and generally what's the
status of master vs 2.8 branch once the (presumably) last 2.7* release is done.

> On Wed, Aug 9, 2017 at 4:40 AM, Joshua Leung <aligorith at gmail.com> wrote:
> > Hi,
> >
> > I thought most of the discussion for this was already happening in the
> > tracker report for this. I'm all in favour of stuff that makes life for
> > animators easier - in particular, if it's something that happens a lot (as
> > is the case here).
> >
> > Last time I checked, my main concern was regarding backwards compatability.
> > Specifically, although it only modifies old curves when handle recalc
> > occurs, care is needed as handle recalc doesn't only occur when editing the
> > curve - for instance, it can also happen when NLA time remapping occurs
> > (e.g. entering/exiting tweakmode on a NLA strip), and probably a few other
> > cases too.
> >
> > (EDIT: The per-curve option mentioned on the Graphicall build probably
> > resolves the backwards compat/handle-editing problem, though the devil is in
> > the details :)
> >
> > On another note, there's another patch floating around that deals with
> > similar issues (or rather, only the case where the user is inserting a new
> > keyframe).
> >     https://developer.blender.org/D2642
> > I'd be curious to hear from animators who've tried D2642 how effective it
> > is, and/or whether it'd still be necessary in light of these handle
> > calculation changes.
> >
> >
> > Regards,
> > Joshua
> >
> >
> > On Wed, Aug 9, 2017 at 10:42 PM, Sergey Sharybin <sergey.vfx at gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> It is hard to justify how well it'll sustain all possible animation
> >> scenarios. Now when we're at BCon1, maybe we can be relaxed and merge the
> >> code to master?
> >>
> >> On Wed, Aug 9, 2017 at 11:06 AM, Ton Roosendaal <ton at blender.org> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> This proposal went unreplied to, but I think it's important to give
> >>> proper attention.
> >>>
> >>> Doc and picture is here. It's actually quite obvious.
> >>> http://graphicall.org/1221
> >>>
> >>> I coded the old auto handle. It was an invention back then (no other sw
> >>> had it), and I simply put the the handle points parallel to the line between
> >>> the prev/next control point. Although that creates satisfying circles, it
> >>> fails to interpolate well. This patch solves this, without breaking Blender
> >>> (only on editing curves the handles re-cacalc).
> >>>
> >>> Thanks,
> >>>
> >>> -Ton-
> >>>
> >>> --------------------------------------------------------
> >>> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> >>> Chairman Blender Foundation, Director Blender Institute
> >>> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
> >>>
> >>> On 16 May 2017, at 10:27, Alexander Gavrilov <angavrilov at gmail.com>
> >>> wrote:
> >>>
> >>> Hello,
> >>>
> >>> It's known that the way auto handles work in blender curves isn't great,
> >>> and there
> >>> have been complaints that animators are often forced to either manually
> >>> adjust all
> >>> curve handles, or bypass interpolation by keyframing every frame
> >>> manually.
> >>>
> >>> Obviously, automatic interpolation can't hope to produce better animation
> >>> than
> >>> a human, but it should be usable when absolute top quality is not
> >>> required.
> >>> Thus I have taken a somewhat old patch by Benoit Bolsee that implements a
> >>> mathematical approach that produces smooth F-Curves and did some
> >>> rewriting
> >>> and adding features to get it working solidly.
> >>>
> >>>
> >>> However since I'm not an animator I cannot evaluate myself how well these
> >>> new auto-handles would work in practical workflows, and how significant
> >>> is
> >>> the improvement in the interpolated motion compared to the old way.
> >>>
> >>> One possible point of contention might be that producing smooth curves
> >>> necessarily
> >>> means that modifying keys affects the curve even at some distance from
> >>> the affected
> >>> key (although the degree of changes drops exponentially with distance,
> >>> and propagation
> >>> is completely stopped by Auto Clamped extremes or manual handles.)
> >>>
> >>> Also the degree this affects existing animations would determine how much
> >>> attention
> >>> to backward compatibility would be needed if this is adopted in 2.8:
> >>> should it e.g.
> >>> implement a legacy mode for curves created in previous versions with an
> >>> explicit
> >>> upgrade operation, or keep the shape until the curve is modified, or just
> >>> recalculate
> >>> shape etc.
> >>>
> >>>
> >>> I have uploaded a windows build of this branch (based on master for ease
> >>> of
> >>> testing) to GraphicAll, with more details on the design in the
> >>> description:
> >>>
> >>> http://graphicall.org/1221
> >>>
> >>> The build there can open master branch files without problems, and the
> >>> handles on
> >>> curves are only updated when the curve is touched by a modification
> >>> operation
> >>> (even if it is cancelled like G Esc), which may aid comparing.
> >>>
> >>> Alexander
> >>>
> >>> _______________________________________________
> >>> Bf-animsys mailing list
> >>> Bf-animsys at blender.org
> >>> https://lists.blender.org/mailman/listinfo/bf-animsys
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Bf-animsys mailing list
> >>> Bf-animsys at blender.org
> >>> https://lists.blender.org/mailman/listinfo/bf-animsys
> >>>
> >>
> >>
> >>
> >> --
> >> With best regards, Sergey Sharybin
> >>
> >> _______________________________________________
> >> Bf-animsys mailing list
> >> Bf-animsys at blender.org
> >> https://lists.blender.org/mailman/listinfo/bf-animsys
> >>
> >
> >
> > _______________________________________________
> > Bf-animsys mailing list
> > Bf-animsys at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-animsys
> >
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> https://lists.blender.org/mailman/listinfo/bf-animsys
> 