所有分类
  • 所有分类
大型游戏中UI优化原则汇总

大型游戏中UI优化原则汇总

一般在大型重度游戏(比如MMO,MOBA,SLG,FPS)的制作中,由于游戏地形大,玩家多,界面多,性能的优化就是重中之重的工作,而UI的优化又是性能优化工作中很重要的一部分,如果UI的优化做好了,会对游戏整体性能的提升有很大的帮助。那么UI如何优化呢?下面我们来详细说...

一般在大型重度游戏(比如MMO,MOBA,SLG,FPS)的制作中,由于游戏地形大,玩家多,界面多,性能的优化就是重中之重的工作,而UI的优化又是性能优化工作中很重要的一部分,如果UI的优化做好了,会对游戏整体性能的提升有很大的帮助。那么UI如何优化呢?下面我们来详细说一下:

一、图片的大小和格式规范

1)最好不要超过2048*2048

2)最好都是2的n次方(128,256,512,1024,2048)

3)最好都是方的(1024*1024,512*512这样的,不要1024*512这样的)

要压缩,选以下格式:

美术刚开始作图的时候就讲明一些规范,省的美术返工:

1)能共用的图片就共用:比如窗口的底图,边框,按钮的底图,边框等。不要把上面的图片设计的非常繁复,窗口,按钮尽量设计成一样的。

2 )一些图片能用九宫格就用九宫格

二、图集划分的粒度

1)共用的common不能太大。

2)一个功能一个图集 登录,背包,技能,角色,商店等。

3)一同出现的最好一个图集,比如主界面一个图集。

三、ABA的问题

ABA问题就是如下的问题:

如上图所示,底图ImageA蓝色背景 使用A图集,中图ImageB鬼头图标 使用B图集,

上图ImageA战力文字 使用A图集。三张图片,两个图集,本来应该是2个drawcall,但是因为两个使用相同图集的图片中间夹了一个别的图集的图片,打断合批了,所以是3个drawcall(如下图,Batches就是drawcall,基本是2,加上UI的3个)。

如果把中间的ImageB隐藏,发现Batches变成了3,一下少了2个drawcall。

在UI制作的时候一定要避免ABA的情况,想法变成AAB或者ABB这样的情况。

四、动静分离

动静分离就是说同一个界面下的UI,可活动的元素(血条,蓝条,伤害数字,CD)放在一个Canvas下,不可活动的元素(人物头像,商城,和平,抽奖等按钮)放在另一个Canvas下。虽然两个Canvas打断了合批,但是却减少了网格的重建时间,总体上是有优化的。

为什么要避免网格重建那? 如果重建的网格过大,就会很卡。比多一个drawcall还卡。

假如同一个Canvas里面有100个Image,Canvas将会把100个单独的Mesh合并成一个大的ShareMesh,用于渲染。

如果刚好这100个Image都是使用了相同的图片或者是同一个图集里面的图片,那么由于使用的Mesh只有一个(ShareMesh),假如UI元素非常多,ShareMesh可能有2M大小(这是一个比较极端的例子,实际上一般的ShareMesh都是几百K,出现这么大的ShareMesh本身就需要注意了),材质球都是同一个(内置的默认材质球),贴图也是同一张,所以得到的结果就是,DrawCall只有一个。

如果这个100个Image是不会动的,合并ShareMesh没有太大的问题

但是如果是上面的血条,蓝条,名字板,CD,文字聊天信息这些需要动的UI元素和其他UI元素合并同一个ShareMesh的,那么问题就来了,血条由长变短,顶点发生了改变,导致2M的整体ShareMesh也需要重新的生成顶点信息,并且整个ShareMesh重新渲染,这明显是得不偿失的。

当然动态的UI还包括文字部分,其中Text是UGUI产生顶点数量的重灾区,一个字符产生4个顶点,如果再加上Shadow则相当于又把Text复制了一遍产生8个,

Outline则会将Text复制4遍产生20个顶点。所以Shadow、Outline不但会产生额外的OverDraw外还会产生过多的顶点数,

一定慎用,确实需要请选择用图片背景替代,其次选择相对较省的Shadow。

五、动态图集

所谓动态图集,就是图集是在游戏运行过程中生成的,而不是在游戏制作阶段生成的。程序生成一张或n张较大的Texture图集(根据项目需求,可以设置Texture大小为1024*1024或2048*2048等等),Image加载进来的Texture不直接使用,而是将Texture信息按照一定规则和排列拷贝到这张Texture上,以达到n个Image共用一张Texture,合并Draw Call的目的,同时Image销毁不用之后,Texture信息从大的Texture图集中移除,达到图集空间重复利用的目的。

什么时候需要打动态图集那?

我们先来看看静态图集的缺点:

1、如果某个界面只需要出现一个图集中包含的小图标(比如掉了一个物品,学会某种技能),这个小图片是包含在一个大的静态图集里的,那为了显示一个很小的图标,就得加载一个很大的图集,从而导致打开该界面很慢(由于加载大的图集)。

并且后期热更新的时候,如果修改或者添加一张图片资源,那么就意味着要更新整个图集的资源。

2、那打成多静态个图集那?这样只有一个图标的界面没问题了。有多个图标出现的界面就有问题了,加载的也多,drawcall也多,并且为了合并Draw Call不被打断,要小心地设置UI的层级,避免ABA问题造成合批被打断,操作复杂度就提高了。


物品图标打了多个图集

一个界面显示多种物品图标

下面demo只是简单的演示一下动态图集的主要思路,图片分配算法也只是将大图片分成64×64的一个一个分区,每个分区采用引用计数开控制是否在使用图片,用于维护整个UI系统的话,这种算法并不适用,但是如果只是用于icon图标的话,由于icon图标是固定尺寸的,所以这套算法就很合适了。

动态图集的缺点:当然动态图集也是有缺点的

1、动态图集因为将图集的生成过程延迟到了游戏运行时,所以必然会比静态图集多了图集生成的成本,当然这也是可以优化的。

2、并且在目前的动态图集生成方案中,还没有出现公开的支持压缩的动态图集解决方案。

3、还有一点,静态图集由于图片在生成过程中是确定的,可以将分配算法做得很好,图集的利用率也能做到很高。动态图集由于图片是动态生成的,在游戏运行过程中也会动态的增减图片,类似操作系统的内存分配算法,图集必然会出现碎片,图集的利用率也不可能做得很高

总之, 如果能把以上五个方面都做到了,那么UI的优化就不成问题。当然有的项目不需要都做到,做到其中几部分就可以了。也有的项目需要做的比 上面的还多。这都得具体问题具体分析,如果游戏中3D场景,人物,特效部分优化做的好,那么UI的压力就小点,如果3D部分优化的不好,那么UI的压力就大点,需要优化的东西就多些。

本页地址:http://www.uiya.cn/27398.html; 所有素材均来自于互联网,经网友投稿后发布,仅供学习请勿商用。如有侵权,请联系 3147141550@qq.com 或 提交工单

分享海报

评论0

站点公告

 

新注册用户福利,免费领取7~90天VIP会员

点击领取

没有账号? 注册  忘记密码?