18年经验莉莉丝技术美术总监:如何让iPhone和低端安卓机都有杰出画面体验?

文/ 呆嫖 2017-05-15 11:33:57

5月13日,在Unite2017开发者大会上,莉莉丝技术美术总监李靖做了一则题为《如何在移动平台打造自适应画质的游戏》的演讲。

ll1副本.jpg

莉莉丝技术美术总监李靖

李靖曾在育碧先后担任资深美术关卡设计师、技术总监(美术)、资深技术总监与上海工作室美术技术发展经理,并于2016年2月加入莉莉丝。在18余年的工作当中,他在技术美术领域积累了相当丰富的经验。

以下为演讲实录:

大家好,非常荣幸这次Unity邀请我参加这次分享会,也很高兴跟各位见面。我是技术美术,在这个行业工作了18年左右。今天这个题目是怎样去制作一些能够自适应不同机种画面的游戏,或者是其他的一些多媒体方面的东西。

我今天会说到三个模块,第一个模块是介绍一些和硬件,或者和软件,其实就是和使用环境相关的知识点;第二块可能会说一些在制作这一类需求的时候,应该注意的技巧和知识;第三块是我个人在工作中总结出来的,一部分工作的实例。

我们先从第一部分开始,现在手机平台已经发展了很多年,硬件的种类非常之多,多到什么程度呢?多到至少个人几乎没办法统计这些设备。分几块来说吧,这几块都是和我们要做不同画质的游戏相关的一些硬件的支持。第一块就是SOC。

ll2.png

SOC是什么,SOC不是CPU,SOC包括CPU。简单一点来讲,就是在一块芯片上集成了几乎整套系统,我这边有一个高通的例子,其实就包括了显示试配的芯片,包括GPS定位的一些芯片。还有联发科的芯片,还集成了内存,这个内存非常容易和CPU、GPU封装在一起,合成一整个芯片,然后给到厂商去使用。

这点其实非常好,但是千万不要认为手机里只有一个CPU,其他的都是分开的设备。如果这样认为,可能针对性的优化就非常难去实现了。

我们来说第二个,GPU。

ll3.png

当年这个领域是列强纷争,现在能够存活下来的基本只有这三家,还有在后面会提到的另外一家,这三家,一是Imagination,这是最最有名的,因为它是苹果设备的GPU的官方授权商。当然它在安卓上也有一部分的客户,尤其是联发科,会使用其部分的GPU。

另外两家基本是独家,高通一个有Adreno GPU,这是整个移动图形部门收编后新的产物;第三就是ARM自己做的MALI。前面还提到一个,相对目前在移动平台上使用不是那么广但,作为在PC显卡是行业老大的nvidia。但是在移动设备上功耗我觉得做的还是稍稍欠缺一些,所以说厂商选择它的可能性比较小。

这里是和内存相关的,但是我这边没有写内存,写的是它的一个极其重要的指标:带宽。这边有一张图:

ll4.png

可以看到从2016年到2018年,PC端的那个主流的内存是DDR4,比较主要的显卡是GDDR5,Y轴都是以Gbps为单位的。手机内存会用到的是中间那条绿线,它的内存的带宽远远小于桌面级的GPU,这也就代表在移动设备上,我们开发那些图像类的作品,完全会受限于带宽。

右图右侧相对于带宽指标也重要,就是耗电性,这就是为什么带宽在移动设备上不够大,因为要考虑耗电,手机由电池供电,不是PC插一个电源随便用。电池耗尽了,用户体验就很糟糕,大家都抱怨苹果手机、安卓手机都只能一天一充,为什么诺基亚时代的神话没有了,这其实跟我们使用硬件的规格越来越高,越来越难控制有关系。这些东西都是一些硬件上的知识,可以对于你做优化有很大的帮助。

有很不同类型的硬件,如果把所有组合加起来会上千种,但是都有同样的问题就是发热还有电池消耗,这是一个恶性循环。

ll5.png

越发热电池消耗更快,然后电池没电了,游戏结束了。我们做弹性画质的一部分目的也是为了避免这样的问题,尽量延长玩家的设备的使用时间。在某些情况下,可能我们还要牺牲画质,或通过其他的方式来实现,所以这个对于用户体验来说还是很重要的。

前面大概综述了一下硬件上的不同,其实还有第二块就是软件。首先从操作系统层面来说,IOS和安卓是目前来说永远不会变的两个主题。

ll6.png

两个系统其实都不错,但是完全不一样。IOS封闭,好处是开发会很容易,因为设备的碎片化也没有那么厉害,并且对于后台进程的管理等等都非常严格,所以不会产生那种后台的进程在拼命地影响前台,或者说是消耗CPU、GPU资源的状态。

但是安卓的话,因为比较开放,它可以给开发者带来很多想象力,可以做很多苹果上面做不了的事情,确实是这样。但是它也有缺点,就是它的生态来说,会相对比较混乱一点。可能只有部分厂家会去完全根据安卓的那套规范去做产品。有些不好的小市场,可能会捆绑很多东西,带来的问题就是你的手机耗电非常快,并且在运行你的前台程序的时候,发现效率往往是和这个级别的硬件是不成正比的。这就是操作系统上带来最大的问题。

还有不同的是,Graphics API,这是跟驱动仅仅相关,API是需要显卡驱动,很少有人在一平台上提到显卡去这个,但是确实存在,任何硬件都是需要软件去驱动的,只不过不像PC端大家会说,现在N卡、A卡通过升级驱动,游戏跑的更快了,他们做了一些优化。

其实在手机平台上,同样有驱动这个概念。但是它的驱动是整合在系统里面,所以一般用户没有办法升级它。所以如果需要新的Graphics API,其实需要驱动的升级支持,比较传统是PC平台微软的DirectX还有OpenGL。

ll7.png

通过OpenGl我们有opengl es版本,但是这很古老了,还是上时代的产物,所以像苹果及OpenGL基金会都忍不住,也开发了全新的API。苹果的是Metal大家都在用,iPhone 5s就已经支持。OpenGL基金会开发出的新API vulkan也已经出现在今年的新设备上了,这些新时代的API给大家带来的好处就是,可以提供新的画质上的提升点,同时还可以提高渲染的效率,这可以让电池耗的更慢,这个外面有一个Mali展台,他们有这方面的展示,就是解释这个能源消耗的一个问题。

软件还有很多不同。Unity带给我们相同的语法,这个帮助极大,如果用其他类型的编辑器引擎的话,可能就要维护多一些,这个节省的成本非常可观。它的语法很简单,先定义属性,其次subshader块,再通过标签,通过pass来区分,渲染的顺序,包括渲染的状态等等。

综上所述,苹果已经有了很多设备,安卓的设备更多,那么首先我们要预知到,当前的硬件设备是属于哪个级别,如果知道了,你可以进行下一步操作,针对不同的因素,可以做减法;或者针对更好的设备,可以做怎样的加法。

首先IOS比较简单,Unity本身就提供,你只要用这个函数返回一下就知道当前的设备是什么,是属于第几代iPhone,或者第几代iPad,至于安卓就更加复杂,话题就很沉重了……

ll8.png

但是Unity提供一部分的功能,你可以通过UnityEngine.Systeminfo可以获得想要的东西,包括CPU、最大的显存、CPU架构、CPU的频率这一类,但是其实你光用这些东西综合出一套自己的算法来评估其实还不够。我觉得最重要的是通过维基百科这个平台定义一份自己的表格。

ll9.png

因为现在大部分游戏都有配表,这是一张设备适配表,大家看第一屏,第一屏是把它分成了几种设备,还有是GPU,后面有一个Lv,然后是注释,这都是iOS的设备。因为iPhone每一代都是一个SOC,你可以通过查维基百科上,这一类的GPU的Gflops是多少级,这是第一点。

ll10.png

第二点,它支持3.0还是2.0?显存最多有多少?通过这一点我可以得到一个结果,现在的分类是,大家可以看到Lv是-1,在我这边-1的意思,其实就是我测试机最低标准以外可能会有不兼容的状态,而且它们都很低端,都是opengl es2.0。我开发的一些图形上的特性可能需要es3.0以上,那这些机器基本上可以排除掉。或者以后根据需要对它们进行支持,可以通过写一些扩展,或者其他的方式,来增量解决兼容性的问题。现在最新的设备是iPhone 7 Plus,它显示的效果会不太一样;iPad也是一样,也是同样的一个逻辑。

ll11.png

这边大家看到,设置这一栏没有东西了,因为安卓你如果去用设备来分的话,你这个表就非常非常长,不可能统计。所以我用GPU来统计,这相对容易一点,尤其是高通和PowerVR。高通每代对应的GPU是不一样,能很清楚这个相对应的SOC是什么,大家都知道,今后因为苹果和PowerVR合同解除的关系,imagination必然越来越加强安卓阵营的投入。

联发科的新SOC Xelio30,包括其他后续的产品,很多都是PowerVR GPU,还有Mali的GPU,这个也很容易区分。像MALI 400系列,T600系列,T700系列,包括现在的GT系列都是如此。

所有这些信息,包括厂商,SOC细节等,在wikipedia上都有,我认为有想法的人可以整合出更完美的表格。譬如打开wiki就可以查到,现在的SOC都是什么制程?GPU核心是什么?你可以做出一份比较详尽的档次表。

光有这点还不够,你还要去使用自己算的表格,如果这些条件都没有达成,那这个机器怎么处理?譬如新出了iPhone 8,厂商没有及时更新自己的表格,这边认出来就会是iPhone unknow。所以需要再制定一些规范,这个CPU主频怎么样,内存有多少,通过这些方法来决定这台机器可以显示什么效果。

前面关于软硬件环境的部分基本上都讲完了,其实最最重要的是首先知道差异化,并且知道这些东西和图形渲染是直接相关,可能不一定需要知道太多的细节。因为我们并不是硬件工程师,也不是做系统,也不是做驱动的,我们是做产品的,需要判断出什么是好硬件,什么是坏硬件就可以了,免得做盲目的优化。

这边其实也要稍稍吐槽一点,就是国外的硬件比较均衡一点,但是国内的稍微偏激一点,在某一块会做的比较主打。比如我这边是10核心的CPU,很棒,但是不提GPU,可能GPU就不是那么好。主打什么,那块肯定没问题,其他都是短板,这就造成很多机器的综合性能并不高。

说到短板,到了第二环节,我们要做的是什么?我们要做的是让整个渲染的效率没有木桶效应,一旦有木桶效应,那它就有瓶颈。

ll12.png

ll13.png

其实最最常用,每天都会用到的工具就是Unity中的Profiler,这个非常好用,因为能看到非常多的信息,并且能够有一个大致的评估范围。比如说CPU里面,CPU这一块到底是什么东西比较费,是Rendering比较费?还是脚本比较费?还是物理比较费?都是非常明确显示在里面。

并且CPU这块还能通过把左下栏那块表,细分出到底是什么函数比较费,可以做一些定位,如果切成另外一个界面。现在这个叫hierachy(层级视图),在工程设置里面,你可以设置成多线程渲染,就能看到现在的情况到底是CPU在等GPU,还是GPU完全不是压力,压力全部在CPU,因为多线程,渲染线程是分开的,并且有一个事件waiting for present,这个事件告诉其他硬件GPU当前在忙,你就等我吧,等我结束了就告诉你了。通过这个例子其实很容易知道,当前开发这款产品,你是逻辑上出问题了,还是渲染的东西过多,已经超过这个GPU能够承受的范围。

包括Rendering也会提供很多消息给我们。如果说我发现我们渲染的东西,GPU并不是很费,大部分时间都在CPU,看一下Rendering,这个也非常高,是不是没做batch(批处理渲染)?或者渲染的东西有问题,或者超标了?这种东西好处还在于可以连到真机进行调试,直接接上iPhone、安卓都可以跑。

像PowerVR的显卡如果顶点流超过范围,就会绘制两次,那时间就是双倍的,所以能看到详细信息。内存和我们这边就关系不大,略过。还有物理的也是一样,物理的话能够看得到当前的激活状态的有多少,当然越多越费。但是这边也要提到一点,你是不是简单的造型?如果都是复杂的造型或凸面体当然很费,如果是简单的造型其实就还好。

除了Unity内置的Profiler,如果需要更详尽的数据,我这边推荐不是三大厂家的,而是Nvidia Tegra Graphcis Debugger。它的一个好处在于可以很容易查看一帧绘制的整个过程,并且可以看绘制的结果,就和Unity的一个功能很像;

另外一个好处在于,你可以即时修改shader,这个时候就没有Unity的帮助,你得注意自己的语法,是GLSL的,还可以通过一些简单的参数的测试。比如说我不知道我现在的渲染的瓶颈到底在哪里,我试试看,把所有贴图就换了,点一下texture替换为2x2像素试试,发现帧数好了,那我知道了,我的贴图有问题,贴图换成2×2代表什么?代表你的带宽被撑满了,内存来不及传输了,你就知道针对点了,也知道在比较低端的平台应该怎么做。或者你也可以把深度测试关掉关掉,不比较Z,通过这样的排除法来替换,能知道这个场景,这个产品到底有什么问题在里边,这是一个方法。

当然另外三大厂商的GPU也可以用,只不过会相对麻烦一些,其实它们的用途作用是一样的。除了使用Profiler工具以外,我们还知道一些知识点,只有这些知识点都被解决了,你的渲染才不会成为整个游戏的瓶颈。

第一个其实解决Draw-CallS和batches。

ll15.png

你把Unity中的标签打开,Unity在运行的时候,会把这些标上Static的东西合并成一个,这个其实也是要看情况使用,不是说你把整个场景所有的东西全部合并效率就是最高的。因为Static batches有一个内存拷贝的问题,它会生成另外一份合并的内存,原来的资源都是在的,会生成一个新的。一般不会占用太多。但如果做的游戏是针对非常非常低端的设备,可能内存本来就非常捉襟见肘。

第二比较多的就是Dynamic batches,这个限制非常多,能够符合标准的那些物件,就是他们的材质是相同的,然后他们的transform,X、Y、Z ok,它们小于900 vertex attributes就可以合并在一起。

现在有一个方法是Instance rendering,使用相同的材质,可以批处理,这个其实是API相关,Opengles2.0就不支持,我们可以使用这样相对高级的方式,但是这个需要大家去改动shader才能实现。标准的Unity里面有专门的shader支持instancing,这些可以做到批量绘制,但如果使用自定义shader就需要自己维护。

就渲染的优先级来说,static模式最高效,最快的;第二是instancing rendering,最后是Dynamicbatches,所以使用优化技术的时候,大家可以有一些侧重点。

第二个支持点,是Overdraw,其实就是屏幕重绘。

ll16.png

现在业界还没有完全解决这个办法。这和当前的图形学的基础优化方案是直接有关的,原因在于不透明的物件,renderer会写深度图,第二个不透明的物件,在画的时候,会比较深度,只有在深度合适的情况下,没有被剔除掉才会画。但是透明物件不一样。透明物件因为不会去写深度,也就是你在屏幕上能看到多少透明物件,就画多少遍,可能会非常多。

比如说我们做一个很简单的例子,往这个游戏摄像机的面前扔一颗炸弹,这个炸弹其实在远处爆炸的时候,效果很酷炫,也不是很费。但是扔到屏幕前,它可能就直接爆炸了。我是指设备爆炸,不是指炸弹爆炸……一下子把很稳定的35帧变成2-3帧,这种情况我都遇到过。

针对这种问题,在制作的时候你就要严格注意半透明的层叠的数量,注意他们全部展开之后的总的像素的数量。也有方法能规避掉这些现象,那就是避免在镜头前出现非常多的半透明物件,让它们在远处显示。

还有一块会对性能产生极大影响,就是Shader,这是今天比较重点讲到的东西。

ll17.png

shader在Unity中有两类:surface shader和vertex fragment shader。surface shader可以在非常顶尖的主机,比如如Xbox One上跑流畅,也可以在PC上的状态下有非常好的效果。但是针对手机游戏的话,surface shader虽然做了非常多的优化,但是因为太通用,所以还是比较费。我个人主张,在手机平台上尽量使用vertex fragment Shader。

像素剔除默认就是把背面裁掉,但是有些情况,比如写了一个草的Shader,正反面都能显示,但是美术把这个shader用在建筑上,内部永远不会看到,这样的状态会导致有些情况下是两倍的输出,这个还是需要注意的。毕竟移动设备的GPU shader的流出率不是那么高,计算也差一些。

接下来还要考虑带宽,额外的深度操作就可以占满带宽。举一个例子来说,就是我所有东西都是不透明的,然后我画阴影,另外一个摄像机在不同的角度,要重复画一遍深度图,那就是额外的带宽,可能就会导致翻倍。或者也有可能让你比较低端的机器的带宽直接撑满,做不了其他的事。

还有一点是ztest(深度测试),如果这个设置不对,虽然是不可见,但是开销是实际存在的。

还有一点就是叠加的模式,这种情况非常少,你做半透明,你这个半透明后面被遮挡的东西就没有了,你看到就是一个非常奇怪的景象,除非你需要这样的特效。

下面有几点建议:尽可能把所有的计算放到顶点计算中,因为顶点计算比较省,而且现在的GPU既能处理顶点,也能处理像素,因为在几年前这些处理环节还是分开的。大家都知道,像素的输出永远比顶点多得多,如果说我把所有计算都放到顶点上,在顶点到像素之间做一个差值计算,一个点到另外一个点中间,线性做一些多度,类似这样的方式,把这个计算的结果转换到这个级别,很多计算可以做简化,在这块把它放到顶点,并且保证这个足够强大。

现在手机虽然屏幕不大,再大也就是6-7寸,但是像素的密度极高,分辨率非常高,往往是2K,1080P和720P也意味着很高的代价。1080乘720是多少像素点?屏幕上绘制三遍再×3就是开销。但它直接、、其实可以公式化。在有时间有预算的情况下你应该尽量自己写,这样可以让你的效果表达更好一点,或者走的更节省一点。

这边的话又提到带宽这个词,从这几个点来说,都会带来带宽上的问题。

ll18.png

第一个是贴图的Filtering,就是过滤器,其实从3D世界远近的角度来说,贴图做的越小,还原度会越高,并且和近处的高分辨率的贴图之间的过度得更平滑。但是带来的代价就是它是多重采样,并且有比较复杂一点的计算,而且这个没有太大的关系。因为这个是硬件级别,是直接可以处理的,但是会占用带宽。

第二点是Mip-maps,它在安卓上有意义,在PowerVR的GPU上帮助会有一点,但是非常少,因为使用的渲染方式是deferred tiled base rendering,所以一定要注意这些问题。当然我指的都是3D物件的贴图,2D其实很多情况下大家都不用mipmaps,因为纯粹是浪费。

还有就是贴图大小。贴图大小不光占显存,还会让传输变慢。越是大的贴图,cache miss率会越高,传输效率也越低,这就是恶性循环。

还有一点,就是我们自定义的一些后期渲染用的postprocess,这个越少越好,这也是为什么Unity到现在为止,不建议让延时渲染这样的技术跑在手机上。其实就是因为手机带宽永远不够,根本跑不动,那么高分辨率,同时3到4个gbuffer,没有那么大的带宽。

带宽其实是渲染时经常出现的一个瓶颈。我以前做主机游戏比较多,带宽很大,比如Xbox One的esram带宽就非常大,但是内存很少。我们为了把一个游戏用延时渲染的方式需要的gbuffer塞进去就需要做很多优化,如果放到主存,虽然能用,但延时就非常厉害,没有实用性;PS4用的主内存速度比较好,可以用全尺寸gbuffer。大家在手机上如果一定要做延时渲染,理论上来说也是可以的,但是只能用非常低的画面分辨率,这个画质非常差,优点不足以弥补缺点。

ll19.png

再讲一下我在莉莉丝实现这套系统的一些想法。这个功能其实有一个切入点,那就是quality setting。

ll20.png

它可以把游戏的画质分为Fast、Good等等,可以控制一些东西。第一个是pixel lighting接受的数量,在forward渲染的模式下,你的物件就以多pass的模式画下来,这样的话效率很低。在我这边的demo里面,低配全部是零,最多有一个,不包括太阳光。

第二,贴图分辨率有两个选项,一种是全尺寸,一种是半尺寸,半尺寸在有些情况下解决带宽的问题。还有就是一些过滤方式,是不是基于每张图都做,还是强行都关闭,这个因需求而异就可以。

