Regression: Bezier curves fail to respect keyframed handle positions #98965

New Issue

Daniel Salazar · 2022-06-18T04:29:15+02:00

Daniel Salazar commented

2022-06-18 04:29:15 +02:00

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1080 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.96

Blender Version
Broken: version: 3.0 and newer
Worked: version: 2.93 and older

Exposed by 7aa39b40f4

Short description of error
Since Bezier handle points can be keyframed (IE: using AnimAll), the curve needs to respect the position of the handles regardless of the handle type.

See below in 2.93 how the curve follows the keyframed handle position, even if the handle type is set to auto.

See below in 3.3 how the curve is not following the keyframed handle position, resulting in an incorrect curvature.

Exact steps for others to reproduce the error
Handle Bug.blend

Open in Blender >3.0 versus <2.93

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1080 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.96 **Blender Version** Broken: version: 3.0 and newer Worked: version: 2.93 and older Exposed by 7aa39b40f4 **Short description of error** Since Bezier handle points can be keyframed (IE: using AnimAll), the curve needs to respect the position of the handles regardless of the handle type. See below in 2.93 how the curve follows the keyframed handle position, even if the handle type is set to auto. ![image.png](https://archive.blender.org/developer/F13181396/image.png) See below in 3.3 how the curve is **not** following the keyframed handle position, resulting in an incorrect curvature. ![image.png](https://archive.blender.org/developer/F13181405/image.png) **Exact steps for others to reproduce the error** [Handle Bug.blend](https://archive.blender.org/developer/F13181414/Handle_Bug.blend) Open in Blender >3.0 versus <2.93

Daniel Salazar commented

2022-06-18 04:29:15 +02:00

Added subscriber: @zanqdo

Daniel Salazar changed title from ~~Bezier curves fail to respect keyframed handle positions~~ to Bezier curves fail to respect keyframed handle positions (Regression)

2022-06-18 04:35:37 +02:00

Daniel Salazar changed title from ~~Bezier curves fail to respect keyframed handle positions (Regression)~~ to Regression: Bezier curves fail to respect keyframed handle positions

2022-06-18 04:35:57 +02:00

Omar Emara commented

2022-06-20 14:46:22 +02:00

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

Philipp Oeser commented

2022-06-20 17:51:21 +02:00

Added subscribers: @Baardaap, @HooglyBoogly, @lichtwerk

Philipp Oeser commented

2022-06-20 17:51:21 +02:00

Exposed by 7aa39b40f4

CC @HooglyBoogly
CC @Baardaap

Exposed by 7aa39b40f4 CC @HooglyBoogly CC @Baardaap

Hans Goudey commented

2022-06-24 01:19:14 +02:00

Looking into this a bit further, the situation is a bit unfortunate. I think I would call the current behavior correct actually.

What's happening is that the handle types are "AUTO" which means that they are automatically calculated based on the neighboring control points.
If I set the handle types to "FREE" this works fine, because they can be moved wherever we want.

{F13222147 size=full}

It's tempting to say that "animation shouldn't respect the handle types", but I don't think that's a good idea. The types are generally expected to stay valid (or rather, the positions are expected to stay valid with the types).
This is especially important because other procedural operations that happen after animation is evaluated will expect the positions and the types to agree.

So, while this is a change in behavior, I think the current behavior is more correct, and I don't think this should be changed back.
Of course in retrospect I would have liked to communicate this change better and maybe do it at a different time, but I didn't foresee it.

Looking into this a bit further, the situation is a bit unfortunate. I think I would call the current behavior correct actually. What's happening is that the handle types are "AUTO" which means that they are automatically calculated based on the neighboring control points. If I set the handle types to "FREE" this works fine, because they can be moved wherever we want. {[F13222147](https://archive.blender.org/developer/F13222147/image.png) size=full} It's tempting to say that "animation shouldn't respect the handle types", but I don't think that's a good idea. The types are generally expected to stay valid (or rather, the positions are expected to stay valid with the types). This is especially important because other procedural operations that happen *after* animation is evaluated will expect the positions and the types to agree. So, while this is a change in behavior, I think the current behavior is more correct, and I don't think this should be changed back. Of course in retrospect I would have liked to communicate this change better and maybe do it at a different time, but I didn't foresee it.

Daniel Salazar commented

2022-06-24 01:32:17 +02:00

@HooglyBoogly The handle types are more of an user input tool. Once the curve is baked with keyframing or other types of procedural control, the curve needs to follow the actual baked in handle positions.

With the original behavior I can switch between handle types to animate in which ever fits the current situation the best without worrying about past shapes which are already keyframed. It's never alright to overwrite poses or keyframes.

@HooglyBoogly The handle types are more of an user input tool. Once the curve is baked with keyframing or other types of procedural control, the curve needs to follow the actual baked in handle positions. With the original behavior I can switch between handle types to animate in which ever fits the current situation the best without worrying about past shapes which are already keyframed. It's never alright to overwrite poses or keyframes.

Hans Goudey commented

2022-06-24 01:35:57 +02:00

That's what I was referring to with the paragraph starting with "It's tempting to say that 'animation shouldn't respect the handle types'..."

switch between handle types to animate in which ever fits the current situation the best

I don't really understand this, could you clarify?

That's what I was referring to with the paragraph starting with "It's tempting to say that 'animation shouldn't respect the handle types'..." >switch between handle types to animate in which ever fits the current situation the best I don't really understand this, could you clarify?

Daniel Salazar commented

2022-06-24 01:47:23 +02:00

@HooglyBoogly

Here is a video in 2.93 (how it used to be). Changing handle types as you go along.
My take on this is once you keyframe, you expect the keyframed shape to be set in stone, completely baked, that's why you're keyframing it with the handles included.

AnimAllCurves.mp4

Now after 3.0 this woudn't work since the handle types set at the very last would affect the rest of the animation that was already keyframed.

@HooglyBoogly Here is a video in 2.93 (how it used to be). Changing handle types as you go along. My take on this is once you keyframe, you expect the keyframed shape to be set in stone, completely baked, that's why you're keyframing it with the handles included. [AnimAllCurves.mp4](https://archive.blender.org/developer/F13222183/AnimAllCurves.mp4) Now after 3.0 this woudn't work since the handle types set at the very last would affect the rest of the animation that was already keyframed.

Hans Goudey commented

2022-06-24 02:24:15 +02:00

@zanqdo pointed out to me in chat that there is disagreement between what the handles show visually and what the final curve is doing. So there is probably something wrong here actually.
I still think the final result is correct/valid, but the different visualizations should at least agree with each other.
My current guess for why that happens is that the handles are drawn with the data from the old (legacy) curve type, but the wire line is drawn with the evaluated result of the new curve type.

I'm not sure I have a good idea here. I do find it weird that the animation system can create invalid states in the curve handles.
I would like to be able to assume that handle types are valid-- I think that's a reasonable thing for everywhere else in the curve code to expect.
I wonder if it's possible for the animation to set the types to "free" as necessary?

@zanqdo pointed out to me in chat that there is disagreement between what the handles show visually and what the final curve is doing. So there is probably something wrong here actually. I still think the final result is correct/valid, but the different visualizations should at least agree with each other. My current guess for why that happens is that the handles are drawn with the data from the old (legacy) curve type, but the wire line is drawn with the evaluated result of the new curve type. I'm not sure I have a good idea here. I do find it weird that the animation system can create invalid states in the curve handles. I would like to be able to assume that handle types are valid-- I think that's a reasonable thing for everywhere else in the curve code to expect. I wonder if it's possible for the animation to set the types to "free" as necessary?

Martijn Versteegh commented

2022-06-24 08:55:57 +02:00

I'm a bit confused. I'm trying to experiment with this, but can't find a way to keyframe curve handles in the default gui. If I turn on the animall add-on in 3.2 I get extra buttons in that window which allow to also keyframe the handle type. Wouldn't keyframing the handle type solve this problem?

As I understand it the problem is that changing the handle type in previous versions only affected new keyframes while old keyframes kept using the previous handle type? Or rather ignore the handletype and just use the control points as keyed, probably.

In any case, the previous behavior was more of side effect of a bug. Though I understand it might be more comfortable when working.

I'm not really sure how this should be solved. Emulating the previous behaviour would mean treating all handles as 'free' during keyframe animation. But that would lead to weird jumps if you change the position of a previously keyframed handle where the controlpoints suddenly jump to their 'auto' positions as soon as you drag the handle. (This probably is the way it happened < 3.0? )
I'm not really a fan of handle types silently automagically being set to 'free' either. That would make the behaviour consistent, but I think it would be surprising as well...

I'm a bit confused. I'm trying to experiment with this, but can't find a way to keyframe curve handles in the default gui. If I turn on the animall add-on in 3.2 I get extra buttons in that window which allow to also keyframe the handle type. Wouldn't keyframing the handle type solve this problem? As I understand it the problem is that changing the handle type in previous versions only affected new keyframes while old keyframes kept using the previous handle type? Or rather ignore the handletype and just use the control points as keyed, probably. In any case, the previous behavior was more of side effect of a bug. Though I understand it might be more comfortable when working. I'm not really sure how this should be solved. Emulating the previous behaviour would mean treating all handles as 'free' during keyframe animation. But that would lead to weird jumps if you change the position of a previously keyframed handle where the controlpoints suddenly jump to their 'auto' positions as soon as you drag the handle. (This probably is the way it happened < 3.0? ) I'm not really a fan of handle types silently automagically being set to 'free' either. That would make the behaviour consistent, but I think it would be surprising as well...

Daniel Salazar commented

2022-06-24 09:05:41 +02:00

@Baardaap The option to keyframe handle types has been removed from AnimAll in Master since it is NOT a solution. It will create jumps when handles change type and we want a smooth interpolation in the curve in both control points and handle positions.

We have to make a choice, either keyframes rule as before 7aa39b40f4
or Handle types rule, in which case auto, aligned and vector handles must ignore keyframed values?

Right now we are in a weird middle which is super confusing since the handles always respect their keyframed values but the actual curve doesn't

@Baardaap The option to keyframe handle types has been removed from AnimAll in Master since it is NOT a solution. It will create jumps when handles change type and we want a smooth interpolation in the curve in both control points and handle positions. We have to make a choice, either keyframes rule as before 7aa39b40f4 or Handle types rule, in which case auto, aligned and vector handles must ignore keyframed values? Right now we are in a weird middle which is super confusing since the handles always respect their keyframed values but the actual curve doesn't ![image.png](https://archive.blender.org/developer/F13181405/image.png)

Martijn Versteegh commented

2022-06-24 10:57:12 +02:00

Right now we are in a weird middle which is super confusing since the handles always respect their keyframed values but the actual curve doesn't

Yeah, that's weird. I agree.

As an aside: I still don't completely understand how 7aa39b40f4 causes this, since it just makes it so that 'ensure_auto_handles' doesn't get written if the handle positions are overwritten right after that anyway.
I'd expect this change to only have an effect for reading curves from dna...

> Right now we are in a weird middle which is super confusing since the handles always respect their keyframed values but the actual curve doesn't Yeah, that's weird. I agree. As an aside: I still don't completely understand how 7aa39b40f4 causes this, since it just makes it so that 'ensure_auto_handles' doesn't get written if the handle positions are overwritten right after that anyway. I'd expect this change to only have an effect for reading curves from dna...

Hans Goudey commented

2022-06-24 22:27:38 +02:00

After thinking more about this, I don't see a great way to support animation without causing the invalid state, at least without forcing the step of always animating the handle types as well.

I added a patch that returns the behavior to before here: D15290

We have to understand that this really is an invalid state of the curves though. If you do further procedural deformation of the curves and don't correct it by setting the curve types to "Free", then Blender will correct it.

After thinking more about this, I don't see a great way to support animation without causing the invalid state, at least without forcing the step of always animating the handle types as well. I added a patch that returns the behavior to before here: [D15290](https://archive.blender.org/developer/D15290) We have to understand that this really is an invalid state of the curves though. If you do further procedural deformation of the curves and don't correct it by setting the curve types to "Free", then Blender will correct it.

Hans Goudey self-assigned this 2022-06-24 22:27:55 +02:00

Hans Goudey commented

2022-06-24 22:29:09 +02:00

I'm setting this to "design" because calling it a bug just doesn't sit right with me.

My remaining question is where we can document this, it would be nice to add a little paragraph in the manual somewhere.

I'm setting this to "design" because calling it a bug just doesn't sit right with me. My remaining question is where we can document this, it would be nice to add a little paragraph in the manual somewhere.

Martijn Versteegh commented

2022-06-25 12:25:04 +02:00

We have to understand that this really is an invalid state of the curves though. If you do further procedural deformation of the curves and don't correct it by setting the curve types to "Free", then Blender will correct it.

I think this will lead to a lot of confusion. But I don't know how to solve it either. In the ideal world I think blender would automagically set the handle type to 'free' for subsequent procedural deformation, but not for the user dragging the original handle? Now that I think a bit more about this I think automatically setting handles to free in needed cases would probably lead to less confusion if documented well...

> We have to understand that this really is an invalid state of the curves though. If you do further procedural deformation of the curves and don't correct it by setting the curve types to "Free", then Blender will correct it. I think this will lead to a lot of confusion. But I don't know how to solve it either. In the ideal world I think blender would automagically set the handle type to 'free' for subsequent procedural deformation, but not for the user dragging the original handle? Now that I think a bit more about this I think automatically setting handles to free in needed cases would probably lead to less confusion if documented well...

Hans Goudey commented

2022-06-25 17:14:43 +02:00

automatically setting handles to free in needed cases would probably lead to less confusion

Yes, agreed. Geometry nodes does do that with the "Set Handle Positions" node. But I don't think that's a simple thing to add to the animation system.

>automatically setting handles to free in needed cases would probably lead to less confusion Yes, agreed. Geometry nodes does do that with the "Set Handle Positions" node. But I don't think that's a simple thing to add to the animation system.

blender-admin commented

2022-06-25 18:11:12 +02:00

This issue was referenced by 5606942c63

This issue was referenced by 5606942c63bf81afa16a0f148287da9421d53a48

Hans Goudey commented

2022-06-25 18:12:43 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Hans Goudey closed this issue

2022-06-25 18:12:43 +02:00

Daniel Salazar commented

2022-06-27 05:39:50 +02:00

Hi @HooglyBoogly , Thank you for taking a look at this rather complex topic.

I was testing your latest changes and still found vector handles do not respect the keyframed positions.

See:

Vector.blend

Hi @HooglyBoogly , Thank you for taking a look at this rather complex topic. I was testing your latest changes and still found vector handles do not respect the keyframed positions. See: [Vector.blend](https://archive.blender.org/developer/F13231820/Vector.blend)

Hans Goudey commented

2022-06-27 15:39:05 +02:00

Hmm, I'm not sure there's much I can do about that one without the proper "animation sets handle types" behavior.

Segments between two vector handles are hard-coded to have no resolution.

Hmm, I'm not sure there's much I can do about that one without the proper "animation sets handle types" behavior. Segments between two vector handles are hard-coded to have no resolution.

Daniel Salazar commented

2022-06-27 18:53:59 +02:00

Ok makes sense. Thank you anyways:)

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

Regression: Bezier curves fail to respect keyframed handle positions #98965