-
-
Notifications
You must be signed in to change notification settings - Fork 21.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AnimationPlayer usability & improvements discussion #10752
Comments
|
Actually if I think about it, blender has a way to modify the loop behavior (extrapolate). So in the F-Curves editor for example, the animation can be set between:
|
Prior to this, the value assumed for the interval between the start of the track and the first frame would be the one of the first key if - *seeking/playing a continuous track*; - *seeking a discrete track*. And the first key would be ignored until reached -thus not modifying the target property/transform- in the remaining case; namely, *playing a discrete track*. In other words, the inner workings of the animation system considered the unreached first key for interpolation but not for a query of every key inside a time range. With this changes, the first key is only considered is the animation is looped and ignored otherwise. That way, in order to have a start value, you'll need an explicit key at the very beginning of the track, while having the flexibility of the animation player not touching the target value until the first key is reached. This corresponds to the point 1) of godotengine#10752.
|
One of the main issues I keep running into is the inflexibility of the step value. Currently it can only be set to 2 decimal points which makes it impossible to set for 30 fps. You could set it to animate at 20fps(0.05) or 25fps(0.04) but these are not good values when your target game fps is likely 60fps. Not sure what a good solution for this is, as how many decimal points to approximate 1/30 is needed? Maybe a mode where you can use a fps value and animate on frames would be ideal. |
1. Agreed, this should only work as you describe if interpolated loop is
enabled.
2. You can choose this behavior per track
3. Yeah makes sense
Regarding step, i think we should have a button to switch between step and
fps, since they are pretty much the same.. and edit the animations in both
modes.
I have a long list of usability improvements for this, but was waiting for
after 3.0 to work on them..
…On Oct 15, 2017 9:15 PM, "James Redmond" ***@***.***> wrote:
One of the main issues I keep running into is the inflexibility of the
step value. Currently it can only be set to 2 decimal points which makes it
impossible to set for 30 fps. You could set it to animate at 20fps(0.05) or
25fps(0,04) but these are not good values when your target game fps is
likely 60fps.
Not sure what a good solution for this is, as how many decimal points to
approximate 1/30 is needed. Maybe a mode where you can use a fps value and
animate on frames would be ideal.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#10752 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF-Z2zZEZmyxHPj5LeYh2xQ-L8sFzZ8mks5ssqAQgaJpZM4PFvZ1>
.
|
Prior to this, the value assumed for the interval between the start of the track and the first frame would be the one of the first key if - *seeking/playing a continuous track*; - *seeking a discrete track*. And the first key would be ignored until reached -thus not modifying the target property/transform- in the remaining case; namely, *playing a discrete track*. In other words, the inner workings of the animation system considered the unreached first key for interpolation but not for a query of every key inside a time range. With this changes, the first key is only considered is the animation is looped and ignored otherwise. That way, in order to have a start value, you'll need an explicit key at the very beginning of the track, while having the flexibility of the animation player not touching the target value until the first key is reached. This corresponds to the point 1) of godotengine#10752.
Here's another issue talking about Animations: #11359 My suggestion to improve AnimationPlayers is an additional transition curve known as spring/elastic. It's helpful for animating natural movements with few keyframes, as it's a fairly realistic interpretation of how living things move. A good demonstration of using spring/elastic easing to speed up procedural animation: David Rosen Procedural Animation GDC (See also 17:42) |
I will be working on this the next weeks, so any feedback will be very
welcome.
…On Fri, Oct 27, 2017 at 7:32 PM, cwook ***@***.***> wrote:
Here's another issue talking about Animations: #11359
<#11359>
My suggestion to improve AnimationPlayers is an additional transition
curve known as spring/elastic. It's helpful for animating natural movements
with few keyframes, as it's a fairly realistic interpretation of how living
things move.
A good demonstration of using spring/elastic easing to speed up procedural
animation: David Rosen Procedural Animation GDC
<https://youtu.be/LNidsMesxSE?t=7m39s> (See also 17:42)
There's an interactive comparison of easing functions here
<http://easings.net/>
This issue discusses the ease function, which is related: #10572
<#10572>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10752 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF-Z27xf_4qTEheqpqKsaLzamZ3naKaNks5swlnugaJpZM4PFvZ1>
.
|
for frame by frame animations I prefer changing the Frames per second (fps) value like in AnimatedSprite or the animation speed with a Duration per frame (milliseconds) value like in Aseprite (even better) AnimationPlayer is not meant to be used for frame by frame animations. Even if you give the option to change the speed with a single value, you will be dealing with moving keyframes through the timeline and that's not needed for sprite animations AnimatedSprite node is better for that job but its lacks features (like the keyframing feature or sprite sheet support) I suggest separating AnimationPlayer node to be focused only for what is made for, cutouts animations / tweening and leaving AnimatedSprites node for frame by frame animations adding the keyframing feature and sprite sheet support this way AnimationPlayer wont be overflowed with features that some people may never use (like me with sprite animations) I opened an issue about this here it is #12469 |
We have now entered release freeze for Godot 3.0 and want to focus only on release critical issues for that milestone. Therefore, we're moving this issue to the 3.1 milestone, though a fix may be made available for a 3.0.x maintenance release after it has been tested in the master branch during 3.1 development. If you consider that this issue is critical enough to warrant blocking the 3.0 release until fixed, please comment so that we can assess it more in-depth. |
A few more suggestions:
|
AnimationPlayer was rewritten from scratch for 3.1 and has tons of UX improvements. I'll close this issue as it's no longer relevant as is, but if some of its points are still relevant in the current master branch, feel free to open new issues specific to each of them. |
Operating system or device, Godot version, GPU Model and driver (if graphics related):
Ubuntu 17.04 - Godot v3.0.alpha.custom_build.3ae1cff
I feel like the animation player is not intuitive at all. I propose to make it work like blender. Eg, things I found that don't make sense (some might be bugs):
some properties are modified even if the play cursors hasn't reached the keyframe. For example, take canvas modulate, and insert only one keyframe say at second 3 and change the color to something other than white (say red). Start the game with canvas modulate color at pure white. It turns out that the canvas modulate will be red immediately, even though there's no key to change it to red at 0! The position on the other hand behaves correctly, that is if you insert a key at second 3 and there's no other keyframe before that, then the object won't move until second 3 is reached. I've only tried a handful of properties but so far the only reasonable behavior is on position
if loop is turned on don't try to interpolate between last keyframe (before the animation finishes) and the first keyframe. Instead let's follow the blender way, so if I have a sprite that moves from left to right and only 2 keyframes, one at T0 and one at T1 and animation length of 2 seconds with loop turned on, I expect sprite to move only between T0 and T1. How it's implemented at the moment is, if loop is on, then there will be an interpolation between T1 and T0 as well (from second 1 and second 2). I think this isn't intuitive. Blender has some pretty good standards, if they do it that way they probably have a good reason why.
would be great if we could be able to type a number in the
Transition
panel instead of just relying on the mouse to move the easing around.If you guys can think of anything else let the discussion begin :)
The text was updated successfully, but these errors were encountered: