Wrong texture size when packing as Polygons

kxs

Hi,
It seems texture packer has bug when calculates texture size while packing as Polygons.

If we use Rectangles packing type the resulting texture size will be as small as possible according defined limits (Min/Max width/height).
If we use Polygons packing type the resulting texture size will always be the same as Max values. No mater what area is really required for the images.
Spine version: 3.8.75

Nate

I'm not seeing that behavior. For example, packing the spineboy project images using the default texture packer settings (max width is 2048x2048) except changing Packing to Polygons results in an image that is 2045x397:
http://n4te.com/x/7131-spineboy-polygons.png
The same with Rectanges is 1534x529:
http://n4te.com/x/7133-spineboy-rects.png

Can you show your settings? Likely the settings are causing the behavior you see.

Apologies that the documentation is lagging behind. FWIW, I wrote a little about the difference between rectangle and polygon packing here:
Spine 3.8.65 and 3.8.66 atlas export problem

kxs

It seems the checkbox 'Square' need to be checked to reproduce the bug.

Nate

Using spineboy as described above but checking Square, I get an image 2045x2045. This is correct: the not square image is 2045x397, so Spine expands the shorter dimension to make it square. In general any special output size requirements produce less optimal results. When packing polygons unfortunately Spine is not able to optimize the smallest size in both dimensions, leading to a larger than necessary size when using Square. Rectangle packing is much faster, so can use brute force, packing many times in different ways, to better fit the images into a square. Polygon packing can't do this as it requires so much more processing that packing many times would take minutes or hours to complete. In the future we may work on heuristics for polygon packing that work better with square output. Do you really need Square? My guess is that need is relatively rare.

kxs

In our game we use Polygon packing wherever it's possible to reduce RAM consumption. We also use it for location assets.
But until now we use TexturePacker for this purpose. And when this feature was added to Spine we tried to use it for animations too.
Here is the same case in TexturePacker and that is why we expected the same result in Spine. The packing process took couple of seconds.

Nate

AFAIK, Texture Packer Pro does not use the polygons from the skeleton data when it packs. Because of that, I'm not sure its polygon packing can be used with the Spine Runtimes. If it can, that is great and you might as well continue using it. I believe Spine can pack polygons more tightly, but clearly Spine doesn't handle Square as well.

Note that last I checked Texture Packer Pro did a poor job of automatically generating polygons

it can cut off non-transparent pixels, especially with low vertex counts.