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

Alexander Gavrilov angavrilov at gmail.com
Wed Aug 9 23:45:38 CEST 2017


The important thing is to never add manual (i.e. Aligned or Free) handles
when the curve uses automatic handles. Every key with manual handles is a
liability because you can't fully control it with just Dope Sheet and keying
and must use the Curve editor. When explicitly adding a manual key then
there is no reason not to compute the handles in a more intelligent way.


On Wednesday, 9 August 2017 23:28:55 MSK Jeffrey wrote:
> Might I also argue for including both smooth-curves _and_ D2642? As far
> as I'm concerned, inserting a keyframe shouldn't change the curve at any
> time, whether on auto curves or custom. The new auto is undoubtedly more
> helpful, but it doesn't cover the case of adding keys on custom curves,
> while D2642 does exactly what I want and expect for those.
> 
> On 08/09/2017 01:19 PM, 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