Thougts on interpolation

I often heard that not all are happy with the current interpolation. At first it is not very intuitive to use and at second it has some problems to be fluid in motion (over- or undershots). So i spend the last days in investigating a better method to do the interpolation.

At first i wanted to get rid of TCBs control over the tangents, which should be able to be specified by the user itself, even though default values (tangents) are provided. So i came to the solution that the path a vertex travels should be a bezier-spline, that can be directly manipulated in the canvas. The control points of this spline will be the locations at the keyframes. The tangents will be initially calculated with Catmull Rom, since it is easy to compute and gives good results. (TCB in standard configuration does exactly this) After that, the user is free to manipulate the tangents and the path the vertex travels. Moving the control points is like moving the vertex itself, while manipulating the center control points (tangents) allows to tune the animation visually. So you can easily predict which way it will travel from start to end. Displaying the points of frames between keyframes is also an easy task.

Thoughts in the big future: If this works as expected, we might have the possibility to get rid of the time line (at least the big one) completely, since anything could be handled directly inside the canvas. Even moving keyframes could be done that way. (Just drag it to another displayed keypoint)

So far the theory. Currently i will try to setup an example application with this approach, which i will write in Java. Since im much more comfortable with it then with C/C++. But basically both languages share most things in common and porting it to C/C++ wouldn’t be so hard. Hardest part so far is the control over the speed on a bezier curve. Since it can’t be solved directly (neither with TCB [cubic hermite curves]) i will have to write a fast approximation. (if its fast in Java, it should run like hell in C :wink: )

If you have any questions, suggestions or don’t like the approach, then please let me know.

This is an interesting approaching but I have some doubts. Let’s call time-path the bezier that the data travels along the time and is represented on the canvas. Say you have two waypoints so the time-path has to vertexes and its tangents for TCB controlling…
I guess that the time of those time vertexes can be known by hovering on the time-vertex and a pop up would reveal its value. Say you want to modify the value of the time-vertex (position or in/our interpolations) then it can be done with the time-vertex or the time-tangents. But how to modify the time of the time-vertex? should it be dragged along the path? remember that the path changes when the time changes because the interpolation depends on the time, the surrounding values and the TBC values. It would look a bit weird. Specially when dragging more than one time-vertex along the path…
Latest. Keyframes are not waypoints. They are just marks on the timeline and the waypoints are the results of that. So completely remove a timeline would be a bit hard. I guess that the time panel can be removed but the canvas timebar cannot.
It is an interesting concept but needs more refining. For example there are parameters that doesn’t have duck representation (colors for example) and I might want to control its waypoints and TCB values along the time. How would they be controlled if we remove the time panel?

I agree that the interpolation needs a rework.
Ability to manipulate curves with bezier handles is a splendid idea. (Keeping them in the graph editor would feel more natural to me though.)
I do however think that it is not such a good idea to base this on the TCB as default. You still get that over/undershoots in motion and will still have to spend considerable time to manually adjust the motion TCB gives. Still tedious work even if bezier manipulation will make it easier.
Getting rid of that default over/undershoots is essential for a faster, more fluid workflow in my opinion.

As to getting rid of the timeline I strongly advise and wish against it. I’m an animator, I like to have control over my motion and see where my keyframes and waypoints are. The timeline concept is very deeply rooted in all animation software and in animators. Removing that concept will make Synfig a confusing and freakish bird to use.
An addition of ability to manipulate time keys in the canvas would be interesting however. Just as it’s not a replacement but a complement.

You can see my view on interpolation here (although I think you’ve already seen it);

Thats why i want to implement it first, to see which problems arise and what can be done and what not. Removing the timeline isn’t the ultimate goal. But having to use it as less as possible would be imo a nice addition.

What maybe leads to misunderstandings is the use of interpolation for the automatically added tangents. This will only control the (forward) way, but not the time. The length of a handle has no influence at all, it only controls the path. Dragging a node to a previous frame does not mean to drag the node at all. Only the waypoint will move in time.

Using Beziercurves should reduce this problem, but i guess you cant fully avoid it, as long every waypoint needs to be reached exactly. Currently im thinking more or less that the TCB implementation has some minor issues and isn’t correct. As far i can see it has problems to get the right tangent orientation and time distribution, since it makes some assumptions that are not generally true. Best seen in a simple example where the tangents rotate 360° around its vertex from one frame to the other.

What i try to achieve is a way of editing that needs as less as possible interaction with the timeline. If you still want to use it, then you should also be able to. Thats right. I just want to connect the timeline and the canvas closer to each other, since in synfig both things are very closely related.

If you wan’t to see the exact time, then i would say: yes. But i thought of displaying the waypoints and the “frame points” also on this path. (a good amount of frames in the future and past if possible, ends will be extended linearly, just to be able to move a vertex in the future.)

Thats what i’m trying to avoid by making the path itself independent from time. So that you can drag a waypoint to another frame-point (but only using its time). This will change the speed of the curve(-segments), but not its direction. The path traveled will be the same, only the speed changes, while the displayed points will give you a good look at the speed. (long way, less frames -> far distant frame points -> high velocity)

Your are right on that. A timebar should be kept, alone for the reason of fast navigation it needs to. Im still confusing the wording of “keyframe” and “waypoint”. (if i speak about keyframes and it makes no sense, think of it as a waypoint, since i’m currently only focusing on waypoints and their time)

It depends strongly on the visualization. You could indicate the color at the frame points by drawing a small colored border or fill in this color.

Guess i will spend more time to think things over and make a sample application and drawings to illustrate it better. “One image can say more then 1000 words.”

Cherck out this:


Its clear to me what keyframes and waypoints are. But i always mess up the terms in words, writing one for the other, meaning the right thing. :wink: