ue4 怎么获取ue4角色角度控制器的变量

对于任何追求UE4性能最佳、同时又想保持极高质量视觉效果的人来说本文有一些可遵循的一般性建议和原则。

为了性能你通常受CPU时间(通常和游戏设置相关)和GPU时间限淛(渲染场景花费的时间)。CPU创建由GPU渲染的场景会耗费一些时间

通常情况下,当你发现游戏的运行速度不像你想要的那么快时第一步昰找出你现在受以上哪个环节的约束,然后确定需要修改的资源或设置来修正问题UE4的一些内置工具就是为了实现这个目标而存在的,我建议好好掌握这些工具特别是CPU和GPU分析器。

UE4中有很多可用工具它们可以用来分析性能和帧率,许多工具采用控制台指令形式可用在控淛台输入这些程序指令,控制台可以在游戏中通过按波浪键显示也可以在编辑器的显示菜单里找到。这里圈出的是几个特别有用的指令(这些可以按“stat__”也就是“stat unitgraph”或者“stat fps”的形式在控制台输入)

这里让我们仔细看看从“Detailed”Stat组得到的信息(自动选中上面圈出的多数其他stat組):

c.      注意GPU和CPU(游戏&绘制)是同时执行的,所以帧花费的总时间不是它们时间的总和但是任一项拖了后腿都可能是帧率降低的原因。

4.     这昰图中的峰值——当一个特定过程(游戏、绘图或者GPU)的执行花费了很长时间时它用毫秒标记了那个顶峰的最慢帧的时间。

这也是stats的一個“Advanced”组它有更详细的内容需要说明。

在“Advanced”组中的大多数项是特别针对像Lighting或者AI Behavior这样特定系统的所以这样的系统也包含专门针对“Advanced”組的stats。这里让我们看一些特殊兴趣点的例子:

场景渲染指令和绘制调用

场景渲染是特别方便的因为它显示了你的场景中绘制调用发生的佽数,取决于你的绘图API这可能是一个极其重要的数字(例如:在手机OpenGL平台上,绘制调用代价太高了以至于开发者经常将大多数的环境并叺一个静态网格中来让它作为一个单一的绘制调用)

在验证场景剔除时这个stats组很有用。“剔除”就是当你选择性地不运行或渲染部分场景这些场景当前视图中不会使运行加速。通过参考Frustum Culled初始量值你可以查看渲染系统决定不绘制的初始量的数量,因为这些量是不可见的相反,可见的动态初始量部分显示了被定义为可见初始量的数量

另一个可视化的方式就是使用调试摄像头,你可以在玩游戏的时候通過控制台命令“ToggleDebugCamera?  ”转至调试摄像头在那里,如果你点击“F”键来停止渲染并且把调试摄像头移到另一个角度你可以清晰地看到哪个初始量被渲染了、哪些被修改了。

在上面的屏幕截图中你可以看到预览窗口中的ue4角色角度摄像的原始视图该视图是在Play模式中通过在场景夶纲中选择摄像头呈现的。ToggleDebugCamera用来停止渲染在移动摄像头到另一边查看剔除的初始量时,要保证摄像位置的剔除是稳定的

线框视图模式鈳以告诉你场景和独立网格中有多少顶点和三角形,要实现这个模式你可以在编辑器等级视口的可视化模式菜单中找到,或者在游戏运荇期间按F1键或者在控制台输入“viewmode wireframe”命令:

如果你的网格有三角形/顶点的富余,而且远比摄像头的充足时线框就会变成实线。如果你的網格不总是实线的这意味着你有可能需要比渲染更高的复杂性,你就应该减少网格中的多边形数量

当你的场景中存在很多材质时,可能很难确定哪些是复杂的幸运的是,UE4中有一个内置视图:着色器复杂性通过编辑器关卡视窗中的可视化模式菜单可以找到它,还可以茬游戏运行时通过按F5找到它或者进入“viewmode shadercomplexity”控制台指令:

这里的暗绿色区域比浅绿色区域含有更复杂的着色程序逻辑,红色和白色区域也仍有更加复杂的着色逻辑着色复杂性最大的原因通常是:当多重透明材质重叠时,需要为所有重叠区域计算着色

当你已经确定了一个紅色区域,你可以右击对象来编辑那个ue4角色角度在这种情况下——一个静态网格:

从这个静态网格编辑器中,你可以在Details面板中看到网格囸使用的材质:

单击放大镜就可以在内容浏览器中选择材质资源你可以双击它来打开材质编辑器:

在材质编辑器中,你可以推动stats按钮来咑开stats的材质标签在这里你可以看到材质对应的着色器的说明数量。但是说明数量不是与性能的影响一一对应的(因为一些说明比其它更昂贵)了于一个材质的复杂度来说,说明的总数是一个很好的表征总体来讲,减少说明的数量可以产生更好的性能

着色器在其它领域的性能也可以是受约束的——如纹理缓存。如果你在你的材质中用了许多纹理那么就可能没有足够的空间来立刻将它们写入缓存,所鉯它们最终会被调入、调出内存这样是非常慢的。因为这个原因有可能的话最好减少每个材质的纹理取样器。在材质编辑器的stats窗口和說明数量中你可以看到材质目前正使用的纹理取样器的数量。

另一方面着色器在纹理检查中性能也受约束。比如说如果你正在使用一個大型纹理但是它距离摄像头很远,相对只有一小部分纹理是会被取样的但是为了给它取样,要读比实际用到的多得多的纹理这里錐形纹理技术(mip map)就起作用了,因为锥形纹理在纹理的连续区域内包含的纹理更小所以只有纹理的小得多的部分需要被读入来得到采样。这样一来保证在所有纹理中充分利用锥形纹理技术是很重要的。

光线复杂度视图模式? 显示了影响你的几何图形的非静态光线的数量它可以通过编辑器等级视口的可视化模式菜单得到,或者在游戏运行中按F9键:

这对于追踪光线代价是很有用的——光影响外观越多它產生阴影的代价就越大。

一个光线可以被剔除的方式有很多包括半径削减、z型交叉、摄像头背对光源、光函数是0等等,所以光会在不同陰影中出现是非常有可能的光线复杂度视图模式在将代价与颜色亮度联系起来的方面是做得最好的。

减少半径削减或者光线的锥形角度鈳能会有帮助打光性能是非常依赖角度的,所以它极大程度上取决于玩家的摄像头在哪里由于这个原因,最好在不同角度研究光复杂喥

静止光线重叠视图模式用红色显示了哪些静止光线正被迫移动。

静止光线一次最多只允许4次重叠一旦你有了大于等于5个的静止光线偅叠,拥有最小半径的那个静止光线会开始投射动态阴影这会产生很高的性能代价。

这个工具显示了在当前关卡下使用的所有纹理它們的分辨率、使用次数和游戏中出现的时间。如果你的场景中有高分辨率的纹理并且没有被很多使用次或者不常见它们不仅会占据很多鈈必要的内存,而且也会造成GPU处理缓慢增加GPU渲染场景花费的时间。

这里你可以看到许多有用信息开始是在你的骨骼网格、静态网格和場景中有多少三角形初始量。如果你在你的场景中定义了一个对象它的三角形数量很多,试着在线框层次上观察这个ue4角色角度

可视化鼡来观察线框在一个正常的观察距离外是否保持着实线(或接近实线),这意味着在你的网格中你有比你需要的更多的细节你可以使用DCC笁具或者UE4支持的网格简化工具来减少网格中的顶点数量。

初始量Stats视图也包括数量这个数量是在当前关卡上使用的数量;还包括实例部分,就是网格中类似着色器和绘制调用这样的元素的数量主要就是绘制这个对象实例复杂度的度量。如果两个值数量值很高(在你的关卡設置了许多相同对象)实例部分值也很高(对象渲染复杂),那么这可能导致渲染时大量的绘制调用或者图形API状态发生变化这会显著增加GPU渲染场景的时间。基本上如果数量×实例部分与场景中其他对象相比是一个相对大的数,这个对象就是应该优化的区域。达到这个目标的一个潜在方法是把单一ue4角色角度用高多边形数量分解成多个ue4角色角度,允许他们被单独选择因此你就有机会一次性绘制比整个多边形数量少的图像了。但是这主要只对CPU加载有影响所以如果你的游戏不是CPU受限的,那么最好把你的优化时间集中在其它任务上

只有一种鈈适用的情况:当使用实例化的静态网格特征时,你可以使用这个特征在你的关卡周围设置许多相同静态网格的拷贝但是在渲染时应把咜们合并为一个单独的绘制调用。这可以提升性能但也意味着那些网格不能被单独选择,所以如果它们中的任何一个在屏幕上可见它們都会被渲染。

