在成功实现了同时烘焙LDR和HDR两种资源之后,就必须面对一个很棘手的情况了 - UE4烘焙出来的材质占用容量太大了。

       相信很多刚用UE4的porn友,都被UE4烘焙时超慢的速度和烘焙后超大的包体所震撼。在我实现了同时烘焙HDR和LDR的两种材质的功能之后,包体体积再度变大,大到了老大很不爽。那就得优化啊。

       UE4通过修改ConsoleVariables.ini中的r.DumpShaderDebugInfo变量,可以将烘焙过程中的shader的源文件以及编译结果导出。对于feature level ES20和ES31,编译的结果自然是GLSL。相信dump过结果的porn友们应该都对Unreal的usf文件不太爽,因为200kb的usf文件,编译成glsl可能只有十几kb,而uassets存的还是ushaderbytecode,还会根据光照方式,动态光源个数,LDR/HDR,skylight等,将烘焙的结果不断的x2,所以烘焙出的材质就很大了。

Opti 1: bShareMaterialShaderCode

       优化1:各材质的shader不再用inline的方式处理依赖,而且继续使用include的形式。启用这个选项,需要在UE4 editor的项目属性中,修改Packaging下的bShareMaterialShaderCode变量,开启,就可以使材质共用通用部分,而不再使用函数inline的方式独立。开启此项之后,我原来2.02G的包体,变成了1.63G,小了接近400m,非常明显。

Opti 1: bSharedMaterialNativeLibraries

       优化2:将材质shader以各平台最终结果的形式保存,而不以UE4的中间代码保存。。启用这个选项,需要在UE4 editor的项目属性中,修改Packaging下的bSharedMaterialNativeLibraries变量,开启。这个属性在UE 4.16版本中貌似只对metal平台生效,而在UE 4.18版本中,需要在启用bShareMaterialShaderCode的情况下,才能启用。使用此方法之后,包体体积将进一步减少。

一些废话

       谈一谈UE4在桌面和移动平台优化的问题吧。经过接近三个星期对UE4代码的阅读,渐渐发现UE4代码在优化思路上的一些问题。UE4作为优秀的PC和console引擎,对于PC和主机平台确实做了很多优化。但在进行移动开发的时候,这些优化可能就变为了负优化。一个比较明显的情况,就是上面对于材质的处理情况。将各个材质完全独立开来,毋庸置疑在材质cache之后,能加快材质渲染时的效率。但是,这样会增大包体体积,也会增大内存占用。对于我们现在的测试包来说,差不多是400m的安装包容量和50m的内存占用,这两点对于移动平台开发,貌似都有点严重了。看来UE4要在移动平台使用,那要做的优化还有不少。

       压缩会减慢程序运行。这个是很多新人(当然也包括我),都犯的一个错误。就是想当然了。实际上很多时候,压缩不仅不会影响程序运行速度,甚至会提升程序运行的速度。压缩之后会便随解压,解压会让程序运行时间变长,所以压缩程序会让程序变慢,这个是一般思路。但是实际程序运行时,包体压缩,会减小数据加载的时间,也就是减少IO的时间。CPU运行程序解压,总比加载文件快多了(除了使用很变态的压缩算法)。这也是移动GPU上使用贴图压缩能让渲染效率提升的原因。