New Animation Editor (with working mockup)

[rossunger]

Describe the project you are working on

I'm making games.
I'm posting this unfinished animation editor mockup now, because otherwise I may never share what I'm working on with anyone, and I'm about to run out of steam...it's a never-ending project.

Describe the problem or limitation you are having in your project

I find myself remaking the same animation for different characters or objects, because you can't apply the same animation to different nodes.
I often want to make relative animations, e.g. walk right from wherever you are currently... but this isn't possibly without some messy hacks at the moment.
Sometimes when you play an animation in the editor, you can ruin your scene because your starting values weren't saved. The latest solution of having a RESET animation comes with it's own challenges.

there are several usability challenges that make the animation editor hard to use..I've described them in the video, and in the proposed solution below

Describe the feature / enhancement and how it helps to overcome the problem or limitation

These are big new features:
a) The option have keyframe values be relative rather than absolute (please watch video for explanation)
b) Easily change which object or which property is being animated using the inspector. This allows you to reuse the same animation for different objects. Also being able to pipe in variable values into keyframes for IK target style animation (please see video for explanation)
c) A preview context that is separate from the actual scene so that when you edit the animation it doesn't accidentally ruin your actual scene... this is similar to how the theme editor work now.

These are the usability features:
a) Ability to move keyframes between tracks
b) Zoom and scroll the viewport with mousewheel and rightclick and vertical zoom
c) dbl click to add keyframe
d) edit keyframe values and curves in the timeline editor (not the inspector)
e) f to zoom to selected keyframes.
f) vertical zoom to see and edit curves liek with a dopesheet (not implemented yet)

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I have made a mockup using godot :) It's fairly buggy, but it should get the concept across.

here's a link to the github:
https://github.com/rossunger/ExtraAnimationEditor

I've also made a video explaining the key features in case you're having trouble getting it working:
https://www.youtube.com/watch?v=JEL4DzB73Ms

If this enhancement will not be used often, can it be worked around with a few lines of script?

I think this would be used all the time

Is there a reason why this should be core and not an add-on in the asset library?

Animation editor is a core editor feature

[Mickeon]

here's a link to the github:
https://github.com/rossunger/ExtraAnimationEditor

GitHub says this page can't be found, but this sounds promising.

[Zireael07]

Possibly OP forgot to set the repo to public?

[rossunger]

here's a link to the github:
https://github.com/rossunger/ExtraAnimationEditor

GitHub says this page can't be found, but this sounds promising.

Woops! just set it to public. thank you!

[DriNeo]

One day I had problem for animating different sprites with a kind of blinking effect. I found a solution by creating a scene for the animation, then I instanced it in the scenes that needs this animation, then I changed the texture.
I dreamed about a player that animates "types" instead of properties with the ability to "plug" objects properties.
So I'm sure this proposal will be useful.

[AniMesuro]

Oh man this is wonderful! It checks a lot of boxes I felt really lacking on the Vanilla Editor.
I realize it's just a mockup but I do like the way it looks. Is there a chance you're willing to finish it as an addon?
The video editor timeline navigation is my favourite. Through only a scrollbar it's painful to navigate seconds on long animations.

[rossunger]

I can't foresee this being useful as an add-on at the very least for performance issues... I have a sense that some of these features are simple to implement, and I think may have already been implemented in godot 4.0.... I noticed today that you can click the middle mouse button and drag to scroll around!

If someone could help me get started with the c++ codebase I'd be pretty down to put some time into porting some of these features... I've built Godot from source, but I still get all jumbled up trying to navigate the codebase... Lack of experience :p

[AnidemDex]

I really like this proposal, being it a plugin also can helps me with #3468 while it's being converted into a core thing

[2plus2makes5]

I was going to open a proposal for keys with relative values when i found this, so i'm all for it.

My reason for keys with relative values is that in my opinion Tweens are great for single interpolations, but many time i felt that doing the interpolations, especially if complex or more than one, in the AnimationPlayer would have been faster, easier, more precise and could have been part of a more complex animation... so in the end the solution i thought of was keys with relative values.

[Calinou]

@2plus2makes5 Keys with relative values can already be implemented by adding an exported property to a script (whose value is added to the original property in _process()), then animating it with AnimationPlayer:

test_relative_animation.zip

