- संपादित
Wrong texture size when packing as Polygons
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
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
It seems the checkbox 'Square' need to be checked to reproduce the bug.
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.
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.
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.