Unity图集、Image和SpriteRenderer

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