Page MenuHome

Graph Editor : limitation of Bézier Handles
Closed, ResolvedPublicKNOWN ISSUE

Authored By
TonyG (TonyG)
Apr 18 2020, 10:55 PM
"Love" token, awarded by gilberto_rodrigues."Love" token, awarded by blackviking."Love" token, awarded by ogierm."Love" token, awarded by Kickflipkid687."Love" token, awarded by dinhdong."Love" token, awarded by TonyG."Love" token, awarded by Kronk.


System Information
Operating system: Darwin-17.7.0-x86_64-i386-64bit 64 Bits
Graphics card: NVIDIA GeForce GTX 980 Ti OpenGL Engine NVIDIA Corporation 4.1 NVIDIA-10.33.0 387.

Blender Version
Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-03-12 05:06, hash: rB375c7dc4caf4
Also broken in previous version and also 2.90 alpha
Worked: Never (2.79+)

Short description of error
In the Graph Editor the bézier handles are meant to be pulled to shape the f-curve.
Currently it seems these handles have a threshold/limitation that prevent strong manipulation.
This is a real shortcoming for animation work.

Exact steps for others to reproduce the error
Open attached .blend file.
Playback and observe the motion difference (here the desired motion is accomplished by adding more keyframes).
Scaling the handles can never accomplish the desired curve.
It should be possible like this :

Event Timeline

Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Apr 20 2020, 5:09 PM

I can't seem to get this desired curve shape even in 2.79 version, but I can't believe nobody reported this yet.

I can't seem to get this desired curve shape even in 2.79 version, but I can't believe nobody reported this yet.

To my knowledge it was never doable, I just tested as far as Blender 2.57 to check.
It's been reported on several discussions forums but never here.

Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Known Issue".Apr 21 2020, 12:30 PM

I wouldn't classify this as a bug, rather as a known limitation. And yes, it's quite a big limitation.
Fixing this would require great care in the versioning code, in order to ensure that existing animations aren't changed. I think with some clever math, this is quite doable, though.

It would be great to have this fixed, because it means that less keyframes are necessary to achieve particular moves, and the less keyframes we need to make the less time takes to animate, polish etc.

@Sybren A. Stüvel (sybren) Thank you for acknowledging the limitation !
Do you know how likely an unassigned known issue is to be processed ? (I'm quite new here)
I'm willing to have a look (though relatively new to Python), can you advise were to look to modify the curves' behaviour ?

It's a feature request on RCS, the workaround that people suggested to me is to add another keyframe in each middle.

It's a feature request on RCS, the workaround that people suggested to me is to add another keyframe in each middle.

Absolutely, I commented on it on RCS to revive the thread after a year of inactivity :
And you're right : adding a keyframe in the middle is the only way to achieve the result and being able to fine-tune it.
I'm hoping this can be improved, I think it can make animating a lot more fluid and elegant.

After reading about the F-curve through this link. It seems I have understood the reason. Here are the relevant key excerpts from the link above :

They're normal Bézier curves with certain restrictions placed on the positions of the handles...
This guarantees that the curve will not turn back on itself.
On line 1830, the correct_bezpart() function begins. The function finds the width of each handle and the width between the two keyframes. If the combined width of the two handles is greater than the width between the two keyframes, then the two handles are scaled down so that they don't cross each other, but their relative lengths are preserved. The original handles are used for drawing to the graph editor, but the scaled-down versions are used for generating the curve, a plain-old cubic Bézier curve."

I think this restriction needs to be corrected. In adobe AE, two handles can move freely, as long as their time value (x value) is not less than the value of the first keyframe and not greater than the value of the second keyframe :

Thanks a lot Dinh Dong ! The post you linked explains it really well indeed.
F-curves are beziers that must not loop or rewind against the flow of time = example of forbidden curve.
To avoid this, f-curves are processed at eval-time by the function "correct_bezpart()" called in fcurve.c (line 1630).

By checking the corresponding code you can see that it was assumed that to prevent the beziers from looping they had to be limited when :
len1 + len2 > len

This assomption turns out to be wrong and unnecessarily limits the handles. Instead they should be constrained as follow :
0 < len1 < len and 0 < len2 < len

Try it for yourself
here is the current limited behaviour
here is the corrected proposal (note that the curve cannot loop/rewind)

I created a patch that corrects the bezier behaviour and makes animating a lot easier : D8752: Graph Editor : Fix for f-curves limitation
The caveat is that existing animation can now render differently because the handles have more range.
@Sybren A. Stüvel (sybren) Do you recommend detecting if blend files were created in previous versions ? or some kind of updating trick to rebake the handles with their previously limited value ?

For the release notes: