Unity3D 5.0+模型合并&灯光烘焙降低Draw Calls方案

模型+灯光测试结果：
执行之前使用的Draw Calls和内存
执行之后使用的Draw Calls和内存
​模型合并规则：
1、非同样的静态模型才需要合并 同样模型（复制的）不用合并
2、UV无重复的模型可用Mesh Baker合并 重复的Mesh Baker会出错 有需要可以在制作软件里合并
3、使用同样材质模型可以合并 使用不同材质的模型不能合并
4、合并模型贴图大小必须为2的N次幂 需选择合适大小以免浪费空间或效果不理想 不要通过贴图设置另外更改大小

灯光烘焙优化场景效果和资源方法：
1、所有相同物体使用相同材质并使用一个Scale
2、所有能合并的同样节点的模型或者共用材质的模型一律合并
3、所有重复使用的模型 顶点上限为900除以贴图张数
4、Occlusion Bake需要根据模型大小来自定义尺寸以免效果不好或浪费时间
5、烘焙时候把环境灯光关闭 把烘焙灯光打开确认范围 根据需要开启或关闭全局照明（GI）如关闭GI则只烘焙AO 把阴影和烘焙灯光做成Lighting Data（多物体多灯光情况下 烘焙AO速度比烘焙GI快N倍）
6、打开环境灯光（如在移动设备上运行只能使用一盏主光）隐藏或者删除烘焙灯光如没有动态模型需要实时计算光影的话最好关闭shadow

其他注意：
1、移动设备上尽量少使用景深、反射、雾效等功能严重影响运行速度
2、移动设备上尽量少使用自定义shader 容易出现未知错误
3、移动设备上使用Light Probe、 Reflection Probe无效

具体 *** 作步骤：
建模步骤：
1、顶点数尽量少 使用贴图来表现物体细节（Color、AO、Normal等）
2、整个场景所有模型的UV单元格大小基本一致
3、节点数量一样的模型（复制的）使用同一个材质
4、一个组合的模型（如整个机械）使用多张贴图需把所有贴图合并到一张上
5、无动画的共用材质的模型合并为一个模型（如机械上的两个或多个部件）
6、没有动画或者不会交互但是会重复利用的模型尽量合并合并后总顶点数不超过900除以贴图数（1张贴图900顶点上限 2张450 3张300 以此类推） 顶点数超出则拆分模型

u3d Mesh Baker步骤：
1、菜单栏>Game Object>Create Other>Mesh Baker>Multi-Mesh andMaterial Baker
2、Hierarchy中选择创建的Mesh Baker在Inspector中选择MB3_Texture Baker脚本使用Open Tools For Adding Objects添加需要合并贴图的object
3、d出窗口选择目标模型 可使用静态或者激活选项来筛选 选择完毕后更改Using Lightmap Index为不过滤 使用Add SelectedMeshes命令添加到列表中
​4、检查添加模型无误后 使用CreateEmpty Assets For Combined Material创建一个合并贴图使用的新材质 指定路径 然后执行Bake Materials Into Combined Material
​5、选择MB3_Multi Mesh Baker脚本 使用Bake生成新的合成Mesh]
​6、原Mesh隐藏或删除（删除节省资源，但一定要确定该模型不会再被使用）

u3d烘焙步骤：
1、导入模型后做成Scale为1的预制体 被调用时尽量不要更改Scale
2、不需要动态载入资源的静态物体尽量不要用脚本载入
3、布置好场景后打开Occlusion 根据需要bake的场景空间大小和模型细节程度选择适当的bake尺寸
4、bake完后 打开Lighting 设置scene中关闭Skybox、Sun（设为None）
41、如使用Light Probe、 Reflection Probe 打开Precomputed Realtime GI 关闭Baked GI
42、如不使用Light Probe、 Reflection Probe 需要烘焙阴影则关闭Precomputed Realtime GI 打开 Baked GI 设定合适的 Baked Resolution、 Baked Padding（Unity3d 540b18 勾选Ambient Occlusion）
5、如Auto Build选项被打开则需关闭（节省时间） 并点击Build下拉菜单执行Clear Baked Data
6、根据需求创建灯光（尽量减少Realtime灯光数量和shadow数量以及点光源数量以节省系统资源）
7、在Lighting 设置Object里筛选Renderers 设置静态物体合适的Scale inLightmap大小（地形为1或者更大 大建筑障碍物05-1树木石头等小障碍物01-05）
8、在Lighting 设置Object里筛选Lights把所有Realtime光源隐藏 所有Bake光源打开执行Build 等候执行读条完成 期间勿对场景进行 *** 作
9、Build完成后 把所有Realtime光源打开 所有Bake光源隐藏或删除（删除节省资源，但一定要确定该光源不会再被使用）
10、主光源打开shadow其余光源按情况决定是否打开shadow 按需求决定是否开启Skybox和Sun

unity场景烘培太亮重新烘焙或者清除一下烘焙数据就可以了。把物体模型放进了场景里之后，引擎会计算光线，光线照到你的物体的表面形成反光和阴影。如果不烘焙，游戏运行的时候，这些反光和阴影都是由显卡和CPU计算出来的。你烘焙之后，这些反光和阴影都记录到了你的模型里，变成了新的贴图了，运行的时候，显卡和CPU不需要进行对环境光效果的运算了。

Unity最初出现在UbuntuNetbook1010中。它最初的目的是更有效地利用上网本有限的屏幕尺寸。和GNOME, KDE 不同，Unity并非一个完整桌面程序安装包，而采用了现有的方案。

Unity环境利用了来自GNOME3中的一些关键组件，包括Mutter混合型窗口管理器和Zeitgeist活动记录引擎。其启动器使用Clutter建立，这与构建 GNOMEShell所用的图形框架相同。虽然底层的技术相似，但Unity用户界面完全是不同的实现，它并没有使用来自GNOMEShell的任何代码。

Unity这个新Shell主要被设计成可更高效的使用屏幕空间，与传统的桌面环境相比，消耗的系统资源更少。Unity将成为UbuntuNetbook版本及新的UbuntuLight即时（instant-on）计算平台的关键组件。Unity环境打破了传统的GNOME面板配置。它的左边包括一个类似Dock的启动器和任务管理面板；而顶面板则由应用程序Indicator、窗口Indicator、以及活动窗口的菜单栏组成。截至2010年Unity开发人员使用的一个名叫Nux的工具替代了Clutter,实现了Unity变成了Compiz的窗口管理器一个插件，且运行速度要比Mutter快。2011年1月14日又发布了一个技术预览版规范的基于Qt的Unity2D版本。

Ubuntu原本使用的是完整的GNOME桌面环境。由于Ubuntu创始人MarkShuttleworth对用户体验的哲学理念与GNOME团队有不同的理解，从2011年4月的Ubuntu1104起，Ubuntu使用Unity作为默认的用户界面，而不采用全新的GNOMEShell。但Ubuntu可通过PPA来安装GNOMEShell。[1]

因为你选了单通道模式烘焙，烘焙结束后，物体和灯光就失去实时光照效果，因此法线效果就不会出现。最简单的理解就是，此时场景中的灯光（不包括烘焙后新添加的）已经无效了。没灯光，法线效果就不会出现。

如果你想在烘焙后看到法线效果，就选择双通道那个模式（第二行）这样法线，高光，阴影都是实时的。或者等40版本出来，40版本的能实现法线烘焙功能。

unity通过窗口更改烘焙灯光阴影的颜色。因为unity的烘焙阴影颜色跟灯光颜色有关，在场景窗口中可以把渲染模式修改成BakedLightingmap来查看烘焙的阴影。所以unity通过窗口更改烘焙灯光阴影的颜色。

其实用动画编辑更简单，新建一个剪辑附加到灯上，然后调节灯光强度的曲线，然后触发播放这个动画就行了。用老版本的animation代码的话，建议在Update中设置，GUI中可能一帧要运行几次代码改下if(count<1){lightintensity=1-count;//我是通过 *** 作这个值实现的count+=001f;}

最近美术反馈，在移动设备上，烘焙之后的场景看上去比PC上预览的效果要暗很多。

因为不同设备的显示器存在色差、亮度差异等问题，确认问题的第一步是通过截屏，拷贝到相同的设备上进行观察。手机截屏，发送到电脑上，然后在同一块屏幕下进行对比，发现场景亮度差别的确很大，角色没有观察到这一现象，推测是lightmap相关的问题。

制作一个简单的Demo，分别使用Standard材质我们自己项目中使用的材质进行对比，发现均有此问题， 排除自己材质的bug 。

因为我们使用了 线性空间 ，因此切换色彩空间进行对比实验，发现伽马空间下也 有色差 ，但是 没有线性空间明显 。

还是照常先搜索一下，收集相关的资料。

怀疑是Unity引擎 官方bug （这不是Unity擅长的么。。。），先是搜索到一个issuetracker上的bug 汇报  AKED LIGHTMAP IS DARKER ON ANDROID PLATFORM COMPARED TO PC PLATFORM ，说是Unity 555版本fix，没提到线性空间的设置，我们7月份要测试也等不到555版本了，所以暂时先记录下，继续。

UWA的问题有一个帖子问过相关问题，有一个答案： Lightmap在PC上显示正常，但是转到Android平台上存在色差，颜色普遍偏暗 。这里引用一下回答的内容：

这里给出了差异产生的原因，即lightmap贴图是使用exr格式存储的，然后在移动设备上如果按照LDR进行处理产生偏差是很正常的，给出我的建议我们看了下，没有对应的问题。

然后，找到一篇 解决Lightmap在PC上与ios和Android上表现不同的问题  ，有基本的原理分析，有解决方案，还有源码，看上去很靠谱。做了一个demo尝试走了一遍流程，是可以解决变暗的问题，但是和PC上比，还会变得更亮。。。依然有偏差，不知道是否是线性空间的问题，而且更加重要的是过程太多繁琐，维护成本很高，所有的材质都需要对应修改，不理想。而且，转换之后的贴图要使用RGBA8的格式，一张1024的贴图需要占用4-5M左右的包体和内存空间，实现不能忍。

不久前看过一篇知乎上的帖子： 谈光照图烘焙技巧 ，里面有提到跨平台的问题，提到：

检查了一下，做demo用的贴图亮度063，光照亮度调整为1，烘焙之前的颜色大约也符合05-07左右的亮度，不知道是否因为线性空间的问题，反正依然没有解决。但这篇文章直接提到了UnityCGcginc中的源码，即lightmap的颜色解析过程，去看了一下。

纠结了一个晚上，最后还是决定选择 修改DecodeLightmapDeubleLDR的方法 来解决，一边尝试修改材质一边测试：

1 直接强制在设备上使用DecodeLightmapRGBM这个函数来处理，可以实现和PC上相同的效果；
2 把DecodeLightmapDeubleLDR内部修改为 (decodeInstructionsx pow(dataa, decodeInstructionsy)) datargb; 结果一样；
3 直接使用unity_Lightmap_HDRx colorrgb; 结果看上去一样相同。

心里很不安，虽然测试结果是好的，但是因为计算过程并不一样，我也搜索不到unity_Lightmap_HDR这个是在哪里进行赋值的，具体是什么含义，尝试修改值，对比结果，感觉这个值大约是50的样子。。。有个宏定义和注释，也不知道是否有关系：
去PS里看了一下lightmap贴图，发现用于调整RGB值的Alpha通道几乎非黑即白，只有在一些边缘的地方有一些灰度的值，这也许可以解释为什么我去掉alpha的调整计算结果看上去是对的——毕竟Alpha通道根本没起到什么作用。找了一个室内场景的lightmap看了下，依然是这样的，不知道是不是美术烘焙的时候有神马设置没有用好。。。

注意 ：这样修改之后，lightmap贴图压缩使用ETC(2)_RGB4的格式即可，不再需要alpha通道，之前1M的1024贴图变成了05M，开心~~（中间测试使用ETC2_RGBA8的格式，场景反而全黑掉了，我也很难理解。。。如果有知道原因的朋友请告诉我，非常感谢~）

最后，重新替换到UnityCGcginc文件，删除Libery下缓存的编译好的Shader，重启Unity，把所有exr格式的贴图格式设置为ETC2_RGB4，重新import一下，打包到手机上，然后截图到PC上在同一屏幕下对比，我们的场景几乎看不到差别。

工程中，解决问题的过程总是伴随着各种猜测和不解，在最后问题解决了之后，有些疑问解开了，有些疑问可能仍然没解开。

最终方案的选择是基于时间成本、维护成本、最终效果一致等各个方面权衡选择的，我也很明确地知道这个解决方案并不一定适合所有的项目。为了更细腻的角色效果和烘焙前后一致的光影效果，我们在移动平台上完全使用了线性空间来进行开发和制作，现在为了解决设备上和PC上烘焙结果不一致的问题，又再次在不知道哪里设置unity_Lightmap_HDR这个变量的情况下修改了UnityCGcginc文件。。。

其实我不知道最后使用的解决方案是否还隐藏着别的坑，但是如美术看到结果时所说——“很完美，看上去和PC上的完全一样！”正应了计算机图学上的那句名言：如果看上去是对的，那它就是对的。

目前能做的，也就只有这样了吧……

最后，如果你手头有Unity源码可以知道unity_Lightmap_HDR这个变量的设置细节，或者知道它的文档或者设置逻辑，还请告知我，如果想到这个方案有什么坑，也欢迎和我讨论~非常感谢！

---