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

Update AnimationPlayer in real-time when keyframe properties change #9686

Closed
dnllowe opened this issue May 5, 2024 · 2 comments · Fixed by godotengine/godot#91599
Closed

Comments

@dnllowe
Copy link

dnllowe commented May 5, 2024

Describe the project you are working on

I'm working on a 2D idle / auto rpg battler. There are different animations, weapons, and equipment, and updating various collision boxes in sync with the animations and equipped items is necessary.

Describe the problem or limitation you are having in your project

When animating properties, the AnimationPlayer does not reflect the changes immediately. This leads to guesswork and a tedious back and forth of editing a property, clicking the timeline to see what it looks like, and repeating until it's correct.

Example:

before-animation-player-realtime-update.mp4

I have seen this issue brought up, but no resolution / implementation for it:

godotengine/godot#76606
godotengine/godot#76785
godotengine/godot#91476

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

I would like the AnimationPlayer to update in real-time when properties of the selected form change in value. This provides immediate feedback and speeds up the workflow and syncing and adjusting various properties to a sprite's animation.

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

  1. When a property of type value is changed in AnimationTrackKeyEdit::_set, I will seek to the current animation position to update the visual representation in the editor in real-time:
AnimationPlayer *player = AnimationPlayerEditor::get_singleton()->get_player();
player->seek(player->get_current_animation_position(), true, true);
  1. When changing keyframes by clicking on the keyframe in the timeline from AnimationTrackEdit::_try_select_at_ui_pos, the timeline will move to that position to immediately show how the state of the animation looks at that keyframe. I know it's possible to move the track from above, but a more natural workflow is to click on the keyframe I want to edit, and then I will want to see how everything looks at that moment in time:
AnimationPlayer *player = AnimationPlayerEditor::get_singleton()->get_player();
player->seek(moving_selection_pivot, true, true);
emit_signal(SNAME("timeline_changed"), moving_selection_pivot, false);

The resulting behavior is now:

after-animation-player-realtime-update.mp4

I have a branch with the changes ready here:
https://github.com/godotengine/godot/compare/master...dnllowe:godot:realtime-animation-player-property-updates?expand=1

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

I think this will be used commonly by anyone using the AnimationPlayer

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

The AnimationPlayer and its behavior is core to the engine.

@Calinou
Copy link
Member

Calinou commented May 6, 2024

This makes a lot of sense. I've been wanting this for a while, but wasn't sure if there were some use cases where this would be counterproductive – I can't think of any right now.

@dnllowe
Copy link
Author

dnllowe commented May 6, 2024

This makes a lot of sense. I've been wanting this for a while, but wasn't sure if there were some use cases where this would be counterproductive – I can't think of any right now.

I wondered if there could have been a negative performance impact, but I didn't notice any. Otherwise, having worked with other engines and similar features in video and audio software, it felt very natural to have this behavior by default.

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

Successfully merging a pull request may close this issue.

4 participants