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

Nathan Vegdahl nathanvegdahl at gmail.com
Thu Aug 10 00:18:18 CEST 2017


Ah, interesting.  I didn't realize that C-infinity continuity and
extensibility were so tightly coupled.  So it's really a matter of
"fair+extensible vs local", then, rather than "pick any two".  Well,
that sucks.

Nevertheless, I think there is still some room for innovation in this
space.  Extensible-ish within certain limits might also practically be
good enough, for example.  And I think examining what "clamping"
really ought to mean is worth exploring further as well--it actually
has some problems in practice (try animating something along a
45-degree-aligned arc).

--Nathan



On Wed, Aug 9, 2017 at 2:41 PM, Alexander Gavrilov <angavrilov at gmail.com> wrote:
> I feel that any hard constraint on influence distance will result in
> violating extensibility: when you add a point, you push one point out
> from the influence range of points on either side of the added point.
> This must result in a change in the curve at least in some cases.
>
> Basically, if you want the curve to not change at all when you add a
> point, you must enforce the condition that all derivatives are continuous
> at that point, because they are always continuous between points. Since
> you don't know which point was just added, you must enforce that at all
> points. This produces the system of linear equations that is used by
> this method.
>
>
> On Thursday, 10 August 2017 00:28:18 MSK Nathan Vegdahl wrote:
>> Hi Alexander,
>> Before I respond to this, I want to make it clear that I am in support
>> of this becoming the new default.  I am not in any way arguing against
>> that below.  This is just general discussion now.
>>
>> > 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.
>>
>> Absolutely.  But these also don't have to be binary considerations.
>> F-curves are an artistic tool--they don't have to strictly adhere to
>> any mathematical criteria, we just need them to work well for their
>> intended purpose.  For example, this patch makes the trade-off of
>> being strictly fair while only being "local-ish" (the exponential
>> falloff you mentioned).  But we could choose to do it the other way
>> around and make them "fair-ish" while maintaining localized effect.
>>
>> I agree that Blender's current behavior isn't desirable, because the
>> trade-off there isn't good: you get some really wonky interpolations.
>> But it's not at all clear to me that this patch strikes the best
>> possible balance either.  I'd be interested at some point in exploring
>> other possibilities, that maybe keep the curve as smooth as artists
>> care about in practice with e.g. a support of only 3 key frames on
>> either side.
>>
>> --Nathan
>>
>>
>> On Wed, Aug 9, 2017 at 1:59 PM, Alexander Gavrilov <angavrilov at gmail.com> wrote:
>> > 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
>> >>
>> >
>> >
>> > _______________________________________________
>> > 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