當(dāng)前位置：首頁(yè) > 运维知识 > windows >内容正文

windows

[译]Kinect for Windows SDK开发入门(八)：骨骼追踪进阶上

發(fā)布時(shí)間：2025/3/15 windows 21 豆豆

生活随笔收集整理的這篇文章主要介紹了 [译]Kinect for Windows SDK开发入门(八)：骨骼追踪进阶上小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

???

??? 前7篇文件我們介紹了Kinect SDK中各種傳感器的各種基本知識(shí)，我們用實(shí)驗(yàn)的方式演示了這些基本對(duì)象和方法的如何使用，這些都是Kinect開(kāi)發(fā)最基本的知識(shí)。了解了這些基本知識(shí)后，就可以開(kāi)發(fā)出一個(gè)基于Kinect的簡(jiǎn)單程序了。但是這些離開(kāi)發(fā)出一個(gè)好的基于Kinect的應(yīng)用程序還有一段距離。后面的文章中，將會(huì)結(jié)合Kinect SDK介紹WPF以及其它第三方工具，類庫(kù)來(lái)建立一個(gè)以Kinect為驅(qū)動(dòng)的有較好用戶體驗(yàn)的程序。我們將利用之前講到的知識(shí)來(lái)進(jìn)行下面一些比較復(fù)雜的話題。

??? Kinect傳感器核心只是發(fā)射紅外線，并探測(cè)紅外光反射，從而可以計(jì)算出視場(chǎng)范圍內(nèi)每一個(gè)像素的深度值。從深度數(shù)據(jù)中最先提取出來(lái)的是物體主體和形狀，以及每一個(gè)像素點(diǎn)的游戲者索引信息。然后用這些形狀信息來(lái)匹配人體的各個(gè)部分，最后計(jì)算匹配出來(lái)的各個(gè)關(guān)節(jié)在人體中的位置。這就是我們之前介紹過(guò)的骨骼追蹤。

紅外影像和深度數(shù)據(jù)對(duì)于Kinect系統(tǒng)來(lái)說(shuō)很重要，它是Kinect的核心，在Kinect系統(tǒng)中其重要性僅次于骨骼追蹤。事實(shí)上，這些數(shù)據(jù)相當(dāng)于一個(gè)輸入終端。隨著Kinect或者其他深度攝像機(jī)的流行和普及。開(kāi)發(fā)者可以不用關(guān)注原始的深度影像數(shù)據(jù)，他們變得不重要或者只是作為獲取其他數(shù)據(jù)的一個(gè)基礎(chǔ)數(shù)據(jù)而已。我們現(xiàn)在就處在這個(gè)階段，Kinect SDK并沒(méi)有提供給開(kāi)發(fā)者訪問(wèn)原始紅外影像數(shù)據(jù)流的接口，但是其它第三方的SDK可以這么做。可能大多數(shù)開(kāi)發(fā)者不會(huì)使用原始的深度數(shù)據(jù)，用到的只是Kinect處理好了的骨骼數(shù)據(jù)。但是，一旦姿勢(shì)和手勢(shì)識(shí)別整合到Kinect SDK并成為其一部分時(shí)，可能開(kāi)發(fā)者甚至不用接觸到骨骼數(shù)據(jù)了。

??? 希望能夠早日實(shí)現(xiàn)這種集成，因?yàn)樗磉@Kinect作為一種技術(shù)的走向成熟。本篇文章和下篇文章仍將討論骨骼追蹤，但是采用不同的方法來(lái)處理骨骼數(shù)據(jù)。我們將Kinect作為一個(gè)如同鼠標(biāo)，鍵盤或者觸摸屏那樣的一個(gè)最基本的輸入設(shè)備。微軟當(dāng)初推出Kinect for Xbox的口號(hào)是“你就是控制器”，從技術(shù)方面講，就是“你就是輸入設(shè)備”。通過(guò)骨骼數(shù)據(jù)，應(yīng)用程序可以做鼠標(biāo)或者觸摸屏可以做的事情，所不同的是深度影像數(shù)據(jù)使得用戶和應(yīng)用程序可以實(shí)現(xiàn)以前從沒(méi)有過(guò)的交互方法。下面來(lái)看看Kinect控制并與用戶界面進(jìn)行交互的機(jī)制吧。

1. 用戶交互

??? 運(yùn)行在電腦上的應(yīng)用程序需要輸入信息。傳統(tǒng)的信息來(lái)自于鼠標(biāo)或者鍵盤等這些輸入設(shè)備。用戶直接與這些硬件設(shè)備進(jìn)行交互，然后硬件設(shè)備響應(yīng)用戶的操作，將這些操作轉(zhuǎn)換成數(shù)據(jù)傳輸?shù)接?jì)算機(jī)中。計(jì)算機(jī)接收這些輸入設(shè)備的信息然后將結(jié)果以可視化的形式展現(xiàn)出來(lái)。大多數(shù)計(jì)算機(jī)的圖像用戶界面上會(huì)有一個(gè)光標(biāo)(Cursor)，他通常代表鼠標(biāo)所在的位置，因?yàn)槭髽?biāo)是最開(kāi)始有個(gè)滾輪設(shè)備。但是現(xiàn)在，如果將這個(gè)光標(biāo)指代鼠標(biāo)光標(biāo)的話，可能不太準(zhǔn)確，因?yàn)楝F(xiàn)在一些觸摸板或手寫設(shè)備也能像鼠標(biāo)那樣控制光標(biāo)。當(dāng)用戶移動(dòng)鼠標(biāo)或者在觸摸板上移動(dòng)手指時(shí)，光標(biāo)也能響應(yīng)這種變化。當(dāng)用戶將光標(biāo)移動(dòng)到一個(gè)按鈕上時(shí)，通常按鈕的外觀會(huì)發(fā)生變化，提示用戶光標(biāo)正位于按鈕上。當(dāng)用戶點(diǎn)擊按鈕時(shí)，按鈕則為顯示另一種外觀。當(dāng)用戶松開(kāi)鼠標(biāo)上的按鍵，按鈕就會(huì)出現(xiàn)另外一種外觀。顯然，簡(jiǎn)單的點(diǎn)擊事件會(huì)涉及到按鈕的不同狀態(tài)。

??? 開(kāi)發(fā)者可能對(duì)這些交互界面和操作習(xí)以為常，因?yàn)橹T如WPF之類的用戶交互平臺(tái)使得程序與用戶進(jìn)行交互變得非常簡(jiǎn)單。當(dāng)開(kāi)發(fā)網(wǎng)頁(yè)程序時(shí)，瀏覽器響應(yīng)用戶的交互，開(kāi)發(fā)者只需要根據(jù)用戶鼠標(biāo)的懸停狀態(tài)來(lái)設(shè)置樣式即可進(jìn)行交互。但是Kinect不同，他作為一個(gè)輸入設(shè)備，并沒(méi)有整合到WPF中去，因此，作為一個(gè)開(kāi)發(fā)者。對(duì)操作系統(tǒng)和WPF所不能直接響應(yīng)的那部分工作需要我們來(lái)完成。

??? 在底層，鼠標(biāo)，觸摸板或者手寫設(shè)備都是提供一些X,Y坐標(biāo)，操作系統(tǒng)將這些X，Y坐標(biāo)從其在的空間坐標(biāo)系統(tǒng)轉(zhuǎn)換到計(jì)算機(jī)屏幕上，這一點(diǎn)和上篇文章討論的空間變換類似。操作系統(tǒng)的職責(zé)是響應(yīng)這些標(biāo)準(zhǔn)輸入設(shè)備輸入的數(shù)據(jù)，然后將其轉(zhuǎn)換到圖形用戶界面或者應(yīng)用程序中去。操作系統(tǒng)的圖形用戶界面顯示光標(biāo)位置，并響應(yīng)用戶的輸入。在有些時(shí)候，這個(gè)過(guò)程沒(méi)有那么簡(jiǎn)單，需要我們了解GUI平臺(tái)。以WPF應(yīng)用程序?yàn)槔?#xff0c;它并沒(méi)有對(duì)Kinect提供像鼠標(biāo)和鍵盤那樣的原生的支持。這個(gè)工作就落到開(kāi)發(fā)者身上了，我們需要從Kinect中獲取數(shù)據(jù)，然后利用這些數(shù)據(jù)與按鈕，下拉框或者其他控件進(jìn)行交互。根據(jù)應(yīng)用程序或者用戶界面的復(fù)雜度的不同，這種工作可能需要我們了解很多有關(guān)WPF的知識(shí)。

1.1 WPF應(yīng)用程序中輸入系統(tǒng)介紹

