deleting last keyframe causing massive unexpected change

hello

Ive got a simple walk cycle (cut out) - everything animating fine.

however i have an extra keyframe at the very end of my sequence that i am trying to remove. No matter what i do, upon deleting the last keyframe (or reducing overall duration) half of my characters body parts end up all over the place.

The movement is still the same - but the placement of pivot points and placement of pieces has been massively altered.

Because it is a cycle i have used “paste special” to duplicate the first frame, at the second to last frame. (this was done with my master peg collapsed).

i have tried deleting the extra frame with both collapsed and expanded pegs - i have even tried deleting the frame layer by layer in the timeline. with the same result everytime.

my character torso and arms remain sweet, but the legs look like the shropshire slasher has been at work.

any hints?

ps: i have been using the main transform tool with peg only mode set to ON to animate my character which should make a keyframe for each attribute of each piece i have moved - yes?



What scene planning tool do you have selected when you try to delete this set of keyframes ? The delete action is directly impacted by the selected scene planning tool at the time you try to delete a set of key framed parameters. If you have a tool other than the scene planning transform tool selected when you execute the remove keyframe command then you are only removing some of the keyed values. Also you might have a situation where you have migrated keys on children element tracks that are still active and need to be removed. When you un-collapse the main character peg and un-collapse all other children pegs attached to that main peg you should be able to examine the tracks of all of your elements an visually see if any key frame indicators are still remaining on the last frame of each track. I’m just trying to give you some clues to follow based on your description of the issue. Hope this helps.-JK

im using the transform tool. - in fact its the only tool i have been using

pretty sure i was using that to begin with but ive gone back and done it again to make sure.

I have keyframes on everything at the first and second to last frames (which are fine) and a couple of keyframes on the last frame. its when removing these last keyframes that everything goes wrong.

should i not have any keyframes on my element layers and just on my peg layers? - just went and tried this but the same thing keeps happening.

I know its probably partly due to me still thinking “flash” but for the life of me i cant fathom why deleting a keyframe would throw out frames that occur before it in the timeline. especially when im only removing positional values for an element/peg at a given frame.

im a little confused when you say “keys on children element tracks that are still active and need to be removed” - i animated with a collapsed master peg and didnt expand anything - so the keys i have should just be the keys required for each pose of my walk cycle.

yes i am banging my head on the desk :wink:



That is a very logical statement so it would suggest that when you copied your earlier frames you may have effected something globally like a static attribute. That is a non-keyframed attribute set using the scene planning select tool (the arrow). A very important concept and a powerful feature of TBS is the fact that the scene planning tools are not just manipulators but also switches used to control actions.

Now back to your “logical” statement, there is one case in which a keyframed setting does impact earlier frames in TBS. That case is when the keyframed value is the first one set for a track. It doesn’t have to be the first frame just the first keyed frame of the track. In that case it has retroactive impact. So you might want to be sure that you don’t have a track where this situation has occurred. You may have inadvertently deleted an earlier key and have created this situation.



When you have the main peg collapsed and you animate you are in fact setting keyframes in a ripple down effect to all the effected children tracks of that collapsed peg. So the keys don’t just reside on a single track but rather on many tracks. You can uncollapse the main peg and look at the children and you will see all of those key indicators on the tracks. Now you can set keys independently on a specific track by selecting just that track by itself. That’s what I referred to in an earlier post as fine tuning. So if you uncollapsed your main peg and then deleted a key you didn’t get the ripple down so you may have left some orphan keys on children tracks. Key frames are visible as symbols (squares and triangles) on your track display. Red indicators show that keys are set on children but not on their parent.

Render engines are very obedient and they do exactly what we tell them to do even when we tell them things accidentally or unintentionally. Somewhere you have inadvertently done this and now the “painful” task is to find and correct that instruction. -JK



That is a very logical statement so it would suggest that when you copied your earlier frames you may have effected something globally like a static attribute. That is a non-keyframed attribute set using the scene planning select tool (the arrow). A very important concept and a powerful feature of TBS is the fact that the scene planning tools are not just manipulators but also switches used to control actions.

Now back to your “logical” statement, there is one case in which a keyframed setting does impact earlier frames in TBS. That case is when the keyframed value is the first one set for a track. It doesn’t have to be the first frame just the first keyed frame of the track. In that case it has retroactive impact. So you might want to be sure that you don’t have a track where this situation has occurred. You may have inadvertently deleted an earlier key and have created this situation.


Sounds a bit like my problem, where I can’t understand why copy and pasting something at the end of timeline …messes up everything that preceeds it.

But let me see if I get what your saying in this case. If in this case I made a keyframe at frame 100 for example, this being the very first key frame in the track. And later I create more key frames at frames 50, 20, 30 etc. If I delete key frame 100, I will impact the earlier frames (20, 30 etc.)?



No, what I said was that if you have the first keyframe on your track at frame 100 and no prior keyframes on that track, then all frames from 1 to 100 in this example on that track will be controlled by the information keyed to frame 100. If you insert keys in front of 100 then the one closest to frame 1 would be your first keyframe on this track. The idea here is that it is always a sound practice to lock down your initial conditions on the first frame of every track. (this is true for each keyframe type, I stress that because there are many unique keyable types and so the first keyed value of each parameter type on a track is the first keyframe for that type. In theory you could have a rotation key at frame 1 but your first scale key might be at frame 30.)

When copying and pasting keyframed information it is important to use paste special and it is also important which scene planning tool you have selected when you do the copy and paste. You don’t have to actually do anything with the tool but you are telling TBS what parameter or parameters you are wanting to use based on the selected tool, it is a selection switch. -JK

So in the case of the last frame keyframe effecting earlier frames on a track, it would only have this effect if there were no prior keys of that type on the track. If you accidentally deleted your initial location keyframe and set a different location key later on the track then it would appear as if your initial location got screwed up. You wouldn’t notice this until you added that downstream key. Or lets say you deleted a key at the end of your track that was maintaining your location position for the entire track because it was your only key on that track then you would get the effect of things changing at the beginning of your track for no apparent reason. This may not be frasermu’s issue but it is a possibility. As Mathieu stated in his post a more likely culprit would be accidentally mistaking the select tool for the transform tool. You can tell them apart by the “grab” handles on the selection box, for the “select” tool they are solid filled handles and for the transform tool they are unfilled handles.

NOTE: This entire first keyframe retroactive effect is strictly a V3.5 situation. V3.0 and prior versions defaulted a first and last keyframe on all pegs at time of creation. V.35 eliminated default keyframe, which was a nice improvement, but also created the possibility of retroactive influences if you don’t lock down the start of a track.



ok things are starting to be a bit clearer.

but not at the same time.

EG: in regards to the quote above - i have a peg layer (the only child is the object attached to the peg layer)with keys (black square with triangles above and below - i have the same key set up on the object layer attached to the peg) at frames 1 and 25. On frame 26 of the peg layer i have a key i want to remove. deleting this key changes the placement of both the object and the position of the peg rotation point across the board.

everything seemed to go out the window after i did a paste special of the 1st keyframe to frm 25.

also definately only using the transform tool and no other.



of that im sure - going to go back and start again form scratch - practice makes perfect aye?

thanks for all the patient help

whoops - last two lines of the second quote are not meant to be a quote

Thanks, please keep the forums posted as you progress. Considering the type of day I’m having in forum posting successes it is nice to know someone got some benefit. You win some and you lose some.

Many readers benefit from these exchanges and believe it or not there are plenty of people who have or will have similar problems and are probably reluctant to ask for help. So you are helping others by sharing your problem and you efforts to solve that problem.

I’m inspired to re-write and improve my previous articles on the timeline and pegs as I can see a great opportunity to make this area clearer. The best way users can improve the software is through helping to make its usage more understandable. But in the end it is the results a person produces that are important not how easy or hard getting to those results happen to be. I’m also inspired to write a series of articles that better differentiate between limited animation and cutout animation as I sort of think that more people would be successful if they focused on limited animation instead of the much more involved and complex cutout puppet animation. -JK

more info on cut out animation would be a good resource (but thats just my opinion). This is an area that is lacking in the official documentation. Especially common problems and their fixes

As a bit of background info - the reason i view cutout animation as one of TBS’s good qualities is that it allows you to rig a character - which is not very intuitive in flash. Plus with the expression editor you have more control over easing than is possible in flash. I realise im probably jumping in at the deep end with cutout animation, but thats the “hole” we are trying to plug by getting TBS

as a quck note i found that when creating a cycle - it is a good idea to setup the first frame (which will also be the last frame) before you extend the duration of the frames. This seems to ensure the first and last frames are the same and removes the need to delete an unwanted frame at the end. I could prove myself wrong by the end of the day but so far so good

been doing some testing and it appears that my problems were related to the setup and rigging of the character - somehow.

dont know what the issue is - but when performing similar operations on the supplied cut out characters everything works fine when deleting keyframes.

Dont know what i need to fix but at least narrowed it down a bit

if you’d like more on rigging a cut-out char, I have a video tutorial on it. It may be all the stuff you already know, but who knows, you could see something you’ve been missing. You can find it through the link in my sig, it’s in 2 parts, there are links to each post on the right. Hope it helps

checked your tute - cheers - didnt answer all my probs but definately gave me some good points to remember.

liked the z axis change when building heirachies - will definately start using that.

tried some tests using the “built in” pegs that are a new feature of TBS 3.5 (the pegs that are part of each element as opposed to adding and attaching pegs). That seemed to fix the issue of deleting keyframes that i have been having.

however it threw up some new issues. when dragging and dropping an element to make it a child of another element, the default position of the rotation point went WAYYYYYYY of and down to the left and the scale increased (scale increase was exponential as more bits were parented) - i am using a character made up of individual swf’s (1 per body part) so im thinking this may have something to do with it.

learning software is never easy tho is it :wink:



Hi
Would it be posible for me to get theses videos, please, please, I am strugeling and frustraated. My private e-mail is dian.parry@ukonline.co.uk so that I can arange payment and address.

You don’t have to purchase anything, these videos are viewable over the Internet just go to Kdog’s videos pages to view them

PirateToon Productions video part 1

PirateToon Productions video part 2-4

They are right there ready for you to do to view. Special thanks to Kdog for making thse. -JK

SHHHHHH!!! I was about to get PAID!!! heheh…

Hope they help though, Wena, fire away if they are unclear.


Frasermu- I couldn’t tell you if it’s an issue with the swf’s or not, but something it might be is if you set your rotation points before you established all your parent/child relationships. I’m not even positive that would cause it either, but it sounds possible. I’ve always set my peg heirarchy first thought & then proceeded with setting rotation points.

I just watched the tut to check myself, & it looks like I did the opposite of that, because all the rotation points were already set on my elements as they were previously saved as templates in my library. I do know that I set their hierarchical relationships before the pivot points when I originally made the character, so I’m guessing that’s why they still all fit into place when I re-did the parent/child relationships in the tutorial. Hopefully someone can let me know if I’m wrong on that, but it’s my best guess. It might not matter at all & could just be the swf thing. I’ll mess around & do some testing when I get a chance to see if setting rotation points first causes problems.
cheers



ah ha! thats exactly the way things went - i was editing a current rig. good point to look out for

cheers