can't change aligned handle length when pared with free/ vector curve handle #40186

New Issue

bassam kurdali · 2014-05-14T01:04:51+02:00

bassam kurdali commented

2014-05-14 01:04:51 +02:00

System Information
gnu linux 64 bit/fedora 20/intel cpu/nvidia gpu

Blender Version
Broken: d1cf350
Worked: 2.70a

Short description of error
If you have a keyframe with a vector/free handle on one side and aligned on one side in the graph editor you can no longer change the length of the aligned handle.
Example of this is having a linear section of the curve with a ramp into it. editing the aligned lenght alows adjusting the amout of ease into the linear section
Exact steps for others to reproduce the error
Open the attached file bug.blend
try to change the length of the selected handle (doesn't work)
used to work in 2.70a

Edit: this bug is caused by fix for #38594

**System Information** gnu linux 64 bit/fedora 20/intel cpu/nvidia gpu **Blender Version** Broken: d1cf350 Worked: 2.70a **Short description of error** If you have a keyframe with a vector/free handle on one side and aligned on one side in the graph editor you can no longer change the length of the aligned handle. Example of this is having a linear section of the curve with a ramp into it. editing the aligned lenght alows adjusting the amout of ease into the linear section **Exact steps for others to reproduce the error** Open the attached file [bug.blend](https://archive.blender.org/developer/F88886/bug.blend) try to change the length of the selected handle (doesn't work) used to work in 2.70a *Edit: this bug is caused by fix for #38594*

bassam kurdali commented

2014-05-14 01:04:51 +02:00

Changed status to: 'Open'

bassam kurdali commented

2014-05-14 01:04:51 +02:00

Added subscriber: @BassamKurdali

Bastien Montagne commented

2014-05-15 12:44:25 +02:00

Added subscriber: @mont29

Ignatz commented

2014-05-15 15:22:17 +02:00

Added subscriber: @ignatz

Ignatz commented

2014-05-15 15:22:17 +02:00

I can confirm this behavior. The tension arm on the left side of the anchor is completely locked.

This may have something to do with some requested changes that were recently made to the curve tension arm editing.

Those changes were not completely finished and still have (other) bugs.

Those other problems are listed in report #39982 (not yet fixed).

But this problem is new to me and is not listed in that report.

I can confirm this behavior. The tension arm on the left side of the anchor is completely locked. This may have something to do with some requested changes that were recently made to the curve tension arm editing. Those changes were not completely finished and still have (other) bugs. Those other problems are listed in report **#39982** (*not yet fixed*). But this problem is new to me and is not listed in that report.

Joshua Leung was assigned by Sergey Sharybin

2014-05-15 15:29:04 +02:00

Sergey Sharybin commented

2014-05-15 15:29:04 +02:00

Added subscribers: @JoshuaLeung, @Sergey

Sergey Sharybin commented

2014-05-15 15:29:04 +02:00

@JoshuaLeung, think this is because of your fix which was intended to improve behavior of editing aligned handles.

Campbell Barton commented

2014-05-16 03:33:14 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2014-05-16 03:33:14 +02:00

Note, this also gives very odd results just dragging the entire keyframe to the bottom right (but dragging around from side to side is odd whatever you do)

Compare before -> after (bottom).

The keyframe IMHO shouldn't change handle length at all when aligned and dragging the entire keyframe

Note, this also gives very odd results just dragging the entire keyframe to the bottom right (but dragging around from side to side is odd whatever you do) Compare before -> after (bottom). ![bug.png](https://archive.blender.org/developer/F89154/bug.png) The keyframe IMHO shouldn't change handle length at all when aligned and dragging the entire keyframe

Campbell Barton commented

2014-05-16 03:36:35 +02:00

Attached 2 possible fixes.

This treats fcurves differently since vertical distance isnt equivalent to horizontal with fcurves.
test_1.diff

This basically reverts the change to how it was in last release.
test_2.diff

Attached 2 possible fixes. This treats fcurves differently since vertical distance isnt equivalent to horizontal with fcurves. [test_1.diff](https://archive.blender.org/developer/F89156/test_1.diff) This basically reverts the change to how it was in last release. [test_2.diff](https://archive.blender.org/developer/F89157/test_2.diff)

Joshua Leung commented

2014-05-16 03:46:21 +02:00

At this stage, I'm leaning towards simply reverting any/all fixes made since the last release regarding how aligned handles are handled, and simply defining it all as "won't fix" territory.

Of course it sucks that one of the handles always seems to wildly overshoot when using aligned handles. But, I've personally just always viewed this as just one of the quirks that come with such a feature; it happens, but if it really becomes a problem when doing fine tuning, we can still just set the offending handle to "free" and manually tweak it into submission.

At this stage, I'm leaning towards simply reverting any/all fixes made since the last release regarding how aligned handles are handled, and simply defining it all as "won't fix" territory. Of course it sucks that one of the handles always seems to wildly overshoot when using aligned handles. But, I've personally just always viewed this as just one of the quirks that come with such a feature; it happens, but if it really becomes a problem when doing fine tuning, we can still just set the offending handle to "free" and manually tweak it into submission.

Ignatz commented

2014-05-16 04:38:36 +02:00

@JoshuaLeung

Is this really so hard to fix? :(

I notice the following about this 'locked' condition.

Changing the handle type of the surrounding anchor points (A, C) seems to have no effect on the condition.

On the other hand, if you switch the handle type of anchor point B from Aligned to Free and then back to Aligned you will find that the curve is unchanged but both handles are now free to move again. After that, both handles remain editable.

It makes me wonder just how the handle got 'locked up' in the first place.

@JoshuaLeung Is this really so hard to fix? :( I notice the following about this 'locked' condition. Changing the handle type of the surrounding anchor points (A, C) seems to have no effect on the condition. On the other hand, if you switch the handle type of anchor point B from Aligned to Free and then back to Aligned you will find that the curve is unchanged but both handles are now free to move again. After that, both handles remain editable. It makes me wonder just how the handle got 'locked up' in the first place.

Ignatz commented

2014-05-16 04:39:26 +02:00

Forgot to post the image.

Forgot to post the image. ![free-aligned.png](https://archive.blender.org/developer/F89158/free-aligned.png)

Campbell Barton commented

2014-05-16 06:55:36 +02:00

Checked on old/new behavior.

My patch: test_1.diff reverts behavior to what it was in 2.68.

While the old behavior does give some issues with overshoot (see: #38594), generally I much prefer it to what we have now.

We could resolve the issue by passing in an aspect value to calchandleNurb_intern, this way #38594 can fixed by making fcurves behave like regular 3D curves, but passing in values from graph editor to calchandleNurb_intern seems like it could be error prone too :S.

Checked on old/new behavior. My patch: [test_1.diff](https://archive.blender.org/developer/F89156/test_1.diff) reverts behavior to what it was in 2.68. While the old behavior does give some issues with overshoot (see: #38594), generally I much prefer it to what we have now. We could resolve the issue by passing in an aspect value to `calchandleNurb_intern`, this way #38594 can fixed by making fcurves behave like regular 3D curves, but passing in values from graph editor to `calchandleNurb_intern` seems like it could be error prone too :S.

Ignatz commented

2014-05-16 20:02:26 +02:00

@Campbell,

I have a suggestion that might help.

Before explaining, I would like to say that I really appreciate the time you guys have put in to try to correct what I see as doubtful behaviour in the curve editor. Of course, this isn't as easy as writing code from scratch. You are trying to patch certain behaviour, but have to respect what is already there. It is a thankless task at times.

I see that you guys are ready to go back to the previous code. And I know you guys have your hands full with other more pressing bugs and performance issues. And anyway, I cannot comment on anything that has happened since I'm no math whiz and the little amount of programming I've done wouldn't impress anyone.

But here is the idea.

What if when editing a single handle of an aligned pair you do as follows:

A) Select a single handle for editing (on either side of the anchor).

B) If 'G' is pressed to move that handle then the length of the handle on the opposite side is temporarily stored.

C) The selected handle is now moved to a new location.

D) As soon as the move is finished and the mouse button released the following automatically happens...

E) The handle on the opposite is subjected to a scaling operation (using that stored value) so as to pull its length back to what the user would have expected. This scaling operation would have to respect both the new arm angle as well as the scaling of the graph in both X and Y so as to give the impression that handle has maintained its original length (or even just something close to its original length)

Note: I would again point out that arbitrarilly locking the X position of the opposite control arm to its original X position is probably not a good idea.

I admit that this suggested solution is a bit 'Micky Mouse' as an approach. This would definitely give something of a surprise 'jump-to-position' effect at times, especially when the overshoot of the opposite arm was rather severe. On the other hand, it would probably save a lot of fussing since most of that wild overshoot effect is seldom wanted (in my opinion). And if that amount of overshoot really WAS wanted, then it is still a simple matter for the user to select that opposite arm and pull it up into some extreme position. But as it stands now, I think that most of the animators are forced to do a second select and move of that control arm anyway in order to compensate for the crazy overshoot, so this approach might ultimately be a time saver.

@Campbell, I have a suggestion that might help. Before explaining, I would like to say that I really appreciate the time you guys have put in to try to correct what I see as doubtful behaviour in the curve editor. Of course, this isn't as easy as writing code from scratch. You are trying to patch certain behaviour, but have to respect what is already there. It is a thankless task at times. I see that you guys are ready to go back to the previous code. And I know you guys have your hands full with other more pressing bugs and performance issues. And anyway, I cannot comment on anything that has happened since I'm no math whiz and the little amount of programming I've done wouldn't impress anyone. But here is the idea. What if when editing a single handle of an aligned pair you do as follows: A) Select a single handle for editing (on either side of the anchor). B) If 'G' is pressed to move that handle then the length of the handle on the opposite side is temporarily stored. C) The selected handle is now moved to a new location. D) As soon as the move is finished and the mouse button released the following automatically happens... E) The handle on the opposite is subjected to a scaling operation (using that stored value) so as to pull its length back to what the user would have expected. This scaling operation would have to respect both the new arm angle as well as the scaling of the graph in both X and Y so as to give the impression that handle has maintained its original length (or even just something close to its original length) Note: I would again point out that arbitrarilly locking the X position of the opposite control arm to its original X position is probably not a good idea. I admit that this suggested solution is a bit *'Micky Mouse'* as an approach. This would definitely give something of a surprise 'jump-to-position' effect at times, especially when the overshoot of the opposite arm was rather severe. On the other hand, it would probably save a lot of fussing since most of that wild overshoot effect is seldom wanted (in my opinion). And if that amount of overshoot really WAS wanted, then it is still a simple matter for the user to select that opposite arm and pull it up into some extreme position. But as it stands now, I think that most of the animators are forced to do a second select and move of that control arm anyway in order to compensate for the crazy overshoot, so this approach might ultimately be a time saver.

Campbell Barton commented

2014-05-27 13:32:42 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2014-05-27 13:32:42 +02:00

Campbell Barton commented

2014-05-27 13:32:42 +02:00

reverted 0985bb483d. closing.

reverted 0985bb483d. closing.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

can't change aligned handle length when pared with free/ vector curve handle #40186