It will work as long as position is being set every frame by the animation (which happens when the animation is playing and there is a position track with keyframes to interpolate between). The object will fly away in the editor while the animation isn't playing, but you can fix this by removing the tool keyword in the script. (If you can think of a way to avoid this, let me know 🙂)

[2plus2makes5]

@Calinou thanks for your precious time!
You are right, relative keys can be already done but in a very specific way, it would be cool to have them to be as easy as absolute keys.
An alternative solution i thought of was to call in the AnimationPlayer a function like this:

func relative_add(var property:String, var value):
	set(property, get(property)+value)
	pass

it's more generic but it would still need to be called each frame.
Another solution that just came in mind while i was writing is to call in AnimationPlayer a function that starts a Tween:

func interpolated_add(var property:String, var add, var duration:=1.0):
	$Tween.interpolate_property(self, property, get(property), get(property)+add, duration)
	$Tween.start()
	pass

this way there's also the interpolation, but in any case you can only see the results while running the scene.

[2plus2makes5]

I had an illumination lol. Relative keys are gamechangers! I'm not kidding they could change the way we make games!

When i saw the video that @rossunger posted and saw the shape on the left continuously going down i thought it was neat but nothing more,... But later i suddenly thought of this scenario, what if we do something like this:

if(Input.is_action_pressed("right")):
       $AnimationPlayer.play("walk")

and in the walk animation with loop enabled we put not only the sprite animation but also the the relative movement of the position.x?
Simple, the result would be that the sprite continuously moves to the right without any code for the movement!

Obviously there would be still the need for code for collisions and other stuff but that's just the first example that came in my mind, i'm sure that people would find amazing ways to use relative keys, after all most of the code that involves numbers is "relative", it's all additions, multiplications etc, rarely we just set a value, now think if many of those operations could be done directly in the AnimationPlayer, a big part of the movement of characters, projectiles, objects etc and many other things involving numbers could be done directly in the editor without code.

Maybe i'm overreacting but i think that relative keys would have an impact way bigger than we imagine. In my opinion relative keys deserve to be discussed on their own. What do you think?

[and-rad]

and in the walk animation with loop enabled we put not only the sprite animation but also the the relative movement of the position.x?
Simple, the result would be that the sprite continuously moves to the right without any code for the movement!

I think you just reinvented root motion. Which comes with its own set of problems when used for locomotion animations, which is why it's not used in most games that aim for responsiveness and reactivity.

[and-rad]

@2plus2makes5 Keys with relative values can already be implemented by adding an exported property to a script (whose value is added to the original property in _process()), then animating it with AnimationPlayer:

This sounds veeery hacky. If I don't annotate every script that contains such a property with @tool, I won't be able to see the animation update in the editor. If I do, then I need to take care that other things that might be happening in the same script do not lead to undesired behavior because it's suddenly running in the editor.

In short, having to declare a script as tool when it's not actually supposed to be used as tool seems like a strong code smell to me.

[2plus2makes5]

I think you just reinvented root motion. Which comes with its own set of problems when used for locomotion animations, which is why it's not used in most games that aim for responsiveness and reactivity.

It wouldn't be the first time i reinvent something that already exists lol, I'm not too familiar with it but IIRC root motion is when in the 3d program you make a walking animation with the character actually moving forward and then in Godot you make it stay in place.

That's not how relative keys works, root motion and relative keys are actually completely unrelated in my opinion.

-first of all in the root motion animation the keys are absolute, if at the beginning the x is 0 and at the end x is 100 then no matter how many times you run the animation the x will always be between 0 and 100, with relative keys at the end of the first animation the x will be 100, the second time x will be 200, the third 300 and so on.

-root animation moves only the model, while with relative keys you can move whatever you want, including the root of the scene where the model is, you could make a walking animation by moving the whole scene while the model is actually walking in place.

-relative keys can be used for any numerical value, not just animation related ones.

[and-rad]

It wouldn't be the first time i reinvent something that already exists lol, I'm not too familiar with it but IIRC root motion is when in the 3d program you make a walking animation with the character actually moving forward and then in Godot you make it stay in place.

Kinda the other way around. In general, root motion is when the animation drives the character's movement. The opposite is when gameplay drives the character's movement and animations are nothing but decoration.

[2plus2makes5]

