Graph Editor : limitation of Bézier Handles #75881

Closed
opened 2020-04-18 22:55:10 +02:00 by TonyG · 29 comments

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

Blender Version
Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-03-12 05:06, hash: 375c7dc4ca
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.
{F8482261, size=full}
{F8482322, size=full}

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 :
good.gif

Bezier_limitation.blend

**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.10.10.10.40.105 **Blender Version** Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-03-12 05:06, hash: `375c7dc4ca` 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. {[F8482261](https://archive.blender.org/developer/F8482261/b.gif), size=full} {[F8482322](https://archive.blender.org/developer/F8482322/bugggg.gif), size=full} **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 : ![good.gif](https://archive.blender.org/developer/F8482358/good.gif) [Bezier_limitation.blend](https://archive.blender.org/developer/F8482344/Bezier_limitation.blend)
Author

Added subscriber: @antoine.grasset

Added subscriber: @antoine.grasset
Member

Added subscriber: @ankitm

Added subscriber: @ankitm

Added subscriber: @iss

Added subscriber: @iss

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'

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.

Added subscriber: @StanislavOvcharov

Added subscriber: @StanislavOvcharov
Author

In #75881#914226, @iss wrote:
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.

> In #75881#914226, @iss wrote: > 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.

Added subscriber: @dr.sybren

Added subscriber: @dr.sybren

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.

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.

Added subscriber: @LucianoMunoz

Added subscriber: @LucianoMunoz

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.

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

@dr.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 ?

@dr.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 ?

Added subscriber: @CobraA

Added subscriber: @CobraA

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

In #75881#922053, @CobraA wrote:
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 : https://blender.community/c/rightclickselect/0Ccbbc/
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.

> In #75881#922053, @CobraA wrote: > 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 : https://blender.community/c/rightclickselect/0Ccbbc/ 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.

Added subscriber: @Oskar3d

Added subscriber: @Oskar3d
Author

Removed subscriber: @antoine.grasset

Removed subscriber: @antoine.grasset
Author

Added subscriber: @antoine.grasset

Added subscriber: @antoine.grasset

Added subscriber: @dinhdong

Added subscriber: @dinhdong

Added subscriber: @bent

Added subscriber: @bent

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 :

"
Image
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 :
Image

After reading about the F-curve through this [link](https://blender.stackexchange.com/questions/52403/what-is-the-mathematical-basis-for-f-curves/52468#52468). It seems I have understood the reason. Here are the relevant key excerpts from the link above : " ![Image](https://i.stack.imgur.com/WaRv8.png) 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 : ![Image](https://media.giphy.com/media/52FJOdN8UMsGalgsVn/giphy.gif)
Author

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 Capture d’écran 2020-08-30 à 03.35.54.png

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.
@dr.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 ?

Thanks a lot Dinh Dong ! The [post you linked ](https://blender.stackexchange.com/questions/52403/what-is-the-mathematical-basis-for-f-curves/52468#52468) explains it really well indeed. F-curves are beziers that must not loop or rewind against the flow of time = [example of forbidden curve ](https://www.desmos.com/calculator/gguei4qn26). To avoid this, f-curves are processed at eval-time by the function "*correct_bezpart()*" called in [fcurve.c (line 1630) ](https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/fcurve.c$1630-1631). By checking [the corresponding code ](https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/fcurve.c$1340-1351) you can see that it was assumed that to prevent the beziers from looping they had to be limited when : `len1 + len2 > len` ![Capture d’écran 2020-08-30 à 03.35.54.png](https://archive.blender.org/developer/F8820355/Capture_d_e_cran_2020-08-30_a__03.35.54.png) 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 ](https://www.desmos.com/calculator/lkjfmfgxao) is the current limited behaviour [here ](https://www.desmos.com/calculator/cpmmvmszc8) 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](https://archive.blender.org/developer/D8752) The caveat is that existing animation can now render differently because the handles have more range. @dr.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 ?
Member

Added subscriber: @wbmoss_dev

Added subscriber: @wbmoss_dev

This issue was referenced by da95d1d851

This issue was referenced by da95d1d851b41e3599310d88e6d03fe23cee455e

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Sybren A. Stüvel self-assigned this 2020-09-15 13:14:39 +02:00

For the release notes: #75881-fcurve-limits-demo.mp4

For the release notes: [#75881-fcurve-limits-demo.mp4](https://archive.blender.org/developer/F8882872/T75881-fcurve-limits-demo.mp4)

This issue was referenced by None@62484

This issue was referenced by None@62484

Added subscriber: @Saiman

Added subscriber: @Saiman

Hi. Could you add the possibility to change the curve as shown in the video? In Maya, the curve can be changed more flexibly. It can be almost the vertical on all animation's length between two frames.
Comp 1_1.mp4

Hi. Could you add the possibility to change the curve as shown in the video? In Maya, the curve can be changed more flexibly. It can be almost the vertical on all animation's length between two frames. [Comp 1_1.mp4](https://archive.blender.org/developer/F8906308/Comp_1_1.mp4)
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
13 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#75881
No description provided.