When resizing key cannot snap to frame

ryf9059

I was trying to resize an animation from 40 frames done to 20 by dragging a box over all the keys and resize the box. However I can't snap to last frame to 20, it was either at 20.5 or at 19.5, which I don't believe is an actual key frame time, all other keys are all stuck in between integer frames. Due to the fact that key frame doesn't snap to numbers I was not able to reverse the frame, it will be somewhere at 41.1 while it should be 40. In this case how is spine handling the key? What are those actual key frames? Is there a way to make then snap to integer? It's confusing when the frames are between numbers, not sure what those frame actually are.

ryf9059

Pharan

There's a peculiarity that you have to be aware of when box-selecting and doing this resize operation.

The selection box isn't just a selection of keys. Its size has nothing to do with the first and last keys selected. The size is the actual size of the box you see, and includes the empty space before or after they keys you dragged around.

So if you started dragging from 41 down to 0, and then tried to resize it to half, it's actually the edge of your box that snaps to integer values. If you dragged 41 to 20 or 21, neither would result in a perfect 1/2 scale and, as a result, your keys won't land on integers.

HERE'S WHAT YOU CAN DO: Drag a box from 42 to 0. Then resize that box to 21. That should make your even keys land on integers, and the odd keys at half frames.

The behavior's a bit unexpected when you're used to other programs, but it's what it does. I think resizing itself is logical and useful. It scales the spacing between the keys according to how much the whole box was scaled. Just like in image editing programs like Photoshop.
But what's difficult to do right now is make a selection box starting from a key. Clicking and dragging a key moves it instead of making a selection including it.
The selection box limitation probably wouldn't matter if there we could type the desired scale in a box somehow. Like type: 0.5 and it'll scale to half no matter what our selection box is.

On another note, ALL keyframes are actually stored as fractions of seconds in the data. Frame 1 is 0.033333 seconds. Frame 15 is 0.5 seconds. 20.5 is actually a perfectly valid keyframe that translates to 0.68333 seconds. But I also agree that fraction frames are messy to work with and manipulate in the dopesheet, especially when you want things to align with each other.
In this sense, "frames" is ever so slightly misleading since this type of animation doesn't really deal with discrete slices of time.

Nate

The selection box size is used because it is more flexible. You can scale the whole box or you can scale just keys by making the box just large enough for those keys. To start a selection box exactly on a key, move the mouse just above or below the key, then start to drag. If the key is not selected before doing this, then you'll know the mouse is in the right place when the key is no longer highlighted. It's a little tricky, but it works. 🙂

Pharan

It is quite tricky. If only the keys always had a bit of space above or below it. I usually need to scale by box selecting the summary row first and there's usually something right below the first and last key of the summary row.

ryf9059

Nate wrote
The selection box size is used because it is more flexible. You can scale the whole box or you can scale just keys by making the box just large enough for those keys. To start a selection box exactly on a key, move the mouse just above or below the key, then start to drag. If the key is not selected before doing this, then you'll know the mouse is in the right place when the key is no longer highlighted. It's a little tricky, but it works. 🙂

I agree with Pharan, it's quite tricky. I have a suggestion, when you select a group of key the box automatically snaps its length to the size of the selected key, which is exactly the frame desired, then we can manipulate that box as long as you give enough height to manipulate it.