The timeline tends to get cluttered with keys, too many to remember exactly what animation they represent. I have an idea that might help people like me keep track of what each key does.
Keys are often copied and pasted to temporarily halt animation. Perhaps there could be a method for quickly identifying such pairings of keys? I think easily identifying such pairings would help a person keep mental track of what each key does.
Perhaps the copied key and the pasted key could be the same color, a color different than the usual color? Or perhaps there could be a zig-zaggy line between the pair of keys?
Easily identifying copied and pasted keys on the timeline
Moderators: Víctor Paredes, Belgarath, slowtiger
There would really be no way to keep track of "copied" and "pasted" keys after they are pasted. Once a key is pasted it's... just a key. The best solution for this would be time line labels. That is another feature request a lot of us would like very much.
Another idea for this might be to "colorize" the space between two keys based on the amount of change. If the amount of change between two keys is the same or close the color between them would be different from the color between two keys that have a larger difference in value. This could be like a "gradation" change in color based on value differences. It would be like "elevation maps" that use color to indicate height of terrain.
-vern
Another idea for this might be to "colorize" the space between two keys based on the amount of change. If the amount of change between two keys is the same or close the color between them would be different from the color between two keys that have a larger difference in value. This could be like a "gradation" change in color based on value differences. It would be like "elevation maps" that use color to indicate height of terrain.
-vern
The problem with the keys is that most of the time they represent to many objects at the same time (points) or it is not a single real value (points or color) In the rest of cases, the level of the keyframe (its value) can be determined looking to the graph mode to the selected object channel and its single real value (angle, scale, xpos, ypos).
I thought the same thing Genete. My idea would probably need to be part of a "revamped" time line, or I was also thinking if you could see all the channels for a bone, scale, rotation, translation etc, then the spaces between those keys in the time line would be a color that represents the change in value.
You could easily see where two keys are that are very close in value representing a "hold" key. This could be based on a gradation or blend between two colors set in the preferences. If the blend has extremes at each end of this "blend" then it would indicate a large change in the value over time. If the colors at each end of the blend are closer in value less change. Each color could represent the start and end point of some arbitrary min/max values or something. Just brainstorming.
-vern
You could easily see where two keys are that are very close in value representing a "hold" key. This could be based on a gradation or blend between two colors set in the preferences. If the blend has extremes at each end of this "blend" then it would indicate a large change in the value over time. If the colors at each end of the blend are closer in value less change. Each color could represent the start and end point of some arbitrary min/max values or something. Just brainstorming.
-vern
Re: Easily identifying copied and pasted keys on the timelin
Okay, if that initial suggestion is not quite possible, then how about this...
First let me describe an animation. Imagine a vector layer containing a toad. And I animate the toad hopping, then pausing, then hopping, then pausing--and this goes on for a bit, with various distances and heights between hops.
To cause the toad to sit still from frame 100 to frame 120, I copy the key at 100 and paste to frame 120.
What if the pasted key was an "x" instead of a circle? Or what if it was a different color?
If it were somehow different, I could conclude that from that frame forward, a hopping movement begins anew. That would be helpful.
First let me describe an animation. Imagine a vector layer containing a toad. And I animate the toad hopping, then pausing, then hopping, then pausing--and this goes on for a bit, with various distances and heights between hops.
To cause the toad to sit still from frame 100 to frame 120, I copy the key at 100 and paste to frame 120.
What if the pasted key was an "x" instead of a circle? Or what if it was a different color?
If it were somehow different, I could conclude that from that frame forward, a hopping movement begins anew. That would be helpful.
Well... as long as the "X" is a user choice. It wouldn't be automatic. It would have to be something you the user would select by "right clicking" or something. I'm not saying your original idea couldn't be done in some way or wasn't a good idea. it was the "process" I was questioning (thus the reason for those other ideas to improve on it).
Not all "pasted" keys need to be uniquely identified. What happens when pasting 20 keys? How does the software "know" you pasted a key and didn't just "move" a bone? More often than not I don't "copy/paste" to create those hold keys. I don't want a "frozen" key. I want a "moving hold" which means I just "wiggle" the bone or tweak it to create a key rather than copy and paste. In that case I would need the same functionality so I wouldn't want it linked to "copy/paste".
Maybe you don't mean the pasted key specifically be different but just the idea of a different symbol for a key that the user choses as it is needed?
-vern
Not all "pasted" keys need to be uniquely identified. What happens when pasting 20 keys? How does the software "know" you pasted a key and didn't just "move" a bone? More often than not I don't "copy/paste" to create those hold keys. I don't want a "frozen" key. I want a "moving hold" which means I just "wiggle" the bone or tweak it to create a key rather than copy and paste. In that case I would need the same functionality so I wouldn't want it linked to "copy/paste".
Maybe you don't mean the pasted key specifically be different but just the idea of a different symbol for a key that the user choses as it is needed?
-vern
That's not quite what I meant, because it's a thousand times better!heyvern wrote:Maybe you don't mean the pasted key specifically be different but just the idea of a different symbol for a key that the user choses as it is needed?
Maybe two or three different symbols, even. That would be awesome, and it would help me keep better mental track of what the numerous dots on the timeline are for.
-
synthsin75
- Posts: 10270
- Joined: Mon Jan 14, 2008 11:20 pm
- Location: Oklahoma
- Contact:
Yeah, it might be cool if you could use custom pngs like we have for tool cursors and icons. I don't think there'd be any easy way to assign them automatically, but perhaps have their names in the interpolation context menu to assign them. Might be a fairly easy way to implement a kind of symbol tag.
I mean that's just a widget change, right?
I mean that's just a widget change, right?
Okay! Mike Clifton? Smith Micro?
The OFFICIAL feature request is some type of user modifiable symbol or icon for the key frames "dots". to determine at a glance what they represent.
Possible simple alternative:
Instead of just a single color dot or different style icons just simple color choices. This would be easier than adding in a new symbol or icon. Just the simple ability to choose alternate colors for the key frame markers.
-vern
The OFFICIAL feature request is some type of user modifiable symbol or icon for the key frames "dots". to determine at a glance what they represent.
Possible simple alternative:
Instead of just a single color dot or different style icons just simple color choices. This would be easier than adding in a new symbol or icon. Just the simple ability to choose alternate colors for the key frame markers.
-vern
What about tiny numbers?
You can have a set of keys with numbers like "01" going to "99" and that ought to do it. At the resolution most of us run AS they should be visible on the timeline as long as you are zoomed in far enough.
Numbers offer all kinds of options (being able to select ranges to do things with, for one tiny example). Programmers love numbered things -- much easier to work with than colors or symbols (which will end up with a numerical representation anyway).
You can have a set of keys with numbers like "01" going to "99" and that ought to do it. At the resolution most of us run AS they should be visible on the timeline as long as you are zoomed in far enough.
Numbers offer all kinds of options (being able to select ranges to do things with, for one tiny example). Programmers love numbered things -- much easier to work with than colors or symbols (which will end up with a numerical representation anyway).
Colors and "icons" are actually much better than using numbers. At a glance a number doesn't tell you much. Plus we already know the "numbers" if you look at the time line.
Colors are quickly and easily recognizable. When you use database software colors are used to highlight rows and columns. Colors and icons are used in this very forum to make navigating and recognizing things instantaneous. Colors and icons are used in this way for all applications. How many of us have applications that we have gotten so use to that when we see a series of colors or icons we know instinctively what they represent?
Numbers on key frames would be... bad in my opinion. I have a big monitor but those numbers would be too tiny to be of any use to me. You would have to stop and focus on the numbers to know what they mean.
As for working on "ranges" that could still be in there. I'm not sure what ranges you would use other than key frame ranges though.
-vern
Colors are quickly and easily recognizable. When you use database software colors are used to highlight rows and columns. Colors and icons are used in this very forum to make navigating and recognizing things instantaneous. Colors and icons are used in this way for all applications. How many of us have applications that we have gotten so use to that when we see a series of colors or icons we know instinctively what they represent?
Numbers on key frames would be... bad in my opinion. I have a big monitor but those numbers would be too tiny to be of any use to me. You would have to stop and focus on the numbers to know what they mean.
As for working on "ranges" that could still be in there. I'm not sure what ranges you would use other than key frame ranges though.
-vern
No, maybe you misunderstood me Vern (or maybe I misunderstood what was needed).
I thought the idea was being able to group certain sets of keys for the purpose of doing something with them -- and thus each "group" would have a different color or icon. For me the easiest way to handle this would be for each group to have a different number.
But perhaps I didn't pay enough attention to the whole thread -- sorry. If the idea is to identify the types of keys then colors by all means would be easier (although you can already identify types by looking across the timeline).
I thought the idea was being able to group certain sets of keys for the purpose of doing something with them -- and thus each "group" would have a different color or icon. For me the easiest way to handle this would be for each group to have a different number.
But perhaps I didn't pay enough attention to the whole thread -- sorry. If the idea is to identify the types of keys then colors by all means would be easier (although you can already identify types by looking across the timeline).
I think the idea here originally was to have a quick way to identify "hold" and "moving" pairs of key frames. Key frames like that are can be hard to see at a glance. If they have unique icons or colors a quick glance at the time line would tell you exactly what is going on.
Grouping keys with numbered identifiers would work I suppose as long as the grouping could also include a "color" either a "bar" or range that encompasses a group.
Not sure what you mean by editing a "range". If that were possibly you could just use the actual "range" like keys between "100 and 356" or something like that. Or I suppose a group of keys for a specific bone in a specific channel... hmm... interesting idea.
-vern
Grouping keys with numbered identifiers would work I suppose as long as the grouping could also include a "color" either a "bar" or range that encompasses a group.
Not sure what you mean by editing a "range". If that were possibly you could just use the actual "range" like keys between "100 and 356" or something like that. Or I suppose a group of keys for a specific bone in a specific channel... hmm... interesting idea.
-vern