Unity Draw Call优化总结

游戏开发到后期,不得不面临性能优化的问题,而提到性能优化就绕不过Draw Call的优化。本文简单的总结了下Unity里各种Draw Call优化手段

批处理

说到Draw Call优化,最简单最容易想到的就是批处理(Batching),Unity里批处理分两种,静态批处理和动态批处理。不管哪种批处理方式都有一个相同的前提,就是材质相同,如果两个物体材质不一样,批处理是无能为力的。

静态批处理针对的是静态的不移动的物体,我们需要做的就是将物体设置成static。优点简单直接,不需要额外的处理,缺点就是会增加内存的消耗,比如100个相同的Cube,Batch之前内存里只有1份mesh数据各个Cube共享,Batch之后,100个小mesh合并成一个大mesh,占用内存*100。

动态批处理看上去似乎比静态批处理还要简单,因为我们啥都不需要做。但是,事情远远没有想象中的那么简单,其中的细节还是挺多的,Unity中动态批处理也不是单一的方案,而是对于不同的Renderer不同的处理方式。

对于Mesh Renderers来说

  • 批处理动态物体需要在每个顶点上进行一定的开销,所以动态批处理仅支持小于900顶点属性的网格物体。如果你的着色器使用顶点位置,法线和UV值三种属性,那么你只能批处理300顶点以下的物体;如果你的着色器需要使用顶点位置,法线,UV0,UV1和切向量,那你只能批处理180顶点以下的物体。
  • 不要使用缩放尺度(scale)。分别拥有缩放尺度(1,1,1)和(2,2,2)的两个物体将不会进行批处理。统一缩放尺度的物体不会与非统一缩放尺度的物体进行批处理。使用缩放尺度(1,1,1)和 (1,2,1)的两个物体将不会进行批处理,但是使用缩放尺度(1,2,1)和(1,3,1)的两个物体将可以进行批处理。
  • 使用不同材质的实例化物体(instance)将会导致批处理失败。
  • 拥有lightmap的物体含有额外(隐藏)的材质属性,比如:lightmap的偏移和缩放系数等。所以,拥有lightmap的物体将不会进行批处理(除非他们指向lightmap的同一部分)。
  • 多通道的shader会妨碍批处理操作。比如,几乎unity中所有的着色器在前向渲染中都支持多个光源,并为它们有效地开辟多个通道。预设体的实例会自动地使用相同的网格模型和材质。

除了这些严苛的使用条件,动态批处理需要在CPU端将顶点位置转换到世界空间下,如果这块的开销大于Draw Call本身所带来的开销,动态批处理就很有可能变成了负优化。

对于Particle Systems, Line Renderers, Trail Renderers这种需要动态生成几何体的组件来说,Unity采用了一种不同的方案,简单来说就是数据打包成一个大VBO,一次提交,通过offset多次Draw。之所以采用这样的方案是因为,对于现代GPU来说,一次渲染的消耗,大部分来自于设置管线状态提交数据,而Draw Call本身的开销其实并不大(大概82开)。对应到Unity,就是SetPass Call的开销要远大于Draw Call的开销,这也是为什么Unity的Statistics窗口显示的是SetPass Calls这种数据而不是Draw Calls。

网格材质合并

批处理要求相同的材质,而且处理不了Skinned Mesh。为了解决这些问题,就需要我们手动合并,这时就可以借助于类似MeshBaker这种插件,进行网格材质合并,把同一个Shader的物体统一合并成尽量少的贴图和Mesh。这种方式本质上依然属于Batch的范畴,只不过相对于Unity自带的批处理方式,我们可以手动的控制哪些物体进行合并,这样随之而来的问题就是合并的尺度,尺度太小,优化效果不明显,尺度太大,可能负优化。

剔除

这里说的剔除不是GPU端的剔除,而是CPU端剔除,Unity支持两种剔除,视锥体剔除跟遮挡剔除,视锥体剔除是全自动的,不需要我们参与,视锥体外的物体不会进行渲染。遮挡剔除只支持静态物体,需要我们手动控制,我们需要将物体设置成static,设置完成之后进行烘焙,烘焙好的数据供运行时使用。Unity里的剔除是Object-Level的,某个物体要么剔除要么不剔除,不会出现只剔除某一部分的情况。所以上文说的MeshBaker合并,如果合并的尺度过大,会导致本该剔除的物体被渲染。

GPU instancing

GPU instancing的原理是对于模型一致的物体,只提交原始的模型的VBO给GPU,然后将每个物体不同的属性单独抽出来组成buffer发给GPU,在显卡中根据这一份VBO和每个物体不同的属性来绘制多个物体,即一次提交,在GPU上绘制多个,对于大量同样模型的物体绘制是一个很好的方案。相比于动态批处理,没有合批的消耗,没有顶点的限制,也没有内存消耗的问题,唯一的不足可能就是不支持Skinned Mesh。

现在的问题就是如何让GPU instancing支持Skinned Mesh,办法总归是有的,那就是GPU Skin。我们知道Skin(蒙皮)是对mesh上的顶点进行变换,在CPU端实现会带来极大的性能限制,而顶点变换这种需要并行处理的问题正是GPU所擅长的。GPU Skin在GPU上并行的对mesh上的顶点进行Skin变换,可以极大的提升效率。GPU Skin本身并不能降低Draw Call,一旦当我们在GPU上实现了Skin,Skinned Mesh Renderer就可以替换成常规Mesh Renderer,GPU instancing就有发挥的余地了。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,290评论 4 363
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,399评论 1 294
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 109,021评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,034评论 0 207
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,412评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,651评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,902评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,605评论 0 199
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,339评论 1 246
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,586评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,076评论 1 261
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,400评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,060评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,083评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,851评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,685评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,595评论 2 270

推荐阅读更多精彩内容