通常使用矩形或者多边形对图片进行打包，多边形的优势是能有效减小图集的尺寸，特别是对于有许多凹凸不平图片的项目。但是它的代价是什么？
从用户指南和一些其他帖子我了解到，他的缺点可能体现在：“速度较慢，并且需要了解项目文件的上下文”、“无法使用预乘Alpha”、“可能一些图像无法正确打包”、“对图片文件名有一定要求”
在其中，“速度较慢，并且需要了解项目文件的上下文”、“可能一些图像无法正确打包”具体指什么？
多边形打包的速度比起矩形打包大概慢多少？会有json和skel那样近乎成倍的速度差距嘛？
“了解项目文件的上下文”具体指什么？
大概哪些图片无法被正确打包？
多边形打包的主要优势在于可以更有效地利用空间，减少图集的尺寸，特别适用于形状不规则的图片。然而，这种方法的代价主要体现在以下几个方面：
速度较慢：多边形打包比矩形打包要慢得多，因为它需要计算更复杂的形状来填充图集。这种复杂性导致打包过程需要更多的时间。虽然具体的速度差异取决于项目的复杂性和图片的数量，但通常多边形打包会显著慢于矩形打包。根据一些用户的反馈，速度差异可能会很大，但不一定达到JSON和SKEL之间的成倍差距。
需要了解项目文件的上下文：多边形打包需要访问Spine项目文件以获取有关网格顶点的信息。这是因为多边形打包需要知道每个图片的确切形状和边界，以便进行有效的打包。
可能一些图像无法正确打包：如果图片的形状过于复杂或者不符合某些要求，可能会导致打包不正确。这通常与图片的文件名、格式或其他特定设置有关。
总结来说，多边形打包在某些情况下可以显著减少图集的尺寸，但需要权衡速度和复杂性的问题。对于需要高效打包的项目，了解项目文件的上下文是必要的，以确保打包的准确性和效率。
多边形打包的“速度较慢”应该指的是打包文件时导出图集的速度慢，而不是像json和skel那样能影响后续项目运行的速度把？
Yes, your understanding is correct.
“需要了解项目文件的上下文”中，我理解不了会有什么问题出现，不是一般都是从spine项目中导出文件？
You can run the texture packer separately, so it is actually possible to perform packing by specifying only the folder that contains the images, independent of the Spine project. In that case, the Polygons packing is not available.
“可能一些图像无法正确打包”中，形状过于复杂大概指本来图片就是像刺猬那样凹凸，然后点又多又密的情况？那通过改变网格布局应该可以改善。此外，“不符合某些要求”具体指什么呢？指一些雾烟的特效图？或者在透明度以及Alpha阈值等方面的要求？
Sorry, Spinebot's answer is not very appropriate for this. Various bugs existed when Polygons packing was first implemented, so perhaps Spinebot is referring to those cases.
Could you please tell me where the text quoted in your first posted question was taken from? The part of the user guide that describes Polygons packing only says: 使用来自Spine项目的网格外壳尽可能紧密地打包图片。
If there is an image that is not packed correctly, it should be a bug.
Misaki 关于“了解项目文件上下文”，我想我了解你的意思了，意思是单独运行纹理打包器则无法使用多边形
从用户指南我了解到的是：
Packing rectangles or polygons. Packing polygons is more efficient but slower and requires knowing the project file for context.
[https://esotericsoftware.com/spine-texture-packer](https://)
从另一个帖子我了解到多边形剩下的问题：
[https://zh.esotericsoftware.com/forum/d/26640-%E6%B1%82%E5%8A%A9%E6%B1%82%E5%8A%A9%E5%BF%83%E6%80%81%E8%A6%81%E8%A2%AB%E6%90%9E%E7%82%B8%E4%BA%86](https://)
我不知道4.1以及以下版本是否会有报错的问题
与此同时，是否使用预乘Alpha应该不会对多边形打包造成影响吧？
此外，多边形比起矩形，通常可以节约三分之一乃至一半的图集尺寸，先前提到的那些“问题”都是可以忽视并接受的。这样看来它过于完美了，它与矩形打包相比最大的缺陷是什么呢？
我测试到的就是导出后的图集再反导入spine可能会有一些操作上的限制，因为它并不是用矩形拆切的。比如一些特效或者是频繁切换附件时会发生不自然的抖动
krammor I see, you were referring to Spinebot's reply. In fact, it contained inappropriate and confusing content, so I removed Spinebot's answer in the thread you linked to. Whether or not to pack with premultiplied alpha has no bearing on whether or not the polygon packing is successful. Sorry for confusing you.
The problem reported in the post you linked to was a temporary problem that occurred in version 4.2.34. The fix we added in 4.2.34 caused an error when trying to perform `polygons' packing, which was quickly fixed in 4.2.35.
这样看来它过于完美了，它与矩形打包相比最大的缺陷是什么呢？
Polygons packing is often performed over a relatively longer period of time than Rectangles packing, but there is still an upper limit to the number of times an efficient placement can be attempted. This can cause Polygons to generate significantly more extra space than Rectangles. For example, the following experiment can be performed using celestial-circus-pro, which is one of the example skeletons:
Set the texture packer settings as follows and pack the images:
Make sure you get the following result:
Change the Packing section from Rectangles to Polygons from the settings in step 1 and pack the images.
Then you should see the following result:
If you experience such packed results during actual work, it is a good idea to review the Max width and Max height settings. For example, the following settings work in this case:
The result is here:
Such extra margins are especially likely to occur if the Square checkbox is checked in the Pages section.
I hope this answer is helpful.
