After canceling, F-Curve handlers don't go back to original position. #40548

New Issue

Mario Mey · 2014-06-09T14:08:33+02:00

Mario Mey commented

2014-06-09 14:08:33 +02:00

Reported in https://developer.blender.org/T40529, but this bug is not related with that bug.

Open the same file.
Select any F-Curve vertex.
Unselect its handlers.
Move the vertex trough X.

What it does? The handlers are moved trough X beside the vertex to avoid multi-Y-values... If you right click to cancel the new location, the handlers don't go back, they stay in the new location.

This bug is in stable version.

Reported in https://developer.blender.org/T40529, but this bug is not related with that bug. Open the same file. Select any F-Curve vertex. Unselect its handlers. Move the vertex trough X. What it does? The handlers are moved trough X beside the vertex to avoid multi-Y-values... If you right click to cancel the new location, the handlers don't go back, they stay in the new location. This bug is in stable version.

Mario Mey commented

2014-06-09 14:08:33 +02:00

Changed status to: 'Open'

Mario Mey commented

2014-06-09 14:08:33 +02:00

Added subscriber: @MarioSottile

Mario Mey commented

2014-06-09 14:09:39 +02:00

50-F-Curve-handlers-canceled-dont-go-back.blend

[50-F-Curve-handlers-canceled-dont-go-back.blend](https://archive.blender.org/developer/F93663/50-F-Curve-handlers-canceled-dont-go-back.blend)

Bastien Montagne commented

2014-06-09 15:37:50 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2014-06-09 15:38:18 +02:00

Added subscribers: @Sergey, @ideasman42

Lukas Tönne commented

2014-07-04 17:47:39 +02:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2014-07-04 17:47:39 +02:00

I think we had a similar issue in another area (mesh modelling), but can't recall where exactly ... Essentially this happens because the transform operator affects data that is not itself marked for transform (the deselected handles in this case). Data that is included in the transform will get reset to the original state on cancel, but unselected data does not store the original location.

Solution could be to always include the origin data for the handles, anticipating the transform constraint effect, without actually transforming them.

I think we had a similar issue in another area (mesh modelling), but can't recall where exactly ... Essentially this happens because the transform operator affects data that is not itself marked for transform (the deselected handles in this case). Data that is included in the transform will get reset to the original state on cancel, but unselected data does not store the original location. Solution could be to always include the origin data for the handles, anticipating the transform constraint effect, without actually transforming them.

Sergey Sharybin commented

2014-07-04 17:49:42 +02:00

@LukasTonne, this is a right solution i think.

Lukas Tönne self-assigned this 2014-07-04 17:51:15 +02:00

Lukas Tönne commented

2014-07-05 09:10:28 +02:00

Added subscriber: @JoshuaLeung

Lukas Tönne commented

2014-07-05 09:19:51 +02:00

There seems to be a lot of complexity in the transform operator for fcurve vertices, resulting from the distinction of modes and the potential description of handle transform in the same TransData instance as their master vertex (TD_MOVEHANDLE1/2 flags).

https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/transform/transform_conversions.c;5aec61f8493f5876a52ec67871148803396ff223$3826

It seems to me that all these different cases are not really necessary: the handle transforms are already stored in separate TransData in some cases (non-translate mode and/or master vertex not selected) - so why not simply do this every time and get rid of all these complicated distinctions? Is there something i'm missing?

(Amount of data can hardly be an argument, you'd have to move thousands to millions of handles for the difference to show, and then all kinds of other issues would probably kick in ...)

There seems to be a lot of complexity in the transform operator for fcurve vertices, resulting from the distinction of modes and the potential description of handle transform in the same `TransData` instance as their master vertex (TD_MOVEHANDLE1/2 flags). https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/transform/transform_conversions.c;5aec61f8493f5876a52ec67871148803396ff223$3826 It seems to me that all these different cases are not really necessary: the handle transforms are already stored in separate `TransData` in some cases (non-translate mode and/or master vertex not selected) - so why not simply do this every time and get rid of all these complicated distinctions? Is there something i'm missing? (Amount of data can hardly be an argument, you'd have to move thousands to millions of handles for the difference to show, and then all kinds of other issues would probably kick in ...)

blender-admin commented

2014-07-06 13:10:22 +02:00

This issue was referenced by 22fa83173b

This issue was referenced by 22fa83173b326ef1344ceec6623a5562d8b851f1

Lukas Tönne commented

2014-07-06 13:10:58 +02:00

Changed status from 'Open' to: 'Resolved'

Lukas Tönne closed this issue

2014-07-06 13:10:58 +02:00

Lukas Tönne commented

2014-07-06 13:10:58 +02:00

Closed by commit 22fa83173b.