??? 當(dāng)開(kāi)發(fā)一個(gè)WPF應(yīng)用程序時(shí)，開(kāi)發(fā)者并不需要特別關(guān)注用戶輸入機(jī)制。WPF會(huì)為我們處理這些機(jī)制使得我們可以關(guān)注于如何響應(yīng)用戶的輸入。畢竟作為一個(gè)開(kāi)發(fā)者，我們更應(yīng)該關(guān)心如何對(duì)用戶輸入的信息進(jìn)行分析處理，而不是重新造輪子來(lái)考慮如何去收集用戶的輸入。如果應(yīng)用程序需要一個(gè)按鈕，只需要從工具箱中拖一個(gè)按鈕出來(lái)放在界面上，然后在按鈕的點(diǎn)擊事件中編寫處理邏輯即可。在大多數(shù)情況下，開(kāi)發(fā)者可能需要對(duì)按鈕設(shè)置不同的外觀以響應(yīng)用戶鼠標(biāo)的不同狀態(tài)。WPF會(huì)在底層上為我們實(shí)現(xiàn)這些事件，諸如鼠標(biāo)何時(shí)懸停在按鈕上，或者被點(diǎn)擊。

??? WPF有一個(gè)健全的輸入系統(tǒng)來(lái)從輸入設(shè)備中獲取用戶的輸入信息，并響應(yīng)這些輸入信息所帶來(lái)的控件變化。這些API位于System.Windows.Input命名空間中(Presentation.Core.dll)，這些API直接從操作系統(tǒng)獲取輸入設(shè)備輸入的數(shù)據(jù)，例如，名為Keyboard，Mouse，Stylus，Touch和Cursor的這些類。InputManager這個(gè)類負(fù)責(zé)管理所有輸入設(shè)備獲取的信息，并將這些信息傳遞到表現(xiàn)框架中。

??? WPF的另一類組件是位于System.Windows命名空間(PresentationCore.dll)下面的四個(gè)類，他們是UIElement，ContentElement，FrameworkElement以及FrameworkContentElement 。FrameworkElement繼承自UIElement，FrameworkContentElement繼承自ContentElement。這幾個(gè)類是WPF中所有可視化元素的基類，如Button，TextBlock及ListBox。更多WPF輸入系統(tǒng)相關(guān)信息可以參考MSDN文檔。

??? InputManager監(jiān)聽(tīng)所有的輸入設(shè)備，并通過(guò)一系列方法和事件來(lái)通知UIElement和ContentElement對(duì)象，告知這些對(duì)象輸入設(shè)備進(jìn)行了一些有關(guān)可視化元素相關(guān)的操作。例如，在WPF中，當(dāng)鼠標(biāo)光標(biāo)進(jìn)入到可視化控件的有效區(qū)域時(shí)就會(huì)觸發(fā)MouseEnterEvent事件。UIElement和ContentElement對(duì)象也有OnMouseEnter事件。這使得任何繼承自UIElement或者ContentElement類的對(duì)象也能夠接受來(lái)自輸入設(shè)備的所觸發(fā)的事件。WPF會(huì)在觸發(fā)任何其它輸入事件之前調(diào)用這些方法。在UIElement和ContentElement類中也有一些類似的事件包括MouseEnter，MouseLeave，MouseLeftButtonDown，MouseLeftButtonUp，TouchEnter，TouchLeave，TouchUp和TouchDown。

??? 有時(shí)候開(kāi)發(fā)者需要直接訪問(wèn)鼠標(biāo)或者其他輸出設(shè)備，InputManager對(duì)象有一個(gè)稱之為PrimaryMouseDevice的屬性。他返回一個(gè)MouseDevice對(duì)象。使用MouseDevice對(duì)象，能夠在任何時(shí)候通過(guò)調(diào)用GetScreenPositon來(lái)獲取鼠標(biāo)的位置。另外，MouseDevice有一個(gè)名為GetPositon的方法，可以傳入一個(gè)UI界面元素，將會(huì)返回在該UI元素所在的坐標(biāo)空間中的鼠標(biāo)位置。當(dāng)需要判斷鼠標(biāo)懸停等操作時(shí)，這些信息尤其重要。當(dāng)Kinect SDK每一次產(chǎn)生一幅新的SkeletonFrame幀數(shù)據(jù)時(shí)，我們需要進(jìn)行坐標(biāo)空間轉(zhuǎn)換，將關(guān)節(jié)點(diǎn)位置信息轉(zhuǎn)換到UI空間中去，使得可視化元素能夠直接使用這些數(shù)據(jù)。當(dāng)開(kāi)發(fā)者需要將鼠標(biāo)作為輸入設(shè)備時(shí)， MouseDevice對(duì)象中的GetScreenPositon和GetPosition方法能提供當(dāng)前鼠標(biāo)所在點(diǎn)的位置信息。

??? 在有些情況下，Kinect雖然和鼠標(biāo)相似，但是某些方面差別很大。骨骼節(jié)點(diǎn)進(jìn)入或者離開(kāi)UI上的可視化元素這一點(diǎn)和鼠標(biāo)移入移出行為類似。換句話說(shuō)，關(guān)節(jié)點(diǎn)的懸停行為和鼠標(biāo)光標(biāo)一樣。但是，類似鼠標(biāo)點(diǎn)擊和鼠標(biāo)按鈕的按下和彈起這些交互，關(guān)節(jié)點(diǎn)與UI的交互是沒(méi)有。在后面的文章中，可以看到使用手可以模擬點(diǎn)擊操作。在Kinect中相對(duì)于實(shí)現(xiàn)鼠標(biāo)移入和移出操作來(lái)說(shuō)，對(duì)鼠標(biāo)點(diǎn)擊這種支持相對(duì)來(lái)說(shuō)較弱。

??? Kinect和觸摸板也沒(méi)有太多相同的地方。觸摸輸入可以通過(guò)名為Touch或者TouchDevice的類來(lái)訪問(wèn)。單點(diǎn)的觸摸輸入和鼠標(biāo)輸入類似，然而，多點(diǎn)觸控是和Kinect類似的。鼠標(biāo)和UI之間只有一個(gè)交互點(diǎn)（光標(biāo)）但是觸摸設(shè)備可以有多個(gè)觸控點(diǎn)。就像Kinect可以有多個(gè)游戲者一樣。從每一個(gè)游戲者身上可以捕捉到20個(gè)關(guān)節(jié)點(diǎn)輸入信息。Kinect能夠提供的信息更多，因?yàn)槲覀冎烂恳粋€(gè)輸入點(diǎn)是屬于游戲者身體的那個(gè)部位。而觸控輸入設(shè)備，應(yīng)用程序不知道有多少個(gè)用戶正在觸摸屏幕。如果一個(gè)程序接收到了10個(gè)輸入點(diǎn)，無(wú)法判斷這10個(gè)點(diǎn)是一個(gè)人的10個(gè)手指還是10個(gè)人的一個(gè)手指觸發(fā)的。雖然觸控設(shè)備支持多點(diǎn)觸控，但這仍然是一種類似鼠標(biāo)或者手寫板的二維的輸入。然而，觸控輸入設(shè)備除了有X,Y點(diǎn)坐標(biāo)外，還有觸控接觸面積這個(gè)字段。畢竟，用戶用手指按在屏幕上沒(méi)有鼠標(biāo)光標(biāo)那樣精確，觸控接觸面積通常大于1個(gè)像素。

??? 當(dāng)然，他們之間也有相似點(diǎn)。Kinect輸入顯然嚴(yán)格地符合WPF 所支持的任何輸入設(shè)備的要求。除了有其它輸入設(shè)備類似的輸入方式外，他有獨(dú)特的和用戶進(jìn)行交互的方式和圖形用戶界面。核心上，鼠標(biāo)，觸控板和手寫板只傳遞一個(gè)像素點(diǎn)位置嘻嘻你。輸入系統(tǒng)確定該點(diǎn)在可見(jiàn)元素上下文中的像素點(diǎn)位置，然后這些相關(guān)元素響應(yīng)這個(gè)位置信息，然后進(jìn)行響應(yīng)操作。

??? 期望是在未來(lái)Kinect能夠完整的整合進(jìn)WPF。在WPF4.0中，觸控設(shè)備作為一個(gè)單獨(dú)的模塊。最開(kāi)始觸控設(shè)備被作為微軟的Surface引入。Surface SDK包括一系列的WPF控件，諸如SurfaceButton，SurfaceCheckBox，和SurfaceListBox。如果你想按鈕能夠響應(yīng)觸摸事件，最好使用SurfaceButton控件。

能夠想象到，如果Kinect被完整的整合進(jìn)WPF，可能會(huì)有一個(gè)稱之為SkeletonDevice的類。他和Kinect SDK中的SkeletonFrame對(duì)象類似。每一個(gè)Skeleton對(duì)象會(huì)有一個(gè)稱之為GetJointPoint的方法，他和MouseDevice的GetPositon和TouchDevice的GetTouchPoint類似。另外，核心的可視化元素(UElement, ContentElement, FrameworkElement, FrameworkContentElement) 有能夠相應(yīng)的事件或者方法能夠通知并處理骨骼關(guān)節(jié)點(diǎn)交互。例如，可能有一個(gè)JointEnter，JointLeave，和JointHover事件。更進(jìn)一步，就像觸控類有一個(gè)ManipulationStarted和ManipulationEnded事件一樣，在Kinect輸入的時(shí)候可能伴隨GetstureStarted和GestureEnded事件。

