make the GUI show if two consecutive keyframes are the same

[Daxel]

In Moho we can hold a keyframe, and the GUI shows it clearly as a wider dot, which is ideal to know that the value didn't change between those frames. But the problem is that in practice I never have held keyframes and I don't see users having them either. So I have many keyframes all over my timeline that I never know if they are actually animating something or just holding a value.

I think we don't use held keyframes for two main reasons:

1. Held keyframes are not created automatically. There are many many ways to hold poses, bones or points in Moho, and none of them create held keyframes. I'm talking about just clicking on bones or points to hold their values, using freeze pose, freeze bones, freeze points, freeze selected, reset bones, reset points, double-clicking on a channel, add keyframe, etc... They all create regular keyframes even if the created keyframe is the same as the previous one.

2. Held keyframes are less practical when we want to move keyframes arround. If you are selecting and dragging a group of keyframes and the end or the beggining of a held keyframe happens to be inside the selected area, the entire held keyframe will be selected and dragged even if the other extreme of the held keyframe is far away from the selected area. So users try to avoid them and that's why solving just the problem 1 wouldn't be desirable.

My proposal:

When we create or change a keyframe, Moho checks if the keyframe has the same value as the previous and the next keyframe. If the value is exactly the same, a line will appear connecting those keyframes to clearly show they are the same. If later the values stop being exactly the same, they should look normal back again and not as held keyframes. This feature is present in other programs so it should be very intuitive. The keyframes would keep being independent from each other so they wouldn't cause any problem when moving things arround.

Edit: The line conecting keyframes is visually ideal but in practice Moho represents the circles too close to each other to be able to show a line conecting them, so instead of the line we could have different shaped keyframes, like squared or diamond shaped keyframes, or colored keyframes (idealy the user could choose the prefered color).


Would this be useful to you?

[mmmaarten]

Great suggestion!

[Daxel]

Thank you!

When I watched the latest video from Victor Paredes on Timeline Improvements, I noticed for a moment he couldn't find a frame that was right next to where he just held a pose. That's a good example of how even a grand master like him would benefit from being able to quicky find held keyframes.

https://www.youtube.com/watch?v=8AjGBgxgHag&t=473s

Watching that video also thought about how useful would be to be able to see reset keyframes too (any keyframe with the same value as the frame 0). This is very useful not only during animation but also creating and fixing smartactions with negative and positive angles combined that need a perfect frame 0 right where the bone is also in its frame 0 angle.

As a follow up, I changed my mind about the proposed visual hint being a line conecting the keyframes because in moho the keyframes circles that are in two consecutive frames are seen right next to each other with no space in between for a line conecting them. So it would have to be something different, like square keyframes or colored keyframes.

[synthsin75]

A script could possibly color-code keyframes that are either holds or duplicates of frame zero. Of course, this could mess up any keyframe coloring someone is using.
Unless someone gets to it first, I'll put it on my list.

[Daxel]

A script could possibly color-code keyframes that are either holds or duplicates of frame zero. Of course, this could mess up any keyframe coloring someone is using.
Unless someone gets to it first, I'll put it on my list.

I think that would be good enough, specially if it has the option to choose the color for both things.

But the tool would have to be manually used to color the keyframes, right? Or is it possible to have a script that is ran automatically each time we add/modify a keyframe?

[synthsin75]

But the tool would have to be manually used to color the keyframes, right? Or is it possible to have a script that is ran automatically each time we add/modify a keyframe?

I *think* I could get it to work automatically, with user options for the colors used.

[Daxel]

I *think* I could get it to work automatically, with user options for the colors used.

That would be amazing!

[synthsin75]

It's on my list. No promises about a due date though.

[Daxel]

It's on my list. No promises about a due date though.

Of course, no pressure.

[hayasidist]

... is it possible to have a script that is ran automatically each time we add/modify a keyframe?

I *think* I could get it to work automatically, with user options for the colors used.

before getting too far into making this run automatically, remember there could be very many duplicates "intentionally" created by auto-freeze; also when considering the "all" or "selected" channel - if there are (e.g.) 3 points selected and ONE of them has the same value in successive keyframes, but not the others, what to you show?

