场景检测:面片、光影和物理属性

news/2024/7/10 4:05:50 标签: 场景, 面片, 光影, 物理, 优化

在上一期《场景检测:Audio Listener、RigidBody和Prefab连接》中,我们依托本地资源检测中和场景检测相关的规则,把涉及到的知识点讲解。这些看似细小的知识点,很容易在开发和学习过程中被疏忽,而长期的问题积累最终都会反映到项目的性能表现上。为此,我们将这些规则列出,并且以一个个知识点的形式向大家逐一解读。

本期,我们将继续讲解目前场景检测中剩余的规则:场景总顶点数过大”、“场景面片数过大”、“阴影分辨率设置不规范的灯光”、“检测场景中的Rigidbody”和“场景中MeshCollider使用的总面片数过多”,我们将力图以浅显易懂的表达,让职场萌新或优化萌新能够深入理解。

1、场景总顶点数过大/总面片数过大

如果说现实里的万事万物都是由原子分子构成,那么在Unity中,“点”与“线”的组合就构成了这个虚拟世界的基础。就算是一个看上去无比圆润的球体,究其根本也是由大量“点—线”组合的三角形面片构造而成。

一般来讲,如果对场景的质量要求越高,那么场景中的元素就会越多、模型也会越精细。相应地,开发团队就需要使用更多的面片去构建地形、角色模型等,用更多更复杂的做法来渲染相应的元素,以满足场景内高质量的需求。

而随着场景内顶点数、面片数的上升,在项目中Unity就需要花费更多的内存去记录相应的顶点以及面片信息,并且在渲染时也会消耗更多的运算资源以达到预期效果。

一方面,大量的顶点与面片场景带来了不可忽视的内存和渲染压力;另一方面,由于没有在这种数量上有个明确的“红线”,一些很明显的优化做法也容易被开发团队所忽略。例如对作为背景的远处物体,本可以通过降低三角面数的做法来减少性能开销;一些数量大但非必要的场景物体,某些情况下甚至可以不用模型,转去用平面纹理也达到同样效果等。

所以借助这两条规则,开发团队能对场景内的元素与复杂程度有个较为明确的概念。针对筛选出来的场景资源,开发团队要根据实际的性能需求去对相关的顶点、面片使用做精简。


2、阴影分辨率设置不规范的灯光

在Unity中,开发团队可以通过对光源和相应的阴影效果进行设置,以达到对现实光影的模拟或者某种特定的光影表现,从而提高场景的渲染质量与展示效果。我们可以很方便地对Directional Light、Point Light、SpotLight等多个类型的光源进行相应的阴影效果设置。

很有意思的是,Unity还提供了一个全局性的质量设置(Quality Settings)。路径一般是Edit—>Project settings—>Quality。我们也可以在这个界面对场景内的光影效果进行相关的设置。

不过在这里我们聚焦在一个更具体的方面:Shadow Resolution。在Quality Settings中,如下图,Unity提供了四种Resolution可供选择:

而在光源的Shadow设置内,相较而言会多出一个“Use Quality Settings”的选项,以方便具体的光源直接采用Quality Settings里的设置:

从规范开发的角度讲,一般两个地方的设置是保持一致的;如果特定灯光的分辨率设置与Quality设置里面的不一致时,就会导致有的地方分辨率高,有的地方分辨率低。就如图所示,不同的阴影效果的差别非常明显,从而破坏了整个场景光影和谐性,使得场景光影效果处于一种不协调的状态。

所以开发团队在进行灯光的阴影设置时,要充分考虑到Quality Settings为场景确立的大方向,尽量使得光源的阴影设定与Quality Settings保持一致,以避免造成冲突导致场景效果打折扣。


3、检测场景中的Rigidbody

在上一期的文章《场景检测:Audio Listener、RigidBody和Prefab连接》中,我们对刚体有过简单的介绍。本条规则就不再局限于静态物体,而是将范围扩大到了整个场景

问题的精髓还是一样的:作为对现实物理属性在虚拟世界中的展现,场景中的物体是否有必要添加上Rigidbody以实现相应物体对物理效果的模拟?

所以在本条规则筛选出场景内带有Rigidbody的物体后,开发团队要根据对应物体的实际使用情况,对挂载的刚体进行保留或去除,以及勾选相关的优化项。


4、场景中MeshCollider使用的总面片数过多

