crashinvaders/gdx-texture-packer-gui

Grid layout option adding weird Y-padding

Closed this issue · 4 comments

Hi,

I am confused by the output of GDX Texture Packer when I enable the Grid layout option. It looks like it is adding an additional Y-padding to the top and bottom for whatever reason.

Here is the result without Grid layout:
image

Here is the result with Grid layout enabled. Notice the padding at the top:
image

Is this intentional? If so, what is the reason behind it?

My problem is that without using Grid layout it seems to randomly pack the images together and therefore creating a TiledMap is not ideal since e.g. a tree is scattered around everywhere in the final texture.

Using Grid layout makes it better but that way I cannot use it in Tiled because Tiled assumes that the edge padding is the same on X and Y coordinate and I personally expected the same.

Hi,
I should clarify first, that the main goal of the app is to create textures atlases, not tile grids. This implies that the output is optimised for the best region placement according to the modern rendering API specifics while keep the minimum amount of disk space. The resulting atlas page images are not intended to be deterministic (in most of ways). Means between the two consecutive outputs of the same atlas, there could be totally different compositional images. But it's fine as long as during the game runtime the rendering looks the same.

In regards to your case, the aspect of "non-deterministic" is somewhat crucial. In a way you never can rely on the order of the images in the resulting tile grid. That's fine of course if you export the tile grid only once, but then if you decide to add an extra images, the positions of the existing elements most likely will be changed.

Hope this ⬆️ makes sense. So I strongly advise you to look for another tool to create tile maps (there must be plenty of those). Or, in case of pixel art, it's always much easier to maintain those by hand, using image editor. It might be tedious at first to compose a couple of dozens small images next to each other, but in the end you will have the full control over the tilemap with unlimited potential to extend it or modify.

Nevertheless, you can totally achieve the described tight packed tile grid by setting up your output like so (I highlighted the most important fields):

Thank you for your quick response and appreciate your input but in fact I need a padding because LibGDX (or maybe OpenGL in general) creates a lot of bleeding for tiledmap rendering when using small sizes like 16x16 or 32x32.

To fix this issue I always added a padding of at least 4 then it solved the bleeding issue. However, in the example above the padding on the top is not according to the settings. I use a padding of 6 but actually there are 12 pixels at the top used for padding.

I guess it is related to the first part of your answer but still it is strange to me that it does that :D I expect it to be 6 pixels as well no matter if I enable Grid layout or not.

If none of the different configurations work (try match mine exactly). There's a chance that we're dealing with the old bug where the slider fields display wrong textual values. Try set edge padding values by dragging the sliders (not by number input). See if the atlas is being packed with wrong padding values...

Okay, I tried out now all the options and combinations. Here is the result:

No checkboxes for padding/grid ticked -> images are moved to the edge and they have the spacing between according to the Padding settings. This is correct:
image

Enabling Edge padding moves images away from the edges by the specified Padding values. This is also correct:
image

Enabling Grid layout without Edge padding adds a padding to the top. I don't understand why:
image

Enablind both Grid Layout and Edge padding has a similar result. Again, there is an additional padding at the top:
image

Does not make a difference if I use the slider or enter a value. Most likely this is intentional and as you said, I should look for a different approach ;) But might be interesting for others to know about this "feature".