Skip to main content
 首页 » 资源教程

UE4 X HTC Vive游戏开发笔记(一)

2016年08月26日 18:29:4911690

UE4 X HTC Vive游戏开发笔记(一) 资源教程

最近开始用UE4做VR游戏,网络上这方面的资料比较少,所以写个文章记录一下开发过程中碰到的问题和解决方案,希望对其它开发者有所帮助。

(题外话:Vive的效果真的很棒,完全打开了新世界大门的感觉。目前来说头盔太重有连线,不方便而且戴久了会累,然后需要的安装空间也比较大。随着设备的不断进化目测未来有一天将会完全的改变我们的生活..对此我想说...早买早享受,只要$699,买不了吃亏买不了上当....)

因为采用的是UE4引擎4.12版本,对VR的支持已经很到位,操作、Camera、Deploy等已经做的非常丝滑流畅。这里主要讲一下游戏的优化。

因为定位是单机游戏,屏幕内单位数量不多。加上目标设备是i7+GTX980,所以我们一开始以为性能瓶颈会比以往来的要晚一些。但是事实证明VR对性能要求高的这个说法...是真!的!很!高!场景里只放了简模+两个角色+一个Stationary Directional Light,加上一点点particle和少许PostProcessing,在设备上跑起来就只有45帧了。此时此刻我的内心是崩溃的...(PS:不过Vive上45帧的感受还可以,没有很明显卡顿,也不太会导致眩晕。但是GearVR不满帧的话就有种玩不下去的感觉..)

然后开始对性能瓶颈进行定位、尝试优化。首先用stat unit观察,VR模式下Frame Time为22ms,Game Thread只有7ms,Rendering Thread和GPU均为22ms。各个参数的意义参考这篇文章: How to improve game thread CPU performance in Unreal Engine

下一步需要确定是Render Thread瓶颈还是GPU瓶颈。结合stat SceneRendering、stat INITVIEWS和stat SceneUpdate命令来观察CPU的开销。我们项目的实际情况是drawcall数量很低,在Culling之类的步骤中的开销也很小,再加上在PC模式下测试Render Thread开销仅为0.1ms。因此初步猜测是GPU bound导致Rendering Thread卡住了。几个命令的意思和参数具体参考:

Render Thread Profiling and Optimization

Stat Commands

为了证实目前为GPU bound,用UE4自带的profile GPU工具来观察GPU开销。然后问题来了:GPU开销为13ms..而不是22ms...那为什么只有45帧??? 这里和负责引擎的同事做了各种假设,比如左右眼画面进行了SwapBuffer操作,而profiler只抓取了一个view的渲染时长,比如UE4 VR Preview模式下PC上还会额外显示一个画面所以是渲染了三次,比如为了减少延迟的感觉所以frameBuffer没有缓冲等等等...游戏中还观察到另外一个现象,在某些角度下为45帧,某些角度下为90帧,FrameTime在11ms和22ms之间跳动。后来是在一篇Valve的GDC文章里找到了答案:

Advanced VR Rendering

Page 21和22提到了VSync机制。根据文档SteamVR每11.11ms做一次sync操作。如果GPU渲染时间超过了11.11ms,那么CPU会推迟到下一个11.11ms再发送command。这样一帧实际上就是22.22ms(45帧)。为了测试,在游戏中通过关闭灯光、PostProcessing等操作观察帧数和GPU frameTime的变化,发现小于11.11ms时均为90帧,大于11.11ms时均为45帧。

所以...要保持稳定流畅的游戏体验...必须在任何时刻...任何视角...将GPU渲染时间保持在11.11ms以下...一旦超过11.11ms就会直接掉一半帧....

目前进展只到这里所以先写到这里...有后续进展再更新...

(下一步计划:用NVIDIA NSight看一下CPU GPU的时序、抓帧看一下VIVE渲染到底是几个framebuffer、分析GPU profile的结果发现有一个高达2-3ms的HZB SetupMips,而且跟光照有关,需要详细看一下原因、参考Valve文档中提到的几个优化,考虑如何在不影响画面效果的前提下进行优化...)

评论列表暂无评论
发表评论