同样的,在介绍场景规则的第一篇文章《场景检测:雾效、Canvas和碰撞体》中,我们对Mesh Collider(网格碰撞体)进行了相应的讲解。

不同于Unity中其他几种简单的预制碰撞体,Mesh Collider以“实现更为精准的碰撞反馈”为目的,将碰撞反馈的范围尽可能地与目标物体的表面形成贴合。碰撞效果相对于立方碰撞体或者球形碰撞体等而言,反馈会更为拟真,但代价是更复杂的碰撞计算和更高的性能开销。

一般而言,构成Mesh Collider的面片数量越多,它所占用的物理开销也会越高。本条规则会找到场景中所有的MeshCollider组件,统计面片数总和。开发团队可以从“精简物体三角面片数”和“换用相对简单的碰撞体”这两条思路去考虑对相应的场景进行优化


希望以上这些知识点能在实际的开发过程中为大家带来帮助。需要说明的是,每一项检测规则的阈值都可以由开发团队依据自身项目的实际需求去设置合适的阈值范围,这也是本地资源检测的一大特点。同时,也欢迎大家来使用UWA推出的本地资源检测服务,可帮助大家尽早对项目建立科学的美术规范。

 

万行代码屹立不倒,全靠基础掌握得好!

相关推荐

《UWA学堂训练营|游戏自动化测试》

性能黑榜相关阅读

《那些年给性能埋过的坑,你跳了吗?》
《那些年给性能埋过的坑,你跳了吗?(第二弹)》
《掌握了这些规则,你已经战胜了80%的对手!》


http://www.niftyadmin.cn/n/1030804.html

相关文章

杂货边角(3):GCC内嵌汇编

前面介绍过miniCRT自定义运行库的代码中涉及到一段代码 static int open(const char* pathname, int flags, int mode) {int fd 0;asm("movl $5, %%eax \n\t""movl %1, %%ebx \n\t""movl %2, %%ecx \n\t""movl %3, %%edx \n\t""…

DrawInstance和完全不做合批情况下的性能差异

1)DrawInstance和完全不做合批情况下的性能差异 ​2)UWA报告中检测出工程没有的资源 3)精灵设置九宫后,如何不在界面中显示出来 4)关于AssetBundle资源的卸载问题 5)Total Mono突然上涨的原因 这是第236篇U…

杂货边角(4):C语言static, inline, volatile, const等关键字解析

1. static关键字解析ANSI标准规定了C具有32个关键字,其中绝大多数并无特别之处,除了涉及到存储类型的几个关键字,而我们的static关键字便是属于存储类型声明的关键字一类:1. auto: 声明该变量标识符是存放在栈上的(局部…

杂货边角(5):预编译指令#家族define/pragma

编译器提供的预处理指令主要是以#作为首字符的,如本文的两个主角#define和#pragma。合理的使用预处理指令可以使得编写的程序更便于修改(#define MAX_SUM 10000)、平台兼容性(#ifdef WIN32 ... #else...#endif)和调试(#define __DEBUG)。如下…

杂货边角(6):Windows的数据类型和编译器固定数据类型对照

基本数据类型作为我们经常用到的东西其实经常容易被我们忽略其中的小文章,有些情况下如果没搞清楚其中的对应关系,则很容易导致我们的程序可移植性下降。 short(__int16),long (__int32),long long(__int64)是编译器层…

系统内核之堆管理

相比于栈内存而言,堆这片内存的管理模式更为复杂,因为程序可能随时发出请求,并且申请一段内存,申请内存的大小不固定,释放的时间也不确定。栈在面向过程的程序设计中远远不够,因为栈上的数据在函数返回时就…

多线程统计 | GOT Online新功能上线

为了能大幅度降低主线程的压力,提升项目的运行帧率,我们更倾向于将与Unity API无关的操作放到子线程中进行处理。但是,在分析堆内存占用时,由于无法获取子线程的堆内存分配具体情况,定位分析时就存在一定门槛。 为了解…

极致优化思想系列之一:操作系统内核极致提升空间效率的设计点滴

《极致优化思想系列》是我用来收集一些不同目的诉求场景下的一些前人的精巧的极致设计思想,这些设计思路充满了艺术性,以此系列来作为敦促自我驱动不断进步之意。 《极致优化》的第一篇文章关注的便是“空间效率”这个最常见的criteria。而谈到空间的极…