@and-rad
Got it, thanks :)
Yes it's somewhat like "animation drives the character's movement" but more like "AnimatioPlayer drives the logic of the game".

Relative keys can be for anything, they don't necessarily have to be related to movement or sprites or models and an animation doesn't necessarily have to contain sprite or model data.
Animations could even serve as simil-functions, for example in an absurd and totally useless case instead of writing a function that adds +5 to a certain variable you could call an animation called "add_5" that contains only a single relative key that adds 5 to that variable.

[philippedcote]

I have another suggestion to make to this list:

• When scrubbing the timeline, let us see the value change in real-time on the left side of the timeline (like After Effects) and also inside the Inspector.

That way, it let the user insert a keyframe anywhere between 2 existing keyframes, knowing exactly what the new keyframe value will be.

[CookieBadger]

I can add another use-case for relative keyframes:
In our last game (Godot 3.4), we had animated UI, that would move in from some offset position. The problem was, that the UI would use positions such as screen center and then, setting the position to fixed values would make it unreactive to changes in viewport size. Relative Keyframes in the animation would then just tell it "wherever you are, please move 5px down", and it would still be 5px from the center. We also set paths to animated properties manually to set e.g. only the y coordinate of the position and that was so cumbersome.
By now, I'm sure there are more elegant workarounds for this, but I remember coming into a scene and the animation player constantly messing up the position of some header, because of how it tried to set position absolutely.

[golddotasksquestions]

This is very awesome. I hope as many people as possible watch the demonstration video.

If you watch the video, you will instantly see how liberating these features (many of which are standard in any timeline based key framing tool) would be for Godot users. This proposal contains many long (for years) requested features, such as the ability to easily move keys between tracks, or to assign an animation to multiple nodes, easily copy-paste keys using standard shortcuts (like Ctrl+C, Ctrl+V, Ctrl+X), relative values for keys.

I would also really appreciate to be able to seamlessly switch between curves and standard key editor. Right now I hardly ever use curves, just because how tedious and impeding the workflow is: having to set this as a separate mode when you add the track, and then not being able to see other curve tracks at the same time. It makes using the curve feature pretty much pointless from the Editor.

However there are some things proposed already implemented even in Godot 3 here: The RESET track does exactly what OP is proposing about the "preview" segment in the video about "not having to worry about changing stuff". All you have to do is to make sure you have the default values you want when adding a track, then you never have to worry about it again. If you did not use the default property value while adding the track, you can always change and edit the RESET track at any later point in time like any other animation track.

Another already implemented feature are the relative animation like OP describes them in the video: A target property is changed at runtime and when the animation starts playing, that value is animated from it's dynamic value to a fixed value keyed in the animation track as key. This is currently done by setting the track to "Capture" Update Mode. Maybe OP missed this because in order to see the effect you have to move the first key in the timeline to a later point. Like to second 2, for example.
Still I think proper relative animation which allows users to declare any key as either "absolute" or "relative" value is something we desperately need in the AnimationPlayer. Keys set to "relative" would simply add their value to the current value, instead of replacing the current value completely.

Something I think is a downgrade in this proposal compared to the existing Animation Editor panel is the tracks visuals or value type preview. One of the best features of the AnimationPlayer is how I can instantly see the a preview of color tracks, sprite animation, Call method tracks, audio, etc. Makes it so much easier for the user to visually orient themselves, especially as the animation grows and becomes more complex. Having this preview right in the track is a crazy time saver.
That being said, I totally agree how much it would be an improvement to also see the interpolated numerical values somewhere more clear than the Inspector.

[Calinou]

@DasGandlaf Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

[ashelleyPurdue]

However there are some things proposed already implemented even in Godot 3 here: The RESET track does exactly what OP is proposing about the "preview" segment in the video about "not having to worry about changing stuff". All you have to do is to make sure you have the default values you want when adding a track, then you never have to worry about it again. If you did not use the default property value while adding the track, you can always change and edit the RESET track at any later point in time like any other animation track.

The RESET track is a workaround, not a solution. Instead of solving the problem at its source(IE: making the previewer work with a copy instead of the original), it just forces extra work on the user. Specifically, it forces you to maintain two copies of your starting values in your tscn, and keep them synchronized whenever one of them changes.

The existence of a workaround does not mean we shouldn't push for a proper solution.