注: 文章写于2015年8月, 眼下VR游戏Demo已经完结, 所以把上一次预研的一些经验分享出来, 希望对大家有所帮助

初接触Oculus时, 从网上下载了一大堆的Demo来体验, 可是, 操作体验大都比較差, 特别是FPS类. 这也让我们意识到, 对于VR游戏, 最大的挑战还不是显示方式的变化, 而是交互方式. 在一个沉浸式的环境中, 最自然的交互就是最完美的方式. 当中主要的需求, 就是能够使用双手跟VR中的虚拟环境进行交互. 这么一来, 首先键鼠或手柄就被排除掉了, 我们仅仅好针对市面上的一些输入设备, 挨个进行评估实验:
- Wiimote: 仅仅能检測运动和方向, 无法准确定位双手的位置
- Leap Motion: 粘在Oculus上能够模拟出双手, 可是识别范围太小, 骨骼的稳定性比較差, 严重影响体验
- Razer Hydra: 能够获取双手的空间位置和旋转, 加上两个手柄上的按键也能触发一些状态切换, 算是看起来还不错的方案. 缺点是位置偏差比較大, 可能是磁场受干扰的问题
- RealSense: 相似LeapMotion, 可是精度比較低, 导致识别出的骨骼位置抖动严重, 无法用于双手的骨骼映射

试来试去, 好像眼下市面上除了高成本的动作捕捉设备, 还没有比較完美的VR输入设备能够用. 最后, 把目光转向了旁边XboxOne开发机配的Kinect2.
因为我们组去年进行了XboxOne体感游戏的研发, 积累了一些Kinect2体感操作的经验, 就把Kinect2连接到了PC上, 看看能不能把体感操作与Oculus的VR显示结合到一起.

需求分析

前面也提到了, 尽量达到接近自然的交互方式, 那就须要实现这几个关键点:

• 能够在虚拟世界中显示出双手, 最好能有肢体躯干
• 虚拟空间中的双手位置与现实空间中跟头部的相对位置(包含旋转)保持一致
• 能够使用双手对虚拟世界中的物体产生影响
• 能够识别一些简单的手势, 如抓, 推, 拉, 按, 摸等等

那Kinect2提供的数据或者功能有哪些呢?

• 30帧/s的Color/Depth/BodyIndex/IR数据
• 身体骨骼位置和朝向(比較不稳定, 会抖动)
• 双手的三种状态识别, 正好相应 石头 剪刀 布(误识别率较高)
• 其他诸如语音之类的功能临时用不上

像LeapMotion那样每根手指单独识别是做不到了, 退而求其次, 仅仅能在交互设计上就去规避过小元素, 使用整个手掌做为交互
双手的骨骼位置能够为我们提供双手的空间定位, 而三种状态能够參考我们在XboxOne体感游戏中的UI交互经验, 把抓住拖动之类的手势利用起来

实现细节

双手肢体的绘制

因为Kinect API已经提供了人体骨骼的变换信息, 那自然而然的我们就想在游戏中绑定到一个蒙皮模型上

终于我们也在UE4中实现了, 可是体验下来很不惬意, 为什么呢?

• Kinect中获取的骨骼变换信息会频繁抖动, 假设不进行处理, 会像抽风一样
• 假设对骨骼变换数据进行稳定性的过滤处理, 会添加响应延迟, 导致虚拟肢体的动作比实际总是慢半拍
• 不同体形的的人的映射到同一模型的效果会有问题, 比方想象一下一个身材高大的人在Oculus中看到自己胳膊变短了是什么感觉. 这会影响基于直觉和经验的空间位置推断

那还有什么别的方法去实现双手肢体的绘制吗? 在使用KinectStudio调试时, 发现3D视图下的深度呈现比較有意思:

事实上这就是深度数据(DepthBuffer)映射到3D空间里的离散的点, 这里我把这样的表示方式称之为 “点云(PointCloud)”

于是突发奇想, 在虚拟空间使用点云表现自己的躯体, 双手手指的动作也能够精确地映射过去. 那么, 这可行吗?

• 延迟: 因为DepthBuffer是硬件採集的原始数据, 是没有经过处理的, 不存在中间的数据处理时间(延迟), 所以在响应速度上肯定是很理想的, 能够控制在70ms左右(Kinect2硬件固定60ms)
• 数据量: DepthBuffer的分辨率是512x424, 也就是须要映射到21万多个顶点, 虽说有点多, 但也在可接受范围内, 实在不行能够隔行取点, 以终于效果需求为准
• UE4点云渲染: 每帧依据DepthBuffer计算出相应的VertexBuffer, 构建DynamicMesh进行绘制, PrimitiveType使用PointList
  

然后再依据BodyIndex数据剔除掉周围环境和其他人的点, 就完美的把自己映射到UE4的3D场景中了. 下图加了个简单的材质, 顶点法线使用地形中经常使用的SlopeBased方法计算

