是在学习tilemap绘制世界地图的时候发现的这个功能。
之前一直只是粗略的知道这部分是对应图片资源的压缩的。比如Compression是指的压缩质量，想要完全不压缩就设置None，会导致图片资源会大一些。
在我的例子工程中，其他图片资源的尺寸都是64x64，在tilemap的调色板中放入是没有任何异常的。但是这个作为瀑布的图片，原图尺寸是640x256，如果按照64比例会生成10*4的图：
但是从图片细节上来看，并不需要切割成这么小的方块。所以，切割时对64x64等比例放大，成为128x128，这样，既能不缺少更多细节，又不至于切割的过于零碎，不好使用。
当然，还可以继续放大。但是如果继续放大，纵方向是256个像素，就无法区分瀑布底部和瀑布上面，不利于扩展使用。
由此，我得到了10张128x128的图片；0-4张可以形成瀑布上方的动画；5-10可以形成瀑布下方的动画。
但是将这个作为Tile之后，我发现，这个Tile和其他的tile之间，如果同时放入调色盘中，会有明显的不适，因为该tile会比其他的tile大了一圈，如图所示：
一个解决方法是，专门为这个tile创建一个单独的调色板，设置对应的尺寸，这样就能够正常使用了。
但是查看示例工程，将64x64的tile和这个128x128的tile，放到一个调色板，看着没有任何的违和感。
原因是瀑布图切割成128x128，但是有一个Pixels Per Unit，其他图设置为64，表示一个单元格渲染64像素，将这个128x128的Pixels Per Unit设置成128，就表示对于这一张图，一个单元大小的格子，渲染这张图片时渲染128个像素，最终效果就是如上图所示，虽然是同样的格子，原图尺寸不一样，但是对于我们逻辑上来说，都是一个格子。在项目工程中是统一的。
通过Pixels Per Unit，就能够把不同分辨率的图，通过设置每单位像素数，令其在逻辑上大小一致，最终效果如图所示：
一开始以为是压缩导致，以下是在调查这个问题的时候，发现的关于素材压缩的一些配置。之前对于压缩设置只是有个概念，没有具体研究其影响。
查看发现，这个128x128的sprite，在示例工程中实际是51x51。
那么这个51x51是怎么来的？我们明明知道png素材的尺寸是640x256。
为什么不使用64x64，而是51x51？
如图所示。设置了“Max Size” = 256.
这个是设置了图片导入工程后，对图片进行怎样的一个压缩处理：
设置max size为256后，原本640x256的图片，就会被等比例缩小为256x(256/640*256)，也就是256x102.4.
这个时候，虽然我们进入sprite editer中，切图还是按照640x256进行切割的，但是我们最终得到的可供工程所使用的“Sprite”素材，已经变成了128 * （256/640） = 51.2。
所以，这就是我们的sprite的最终尺寸了。
这个地方，实际上并不是设置sprite素材的属性，而是导入图片后，对素材做怎样的压缩处理，甚至其大小也会做对应的变化。
如：
设置了maxsize= 256后，图片的尺寸为256x102，大小为76.5KB。
如果设置的maxsize高于原图的最长宽或者高，那么图片尺寸为原图尺寸
640x256，并且大小也会做相应的变化，成为80.0KB .
如果再次基础上，我们修改Compression属性，也就是修改压缩程度：
比如选择“High Quality”，可以看到，图片的颜色格式也变成了RGBA，多了一个alpha通道，并且，图片大小变成了160.0KB 。
之前虽然知道这个地方是设置图片导入工程后的压缩算法的，但是没有这么直观的感受到。原来这里的修改是会直接影响到后面所有的使用者。
当然，不要忘记那个filter mode，设置为point（no filter）。