还有就是soft particle开销很大,会有额外的深度图的输出,其他的一些选项开销都不是那么大,所以没太大的关系。reflection probes我现在没有用到它,其实就是做一些反射的点,在场景里面有很多,还要是实时更新这些probes,对CPU的负担肯定很大。然后还有下面这一块,在我的例子里面,shadow全部是自己实现的,所以在高中低配,把这些全部都禁掉。

还有其他的选项,也会有帮助。像第一个是bone weights,这个是对于蒙皮的骨架数量控制,如果你用CPU蒙皮的话,这个选项的作用就很大,可以控制这个顶点到底由是多少个骨架影响,最终来实现那个运动。

第二个是vsync,vsync手机上一般都不会去开,因为虽然可以帮助画面不撕裂,但是会让帧数跌5帧以上,造成明显的卡顿。还有一点,我用比较多的是LOD Bia和Max LOD,这个我在后面会说到。包括Paticle 射线检测方面的这一块我会降到很低。

还有下面就是异步加载的时间切片,你使用脚本去调用资源相关的东西,这类东西的话,目前在我这个Demo里面没有使用。

先说说第一个,第一个其实就是LOD。

ll21.png

这个其实对应的是前面那个LOD Bias里面的。LOD有几种,第一个是显示模型,就是和显示相关的物件,一类是静态模型,一类是蒙皮模型,可以添加一个LODGroup的组件,有了这个之后,可以有多个模型,根据距离切换显示的等级,可能是越远越简单。通过LOD Bias可以控制这个系数。在最高配的机器上,可能50米以外才会切到第二个等级。

但是如果是非常差的设备,我会把这个系数传的非常小,在5米以外就变成另外一个模型了。对于Particle来说,这块同样是适用的,使用它的话,就把一个完整的Particle system切成不同的分类,使用这个LODGroup,你可以在近距离的时候,显示的是相对精简过的。

为什么与模型的方式不一样呢,这和overdraw相关。因为相对镜头最近的,比如说十米以内,不允许有很复杂的overdraw,必须很简单。10-50米之间,全效果,50米以后慢慢再精简,这样的方法可以让你的粒子在大部分的状态下显示出完整的效果。

但是这类方式也有一个问题,就是所有的这一类,换了LodGroup,必然有一个计算距离,有什么办法可以一劳永逸吗?有一个小技巧,这张图上写的,有一类叫decorations,纯装是的和这个游戏本身的关卡、结构没有必然的联系,一类东西。我把它全部放到一个节点上,在低配或者中配的情况下,把部分的节点关掉,下面所有的东西都关掉,就不要显示浪费性能了。

然后自己再写一点比较有扩展性的东西,我在这边,我把它扩展出了几类。

ll22.png

在游戏中,我们的人物比较小,它不是真实的,但是会拿一个灯光的方向,根据matcap来算出受光面和背光面的效果。就全局上来说,我会使用到场景里面的ambient,但是Unity的ambient会比较多一点变化,比较复杂,所以我们直接提出来,这样的话可以做到,在游戏中,在不同的区域,可以有不一样的效果,它们互相之间可以转换。

还有一类是shadow,因为我shadow完全重写,我的设置全部在这边。还有一个反射源,我会用Unity的reflection probes来生成出需要的资源,有时候会自己手动放一些cubemap在里面,在不同的区域,可以通过把这些做差值,计算出你到底是离哪一个点更近的混合的效果。比较简单的反射的,水面或者PBR都可以用到,基于顶点的也可以放在这儿。

还有这个面板是每个场景,都会有一个,当然也可以有多个,你只要放在那个,每个区域放一个,并且标记好位置,区域也是可以的。这样的话你在不同的位置,可能你全片滤镜是不一样,我这边还有一些全品滤镜的调整。

这边其实就是这边也要写LOD,这个语法很简单,就是利用Shader Lab中的一个LOD的标签。

ll23.png

ll24.png

这个有很多好处,第一个是兼容性很高,兼容性有两方面。一方面是对于美术同学它的兼容性很高,不用高中低配,为了不同的模型指定不一样的模式。它只需要一个材质,这个材质自带LOD,你为这个材质所做所有变化,对于所有的低级的LOD都有意义。

