Difference between revisions of "Talk:Keyframe"
("Duplicate_a_keyframe_with_no_waypoint_on_it" is a bug?) |
m (Information about "menu /../ keyframe" are missing) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
+ | --[[User:D.j.a.y|D.j.a.y]] ([[User talk:D.j.a.y|talk]]) 13:30, 19 May 2013 (UTC) Information about "menu /../ keyframe" are missing | ||
+ | |||
+ | ---- | ||
I think [[Keyframe#Duplicate_a_keyframe_with_no_waypoint_on_it]] can be considered not only as example, but as bug report. :) | I think [[Keyframe#Duplicate_a_keyframe_with_no_waypoint_on_it]] can be considered not only as example, but as bug report. :) | ||
As I understand the main purpose of keyframes is to fixate canvas state at some time (i.e. prevent from changes when neighbor waypoints are created/manipulated/edited). But in this example when we duplicating keyframe we could see what the value of duplicated frame is changed, although we not directly edited him. For me as user keyframes loosing their meaning if they could loose their original values because of some manipulations some simple manipulations. It's possible, what duplicating of just one keyframe can ruin whole animation. --[[User:Zelgadis|Zelgadis]] 04:59, 29 February 2008 (EST) | As I understand the main purpose of keyframes is to fixate canvas state at some time (i.e. prevent from changes when neighbor waypoints are created/manipulated/edited). But in this example when we duplicating keyframe we could see what the value of duplicated frame is changed, although we not directly edited him. For me as user keyframes loosing their meaning if they could loose their original values because of some manipulations some simple manipulations. It's possible, what duplicating of just one keyframe can ruin whole animation. --[[User:Zelgadis|Zelgadis]] 04:59, 29 February 2008 (EST) | ||
+ | : You can consider it a bug, yes. But remember that lock keyframes is designed to stop effects on the neighbor keyframes of the place where the new waypoints are inserted. In the example you mentioned there is a keyframe at frame 4s and it keeps the current value. To solve that bug, Synfigstudio would lock all the keyframes past and/or future (depending on the keyframe lock status) and not only the neigbour ones were the new waypoint was created. I don't know if that is better or worse than the current behavior. --[[User:Genete|Genete]] 08:28, 29 February 2008 (EST) | ||
+ | :: Notice how "Lock Keyframes" states called: All Keyframes Locked/Past Keyframes Locked/Future Keyframes Locked/No Keyframes Locked. Nothing said about "neighbors". :) Now synfig considering only neighbors. But I think that it's breaks all keyframes concept. | ||
+ | :: I consider keyframes as waypoints for canvases. Waypoint is a fixation for something. Currently keyframes is "not always working fixation". This is irritating, don't you think? Maybe synfig must make more deeper analysis while duplicating keyframes to prevent changes in other keyframes. --[[User:Zelgadis|Zelgadis]] 10:43, 29 February 2008 (EST) | ||
---- | ---- |
Latest revision as of 15:30, 19 May 2013
--D.j.a.y (talk) 13:30, 19 May 2013 (UTC) Information about "menu /../ keyframe" are missing
I think Keyframe#Duplicate_a_keyframe_with_no_waypoint_on_it can be considered not only as example, but as bug report. :)
As I understand the main purpose of keyframes is to fixate canvas state at some time (i.e. prevent from changes when neighbor waypoints are created/manipulated/edited). But in this example when we duplicating keyframe we could see what the value of duplicated frame is changed, although we not directly edited him. For me as user keyframes loosing their meaning if they could loose their original values because of some manipulations some simple manipulations. It's possible, what duplicating of just one keyframe can ruin whole animation. --Zelgadis 04:59, 29 February 2008 (EST)
- You can consider it a bug, yes. But remember that lock keyframes is designed to stop effects on the neighbor keyframes of the place where the new waypoints are inserted. In the example you mentioned there is a keyframe at frame 4s and it keeps the current value. To solve that bug, Synfigstudio would lock all the keyframes past and/or future (depending on the keyframe lock status) and not only the neigbour ones were the new waypoint was created. I don't know if that is better or worse than the current behavior. --Genete 08:28, 29 February 2008 (EST)
- Notice how "Lock Keyframes" states called: All Keyframes Locked/Past Keyframes Locked/Future Keyframes Locked/No Keyframes Locked. Nothing said about "neighbors". :) Now synfig considering only neighbors. But I think that it's breaks all keyframes concept.
- I consider keyframes as waypoints for canvases. Waypoint is a fixation for something. Currently keyframes is "not always working fixation". This is irritating, don't you think? Maybe synfig must make more deeper analysis while duplicating keyframes to prevent changes in other keyframes. --Zelgadis 10:43, 29 February 2008 (EST)
"Also it is a mark to a special frame where the information of every parameter in the animation is stored there in order to be reused later."
- No information is stored at all if you don't edit any parameter values. For example, make a scene, set the slider to 0s, arrange things, change the slider to 10s, arrange things again. You'll have a bunch of waypoints at 0s and 10s.
- Then add keyframes at 2, 4, 6, and 8s, save the file and look at the saved .sif. You'll not see any information at all about the values of the parameters at 2, 4, 6, or 8s; you'll only see information about the value at 0s and 10s. The values at 2, 4, 6, and 8s are calculated using interpolation, just like all other points in time between 0s and 10s.
- It's only when you edit parameters _after_ making a keyframe that information is stored about the value of the parameter at the keyframe(s). -- dooglus 20:11, 10 October 2007 (EDT)
- The meaning of this phrase is that you are storing the current interpolated values of the keyframes although there isn't any waypoint there. In your exaple wou can make a duplicate of any of the keyframes at 2, 4, 6 or 8s for example at 12s and then the interpolated values are stored with the duplicated keyframe, so in a way or other, the information of the frame (by waypoints or its interpolation) is retrieved in the duplicated keyframe and taken form the original keyframe. It would be a very cool feature that you could make not a copy of the original keyframe but a reference of the original keyframe. It would allow modify the original keyframe and all the referece keyframes would be modified as well.--Genete 04:32, 11 October 2007 (EDT)
"A keyframe could live all the time without any waypoint but it stores the information of the values of the parameters on that specific frame"
- There, you said it again. I suppose you can think of it as storing the information if you like. It doesn't really though. It's just a note that the information must be stored if anyone ever tries to change it by editing in 'neighboring' frames. -- dooglus 20:15, 10 October 2007 (EDT)
"If there is a waypoint there then the waypoint information is stored also (I have to verify this)"
- Waypoints are all that is stored to record animation information. The only thing stored about keyframes are their positions in time (2,4,6,8s) and their names. -- dooglus 20:18, 10 October 2007 (EDT)
- I verified that after upload that wiki page section. If you duplicate a keyframe that has waypoints on it then the duplicate keyframe creates exatclty the same waypoints as the original.--Genete 04:32, 11 October 2007 (EDT)
"Anyway the creation of a waypoint implies possible creation of keyframes"
- I think that's probably just a typo, rather than a misunderstanding. The creation of waypoints can cause the creation of other waypoints at keyframes. It doesn't cause the creation of keyframes themselves - they are only made directly by the user. -- dooglus 20:21, 10 October 2007 (EDT)
- Yes it is a typo.--Genete 04:32, 11 October 2007 (EDT)
I'm going to have to stop reading this for now, I'm too tired. It looks like a very good basis for the page on keyframes, and it well overdue. Well done! dooglus 20:21, 10 October 2007 (EDT)
- Thanks for the review. This evenning - night I'll add more. --Genete 04:32, 11 October 2007 (EDT)