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

Nathan Vegdahl nathanvegdahl at gmail.com
Wed Aug 9 23:46:59 CEST 2017


> [...] but I felt it's utterly ridiculous that you can't animate a
> loop without doing something for every single curve in the Curve Editor.

Yeah, it's certainly not a good situation!  Believe me, I've done my
fair share of pulling my hair out over this stuff. :-)

> Well, at least these things can be done from the Dope Sheet by
> copying and moving key columns, instead of having to go through
> all curves one by one :)

Eh... not quite.  For really simple cases, sure.  But in practice, the
restriction to keep all of the first and last keys on the same frame
is _itself_ an infuriating restriction.  Many times when working on
animation loops, I offset things one way or another, and then I can't
do the simple column-select + duplicate-move thing anymore.

Moreover, when things aren't all aligned on a single column, that also
means that the first and last keyframe of the action can't be used to
accurately determine its length anymore, which is extremely annoying
when then exporting the animation (for a game) or pulling the action
into the NLA editor.  For game export, you have to do something weird
like include the animation length in the action name (and write your
exporter to use that).  And in the case of NLA, you have to manually
set the length of the clip every time you pull an action in.

I think having a system that:

1. Lets you (optionally) specify the start/end frames of an action.
2. Lets you explicitly mark an action as looping.
3. Uses points 1 and 2 above to create an excellent looping animation
editing experience.
4. Uses points 1 and 2 above to make exporting animations and using
actions in the NLA editor "just work".

...would be a god-send.

--Nathan


On Wed, Aug 9, 2017 at 2:33 PM, Alexander Gavrilov <angavrilov at gmail.com> wrote:
> On Thursday, 10 August 2017 00:05:56 MSK Nathan Vegdahl wrote:
>> > 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.
>
> Maybe my wording wasn't best either - it's midnight and I'm tired and sleepy :)
>
>> 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:
>
> My experience basically amounts to trying to animate a few walk cycles
> for fun, but I felt it's utterly ridiculous that you can't animate a
> loop without doing something for every single curve in the Curve Editor.
>
>> 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.
>
> Well, at least these things can be done from the Dope Sheet by
> copying and moving key columns, instead of having to go through
> all curves one by one :)
>
> Maybe key editing operations could update the key on the other end
> when looping is enabled, unless it's cycle with offset. Looping the
> whole action could technically already be done through NLA, but that
> functionality is so remote from the curve itself that it definitely
> can't affect handles on the ends. And it's conceivable that for some
> reason you might want to loop different bones on different cycles.
>
>> 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
>> _______________________________________________
>> 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