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

Tue Aug 15 15:00:22 CEST 2017

It's interesting how we're going full-circle on the interpolation options
here (2.4x's IPO-Curves had these two exact cyclic extrapolation modes in
that exact enum). ;)

I've had a look at both patches. TBH, I'm on the fence about parts of both
approaches:
- D2783 ("hacky" approach) is a bit too invasive in places, especially how
quite a number of places needed to be changed just so that the RNA update
calls could easily lookup the F-Curve (to force the handles to get
recalculated). However, considered from another perspective, those having
those F-Curve backlinks is not necessarily a bad thing, as quite a few RNA
callbacks (e.g. the FModifier rna_path getters) there currently have to
traverse all the F-Curves in the AnimData block (i.e. all F-Curves in all
attached actions, drivers, and NLA strips) to try to find where they come
from.

- D2790 (back-to-the-future approach) is obviously a much simpler patch. It
also removes much of the need to jump through hoops to access the modifier
data. BUT, on the other hand, it duplicates functionality, while negating
the benefits of the FModifier, i.e.
     1. Greater control/flexibiltiy over how the repeats happen, with
flexibility for easily adding more options later without polluting the
F-Curve struct/namespace,
     2. F-Curve evaluation doesn't have any funky time/value-manipulation
magic, leaving the door open for more special cases to also be tacked on.
By having it as a FModifier (i.e. by definition, a filter/wrapper around
the evaluated results whose sole purpose is to perform time/value
fiddling), it's instead handled just like any other effect that works this
way, instead of it being a special case.

if we do go with the second option, I don't think we should do anything
with old files. They should left as-is. Same as the Make/Clear Cyclic
operators (though maybe we add "(Advanced)" to the names for those).

Regards,
Joshua

On Tue, Aug 15, 2017 at 7:49 PM, Alexander Gavrilov <angavrilov at gmail.com>
wrote:

> So yesterday I implemented simple infinite cycle as a new extrapolation
> mode
> of the F-Curve proper, obsoleting the modifier with fully default
> settings. This
> avoids the need for abstraction violating hacks in the code at the cost of
> small
> duplication of functionality:
>
> https://developer.blender.org/D2790
>
> One question is whether blender should automatically replace the old
> modifier
> with default settings with the new modes on file load, or keep it as is
> and leave the
> process to the user; and also what to do with the old Make Cyclic and
> Clear Cyclic
> options in the extrapolation menu.
>
> On Mon, Aug 14, 2017 at 12:54 PM, Alexander Gavrilov <angavrilov at gmail.com
> > wrote:
>
>> Maybe the importance of loops in practice and the necessity of additional
>> support in auto handles and editing to make cyclic curves really nice to
>> use
>> means that unbounded cyclic extrapolation (i.e. without any frame range
>> or influence limits) should be an fcurve feature without any 'modifiers'
>> being involved. I.e. keep the modifier for those that want to use the
>> additional
>> options, but add Cycle and Cycle with Offset as new entries of the
>> extrapolation
>> mode setting of the fcurve itself. It may duplicate some functionality,
>> but will
>> allow adding new loop usability features without 'magic modifier' hacks.
>>
>> On Fri, Aug 11, 2017 at 9:22 PM, Nathan Vegdahl <nathanvegdahl at gmail.com>
>> wrote:
>>
>>> Hmm... I guess I'm a little wary of f-curve modifiers becoming too
>>> "magical".  I'm not sure if this really qualifies, but it makes my
>>> "magical" sense tingle. ;-)  However, that certainly seems like it
>>> would be an excellent behavior for the more holistic system, at the
>>> very least.
>>>
>>> I don't want to beat a dead horse, but looping animations are such a
>>> common thing (especially in game dev, but also sometimes in movie
>>> production) that having first-class support for it would be really
>>> great.  I'd rather see effort go towards first-class support than
>>> piece-meal creating features that have to be carefully turned on
>>> one-by-one by the user, that aren't necessarily obvious to the user,
>>> and that might not interact with each other reliably.  But, of course,
>>> I'm not doing any of the dev work, so I don't mean to dictate.  Just
>>> my two cents. :-)
>>>
>>> --Nathan
>>>
>>> On Fri, Aug 11, 2017 at 11:01 AM, Alexander Gavrilov
>>> <angavrilov at gmail.com> wrote:
>>> > I wonder if it could be useful to improve interaction of 'I' keyframing
>>> > with Cyclic Extrapolation. Namely, maybe as an option when you keyframe
>>> > a channel with cyclic extrapolation, automatically retime the key that
>>> > is being inserted or updated to be within the existing loop and if its
>>> > on an end keyframe update both ends. This won't help in creating the
>>> cycle
>>> > with proper timing, but may help in tweaking the animation.
>>> >
>>> > Also, as a start in getting my changes reviewed, I have submitted
>>> > a diff for the auto handle with cyclic extrapolation part:
>>> >
>>> > https://developer.blender.org/D2783
>>> >
>>> >
>>> > On Friday, 11 August 2017 02:57:46 MSK Nathan Vegdahl wrote:
>>> >> Hi Alexander,
>>> >>
>>> >> > This can probably be helped by making some kind of addon in the
>>> meantime
>>> >> > that would sync ends of curves with cyclic extrapolation and verify
>>> that
>>> >> > their periods match.
>>> >>
>>> >> That would certainly help, yeah.  The next time I need to make a
>>> >> looping animation I might play around with whipping something like
>>> >> that up. :-)
>>> >>
>>> >> > Do you have ideas re how editing a looping action should work?
>>> >>
>>> >> I think the details would probably need to be worked out with a bit of
>>> >> trial-and-error and iteration.  But the broad-strokes are.
>>> >>
>>> >> - The first keyframe would automatically be the last keyframe as well
>>> >> (offset action-length frames later).  I'm guessing not as a literally
>>> >> manipulable key duplicated in two cases, but dunno.
>>> >> - Visually the f-curve would continue infinitely into the past and
>>> >> future (just like with the cycle modifier).
>>> >> - Any auto-handle type stuff would behave as if the keyframes were
>>> >> themselves duplicated infinitely into infinity (much like this new
>>> >> cycle modifier behavior).
>>> >>
>>> >> That still leaves a lot of open questions, of course.  For example,
>>> >> what to do when a user tries to move a keyframe past the length of the
>>> >> loop (relative to the first key)?  Or drags the first key leftward
>>> >> past the length of the loop relative to the last key?  Or what happens
>>> >> when a user switches an existing action to "loop" if the keys already
>>> >> in it don't fit in the loop length?  How do we visually indicate the
>>> >> loop length in the f-curves and action editor, since each f-curve may
>>> >> be offset from the others.  Etc.
>>> >>
>>> >> But I think with some trial-and-error and iteration these things could
>>> >> be sorted out satisfactorily.  Figure out what feels good and is the
>>> >> least surprising.
>>> >>
>>> >> --Nathan
>>> >>
>>> >>
>>> >> On Thu, Aug 10, 2017 at 11:53 AM, Alexander Gavrilov
>>> >> <angavrilov at gmail.com> wrote:
>>> >> > On Thursday, 10 August 2017 00:46:59 MSK Nathan Vegdahl wrote:
>>> >> >> > 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.
>>> >> >
>>> >> > This can probably be helped by making some kind of addon in the
>>> meantime
>>> >> > that would sync ends of curves with cyclic extrapolation and verify
>>> that
>>> >> > their periods match.
>>> >> >
>>> >> >> 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".
>>> >> >
>>> >> > Do you have ideas re how editing a looping action should 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
>>> >> >> _______________________________________________
>>> >> >> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20170816/6f538341/attachment.html>