Skip to content
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

Closed
razcore-rad opened this issue Aug 29, 2017 · 11 comments
Closed

AnimationPlayer usability & improvements discussion #10752

razcore-rad opened this issue Aug 29, 2017 · 11 comments

Comments

@razcore-rad
Copy link
Contributor

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):

  1. 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

  2. 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.

  3. 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 :)

@RandomShaper
Copy link
Member

  1. Yes, that shouldn't happen. I think I know why it does and maybe I can fix it.
  2. Interpolation between cycles is interesting, but indeed not always desirable. Looping mode could be changed from on/off to off/on/on-interp-cycle.
  3. Yes, sometimes it takes a while to get the exact value you want. Improving that would benefit every place an easing editor is present.

@razcore-rad
Copy link
Contributor Author

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:

  • constant extrapolation
  • linear extrapolation
  • make cyclic (what godot is doing by default)
  • and clear cyclic (what blender does by default)

RandomShaper added a commit to RandomShaper/godot that referenced this issue Oct 14, 2017
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.
@RandomShaper
Copy link
Member

  1. Addressed by me (Fix animation before first key #12107).
  2. Already done (don't know by whom nor when).
  3. Addressed by me (Add ability to type easing value for key transition #12113).

@fracteed
Copy link

fracteed commented Oct 16, 2017

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.

@reduz
Copy link
Member

reduz commented Oct 16, 2017 via email

@akien-mga akien-mga added this to the 3.0 milestone Oct 20, 2017
wafemand pushed a commit to wafemand/godot that referenced this issue Oct 24, 2017
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.
@cwook
Copy link

cwook commented Oct 27, 2017

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)
There's an interactive comparison of easing functions here
This issue discusses the ease function, which is related: #10572

@reduz
Copy link
Member

reduz commented Oct 27, 2017 via email

@aaronmzn
Copy link

aaronmzn commented Oct 28, 2017

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

@akien-mga
Copy link
Member

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.

@akien-mga akien-mga modified the milestones: 3.0, 3.1 Jan 8, 2018
@samdze
Copy link
Contributor

samdze commented Mar 16, 2018

A few more suggestions:

  1. I think it should be clear from where every animation of an AnimationPlayer come from. Right now the animation list only displays animation names, but I'm never sure if they are built-in, from another scene or saved in the filesystem. I often end up modifing an animation in one AnimationPlayer and get another AnimationPlayer broken.
  2. In support of point 1 I would like better copy/paste capabilities, like being able to choose between a shallow or deep copy.
  3. Right now assigning an Object as a parameter in a callback in a Call Func Track doesn't work, drag and dropping a resource there locks the mouse in the middle of the window and a restart of Godot is required.

@akien-mga
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants