AnimationTreePlayer filters need to be more usable

[slapin]

Together with AnimationTree player there are ainmation filters which allow us to fight importer stupidity a bit and have more control over animation blends.

These filters are really something not known to general public and are not that easy to grasp and use. The obvious use case is - you imported breathe animation, and you want to add it to walk, idle, and sit down animation. But as importer imports all bones, the animation will blend not only changed bones, but also unchanged ones, which lead to invalid/strange blends, like half-sitting man, etc. Filter allows choice which animation tracks to include in blend.

I think this should be re-shufled. We need separate filter node, which gets animation in (after whatever nodes on its path) and gives out animation with tracks removed. All other blend support can be removed from UI then. Also we need nice clean UI to edit animations filters with many tracks. Otherwise, these could be exported/imported to/from text format like json or plain lines of text. Ideas?

@JoshuaGrams I think you might share your ideas about this.

[JoshuaGrams]

We're just doing 2D animation and entirely in Godot, so we have only made the tracks that we need. I'd want to know what an animator's workflow looks like and see what they actually need and how we can support that. What do other tools do? etc. But I gather from my artist brother that in films they generally animate every frame manually, so I don't know how much existing experience there is to draw on...

I'm fairly sure that the other blend support is still useful. Are you really suggesting that we remove it? We blend from stand to walk to run, for instance, and those all need to affect the same bones. And...when running our character holds his sword over his shoulder and his hands/sword bob a bit, but those obviously need to be animated by the attack as well, so those need to be blended. MechWarrior 4 (?) used blending to have their mechs walk in different directions, uphill/downhill/sidehill, etc.

I do understand that in many cases you can get by without blending by animating only selected bones.

As for UI...I think the UI in general is pretty terrible, but I would prefer to move more functionality into a common core that all animation tree nodes inherit from and to have fewer special purpose nodes. I think you should be able to seek any animation, for instance, and possibly set its time scale as well. In this tree, for instance, almost half the nodes would become unnecessary and the purpose might be clearer.

I agree that the options aren't very visible, and I think that if we removed the unnecessary info from the nodes display the settings could be visible all the time rather than hidden in a pop-up dialog. But maybe we still need the special-purpose nodes to make things more visible.

I gather there are plans afoot to give the editor an overhaul this year (?) and I don't know who's working on that or where they're going with it. Would this fit in with what they're doing? A temporary work-around might be to write a decent article for the docs about the animation options. Something like the 2D physics overview, which is pretty great. I dunno.

[slapin]

I don't tell about blend here. Blends are useful. I tell about filters.

Currently you setup filters for each node individually in each node.

Usability-wise it is a mess.

I think we need to create separate node type which is used for filters, and drop filters from all other nodes.

This can be done in multiple steps.

1. Implement just-filter node for blends, should filter any tracks passing through it however they were transferred before. 1a. make usable interface for it (not one we have now).
2. As this one works, remove all filter support from all other nodes. This will make this stuff easier to use and understand. Current interface is really messy.

About the workflow - of course this is usable for imported scenes (3D) where you import prepared skeletal animation actions and basically you want to drive them through ATP to blennd/make motions better. Actually making full-frame animations is traditional old way, which is not suitable for games, as games are much more interactive than movies, also people do not want to make each animation, they want to make pieces and blend them together. Also current tendency is to make procedural cyclic animations for walks, runs etc., where physics works together with many other things, which makes them respect terrains, etc. It is impossible to make good animation for game the traditional old way (unless you present your game as movie and make animation for each case, which might require thousands of them). This is good helper to make your game release next year, not next century, especially for small teams.

On Fri, Apr 15, 2016 at 4:15 PM, Joshua Grams notifications@github.com wrote:

We're just doing 2D animation and entirely in Godot, so we have only made the tracks that we need. I'd want to know what an animator's workflow looks like and see what they actually need and how we can support that. What do other tools do? etc. But I gather from my artist brother that in films they generally animate every frame manually, so I don't know how much existing experience there is to draw on...

I'm fairly sure that the other blend support is still useful. Are you really suggesting that we remove it? We blend from stand to walk to run, for instance, and those all need to affect the same bones. And...when running our character holds his sword over his shoulder and his hands/sword bob a bit, but those obviously need to be animated by the attack as well, so those need to be blended. MechWarrior 4 (?) used blending http://www.gamasutra.com/view/feature/131863/animation_blending_achieving_.php to have their mechs walk in different directions, uphill/downhill/sidehill, etc.

I do understand that in many cases you can get by without blending by animating only selected bones.

As for UI...I think the UI in general is pretty terrible, but I would prefer to move more functionality into a common core that all animation tree nodes inherit from and to have fewer special purpose nodes. I think you should be able to seek any animation, for instance, and possibly set its time scale as well. In this tree, for instance, almost half the nodes would become unnecessary and the purpose might be clearer.

