控制drawcalls，提升性能
首先看下手机场景要求，明确了要求，就会有问题有针对性
drawcalls，控制在100一下，同屏不超过2w三角面。
需要看到远景的用LOD，鸟瞰用低模。
漫游的话就是1、2层精细点，其它粗糙点。
地图面积大，得用分部加载的。
Drawcalls:这个东西值越小，你的游戏性能越好
介绍：在游戏中每一个被展示的独立的部分都被放在了一个特别的包中，我们称之为“描绘指令”（draw call），然后这个包传递到3D部分在屏幕上呈现出来。这就和你希望你的亲友收到准备好的圣诞礼物需要包装好然后穿过城市准时放在他应该出现的地方一样没什么不同。你的CPU来完成包装和传递他们的活，同时会消耗很多的带宽，所以最终分配好这些关键性资源很重要。目前，真正可怕的事情是从“描绘指令”消耗远景开始，每一个独立的飞溅到地板上的血迹和一个角色或者一具死尸消耗的字节是一样的多的。他们都消耗同样的描绘指令。除此之外，没有什么更多的差别。
降低DrawCalls：
那么如何降低 draw call 呢？？那么我们就用到Culling(剔除）技术。如果不应用这个技术，电脑是不管3721把场景里所有的东西都送去渲染的。看得见的也渲染，看不见得照样也送去渲染。很傻是吧，那咋办呢。得告诉电脑，那个你看得见的渲染，看不见的就算了。于是就有了
1.视锥体剔除（Frustum Culling）这个unity系统自带了好像，就不用操心了。
2.遮挡剔除（Occlusion Culling）
Culling的实现
对于realtime interactive 3d environment,现实的速度是非常重要的，虽然现在的硬件能力非常的快，但是要想保持30FPS的同时处理数十万的三角形，以现在的主流机器来说还是非常困难的。
为了解决这种问题，人们提出了很多方法，其中有LOD,有Culling,对于LOD,它可以从2FPS提高到10FPS,但是很难从4FPS提高到20FPS。这两种方法并不矛盾，而且我们往往需要在culling的基础上再使用lod进一步解决pipeline的负担。
这里我主要希望讨论一下culling方面的技术：culling的意思是select from a flock,就是“从一群里面选择一部分“。对于3d engine来说，就是要从几十万的triangle之中选择出一小部分送给pipeline进行渲染。
选择的方法总的来说有如下几种途径：
最简单的就是backface culling,这个已经很普通，我就不说废话了。
然后就是view frustum culling,只选择在view frustum中可见的部分送入pipeline,通常人们会采用hierarchy的数据结构来有效的进行view frustum culling,层次型的结构在各种图形学算法中普遍采用，比如碰撞检测，光线追踪，radiosity等等。我尝试过一种基于AABB Tree的view frustum culling,加上frame coherency,plane masking等优化的方法之后，我认为效率已经非常高了。
但是对于现在的游戏场景viewfrustum culling是远远不够用的，因为view frustum实在是非常的大，现在的场景又非常的复杂，采用view frustum culling对于场景漫游的视角来说,平均可以删除场景中60%左右的数据，对于一个100,000triangle的场景来说，剩下的数据也会有好几万多边形，对于pipeline来说依然是比较重的负担。
不过view frustum culling是最容易实现的算法了，非常的方便和有效，对于一部分3d rpg来说，我认为是一个不错的选择，因为你可以要求camera处于较高的位置，并且总是向下观察，这样用view frustum culling就可以以非常低的代价筛选出很少的一部分场景数据了，对于《格兰蒂亚》,《星辰物语》，还有最新的《绝冬城之夜》等,是足够了，他们对于镜头都有比较严的限制，正好适用于viewfrustum culling.如果大家想做3d游戏，还是先从这类游戏入手的好，因为可以直接集中精力于渲染技术和其他有趣的部分。
但是对大部分第一人称射击游戏而言，view frustum culling是远远不够的，事实上，在实际的环境中我们的视野总是被各种物品遮挡住，所以我们往往只能看到整个场景中的一小部分，远远小于我们的view frustum的范围。这些物品被称作occluder,所以有很多方法就是在考虑如何使用occlusion culling来提高显示的性能。然而，occlusion culling比起view frustum culling复杂度上升的太多，直径也很难找到一个很完美的解决方案，下面我就将现有的一些途径简单的介绍一下：
这些方法都有需要将整个场景进行层次划分(用bsp tree,kd-tree)，分解成一个个cell。可见性判别的力度往往就是到达cell的级别，你可以根据自己需要决定cell的粒度来平衡效率。
先介绍run-time的一些方法：
1.基于portal的occlusion culling,
这是一种基于object space的run-time method,这种方法特别适用于全封闭的建筑类场景，洞穴类场景，因为这些场景有一个特点，遮挡非常明显，比如一个大楼，每个房间（cell)的大部分都被墙壁所遮挡，只能透过少数的门，窗看到场景中的其他部分。对于这种场景，我们可以采用如下的方法进行有效的culling:
首先，识别出场景中每个cell的portal(门，窗),渲染的时候，找到view point所在的cell,然后view frustum从当前cell开始，一次通过该cell的portal来遍历场景，每经过一个portal, 就对view frustum进行一些修正，因为这些portal与视点形成更多的限制，直到看不到任何portal位置。遍历过的cell就是可见的cell.
这种方法对于这类场景非常有效，因为通常我们的遍历透过几扇门窗就停止了。portal需要事先人工设置，或者用算法自动识别。然而对于很多户外场景，很难存在这样的cell和portal,因此对于那些场景这个方法就不适用了。
2.single occluder culling
在portal算法的基础上，这又是一种基于object space的run-time method,这种方法可以用于那些有很多高大的遮挡物的场景，比如大都市，高山环绕的场景。这些场景的特点是，存在很多单个的高大有效的遮挡物，比如大山，大楼，他们往往能够遮挡住viewfrustum中的很多部分。当然对于portal算法对应的室内场景该方法也同样适用。算法的过程如下：
维护一个occluder列表，利用层次性的结构，从视点出发，以从前往后的顺序访问各个cell,判断是否被occluder列表中的某个occluder挡住，如果没有对于该cell中的物体，判断它是否是比较好的occluder(根据它在是平面上的投影面积等因素）,如果是则加入occluder列表，继续遍历。
这种方法有时也会采用一些与处理的过程，标记一些物体为好的occluder,或者生成一些virtual occluder(外形更加简单，近似代替一些occluder）,这些都是为了减少运行时选择occluder的时间，以及让occluder的选择更加有效。
这种方法的缺陷是，无法考虑几个occluder共同的作用效果，有很多东西也许既不能被occluder A挡住，也不能被occluder B挡住，但是有了occluder A和B,你确实看不见这个东西了。所以对于没有非常大的occluder的但是仍然遮挡很密集的场景，比如丛林，这个方法一点用也没有。然而要想在run-time的时候考虑多个occluder共同的影响（在object-space中)，是非常难以做到速度的保证（计算的代价太大）。
3.由上面两个例子，可以看出如果可以考虑多个occluder的作用影响，那么viewfrustum中的部分就可以限制得非常多，而且也可以处理更加复杂的场景。但是像在object-space中处理这种情况实在是很难以很低的计算代价来获得。因此一些基于image-space的方法就诞生了。最普通的例子就是z-buffer.利用image-space来处理的好处就是image-space的可见性是由有限的元素（屏幕上的像素个数）来决定的，比起object-space有很大的优势。但是依靠z-buffer已经到达了渲染阶段，是不够的。有一种hierarchy z-buffer的做法，也称作z-pyramid,因为它生成一系列的不同精细度的z-buffer,比如，最大的z-buffer是32*32的一块suface,那么它生成16*16,4*4,2*2,1*1的另外4级z-buffer,每一级z-buffer对应上一级中的四个像素，并且取其中的最远深度。因此我们在绘制场景的时候可以通过层次性结构，从前往后渲染，并且每次可以先拿层次结构中的结点的bounding box先进行比较（从最粗的那一级z-buffer开始），那么就可以非常有效的绘制遮挡关系复杂的场景。这种方法我感觉非常有希望，但是唯一不足的是如果没有硬件的支持，考软件的方法来实现这种z-pyramid以及相应的检测，速度还是非常慢的。
因此我认为如果以后硬件开始很好的支持z-pyramid,那么这会是一个非常好的方法，说不定会成为一个标准方法，就像现在的z-buffer那样。
4.image-space确实是一个解决多个occluder共同影响可见性的好途径，但是没有硬件的支持，使得他的效率降低。然而对于某些特殊的环境，可以采用一些特殊的方法，使得我们也可以将objec-space和image-space的方法结合起来从而得到一个比较好的trade off.这种场景就是那些2.5d的场景，最常见的就是城市环境。基本上，绝大部分在城市场景的游戏都可以看作是2.5d的环境，可见性的判断只要在2d的基础上考虑一下高度的因素就可以了。
因此这里有一个方法可以有效的处理城市的环境。算法如下：首先将cell的划分严格限制在平面上（比如水平的地面上），比如256*256个cell的方格,大小和粒度可以根据具体的场景来决定。每个cell记录属于该cell的objects(需要绘制的），以及该cell中最高object的高度。为了提高效率，也需要事先标记一些良好的occluder，比如各个楼房的正面，不过这里有一个限制，就是occluder必须是垂直于水平面的矩形。
有一个surface buffer,比如我们这里的是256*256的一块surface对应各个cell,一开始该surface对应的z-buffer都是0，然后我们根据视点选择附近的一些occluder,可以选择上百个，（这是比object-space方法好的一点，一般的object-space算法只能是用少量的occluder）,将视点与occluder形成的shadow volume以正投影视角（从天空上往地面的方向正投影）渲染在我们的surface上，这样surface对应的z-buffer上就留下了该shadow volume的高度，多个shadow volume的影响只要将他们都渲染到该suface上就可以得到，而且这种渲染可以使用硬件加速，所以可以使用许多occluder.最后对于每个cell的可见性判断，只要比较cell的高度和surface中对应的点的z-buffer的高度就可以判断出来了。
这里还有一点需要改进的是，直接读取z-buffer是非常慢的，所以必须用个比较好的办法，将这种信息转换到surface buffer上，将surface buffer的数据拷贝到系统内存中的代价要低很多。
具体做法如下：一开始surface buffer全部清0，对应的z-buffer设置为各个cell的高度。然后关闭z-buffer check和write,现将view frustum以颜色1渲染到surface buffer上，打开z-buffer check,用颜色0渲染shadow volume,最后将surface buffer拷贝到系统内存，数据为1的地方就是可见的cell。
这种方法对于2.5d的城市来说确实是个好办法，不过他也有很多限制，比如对occluder的限制，你可能不得不为此专门写一个编辑器。对于其他全3d的复杂场景，这种方法也不行了。
介绍了这些run-time的方法，我们可以看一下很多preprocess的方法，在run-time的时候计算可见性，对于一个相当复杂的场景来说，代价确实非常高。而事先计算好可见性的一些方法却可以取得非常好的效果。这种方法放弃了计算point to cell的可见性，转而计算cell to cell的可见性，这样虽然增加了可见部分，把一些不可见的cell也送入pipeline处理，但是preprocess却不用占用run-time的时间，这一节省大大提高了效率，因为在很多最坏的情况下，特别是在处理复杂场景的时候比起run-time就非常具有优势。基本的做法是计算出在每个cell中任何一个视点可能看到的其他cell的集合,也叫做PVS。运行的时候只要将pvs中的cell同时又处于view frustum中的cell绘制出来就可以了。然而如何计算出好的pvs却是一件非常复杂的事情。
每个人也有不同的方法，具些简单的例子如下:
1.在portal引擎适用的环境中，利用portal间形成的全影半影来计算pvs
2.在cell的附近，选择一些occluder，然后不断的与周围的某些occluder形成一些virtual occluder(可以这挡住一些比较大的范围）,然后再用这些virtual occluder去计算对其他cell的可见性。
3.有一种针对2.5d的城市环境的pvs算法，对occluder也仅限于垂直于地面的rectangle,基本计算都是在进行2d空间的visibility计算，只在需要的时候才进行高度的检测。还有其他的一些算法，感觉都非常的复杂，我也还没有完全搞清楚，就不在这里乱说了
LOD技术
LOD技术（Levels of Detail，简称LOD，多细节层次）在不影响画面视觉效果的条件下，通过逐次简化景物的表面细节来减少场景的几何复杂性，从而提高绘制算法的效率。该技术通常对每一原始多面体模型建立几个不同逼近精度的几何模型。与原模型相比，每个模型均保留了一定层次的细节。在绘制时，根据不同的表准选择适当的层次模型来表示物体。LOD技术具有广泛的应用领域。目前在实时图像通信、交互式可视化、虚拟现实、地形表示、飞行模拟、碰撞检测、限时图形绘制等领域都得到了应用，已经成为一项要害技术。很多造型软件和VR开发系统都开始支持LOD模型表示。
关于页游以下是我以前弄的一点心得和网友其它人分享的优化方案：
1、将GameObject逐个禁用，确定影响性能的GameObject
2、stats里面的Draw calls & 三角形的个数，尽量减少Draw calls的个数，据说上限是35
3、合并网格物体、合并材质张数
4、不要用网格碰撞
5、Unity对带动作的模型渲染消耗比较大,如果是静态的不带动作文件的模型渲染不会出现效率问题,但是要确保只绘制屏幕内的东西。
6、Batched越高越好, 整合渲染
7、灯光能不用就不用, 阴影用个面代替, 投射阴影和实时灯光,简直就是frameKller
8、模型尽量减少面. 这个和drawCall相辅相成. 我上个游戏满屏只有400面, drawCalls都干到快90了,还一样能跑到30帧在真机上. 当然没有复杂的运动是另个方面
9、模型尽量不要分开, 比如我现在坦克游戏, 车身和履带是分开的, 分别都是一次drawCalls
10、最终输出的时候,在unity - edit - project setting - player 里, 把 other settings - script call optimization 改成 快速, 但没有例外. fast but no exception
低模和高模
大众的通常说法是高模指的面数多的模型，看起来精细。低模指的就是面数低了，看起来当然没有高模细致。 至于游戏一般为什么都用低模，因为游戏厂家要考虑大众的电脑配置了(一般都是用最少的面表现模型的大体形状)。玩游戏的时候模型的每个面都得你的电脑去运算，面数多了无疑就给电脑增加负担使游戏不流畅了。在MAX里，你把一个物体加上网格平滑命令，然后把迭代次数的值调到10 看看你的电脑是否能承受得了，旋转它看卡不卡。
在日常工作交流中，最通常的定义方式就是"用面数定义"。
如：
上3000面的是高模
上4000面的是高模
上4500面的是高模
上10000面的是高模
单纯的用面数来区分"高模"、"低模"的话，不太精确。
百度上的说法：
高模一般经过smooth处理——这是从做法上讲的。
高模一般用于影视、广告。低模一般用于游戏。——这是从用途来说的。
高模一般用于烘培，贴在低模上。——这是从制作法线贴图上来说的。
个人认为， 有一种定义方式比较合理。
对面数有控制的模型——低模
对面数无控制的模型——高模
这既体现了制作方式，也体现了模型用途。
一般来讲：用于渲染的模型，都不控制面数。基本上可以用模型编辑的一切功能达到效果。用于效果图，影视动画，2D游戏（模型变为图片了），法线烘培……
而用于即时显示的模型，需要控制面数，基本使用EditablePoly。一般只用于3D游戏。
也许建筑家装中所用的一个桌子模型是100面，一个3D游戏角色是3000面。 但是桌子仍然是高模。
因为没有人规定你桌子要控制在多少面内。你可是肆意倒角，肆意平滑，只要你电脑扛得住，你高兴，你甚至可以模型做出桌子上的纹理，把100面的桌子做到100万面。
而3D游戏模型，限定了面数。你一定要控制在3000上下的范围内。
总之， 从面数上去定义"高模"、"低模"的绝对错误的。
个人推荐的定义是： 对面数有控制的模型——低模 对面数无控制的模型——高模
渲染调用（Drawcalls）
每个物体的一个不同的材质都会引起一个单独的Drawcall调用。每一次Drawcall都会引起引擎的一次额外开销，所以在关卡任何点观察时都要避免超过2000次的Drawcalls
不同的材质应尽量少的使用
合并一些纹理（例如：如果你在同一个物体使用使用了2个不同的512x256的纹理，应该把它们合并到1张512x512的纹理里）
正方形的纹理会更好的应用到纹理流
每个物体尽可能使用越少的不同材质，对象的每一个材质都会引起至少2次的Drwacall,如果开启阴影就是3次
延迟渲染使用，延迟渲染在CPU方面的开销比前台渲染开销要小的多，主要开销只在GPU渲染方面。而之前前台渲染的多次Drawcall可以用延迟渲染统一的一次屏幕Drawcall替代。
场景复杂度
通过关闭的门将房间隔离开
使用过渡区域
为没有遮蔽的环境使用雾效
对于大物体使用Visblocking/occluders
在特别多对象的区域调整减小可见区域
删除player看不到的地型
平滑地表以减少顶点密度
为每个物体调整可见范围
设置最大drawcalls警戒值为2000，或者更小
地表尽量使用越少纹理越好
避免多种材质重叠
不要覆盖多个非常大的透明层(transparent)或者添加层(additive)
为美术资源设置合适距离的LOD范围。
CPU性能
使用尽量少的复杂的材质（性能成本便宜的）
在cbuffer中尽量少的三角形(节约drawcalls,减少drawcalls的冲突)
限制cbuffer中的覆盖的区域
减少动画角色的骨骼数
不要使用角色动画模糊（蒙皮需要更多的骨骼)
谨慎使用texture streaming（需要解压缩）
尽可能少的在天气效果中使用通明混合的物体(CPU计算雾效的近似值)
物理代理体尽量使用三角形(要做碰撞检测)
谨慎使用可破坏的物体
GPU性能
与分辨率无关的：
使用尽量少的顶点渲染.(每个顶点是一个独特的位置和纹理坐标点)
使用一个不太复杂的顶点格式
使用尽量少的会投射阴影的灯光
谨慎使用Decals
与分辨率有关的：
渲染对象在屏幕上占用尽量少的象素
使用成本较低的pixel shader(较小的灯光，较少的shader特性如反射，简单的shader)。
场景中每一种材质使用尽量少的纹理
使用廉价的纹理格式(要尽量使用压缩的DXT1,DXT3,3DC/DXT5)
使用mipmap
AlphaBlend比AlphaTest要慢，而AlphaTest又比不透明渲染的物体要慢
延迟渲染的灯光要比正常的灯光要廉价，所有的光影响的半径应尽量的小
如果需要一些灯光在一些区域的时候（如Box区域），这会导致灯光大量的重叠，使用IrradianceVolumes是非常必要的
尽可能少的同时开启多种后处理效果，另外一种策略是减少后处理效果开启的时间。
不使用或使用开销小的全屏抗锯齿(MSAA/FSAA)
使用劲可能少的天气效果
使用尽量少的地形材质混合。
内存使用：
使用尽可能少的贴图
使用一个低分辨率的纹理分辨率
使用纹理压缩格式(DXT1最好，DXT5和3dc也是不错的选择)
使用尽可能少的顶点
使用尽可能简单的物理替代体
使用尽可能少的动画
使用尽可能少的模型或LOD层级
使用尽可能少的材质和粒子发射器
使用尽可能少的道路
谨慎使用贴花
使用尽可能少的可投射阴影的光源
纹理流：（与纹理传送带宽相关）
可流化的纹理应该是正方形大小的（宽和高相等如:1x1 256x256）最好
使用尽可能少的不同文理格式用来更好的做纹理池的统一管理
每个区域尽可能少的使用独特的大纹理来减少I/O带宽的耗费
严格遵守每平方米texels（个数）的规则(distance streaming是基于它的)，使用r_texelspermetter 1来检查它
不要尝试使用大于512x512的纹理大小(拆分一些大的纹理成小的纹理)
尝试避免使用小于128x128的纹理单元(这会引起内存碎片)，把同一区域的小纹理拼接他们成一个大纹理
如果你仍坚持使用大的纹理集(texture atlases)（不建议），确保你不会使用这些物理到场景的不同区域(例如植被)
通用的程序性能准则：
越简单的材质使用越精简的纹理
附加物(Attachments)应该是可调整的，当在屏幕上过小是应该不显示他们
眼睛根据距离是要关闭的，以减少眼球渲染上的消耗（如果把渲染眼睛的情况下）
可摧毁的物体应该尽量让避免过快的散开（我的理解是爆炸的破损物体尽量散落的要慢，不要设置成太小的破坏体？）
纹理展开时应该使用越少的顶点(展开成大块)
贴花要谨慎的使用
制订纹理分辨率（根据不同范围设置适当比例）
设置阻挡地带体来减少物体渲染个数
静态场景中使用Protals可以带来更好的效率
Blocky geometry helps to get more for the same vertex count.（理解不了）
重用几何体与纹理来减少内存使用
避免在场景中使用独特的细节（尤其是一些复杂的场景中）
需要多遍渲染的材质层比正常的要慢，谨慎使用
在导出之前手动做Reset XFrom和Reset Transformations操作，如果不做，这些值会被引擎检查出来生成断言，比如物理模型与渲染几何体不匹配。
原点应该在物体的包裹盒内部以避免与预期不一直的渲染结果
跟踪解决控制台输入窗口显示的所有关卡错误级别的错误。
渲染调用（Drawcalls）
每个物体的一个不同的材质都会引起一个单独的Drawcall调用。每一次Drawcall都会引起引擎的一次额外开销，所以在关卡任何点观察时都要避免超过2000次的Drawcalls
不同的材质应尽量少的使用
合并一些纹理（例如：如果你在同一个物体使用使用了2个不同的512x256的纹理，应该把它们合并到1张512x512的纹理里）
正方形的纹理会更好的应用到纹理流
每个物体尽可能使用越少的不同材质，对象的每一个材质都会引起至少2次的Drwacall,如果开启阴影就是3次
延迟渲染使用，延迟渲染在CPU方面的开销比前台渲染开销要小的多，主要开销只在GPU渲染方面。而之前前台渲染的多次Drawcall可以用延迟渲染统一的一次屏幕Drawcall替代。
顶点个数
在引擎中UV边界会增加顶点个数，使用尽量少的UV边界
顶点法向量会在一些硬边被分割，保证平滑的多边形减少硬边的数量
物理代理
良好的物理代理在降低CPU物理计算时间上是非常重要的，如果没有物理代理性能会变慢
使用简单的物理代理体替代渲染模型来处理物理计算，减少CPU物理计算时间
渲染几何体的物理计算应该只被应用于一些可破坏的三维体，如可破坏的树干
物理代理替应尽量使用（图元）Primitives
尽可能利用粗糙的物体代理体处理角色碰撞和渲染集合体与子弹的碰状检测
为每个物理代理替使用一组平滑体（只有软边缘）
在材质编辑器的3d Package中设置物理类型（Set the proper physics type in the material edtior of the 3d package）
闭塞代理
为大的物体设置角色视觉遮挡，使用闭塞代理替，使用单面的闭塞代理（因为默认多边型被视为双面），尽可能的简单，越少三角形越好
物体的LOD
为每个美术资源设置LOD层级，每个LOD的层级中的多边形个数必须至少减少P以上。利用3DMAXd的Instancing和reduction 修改器
减少LOD岑寂的材质数于节省Drawcalls
良好的LOD是的良好性能和良好资源外观的关键。
材质设置
使用尽可能少的材质数量
合并纹理减少材质数和纹理提取
保持所有纹理使用CryTIF格式
使用128/128/128作为默认漫反射颜色
使用简单的灰色128/128/128或快速的色彩纹理做早期的纹理大小的实验，以获取一个合适的内存开销的解决方案
确保所有纹理都做过性能检测
植被
在室外游戏中，植被是一个植被覆盖场景中非常大的开销，确保每棵数不超过1或2个drawcalls
减少植被物体的材质数以节省Drawcalls
只使用最优化的shader在植被物体上
减少多边型个数，因为这些物体会被在屏幕上绘制很多遍
合并文理以减少材质数和最少的纹理提取（texture fetches）
为树叶添加多边型以匹配文理减少overdraw(遮挡绘制)，在树干上使用面片
粒子
尽可能使粒子特效有效，因为他们会带来很大的开销，对性能有很大影响，此外，尽可能的在不影响视觉的条件下用简单粒子替代标准粒子以减少性能开销
FrameTime:
如果你的FrameTime的目标是每秒30帧，那么每帧的消耗不应该超过33耗秒。
可以使用r_DisplayInfo 2来检测帧时间，或者开启性能评测模式（profile = 1）。
帧速率 = 1.0/1秒中的帧时间。例如1.0/0.033(3) = 30。
GPU时间是非常依赖于屏幕的分辨率，如果使用FSAA和render target的格式，例如720P(1280x720)并且HDR关闭。越高的设置，性能越差。
具体而言，这以为着对于XBOX360,如果你花费5毫秒做Zpass,6毫秒做一般pass,10毫秒做阴影处理（如果开启这个功能的话），这加起来大概花费21毫秒，理论上GPU上的帧速率不会超过47帧。
非延迟渲染光照的开销
太阳光的渲染使用一个简单的Pass
点光源的渲染使用一个单独的Pass,可以被合并，最多一个Pass处理4盏灯
聚光灯渲染总是使用单独的pass
这以为着如果你场景有阳光，你添加一个点光源，对于每个物体会带来额外的Drawcalls的光源影响。额外的Drawcall开销意味着更多的数据需要被处理在CPU方面，每个drawcall会带来更多的填充率开销
限制纹理数
Shaders读取纹理对于主机类和老PC硬件是非常昂贵的
尽量使用DiffuseAlpha的Shader中Gloss选项来替代发光贴图(GlossMap)。这将节省一个着色器的纹理读取。你可以安全的使用不必担心任何质量的损失。如果你使用这个功能并且你的光泽只有单色调，你可以通过高光颜色(Specular Color)中的颜色材质参数来调整。
对于植被的shader,使用Merged Textures选项。对于叶子这意味着GlossMap纹理的RGB通道包含了你的透明度RGB通道,GlossMap Alpha将会包含你的灰度光泽信息。对于树干意味着DiffuseAlpha包含了你的灰度光泽信息。请不要忽视这点，因为它对GPU（减少读取开销）和CPU（更少的设置纹理采样的开销）两方面都有好处。
正确的使用Shader着色器选项
使用Grass Shader Generation选项当你做草渲染的时候，这个选项是非常便宜的渲染方法，会生成所有阴影、使用最少的纹理读取，正确的使用这个选项是非常重要的，尤其是对主机游戏。
使用Decal shader generation选项当你把一个材质当作贴花使用时。这对于确保适当的渲染非常重要，比如你要避免Z-fighting（Z竞争）在某些硬件和一些渲染条件下。另外延迟渲染（deferred rendering）将只能正常渲染不透明几何体/地表层/贴花，如果没有启动这个选项，你要重新读取Normal Map并再次渲染和计算雾效。
Water/Rivers Volumes
当使用Water volumes和水下雾效的时候，如果是浅水应将density设置为0。这样可以跳过雾效处理。
在在小范围可见区域内使用Water Volumes，如果要覆盖一个大区域的话尽量使用小块进行替代。