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

Wed Aug 9 22:27:40 CEST 2017

Regarding the cycle f-curve modifier affecting the end-point handles:

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.

--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
>>