使用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游戏应用的输入设备的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 观天利器-stellarium
- 下一篇： Stellarium Windows/L