基于Unreal Engine 4 的虚拟现实插件分析

研究unreal也有两三周了，一直在熟悉其插件工程c 开发环境和steam/oculus的vr实现。得出一些经验和结论：

1.      unreal的c 开发环境。一个完整的unreal游戏工程（应用）包含以下两个部分：

a)        主体c 源码。包含了游戏中基本元素和逻辑的扩展实现。当前开发调试已经很便利，可以在UE4编辑器中实时同步代码和编译。

b)        插件c 源码。将一些通用的功能集合起来，通过专用接口集成到UE4的编辑器环境，方便在多个工程之间重复使用。当前开发调试尚不完善，管方文档对插件的形式和开发流程仍处在测试阶段。

2.      内置oculus-rift插件的剥离和调试。

a)        内置oculus插件是事先编译好binary而无法增加打印信息或者调试源码的。

b)        剥离至独立游戏开发工程作为外置插件，并实时调试代码，补全了一些缺失的代码，现在可以正常配合DK2进行调试。这个对后面研究oculus的vr实现起到了很大的参考作用。

3.      UE4 VR插件现状:

a)        UE4针对HMD提供了统一的接口IHeadMountedDisplay和ISceneViewExtension供第三方来实现，然后通过HMD设备类型注册到引擎内部。这是当前UE4已经注册的设备：

b)   UE4提供了一个demo级HMD设备插件实现：SimpleHMD，类型即上面的DT_ES2GenericStereoMesh。但基本只实现了个分屏功能。

c)        UE4对于VR的代码实现与HMD厂商的核心研发其实是一种相互竞争和此消彼长的关系。虽然引擎源码当前只是稳定的实现了stereo render分屏功能，但是预留的接口比如distortion mesh和他不断优化的特性，同样表明UE4想覆盖几乎所有的VR核心实现。于是，这些已经注册设备的厂商在代码实现上有两个选择：

                                      i.              Morpheus选择了最大程度依赖UE4的研发，将主逻辑和核心实现嵌入到引擎里。于是就有了下面这类代码（在UE4的图像后期处理模块里）：

                                    ii.              oculus和steam在引擎内部基本没有植入，只是依照UE4在外部插件开放的接口来做。

                                  iii.              除了以上两个选择之外，国内3-Glasses的做法同样是在引擎中定义自己的type，配合自己的插件使用。但是需要开发者自己下载UE4源码修改编译（大概是交不起这么大笔授权费）。最大程度的实现和利用SimpleHMD的现有接口（包括畸变）。（至少我严重怀疑畸变功能的可用性，因为这个接口无论在oculus还是simplehmd中经测试从来没有被成功调用过）

4.      一个完整的VR应用是这样运行的：

a)        VR应用启动，通过usb从HMD取回当前姿态信息，并绘制对应的画面；

b)        将画面通过HDMI/DP传输到HMD的同时，在桌面上显示一个镜像。

5.      Oculus和steam VR插件实现了哪些功能？如何做到的？

a)        从oculus/steam sdk获取当前姿态（包括旋转、位移）数据，通过UE4接口实现传递给引擎。

b)        引擎根据姿态信息和场景绘制画面。

c)        Oculus/steam从UE4拿到当前平台渲染设备（D3D/OPENGL），并截获已绘制画面，在sdk中进行畸变和其他优化处理（如timewarp）。

d)        通过sdk将画面传输给HMD。对于非扩展桌面方式的HMD来说，往往通过direct render来实现。

e)        将画面同时显示到普通已开辟窗口作为镜像。

而oculus/steam sdk的调用方式就是映射dll里的函数。这捍卫了他们的核心实现，也站稳了跟游戏引擎厂商讨价还价的脚跟。

6.      Oculus sdk以及runtime的架构如下

如果再回过头来对比下google cardboard和oculus sdk的架构，两者真的有太多异曲同工之处。在性能攸关的地方，google和oculus都采取了封闭的策略，只提供Native的binary封装。但至少google慷慨点，核心部分还是给了一个开源的乞丐版实现。