[实践通才]-Unity性能优化之Drawcalls入门

Drawcall到底什么
CPU做渲染肯定要,而每一个Drawcall要做很多前提工作,所以减少了Drawcall等于减少了CPU工作量,从而提升了游戏流畅度
(这个逻辑。。。。网上都这么传。。。。但其实是很有有问题的,我游戏Drawcall很大,但是要是我的CPU性能够,只要游戏需要的性能不超出游戏的所需要的性能,那么游戏还是很流畅的。减少Drawcall是否那么必要?)
Drawcall对游戏的实际影响
以下所有实践都是基于这个“运行时DEBUG”
实践一:Drawcall是动态变化的
Unity本身已经提供了大量运行时Debug的工具, 基于Unity5.6
例如。右上的Stats面板可以看到Drawcalls, 据说Unity5.x将Drawcalls改成Batches
 
运行过程中,点击按钮,Batches会动态变化
 


实践结论:

*移动过程中,Drawcalls会达到峰值,如果玩家不操作摇杆,固定在一个画面,其实Drawcalls会达到一个固定值

    

*没运行时,也可以增加Drawcalls,运行后Drawcalls不见了,后来发现是静态对象,Static的是否勾选影响Drawcalls的多少

*参考的是网上的一个视频,却用的不是网上的示例,其实用自己的素材代码测试的理论其实相同,这种实践类源码用标准的示例其实也没什么作用

*所有的实践目前只是在Pc Editor上测试(选了Android平台),但并不真实代表Android 或者IOS真机的情况


实践二:Drawcall达到多少才会达到游戏卡顿感
方法很粗暴,直接克隆GameObject
直接上5W个,FPS马上掉到10
 
试试1W个?基本上达到30FPS
 


Verts,顶点个数由10几K ->  接近20M ,而Profiler虽然有峰值,基本上认为它是能达到30FPS,这时候可能马上有人跳出来说,峰值那么多0FPS都有,怎么是30FPS呢,至于1个测温计如何测量温度,随机抽样,插值法等等高深测量方法不在这里讨论,
有一个比较科学的观点是:测量方法是有很多种,有很多被一些人做科学依旧拿去用了,而正在被创造出来的测量方法也不少,
这里仅仅只是用了Unity 的Stats面板和Profiler这2个工具做了一些实践,然后告诉你结果
 
 
上面只是前菜,真正的实践才开始
实践2-1,跳到第二个地方(同一个场景)
 


  
*Draw Calls明显减少,摄影机视觉范围内没有了刚才爆测的GameObject
*但其实还有峰值,这明显也是刚才的爆测造成的,虽然已经没有了Drawcalls,这是不是可以证明GameObject对象多了,就算不是Drawcalls也可能会造成卡顿,
实践2-2,跳到第三个地方(同一场景)
 
  
*DrawCall回来了,FPS明显又掉了
实践2-3:重新跳回游戏开始第一个地方
 
  
*Drawcalls还是很大,那是因为树后面就是刚才爆测的GameObject ,所以好像你看不到,但其实摄影机看得到,而你又不确认摄影机什么时候能看到,所以网上那种优化说摄影机看不到的场景全去掉的解决方案,这种方案真得具体问题具体分析,一般是真解决不了你项目组的游戏优化
*Drawcalls优化的方法,百度能查到一大堆,就不在这里详细说了,这里真的只是做实践


Siki老师的视频试看
看了真的觉得还不错,虽然了老师可能不是故意的,有人也说很简单,但确实通过视频带大家实践了一遍,讲了Drawcalls 基本,Stats统计面板, Profiler工具等


*明天再继续实践其他的优化

*其实我这个博文,又或者知乎和其他的一些媒体,图片有点大,不但看客Load图麻烦,我自己上传也慢,但我明知道却没有优化的,其实没优化,地球还不是照样转,并不是像大家鼓吹不需要绿化,但只是想说嘴上说的容易,至于大家心里怎么想的,而且又有多少人愿意花时间去实践?

相关文章
相关标签/搜索