VR测试预研：基于unity实现VRdemo技术方法分析（下）

发表于2016-12-05

作者：付雷

Unity虚拟现实的实现方法（基于暴风SDK）

在这个Demo制作过程中，使用的是暴风魔镜的SDK，在其官网上有免费的下载。其中很多例子场景可以很快的用于学习。下面的环节重点剖析下用到的预设及主要代码。

头盔及双摄像头模式

在暴风里面主要使用的是Mojingmain这个预设，下面又分为Mojinghead和多个摄像机。其中VR camera Left和VR camera Right 的坐标几乎一致，仅仅是X轴坐标相差了0.06个单位。在Unity中一个单位等于一米，也即是说暴风给出的平均值是6厘米。我用我的眼睛用尺量了一下，我的眼镜两眼瞳距大概也是6~7厘米。所以从这个设计来看，暴风所放置的两个摄像头的距离是比较合理的。我觉得更好的做法是通过代码以及配置来动态的改变这个值。做到更加灵活。

Figure 33 暴风眼镜的摄像机布局

Figure 34 亲测一款眼镜的双眼瞳距

仅仅有模拟人眼的摄像机摆放还不足以让画面显示完美，暴风还调整了摄像头的宽度，设置为0.5，是一般摄像头的一半。

Figure 35 摄像头宽度

对于fov配置这块，暴风对于不同的VR盒子的尺寸定制了一套配置，存放在Mojing.glassesNameList里面，根据这些name，在选择后会调整摄像头的Field of view。暴风的两款产品暴风小d和暴风3都使用过，都是可以调节左右瞳距的。

Figure 36 暴风对市面眼镜盒子的尺寸适配

至于在摄像头在运行中的位置变化，主要在MojingVrHead的UpdateHead方法中实现，改变头盔的方向和坐标，具体参考如下代码段：

Figure 37 暴风调整头盔的代码

通过上面对暴风的配置和主要代码的展示，相信大家对于这个虚拟世界中两个摄像头是如何完成人的头部运动的模拟有了些认识。

在本场景中，我把一个空物体放在暴风的摄像头下面，并且设置其相对坐标为0 ，这样就可以作为一个参考坐标，到时候我想发射小球时，这个空物体eyePosition自身的坐标就是起始点了。发射方向就是摄像机的前方。

Figure 38 跟随镜头的物体

下面这一段是demo中最主要的代码，其中的position和rotation赋值就是参考eyeposition的坐标：

Figure 39 向前射击小球的方法

通过gaze交互的技术实现

所谓的gaze，就是注视的意思。在VR中交互除了手柄等外设，最主要的交互就是靠眼神的注视，暴风魔镜app在交互上就是采用凝视几秒的方法判断用户选择某个按钮的。

想完成这个交互在理解了上面的分析后比较简单，结合unity的一个技术就可以实现。具体就是调用Raycast方法，其函数原型如下：

Public static bool Raycast(Vector3 origin, Vector3 direction, out RaycastHit hitInfo,float maxDistance = Mathf.Infinity, int layerMask =DefaultRaycastLayers, QueryTriggerInteraction = QueryTriggerInteraction.UseGlobal);

主要参数解释

origin	射线发射的起点
direction	射线发射的方向
hitInfo	摄像与其他物体重合“碰撞”后的撞击点信息
layerMask	是否需要过滤，仅与指定的mask对象碰撞

代码示例：

Figure 40 射线方法举例

下面总结下发射射线以及碰撞后获取hit的步骤：

1、在你的 camera中添加一个000坐标000转向的物体，如上面的eyePosition

2、在其绑定的update方法中“投射”一个射线出去，也即调用rayCast

3、射线击中的对象 hit将返回坐标信息

4、利用这个坐标信息进行下一步控制

谈谈3D移植到VR

经过上面的分析，大家应该对unity中如何创建基本的物体和基本的交互有了感觉。如果我们手上有以前做的3D游戏，我们能快速定制一下，做成VR效果吗？个人觉得是有一定条件的。

1、3D场景的背景需要支持全视角观察。如果你的游戏从头到尾都是俯视的，周围的布景是空白的，那么你需要添加类似天空盒或者“墙”的元素进去。

2、交互上的适配成本。如果你的游戏是复杂按键软键盘的格斗游戏，那么可能不太合适，要做的真实，需要用HTC vive类似的手柄来触发攻击，修改成本不小。

目前来看VR制作的主题多为第一视角射击、飞行、坠落等。移植方法主要是替换原来的摄像头，使用包含左右眼的头盔式模型替代。摄像头放置的位置也需要多次试验体验。

鉴于当前设备性能以及重量的现状，制作的场景内容体验10分钟左右就算不错，随着设备的提升，制作的内容可以更长有更多场景的切换。

Figure 41 另一款demo 异域救援

VR测试的方向探讨

前面通过庖丁解牛的方式分析了一个demo级VRapp的产生过程，最后这一部分探讨一下测试工作可能的点。

机型分辨率适配

产品如果需要适配市面不同的盒子，需要了解这些盒子的尺寸，屏幕与镜片的距离，并且类似暴风这样配置一组参数，来调整fov以及瞳距。这些测试直观感觉比较大，初期在可靠的图像识别标准出来之前，肯定是一直使用人肉测试的。

关键词：fov、瞳距

关于性能

目前盒子类产品计算量都在手机上，VRapp如果对于资源的处理不好，几分钟手机就发烫了。一般优化的方法主要是gameobject的释放、纹理的压缩、使用烘焙贴图而不是实时灯光等。

测试性能的主要思路是对每个版本性能采集，进行版本间性能数据对比，每个版本的性能指标可以自己定也可以逐步形成内部标准。采集的工具可以利用unity的Profiler，该工具能全面展示运行时各种数据，应该unity有提供api去直接从接口级获取这些数据。当然在PC端和安卓手机运行时使用普通的app测试性能方法也可以作为辅助手段。

Figure 42 unity的Profiler

对应这些数据的对比，需要搭建简单的web展示，供团队查看。

关键词：Profiler、对比、展示

关于自动化构建

对于版本构建这块是肯定必须自动化完成的。Unity在这方面提供了很好地支持。这块主要用到了unity脚本中的BuildPipeline 类。具体参考实践，网上的雨凇MOMO有帖子参考：http://www.xuanyusong.com/archives/2418 。自动构建之后自动运行，运行过程采集性能数据以及是否crash等基本稳定性。

http://docs.unity3d.com/ScriptReference/BuildPipeline.html