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

Wed Aug 9 23:05:56 CEST 2017

Hi Alexander,

> It's not 'useful', it is _essential_.

I understated its usefulness, to be sure.  My apologies, as that
wasn't my intent.  My reservations aren't in whether to include the
functionality, but rather how it interacts with other things.

I also think that as much as I was understating its usefulness, you're
also overstating by calling it "essential".  I've animated a lot of
character animation loops for games and NLA work, and although
manually adjusting the tangents to match at the end points is annoying
and tedious, there are other equally annoying and tedious things that
this feature doesn't address:

1. Manually keeping track of how long the "loop" is supposed to be
(instead of that being something you can specify about the action).
2. Keeping the *values* of the end points matched. It would be nice at
some point to have a more holistic solution.

Having a more holistic solution for looping animations would be
really, _really_ nice.  That's more where I was coming from when I
called this feature "useful".  I'm seeing it from the perspective that
it's only one part of what really needs a bigger solution.  Being able
to set the length of an action and say whether the *action* is looping
or not, and then having everything "just work", is where I think we
need to go.

But, _having said that_, I am in support of this feature going in.  I
apologize if I came across as otherwise.

--Nathan

On Wed, Aug 9, 2017 at 1:41 PM, Alexander Gavrilov <angavrilov at gmail.com> wrote:
> On Wednesday, 9 August 2017 23:27:40 MSK Nathan Vegdahl wrote:
>> I'm not sure how I feel about that.  It certainly seems like a useful
>> behavior, but it might not be what people always want.  Can an option
>> be added to the modifier to enable/disable that?  Also, it doesn't
>> appear to work when either "Restrict Frame Range" or "Use Influence"
>> are enabled.
>
> It's not 'useful', it is _essential_. If interpolation doesn't work
> smoothly across the loop boundary, there is nearly no point in having
> a looping interpolation mode. Without the change the only choices to
> get useful results are to either ensure the loop ends on extremes of
> every curve (leads to a mess in the dopesheet) or change the handles
> on the loop ends to manual and adjust them all by hand.
>
> The feature only works with unrestricted infinite looping mode of the
> modifier because handles are in fact processed before modifiers and
> thus it can either use looping mode or not. Having an 'extrapolation mode'
> as a modifier is somewhat weird anyway and it already has restrictions
> like only being allowed as the first item in the stack.
>
> Enabling influence or frame range is thus also an indirect option
> to disable the new behavior.
>
>> --Nathan
>>
>> On Wed, Aug 9, 2017 at 1:19 PM, Nathan Vegdahl <nathanvegdahl at gmail.com> 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