[Daxel]

before getting too far into making this run automatically, remember there could be very many duplicates "intentionally" created by auto-freeze; also when considering the "all" or "selected" channel - if there are (e.g.) 3 points selected and ONE of them has the same value in successive keyframes, but not the others, what to you show?

Good question. I quickly tested how colors work and they seem to show the predominant color, so if the majority of bones have blue keyframes in that frame the general keyframes will look blue, and if the majority of the selected bones have blue keyframes in that frame, the "selected" red channel will show blue keyframes.

I think this "majority" behaviour is not ideal for this purpose. The user wants to know if *anything* changed that frame. So if something changed, even if the majority of the elements were unchanged, the keyframes should show that something changed. Only if every element (or every selected element) has the same values, the keyframes should show that they are the same.

[hayasidist]

if you're looking to flag "same", but only one out of 3 selected is "same" then what I think you've just said is that it would be necessary to flag a majority as "same" to have the colour show in the "selected" channel and similarly if there are a total of 10 in the all channel then again it would be necessary to flag a majority???

[Daxel]

if you're looking to flag "same", but only one out of 3 selected is "same" then what I think you've just said is that it would be necessary to flag a majority as "same" to have the colour show in the "selected" channel and similarly if there are a total of 10 in the all channel then again it would be necessary to flag a majority???

I'm not sure if I understood what you said. English is not my first language so I will try to explain it better.

The "majority color behaviour" is how colors work by default. And it means that a circle will display the color of the majority of the keyframes that are represented by that circle. If 6/10 are blue, the circle representing those 10 keyframes will be displayed blue. This is true for the circles in the red channels too.

But that "majority color behaviour" is not that useful to display circles as "same", because when a circle is flagged as "same" each and every keyframe represented by that circle should be the same, and not just the majority of the keyframes.

So answering your first question:

if there are (e.g.) 3 points selected and ONE of them has the same value in successive keyframes, but not the others, what to you show?

The circles should look normal, because they are not representing keyframes/values that are all exactly the same. Only when you select that one point that has the same value, the circle in the red channel should be shown as "same".

[hayasidist]

thanks for the clarification (and your English is fine) -- I was, in effect, asking if your intention was to make it obvious that there was a duplicate by making all keys coloured -- and you've just said that you only want to show duplicates if all (or a majority) of selected items have duplicated keys -- it's a clarification for the design - either approach could be made to work.

But I guess I should have asked this first -- why? It's very common to (say) move something; leave it there and then move it later.. IOW keyframe at start-1, then at end-1, then at start-2 (=end-1 value)... Three in a row would make more sense to me, with the middle one as a candidate for deletion.

[Daxel]

and you've just said that you only want to show duplicates if all (or a majority) of selected items have duplicated keys -- it's a clarification for the design - either approach could be made to work.

Only if all items have duplicated keys. If the majority of the items have duplicated keys, but not all of the items, I think it should not show as a duplicate, because it is not.

But I guess I should have asked this first -- why? It's very common to (say) move something; leave it there and then move it later.. IOW keyframe at start-1, then at end-1, then at start-2 (=end-1 value)... Three in a row would make more sense to me, with the middle one as a candidate for deletion.

The reason is just to be clear, to not give false or incomplete information. Showing a circle as "same" is only totally true if every item represented by that circle has the same values. If the user wants to know if there are "same" values in a circle that looks normal, he can be more specific selecting specific items to see if those have the same values. But if a user sees a "same" circle, he instantly knows that the items represented by that circle are, without a doubt, all the same as the previous circle.

In practice, the workflow of the animator shouldn't matter, this is just a visual help to easily spot held poses and held values arround the timeline at a glance. Victor, in that video, when he freezed the pose in the middle of the timeline, those keyframes would have clearly shown as a held pose. And if later he decides to move a single bone in that frame, the circles would have to look normal back again, because no matter how little you move, if you are moving you are not holding a pose so it shouldn't look like you are holding a pose there.