godot
godot copied to clipboard
godotengine
Add a Scaling Modifier to scale animation Keys and Markers
Closes https://github.com/godotengine/godot-proposals/issues/3532
Uses ALT Modifier when moving selected to scale selected instead. Pressing CTRL flips snapping (aka if snapping is on it behaves as it were off and vice versa) matching how moving keyframes works.
https://github.com/user-attachments/assets/d361c732-225b-4a40-b19a-673f13a5bb96
I'll find some time to test it though I'm sick right now. If you don't mind a question, does this take into account the curve editor for animation too for scaling of keys. If so, does it work with scaling in both X and Y axis? If so, is there a way to lock it to work with just one axis for precisions (let's say by pressing X or Y to specify a single axis)?
I find this somewhat difficult to use. For example I'd want to stretch 1s animation to 2s:
https://github.com/user-attachments/assets/34001568-93de-4543-b67b-143b22154163
Dragging the keys to the right always shrinks them, so I have to overshoot the animation, then move them back. Also it involves guess work on how much I need to scale, there is no way to scale in fixed increments (steps).
I think scaling should be opposite, i.e. dragging to the right should expand. Or at least there should be modifier to reverse the direction. Not sure about steps though. Maybe there could be another modifier to use animation snapping setting for increments (so e.g. with 0.1 snapping, the scale will increase to 1.1, 1.2, 1.3 etc., instead of linearly). Though some separate step value would be better.
I tried to match how blender behaves when scaling, because its the animation software most users would be familiar with (and it was mentioned in the proposal).
It scaled the animation relative to the cursor (The timeline current time).
https://github.com/user-attachments/assets/f06d7513-bf7c-4be4-9cc9-053819bf399a
I hope you can see the similarities. This PR also tackles a visual bug where right clicking while moving doesn't visually reset keys.
Edit: Similar to blender, holding CTRL while dragging snaps too. Updated the PR description.
Ok I completely missed that it scales from cursor. Makes sense. And snapping seems to be working too.
However I noticed there is some weird line appearing when you Alt+drag:
https://github.com/user-attachments/assets/30fb617b-3173-4c60-9358-f8d3b65e0c2d
Is this intended?
When you try to scale 2 markers, with cursor being at the same position as one of them, the marker might move uncontrollably.
https://github.com/user-attachments/assets/d27e793c-d5bd-4c45-b70d-793c309f2e0d
Notice how it ended up outside timeline, after minimal mouse movement.
Notice how it ended up outside timeline, after minimal mouse movement.
This is intended. it is caused by you moving the mouse cursor really close to the timeline cursor.
https://github.com/user-attachments/assets/4accc213-f7a0-497a-8d55-a3af4c6727f4
Notice how the closer you are to the cursor. the scaling factor increases faster than when farther away.
Yeah but instant jumps aren't very friendly. I didn't catch it in the video, but at some point any mouse movement moved the marker to infinity.
I don't think limiting the scaling factor delta would be a good idea. Notice how keys closer to the cursor need to be scaled with larger delta pixels to still be at the mouse cursor position.
Pixels close to the timeline cursor would have small pixel positions, lets say 30, in order to make them follow the mouse cursor when scaling you have to set its final destination to its position + delta mouse position, which results in 4x or 5x scaling, if we assume the mouse moved only 150 pixels.
Further pixels would scale slower because they need smaller factors as their value is already large so moving from 800 to 950 would need multiplying the position only by about 1.1x.
So pixels at a position of 1 would need multiplying by crazy numbers to follow the mouse cursor.
This is all intended behavior and anything other than that would result in the timeline editor feeling irresponsive. Unless something results in an undefined behavior all of this should be fine. I hope my message came across correctly.
I don't think limiting the scaling factor delta would be a good idea.
I printed the delta out of curiosity and it went up to 12k. Eventually I even managed to make it shoot to infinity.
This makes the markers unusable.
While it's not that easy to trigger unreasonable deltas, it can happen by accident, potentially breaking the animation.
Maybe that can be resolved by making scalings that are from really close to the cursor use a different scaling factor?
@KoBeWi Addressed the issue by making it so that whenever the mouse cursor is too close to pivot, we add a small constant value to increase the difference of the cursors. This seems to work fine, I would be pleased to hear your feedback. Fixed a minor issue where scaling with a negative factor had no effect and instead scaled as if the factor were absolute. The intended behavior was that scaling with a negative factor (i.e. scaling from the left of the animation cursor to the right and vice versa) should reverse the keyframes. Keep that in mind when testing.
This honestly feels kinda unpolished. The scaling of bezier keys follows on Unity's footsteps by showing handles for scaling, and I think scaling for basic keys should do the same.
I kinda do agree, but scaling like this is usually faster and matches with blender, and works well with the already existent Keyframe/Marker move action. I don't know if having handles is necessary. For Bezier curves you're working in 2D space in which scaling shortcuts won't click intuitively with users.
I'd like to hear more of your thoughts on this.
Handles work better because they are more intuitive. Instead of being in a shortcut that the user will not be aware of from the get-go unless they already have experience with it on things like Blender, handles are tangible things they can be interacted with and be can be understood immediately.
Besides, handles and shortcuts aren't mutually exclusive, they can co-exist. But I think handles should be the ones implemented first.
Feedback from animation meeting. We agree the feature of being able to scale animation keyframes is important, but we some UX fixes. Here are some of the notes of what people brought up in the meeting:
- Needs visual feedback. Since there is a comparison to Blender, blender will show a dotted line to the origin of the scale operation.
- By default should scale relative to the midpoint the start and end.
- "stretch operation" for scaling from the start and end from the edge of the bounding box of what is selected (Unity does this).
- Allow negative scale
Needs visual feedback. Since there is a comparison to Blender, blender will show a dotted line to the origin of the scale operation.
I think this should be added too, currently there's no real feedback to transforming.
By default should scale relative to the midpoint the start and end.
Can I have a reason for why is that? I think being able to scale relative to the timeline head, because it allows for more freedom. Maybe we can have those as an option in the animation settings tho.
"stretch operation" for scaling from the start and end from the edge of the bounding box of what is selected (Unity does this).
YeldhamDev did say so and I am convinced. When I get to working on updating this PR this will definitely be the first thing to be added.
Allow negative scale
The current implementation does allow for this by crossing the origin of scaling with the mouse cursor (If starting from the right side of the anchor, negative scaling would occur when moving the mouse cursor to the left side of the anchor). This also matches the blender implementation.
The scale draggers should look something like this, to follow the design of the bezier ones:
This only implements the handles and is still unfinished but I decided to push it for feedback from the animation team and to discuss some bits of the code implementation.
Tried out this PR as I had been working on the same thing without realising you were working on it.
The scaling with the mouse works well, I don't know if the plan was to add both that and the handle scaling. It appears you haven't done much work on the handle scaling yet and I have that mostly done in my PR. Not sure what the best way to proceed is.
Link to my PR. https://github.com/godotengine/godot/pull/112488
