Notifications
Article
《不可思议之梦蝶》从PC版移植到Nintendo Switch经验分享(下)
Updated 3 months ago
391
1
本文将重点分享《不可思议之梦蝶》的各种优化方法。
在《不可思议之梦蝶》从PC版移植到Nintendo Switch经验分享(上)中,队友游戏制作人李喆分享了需要针对Switch平台开发的内容以及开发中Unity版本的选择。
本文将重点分享《不可思议之梦蝶》的各种优化方法。

演讲内容

下面分享一下包体尺寸的优化。
Switch对包体尺寸并没有太大的要求,因为游戏也同时移植到Android和iOS平台,所以我们也是顺便优化一下包体。
优化方法的主要方法是控制台的Editor Log,每次Build的时候都会在Editor Log中生成非常详细的游戏资源占用容量及比例信息。
通过正向的从工程里查找资源,很难发现哪个资源是不是真正打入包里了。有些资源你觉得好像是用了,但实际上根本没有进到包里。有些资源你觉得根本没有,但它可能会通过材质球或间接引用方式还会进入包的安装部分。
所以通过Editor Log,可以完全清楚看到哪些是在包里,哪些是不在包里的,肯定要把包里的东西进行重点优化。
优化的重点目标就是纹理,一般3D游戏最占容量的可能就是纹理了。Switch平台是支持ETC2和ASTC这二种纹理压缩格式的,这类格式是可以被显卡直接解压的,所以纹理会很快速的载入,然后在压缩时会产生非常大的压缩率。
一般找到纹理之后,要去覆盖对应平台的设置。我们可以切换不同压缩格式,压缩格式也不是越小越好,因为压缩的纹理是有显示效果上的损失的。我们要平衡最终的显示效果和包体体积的关系。
还有一项注意的事情是:如果烘焙了Lightmap和Shadowmap的话,这些纹理实际上是不压缩的。为了获得比较好的查看效果,在PC上也用不着压缩,所以在移动设备上时,我们可以针对平台单独设置Lightmap和Shadowmap的压缩,这样可以大幅度减少包体容量。
我们会很明显察觉到阴影和光照的显示效果变化,并且要对这些进行适中的平衡。其实Switch平台显示的分辨率是比较低的,掌机模式只有720P的画面,下降一些不会有太大变化。
还有一个比较容易忽视的Mip Maps。游戏里会有一些高清的Logo或菜单图标,美术在考虑到后期迭代时,会把图标做得比较大,一般会做到1024或512这种格式,但在PC上其实也不在乎。
如果把Mip Maps这个选项勾掉的话会减少很多存储的容量。很多用在UI上的图片是没有远近区别的,所以Mip Maps不会产生实际上的显示效果。
上图是我们的Build Report,也就是刚刚说的Editor Log的截屏。下面我一步步拆解这个截屏给大家看看,分析一下优化的方法。
上图是第一部分,我们可以看到排序按照:纹理、Mesh、动画、声音、Shader,还有其它的资源、Level场景、Script脚本、Unity自带的库Included DLL、其它File header这些内容。
整体看下来打包之后是1.8G,这并不是实际的打包结果。Android的APK打包出来后,实际上安装后的容量就是这个数字。在APK里面还会再次压缩,基本上会压缩到800多MB的样子。
Switch平台的压缩打包结果应该在1.2G左右,后续还会有一次打包的压缩,这个打包压缩在机器安装以后就解压了,所以在机器上就会占到1.8G的容量。
第一段信息显示了三个数据:60Mb、40Mb、25Mb,这是游戏手绘的动画片。它们都是1080P的,60M并不算很大,而且它们对游戏有很重要的作用,所以我们没有进行特殊的处理。
第二段信息显示是16MB这种都是TTF文件,也就是字体。在游戏里,因为需要支持多语言,例如:韩语和日语,所以要将特殊字体放进去,每个字体都占这么多的容量。大家也要提前想到这点,但如果仅针对中国出一个国服版本,不支持多语言,这些东西都可以删掉。
第三段信息是FBX文件,它们实际上并不是模型,里面存了很多动画,所以文件会有3.9MB的大小,这就比较大了。
上图倒数第二行其实是一个Shader,这是从资源商店买的Toony Colors Pro。它是用于卡通渲染的Shader。但Shader的变体比较多,其实Unity自带的Standard Shader也有这个问题。
变体比较多的Shader在打包时,每个变体都会单独出一个文件,最后会把这些文件汇总成一个,就有3MB多。大家一般不会想到Shader会占那么多容量,但是它因为有那么多变体,所以它只能有这么大。
由于Toony Colors Pro是购买的,我们也不太会改动它,它也非常复杂,工作非常多,所以就只能放在里面。而且我们是在后期才发现这个问题,因此也不好改了。现在我们已经会自己做Shader了,生成的Shader是非常有目的性的Shader,它可以很小很小,一般的Shader,也就是单独功能的Shader可能1K都不到。
所以大家要考虑如果打算自己做Shader的话,就要尽量避免使用这些外部的公共的资源。因为这些资源是通用性的Shader,所以会产生很多没有用的存储。
最后说一下Level,其实就是场景,从上图可以看见Levels现在有500多MB,为什么有这么大呢?一般制作完一个场景大小大概也就是10-20MB左右。《不可思议之梦蝶》有一个特殊的点,:它都是在室外的开放环境,所以有很多建筑的Mesh。这些Mesh非常大,因为本身它引用FBX文件,它的存储不会占用太多的地方。
我们要进行优化,因为Draw Calls实在太多了。就算切换到静态模式,自动的静态合批在中间可能会被动态的材质球打断合批,在Frame Debugger中可以看到,它的合批是被打成一段一段的。
当物体很多的时候,Draw Calls数非常高。这对显卡没有太大要求,但对CPU压力比较大。Draw Calls数值高在PC上是几乎没有影响的,但是在Switch平台和移动平台上,CPU的压力是非常大的。
我们进行了一个合并工作,就是Mesh烘焙。我们是通过Mesh Baker来完成的,真的非常有效果。Mesh Baker有一个合并的方式,支持按照簇来合并,我们可以把想合并的静态的Mesh选入进去,在工具里去设定覆盖每个簇也就是每个球的半径大小,这个球半径内包含的所有零碎Mesh,它都可以帮你烘焙成一个。
上面不同的材质球都可以通过子Mesh的方式去挂接上去,Mesh Baker会自动帮你合并这些簇。合并簇的一个好处是,静态合批是在运行前就已经处理好了,就是已经完全固化好的一个合批。
此外,Unity有Occlusion Culling遮挡剔除,如果一个物体被另一个物体完全遮挡的时候,它在摄像机渲染上是可以自动拿掉的。变成一簇一簇的话就会很好理解。例如:站在音响后的这些人就可以完全不渲染,这可以极大的提高渲染的性能,所以这是合并Mesh的目的。
合并Mesh之后,可能会让场景变得非常大,但我们可以把Mesh再导出单独的Prefab来,然后放在游戏的资源里去挂接,但结果是一样的,它的体积并不会变小。
为什么会变大呢?大家可以想象一个石头大概有100面,场景里这样的石头可能有1000个。分簇的时候,一块地方包含花花草草,一共会有50个物体,它会把它们合成一个。
合成一个之后,原来共用的FBX文件就没有用了,它就单独生成了一个顶点数非常多的新模型,其实是新的Mesh。因此它的存储容量会大幅度提升,而且这个Mesh本身是不太容易压缩的,所以体积会变得非常大。
为了提高渲染性能和整体的结果,肯定是要丢失一些东西。我们在纹理压缩上进行了很大处理,让出了很多空间给Mesh。
关于纹理,项目从一开始,没有优化纹理压缩格式之前,就包括所有的Lightmap和Shadowmap加起来有2G多,完成纹理压缩格式的针对性设置后,纹理最后加起来才600多MB。
在iOS上,我们把它切换到ASTC的格式后,2G多的纹理可以压缩到180多MB,可以有将近10倍的压缩。所以大家一定要记住这种方法,这是非常有效减少包体的办法。
最后是提升渲染性能。刚刚也说到CPU开销如果太大的话,对帧率的影响是很大的。
大家玩3D游戏多了之后,可能只认为显卡对游戏性能的影响比较大,但实际上关于CPU的开销,我与很多开发者交流,其实项目一开始优化时,CPU跑不动,降低帧率的结果几乎都是百分之百的。
大家一般都不会去考虑CPU占用的问题,拼命去堆功能。这样可能没错,但是最后一定要优先处理CPU开销,才能节约出大量的时间给其它的逻辑,比如没法减少开销的物理引擎,包括一些其它逻辑上的运算。
在Switch平台上,对于显示帧数,有一个单独的工具NxGraphicDebugger。它使用起来和Unity自带的Frame Debugger其实是相似的。这里我没办法分享放NxGraphicDebugger的截图,因为主机平台对开发者有NDA,包括游戏里运行时出现的日志和所有工具图像的截屏,都是不能公开的。
我们努力进行优化,基本上面谈及这些方面的内容,并没有针对游戏有什么巨大的改动,我们的游戏在Switch平台可以从8帧优化到40帧。其实还不算很好,我们本来想要60帧。
但我可以跟大家分享一个经验,Unity打包出来的程序,如果使用Standard Shader,有人做过极端的测试:在Switch平台到底能运行几个Standard Shader的物体在游戏里?它们都是动态物体,不是静态物体,最后测下来只能运行6个Cube,超过6个之后就不能稳定在60帧了。
具体我也没有对运行原理有太多研究,但最后结果是:可能这和Standard Shader的复杂计算有关系,它把Shader换成Unlit非光照Shader以后,即使放入100个Cube也可以稳定在60帧。所以大家在Switch,尤其在掌机模式下也不用苛求60帧,我觉得可以稳定在30帧就已经很不错了。
上面这个视频是在2018年6月9日凌晨1点,《不可思议之梦蝶》第一次在Switch上运行。当时很开心,我本来以为优化基本上没希望了,但经过一些黑洞般的调试后却可以了。
在此之前,我大概经历了一个星期的时间,游戏没有任何画面是可以在Switch上显示出来的,当时根本运行不了,还出现了各种各样的问题,游戏每次都会闪退,根本不知道为什么。
刚刚忘记说了,如果使用第三方插件,在Switch移植的过程中,第一次一定要记得先把插件先关掉,看看游戏到底能不能运行,有没有问题。
一开始闪退后,我们花了3-4天,最后发现是Wwise的一个设置错了,导致每次崩溃都是因为Wwise而崩溃,而且第三方引擎的簇其实在簇日志上输出是非常非常少的,根本不知道是为什么。其实是完全一个瞎调试的状态。
后来通过项目经验的不断积累,我开始把不同的插件都关掉,最后通过排除发现是第三方插件的问题。大家也可以使用这种方法进行折半查找,把项目关掉一半,看看另一半有没有问题,使用快速查找的方法去发现问题。
最后把第三方插件排除掉之后,这是License已经申请到的结果,游戏可以跑起来了。但这个场景其实是Boss战的场景,内容量其实非常少,只有一个Boss和自己,此时运行只有8-10帧的状态,虽然大半夜跑起来让人很兴奋,但其实结果并不算太好。
经过一个星期的优化,上面这个视频还是这个场景,大家可以看到游戏已经顺利运行起来了,它已经可以稳定在30帧以上了,就是这么一个状态。
在优化过程中,我们经历了太多的调试和处理,最后又经过大概一个月的时间,《不可思议之梦蝶》每个场景在Switch上都可以稳定在30帧以上,当然也关闭了一些功能。
再说再一些其它经验。使用Post-Processing Stack后期处理特效包对屏幕特效做处理,它在Switch这类移动平台的开销是非常大的,特别在CPU占用上是很大的。
经过我们调试,后期处理中动态屏幕AO和Bloom效果的占用都比较大,我们最后一定要想一些替代方案。如果可以接受的话,就把它直接关掉。
我的分享到此结束了,大家如果有什么技术上的问题,可以邮件联系我,咱们一起切磋,一起交流,谢谢大家 !

小结

我们感谢队友游戏制作人李喆给带来的精彩分享。更多Unite大会精彩内容分享,尽在Unity官方微信:Unity官方平台。 观看部分Unity官方视频,请关注B站帐户:Unity官方。
Tags:
Unity China
675
Comments
X
XIONGSONGLIN
2 months ago
写的很详细有针对性 学习了 感谢作者
0