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

[Sergey Sharybin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20170809/9a29f0d2/attachment.html>