Godot: How does one use a Texture Atlas in Godot 3?

[jesperkondrup]

In Godot 2.1 you would put all your sprites in a folder outside of Godot and then when you imported them a big sprite atlas would be created automatically, this worked fairly well. But It seems like this really important feature for some reason never got transferred to Godot 3?

Below is a Mockup of one of our Sprite Atlases (created in Texture Packer specifically for Godot 3). The problem with the texture packer plugin for Godot 3 is that it currently does not work as intended and therefore does not give the draw call reduction you would expect.

https://github.com/CodeAndWeb/texturepacker-godot-plugin/issues/1

Right now it looks like this is the only way to create and use a Sprite Atlas in Godot 3 is through a "broken" third party plugin? Or are we over looking something?

[akien-mga]

CC @reduz

[arkology]

13940

[arkology]

Don't know why atlas packing option is removed. In my opinion, using texture atlas the way it is implemented in Godot 3 is NOT convenient and flexible.

[piratesephiroth]

Well, you don't need the plugin at all.
You can save your AtlasTexture as a png image and load it manually.

[jesperkondrup]

@piratesephiroth Could you elaborate on this?

[piratesephiroth]

You pack the frames in a single spritesheet, divided in blocks of equal size, like this:

Then you add it to a sprite and adjust the Animation property in the inspector
This image is divided in 16 blocks so it has 4 rows (Vframes) and 4 columns (Hframes)

You can them animate it with an animationplayer, for example.

[jesperkondrup]

The issue is that my Sprite Atlas does not have sprites of equal size (as you can see in the example I posted).

[piratesephiroth]

In that case it isn't an animation either, you're just packing the different static images together for convenience.
Can't you just assign the same texture to the different sprites specifying different regions for each one?
I didn't test but the issue apparently mentions memory usage issues with AnimatedSprite only.

[jesperkondrup]

No, we are not animating anything, and we are definitely not creating Sprite Atlases out of convenience, it would be a lot easier to have the images separately. But you need to have Sprite Atlases in order to reduce draw calls, especially when making mobile games.

[piratesephiroth]

well let's hope it gets fixed soon then

[metaphoricalsasquash]

This is not an issue I have now, as my level is rather small, but something I see myself struggling with down the line as well.

[piratesephiroth]

Also reminder that this bug only happens if you use the TexturePacker plugin (or import those multiple resource files).

It works exactly as expected if you make multiple sprites use different regions from the same texture using the editor.

So you can use AtlasTextures as long as you don't use the plugin.

[Keetz]

@piratesephiroth this issue isn't tied to the TexturePacker plugin! You can see #21506 for a issue specifically targeted to TexturePacker.

This issue is about how Godot handles spritesheet, and it just mentions TexturePacker as the only smart alternative right now.

And yes you are right, you can manually define regions but that is an extremely, extremely, extremely tedious task to do!

There is auto slicing, but it works pretty bad and also if you use that, you have to go to every single sprite, set the texture, perform the auto slicing and then select the region, again, very tedious!

The way it was handled in 2.x was pretty smart, maybe not the import stuff and so on, but it generated .atex files based on the .tex file, and you could just drag and drop those .atex files, very smart! very easy to use! (.tex being the atlas and .atex being kind of a reference and a region to the atlas)

TexturePacker kind of does the same, but as mentioned it is pretty broken right now (or Godot is?), and also more importantly, why should we be dependent on a third party plugin to a paid tool? Godot should be able to handle spritesheets properly itself, in my opinion.

So again to clarify, this has nothing to do with TexturePacker, it is just used as an example!

[piratesephiroth]

Yeah it is a problem with Godot loading external resources.
It reads the whole texture everytime it loads the new resource instead of caching it and reusing as many times as needed, like it does with a built-in resource.

[Keetz]

@piratesephiroth That is the issue I linked to before, and the issue I created on the TexturePacker plugins GitHub page CodeAndWeb (where you also commented).

You are totally right that Godot has an issue loading resources multiple times, but that is already in focus in previously mentioned issues, this is more to point out that Godot doesn't really have a good way of handling spritesheets.

I really want to make sure the focus of this issue isn't shifted to the resource loading issue! They are NOT the same issues!

[damianday]

I think godot should handle it similar to unity, godot 2 was close. Given how much texture atlas are used in games especially 2d why godot 3 makes you jump hurdles to use them.

[piratesephiroth]

I think I figured it out.

The plugin is intentionally denying the caching of the texture by setting the p_no_cache argument of ResourceLoader.load.

https://github.com/CodeAndWeb/texturepacker-godot-plugin/blob/e9912d574e3c624bc545aff39f8a1a0e76326c16/addons/codeandweb.texturepacker/image_loader.gd#L54

So just change that last argument to false (or remove it) and the plugin will work as expected.

[Keetz]

@piratesephiroth perfect if that works, and i see you also made a PR on the plugin, nice find.
I still want to make sure that we do not move the focus away from the original issue here, the lack of proper spritesheet handling in godot.

The plugin is not the problem here, so this issue is still very relevant

[piratesephiroth]

Yeah that only solves the problem with TexturePacker plugin's RAM usage.
Godot still lacks a native feature however it makes it possible to use the atlases the way the OP wants.

[jesperkondrup]

@piratesephiroth Very nice, the fix for the Texture Packer plugin seems to work! So now we can definitely use the Texture Packer plugin.
But as both you and @Keetz mentioned the original issue is still relevant. A third party addon that you have to pay for is not optimal.

[piratesephiroth]

Today I remembered ShoeBox exists so I made this:
https://github.com/piratesephiroth/GodotTexturePackerShoeBoxConfig

Yeah it's still 3rd party but you can make excelent spritesheets and load them with the TexturePacker Importer plugin for free.

[hedin-hiervard]

I made this tool to approach this problem:
https://github.com/hedin-hiervard/spritesheet-creator

It can be used as a standalone spritesheet creator for Godot and a drop-in replacement for TexturePacker (which is no longer needed). It generates a structure which can be used right away in Godot. Usable in dev and CI environment.

I will soon upgrade it to include more options and add support for other popular engines.

[piratesephiroth]

ah yeah, later on I "made" this plugin too so you can use free tools to pack your sheets
https://github.com/piratesephiroth/shoebox-pixijs-spritesheet-plugin

However it hasn't been reviewed yet (probably because people are busy with the wild jam)

[arkology]

Re-added in https://github.com/godotengine/godot/commit/04847ef5f98d9a20a72286c44cc26302ec82dec5, should be closed now. @akien-mga

[Calinou]

Closing, as this was implemented in https://github.com/godotengine/godot/commit/04847ef5f98d9a20a72286c44cc26302ec82dec5.

[rakkarage]

Can anyone please elaborate on this? This is in 3.2? How to setup "Image Groups" that turn sprites into atlas? Thanks

[artism90]

@rakkarage https://godotengine.org/article/atlas-support-returns-godot-3-2

It yet has to be properly documented in the docs. (https://github.com/godotengine/godot-docs/issues/4019)