[image: animation-tree] https://cloud.githubusercontent.com/assets/39438/14562226/7655bde8-02e9-11e6-9de4-2123ce5cb469.png

I agree that the options aren't very visible, and I think that if we removed the unnecessary info from the nodes display the settings could be visible all the time rather than hidden in a pop-up dialog. But maybe we still need the special-purpose nodes to make things more visible.

I gather there are plans afoot to give the editor an overhaul this year (?) and I don't know who's working on that or where they're going with it. Would this fit in with what they're doing? A temporary work-around might be to write a decent article for the docs about the animation options. Something like the 2D physics overview, which is pretty great. I dunno.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4314#issuecomment-210460586

[slapin]

If you want to reshuffle core, one of my old ideas was to make ATP not require a hundred of animation copies for different purposes, but live from one, hiding copying from user, this should de-clutter node editor quite well.

On Sat, Apr 16, 2016 at 1:13 AM, Sergey Lapin slapinid@gmail.com wrote:

I don't tell about blend here. Blends are useful. I tell about filters.

Currently you setup filters for each node individually in each node.

Usability-wise it is a mess.

I think we need to create separate node type which is used for filters, and drop filters from all other nodes.

This can be done in multiple steps.

1. Implement just-filter node for blends, should filter any tracks passing through it however they were transferred before. 1a. make usable interface for it (not one we have now).
2. As this one works, remove all filter support from all other nodes. This will make this stuff easier to use and understand. Current interface is really messy.

About the workflow - of course this is usable for imported scenes (3D) where you import prepared skeletal animation actions and basically you want to drive them through ATP to blennd/make motions better. Actually making full-frame animations is traditional old way, which is not suitable for games, as games are much more interactive than movies, also people do not want to make each animation, they want to make pieces and blend them together. Also current tendency is to make procedural cyclic animations for walks, runs etc., where physics works together with many other things, which makes them respect terrains, etc. It is impossible to make good animation for game the traditional old way (unless you present your game as movie and make animation for each case, which might require thousands of them). This is good helper to make your game release next year, not next century, especially for small teams.

On Fri, Apr 15, 2016 at 4:15 PM, Joshua Grams notifications@github.com wrote:

We're just doing 2D animation and entirely in Godot, so we have only made the tracks that we need. I'd want to know what an animator's workflow looks like and see what they actually need and how we can support that. What do other tools do? etc. But I gather from my artist brother that in films they generally animate every frame manually, so I don't know how much existing experience there is to draw on...

I'm fairly sure that the other blend support is still useful. Are you really suggesting that we remove it? We blend from stand to walk to run, for instance, and those all need to affect the same bones. And...when running our character holds his sword over his shoulder and his hands/sword bob a bit, but those obviously need to be animated by the attack as well, so those need to be blended. MechWarrior 4 (?) used blending http://www.gamasutra.com/view/feature/131863/animation_blending_achieving_.php to have their mechs walk in different directions, uphill/downhill/sidehill, etc.

I do understand that in many cases you can get by without blending by animating only selected bones.

As for UI...I think the UI in general is pretty terrible, but I would prefer to move more functionality into a common core that all animation tree nodes inherit from and to have fewer special purpose nodes. I think you should be able to seek any animation, for instance, and possibly set its time scale as well. In this tree, for instance, almost half the nodes would become unnecessary and the purpose might be clearer.

[image: animation-tree] https://cloud.githubusercontent.com/assets/39438/14562226/7655bde8-02e9-11e6-9de4-2123ce5cb469.png

I agree that the options aren't very visible, and I think that if we removed the unnecessary info from the nodes display the settings could be visible all the time rather than hidden in a pop-up dialog. But maybe we still need the special-purpose nodes to make things more visible.

I gather there are plans afoot to give the editor an overhaul this year (?) and I don't know who's working on that or where they're going with it. Would this fit in with what they're doing? A temporary work-around might be to write a decent article for the docs about the animation options. Something like the 2D physics overview, which is pretty great. I dunno.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4314#issuecomment-210460586

[slapin]

i.e. having Animation node with multiple outputs, each associated with separate copy of Animation resource. Should be easy enough to do.

On Sat, Apr 16, 2016 at 1:16 AM, Sergey Lapin slapinid@gmail.com wrote:

If you want to reshuffle core, one of my old ideas was to make ATP not require a hundred of animation copies for different purposes, but live from one, hiding copying from user, this should de-clutter node editor quite well.

On Sat, Apr 16, 2016 at 1:13 AM, Sergey Lapin slapinid@gmail.com wrote:

I don't tell about blend here. Blends are useful. I tell about filters.

Currently you setup filters for each node individually in each node.

Usability-wise it is a mess.

I think we need to create separate node type which is used for filters, and drop filters from all other nodes.

This can be done in multiple steps.

1. Implement just-filter node for blends, should filter any tracks passing through it however they were transferred before. 1a. make usable interface for it (not one we have now).
2. As this one works, remove all filter support from all other nodes. This will make this stuff easier to use and understand. Current interface is really messy.

About the workflow - of course this is usable for imported scenes (3D) where you import prepared skeletal animation actions and basically you want to drive them through ATP to blennd/make motions better. Actually making full-frame animations is traditional old way, which is not suitable for games, as games are much more interactive than movies, also people do not want to make each animation, they want to make pieces and blend them together. Also current tendency is to make procedural cyclic animations for walks, runs etc., where physics works together with many other things, which makes them respect terrains, etc. It is impossible to make good animation for game the traditional old way (unless you present your game as movie and make animation for each case, which might require thousands of them). This is good helper to make your game release next year, not next century, especially for small teams.

On Fri, Apr 15, 2016 at 4:15 PM, Joshua Grams notifications@github.com wrote:

We're just doing 2D animation and entirely in Godot, so we have only made the tracks that we need. I'd want to know what an animator's workflow looks like and see what they actually need and how we can support that. What do other tools do? etc. But I gather from my artist brother that in films they generally animate every frame manually, so I don't know how much existing experience there is to draw on...

I'm fairly sure that the other blend support is still useful. Are you really suggesting that we remove it? We blend from stand to walk to run, for instance, and those all need to affect the same bones. And...when running our character holds his sword over his shoulder and his hands/sword bob a bit, but those obviously need to be animated by the attack as well, so those need to be blended. MechWarrior 4 (?) used blending http://www.gamasutra.com/view/feature/131863/animation_blending_achieving_.php to have their mechs walk in different directions, uphill/downhill/sidehill, etc.

I do understand that in many cases you can get by without blending by animating only selected bones.

As for UI...I think the UI in general is pretty terrible, but I would prefer to move more functionality into a common core that all animation tree nodes inherit from and to have fewer special purpose nodes. I think you should be able to seek any animation, for instance, and possibly set its time scale as well. In this tree, for instance, almost half the nodes would become unnecessary and the purpose might be clearer.

[image: animation-tree] https://cloud.githubusercontent.com/assets/39438/14562226/7655bde8-02e9-11e6-9de4-2123ce5cb469.png

I agree that the options aren't very visible, and I think that if we removed the unnecessary info from the nodes display the settings could be visible all the time rather than hidden in a pop-up dialog. But maybe we still need the special-purpose nodes to make things more visible.

I gather there are plans afoot to give the editor an overhaul this year (?) and I don't know who's working on that or where they're going with it. Would this fit in with what they're doing? A temporary work-around might be to write a decent article for the docs about the animation options. Something like the 2D physics overview, which is pretty great. I dunno.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4314#issuecomment-210460586

[JoshuaGrams]

Ah, OK. In your original post you said:

All other blend support can be removed from UI then.

That's the only reason I was talking about blending. But I guess that was a typo and you meant to say filter support.

Currently the code doesn't know anything about which tracks which "pass through" a given node. That would require re-working the core data structures/data flow of the blending algorithm, which may be a good idea anyway, but...

It also doesn't really know about tracks affecting values in a tree. So to do something like UE4's Layered blend node where you can blend only tracks that affect a given bone and its descendants you would have to check the NodePath of each track to see if it's a descendant, and that code doesn't exist yet either.

So. It's possible, but probably not soon. It's one more argument for rewriting the whole ugly mess though...

[slapin]

By this I meant to remove filters support from all blend nodes. No, I did not mean to do fancy stuff now, I just think about making filters a separate "node". This is more logical and look much more usable. This doesn't affect core too much yet.

About other things, I think they are just to be discussed and done, no reason for waiting for something, as that something won't happen just by itself.

On Sun, Apr 17, 2016 at 2:05 PM, Joshua Grams notifications@github.com wrote:

Ah, OK. In your original post you said:

All other blend support can be removed from UI then.

That's the only reason I was talking about blending. But I guess that was a typo and you meant to say filter support.

Currently the code doesn't know anything about which tracks which "pass through" a given node. That would require re-working the core data structures/data flow of the blending algorithm, which may be a good idea anyway, but...

It also doesn't really know about tracks affecting values in a tree. So to do something like UE4's Layered blend node https://youtu.be/C16vlfe3pXc?t=3m59s where you can blend only tracks that affect a given bone and its descendants you would have to check the NodePath of each track to see if it's a descendant, and that code doesn't exist yet either.

