使用Kinect2作為Oculus遊戲應用的輸入裝置

標籤：

注: 文章寫於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座標系中分別固定不動的基準點後, 把它們進行對齊, 兩邊的座標系不就可以重合了? 方法很簡單, 把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)的發布的操作裝置已經趨於一致: 雙持控制器, 每個控制器都可以擷取位置和旋轉, 並且帶有傳統的按鈕和搖杆. 這雖然不是最自然的互動方式, 但是也是目前在成本和功能之間的一種平衡, 後續的VR遊戲開發, 操作上就可以基於這些裝置做統一的設計.

有了這個VR互動Demo的成功經驗, 我們把這種互動方式也帶入了正在開發的一個VR遊戲Demo, 在Oculus Touch沒上市之前, 這是目前我們能在VR中實現的比較好的操作體驗. 個人以為, 只是顯示方式的變化並不能帶來遊戲性上的太大變化, 雙手控制器才可以讓VR遊戲玩法產生更多創意, 從根本上推動產生新的遊戲類型和全新體驗.

使用Kinect2作為Oculus遊戲應用的輸入裝置