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

Alexander Gavrilov angavrilov at gmail.com
Wed Aug 9 22:59:54 CEST 2017


Basically the thing here is that a fair (smooth) extensible (adding
redundant points doesn't change the shape) local (limited propagation
of influence) curve doesn't exist mathematically. The fact that legacy
blender auto handles only consider the adjacent 2 points is the precise
reason why the interpolation is awful. Interpolation is pretty important
for any users that don't have the skill or time/resources to key every
frame manually to film quality standards.

In practice (according to a comment in the original code by Benoit Bolsee)
the influence decreases exponentially with every key, and things like
Auto Clamped extremes and manually modified handles completely stop
propagation as they actually split the curve into sections that are
smoothed separately.


On Wednesday, 9 August 2017 23:19:06 MSK Nathan Vegdahl wrote:
> I downloaded the Linux build and played with it for a little while.
> My general impression is that--as with many things--it has both good
> and bad things.
> 
> Good:
> 
> 1. Smoother interpolation.  It's much easier to get motion that
> doesn't have hiccups or weird "stalls" in it.
> 
> 2. The curves don't change when you insert new keyframes with the same
> values as the curve had at that point already.  This is a _really_
> nice property to have, because it lets you more easily tweak animation
> curves (by inserting a new key and adjusting slightly).
> 
> Bad:
> 
> 3. The effects of keyframes aren't localized.  When tweaking the
> position of a keyframe, it can effect the interpolation of areas
> arbitrarily many keyframes away, whereas the old behavior at most
> affects areas two keyframes away on either side.  This is _really
> annoying_ because it makes it difficult to locally tweak things
> without messing up other parts of the animation that you already
> polished.
> 
> Honestly, points #2 and #3 are much more important to me than point
> #1.  While it's certainly nice to have smoother interpolation by
> default, for my workflow it's not _that_ compelling.  But point #2 is
> absolutely fantastic.  I _love_ it.  It makes adjusting animation
> soooo much easier.  On the other hand, Point #3 is really awful and
> makes adjusting animation _harder_.  So it feels like a trade of
> sorts.
> 
> However, regarding #3: in practice tweaking key frames doesn't seem to
> have a meaningful impact further than 5 key frames away on either side
> (I had to do extreme value changes to be able to tell it affected
> anything beyond that).  Furthermore, turning clamping on appears to
> keep things localized within 4 keyframes on either side.  That's still
> more non-locality than I'd like, but it's workable, and may be worth
> it for point #2.  (The downside to clamping is that it's not
> rotation-invariant--if you reorient the animation, it doesn't
> interpolate the same way--but in practice that probably doesn't matter
> much.)
> 
> So I think my recommendation is this:
> 
> I _do_ think this should be the new default because the trade-offs
> seem better.  However, I'd like to future-proof a bit for further R&D
> in this area since this still isn't an "ideal" behavior.
> 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.
> 
> --Nathan
> 
> 
> 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
> 





More information about the Bf-animsys mailing list