??? 目前，Kinect SDK和WPF是完全分開(kāi)的，因此他和輸入系統(tǒng)沒(méi)有在底層進(jìn)行整合。所以作為開(kāi)發(fā)者的我們需要追蹤骨骼關(guān)節(jié)點(diǎn)位置，并判斷節(jié)點(diǎn)位置是否和UI界面上的元素有交互。當(dāng)關(guān)節(jié)點(diǎn)在對(duì)應(yīng)的UI坐標(biāo)系可視化界面的有效范圍內(nèi)時(shí)，我們必須手動(dòng)的改變這些可視化元素的外觀以響應(yīng)這種交互。

1.2 探測(cè)用戶的交互

??? 在確定用戶是否和屏幕上的某一可視化元素進(jìn)行交互之前，我們必須定義什么叫用戶和可視化元素的交互。在以鼠標(biāo)或者光標(biāo)驅(qū)動(dòng)的應(yīng)用程序中有兩種用戶交互方式。鼠標(biāo)懸停和點(diǎn)擊交互。這些將事件劃分為更精細(xì)的交互。就拿光標(biāo)懸停來(lái)說(shuō)，它必須進(jìn)行可視化組件的坐標(biāo)空間區(qū)域，當(dāng)光標(biāo)離開(kāi)這一區(qū)域，懸停交互也就結(jié)束了。在WPF中，當(dāng)用戶進(jìn)行這些操作時(shí)，會(huì)觸發(fā)MouseEnter和MouseLeave操作。

除了點(diǎn)擊和懸停外，鼠標(biāo)還有另外一種常用的交互，那就是拖放。當(dāng)光標(biāo)移動(dòng)到可視化組件上方，按下鼠標(biāo)左鍵，然后在屏幕上拖動(dòng)，我們稱之為拖動(dòng)(drag)，當(dāng)用戶松開(kāi)鼠標(biāo)左鍵時(shí)，我們之位釋放操作(drop)。鼠標(biāo)拖動(dòng)和釋放是一個(gè)比較復(fù)雜的交互，這點(diǎn)和Kinect中的手勢(shì)類似。

??? 本節(jié)我們來(lái)看一下一些簡(jiǎn)單的諸如光標(biāo)懸停，進(jìn)入，離開(kāi)可視化控件的交互。在前篇文章中的Kinect連線小游戲中，我們?cè)诶L制直線時(shí)需要判斷手是否在點(diǎn)的合適范圍內(nèi)。在那個(gè)小游戲中，應(yīng)用程序并沒(méi)有像用戶界面和人那樣直接響應(yīng)用戶界的操作。這種差別很重要。應(yīng)用程序在屏幕坐標(biāo)空間中產(chǎn)生一些點(diǎn)的位置(數(shù)字)，但是這些點(diǎn)并沒(méi)有直接從屏幕空間派生。這些點(diǎn)只是存儲(chǔ)在變量中的數(shù)據(jù)而已。我們改變屏幕大小使得很容易展現(xiàn)出來(lái)。在接收到新的骨骼數(shù)據(jù)幀之前。骨骼數(shù)據(jù)中手的位置被轉(zhuǎn)換到屏幕中點(diǎn)所在的空間坐標(biāo)系，然后我們判斷手所在的位置的點(diǎn)是否在點(diǎn)序列中。技術(shù)上來(lái)講，這個(gè)應(yīng)用程序即使沒(méi)有用戶界面也能夠正常運(yùn)行。用戶界面是動(dòng)態(tài)的由這些數(shù)據(jù)產(chǎn)生的。用戶直接和這些數(shù)據(jù)而不是和界面進(jìn)行交互。

1.2.1命中測(cè)試(Hit testing)

??? 判斷用戶的手是否在點(diǎn)的附近遠(yuǎn)沒(méi)有判斷手是否在點(diǎn)的位置上那么簡(jiǎn)單。每一個(gè)點(diǎn)只是一個(gè)象元。為了使得應(yīng)用程序能夠工作。我們并不要求手的位置敲好在這個(gè)點(diǎn)所在的象元上，而是要求在以這個(gè)點(diǎn)為中心的某一個(gè)區(qū)域范圍內(nèi)。我們?cè)邳c(diǎn)的周圍創(chuàng)建了一個(gè)圓圈代表點(diǎn)的區(qū)域范圍，用戶的手的中心必須進(jìn)入到這個(gè)點(diǎn)的區(qū)域范圍才被認(rèn)為是懸停在該點(diǎn)上。如圖所示在圓形中的白色的點(diǎn)是實(shí)際的點(diǎn)，虛線繪制的圓形是該點(diǎn)的最大可觸及范圍。手形圖標(biāo)的中心用白色的點(diǎn)表示。所以，有可能手的圖標(biāo)和點(diǎn)的最大范圍接觸了，但是手的中心卻不在該點(diǎn)的最大范圍內(nèi)。判斷手的中心是否在點(diǎn)的最大范圍之內(nèi)稱之為命中測(cè)試。

??? 在Kinect連線游戲中，用戶界面響應(yīng)數(shù)據(jù)，依據(jù)產(chǎn)生的坐標(biāo)將點(diǎn)繪制在圖像界面上，系統(tǒng)使用點(diǎn)而不是用可視化控件的有效區(qū)間來(lái)進(jìn)行命中測(cè)試。大多數(shù)的應(yīng)用程序和游戲都不是這樣做的。用戶界面通常很復(fù)雜，而且是動(dòng)態(tài)的。例如在Kinect for Windows SDK中自帶的ShapeGame應(yīng)用就是這樣一個(gè)例子，它動(dòng)態(tài)的從上至下產(chǎn)生一些形狀。當(dāng)用戶觸碰這些形狀時(shí)形狀會(huì)消失或者彈開(kāi)。

??? ShapeGame這個(gè)應(yīng)用比之前的Kinect連線游戲需要更為復(fù)雜的命中測(cè)試算法。WPF提供了一些工具來(lái)幫助我們實(shí)現(xiàn)命中測(cè)試。在System.Windows.Media命名空間下的VisualTreeHelper幫助類中有一個(gè)HitTest方法。這個(gè)方法有很多個(gè)重載，但是最基本的方法接受兩個(gè)參數(shù)，一個(gè)是可視化控件對(duì)象，另一個(gè)是待測(cè)試的點(diǎn)。他返回可視化對(duì)象樹中該點(diǎn)所命中的最頂層的那個(gè)可視化對(duì)象。聽(tīng)起來(lái)可能有點(diǎn)復(fù)雜，一個(gè)最簡(jiǎn)單的解釋是，在WPF中有一個(gè)分層的可視化輸出，有多個(gè)對(duì)象可能占據(jù)同一個(gè)相對(duì)空間，但是在不同的層。如果該點(diǎn)所在位置有多個(gè)對(duì)象，那么HitTest返回處在可視化樹中處在最頂層的可視化對(duì)象。由于WPF的樣式和模板系統(tǒng)使得一個(gè)控件能夠由一個(gè)或者多個(gè)元素或者其它控件組成，所在通常在一個(gè)點(diǎn)可能有多個(gè)可視化元素。

??? 上圖可能幫助我們理解可視元素的分層。圖中有三個(gè)元素：圓形，矩形和按鈕。所有三個(gè)元素都在Canvas容器中。圓形和按鈕在矩形之上，左邊第一幅圖中，鼠標(biāo)位于圓形之上，在這點(diǎn)上的命中測(cè)試結(jié)果將返回這個(gè)圓形。第二幅圖，即使矩形最底層，由于鼠標(biāo)位于矩形上，所以命中測(cè)試會(huì)返回矩形。這是因?yàn)榫匦卧谧畹讓?#xff0c;他是唯一個(gè)占據(jù)了鼠標(biāo)光標(biāo)象元所在位置的可視化元素。在第三幅圖中，光標(biāo)在按鈕的文字上，命中測(cè)試將返回TextBlock對(duì)象，如果鼠標(biāo)沒(méi)有位于按鈕的文字上，命中測(cè)試將會(huì)返回ButtonChrome元素。按鈕的可視化表現(xiàn)通常由一個(gè)或者多個(gè)可視化控件組成，并能夠定制。實(shí)際上，按鈕沒(méi)有繼承可視化樣式，它是一個(gè)沒(méi)有可視化表現(xiàn)的控件。上圖中的按鈕使用的是默認(rèn)樣式，它由TextBlock和ButtonChrome這兩個(gè)控件構(gòu)成的。在這個(gè)例子中，我們通常會(huì)獲得到有按鈕樣式組成的元素，但是永遠(yuǎn)獲取不到實(shí)際的按鈕控件。

??? 為了使得命中測(cè)試更為方便，WPF提供了其他的方法來(lái)協(xié)助進(jìn)行命中測(cè)試。UIElement類定義了一個(gè)InputHitTest方法，它接受一個(gè)Point對(duì)象，并返回該P(yáng)oint對(duì)象指定的一個(gè)IIputElement元素。UIElement和ContentElement兩個(gè)類都實(shí)現(xiàn)了IInputElement接口。這意味著所有的WPF用戶界面元素都實(shí)現(xiàn)了這個(gè)接口。VisualTreeHelper類中的HitTest方法可以用在一般的場(chǎng)合。

Note: MSDN中關(guān)于UIElement.InputHitTest方法的建議“應(yīng)用程序一般不需要調(diào)用該方法，只有應(yīng)用程序需要自己重新實(shí)現(xiàn)一系列已經(jīng)實(shí)現(xiàn)了的底層輸入特征，例如要重新實(shí)現(xiàn)鼠標(biāo)設(shè)備的輸入邏輯時(shí)才會(huì)去調(diào)用該方法。”由于Kinect并沒(méi)有原生的集成到WPF中，所以必須重新實(shí)現(xiàn)類似鼠標(biāo)設(shè)備的輸入邏輯。

??? WPF中，命中測(cè)試依賴于兩個(gè)變量，一個(gè)是可視化元素，另一個(gè)是點(diǎn)。測(cè)試首先該點(diǎn)轉(zhuǎn)換到可視化元素所在坐標(biāo)空間，然后確定是否處于該可視化元素的有效范圍內(nèi)。下圖可以更好的理解可視化元素的坐標(biāo)空間。WPF中的每一個(gè)可視化元素，不論其形狀和大小，都有一個(gè)外輪廓：這個(gè)輪廓是一個(gè)矩形，它包含可視化元素并定義了可視化元素的寬度和高度。布局系統(tǒng)使用這個(gè)外輪廓來(lái)確定可視化元素的整體尺寸以及如何將其排列在屏幕上。當(dāng)開(kāi)發(fā)者使用Canvas，Grid，StackPanel等容器來(lái)布局其子元素時(shí)，元素的外輪廓是這些容器控件如進(jìn)行布局計(jì)算的基礎(chǔ)。用戶看不到元素的外輪廓，下圖中，可視化元素周圍的虛線矩形顯示了這些元素的外輪廓。此外，每一個(gè)元素有一個(gè)X,Y坐標(biāo)用來(lái)指定該元素在其父容器中的位置。可以通過(guò)System.Windows.Controls.Primitives命名空間中的LayoutInformation靜態(tài)類中的GetLayoutSlot方法來(lái)獲取元素的外輪廓和其位置。舉例來(lái)說(shuō)，圖中三角形的外輪廓的左上角坐標(biāo)點(diǎn)為（0,0），三角形的寬和高都是200像素。所以在三角形外輪廓中，三角形的三個(gè)點(diǎn)的坐標(biāo)分別為(100,0),(200,200),(0,200)。并不是在三角形外輪廓中的所有點(diǎn)在命中測(cè)試中都會(huì)成功，只有在三角形內(nèi)部的點(diǎn)才會(huì)成功。點(diǎn)(0,0)不會(huì)命中，而三角形的中心(100,100)則能命中。

??? 命中測(cè)試的結(jié)果依賴于可視化元素的布局。在目前所有的項(xiàng)目中，我們使用Canvas容器來(lái)包含所有可視化元素。Canvas是一個(gè)可視化的容器，能夠使得開(kāi)發(fā)者對(duì)可視化元素的位置進(jìn)行完全控制，這一點(diǎn)在使用Kinect的時(shí)候尤其明顯。像手部跟蹤這類基本的方法也可以使用WPF中的其他容器，但是需要做很多其他工作，并且性能沒(méi)有使用Canvas好。使用Cnavas容器，用戶可以通過(guò)CanvasLeft和CanvasTop顯式設(shè)定其所有子元素的起始X,Y的位置。前面討論的坐標(biāo)空間轉(zhuǎn)換使用Cnavas作為容器，因?yàn)椴恍枰嗟奶幚聿僮?#xff0c;轉(zhuǎn)換也非常明了，只需要少量的代碼就可以實(shí)現(xiàn)較好的性能。

??? 使用Canvas作為容器的缺點(diǎn)也是其的優(yōu)點(diǎn)。由于開(kāi)發(fā)者可以完全控制在Canvas中子元素的位置，所以當(dāng)窗體大小發(fā)生改變或者有比較復(fù)雜的布局時(shí)，也需要開(kāi)發(fā)者去更新這些可視化元素的位置。而另外一些容器控件，如Grid，StackPanel則會(huì)幫助我們實(shí)現(xiàn)這些更新操作。但是，這些容器控件增加了可視化樹的結(jié)構(gòu)和坐標(biāo)空間，從而增加了命中測(cè)試的復(fù)雜度。坐標(biāo)空間越多，需要的點(diǎn)的轉(zhuǎn)換就越多。這些容器還有alignment屬性（水平和垂直）和相對(duì)于FrameworkElement的margin屬性，進(jìn)一步增加了命中測(cè)試的計(jì)算復(fù)雜度。如果可是化元素有RenderTransforms方法的話，我們可以直接使用這些方法而不用去自己寫命中測(cè)試的算法了。

?? 一個(gè)折中的方法是，將那些基于骨骼節(jié)點(diǎn)位置的需要頻繁變化的可視化元素，如手形圖標(biāo)放在Canvas容器內(nèi)，而將其他UI元素放在其他容器控件內(nèi)。這種布局模式需要多個(gè)坐標(biāo)空間轉(zhuǎn)換，會(huì)影響程序性能，并且在進(jìn)行坐標(biāo)空間轉(zhuǎn)換計(jì)算時(shí)可能會(huì)引入一些bug。這種混合的布局方案在大多數(shù)情況下是最好的選擇，它充分利用了WPF布局系統(tǒng)的優(yōu)點(diǎn)。要詳細(xì)了解各種容器及其命中測(cè)試的相關(guān)概念，可以參閱MSDN中WPF的布局系統(tǒng)。

1.2.2響應(yīng)輸入

??? 命中測(cè)試只能告訴當(dāng)前用戶輸入點(diǎn)是否在可視化元素的有效區(qū)間內(nèi)。用戶界面最重要的一個(gè)功能是要給予用戶一些對(duì)輸入操作的反饋。當(dāng)鼠標(biāo)移到一個(gè)按鈕上時(shí)，我們期望按鈕能夠改變其外觀，告訴我們這個(gè)按鈕是可以點(diǎn)擊的。如果沒(méi)有這種反饋，用戶不僅用戶體驗(yàn)不好，而且還會(huì)使用戶感到迷惑。有時(shí)候即使功能完備，用戶體驗(yàn)失敗意味著應(yīng)用的失敗。

??? WPF有一套功能強(qiáng)大的系統(tǒng)來(lái)通知和響應(yīng)用戶的輸入。只要用戶的輸入設(shè)備是鼠標(biāo)，手寫筆，觸摸板這些標(biāo)準(zhǔn)設(shè)備，WPF的樣式和模版系統(tǒng)使得開(kāi)發(fā)出能夠響應(yīng)用戶輸入的高度的定制化的用戶界面非常容易。而Kinect的開(kāi)發(fā)者有兩種選擇：不使用WPF系統(tǒng)提供的功能，手動(dòng)實(shí)現(xiàn)所有功能，或者創(chuàng)建一個(gè)通用的控件來(lái)響應(yīng)Kinect輸入。第二種方法雖然不是特別難，但是初學(xué)者也不太容易能夠?qū)崿F(xiàn)。

??? 了解了這一點(diǎn)，在下面的章節(jié)中，我們將會(huì)開(kāi)發(fā)一個(gè)游戲來(lái)使用命中測(cè)試并手動(dòng)響應(yīng)用戶的輸入。在開(kāi)始之前，思考一個(gè)問(wèn)題，到目前位置，還有那些問(wèn)題沒(méi)有很好解決？使用Kinect骨骼數(shù)據(jù)和用戶界面進(jìn)行交互是什么意思？核心的鼠標(biāo)交互有：進(jìn)入，離開(kāi)和點(diǎn)擊。觸摸輸入交互有進(jìn)入，離開(kāi)，按下，彈起。鼠標(biāo)只有一個(gè)觸控點(diǎn)，觸摸版可以有多個(gè)觸控點(diǎn)，但是只有一個(gè)是主觸控點(diǎn)。Kinect骨骼節(jié)點(diǎn)數(shù)據(jù)有20個(gè)可能的數(shù)據(jù)點(diǎn)，哪一個(gè)點(diǎn)是主觸控點(diǎn)？應(yīng)該有一個(gè)主控點(diǎn)嗎？一個(gè)可視化元素，比如說(shuō)按鈕，會(huì)在任何一個(gè)關(guān)節(jié)點(diǎn)數(shù)據(jù)到達(dá)按鈕的有效范圍內(nèi)觸發(fā)，還是只是特定的關(guān)節(jié)點(diǎn)數(shù)，比如手，進(jìn)入范圍后才能觸發(fā)？

