New Lock Keyframe status

Development Feature discussions
1

Current behavior of keyframes is defined by the lock keyframe status. There are four states in the lock keyframe button:

Lock all: past a future keyframes from the current time cursor are enabled.
Lock future: only future keyframes from the current time cursor are enabled.
Lock past: only past keyframes from the time cursor are enabled.
Lock none: Any keyframe (past, or future) are enabled.

What if plus the lock status button the keyframes were enabled/disabled individually? In that way the lock keyframe status would act like today but enabling and disabling all the corresponding keyframes depending on the current position of the time cursor. Also I suggest to split the lock keyframe status button into four button mutually excluded (like the radio buttons). That would allow quickly the desired status without need to loop by all the status of the lock keyframe button.

With that feature the user can select individually which keyframes are going to be affected by the lock keyframe status.

So the four buttons would act like that:

Assumed that the user press the button with the time cursor placed between keyframe 3 and 4. An asterisk means disabled.

Lock all: past a future keyframes from the current time cursor are enabled.
k1, k2, k3, k4, k5
Lock future: only future keyframes from the current time cursor are enabled.
k1, k2, k3, k4*, k5*
Lock past: only past keyframes from the time cursor are enabled.
k1*, k2*, k3*, k4, k5
Lock none: None keyframe (past, or future) are enabled.
k1*, k2*, k3*, k4*, k5*

The user can disable or enable any keyframe after press one of those buttons and obtain this lock status:
k1*, k2, k3*, k4*, k5

So when the user adds a waypoint on the frame between k3 and k4 then only k2 and k5 would keep the pose.

What do you think?
-G

2

/me head explodes

Man, and I just had gotten my head around how the lock keyframes button worked now…

3

Maybe I didn’t explained properly. I propose that each keyframe has a checkbox (like the checkbox for layers) that allows individually enable or disable them regardless the buton status. They should respond keeping the pose if the keyframe is neighbour of the modified parameter.
The lock keyframe button status only acts as a reset for all the existing keyframes to a set of known status (all enabled, all disabled, past enabled, future enabled)

-G

4

I have to wonder: Why exactly? Does it really add something (new)? Will it enable different kinds of animations? Will it significantly (50%, 25%) reduce the work of an animator?

We can easily add all kinds of features; I’m just not sure they add something useful. I think, in that sense, that the whole “bones” project is much more worthwhile.

G.

5

The main aim of this feature is allow the user use differnt keyframes for different parts of the animation in the same canvas.
Keyframe scope is the entire canvas. Let’s say you have some keyframes set for the mouth of a character and want to create some inbetweens for some lipsync. What would happen if the whole character has other keyframes in in the middle of the keyframes of the mouth? The lock keyframe status makes enabled/disabled the next or previous keyframe regardless what’s the real or desired scope of the keyframe. The only way I’ve found to solve this is to export the mouth in a separate canvas (or import it from an external file) and edit its own keyframes and inbeweens there. That solution is tedious and not always works well (the time cursor is not properly sync beween child and parent canvases).
So I’d love to be able to select which keyframes are locked for each kind of partial animation I want to do, without need to split each part of the composition in a separte canvas.
The current behavior is maintained, because the lock buttons should work the same, but the user has the oportunity to choose other better workflow.

Hmm. There is a drawback. If the user selects a particular lock status, it is vallid only for the current time cursor position. If he jumps to other frame where other keyframes are around, the lock keyframe status maybe is not correct. :frowning:

That’s the reason for the post here.
-G

6

So, I guess the basic underlying problem is that Synfig keyframe concept is too crude. You cannot specify exactly what you want. If I understand you correctly, instead of associating a keyframe with a canvas and every layer and every parameter on that canvas, you want to associate a keyframe with a specific group of parameters of a specific group of layers (on a canvas). If this is the case, shouldn’t we look for a way add this functionality at this conceptual level? My fear is that your solutions (though it probably will work) is rather lowlevel, and might have trouble scaling when dealing with multiple keyframes and layers and parameters. An animator could quickly loose track of what’s going on…

G.

7

Not exaclty.
What I want to be able to do is to select which keyframe is going to be locked on past and which one is going to be lokec on future. As frames are unique per canvas it has not meaning to stablish a keyframe per parameter. If it is defined for a parameter the keyframe is a keyframe at all and can be used for any parameter that is modified when the keyframe lock status is ON.

So I just want to add the option to select wich keyframe is the next one locked in past and future form the point of view of the time cursor. Current behavior is that the closer keyframe is the one that is locked. That might be unuseful in several situations (For example main motion and secondary motion). For main motion (walk) you stablish the main keyframes and in the same canvas you stablish the secondary keyframes for secondary motion (the dress) it is a pain to edit the dress using keyframe features because the main keyframes are interfering… unless you can select wich keyframes are locked when you’re editing the secondary motion and viceversa.

Maybe there is other solution like group keyframes and toggle one group to other in the same timeline/canvas for eidtion of different parts of the animation. I don’t want to restrict object-param to a particular keyframe because mabybe the user want to mix both animations (main and secondary)

Hope it makes sense.
-G

8

Genete: I don’t think we misunderstand eachother as much as you think! Maybe a minor language barrier? :wink:

To make things more concrete, let us consider your example. An animator wants to animate a girl in a skirt walking. In this example, we have motion one: the legs moving; and we have motion two: the skirt moving. Motion one and motion two are related, but their movement is mostly independent. Since the motions are independent, motion one and motion two probably need to have their own keyframes. Currently, however, if motion one and motion two are part of the same canvas, they will be influenced by the same set of keyframes.

Your solution: Let the animator select the “previous” and the “next” keyframe to use, depending on whether he works on the legs or on the skirt.

My solution: Let the animator associate the keyframes for motion one with the layers for motion one, and associate the keyframes for motion two with the layers for motion two. This solution should additionally also allow associating keyframes with both motion one and motion two.

My idea is that if the animator switches regularly between animating the legs and animating the skirt, my solution is less work for the animator than yours, and there is no risk of the animator forgetting to select the different keyframes when swithing to the other motion. I assume the animator will switch regularly since both motions are related.

On the other hand, your solution might very well be much easier to implement.

I took my idea one step further: I would assume that an animator sometimes wants to associate the keyframe with only certain parameters within a specific layer. For example, in a region layer, the animator might want the keyframe to influence only the list of vertices parameter and not influence the color parameter. Hence my remark about also specifying the parameters that should be influenced by a specific keyframe.

I hope this made my idea more clear.

With regards,
G.

PS: How are the bones coming along?

9

Ok, what you explained is what I wanted to explain. Your proposal is certainly more helpful for animator “once” it is set up. There is an extra work for the animator to specify which keyframes are for which layer/parameter. But it is true that once done the animator can forget about them from now on.

As you mentioned, the implementation of my solution is simpler and I have not an initial idea of how would yours be implemented. Maybe it is worth to think on it because certainly it is more useful at the end.

Regarding to bones there are two circumstances that have stopped them momentarily:
-Dooglus’s laptop cannot connect to Internet properly.
-We don’t know how to code properly inverse manipulation of blinepoints under bone influence. We thought that it would be similar to Link to Bline inverse manipulation but we don’t find the key to make it work.

Maybe you can take a look? If so, and want to comment something, please open other post or reopen the bones feature thread.

-G