Hi all,
I am having a bit of dilemma on how to approach the following problem. Sprites that I use in my game are 1024x1024 and the animations are 60 FPS. Throughout the development of the game and while I was using placeholder art, I have used AnimationTree + AnimationPlayer to animate stuff, which was fine since the art had like 2-3 FPS.
Now, while that was no trouble, manually entering 60 frames for each second of animation of each character sounds like A LOT of trouble. Initially I tried making a huge spritesheet and handling it like that, which would be slightly easier then manually changing the texture each time. The spritesheet was too large, however, and couldn't be imported. I guess I could try to evolve this approach and make smaller spritesheets for each animation sequence, but it might be tight for some longer animations.
So, next I tried to make some sort of Frankenstein of AnimationTree + AnimationPlayer + AnimatedSprite2D, where the AnimationPlayer would dictate the frames of the AnimatedSprite2D. In the AnimationPlayer I would set the animation property of AnimatedSprite2D to the desired animation. This behaved pretty weirdly, since the actual animation wouldn't trigger during the AnimatedPlayer's animation, but it did as soon as it finished. I also tried setting the frames property of AnimatedSprite2D during the AnimatedPlayer's animation, which worked - but another animation played right after it finished.
I assume this is because the player from AnimationPlayer and AnimatedSprite2D are clashing for some weird reason. I also tried stopping the AnimatedSprite2D both through code and through animation and in various points, with no luck.
It is also inconvenient for me to just use AnimatedSprite2D, as AnimationTree and AnimationPlayer are just a much more powerful combination.
I was toying with the idea to just change textures of Sprite2D through some sort of function in a script which I would call at the beginning of animation in AnimationPlayer.

Sorry for the long post everyone 😃.
Anyways - does anyone have any ideas how I could approach this?

  • xyz replied to this.

    xyz I actually managed to solve it in the meantime with the idea that I mentioned at the end:

    I was toying with the idea to just change textures of Sprite2D through some sort of function in a script which I would call at the beginning of animation in AnimationPlayer.

    Basically I have a dictionary linking animation name to a directory holding all frames. I load these frames on _ready, and map it in another dictionary to said animation name. Then in AnimationPlayer, I just call the function with the animation name and the desired duration of the animation.
    I assume it would be better performance wise to preload these in the future?

    Anyway, here's one of the sprites so I don't end up uploading a huge amount 😃.

    • xyz replied to this.

      Perfex This shouldn't be handled via a single sprite. Instead, use skeletal or just plain forward kinematics animation with multiple sprites.

        xyz Could you elaborate what you meant here?
        The sprite I sent is one of the frames of the animation I made in Synfig Studio. If you are saying that because of the simplicity of the sprite - its a placeholder, but the final sprite and animation will require a bit more tuning and mixing of frame by frame animation and skeletal animation. Most likely, I will require the morphing feature of Synfig Studio as well.
        I think it would look quite messy if I tried to do it through Godot (if its even possible). Either way, it seems like Synfig Studio provides a bit more options for animating than Godot, but I am no expert so please correct me if I am wrong

          xyz Also, in your opinion, what are the drawbacks of using this type of animation that I am using?
          Hypothetically, if I only required skeletal animation, I assume the approach you suggested would save quite a lot of memory both during runtime and in terms of size of the game.

          • xyz replied to this.

            Perfex Also, in your opinion, what are the drawbacks of using this type of animation that I am using?

            It will eat up vram quite quickly. Calculate it. One 1024x1024 rgba bitmap is 4 megs. Maybe a bit less if you use vram compression. Multiply that with the total number of frames you plan to have in the game and that's the amount of memory you'll consume on the gpu. This is extremely wasteful especially with so many whitespace pixels that could have been used to store other bitmap data.

            This is normally done with every body part being a separate sprite. That would also make collider management and animation much easier.

              xyz You have a valid point.
              In that case, do you have any suggestions on how to handle a more complex animation that doesn't involve just skeletal animation?
              I did some research and came across a Spine to Godot integration - do you think that doing the animation in Spine project and then importing that project into Godot would solve these memory issues?
              The problem here is that Spine is quite expensive of course 😃

              • xyz replied to this.

                Perfex Depends what you mean by "more complex animation". The main idea here is to minimize the vram consumption by not wasting it on blank pixels, or stuff that repeats or stuff that can be animated via linear transformations (translation, rotation, scaling). Of course, if you want to have non linearly animated parts other than standard skin deformations, like morphing or motion blurring, you obviously need to do it via frame-by-frame animation, but it's best to isolate such parts into smallest possible bitmaps and include them as separately animated sprites into overall multi sprite hierarchy of your character.

                Perfex Could you elaborate what you meant here?

                It's worth a note here that @xyz is suggesting skeletal animation here because this specific example sprite you've provided lends itself well to a skeletal cutout animation. If you were dealing with something like CupHead style sprites & animation the discussion would be very different.

                • xyz replied to this.

                  Megalomaniak I hinted on plain node hierarchy fk as well. The important thing is to cleverly break the character down into multiple parts and animate them in the most appropriate/economic way, possibly mixing the animation techniques. Even cuphead likely does that. Those long noodle arms are surely not in the same bitmap with the head etc.

                    xyz @Megalomaniak In that case, I suppose some blend of frame-by-frame animated character parts with skeletal animation in Godot could do the trick in this case.
                    This was a very helpful discussion I must admit.
                    Thanks a lot 😃, I will most likely try out the Godots skeletal animation along with the frame-by-frame animation for parts in the end and see how it goes!