??? 沒(méi)有一個(gè)回答能夠完全回答好上面的問(wèn)題。這取決于應(yīng)用程序界面的設(shè)計(jì)及要實(shí)現(xiàn)的功能。這些問(wèn)題其實(shí)是自然交互界面設(shè)計(jì)中的一部分典型問(wèn)題。在后面我們會(huì)介紹。對(duì)于大多數(shù)Kinect應(yīng)用程序，包括本文中的例子，只允許手部關(guān)節(jié)點(diǎn)數(shù)據(jù)才能和用戶界面進(jìn)行交互。最開(kāi)始的交互是進(jìn)入和離開(kāi)。除此之外的交互可能會(huì)很復(fù)雜。在后面我們將介紹這些復(fù)雜的交互，現(xiàn)在讓我們來(lái)看看最基本的交互。

?

2.? “我說(shuō)你做”游戲

?? 為了演示如何將Kinect作為一個(gè)輸入設(shè)備，我們開(kāi)始開(kāi)發(fā)我們的項(xiàng)目：該項(xiàng)目使用手部關(guān)節(jié)點(diǎn)數(shù)據(jù)模仿鼠標(biāo)或者觸控板和用戶界面進(jìn)行交互。這個(gè)項(xiàng)目的目標(biāo)是展示如何進(jìn)行命中測(cè)試和使用WPF可視化元素來(lái)創(chuàng)建用戶界面。項(xiàng)目是一個(gè)稱之為“我說(shuō)你做”(Simon Say)的小游戲。

?? “我說(shuō)你做”（Simon says）是一個(gè)英國(guó)傳統(tǒng)的兒童游戲。一般由3個(gè)或更多的人參加。其中一個(gè)人充當(dāng)"Simon"。其他人必須根據(jù)情況對(duì)充當(dāng)"Simon"的人宣布的命令做出不同反應(yīng)。如果充當(dāng)"Simon"的人以"Simon says"開(kāi)頭來(lái)宣布命令，則其他人必須按照命令做出相應(yīng)動(dòng)作。如：充當(dāng)"Simon"的人說(shuō)："Simon says jump（跳）"。其他人就必須馬上跳起；而如果充當(dāng)"Simon"的人沒(méi)有說(shuō)"Simon says"而直接宣布命令，如：充當(dāng)"Simon"的人說(shuō)"jump"。則其他人不準(zhǔn)有動(dòng)作，如果有動(dòng)作則做動(dòng)作的人被淘汰出游戲。

??? 在70年代末80年代初有一個(gè)叫Milton Bradley的游戲公司開(kāi)發(fā)了一個(gè)電子版的Simon say游戲。該游戲界面由4個(gè)不同顏色 (紅色，藍(lán)色，綠色，黃色) 的按鈕組成，這個(gè)游戲在電腦上運(yùn)行，讓游戲者按演示的順序按下這些按鈕。當(dāng)開(kāi)始游戲時(shí)，程序首先按照一定的順序亮起每一個(gè)按鈕，游戲者必須按照這個(gè)亮燈的順序依次按下這些按鈕。如果游戲者操作正確，那么下一個(gè)亮燈序列又開(kāi)始，到后面變化會(huì)越來(lái)越快，直到游戲者不能夠按照給定的順序按下這些按鈕位置。

我們要做的是，使用Kinect設(shè)備來(lái)實(shí)現(xiàn)這么一個(gè)Simon Say游戲。這是個(gè)很好的使用Kinect展示如何和用戶界面進(jìn)行交互的例子。這個(gè)游戲也有一些規(guī)則。下圖展示了我們將要做的用戶界面，他包含四個(gè)矩形，他用來(lái)模擬游戲中的按鈕。界面上方是游戲標(biāo)題，中間是游戲的操作指南。

??? 這個(gè)Kinect版的Simon says游戲追蹤游戲者的手部關(guān)節(jié)。當(dāng)用戶的手碰到了這四個(gè)填充了顏色的方框中的任何一個(gè)時(shí)，程序認(rèn)為游戲者按下了一個(gè)按鈕。在Kinect應(yīng)用程序中，使用懸停或者點(diǎn)擊來(lái)和按鈕進(jìn)行交互很常見(jiàn)。現(xiàn)在，我們的游戲操作指南還很簡(jiǎn)單。游戲一開(kāi)始，我們提示用戶將手放在界面上紅色矩形中手勢(shì)圖標(biāo)所在的位置。在用戶將雙手放到指定位置后，界面開(kāi)始發(fā)出指令。如果游戲者不能夠重復(fù)這個(gè)過(guò)程，游戲?qū)?huì)結(jié)束，并返回到這個(gè)狀態(tài)。現(xiàn)在，我們對(duì)這個(gè)游戲的概念，規(guī)則和樣子有了一些了解，現(xiàn)在開(kāi)始編碼。

2.1 Simon say “設(shè)計(jì)一個(gè)用戶界面”

??? 首先來(lái)設(shè)計(jì)一個(gè)用戶界面，下面的代碼展示的主界面中的XAML和之前的連線游戲一樣，我們將所有的主界面的UI元素包含在Viewbox容器中，讓他來(lái)幫助我們進(jìn)行不同顯示器分辨率下面的縮放操作。主UI界面分辨率設(shè)置為1920*1080。UI界面共分為4個(gè)部分：標(biāo)題及游戲指導(dǎo)，游戲界面，游戲開(kāi)始界面以及用來(lái)追蹤手部的手形圖標(biāo)。第一個(gè)TextBlock用來(lái)顯示標(biāo)題，游戲引導(dǎo)放在接下來(lái)的StackPanel元素中。這些元素是用來(lái)給游戲者提供當(dāng)前游戲狀態(tài)。他們沒(méi)有功能性的作用，和Kinect或者骨骼追蹤沒(méi)有關(guān)系。

??? GameCanvas，ControlCanvas和HandCanvas包含了所有的和Kienct相關(guān)的UI元素，這些元素是基于當(dāng)前用戶手的位置和用戶界面進(jìn)行交互的。手的位置來(lái)自骨骼追蹤。HandCanvas應(yīng)該比較熟悉，程序中有兩個(gè)手形圖標(biāo)，用來(lái)追蹤游戲者兩只手的運(yùn)動(dòng)。ControlCanvas存儲(chǔ)的UI元素用來(lái)觸發(fā)開(kāi)始游戲。GameCanvas用來(lái)存儲(chǔ)這4個(gè)矩形，在游戲中，用戶需要點(diǎn)擊這些矩形。不同的交互元素存儲(chǔ)在不同的容器中，使得用戶界面能夠比較容易使用代碼進(jìn)行控制。比如，當(dāng)用戶開(kāi)始游戲后，我們需要隱藏所有的ControlCanvas容器內(nèi)的子元素，顯然隱藏這個(gè)容器比隱藏其每個(gè)子控件容易的多。整個(gè)UI代碼如下：

2.2 Simon say “構(gòu)建程序的基礎(chǔ)結(jié)構(gòu)”

???? UI界面設(shè)計(jì)好了之后，我們現(xiàn)在來(lái)看游戲的基礎(chǔ)結(jié)構(gòu)。需要在代碼中添加響應(yīng)SkeletonFrameReady事件的邏輯。在SkeletonFrameReady事件中，添加代碼來(lái)跟蹤游戲者手部關(guān)節(jié)的運(yùn)動(dòng)。基本代碼如下：

