UDN
Search public documentation:
GameplayPerformanceOptimizationCH
English Translation
日本語訳
한국어
Interested in the Unreal Engine?
Visit the Unreal Technology site.
Looking for jobs and company info?
Check out the Epic games site.
Questions about support via UDN?
Contact the UDN Staff
日本語訳
한국어
Interested in the Unreal Engine?
Visit the Unreal Technology site.
Looking for jobs and company info?
Check out the Epic games site.
Questions about support via UDN?
Contact the UDN Staff
供游戏性程序员的使用的性能最优化方法
概述
广泛性能调查
STAT UNIT
设置为开启的状态来看看游戏,渲染或GPU是否速度慢。 如有可能应在 测试 版本上运行。 GPU时间可能无法看,但如大于另两项时间可假设等同于总体框架时间。如有质检团队的报告并分配给相关部门则更好。 一需包括在报告内的有用信息包括:
- Average FPS(平均FPS) - 原始平均fps,有时不包括动画或非互动环节。 这里的原始数字并不特别重要,只要运行数值高于vsync(一般为30),但可用来察看趋势。
- % over 30(超过30FPS的百分比) - 超过30fps的时间。 应尽可能高,一般要达到95%或更高。
- Total Hitches(总顿卡数) -花费时间超过100ms的帧数。这个值要尽可能低。
- % Bound by Game and Render(游戏和渲染绑定百分比) - 哪些慢帧是由游戏或渲染线程造成的。 如果这些值非0,您应该查看一下是如何造成的。 GPU绑定使用的百分比一般看不到,但如果其他两个绑定的百分比数字较低,即使高于30%也属于低的范围,GPU处理用时过长是很可能的原因。
游戏和渲染性能
.gprof
文件的目录并为Stat Viewer(统计数据查看器)创建 .ustats
文件。 您可以随后使用合适的工具来打开它们(一般双击即可,可能需要关联文件)
游戏线程分析
如果您开着.gprof
文件,您可以开始使用 Gameplay Profiler 查看相关问题。 一种方法是在上方图表中深入挖掘缓慢的帧。 点击一个慢帧,并察看 Frame Actor / Class Call Graph 标签及 Frame Function * 标签。 红色文本是统计信息,绿色文本是脚本调用和更新时间。



渲染线程分析
Stats Viewer 可以让您看到渲染线程,最小的更新和脚本时间的相似信息。 当您打开.ustat
,您会在右侧看到图表,左侧看到一系列过滤器。 如果您怀疑某个统计,您可以选择它查看该统计图表,但如果查看单独帧将会容易一些。 右键点击右侧的帧并选择 Open call graph 。 这可以查看单独的帧并让您查看变慢的元素,标记为红色。 当您看到一处后,您可以把它添加到总体图表中来看一下该统计造成游戏变慢的频率有多少。
常见性能问题
- Platform specific issues(平台特定问题) - 这些往往表明游戏或渲染的大量统计时间没有任何更多可用的细节。 这包含了着色器编译,声音问题,内存延迟等。一旦您确认了哪个统计确认了迟缓时间,您可以使用平台特定的本地分析器或与引擎团队讨论来获得额外的帮助。
- Script call overhead(脚本调用内存消耗) - 这条在游戏分析器中会很快出现,也很容易通过调整游戏逻辑或移动特定慢速函数到本地来解决。
- GC Time - GC Mark 和 GC Sweep 经常在游戏分析器/统计数据查看器中呈现为大的周期性的延迟. 如果在release(发行)模式下运行而没有
-NoVerifyGC
则该延迟会变得大得多,所以先要看那个值。 这些是不可能完全消除的,但是最优化GCable对象数量是主要目标。把更多的东西移入启动包并减少对象计数是很好的目标。 - Pathfinding and line checks(寻路和线性检测) - 寻路调用和线性检测经常在游戏线程中表现缓慢。 最优化此处的最容易的办法是少做一些。在游戏代码中要注意多余的寻路调用或线性检测。
- DLE Tick time(动态光照更新时间) - 在一些场景中动态光照效果的更新时间往往很高。确认只给实际需要的对象做动态光照环境,并对不需要动态光照的任何为actor放置的动态光照环境复位
bDynamic
。 在手机平台上,您可能需要进一步的优化,比如对您想要做lightmass效果而不想要动态对象的灯取消动态合成标记。 - Particle Time(粒子时间) -单独的粒子系统更新的性能消耗往往很大。您可以从游戏分析器中找出粒子系统并让美工对此最优化。或者,您可能需要改变游戏逻辑来减少它们的产生,比如如果一次攻击杀死10个敌人,您只需要在一帧内死亡的前2个敌人上做死亡粒子。 Update Bounds time 表明粒子系统需要固定的边界,而动态光照环境更新时间表明它可能正在做不必要的光照更新。这是和内容及游戏非常有关的。看一下 ParticleTickStats 获得更多细节。另外,太多的粒子可能会显示为渲染线程的 Particle update time ,而这可以通过LOD(层次细节度)或剔除来削减可见粒子的数量。
- Death and explosions(死亡和爆炸) - 死亡和爆炸的缓慢是由于不同的原因造成,一般是需要做组件更新,粒子生成和一些逻辑或AI更新。您可能需要把一些元素延迟到下一帧,或如果很多东西一起死亡则您需要把它们一起移除。
- Component Update time(组件更新时间) - 特定组件更新时间可能很长,比如骨骼网格。您需要看一下这种类型的组件,也许能把他们移到更为简单的组件类型(比如,100带顶点动画的静态网格比100 骨骼网格消耗的资源更少)
- Interp actor update time(Interp actor更新时间) -Interp actor更新起来可能在动态光照环境时间和运动时间上非常消耗资源。一个共同的修复方式是让关卡设计师在非游戏对象上标记"不要侵占" ,因为那会使停止慢速碰撞检测。
- Transparency Drawing(绘画的透明度) - 透明的物体经常在渲染线程中变得很慢,尤其是粒子。让美工确认没有叠加很多透明对象,并用LOD大量清除透明对象。
- Too Much Stuff(加入过多物体) -一般来说,美工和关卡设计喜欢在游戏里放很多东西。一般放置很多敌人(>10)或放置大量的网格物将使整体拖慢,并需要内容方面的最优化。