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

Animation sandbox mode #214

Closed
KoBeWi opened this issue Nov 7, 2019 · 2 comments
Closed

Animation sandbox mode #214

KoBeWi opened this issue Nov 7, 2019 · 2 comments

Comments

@KoBeWi
Copy link
Member

KoBeWi commented Nov 7, 2019

Describe the project you are working on:
A Godot game using animations.

Describe the problem or limitation you are having in your project:
Basically this godotengine/godot#812
Every time I edit animation, I have to remember to reset all values afterwards, because when I save scene and run the game, it starts in wrong state. It's even worse when I don't run the game, but just commit changes and push a broken scene.
Recently it has been made worse (#godotengine/godot#33353). Simply clicking AnimationPlayer will cause undoable changes, which is catastrophic if you had some other changes that were unsaved (otherwise you can just revert the scene).

Describe how this feature / enhancement will help you overcome this problem or limitation:
What I'm proposing is sandbox mode for editing animations. Every time you open the Animation tab at the bottom, the sandbox would be automatically enabled. Every change you do in this mode would be reverted upon closing Animation tab. This way you can freely edit animations without your scene being affected. Of course the currently selected AnimationPlayer should not be affected itself, to allow editing its properties and animations.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:
image

Describe implementation detail for your proposal (in code), if possible:
The Animation tab should already have some signal/callback for being opened and closed. So it's about storing the current state of the scene upon opening the tab and restoring it upon closing.

The biggest problem of this proposal is how to correctly store the state. Dump all properties of every node in the scene? Or just track changed properties and revert only them? Or revert the whole scene after done editing the animation? First option might have problems with big scenes, second one will most likely be unreliable and last one... you'd need to save your scene before editing animation, unless we introduced some temporary file that stores current edited state.

Anyways, this is definitely doable.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
This will be used by anyone using animations, so like 99% Godot users.

Is there a reason why this should be core and not an add-on in the asset library?:
It's a crucial part of animation system.

@hammeron-art
Copy link

Same problem with AnimationTrees.

Or just track changed properties and revert only them?

I don't think this would be unreliable. It makes sense to store and revert only what changed.

Godot already has convenient code to implement a sandbox. The editor can backup the original state of a node using SceneState and revert when required.

The Animation tab should already have some signal/callback for being opened and closed. So it's about storing the current state of the scene upon opening the tab and restoring it upon closing.

Also any operation that writes the scene to disk such as building and saving.

@akien-mga
Copy link
Member

We discussed this with core developers yesterday and decided that a better system would be to auto-key original values in a dedicated "RESET" track, which can be used by the engine to automatically reset properties to what you want serialized.

Superseded by #1597.

@aaronfranke aaronfranke closed this as not planned Won't fix, can't repro, duplicate, stale Sep 18, 2022
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

5 participants