private void KinectDevice_SkeletonFrameReady(object sender, SkeletonFrameReadyEventArgs e) {using (SkeletonFrame frame = e.OpenSkeletonFrame()){if (frame != null){frame.CopySkeletonDataTo(this.frameSkeletons);Skeleton skeleton = GetPrimarySkeleton(this.frameSkeletons);if (skeleton == null){ChangePhase(GamePhase.GameOver);}else{LeftHandElement.Visibility = Visibility.Collapsed;RightHandElement.Visibility = Visibility.Collapsed;}}} }private static Skeleton GetPrimarySkeleton(Skeleton[] skeletons) {Skeleton skeleton = null;if (skeletons != null){//Find the closest skeleton for (int i = 0; i < skeletons.Length; i++){if (skeletons[i].TrackingState == SkeletonTrackingState.Tracked){if (skeleton == null){skeleton = skeletons[i];}else{if (skeleton.Position.Z > skeletons[i].Position.Z){skeleton = skeletons[i];}}}}}return skeleton; }

??? 上面代碼中TrackHand和GetJointPoint代碼和Kinect連線游戲中相同。對(duì)于大多數(shù)游戲來(lái)說(shuō)，使用“拉模型”來(lái)獲取數(shù)據(jù)比使用事件模型獲取數(shù)據(jù)性能要好。游戲通常是一個(gè)循環(huán)，可以手動(dòng)的從骨骼數(shù)據(jù)流中獲取下一幀骨骼數(shù)據(jù)。但是在我們的例子中，仍然使用的是事件模型，為的是能夠減少代碼量和復(fù)雜度。

2.3 Simon say “添加游戲基本元素”

??? Simon say游戲分成三步。起始步驟，我們之為GameOver，意味著當(dāng)前沒(méi)有可以玩的游戲。這是游戲的默認(rèn)狀態(tài)。這也是當(dāng)Kinect探測(cè)不到游戲者時(shí)所切換到的狀態(tài)。然后游戲開(kāi)始循環(huán)，Simon給出一些指令，然后游戲者重復(fù)執(zhí)行這些指令，重復(fù)這一過(guò)程，直到用戶沒(méi)能夠正確的執(zhí)行Simon給出的指令為止。應(yīng)用程序定義了一個(gè)枚舉變量來(lái)描述游戲所有可能的狀態(tài)，以及定義了一個(gè)變量來(lái)跟蹤游戲這當(dāng)前所執(zhí)行了的指令位置。另外我們需要一個(gè)變量來(lái)描述游戲者成功的次數(shù)或者游戲等級(jí)。當(dāng)游戲者成功的執(zhí)行了Simon給出的指令后，這個(gè)變量加1。下面的代碼展示了這個(gè)枚舉以及變量，變量的初始化在類的夠著函數(shù)中執(zhí)行。

public enum GamePhase {GameOver = 0,SimonInstructing = 1,PlayerPerforming = 2 }public MainWindow() {InitializeComponent();KinectSensor.KinectSensors.StatusChanged += KinectSensors_StatusChanged;this.KinectDevice = KinectSensor.KinectSensors.FirstOrDefault(x => x.Status == KinectStatus.Connected);ChangePhase(GamePhase.GameOver);this.currentLevel = 0; }

??? SkeletonFrameReady事件需要根據(jù)當(dāng)前游戲所處的狀態(tài)來(lái)執(zhí)行不同的操作。下面的代碼中根據(jù)當(dāng)前游戲的狀態(tài)執(zhí)行ChangePhase，ProcessGameOver和ProcessPlayerPerforming子方法。這些方法的詳細(xì)執(zhí)行過(guò)程將在后面介紹。ChangePhase方法接受一個(gè)GamePhase枚舉值，后兩個(gè)方法接受一個(gè)Skeleton類型的參數(shù)。

??? 當(dāng)應(yīng)用程序探測(cè)不到骨骼數(shù)據(jù)時(shí)，游戲會(huì)終止，并切換到Game Over階段。當(dāng)游戲者離開(kāi)Kinect視野時(shí)會(huì)發(fā)生這種情況。當(dāng)游戲處在Simon給出操作步驟階段時(shí)，隱藏界面上的手勢(shì)圖標(biāo)。否則，更新這兩個(gè)圖標(biāo)的位置。當(dāng)游戲處在其它狀態(tài)時(shí)，程序基于當(dāng)前特定的游戲階段調(diào)用特定的處理方法。

private void KinectDevice_SkeletonFrameReady(object sender, SkeletonFrameReadyEventArgs e) {using (SkeletonFrame frame = e.OpenSkeletonFrame()){if (frame != null){frame.CopySkeletonDataTo(this.frameSkeletons);Skeleton skeleton = GetPrimarySkeleton(this.frameSkeletons);if (skeleton == null){ChangePhase(GamePhase.GameOver);}else{if (this.currentPhase == GamePhase.SimonInstructing){LeftHandElement.Visibility = Visibility.Collapsed;RightHandElement.Visibility = Visibility.Collapsed;}else{TrackHand(skeleton.Joints[JointType.HandLeft], LeftHandElement, LayoutRoot);TrackHand(skeleton.Joints[JointType.HandRight], RightHandElement, LayoutRoot);switch (this.currentPhase){case GamePhase.GameOver:ProcessGameOver(skeleton);break;case GamePhase.PlayerPerforming:ProcessPlayerPerforming(skeleton);break;}}}}} }

2.4 開(kāi)始新游戲

??? 當(dāng)游戲處在GameOver階段時(shí)，應(yīng)用程序只調(diào)用了一個(gè)方法：該方法判斷用戶是否想玩游戲。當(dāng)用戶將相應(yīng)的手放在UI界面上手勢(shì)所處的位置時(shí)，游戲開(kāi)始。左右手需要分別放在LeftHandStartElement和RightHandStartElement所處的位置內(nèi)。在這個(gè)例子中，我們使用WPF自帶的命中測(cè)試功能。我們的UI界面很小也很簡(jiǎn)單。InputHitTest操作所需要處理的UI元素很少，因此性能上沒(méi)有太大問(wèn)題。下面的代碼展示了ProcessGameOver方法和GetHitTarget方法。

private void ProcessGameOver(Skeleton skeleton) {//判斷用戶是否想開(kāi)始新的游戲if (HitTest(skeleton.Joints[JointType.HandLeft], LeftHandStartElement) && HitTest(skeleton.Joints[JointType.HandRight], RightHandStartElement)){ChangePhase(GamePhase.SimonInstructing);} }private bool HitTest(Joint joint, UIElement target) {return (GetHitTarget(joint, target) != null); }private IInputElement GetHitTarget(Joint joint, UIElement target) {Point targetPoint = LayoutRoot.TranslatePoint(GetJointPoint(this.KinectDevice, joint, LayoutRoot.RenderSize, new Point()), target);return target.InputHitTest(targetPoint); }

??? ProcessGameOver方法的邏輯簡(jiǎn)單明了：如果游戲者的任何一只手在UI界面上的對(duì)應(yīng)位置，就切換當(dāng)前游戲所處的狀態(tài)。GetHitTarget方法用來(lái)測(cè)試給定的關(guān)節(jié)點(diǎn)是否在可視化控件有效范圍內(nèi)。他接受關(guān)節(jié)點(diǎn)數(shù)據(jù)和可視化控件，返回該點(diǎn)所在的特定的IInputElement對(duì)象。雖然代碼只有兩行，但是了解背后的邏輯很重要。

????? 命中測(cè)試算法包含三個(gè)步驟，首先需要將關(guān)節(jié)點(diǎn)所在的骨骼空間坐標(biāo)系中坐標(biāo)轉(zhuǎn)換到對(duì)應(yīng)的LayoutRoot元素所在的空間坐標(biāo)中來(lái)。GetJointPoint實(shí)現(xiàn)了這個(gè)功能。其次，使用UIElement類中的TranslatePoint方法將關(guān)節(jié)點(diǎn)從LayoutRoot元素所在的空間坐標(biāo)轉(zhuǎn)換到目標(biāo)元素所在的空間坐標(biāo)中。最后，點(diǎn)和目標(biāo)元素在一個(gè)坐標(biāo)空間之后，調(diào)用目標(biāo)元素的InputHitTest方法，方法返回目標(biāo)對(duì)象樹中，點(diǎn)所在的確切的UI元素，任何非空值都表示命中測(cè)試成功。

??? 注意到邏輯之所以這么簡(jiǎn)單是因?yàn)槲覀儾捎玫腢I布局方式，應(yīng)用程序假定全屏運(yùn)行并且不能調(diào)整大小。將UI界面設(shè)置為靜態(tài)的，確定大小能夠極大的簡(jiǎn)化計(jì)算量。另外，將所有的可交互的UI元素放在Canvas容器內(nèi)使得我們只有一個(gè)坐標(biāo)空間。使用其他容器空間來(lái)包含元素或者使用諸如HorizonAlignment，VerticalAlignment或者M(jìn)argin這些自動(dòng)布局屬性會(huì)增加命中測(cè)試的復(fù)雜性。簡(jiǎn)言之，越是復(fù)雜的UI布局，命中測(cè)試的邏輯越復(fù)雜，也越會(huì)影響程序的性能。

?

2.4.1 更改游戲狀態(tài)

??? 編譯并運(yùn)行程序，如果沒(méi)問(wèn)題的話，結(jié)果應(yīng)該如下圖。應(yīng)用程序能夠追蹤手部的運(yùn)動(dòng)，并且當(dāng)用戶將手放到對(duì)應(yīng)的位置后，應(yīng)用程序的狀態(tài)會(huì)從GameOver轉(zhuǎn)到SimonInstructing狀態(tài)。下一步是要實(shí)現(xiàn)ChangePhase方法，代碼如下：

private void ChangePhase(GamePhase newPhase) {if (newPhase != this.currentPhase){this.currentPhase = newPhase;switch (this.currentPhase){case GamePhase.GameOver:this.currentLevel = 0;RedBlock.Opacity = 0.2;BlueBlock.Opacity = 0.2;GreenBlock.Opacity = 0.2;YellowBlock.Opacity = 0.2;GameStateElement.Text = "GAME OVER!";ControlCanvas.Visibility = Visibility.Visible;GameInstructionsElement.Text = "將手放在對(duì)象上開(kāi)始新的游戲。";break;case GamePhase.SimonInstructing:this.currentLevel++;GameStateElement.Text = string.Format("Level {0}", this.currentLevel);ControlCanvas.Visibility = Visibility.Collapsed;GameInstructionsElement.Text = "注意觀察Simon的指示。";GenerateInstructions();DisplayInstructions();break;case GamePhase.PlayerPerforming:this.instructionPosition = 0;GameInstructionsElement.Text = "請(qǐng)重復(fù) Simon的指示";break;}} }

??? 上面的代碼和Kinect無(wú)關(guān)，事實(shí)上可以使用鼠標(biāo)或者觸控板來(lái)實(shí)現(xiàn)這一步，但是這段代碼是必須的。ChangePhase方法用來(lái)控制UI界面來(lái)顯示當(dāng)前游戲狀態(tài)的變化，維護(hù)一些游戲進(jìn)行所需要的數(shù)據(jù)。在GameOver狀態(tài)時(shí)，矩形框會(huì)漸變消失，然后改變操作指示，顯示按鈕來(lái)開(kāi)始一個(gè)新的游戲。SimonInStructing狀態(tài)不在更新UI界面討論范圍內(nèi)，他調(diào)用了兩個(gè)方法，用來(lái)產(chǎn)生指令集合 (GenerateInstructions)，并將這些指令顯示到UI界面上(DisplayInstructions)，代碼中也定義了instructionPosition變量，來(lái)維護(hù)當(dāng)前所完成的指令步驟。

2.4.2 顯示Simon的指令

??? 下面的代碼顯示了一些局部變量和GenerateInstructions方法。instructionSequence變量用來(lái)存儲(chǔ)一系列的UIElements對(duì)象，這些對(duì)象組成了Simon的指令集合。游戲者必須用手依次移動(dòng)到這些指令上。這些指令的順序是隨機(jī)設(shè)定的。每一關(guān)指令的個(gè)數(shù)和當(dāng)前等級(jí)是一樣的。比如，到了第五關(guān)，就有5個(gè)指令。代碼也顯示了DisplayInstruction方法，他創(chuàng)建并觸發(fā)了一個(gè)故事板動(dòng)畫效果來(lái)根據(jù)指令的順序來(lái)改變每一個(gè)矩形的透明度。

private UIElement[] instructionSequence; private int instructionPosition; private int currentLevel; private Random rnd = new Random();

private void GenerateInstructions() {this.instructionSequence = new UIElement[this.currentLevel];for (int i = 0; i < this.currentLevel; i++){switch (rnd.Next(1, 4)){case 1:this.instructionSequence[i] = RedBlock;break;case 2:this.instructionSequence[i] = BlueBlock;break;case 3:this.instructionSequence[i] = GreenBlock;break;case 4:this.instructionSequence[i] = YellowBlock;break;}} }private void DisplayInstructions() {Storyboard instructionsSequence = new Storyboard();DoubleAnimationUsingKeyFrames animation;for (int i = 0; i < this.instructionSequence.Length; i++){this.instructionSequence[i].ApplyAnimationClock(FrameworkElement.OpacityProperty, null);animation = new DoubleAnimationUsingKeyFrames();animation.FillBehavior = FillBehavior.Stop;animation.BeginTime = TimeSpan.FromMilliseconds(i * 1500);Storyboard.SetTarget(animation, this.instructionSequence[i]);Storyboard.SetTargetProperty(animation, new PropertyPath("Opacity"));instructionsSequence.Children.Add(animation);animation.KeyFrames.Add(new EasingDoubleKeyFrame(0.3, KeyTime.FromTimeSpan(TimeSpan.Zero)));animation.KeyFrames.Add(new EasingDoubleKeyFrame(1, KeyTime.FromTimeSpan(TimeSpan.FromMilliseconds(500))));animation.KeyFrames.Add(new EasingDoubleKeyFrame(1, KeyTime.FromTimeSpan(TimeSpan.FromMilliseconds(1000))));animation.KeyFrames.Add(new EasingDoubleKeyFrame(0.3, KeyTime.FromTimeSpan(TimeSpan.FromMilliseconds(1300))));}instructionsSequence.Completed += (s, e) => { ChangePhase(GamePhase.PlayerPerforming); };instructionsSequence.Begin(LayoutRoot); }

??? 運(yùn)行程序，當(dāng)雙手放到指定位置是，Simon游戲開(kāi)始。

2.4.3 執(zhí)行Simon的指令

??? 游戲的最后一步就是根據(jù)指令來(lái)捕捉用戶的動(dòng)作。注意到當(dāng)故事版動(dòng)畫完成了顯示Simon的指令后，程序調(diào)用ChangePhase方法使游戲進(jìn)入PlayerPerforming階段。當(dāng)在PlayerPerforming階段時(shí)，應(yīng)用程序執(zhí)行ProcessPlayerPerforming方法。表面上，實(shí)現(xiàn)該方法很簡(jiǎn)單。邏輯是游戲者重復(fù)Simon給出的操作步驟，將手放在對(duì)應(yīng)矩形上方。這和之前做的命中測(cè)試邏輯是一樣的。但是，和測(cè)試兩個(gè)靜態(tài)的UI對(duì)象不同，我們測(cè)試指令集合中的下一個(gè)指令對(duì)應(yīng)的元素。下面的代碼展示的ProcessPlayerPerforming方法，編譯并運(yùn)行就可以看到效果了，雖然能夠運(yùn)行，但是它對(duì)用戶非常不友好。實(shí)際上，這個(gè)游戲不能玩。我們的用戶界面不完整。

private void ProcessPlayerPerforming(Skeleton skeleton) {//Determine if user is hitting a target and if that target is in the correct sequence.UIElement correctTarget = this._InstructionSequence[this._InstructionPosition];IInputElement leftTarget = GetHitTarget(skeleton.Joints[JointType.HandLeft], GameCanvas);IInputElement rightTarget = GetHitTarget(skeleton.Joints[JointType.HandRight], GameCanvas);if(leftTarget != null && rightTarget != null){ChangePhase(GamePhase.GameOver);}else if(leftTarget == null && rightTarget == null){//Do nothing - target found}else if((leftTarget == correctTarget && rightTarget == null) ||(rightTarget == correctTarget && leftTarget == null)){ this._InstructionPosition++;if(this._InstructionPosition >= this._InstructionSequence.Length){ChangePhase(GamePhase.SimonInstructing);}}else{ ChangePhase(GamePhase.GameOver);} }

??? 上面的代碼中，第一行獲取目標(biāo)對(duì)象元素，即指令序列中的當(dāng)前指令。然后執(zhí)行命中測(cè)試，獲取左右手對(duì)應(yīng)的命中元素。下面的代碼對(duì)這三個(gè)變量進(jìn)行操作。如果兩只手都在UI元素上，游戲結(jié)束。我們的游戲很簡(jiǎn)單，只能允許一次點(diǎn)擊一個(gè)矩形。當(dāng)兩只手都不在UI元素上時(shí)，什么都不做。如果一只手命中了期望的對(duì)象，我們就把當(dāng)前指令步驟加1。當(dāng)指令集合中還有其他指令時(shí)游戲繼續(xù)運(yùn)行，直到完成了指令集合中的最后一個(gè)指令。當(dāng)完成了最后一個(gè)指令后，游戲狀態(tài)又變?yōu)榱薙imonInstruction狀態(tài)，然后將游戲者帶入下一輪游戲。直到游戲者不能重復(fù)Simon指令而進(jìn)入GameOver狀態(tài)。

??? 如果游戲者動(dòng)作夠快，那么上面代碼工作正常，因?yàn)橹灰脩羰诌M(jìn)入到了可視化元素有效區(qū)域，那么指令位置就會(huì)自增，游戲者在進(jìn)入到下一個(gè)指令之前，沒(méi)有時(shí)間來(lái)從UI元素所在的空間上移除手。這么快的速度不可能使得游戲者能夠闖過(guò)第二關(guān)。當(dāng)游戲者成功的闖過(guò)第二關(guān)的指令后，游戲就會(huì)突然停止。

??? 解決這個(gè)問(wèn)題的辦法是在進(jìn)入到下一個(gè)指令前等待，直到游戲者的手勢(shì)從UI界面上清除。這使得游戲者有機(jī)會(huì)能夠調(diào)整手勢(shì)的位置開(kāi)始進(jìn)入下一條指令，我們需要記錄用戶的手什么時(shí)候進(jìn)入和離開(kāi)UI對(duì)象。

??? 在WPF中，每一個(gè)UIElement對(duì)象都會(huì)在鼠標(biāo)進(jìn)入和離開(kāi)其有效范圍內(nèi)時(shí)觸發(fā)MouseEnter和MouseLeave事件。不幸的是，如前面所討論的，WPF本身并不支持Kinect產(chǎn)生的關(guān)節(jié)點(diǎn)數(shù)據(jù)和UI的直接交互，如果當(dāng)關(guān)節(jié)點(diǎn)進(jìn)入或者離開(kāi)可視化元素時(shí)能夠觸發(fā)諸如JointEnter和JointLeave事件，那么就簡(jiǎn)單多了。既然不支持，那么我們只有自己手動(dòng)實(shí)現(xiàn)這個(gè)邏輯了。要實(shí)現(xiàn)一個(gè)可重用，優(yōu)雅，并能像鼠標(biāo)那樣能夠在底層追蹤關(guān)節(jié)點(diǎn)運(yùn)動(dòng)這樣的控件不太容易并且不容易做成通用的。我們只針對(duì)我們當(dāng)前遇到的問(wèn)題來(lái)實(shí)現(xiàn)這個(gè)功能。

??? 要修正游戲中的這個(gè)問(wèn)題比較容易。我們添加一系列成員變量來(lái)保存UI元素上的哪一個(gè)鼠標(biāo)手勢(shì)最后懸停在上面。當(dāng)用戶的手經(jīng)過(guò)UI元素的上方時(shí)，更新這個(gè)變量。對(duì)于每一個(gè)新的骨骼數(shù)據(jù)幀。我們檢查游戲者手的位置，如果它離開(kāi)了UI元素空間，那么我們處理這個(gè)UI元素。下面的代碼展示了對(duì)上面ProcessPlayerPerforming方法的改進(jìn)。改進(jìn)的部分用粗體表示。

private IInputElement leftHandTarget; private IInputElement rightHandTarget; private void ProcessPlayerPerforming(Skeleton skeleton) {//判斷用戶是否手勢(shì)是否在目標(biāo)對(duì)象上面，且在指定中的正確順序UIElement correctTarget = this.instructionSequence[this.instructionPosition];IInputElement leftTarget = GetHitTarget(skeleton.Joints[JointType.HandLeft], GameCanvas);IInputElement rightTarget = GetHitTarget(skeleton.Joints[JointType.HandRight], GameCanvas);bool hasTargetChange = (leftTarget != this.leftHandTarget) || (rightTarget != this.rightHandTarget);if (hasTargetChange){if (leftTarget != null && rightTarget != null){ChangePhase(GamePhase.GameOver);}else if ((leftHandTarget == correctTarget && rightHandTarget == null) ||(rightHandTarget == correctTarget && leftHandTarget == null)){this.instructionPosition++;if (this.instructionPosition >= this.instructionSequence.Length){ChangePhase(GamePhase.SimonInstructing);}}else if (leftTarget != null || rightTarget != null){//Do nothing - target found}else{ChangePhase(GamePhase.GameOver);} if (leftTarget != this.leftHandTarget){if (this.leftHandTarget != null){((FrameworkElement)this.leftHandTarget).Opacity = 0.2;}if (leftTarget != null){((FrameworkElement)leftTarget).Opacity = 1;}this.leftHandTarget = leftTarget;}if (rightTarget != this.rightHandTarget){if (this.rightHandTarget != null){((FrameworkElement)this.rightHandTarget).Opacity = 0.2;}if (rightTarget != null){((FrameworkElement)rightTarget).Opacity = 1;}this.rightHandTarget = rightTarget;}} }

??? 現(xiàn)在運(yùn)行代碼，由于游戲需要兩只手進(jìn)行操作，所以沒(méi)法截圖，讀者可以自己下載代碼運(yùn)行。

2.5 需要改進(jìn)的地方

??? 這個(gè)游戲演示了如何建立一個(gè)基于Kinect進(jìn)行交互的程序，雖然程序可以運(yùn)行，但是仍然有一些有待改進(jìn)的地方，有以下三個(gè)方面可以進(jìn)行改進(jìn)：用戶體驗(yàn)，游戲內(nèi)容和表現(xiàn)形式。

2.5.1 用戶體驗(yàn)

??? 基于Kinect的應(yīng)用程序和游戲比較新穎，在這種應(yīng)用達(dá)到成熟前，要想獲得良好的用戶體驗(yàn)需要進(jìn)行很多實(shí)驗(yàn)和測(cè)試。我們的Simon Say游戲的用戶界面就有很多值得改進(jìn)的地方。Simon Say的游戲者可能會(huì)意外的觸摸到游戲的區(qū)間。游戲時(shí)在游戲開(kāi)始的時(shí)候，有可能會(huì)碰到開(kāi)始按鈕。一旦兩只手都在指定的區(qū)間，游戲就開(kāi)始產(chǎn)生指令，如果用戶沒(méi)有及時(shí)的放開(kāi)手，他可能會(huì)無(wú)意識(shí)的碰到一個(gè)游戲?qū)ο蟆Ｒ粋€(gè)有效的解決方法是在產(chǎn)生指令之前，給予用戶一定的時(shí)間讓其重新設(shè)置手的位置。因?yàn)槿藗儠?huì)自然而然的將手垂在身體兩邊。一個(gè)比較好的變通方法是簡(jiǎn)單的給一個(gè)倒計(jì)時(shí)。在不同的關(guān)卡間，也可以給這樣一個(gè)時(shí)間間隔。在開(kāi)始新的一關(guān)時(shí)，用戶應(yīng)該有時(shí)間來(lái)從可視化元素中移開(kāi)手。