也许在优化性能时应该熟悉的两个最重要的工具是CPU分析器和GPU分析器

CPU分析器作为一个独立应用运行,可以从Session前端或者Unreal前端獲取到Session前端可以在Unreal编辑器的窗口菜单中找到。这里我将会讨论如何使用Unreal前端因为两者的界面几乎是完全相同的。

首先你应该启动你的遊戏最好是作为一个独立应用程序运行,但是你也可以在Unreal编辑器中分析运行(在编辑器中分析意味着会有很多的编辑器菜单逻辑和其他玳码在你的分析记录中出现所以最好把它作为一个独立游戏来分析)。

分析的最好配置就是测试建立因为所有不必要的调试输出都可鉯被省略,而且它含有全部的代码优化并且使用烘焙的优化内容。你可以读到更多关于不同建立配置的信息你也会需要烘焙来让你的內容作为独立游戏来运行,这可以通过Unreal编辑器的File Menu > Cook Content for*Platform*完成或者你可以为其他平台给你的内容打包。

无论是何种原因如果你不能完成测试建竝或者烘焙你的内容,你可以完成一个开发编辑器建立带着游戏选项运行,这会为很好地为你显示不同特征的相对性能代价但是一个含有烘焙内容的测试建立对于得到最终数据是最佳选择。

当启动你的游戏时启用游戏和Unreal前端之间的内部过程通信,通过使用命令行上的?messaging选项是很必要的Unreal前端不仅支持在相同机器上运行的UE4应用分析,也支持在网络中分析

在你完成启动游戏之后,你可以运行UnrealFrontend.exe这可以在UE4/Engine/Binaries 攵件夹中找到。你可以看到如下的界面先在导航找到Session前端标签,之后找到分析器标签

 一旦你选择了一个session和一个实例,数据抓取按钮就會变得可用你可以立即点击它开始数据抓取,再点击一次停止当你停止的时候,你可以看到一个对话框询问你是否想要把抓取结果传遞到这台机器上:

在这里它会把文件传到你的机器上(如果你不是在网上分析的话就本地拷贝),你会看到这个弹出框:

 当完成时会詢问你是否想要加载:

 当分析器已经加载了,它长成这样: 

我会详细解释各个部分:

1.     这是一个渲染线程vs游戏线程的简图根据CPU逻辑与渲染嘚关系,一眼你就会知道你是否是CPU受限的或者它是否是与游戏相关的且花费最多性能的逻辑。

2.     这个区域显示了抓取期间的整个CPU加载的简圖在这里,你可以沿着时间线单击任何部分来观察对应帧的CPU分析或者你可以单击、拖拽来选择帧的范围并且查看均值。根据你这里的選择函数时间(3)的层级列表中的分析数据会改变。

3.     这是调用的不同函数和所花时间的层级列表花费时间最长的函数排在顶端。花费朂多时间的函数以红色显示其它用黑色显示。你可以通过单击左侧三角来展开对应层你可以看到这个函数调用过程的分解以及执行花費的时间。

b.  注意这里的CPU停转是CPU闲置等待其它线程结束的时间

4.     如果你在函数时间(3)的层级列表中选择了特定的函数,你可以看到这里的顯示变化这里显示了什么函数调用了这个函数,以及该函数调用了哪些函数同时可以看到这些调用和被调用函数执行时间的比例。

5.     左側面板展示了stats和stat组顶层是stat组,你可以展开它查看内部的独立stat这些stat可以是整型、浮点型数字或者内存,你可以控制哪些显示在stat过滤器面板(6)中如果你鼠标停留在一个stat上,会弹出该stat的分析信息(8)

6.     在这里你可以通过搜索想要的stat、改变分组和排序、隐藏/显示不同类型的stat(浮点/整型/内存)以及启用/禁用层级视图控制stat面板的显示(5)。

a.  类型——如果在图像视图中你只选择了一帧(2)你唯一的选择就是显示信息那帧,但是如果你选择了一系列帧你可以选择是否显示平均时间或者花费的最长时间。

b.  视图模式——这会改变函数时间分层的层级列表视图(3)或者改变单纯的函数列表,里面包括这些函数的子程序包括的或排除的时间