第二种好处,因为这是Unity自带,所以Unity原生的shader都有标好了级别的,这个上官网,帮助里面都有,你可以和你的评估值对比,评估测试一下自己的shader,让你的消耗程度和他写的某种shader差不多,这样的话你的场景中,可以不需要全部自己写shader,一部分的用原生的,一部分用自定义的,就可以解决兼容性的问题。

第二个来说,非常容易扩展,因为LOD随便定,所以容易扩展。

第三个的话是切换很方便,切换其实就是用到了Max LOD。开始的时候,在quaity setting的面板中只要把中间那个max LOD的值改了就自动切换了,所以它很灵活。但是它也有缺点,缺点就是现在变的冗长,修改起来,一下子修改多个LOD,第二块来说,会稍稍多占一点内存。

ll25.png

这边其实很简单,就是提了一下,也可以用Script方式可以切换,所以含这些的,包括的物体,这类物体的Shader会变成另外一种状态。

ll26.png

但是有一点注意,因为写shader的时候经常会碰到一个兼容性问题。其实兼容性问题都来自于两点:是D3DLike还是OpenGlLike,

主要的不同点在于,一个是切线不一样,还有深度方向是相反的。然后数值的精确度,这种全精度、半精度类型等,可能某些Shader对数值精度会很敏感,千万注意这些问题。还有千万不要忽视PC,我一开始写这些东西,经常碰到的问题就是在真机上一切都OK,PC上会报错,因为Unity都是有支持的。那么它的shader在一个装了比较高版本directx(DX9以上)的PC上,那这个shader compiler是不一样的,会严苛很多。所以需要花更多的时间去维护。

ll27.png

最后的话,还有一些小的技巧上的东西,我觉得也很重要。

第一个是后期滤镜,一定要把后期滤镜的合并起来,因为Unity的标准资源包中包括了一部分。但就算用官方的,也是可以合并在一起,这样可以节省rendertexture的数量,提升在一帧中不同阶段的重用率,带宽占用也就少了一点。

第二,尽量使用Unity提供的宏。因为用了shader的LOD及宏控制,一定要放在Shader Variants的容器下,并且挂载到quality setting中,这些shader在一开始就被预加载,虽然内存多那么一点点,但是在游戏中不会卡顿。

还有就是要注意透明;以及在有可能的情况下,使用一些Culling的方式,自己写一些Culling给的方法,因为Unity都有开放接口,或者使用官方的occlusion culling。

ll28.png

这个就是Demo本身,这个屏幕很大,大家会看到影子是画两层,如果说放在一个非常高ppi设备上,这两层影子就变成软阴影,这本身是一个PBR材质的Demo,现在是最高级别,大家可以看到会有景深,会有bloom效果,还有PBR所有反射还有影子等等。

ll29.png

这是降一档,其他效果都还在,还有影子变成单层,法线贴图没有了。

ll30.png

再降一档(我这边有意做的区别很大)反射没有了,变成这样了,然后后面那些塑料球的质感变化不大,影子变成不受你太阳光的角度控制,变成了垂直的,因为这样是最省的。

ll31.png

然后再往下,高光也没有了,影子也没有了。

ll32.png

再往下,只有顶点光和贴图。

ll33.png

使用到相对比较实际的情况下,是这样,差距没有前面看到那个Demo那么大,这个是全效果。

ll34.png

往下,并且影子那边那辆赛车上只有影子,自投影和地面投影,都有一个影子:

ll35.png

再往下动态投影没有影子,并且反射关闭了,但是specular还是在:

ll36.png

再往下lightmap还在,其他东西没有了:

ll37.png

最后一级,是顶点光照,这些可以写成各种各样不一样的样子,可以做的就是会更好一些,或者说是差距再大一点都是有可能的。

ll38.png

今天我分享的内容就到这里,时间有限,谢谢。

Alex Matveev
2022-06-06 16:27:13
不合规
审核中
@苏某某: 她在音乐方面的喜好,以及对天文的兴趣,也源于这部动画的影响。一直很喜欢爵士乐的她突然开始想
乐方面的喜好,以及对天文的兴趣,也源于这部动画的影响。一直很喜欢爵士乐的她突然开始想,没有系统了解过此类音乐的她怎么会喜欢上 呢?后来听完《美少女战士》原声带后才发现,“原来我在那么小的时候
评论全部加载完了~