Add Crop Position to the Texture Atlas importer

[jesperkondrup]

Describe the project you are working on:
We are currently working on several 2D games that should be able to run on very old hardware and therefore we rely on sprite atlases to optimize performance.

Currently for all our projects we use Texture Packer by Code and Web. One of the functions we use a lot in Texture Packer is the trim mode: "Crop, flush position". This basically just removes the transparent pixels and discards the old resolution of the image, resulting in a cropped image with the bounding box set to the border pixels.

This actually works perfectly but we don't like being dependent on a third party plugin that often needs to be updated when a new version of godot is available. Therefore it would be great if this functionality was available native in godot so we could remove texture packer entirely from our pipeline.

Describe the problem or limitation you are having in your project:
The newly added feature "import as TextureAtlas, Region" in godot 3.2 is very close to what we are looking for but it does not crop the position. If we use the blue circle as an example: The circle is not placed in the center of the image and it has many transparent pixels around it. This will result in a bounding box that's not centered and also bigger than the image (see image below).

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
We propose to add a check mark "Crop position" in the Texture Atlas importer window (see image below).
We should not remove any of the existing functionality since not having the position cropped could be preferred in many cases.

Setting the check mark "Crop Position" (not sure about the name) should result in the orange bounding box in Godot being set to the border of the pixels in the sprite (see image).

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

Select a number of sprites in a folder and go to the import tab. Chose import as TextureAtlas, set the location of the atlas file, import mode should be set to region and optionally you can set a check mark in the "Crop position".

Godot is almost there:
It does actually seem like the "code" we are requesting is already in godot and you could use it as work around in some way but it's very cumbersome and definitely not an ideal solution. Here is how it currently could work (see image below).

1. Create your sprite atlas using the region setting.
2. Drag the entire atlas.png it into the scene.
3. set the "region" check mark ON.
4. Now go to the Texture Region window and chose "Auto slice".
5. Pick the sprite you want.

This actually crops the image in the way we want and the orange pivot square is set perfectly.
But this is not an ideal solution. You cannot search for images in the file system, it involves many steps and furthermore if you update one of the sprites it will not update the new position in the auto slice automatically, so you have to go into each sprite and update them.

Edit: We are aware that you can also select "2D Mesh" in the TextureAtlas import settings but 2D Mesh does also not crop and it is not batched like the "Region" setting.

If this enhancement will not be used often, can it be worked around with a few lines of script?:

We believe that this feature could potentially help a lot of artists when working with sprite sheets. Since we are using the native TextureAtlas import setting in godot it would not be a good solution to add a custom script to crop the position.

Is there a reason why this should be core and not an add-on in the asset library?:
We already have many games relying on this feature and in the future we are also going to use this feature extensively. So it would definitely be easier if this is built-in instead of an add-on that has to be updated. We also believe that good sprite atlas support should be a basic feature in godot, so developers don't need to rely on third party plugins.

We hope this post explains what we are looking for, thanks : )

[akien-mga]

Implemented for 3.4 via godotengine/godot#52652, still needs an implementation for master before closing this proposal.

[akien-mga]

Implemented for 4.0 via godotengine/godot#53499.

[Sousio]

I wish there were also some options to add or remove textures to the Atlas Texture as well. Right now if you want to put another texture to it, you need to delete the previous Atlas Texture and import all textures together again! This can be cumbersome, as this would happen a lot in a development process. Tell me if there is a solution to that which I'm not aware of.
The other lacking use case is when you want to share one texture in multiple AtlasTextures which is not currently available. However I know the current choice is preferable for the memory usage and optimizes the file storage, but it limits the usability.

[Calinou]

I wish there were also some options to add or remove textures to the Atlas Texture as well. Right now if you want to put another texture to it, you need to delete the previous Atlas Texture and import all textures together again! This can be cumbersome, as this would happen a lot in a development process. Tell me if there is a solution to that which I'm not aware of. The other lacking use case is when you want to share one texture in multiple AtlasTextures which is not currently available. However I know the current choice is preferable for the memory usage and optimizes the file storage, but it limits the usability.

See #1053. In general, AtlasTexture functionality is considered to be in maintenance mode, so don't expect massive changes occurring to it for 4.0.

[Sousio]

See #1053. In general, AtlasTexture functionality is considered to be in maintenance mode, so don't expect massive changes occurring to it for 4.0.

Thanks for your response. Yeah, I guess that the AtlasTexture is developed with sprite sheets in mind, but there can be other use cases (like my rare case) where the sprite sheets should be procedurally generated. I've implemented a workaround snippet for that which seems not to be efficient. I don't expect this class to be changed for these rare cases, but I think adding some general feature can improve the AtlasTexture flexibility for some other special cases too.

One of those features is to make the AtlasTexture return the separate textures by ID (just the way the TextureArray works); the returned texture can also be selected by a cropped/or original(not cropped) option. This can relief the pain to store the separate texture's region and margin, keeping track of the needed one and retrieving data when on implementation. I currently store them in arrays, but they should be updated every time the AtlasTexture gets updated (no actual way to update by adding/removing textures, just delete the previous AtlasTexture and create a new one). Anyway later on (if reviewing the AtlasTexture after v 4.0) this general "Retrieving data by ID" can be a thing if other people need it too.

[cloudziq]

One of those features is to make the AtlasTexture return the separate textures by ID (just the way the TextureArray works); the returned texture can also be selected by a cropped/or original(not cropped) option. This can relief the pain to store the separate texture's region and margin, keeping track of the needed one and retrieving data when on implementation. I currently store them in arrays, but they should be updated every time the AtlasTexture gets updated (no actual way to update by adding/removing textures, just delete the previous AtlasTexture and create a new one). Anyway later on (if reviewing the AtlasTexture after v 4.0) this general "Retrieving data by ID" can be a thing if other people need it too.

Agree, Now it's very problematic, I mean.. Functionality of Atlases, without ablility to remove textures and reference certain region by texture name, is very limiting
For situations where each tile/graphic on sprite need to be randomised, currently there is no way without storing each region coordinates which is a real, time consuming, pain (which need to be repeated over and over when atlas change)
And using individual images from folder resulting in 200 draw calls (for example) instead of 1

(btw: you can add textures single textures to existing atlas)
sadly this is closed.. I should post this as new proposal I guess..