c.  向前、向后按钮可以让你在图像视图的不同蔀分之间跳转(2)。所有你可以看到一系列信息之后缩小你的选择范围直到一个帧,然后用这些按钮来在两者之间切换下拉箭头显示叻之前的选择。

d.  这里的火焰按钮是用来展开你当前选择函数的时间层级列表的(3)用来查找花费最多时间的路径,它也会用一个小火焰圖标来标识该路径

有一个与研究GPU性能的类似工具。

首先如果你想要启动你的游戏,最好先作为一个独立应用来启动但是你也可以在Unreal編辑器中分析它的运行(因为编辑器UI渲染等也会在你的分析文件中显示,所以最好单独分析游戏)

分析的最好配置就是测试建立,它含囿全部的代码优化并且使用烘焙的优化内容。你可以读到更多关于不同建立配置的信息你也会需要烘焙来让你的内容作为独立游戏来運行,这可以通过Unreal编辑器的File Menu > Cook Content for*Platform*完成或者你可以为其他平台给你的内容打包。

如果因为无论任何原因你不能完成测试建立或者烘焙你的内容你可以完成一个开发编辑器建立,带着游戏选项运行这会为很好地你显示不同特征的相对性能代价,但是一个含有烘焙内容的测试建竝对于得到最终数据是最佳选择

在这个游戏中,你可以在控制台输入profilegpu来启动GPU分析器或者按Ctrl+Shift+,来启动,这会打开GPU观察器:

这里你可以看到┅张形象图里面有渲染场景的步骤,在顶部可以看到它们在GPU上花费多少时间在底部你可以在文本列表中看到相同的信息。在图或者列表中任选一个入口都会在两地方同时选定选中对象如果鼠标在图上停留,会显示GPU的任务名称

这个命令不仅打开了观察器,同时也向日誌文件和输出日志输出了相同信息(也有一些额外信息)你可以从窗口菜单中打开输出日志:

输出日志标签中的输出内容如下:

你可以茬输出日志中看到这里也有百分比信息,还有绘制、初始量和顶点的数量

优化的最初阶段之一应该是为你的内容计划性能预算。为制作內容制定指导方针是必要的所以当美工为游戏制作不同ue4角色角度和环境时,它们的性能和内存特征变化不大一些内容的合并会以一个鈈好的帧率运行,因为一些合并未充分利用潜在可用的CPU和图形性能

如之前在线框可视化解释中提到的,减少三角形和顶点的数量永远都昰提高性能的方法但是很多时候,一个单独网格比多个网格刻画集合图形的性能要好得多(一个有1000个顶点的网格可能比10个有100个顶点的网格的更新和渲染都快)这是因为不仅这些网格可能会分别单独调用GPU来绘制,也因为UE4会为每个网格单独保存和更新变换信息而且可能检查这些独立网格间的碰撞。所以如果没有功能性的原因来设置单独网格的话,你应该考虑在把它们引入UE4之前在DCC工具中选择合并它们

关於合并网格反对的说法是:一个单独的网格可能不能被部分剔除,所以如果它的任何一部分是可见的整个网格都会渲染。由于这个原因可能把你的整个关卡都合并成一个单独网格可能不是一个好主意,但是让每一个三角形都成为一个单独网格同样也不是最理想的所以茬两种极端中取得平衡至关重要。

由大量网格组成的单一对象

使用由很多独立网格组成的对象(比如说一辆车的每个独立部分由成百成千嘚单独网格组成)对于引擎来说可能任务非常繁重如果引擎在仿真时把每个网格当做独立对象,而且为每个网格单独运行引擎系统(例洳:在你的对象中为几千个网格进行单独的挽歌物理仿真)

像这样对许多网格组件进行父处理并且把它们作为一个对象处理比较好,但昰我们有一些建议提供给你来避免在这些事情上浪费不必要的CPU和GPU的周期。

首先如果你的对象中有许多网格并且经常不可见,试着不要茬移动场景中建立这些网格直到它们可见即使网格没被渲染,每当一个父级网格组件的变换改变时每个子网格组件的变换都会被更新,而且在网格需要可见前不要调用Components.Add()方法这样可以节省许多处理器周期。

同样道理也适用于在游戏系统中注册不可见的网格如果网格不鈳见,它的物理形态等可能不需要每帧都更新所以,在网格需要变为可见之前不要在不可见网格组件上调用RegisterComponent()方法

避免在由相同对象组荿的、或不需要相互碰撞的网格间运行碰撞检测。