2.5.2 游戲內(nèi)容

??? 產(chǎn)生游戲指令序列的邏輯比較簡(jiǎn)單。指令序列中指令的數(shù)目和當(dāng)前的關(guān)卡是一致的。每一條指令所選擇的可視化元素是隨機(jī)選擇的。在原始的Simon Say游戲中，新一輪的游戲通常會(huì)添加一些新的指令。例如，第一關(guān)中有紅的，第二關(guān)中有紅的和藍(lán)的，第三關(guān)增加了綠的。因此在第三關(guān)指令可以是，紅綠藍(lán)。另一種改進(jìn)可以不在每一關(guān)增加一個(gè)指令。而是將指令的個(gè)數(shù)設(shè)置為當(dāng)前關(guān)卡數(shù)的2倍。軟件開(kāi)發(fā)一個(gè)有趣的地方就是應(yīng)用程序可以有多種產(chǎn)生指令序列的算法。例如，應(yīng)用程序可以分為容易，中等，難三種產(chǎn)生指令序列的方法供用戶選擇。最基本的產(chǎn)生指令序列的邏輯就是每一關(guān)要盡可能的比前一關(guān)要長(zhǎng)，并且指令顯示速度要以一個(gè)常量的速度顯示。要增加游戲的難度，在顯示指令序列時(shí)可以減少指令展示給用戶的時(shí)間。

