AnimatedTexture sprite sheet support

[TheDuriel]

Godot version:

3.1

Issue description:

AnimatedTexture is not capable of using AtlasTextures for its frames. When loading an AtlasTexture the animation will stop, and the entire first frame displays.

Steps to reproduce: Create an AnimatedTexture with four frames. Make each frame an AtlasTexture that is one quarter of the Godot Icon.

Comment:

We should document which texture types animated texture supports. I would also like the ability for AnimatedTexture to support sprite sheets, this would make it much easier to configure them in general. And makes it more convenient to use them as shader flipbooks. For effects such as described in this GDC talk: https://www.gdcvault.com/play/1024630/Visual-Effects-Bootcamp-The-Rise (Technically you can do it without sprite sheets. but its quite a hassle because the workflow is dreadfully slow.)

[nobuyukinyuu]

support for AtlasTextures seems like it would be a minimum requirement for animating such things as TileMaps, seeing as how most people don't store tilesets any other way except densely-packed...

[Byteron]

there are the issues #30295 and #32653 about the issues with using AtlasTextures in AnimatedTextures.

[akien-mga]

See also example project from #32653:

Steps to reproduce: https://imgur.com/a/76RF7hB Minimal reproduction project: https://github.com/MasterGordon/animatedtexturetest

[Shadowblitz16]

just ran into this issue and now that I see this idk how to work around it EDIT: how is this not labeled as a bug? animated texture takes a array of textures which should support a atlas texture

[Aldlevine]

I've created a simple workaround for this that provides minimal functionality similar to this. It extends AtlasTexture with AnimatedAtlasTexture and hooks into VisualServer signal "frame_pre_draw" to update the region of the AtlasTexture based on h_frames, v_frames, and fps. Also because #42134 prevents the use of "tool" on classes that extend Resource, I've also created a small plugin that allows you to see it in editor (the plugin is not necessary if you don't need to see the animation in editor).

This could definitely be extended to allow you to set specific frames/durations (right now, it includes all frames from left-right, top-bottom, with a single fps), but I don't need this for my case.

You can find a gist of it here https://gist.github.com/Aldlevine/93b8958a39fe7ce7ad8c2b253ccec1c5

[frozenMustelid]

/signed

I meant to check on this feature request a month ago, and create it if need be. This limitation in Godot is trivial to work around, but working around it makes the asset folder structure slightly harder to manage.

[Beefster09]

What's the status on this? Has anyone taken a look at it lately?

What technical limitations are there to why this doesn't work with atlases?

Wouldn't it be more performant for animated textures to require atlases rather than not work with them at all? (since that can be handled with batching)

[Calinou]

AtlasTextures are kind of broken and, as I understand it, they may be removed in 4.0. There are lots of places where you can't use them in 3.x, and nobody knows how to fix those. The context in which they were added in was for low-end mobile devices: https://godotengine.org/article/atlas-support-returns-godot-3-2

[Beefster09]

Just curious. In what way are atlases broken? Is it just jankiness of integration with the rest of the engine?

Is my insight on batching not as correct as it used to be now that Vulkan and bindless textures are a thing? (I've only poked around in OpenGL 3.3)

[Calinou]

Just curious. In what way are atlases broken? Is it just jankiness of integration with the rest of the engine?

Yes, mostly.

Is my insight on batching not as correct as it used to be now that Vulkan and bindless textures are a thing? (I've only poked around in OpenGL 3.3)

The Vulkan renderer in master doesn't use batching and makes use of instancing instead, in both 2D and 3D. Batching still has benefits in Vulkan, but since draw calls are significantly cheaper compared to OpenGL, they are far less obvious for most use cases compared to the added complexity of batching.

[rakkarage]

What about the SpriteFrames resource? Nothing about this seems specific to sprites vs controls? It just marks out parts of pngs for animation and has a fps? The top window title even calls itself Animation Frames instead of SpriteFrames. Maybe it could work for both and we would not have to redefine animations...

If I want to show the same simple animation with nodes (Sprites) and controls (TextureRect)? I must setup the Sprite half with SpriteFrames and duplicate all that data into 4 (frames) AtlasTextures for the control version? which does not even work so I have to cut up the sprite to make it work with controls then the SpriteFrames not work anymore...

I guess AnimationPlayer might be a better choice in some situations but SpriteFrames can exist and the data inside is exactly what I (we?) use to setup multiple AtlasTextures to try to recreate animation

Or maybe once this works sprites can somehow use the same data? to avoid having two copies of animation data

Complex Animations = AnimationPlayer? Works... Simple Sprite Animations = SpriteFrames? Works... Simple Control Animations = AnimatedTexture? Does not work? for 3 years?

Thanks.

[overbound]

Dang want this so bad