Page MenuHome

Added keyframes incorrectly altering animation curve
Closed, InvalidPublic


Windows 7 Professional 64-bit w Service Pack 1
Display Card: Nvidia GeForce GTX 760

Blender 2.69 - r60995

There is a bug in the subdivision of animation curves.

See the attached file: “curve bug.blend”

The three cubes are animated from -5 units on Y to +5 units on Y over the length of the animation.

The green cube has had one extra keyframe added. This was done by simply going to time frame 125 and using the I key to add an extra location keyframe. No translations were made to the green cube prior to adding the extra keyframe. It can be seen in the animation that the simple addition of this extra keyframe has altered the speed of cube relative to the other two cubes that do not have the added keyframe.

It will be seen that the handles of the added keyframe do not respect the slope of the existing animation curve. This is not correct behaviour. Since there has been no change at all to the cube, the desired end result would be a subdivision of the animation curve and handles as required that still retains the existing slope.

The attached file, “incorrect curve.jpg”, shows the incorrectly altered animation curve (in green) relative to the form of the animation curve as it existed before the addition on the extra keyframe (in yellow).

By way of comparison, the subdivision of curves in the edit mode is handled correctly. Here it is obvious that the curve is retaining its form and slope no matter how it is subdivided. See attached file, “edit curve subdivide.jpg”



Event Timeline

Ignatz (ignatz) added a project: BF Blender.
Ignatz (ignatz) set Type to Bug.
Ignatz (ignatz) added a subscriber: Ignatz (ignatz).
Ignatz (ignatz) created this task.
Ignatz (ignatz) raised the priority of this task from to Needs Triage by Developer.
Brecht Van Lommel (brecht) triaged this task as Normal priority.

It indeed does not attempt to keep the curve the same, as far as I know that was never intended to work, so this would likely be considered a feature request. But it's up the animation team to decide that kind of thing.

I agree with Brecht that this is a feature request.

In general, most key frames are added not to subdivide a curve while preserving its curvature, but rather are added to provide a new data point to alter the curve.

There are situations where it would indeed be handy to subdivide a curve for minor tweaking, but that doesn't usually come until later in the animation process when you're polishing things in the graph editor. If curve-preserving subdivision was a default behavior in the 3d editor, that would cause problems and unexpected behaviors.

I recommend we make this a tool in the graph editor. Something like "subdivide curve at time cursor".

Please allow me to point out that bezier curve subdivision is really nothing new. Almost any vector drawing program worth its salt handles this curve subdivision by addition of anchor points properly. For example see curve behaviour in Photoshop, Inkscape, etc.

The real problem here as I see it is that the addition of the extra keyframe(s) is unnecessarily changing the mesh object's velocity where the operator did not expect it nor expressly intend it to happen.

Whether this is regarded as a bug or a feature request, I truly believe that addressing this would be an improvement to the animation system of Blender.

Oh, and I forgot to mention one other thing. This same odd tension implementation of the curve subdivision also affects anchors which are added when doing automatic keyframing.

This means that if the operator moves the object only a little bit (so as to make certain that it passes through a certain point in space) the keyframe anchor that is added once again will unnecessarily cause the curve to have unexpected slope changes. Of course, this makes perfect sense since the auto keyframing procedure is running on the same (flawed) algorithm.

Please allow me to point out that bezier curve subdivision is really nothing new.

Agreed. The math is quite straight-forward and easy to implement. That's not the issue here. The issue is workflow and user experience:

The use-case here is different than that of a vector drawing program. During the early stages of animation (typically known as "blocking") where the animation is still rough, it is advantageous for the animator to focus only on the time and value of keyframes, and not have to think about the handles.

Specifically, in a pose-to-pose workflow, the animator will frequently be adjusting the timing of large numbers of key frames together. If inserting keys acts like subdivision, the resulting key frame handles will be static (or "manual), rather than auto. When the animator then subsequently changes the timing of the key frames, those handles won't adjust accordingly and the will result in strange interpolations that require manual intervention on each of those large numbers of keys.

Therefore I argue it is a poor default behavior.

However, as I said in my previous post, this is a feature that makes a lot of sense to be in the graph editor. The point at which a user is focusing on key frame handles is also the point at which they are spending a lot of time in the graph editor. So making this a tool in the graph editor makes a lot of sense, and would be very useful there during the polish phase of animation.

I also wouldn't object to it being available in the 3d view, but it shouldn't be the default behavior.

I'm more aligned here with Cessen - 'insert with curvature preservation' could be a tool. If it isn't:

1- we should make a table of possibilities of each end point handle type (vector/aligned/free/auto/auto clamped) and possibly keyframe type (linear/constant/bezier)
2- decide for each type what the right behavior is
3- If we find there is an intutitive and consistent result (I'm a bit pessimistic about this) then we could add 'curvature preservation when possible/sensible as a feature.
4- If it gets too dicey it might be better to do insert curvature preservation as a new tool, explicitly invoked by the animator.

In practice I've never been bothered by the current behavior - reason being, I insert keyframes in order to change behavior, so I'm not trying to keep the curvature. This is pretty typical, but I bet there are some workflows / use cases where you would want to keep it.

Julian Eisel (Severin) closed this task as Invalid.

Reading this, it seems like decision was made to handle this as a feature request!? In this case a new ToDo or Design task should be opened, but for now it's time to close this (almost a year old already)