2.5.3表現(xiàn)形式

??? 創(chuàng)建一個(gè)賦予表現(xiàn)力的程序遠(yuǎn)不止我們這里所介紹的這些內(nèi)容。可能做一點(diǎn)改動(dòng)就可以將我們的UI做的更加好看，比如，可以在顯示指令提示，以及用戶移入和離開(kāi)指定區(qū)域時(shí)可以采用一些比較好看的動(dòng)畫。當(dāng)用戶執(zhí)行的指令正確時(shí)，可以展現(xiàn)一個(gè)動(dòng)畫效果給予獎(jiǎng)勵(lì)。同樣的，在游戲結(jié)束時(shí)也可以展現(xiàn)出一個(gè)動(dòng)畫。

3. 結(jié)語(yǔ)

??? 本文圍繞Kinect介紹了WPF輸入系統(tǒng)的相關(guān)知識(shí)，并討論了如何將Kinect作為WPF程序的輸入設(shè)備與應(yīng)用程序進(jìn)行交互，最后展示了一個(gè)Simon say的小游戲來(lái)講述如何進(jìn)行這些實(shí)際操作。

??? 限于篇幅，下面一篇文章將會(huì)對(duì)骨骼追蹤進(jìn)行進(jìn)一步闡述，并對(duì)Simon say這個(gè)小游戲增加姿勢(shì)識(shí)別，敬請(qǐng)期待。

??? 本文所有代碼點(diǎn)擊此處下載，希望以上文章對(duì)你了解Kinect SDK有所幫助，謝謝！

轉(zhuǎn)載于:https://www.cnblogs.com/yangecnu/archive/2012/04/13/KinectSDK_AdvanceSkeletonTracking_part1.html

總結(jié)

以上是生活随笔為你收集整理的[译]Kinect for Windows SDK开发入门(八)：骨骼追踪进阶上的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：通过select选项动态异步加载内容
下一篇： DWZ富客户端框架设计思路与学习建议