点云坐标系对齐

有了点云的躯体了, 怎么把它 “装”在虚拟世界中的头以下呢?
因为Kinect, Oculus, UE4相当于是三个不同的坐标系, 假设要把点云映射到Oculus视角下身体的位置, 须要一些坐标映射和转换.

• UE4已经默认集成了Oculus的支持, 所以这两个坐标系的处理不用我们担心了, 默认Oculus头戴显示器的坐标就是UE4摄像机的位置加上PostionTracking的Offset
• 而Oculus头戴显示器的位置来源于Oculus DK2中带的CameraSensor, 这才是Oculus虚拟坐标的基准点, 仅仅只是UE4做了变换, 把Oculus初始位置映射到了摄像机的位置上
• Kinect中的DepthBuffer映射成顶点后, 全都是CameraSpacePoint, 即Kinect设备本身就是原点. 须要注意的是, Kinect坐标与UE4坐标须要做一下转换, 相应关系为 UE4Vector = FVector(-V.Z * 100, V.X * 100, V.Y * 100)

那找到Oculus和Kinect坐标系中分别固定不动的基准点后, 把它们进行对齐, 两边的坐标系不就能够重合了?

方法很easy, 把Kinect和Oculus的CameraSensor”合体”:

游戏中能够通过CameraComponent位置和Oculus的CameraOrigin计算出Sensor的世界坐标, 然后把点云对齐到这个位置就可以, 通过一个能够保存配置的Offset进行偏移校正

交互设计

整个交互灵感事实上来源于钢铁侠电影里的全息投影的交互片段, 我们的目标就是把这样的科幻片中经常出现的镜头变成现实

以全息投影的感觉做为美术风格的指导方向, 结合我们日常接触最多的功能, 我们实现了5种交互控件:

• 图片查看器: 仅仅有一个翻页操作
  

• 视频播放器, 能够操作播放/暂停, 放大后有电影院看电影的感觉, 这也是眼下VR视频应用比較经常使用的方式
  

• 网页浏览器: 我们集成了CEF, 相当于内嵌了一个chrome, 支持HTML5的游戏. 以下的视频中我们选择了一个H5的猜单词小游戏, 支持网页上的点击操作
  

• 打飞机小游戏: 这个是使用体感操作的, 尽管是一个2D平面的游戏, 可是爆炸后的碎片会落到地板上, 视觉效果还不错
  

• 模型查看器: 主要是用于演示在3D空间怎么用双手比較直观地观察一个三维物体, 能够说这才是VR交互的亮点所在, 你能够从各个角度和随意大小去观察一个物体的每一个细节
  

每一个控件我们还做了统一的Tooltips的弹出动画提示, 这样的3D空间的信息显示也是AR应用场景中比較常见的

为了更好地展示每一个控件的功能, 我们把整个全息交互场景分成了前后两”层”

• 远景: 仅仅能同一时候存在一个控件, 能够抓住进行拖动和缩放操作, 并进行每一个控件特定的功能操作, 如网页的点击, 小游戏的手势移动等等.
• 近景: 摆放各个功能控件, 相当于任务栏图标, 能够通过手势把它”扔”到远景的那一层上去, 相当于窗体最大化/Active状态

对远景的控件进行操作时, 双手各加了一根闪电特效, 如同释放魔法一样, 在远处控件上模拟出相似iPad的操作体验

PS: 为了不正确第一人称的VR显示产生干扰, 已经把点云的头”砍”掉了

近景的交互是基于双手的”Touch”操作, 通过Kinect获取双手骨骼位置, 挂了两个碰撞体用于检測与控件之间的Overlap状态

效果展示

点击播放视频(略)

优化

基于VertexBuffer的点云因为要进行顶点坐标计算, 十分消耗CPU, 为了节省时间, 能够把顶点计算转移到GPU, 使用静态VertexBuffer+动态VertexTexture进行Mesh的构建, 而同一时候带来的优点是点云不再限于Point渲染, 能够做成Particle的样子

总结

在做VR技术预研的过程中, 我们也发现三大VR设备(Oculus, Steam VR, PS VR)的公布的操作设备已经趋于一致: 双持控制器, 每一个控制器都能够获取位置和旋转, 而且带有传统的button和摇杆. 这尽管不是最自然的交互方式, 可是也是眼下在成本和功能之间的一种平衡, 兴许的VR游戏开发, 操作上就能够基于这些设备做统一的设计.

有了这个VR交互Demo的成功经验, 我们把这样的交互方式也带入了正在开发的一个VR游戏Demo, 在Oculus Touch没上市之前, 这是眼下我们能在VR中实现的比較好的操作体验. 个人以为, 仅仅是显示方式的变化并不能带来游戏性上的太大变化, 双手控制器才干够让VR游戏玩法产生很多其他创意, 从根本上推动产生新的游戏类型和全新体验.