Unity图集、Image和SpriteRenderer
前言
最近好久没有写技术笔记了，今天继续回归日常学习的状态。
图集Tight Packing
Unity提供的SpriteAtlas有一个Tight Packing选项。这个选项勾选之后，图片就会按照它的Sprite Mesh来进行图集排布。可以大大提升图集的使用率，尤其是对于那些斜视角游戏。
但是使用Tight Packing会面临一个问题，就是默认情况下，Image使用的Mesh是Rect Mesh，也就是说在裁剪图集的时候，回把一些我们不想要的图片也裁剪进来。如下图：
那我们不想要多余的图片怎么办呢？
那就需要让Image使用Sprite Mesh来渲染。Sprite Mesh的图集对应Sprite Mesh的Image，好像也没什么毛病。
在Image组件上选择Use Sprite Mesh即可。如下图：
多余的图片是不是就没有了？
但是这也面临一个问题，使用Sprite Mesh会增加渲染的顶点数量，增加计算量，也会降低Overdraw。所以说，到底选不选择这种方案，就是一个trade off的过程了。对于一些渲染压力比较低内存压力比较高的游戏，采取这种方案还是很好的。
SpriteRenderer和Image
既然提到了图集，那么正好顺便总结一下SpriteRenderer和Image相关的区别知识点。
主要区别：
SpriteRenderer | Image |
SpriteRenderer使用的是图片Mesh，增加顶点数的同时减少了Overdraw | Image可以使用RectMesh也可以使用图片Mesh |
SpriteRenderer就是Unity基本渲染器的一种，渲染顺序基于Sorting Layer等 | Image是基于Canvas绘制的，由底层计算的depth控制绘制顺序（具体可以参考我之前写的笔记） |
SpriteRenderer的SetPass基于动态合批和图集，同一批次的绘制中要尽可能减少切换材质的次数 | Image不管是不是一个图集，在不设置额外Material的情况下，同一Canvas下的SetPass就是1 |
SpriteRenderer在大量绘制的情况下，绘制成本开销会高，但移动、变化消耗几乎没有 | Image在大量绘制的情况下，Canvas会重用，绘制成本会很低，但是一旦移动、变化就会触发Canvas重绘，会产生很大开销 |
总得来说，就是各有利弊。
使用场景：
综合上述，对于大量静态图片，最好还是使用Image。
一旦这些图片需要移动、变化，要么把这些需要移动、变化的图片单独放在一个Canvas上，要么把它们做成SpriteRenderer。
小结
最近因为个人原因，很久没有总结技术笔记了。
现在算是回归初心了，总之继续总结笔记，学就完事了。
参考
https://tsubakit1.hateblo.jp/entry/2016/09/26/080000 https://forum.unity.com/threads/tight-packing-in-sprite-atlas-issue.701582/#post-4750916