So. It's possible, but probably not soon. It's one more argument for rewriting the whole ugly mess though...

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4314#issuecomment-211001208

[slapin]

And I'd prefer controlled evaluational changes step-by-step than blunt rewrite, as the later could become endless. I think the core changes should be done in planned small steps.

On Sun, Apr 17, 2016 at 4:57 PM, Sergey Lapin slapinid@gmail.com wrote:

By this I meant to remove filters support from all blend nodes. No, I did not mean to do fancy stuff now, I just think about making filters a separate "node". This is more logical and look much more usable. This doesn't affect core too much yet.

About other things, I think they are just to be discussed and done, no reason for waiting for something, as that something won't happen just by itself.

On Sun, Apr 17, 2016 at 2:05 PM, Joshua Grams notifications@github.com wrote:

Ah, OK. In your original post you said:

All other blend support can be removed from UI then.

That's the only reason I was talking about blending. But I guess that was a typo and you meant to say filter support.

Currently the code doesn't know anything about which tracks which "pass through" a given node. That would require re-working the core data structures/data flow of the blending algorithm, which may be a good idea anyway, but...

It also doesn't really know about tracks affecting values in a tree. So to do something like UE4's Layered blend node https://youtu.be/C16vlfe3pXc?t=3m59s where you can blend only tracks that affect a given bone and its descendants you would have to check the NodePath of each track to see if it's a descendant, and that code doesn't exist yet either.

So. It's possible, but probably not soon. It's one more argument for rewriting the whole ugly mess though...

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4314#issuecomment-211001208

[JoshuaGrams]

Yeah, it would probably be better to do it step-by-step. There's just such a long way to go... :(

And I just realized that it does pass the filter track list through the _process_node recursion, so yeah, implementing a separate filter node would be simple enough. And it's only currently on Oneshot and Blend2 (but Blend2 doesn't have the UI stuff), so there's only a couple of places to remove it. You can just copy the code from OneShot and then it's mostly UI work. A better filter UI would be worse, but again, you could probably hack it in so it mostly works with the existing code...

But I think I'm about done with Godot. Everything about it is so poorly designed and implemented that it's really depressing to work on. I'll try and do a bunch of commenting/documentation to make the AnimationTree code easier to get started with, but I've sketched out my own engine and from now on I'm going to focus on getting it to the point where we can import our game to that.

[slapin]

Well, Godot engine got a community now, it is several people, but it is something, so I hope things will be in motion, I like many changes done, the editor is much more stable now, and many other small things are done.

It is good learning exerience as people with various interesting backgrounds appear and suggest interesting things. Godot is a good thing to play with, as you can setup and run things very quickly, unlike other OpenSource engines. For commercial ones, both UE and Unity5 are really complicated and have some policies preventing me from depending on them, and I don't have any commercial interests in gamedev field to be interested in using these.

Of course Godot got a lot of kindergarten problems, but I'd like to see how these are fixed, I will see patches and learn from them. Also I can add my $.05 from time to time. It is good to have some side project as hobby, which is entirely different from my field of experience, and close enough for me to be involved, so I really want to see what will happen and do what I can do to make it happen.

On Mon, Apr 18, 2016 at 3:35 PM, Joshua Grams notifications@github.com wrote:

Yeah, it would probably be better to do it step-by-step. There's just such a long way to go... :(

And I just realized that it does pass the filter track list through the _process_node recursion, so yeah, implementing a separate filter node would be simple enough. And it's only currently on Oneshot and Blend2 (but Blend2 doesn't have the UI stuff), so there's only a couple of places to remove it. You can just copy the code from OneShot and then it's mostly UI work. A better filter UI would be worse, but again, you could probably hack it in so it mostly works with the existing code...

But I think I'm about done with Godot. Everything about it is so poorly designed and implemented that it's really depressing to work on. I'll try and do a bunch of commenting/documentation to make the AnimationTree code easier to get started with, but I've sketched out my own engine and from now on I'm going to focus on getting it to the point where we can import our game to that.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4314#issuecomment-211359689

[akien-mga]

The whole AnimationTreePlayer is queued for a rewrite by @reduz, probably for the 3.1 release. I'm not familiar with ATP myself so I'm not sure to what extent it will address the issues outlined here, but I think @reduz has a pretty good idea of what he wants to implement already to replace ATP.

[akien-mga]

AnimationTreePlayer is deprecated in Godot 3.1 and will be removed in Godot 3.2. It is replaced by AnimationTree, which was written from scratch and likely fixes/deprecates this issue.

If the issue is still relevant in some form with AnimationTree in Godot 3.1, please open a new issue about it (potentially linking this one if there is relevant discussion to keep track of).