Alternative with AnimatedSprite3D

When we were dragging the sprite images around one by one, I thought “There must be an easier way to make breakfast”, and I found one I like better.

A case like ours, where we have a bunch of image files instead of a single sprite sheet image for an animation, seems to be better supported by the AnimatedSprite3D node. It takes sprite animations via a SpriteFrames resource. (In the other case, plain Sprite3D would offer features to split the sheet that we now cannot use.) In the SpriteFrames editor we can bulk-drag all the images for one animation into the Animation Frames panel at once. To play the animations, we would not need an AnimationPlayer then.

But since I expect we might add more animation tracks later (e.g., sound and particles for footsteps), the playback of the AnimatedSprite3D can still be controlled via an AnimationPlayer. I set mine up so that one track sets the animation to be played, another track just does linear interpolation over the frame property, from the first to the last frame number.

I think this approach might be less effort to set up and to maintain, but it depends on the situation.

AnimatedSprite3D docs

(Concerns lecture Adding Player Animations from the Godot 4 C# Action Adventure course.)

2 Likes

I hope this gets easier (quicker) in later lessons. Creating and setting up each keyframe one by one is a real pain. I’m losing interest already. Hopefully, once we get past the 2d-ish 3d sprites, animation will be more intuitive.

1 Like

This is exactly what I want to ask as well. Thank you for the perfect comment and also for the proposition of a possible workflow.

I would like to hear if there is a reason to do it like it is described in the lecture or if what @daberny proposed is the more efficient and time-saving way to do sprite animations without any limitations later.

Therefore, my questions are:
Why are we using Sprite3D + AnimationPlayer instead of AnimatedSprite3D?
Also, why are we using a bunch of image files instead of a single sprite sheet?

Thank you

Good lookin’ out. This lecture demo would be a completely unreasonable workflow when considering a game that might have dozens of characters with several animations each, all running at 30 or 60fps. I don’t mind a lack of sprite sheets–image sequences are easier to generate, anyhow–but all that manual entry would be a dealbreaker. Is there not even a shortcut to move the playhead forward and backward? I keep trying to use After Effects shortcuts because they’re burned into my muscle memory. :sweat_smile:

On Windows, Ctrl-Left/Ctrl-Right seem to move the playhead forward/backward one step. In addition, the playback control buttons have their hotkeys in their tooltips. Maybe this helps.

1 Like

This is a very slow, time consuming way of doing this. Why was this not done using a sprite sheet?

To put it in simple terms, you gotta learn to walk before you start running.

The method shown in the course isn’t the fastest nor the easiest, but it’s the most basic to learn and start from. There are often more than 6 different ways of handling things shown in these kind of course and sticking to the most basic one is more advisable as a learning experience.

Don’t get me wrong, sprite sheet is a really good and simple way of getting things done fast, but it requires a different kind of setup and comes with its own cons.

When learning a craft, it’s always better to learn how to do things in the old slower way before looking up newer & faster ways. I’m not writing that you should do a whole 100+ hours project with that method, but for something fed-to-mouth like this course, it’s just perfect for an exercise of everyone’s brain’s neurons.

This is still in the early-bits of the course.
If this is your first course on this site, you might not be aware of the fact that many course do it this way: first it teaches you how to do this following raw methods, then teaches you how to do it better and faster.

For example, instead of a sprite sheet, you could use an Textures Atlas which is faster, better and more optimized when it comes to Godot. Did you knew that? Or you could generate a list of sprite and attribute them to a new animations created dynamically when the game loads instead of creating an animation for each state and applying manually the sprite on each frame. Takes about 5 min to do if you got the know-how. Why isn’t this explained instead of making us loose our time? The answer: It’s still about how to walk the basics and we’re clearly not running yet.

Theres also such a thing as teaching bad habits…

You don’t have to show all the methods from the beginning, but why not show at least the sprite sheet method along with the drag and drop method? I believe Brackeys recent Godot video just jumps straight into sprite sheets. Personally I absolutely abhor this drag and drop method, and I did lose time to it as I accidentally dragged something where it wasn’t meant to go and broke the animation and had to start again.

“you might not be aware of the fact that many course do it this way” in fact I have seen this before, and its just irritating to go through it again?

Privacy & Terms