<div dir="ltr"><div>So yesterday I implemented simple infinite cycle as a new extrapolation mode</div><div>of the F-Curve proper, obsoleting the modifier with fully default settings. This</div><div>avoids the need for abstraction violating hacks in the code at the cost of small</div><div>duplication of functionality:</div><div><br></div><a href="https://developer.blender.org/D2790">https://developer.blender.org/D2790</a><br><div class="gmail_extra"><br></div><div class="gmail_extra">One question is whether blender should automatically replace the old modifier</div><div class="gmail_extra">with default settings with the new modes on file load, or keep it as is and leave the</div><div class="gmail_extra">process to the user; and also what to do with the old Make Cyclic and Clear Cyclic</div><div class="gmail_extra">options in the extrapolation menu.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 14, 2017 at 12:54 PM, Alexander Gavrilov <span dir="ltr"><<a href="mailto:angavrilov@gmail.com" target="_blank">angavrilov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Maybe the importance of loops in practice and the necessity of additional<div>support in auto handles and editing to make cyclic curves really nice to use</div><div>means that unbounded cyclic extrapolation (i.e. without any frame range<div>or influence limits) should be an fcurve feature without any 'modifiers'</div><div>being involved. I.e. keep the modifier for those that want to use the additional</div><div>options, but add Cycle and Cycle with Offset as new entries of the extrapolation</div><div>mode setting of the fcurve itself. It may duplicate some functionality, but will</div><div>allow adding new loop usability features without 'magic modifier' hacks.</div><div><div class="gmail-h5"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 11, 2017 at 9:22 PM, Nathan Vegdahl <span dir="ltr"><<a href="mailto:nathanvegdahl@gmail.com" target="_blank">nathanvegdahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hmm... I guess I'm a little wary of f-curve modifiers becoming too<br>
"magical".  I'm not sure if this really qualifies, but it makes my<br>
"magical" sense tingle. ;-)  However, that certainly seems like it<br>
would be an excellent behavior for the more holistic system, at the<br>
very least.<br>
<br>
I don't want to beat a dead horse, but looping animations are such a<br>
common thing (especially in game dev, but also sometimes in movie<br>
production) that having first-class support for it would be really<br>
great.  I'd rather see effort go towards first-class support than<br>
piece-meal creating features that have to be carefully turned on<br>
one-by-one by the user, that aren't necessarily obvious to the user,<br>
and that might not interact with each other reliably.  But, of course,<br>
I'm not doing any of the dev work, so I don't mean to dictate.  Just<br>
my two cents. :-)<br>
<br>
--Nathan<br>
<br>
On Fri, Aug 11, 2017 at 11:01 AM, Alexander Gavrilov<br>
<div class="gmail-m_-8033960820230923005HOEnZb"><div class="gmail-m_-8033960820230923005h5"><<a href="mailto:angavrilov@gmail.com" target="_blank">angavrilov@gmail.com</a>> wrote:<br>
> I wonder if it could be useful to improve interaction of 'I' keyframing<br>
> with Cyclic Extrapolation. Namely, maybe as an option when you keyframe<br>
> a channel with cyclic extrapolation, automatically retime the key that<br>
> is being inserted or updated to be within the existing loop and if its<br>
> on an end keyframe update both ends. This won't help in creating the cycle<br>
> with proper timing, but may help in tweaking the animation.<br>
><br>
> Also, as a start in getting my changes reviewed, I have submitted<br>
> a diff for the auto handle with cyclic extrapolation part:<br>
><br>
> <a href="https://developer.blender.org/D2783" rel="noreferrer" target="_blank">https://developer.blender.org/<wbr>D2783</a><br>
><br>
><br>
> On Friday, 11 August 2017 02:57:46 MSK Nathan Vegdahl wrote:<br>
>> Hi Alexander,<br>
>><br>
>> > This can probably be helped by making some kind of addon in the meantime<br>
>> > that would sync ends of curves with cyclic extrapolation and verify that<br>
>> > their periods match.<br>
>><br>
>> That would certainly help, yeah.  The next time I need to make a<br>
>> looping animation I might play around with whipping something like<br>
>> that up. :-)<br>
>><br>
>> > Do you have ideas re how editing a looping action should work?<br>
>><br>
>> I think the details would probably need to be worked out with a bit of<br>
>> trial-and-error and iteration.  But the broad-strokes are.<br>
>><br>
>> - The first keyframe would automatically be the last keyframe as well<br>
>> (offset action-length frames later).  I'm guessing not as a literally<br>
>> manipulable key duplicated in two cases, but dunno.<br>
>> - Visually the f-curve would continue infinitely into the past and<br>
>> future (just like with the cycle modifier).<br>
>> - Any auto-handle type stuff would behave as if the keyframes were<br>
>> themselves duplicated infinitely into infinity (much like this new<br>
>> cycle modifier behavior).<br>
>><br>
>> That still leaves a lot of open questions, of course.  For example,<br>
>> what to do when a user tries to move a keyframe past the length of the<br>
>> loop (relative to the first key)?  Or drags the first key leftward<br>
>> past the length of the loop relative to the last key?  Or what happens<br>
>> when a user switches an existing action to "loop" if the keys already<br>
>> in it don't fit in the loop length?  How do we visually indicate the<br>
>> loop length in the f-curves and action editor, since each f-curve may<br>
>> be offset from the others.  Etc.<br>
>><br>
>> But I think with some trial-and-error and iteration these things could<br>
>> be sorted out satisfactorily.  Figure out what feels good and is the<br>
>> least surprising.<br>
>><br>
>> --Nathan<br>
>><br>
>><br>
>> On Thu, Aug 10, 2017 at 11:53 AM, Alexander Gavrilov<br>
>> <<a href="mailto:angavrilov@gmail.com" target="_blank">angavrilov@gmail.com</a>> wrote:<br>
>> > On Thursday, 10 August 2017 00:46:59 MSK Nathan Vegdahl wrote:<br>
>> >> > Well, at least these things can be done from the Dope Sheet by<br>
>> >> > copying and moving key columns, instead of having to go through<br>
>> >> > all curves one by one :)<br>
>> >><br>
>> >> Eh... not quite.  For really simple cases, sure.  But in practice, the<br>
>> >> restriction to keep all of the first and last keys on the same frame<br>
>> >> is _itself_ an infuriating restriction.  Many times when working on<br>
>> >> animation loops, I offset things one way or another, and then I can't<br>
>> >> do the simple column-select + duplicate-move thing anymore.<br>
>> ><br>
>> >> Moreover, when things aren't all aligned on a single column, that also<br>
>> >> means that the first and last keyframe of the action can't be used to<br>
>> >> accurately determine its length anymore, which is extremely annoying<br>
>> >> when then exporting the animation (for a game) or pulling the action<br>
>> >> into the NLA editor.  For game export, you have to do something weird<br>
>> >> like include the animation length in the action name (and write your<br>
>> >> exporter to use that).  And in the case of NLA, you have to manually<br>
>> >> set the length of the clip every time you pull an action in.<br>
>> ><br>
>> > This can probably be helped by making some kind of addon in the meantime<br>
>> > that would sync ends of curves with cyclic extrapolation and verify that<br>
>> > their periods match.<br>
>> ><br>
>> >> I think having a system that:<br>
>> >><br>
>> >> 1. Lets you (optionally) specify the start/end frames of an action.<br>
>> >> 2. Lets you explicitly mark an action as looping.<br>
>> >> 3. Uses points 1 and 2 above to create an excellent looping animation<br>
>> >> editing experience.<br>
>> >> 4. Uses points 1 and 2 above to make exporting animations and using<br>
>> >> actions in the NLA editor "just work".<br>
>> ><br>
>> > Do you have ideas re how editing a looping action should work?<br>
>> ><br>
>> ><br>
>> >> ...would be a god-send.<br>
>> >><br>
>> >> --Nathan<br>
>> >><br>
>> >><br>
>> >> On Wed, Aug 9, 2017 at 2:33 PM, Alexander Gavrilov <<a href="mailto:angavrilov@gmail.com" target="_blank">angavrilov@gmail.com</a>> wrote:<br>
>> >> > On Thursday, 10 August 2017 00:05:56 MSK Nathan Vegdahl wrote:<br>
>> >> >> > It's not 'useful', it is _essential_.<br>
>> >> >><br>
>> >> >> I understated its usefulness, to be sure.  My apologies, as that<br>
>> >> >> wasn't my intent.  My reservations aren't in whether to include the<br>
>> >> >> functionality, but rather how it interacts with other things.<br>
>> >> ><br>
>> >> > Maybe my wording wasn't best either - it's midnight and I'm tired and sleepy :)<br>
>> >> ><br>
>> >> >> I also think that as much as I was understating its usefulness, you're<br>
>> >> >> also overstating by calling it "essential".  I've animated a lot of<br>
>> >> >> character animation loops for games and NLA work, and although<br>
>> >> >> manually adjusting the tangents to match at the end points is annoying<br>
>> >> >> and tedious, there are other equally annoying and tedious things that<br>
>> >> >> this feature doesn't address:<br>
>> >> ><br>
>> >> > My experience basically amounts to trying to animate a few walk cycles<br>
>> >> > for fun, but I felt it's utterly ridiculous that you can't animate a<br>
>> >> > loop without doing something for every single curve in the Curve Editor.<br>
>> >> ><br>
>> >> >> 1. Manually keeping track of how long the "loop" is supposed to be<br>
>> >> >> (instead of that being something you can specify about the action).<br>
>> >> >> 2. Keeping the *values* of the end points matched. It would be nice at<br>
>> >> >> some point to have a more holistic solution.<br>
>> >> ><br>
>> >> > Well, at least these things can be done from the Dope Sheet by<br>
>> >> > copying and moving key columns, instead of having to go through<br>
>> >> > all curves one by one :)<br>
>> >> ><br>
>> >> > Maybe key editing operations could update the key on the other end<br>
>> >> > when looping is enabled, unless it's cycle with offset. Looping the<br>
>> >> > whole action could technically already be done through NLA, but that<br>
>> >> > functionality is so remote from the curve itself that it definitely<br>
>> >> > can't affect handles on the ends. And it's conceivable that for some<br>
>> >> > reason you might want to loop different bones on different cycles.<br>
>> >> ><br>
>> >> >> Having a more holistic solution for looping animations would be<br>
>> >> >> really, _really_ nice.  That's more where I was coming from when I<br>
>> >> >> called this feature "useful".  I'm seeing it from the perspective that<br>
>> >> >> it's only one part of what really needs a bigger solution.  Being able<br>
>> >> >> to set the length of an action and say whether the *action* is looping<br>
>> >> >> or not, and then having everything "just work", is where I think we<br>
>> >> >> need to go.<br>
>> >> >><br>
>> >> >> But, _having said that_, I am in support of this feature going in.  I<br>
>> >> >> apologize if I came across as otherwise.<br>
>> >> >><br>
>> >> >> --Nathan<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> On Wed, Aug 9, 2017 at 1:41 PM, Alexander Gavrilov <<a href="mailto:angavrilov@gmail.com" target="_blank">angavrilov@gmail.com</a>> wrote:<br>
>> >> >> > On Wednesday, 9 August 2017 23:27:40 MSK Nathan Vegdahl wrote:<br>
>> >> >> >> I'm not sure how I feel about that.  It certainly seems like a useful<br>
>> >> >> >> behavior, but it might not be what people always want.  Can an option<br>
>> >> >> >> be added to the modifier to enable/disable that?  Also, it doesn't<br>
>> >> >> >> appear to work when either "Restrict Frame Range" or "Use Influence"<br>
>> >> >> >> are enabled.<br>
>> >> >> ><br>
>> >> >> > It's not 'useful', it is _essential_. If interpolation doesn't work<br>
>> >> >> > smoothly across the loop boundary, there is nearly no point in having<br>
>> >> >> > a looping interpolation mode. Without the change the only choices to<br>
>> >> >> > get useful results are to either ensure the loop ends on extremes of<br>
>> >> >> > every curve (leads to a mess in the dopesheet) or change the handles<br>
>> >> >> > on the loop ends to manual and adjust them all by hand.<br>
>> >> >> ><br>
>> >> >> > The feature only works with unrestricted infinite looping mode of the<br>
>> >> >> > modifier because handles are in fact processed before modifiers and<br>
>> >> >> > thus it can either use looping mode or not. Having an 'extrapolation mode'<br>
>> >> >> > as a modifier is somewhat weird anyway and it already has restrictions<br>
>> >> >> > like only being allowed as the first item in the stack.<br>
>> >> >> ><br>
>> >> >> > Enabling influence or frame range is thus also an indirect option<br>
>> >> >> > to disable the new behavior.<br>
>> >> >> ><br>
>> >> >> >> --Nathan<br>
>> >> >> >><br>
>> >> >> >> On Wed, Aug 9, 2017 at 1:19 PM, Nathan Vegdahl <<a href="mailto:nathanvegdahl@gmail.com" target="_blank">nathanvegdahl@gmail.com</a>> wrote:<br>
>> >> >> >> > I downloaded the Linux build and played with it for a little while.<br>
>> >> >> >> > My general impression is that--as with many things--it has both good<br>
>> >> >> >> > and bad things.<br>
>> >> >> >> ><br>
>> >> >> >> > Good:<br>
>> >> >> >> ><br>
>> >> >> >> > 1. Smoother interpolation.  It's much easier to get motion that<br>
>> >> >> >> > doesn't have hiccups or weird "stalls" in it.<br>
>> >> >> >> ><br>
>> >> >> >> > 2. The curves don't change when you insert new keyframes with the same<br>
>> >> >> >> > values as the curve had at that point already.  This is a _really_<br>
>> >> >> >> > nice property to have, because it lets you more easily tweak animation<br>
>> >> >> >> > curves (by inserting a new key and adjusting slightly).<br>
>> >> >> >> ><br>
>> >> >> >> > Bad:<br>
>> >> >> >> ><br>
>> >> >> >> > 3. The effects of keyframes aren't localized.  When tweaking the<br>
>> >> >> >> > position of a keyframe, it can effect the interpolation of areas<br>
>> >> >> >> > arbitrarily many keyframes away, whereas the old behavior at most<br>
>> >> >> >> > affects areas two keyframes away on either side.  This is _really<br>
>> >> >> >> > annoying_ because it makes it difficult to locally tweak things<br>
>> >> >> >> > without messing up other parts of the animation that you already<br>
>> >> >> >> > polished.<br>
>> >> >> >> ><br>
>> >> >> >> > Honestly, points #2 and #3 are much more important to me than point<br>
>> >> >> >> > #1.  While it's certainly nice to have smoother interpolation by<br>
>> >> >> >> > default, for my workflow it's not _that_ compelling.  But point #2 is<br>
>> >> >> >> > absolutely fantastic.  I _love_ it.  It makes adjusting animation<br>
>> >> >> >> > soooo much easier.  On the other hand, Point #3 is really awful and<br>
>> >> >> >> > makes adjusting animation _harder_.  So it feels like a trade of<br>
>> >> >> >> > sorts.<br>
>> >> >> >> ><br>
>> >> >> >> > However, regarding #3: in practice tweaking key frames doesn't seem to<br>
>> >> >> >> > have a meaningful impact further than 5 key frames away on either side<br>
>> >> >> >> > (I had to do extreme value changes to be able to tell it affected<br>
>> >> >> >> > anything beyond that).  Furthermore, turning clamping on appears to<br>
>> >> >> >> > keep things localized within 4 keyframes on either side.  That's still<br>
>> >> >> >> > more non-locality than I'd like, but it's workable, and may be worth<br>
>> >> >> >> > it for point #2.  (The downside to clamping is that it's not<br>
>> >> >> >> > rotation-invariant--if you reorient the animation, it doesn't<br>
>> >> >> >> > interpolate the same way--but in practice that probably doesn't matter<br>
>> >> >> >> > much.)<br>
>> >> >> >> ><br>
>> >> >> >> > So I think my recommendation is this:<br>
>> >> >> >> ><br>
>> >> >> >> > I _do_ think this should be the new default because the trade-offs<br>
>> >> >> >> > seem better.  However, I'd like to future-proof a bit for further R&D<br>
>> >> >> >> > in this area since this still isn't an "ideal" behavior.<br>
>> >> >> >> > Specifically, having a single checkbox to enable the new behavior<br>
>> >> >> >> > seems short-sighted: if better interpolation approaches show up in the<br>
>> >> >> >> > future, we'll have to add additional checkboxes, and it will turn into<br>
>> >> >> >> > a weird mess of checkboxes that really should be a single enum.  So<br>
>> >> >> >> > before merging, PLEASE change the checkbox to an enum/dropdown.  It<br>
>> >> >> >> > doesn't hurt anything if we don't get anything additional in the<br>
>> >> >> >> > future, but it prevents an awful confusing mess if we do.<br>
>> >> >> >> ><br>
>> >> >> >> > --Nathan<br>
>> >> >> >> ><br>
>> >> >> >> ><br>
>> >> >> >> > On Wed, Aug 9, 2017 at 4:40 AM, Joshua Leung <<a href="mailto:aligorith@gmail.com" target="_blank">aligorith@gmail.com</a>> wrote:<br>
>> >> >> >> >> Hi,<br>
>> >> >> >> >><br>
>> >> >> >> >> I thought most of the discussion for this was already happening in the<br>
>> >> >> >> >> tracker report for this. I'm all in favour of stuff that makes life for<br>
>> >> >> >> >> animators easier - in particular, if it's something that happens a lot (as<br>
>> >> >> >> >> is the case here).<br>
>> >> >> >> >><br>
>> >> >> >> >> Last time I checked, my main concern was regarding backwards compatability.<br>
>> >> >> >> >> Specifically, although it only modifies old curves when handle recalc<br>
>> >> >> >> >> occurs, care is needed as handle recalc doesn't only occur when editing the<br>
>> >> >> >> >> curve - for instance, it can also happen when NLA time remapping occurs<br>
>> >> >> >> >> (e.g. entering/exiting tweakmode on a NLA strip), and probably a few other<br>
>> >> >> >> >> cases too.<br>
>> >> >> >> >><br>
>> >> >> >> >> (EDIT: The per-curve option mentioned on the Graphicall build probably<br>
>> >> >> >> >> resolves the backwards compat/handle-editing problem, though the devil is in<br>
>> >> >> >> >> the details :)<br>
>> >> >> >> >><br>
>> >> >> >> >> On another note, there's another patch floating around that deals with<br>
>> >> >> >> >> similar issues (or rather, only the case where the user is inserting a new<br>
>> >> >> >> >> keyframe).<br>
>> >> >> >> >>     <a href="https://developer.blender.org/D2642" rel="noreferrer" target="_blank">https://developer.blender.<wbr>org/D2642</a><br>
>> >> >> >> >> I'd be curious to hear from animators who've tried D2642 how effective it<br>
>> >> >> >> >> is, and/or whether it'd still be necessary in light of these handle<br>
>> >> >> >> >> calculation changes.<br>
>> >> >> >> >><br>
>> >> >> >> >><br>
>> >> >> >> >> Regards,<br>
>> >> >> >> >> Joshua<br>
>> >> >> >> >><br>
>> >> >> >> >><br>
>> >> >> >> >> On Wed, Aug 9, 2017 at 10:42 PM, Sergey Sharybin <<a href="mailto:sergey.vfx@gmail.com" target="_blank">sergey.vfx@gmail.com</a>><br>
>> >> >> >> >> wrote:<br>
>> >> >> >> >>><br>
>> >> >> >> >>> Hi,<br>
>> >> >> >> >>><br>
>> >> >> >> >>> It is hard to justify how well it'll sustain all possible animation<br>
>> >> >> >> >>> scenarios. Now when we're at BCon1, maybe we can be relaxed and merge the<br>
>> >> >> >> >>> code to master?<br>
>> >> >> >> >>><br>
>> >> >> >> >>> On Wed, Aug 9, 2017 at 11:06 AM, Ton Roosendaal <<a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a>> wrote:<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> Hi all,<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> This proposal went unreplied to, but I think it's important to give<br>
>> >> >> >> >>>> proper attention.<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> Doc and picture is here. It's actually quite obvious.<br>
>> >> >> >> >>>> <a href="http://graphicall.org/1221" rel="noreferrer" target="_blank">http://graphicall.org/1221</a><br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> I coded the old auto handle. It was an invention back then (no other sw<br>
>> >> >> >> >>>> had it), and I simply put the the handle points parallel to the line between<br>
>> >> >> >> >>>> the prev/next control point. Although that creates satisfying circles, it<br>
>> >> >> >> >>>> fails to interpolate well. This patch solves this, without breaking Blender<br>
>> >> >> >> >>>> (only on editing curves the handles re-cacalc).<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> Thanks,<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> -Ton-<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> ------------------------------<wbr>--------------------------<br>
>> >> >> >> >>>> Ton Roosendaal  -  <a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a>   -   <a href="http://www.blender.org" rel="noreferrer" target="_blank">www.blender.org</a><br>
>> >> >> >> >>>> Chairman Blender Foundation, Director Blender Institute<br>
>> >> >> >> >>>> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> On 16 May 2017, at 10:27, Alexander Gavrilov <<a href="mailto:angavrilov@gmail.com" target="_blank">angavrilov@gmail.com</a>><br>
>> >> >> >> >>>> wrote:<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> Hello,<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> It's known that the way auto handles work in blender curves isn't great,<br>
>> >> >> >> >>>> and there<br>
>> >> >> >> >>>> have been complaints that animators are often forced to either manually<br>
>> >> >> >> >>>> adjust all<br>
>> >> >> >> >>>> curve handles, or bypass interpolation by keyframing every frame<br>
>> >> >> >> >>>> manually.<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> Obviously, automatic interpolation can't hope to produce better animation<br>
>> >> >> >> >>>> than<br>
>> >> >> >> >>>> a human, but it should be usable when absolute top quality is not<br>
>> >> >> >> >>>> required.<br>
>> >> >> >> >>>> Thus I have taken a somewhat old patch by Benoit Bolsee that implements a<br>
>> >> >> >> >>>> mathematical approach that produces smooth F-Curves and did some<br>
>> >> >> >> >>>> rewriting<br>
>> >> >> >> >>>> and adding features to get it working solidly.<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> However since I'm not an animator I cannot evaluate myself how well these<br>
>> >> >> >> >>>> new auto-handles would work in practical workflows, and how significant<br>
>> >> >> >> >>>> is<br>
>> >> >> >> >>>> the improvement in the interpolated motion compared to the old way.<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> One possible point of contention might be that producing smooth curves<br>
>> >> >> >> >>>> necessarily<br>
>> >> >> >> >>>> means that modifying keys affects the curve even at some distance from<br>
>> >> >> >> >>>> the affected<br>
>> >> >> >> >>>> key (although the degree of changes drops exponentially with distance,<br>
>> >> >> >> >>>> and propagation<br>
>> >> >> >> >>>> is completely stopped by Auto Clamped extremes or manual handles.)<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> Also the degree this affects existing animations would determine how much<br>
>> >> >> >> >>>> attention<br>
>> >> >> >> >>>> to backward compatibility would be needed if this is adopted in 2.8:<br>
>> >> >> >> >>>> should it e.g.<br>
>> >> >> >> >>>> implement a legacy mode for curves created in previous versions with an<br>
>> >> >> >> >>>> explicit<br>
>> >> >> >> >>>> upgrade operation, or keep the shape until the curve is modified, or just<br>
>> >> >> >> >>>> recalculate<br>
>> >> >> >> >>>> shape etc.<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> I have uploaded a windows build of this branch (based on master for ease<br>
>> >> >> >> >>>> of<br>
>> >> >> >> >>>> testing) to GraphicAll, with more details on the design in the<br>
>> >> >> >> >>>> description:<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> <a href="http://graphicall.org/1221" rel="noreferrer" target="_blank">http://graphicall.org/1221</a><br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> The build there can open master branch files without problems, and the<br>
>> >> >> >> >>>> handles on<br>
>> >> >> >> >>>> curves are only updated when the curve is touched by a modification<br>
>> >> >> >> >>>> operation<br>
>> >> >> >> >>>> (even if it is cancelled like G Esc), which may aid comparing.<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> Alexander<br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> ______________________________<wbr>_________________<br>
>> >> >> >> >>>> Bf-animsys mailing list<br>
>> >> >> >> >>>> <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> >> >> >> >>>> <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>> >> >> >> >>>><br>
>> >> >> >> >>>><br>
>> >> >> >> >>>><br>
>> >> >> >> >>>> ______________________________<wbr>_________________<br>
>> >> >> >> >>>> Bf-animsys mailing list<br>
>> >> >> >> >>>> <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> >> >> >> >>>> <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>> >> >> >> >>>><br>
>> >> >> >> >>><br>
>> >> >> >> >>><br>
>> >> >> >> >>><br>
>> >> >> >> >>> --<br>
>> >> >> >> >>> With best regards, Sergey Sharybin<br>
>> >> >> >> >>><br>
>> >> >> >> >>> ______________________________<wbr>_________________<br>
>> >> >> >> >>> Bf-animsys mailing list<br>
>> >> >> >> >>> <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> >> >> >> >>> <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>> >> >> >> >>><br>
>> >> >> >> >><br>
>> >> >> >> >><br>
>> >> >> >> >> ______________________________<wbr>_________________<br>
>> >> >> >> >> Bf-animsys mailing list<br>
>> >> >> >> >> <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> >> >> >> >> <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>> >> >> >> >><br>
>> >> >> >> ______________________________<wbr>_________________<br>
>> >> >> >> Bf-animsys mailing list<br>
>> >> >> >> <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> >> >> >> <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>> >> >> >><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> > ______________________________<wbr>_________________<br>
>> >> >> > Bf-animsys mailing list<br>
>> >> >> > <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> >> >> > <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>> >> >> ______________________________<wbr>_________________<br>
>> >> >> Bf-animsys mailing list<br>
>> >> >> <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> >> >> <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>> >> >><br>
>> >> ><br>
>> >> ><br>
>> >> > ______________________________<wbr>_________________<br>
>> >> > Bf-animsys mailing list<br>
>> >> > <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> >> > <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>> >> ______________________________<wbr>_________________<br>
>> >> Bf-animsys mailing list<br>
>> >> <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> >> <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>> >><br>
>> ><br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > Bf-animsys mailing list<br>
>> > <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> > <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>> ______________________________<wbr>_________________<br>
>> Bf-animsys mailing list<br>
>> <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
>> <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
>><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Bf-animsys mailing list<br>
> <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
> <a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
______________________________<wbr>_________________<br>
Bf-animsys mailing list<br>
<a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-animsys</a><br>
</div></div></blockquote></div><br></div></div></div></div></div></div></div>
</blockquote></div><br></div></div>