对于那些不需要碰撞的子网格组件把它们的碰撞情况设置为无:

如果你的ue4角色角度一點也不需要碰撞,那么就在你的父级网格组件上设置相同的内容否则就在父级上启用碰撞,但是给它一些能表示它和它的孩子的碰撞说奣

如果包含你的ue4角色角度的网格组件是接触的或重叠的,它们就会产生重叠时间如果你不在意这些事件,禁用它们会提升性能:?MeshComponent??>?bGenerateOverlapEvents? = ?false?;

屏幕剔除系统用网格组件的边界来确定该网格是否应该在这一帧中渲染对于那些含有许多网格组件的对象来说,即使对象部汾在屏幕外为每个独立子对象检查边界的代价也可能比单纯渲染所有网格组件的代价要大。试着设置子网格组件使用它们父级组件的边堺来测试观察性能是否没有提升。

给所有这些网格单独打光是不必要的繁重任务——在CPU配置文件中渲染线程部分中“更新间接照明缓存”的毫秒数值很高通过在你对象的根组件中设置bLightAttachmentsAsGroup为true,你可以选择在你的对象的每个网格中使用相同的间接照明缓存信息这会节省独立哽新网格的时间。

在你的关卡的平行光属性中经常减少动态阴影级联的数量不会对阴影外观产生非常大的影响,但是会提升性能我认為默认的是5,但是减少至大约3的样子就会产生大致差不多的效果

动态阴影的代价可能很大,尤其是全局动态阴影这是因为三角形必须嘚为动态阴影映射重新渲染。如果你在移动光源上需要许多动态阴影来使多边形尽可能少如果你想要更多多边形,那就试着少用带有动態阴影的可移动光线

记住,设置了4个以上的重叠固定光线会迫使半径最小的那个变成可移动的这样就会开始投射动态阴影。本文他处討论的固定光重叠可视化是确保没有过多重叠的好方法

后过程效果同样是代价很大的,禁用你不需要的效果也可以很大地提升性能一些可以考虑禁用的后过程效果包括镜头闪光、土地深度和屏幕空间反射。为了提升性能你可能也想要以低质量运行屏幕空间抗混叠,以哽小的散景尺寸运行散景DOF因为这里的尺寸与性能是负相关的(更大的散景意味着更差的性能)。

如果最终你可以在其它系统中取得足够嘚性能提升你可以之后选择性地把这些效果重新启用。

在单一镜头中限制贴花数量

如果在摄像头中同时有许多彼此接近的贴花有时这樣的代价是很大的。如果你有比如说50个贴花正同时被渲染这对于性能可能有消极影响。试着稀释或扩散这些贴花那么就不会有那么多貼花同时被渲染了。

以更低分辨率和更少变形渲染

如果你想要试着以稍低的分辨率和稍少的变形进行渲染来节省性能试着做、看看它看起来和运行起来效果如何是非常简单的。

当游戏运行时你可以打开控制台输入“r.screenpercentage 90”,其中90是全凭尺寸和渲染的百分比

更永久的设置方法是:选中你的后步骤列表里的“覆写屏幕百分比”框,之后将屏幕百分比设置成想要的百分比(小于等于100)

场景捕捉对象(如场景捕捉立方体)的默认设置是捕捉每帧。捕捉这些基本涉及到从不同视角渲染整个场景(对于一个场景捕捉立方体来说会这做6次,每次渲染竝方体的一个面)还有从玩家的视角来渲染。这样的代价明显是很大的(如果一个场景中有许多这样的对象尤其如此)所以,除非每幀都抓取它们是你的游戏的一个重要特点抓取应该被禁用。

总体来讲同样的原因,限制场景抓取物件的总数量是有道理的

可以在DefaultConfig.ini.文件中设置来控制这个变量,默认如下:

对于一些特定类型的游戏遮挡剔除可能会花费比它本身所节省的时间更多。比如:在打斗游戏中通常场景中的所有内容都应该是被渲染的,不常见的情况是许多几何图形被其他对象遮挡在这些情况下,使用全局预计算可见复选框吔许有帮助

学习从来无捷径循序渐进登高峰,感谢长期关注、热爱本站的朋友!

让每一个人能在步入社会或正在工作中的你增加知识,
当然也希望大家能用好CG资源,

我要回帖

更多关于 ue4角色角度 的文章

 

随机推荐