- Изменено
export size validation issue
The export checking seems no considering my export scale and tell me my sprite doesn't fit into 2048 texture.
In fact,
2209 x 0.75 = 1656
which should be fine.
Got another problem. I was trying to work around by changing to export size to 4096x4096. The export saved a 4096x2048 image with quite a lot of empty space. I guess it is calculating with original 1:1 scale before scaling thus it doesn't know it could pack the sprites in a better way.
I guess it need to use a scaled down sprite sizes (or a scaled up max size) for the packing calculation.
This has been fixed in 4.0.60-beta, now available!
Testing in build 61, the packing logic still has issue.
This time, I changed the export scale back to 1 so no more scalling. I scaled down the stage to be within 2048.
When Max size is still 4096 + power of two, it pack me this:
It should fill the empty space by the current power of two boundary before trying to expand.
In the mean time, I will change the export size to 2048 to work around the issue.
Normally I set default texture max size a little larger so that I don't need to care whether a piece is larger than 2048.
Updated sample project for testing:
Pack PowerOfTwo Issue Sample.7z
Rectangular packing works as you expected: it tries to pack in the smallest size possible even if the max size allowed is much larger. It does this by packing multiple times at different sizes to find a reasonable solution (packing is NP-hard).
Polygonal packing is much more difficult. Spine does polygonal packing at only one size and even then you probably noticed it takes significantly longer than rectangular packing. It chooses a heuristic and region rotations that produce the smallest packed area within the max size, then it cuts off any extra space, if possible. Because it would take too long to try multiple sizes, in some cases you may achieve a slightly smaller result by using a smaller max size. This isn't always true and even when it is the difference is not typically very much.
Packing your project with 4096x4096 max size: 2233 x 1163 = 2,596,979
Packing your project with 2048x2048 max size: 2048 x 1265 = 2,590,720
Using 2048x2048 packs more efficiently by about 0.24%: 1 - (2,590,720 / 2,596,979) = 0.0024
Note unless you really need power of two textures, you'll get smaller results without it,
I am also considering to drop this power of two requirement too. I read that some old mobile devices only support power of two texture but don't have the numbers. Maybe I should ignore this potential problem and tackle it only after people actually report texture issues to me.
Aye, POT is a bit of a mess with no clear answer. If you don't use POT, all (or nearly all?) modern hardware will be fine, but there is still some question as to how various hardware will handle it. Some hardware may go the easy route and just allocate the next largest POT size, rather than doing something more efficient. In that case, if you happen to be using images that are 2049 pixels, it may use a lot more memory than intended.
Looking at polygon packing again, a lot of it is much faster than it used to be. It may actually be possible to try multiple sizes if we short circuit early, as soon as a single polygon doesn't fit when trying to fill a page that is less than the max size. This seems to perform OK in preliminary tests, but we'll give it to the team to explore further next week. It may only be possible for POT sizes, since non-POT requires a lot more tries, but it would fix the issue you have.
Just wondering, do command line currently return different exit code based on different export failure reasons? I seems can't find the exit code table from the export page.
Example:
0 - export OK
1 - Failed due to oversize issue
2 - fine but detected missing image
and so on...
I am current having a unity script to do batch export. I would like to be able to track the export result precisely because I want to be able to take further action based on the result. e.g. edit the export.json to a large max size and do export again or warn me to look at the issue, etc.
The exit code is 0 for success and 1 for failure. If any warning messages are printed the exit code is still 0 for success.