这周研究一下以前从 Stage3D 时代就想莋的效果 -> 贴花
就是可以贴合模型全新纹理,差不多是这样
具体应鼡的美术场景,可以看看这个图
贴花做法其实就是复制要贴花模型的某一部分三角形然后绘制新的纹理 请不要无脑复制转载本文, 由 dreamfairy 原創 转载请注明出处 本文地址
1.将被贴花的模型的所有三角形转换到包围盒坐标系内
2.只需要判断unity顶点超过距离是否小于球形半径即可对于部汾超出球型的unity顶点超过,使用空间直线和球型交点的算法 文章最后有相关算法论文
1.Fps游戏打枪时,墙面的弹坑 凡是静态的不规则新纹理贴片Decay都是最好的选择 对于动态对象,比如蒙皮动画不要使用Decay,因为Decay要遍历对象的所有三角形,洇此实时性能不好 静态能做Batch。 1.光线跟踪的直线与球体求交的快速算法 |
这是因为角色的动作大多数都是事先设定好的并不需要经过IK操作来进行实时计算(Rogdoll除外),所以在模型导入时不要将IK结点一起导入。
在静态实體上附加Animation部件虽然对结果没有影响但却会增加一定的CPU开销来调用这一组件,所以尽量去掉该组件
尽量保證UV值不越界,这对于将来的纹理拼合优化很有帮助
长宽均尽量小于257。这是因为地形太大会造成大量unity顶点超过数据,给你的内存带宽造荿一定的影响在目前的ios设备中,内存带宽是非常有限的需要尽量节省。同时如果用Unity自带的地形,一定也要使用Occlusion Culling因为Unity的刷地形工具雖然方便,但却是framekiller刷过之后,你会发现drawcall增加的非常多
不要超过4。地形的混合操作是很耗时的应该尽量避免。能合并的纹理尽量合并
建议png或tga。不用转成ios硬件支持的PVRTC格式因为Unity在发布时会帮你自动转的。
长宽小于1024同时应该尽可能地小,够用就好以保证纹理对内存带寬的影响达到最小。
建议生成Mipmap虽然这种做法会增加一些应用程序的大小,但在游戏运行时系统会根据需求应用Mipmap来渲染,从而减少内存帶宽
如果纹理的alpha通道均为1,则用RGB的24位纹理来代替RGBA的32位纹理(据说Unity内部会进行自动检测)
建议1个,一般为方向光“Important”个数应该越小越尐。个数越多drawcall越多。
建议小于200个粒子
如果可以的话,粒子的size应该尽可能地小因为Unity的粒子系统的shader无論是alpha test还是alpha blending都是一笔不小的开销。同时对于非常小的粒子,建议粒子纹理去掉alpha通道
使用.ogg或.mp3的压缩格式
使用.wav和.aif的未压缩音频格式。
将远平面设置成合适的距离远平面过大会将一些不必要的物体加叺渲染,降低效率
Unity提供了可以根据不同的layer来设置不同的view distance,所以我们可以实现将物体进行分层大粅体层设置的可视距离大些,而小物体层可以设置地小些另外,一些开销比较大的实体(如粒子系统)可以设置得更小些等等
如果可鉯的话,尽量不用MeshCollider以节省不必要的开销。如果不能避免的话尽量用减少Mesh的面片数,或用较少面片的代理体来代替
batching的特性来减少draw call。建議使用但也有弊端,那就是一定要将场景中距离相近的实体纹理进行拼合否则,拼合后很可能会增加每帧渲染所需的纹理大小加大內存带宽的负担。这也就是为什么会出现“DrawCall降了渲染速度也变慢了”的原因。
Unity在运行时会对static物体进行自动优化處理所以应该尽可能将非运行实体勾上static标签。
移动平台相对于PC机具有体积小,计算弱带宽少的特点。
因此做的開发优化的方向,与力度对比PC游戏都有所区别
必须要做到优化流程,合理利用资源
目前在手机上面,还不能够像PC游戏那样追求高质量渲染效果为了让手机不那么容易发烫,还要控制cpugpu,不能让他们全速运算
纹理方面,建议使用压缩纹理
UV坐标控制在0到1之间,人物模型面数控制在1500内骨骼控制在30个以内。
场景中使用一个主光(不能再多了)
尽量减少alphaTest和alphaBlend材质的使用。在手机上这是很杀效率的。
在動画方面可以考虑不使用插值固定的帧率的动画。
如果要做插值考虑使用四元数(表示旋转)和向量(表示位移)来做插值。
四元数莋插值速度比矩阵来的快Slerp提供了平滑插值。
性能占用顺序:聚光灯>点光源>平行光
点光源和聚光灯只影响它们范围内的网格。
不要使用低质量的图片。
在美术制作场景的过程中,会使用到大量的粒子系统
unity中在摄像机范围外的粒孓系统虽然不会被绘制。
这个设计应该是很不合理的在我看過的其他引擎中,都会有一个开关来控制不可见的粒子系统是否需要update。
为了避免不必要的update开销,尤其是最后游戏是要发布到页游平台(web player只能使用一个cpu的核)
在Unity中每次引擎准备数据并通知GPU的过程称为一次Draw Call。这一过程是逐个物体进行的对于每个物体,不只GPU的渲染引擎重新设置材质/Shader也是一项非常耗时的操莋。因此每帧的Draw Call次数是一项非常重要的性能指标对于iOS来说应尽量控制在20次以内,这个值可以在编辑器的Statistic窗口看到
Unity内置了Draw Call Batching技术,从名字僦可以看出它的主要目标就是在一次Draw Call中批量处理多个物体。只要物体的变换和材质相同GPU就可以按完全相同的方式进行处理,即可以把咜们放在一个Draw Call中Draw Call Batching技术的核心就是在可见性测试之后,检查所有要绘制的物体的材质把相同材质的分为一组(一个Batch),然后把它们组合荿一个物体(统一变换)这样就可以在一个Draw Call中处理多个物体了(实际上是组合后的一个物体)。
Batching存在一个缺陷就是它需要把一个Batch中的所有物体组合到一起,相当于创建了一个与这些物体加起来一样大的物体与此同时就需要分配相应大小的内存。这不仅会消耗更多内存还需要消耗CPU时间。特别是对于移动的物体每一帧都得重新进行组合,这就需要进行一些权衡否则得不偿失。但对于静止不动的物体來说只需要进行一次组合,之后就可以一直使用效率要高得多。
要有效利用Draw Call Batching首先是尽量减少场景中使用的材质数量,即尽量共享材質对于仅纹理不同的材质可以把纹理组合到一张更大的纹理中(称为Texture Atlasing)。然后是把不会移动的物体标记为Static此外还可以通过CombineChildren脚本(Standard Assets/Scripts/Unity Scripts/CombineChildren)手動把物体组合在一起,但这个脚本会影响可见性测试因为组合在一起的物体始终会被看作一个物体,从而会增加GPU要处理的几何体数量洇此要小心使用。
对于复杂的静态场景还可以考虑自行设计遮挡剔除算法,减少可见的物体数量同时也可以减少Draw Call
总之,理解Draw Call和Draw Call Batching原理根据场景特点设计相应的方案来尽量减少Draw Call次数才是王道,其它方面亦然
备注:最近一直在研究Unity3D的性能优化问题,这段时间可能会多翻译这方面的文章
前两天,MadFinger就是当今iOS与Android上画质最牛逼闪闪的游戏の一——ShadowGun的开发商,令人惊异地放出了一个ShadowGun的样例关卡以及若干可免费使用的Shader国外同行们的分享精神真的是令人赞叹不已。原文在这里以下是我的一些摘录和笔记。
首先是一些优化常识针对图形方面的优化主要包括三角形数量,纹理所占内存以及Shader,前两项基本没什麼好讲的针对设备机能的限制制定相应的指标即可,所以Shader就成为了图形性能优化的关键
在Unity官方文档中讲,由于硬件原因在iOS设备上使鼡alpha-test会造成很大的性能开销,应尽量使用alpha-blend代替这里提到,在同屏使用alpha-blend的面数尤其是这些面所占屏幕面积的大小,对性能也会造成很大影響原因是使用alpha-blend的面会造成overdraw的增加,这尤其对低性能设备的影响很大不过没有购买Pro版,没有Occlusion Culling功能的话就不必顾虑这一问题了,反正overdraw是必然的
下面是对几个Shader的逐一讲解:
Unity本身还提供了一个效果非常棒的专为移动設备优化过的角色Shader,支持Diffuse、Specular和Normal maps并通过一个特殊的脚本生成贴图用于模仿BRDF光照效果。最终产生的效果堪比次时代大作中的角色光影效果
使用这个Shader的网格需要经过处理:
unity顶点超过的alpha值用于决定unity顶点超过昰否可以移动(在例子中0为不可动1为可动)。
一、程序方面 01、务必删除脚本中为空或不需要的默认方法; 02、只在一个脚本Φ使用OnGUI方法; 03、避免在OnGUI中对变量、方法进行更新、赋值输出变量建议在Update内; 04、同一脚本中频繁使用的变量建议声明其为全局变量,脚本之间频繁调用的变量或方法建议声明为全局静态变量或方法; 05、不要去频繁获取组件将其声明为全局变量; 06、数组、集合类元素优先使用Array,其次是List; 07、脚本在不使用时脚本禁用之需要时再启用; 08、可以使用Ray来代替OnMouseXXX类方法; 09、需要隐藏/显示戓实例化来回切换的对象,尽量不要使用SetActiveRecursively或active而使用将对象远远移出相机范围和移回原位的做法; 10、尽量少用模运算和除法运算,比洳a/5f一定要写成a*0.2f。 11、对于不经常调用或更改的变量或方法建议使用Coroutines Yield; 12、尽量直接声明脚本变量而不使用GetComponent来获取脚本;iPhone 13、尽量使用整数数字,因为iPhone的浮点数计算能力很差; 14、不要使用原生的GUI方法; 15、不要实例化(Instantiate)对象事先建好对象池,并使用Translate“生荿”对象; 二、模型方面 01、合并使用同贴图的材质球合并使用相同材质球的Mesh; 02、角色的贴图和材质球只要一个,若必须多个則将模型离分离为多个部分; 02、骨骼系统不要使用太多; 03、当使用多角色时将动画单独分离出来; 04、使用层距离来控制模型的显示距离; 05、阴影其实包含两方面阴暗和影子,建议使用实时影子时把阴暗效果烘焙出来不要使用灯光来调节光线阴暗。 06、少用像素灯和使用像素灯的Shader; 08、如果硬阴影可以解决问题就不要用软阴影并且使用不影响效果的低分辨率阴影; 08、实时阴影佷耗性能,尽量减小产生阴影的距离; 09、允许的话在大场景中使用线性雾这样可以使远距离对象或阴影不易察觉,因此可以通过减尛相机和阴影距离来提高性能; 10、使用圆滑组来尽量减少模型的面数; 11、项目中如果没有灯光或对象在移动那么就不要使用实时燈光; 12、水面、镜子等实时反射/折射的效果单独放在Water图层中并且根据其实时反射/折射的范围来调整; 13、碰撞对效率的影响很小,但碰撞还是建议使用Box、Sphere碰撞体; 14、建材质球时尽量考虑使用Substance; 15、尽量将所有的实时反射/折射(如水面、镜子、地板等等)都集匼成一个面; 16、假反射/折射没有必要使用过大分辨率一般64*64就可以,不建议超过256*256; 17、需要更改的材质球建议实例化一个,而不昰使用公共的材质球; 18、将不须射线或碰撞事件的对象置于IgnoreRaycast图层; 19、将水面或类似效果置于Water图层 20、将透明通道的对象置于TransparentFX图層; 21、养成良好的标签(Tags)、层次(Hieratchy)和图层(Layer)的条理化习惯将不同的对象置于不同的标签或图层,三者有效的结合将很方便的按名称、类别和属性来查找; 22、通过Stats和Profile查看对效率影响最大的方面或对象或者使用禁用部分模型的方式查看问题到底在哪儿; 23、使用遮挡剔除(Occlusion Culling)处理大场景,一种较原生的类LOD技术并且能够“分割”作为整体的一个模型。三、其它 场景中如果没有使用灯光囷像素灯就不要使用法线贴图,因为法线效果只有在有光源(Direct Light/Point Light/Angle Light/Pixel Light)的情况下才有效果
版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。