(57)【特許請求の範囲】
【請求項１】
仮想空間に関連したアバターのモデルと、物理空間に関連したユーザーのモデルとを使用するためのシステムであって、
命令を格納したメモリーを含み、前記命令は、実行されると前記システムに、少なくとも、
前記ユーザーの画像を処理して、前記ユーザーのエンド・エフェクターの前記物理空間における位置を決定し、前記ユーザーの前記エンド・エフェクターは、前記ユーザーの前記モデルに関連した複数のノードのうちの１つであり、かつ前記ユーザーの一部に動きにおいて関連し、前記複数のノードが、階層構造の親子関係によって相互接続され、
前記アバターのエンド・エフェクターの前記仮想空間における位置を決定し、前記アバターの前記エンド・エフェクターは、前記アバターの前記モデルに関連した複数のノードのうちの１つでありかつ前記ユーザーの前記エンド・エフェクターに関連し、前記アバターの前記エンド・エフェクターの前記位置は、前記ユーザーの前記エンド・エフェクターの前記位置を使用して計算され、
前記アバターの前記エンド・エフェクターに関連した関節の可能な動きを、前記エンド・エフェクターが所望の位置に達するのを可能にする前記アバターの前記エンド・エフェクターに関連した前記関節およびノードの可能な動きを定める情報に基づいて決定し、
前記アバター・モデルに解剖学的に可能なポーズを求めるために、前記アバターの前記関節の前記仮想空間における位置を決定し、前記アバターの前記関節の位置が、少なくとも前記アバターの前記エンド・エフェクターの前記位置および前記動きから決定され、
前記アバター・モデルの前記解剖学的に可能なポーズを求めるために、前記アバターの前記エンド・エフェクターの前記位置を変更することなく前記関節の前記位置に前記アバターの前記関節を設定し、前記解剖学的に可能なポーズが前記アバターの前記関節と前記アバターの前記エンド・エフェクターを含み、前記解剖学的に可能なポーズが、存在しないまたはサイズ変更されたノードの位置を決定するために逆運動学システムを使用して決定される、
システム。
【請求項２】
請求項１記載のシステムにおいて、前記関節の位置を決定することが、更に、
前記ユーザーの関節の向きに少なくとも近づけるように、前記関節の向きを決定することを含み、前記ユーザーの前記関節の向きが、前記ユーザーの前記画像から生成されたデーターから得られる、システム。
【請求項３】
請求項１記載のシステムであって、前記メモリーは更に命令を含み、該命令は、実行されると前記システムに、
前記ユーザーの前記画像から前記ユーザーの前記モデルを生成させ、前記ユーザーの前記モデルが前記ユーザーの前記エンド・エフェクターの位置を含む、システム。
【請求項４】
請求項１記載のシステムであって、前記メモリーは更に命令を含み、該命令は、実行されると前記システムに、  
アニメーション・ストリームを生成することであって、前記アニメーション・ストリームが、前記関節の前記位置と、前記アバターの前記エンド・エフェクターの前記位置とを含み、
前記アニメーション・ストリームをグラフィクス・プロセッサーに送ること、
をさせる、システム。
【請求項５】
請求項１記載のシステムにおいて、前記関節の前記位置を決定することが、更に、
前記関節がユーザーの特定の関節と関連付けられないと決定することであって、前記ユーザーの前記画像から生成されたデーターが前記ユーザーの前記特定の関節についての位置情報を含まないときに、前記関節が前記ユーザーの前記特定の関節と関連付けられず、
デフォルトの位置に近づけるように、前記関節の前記位置を設定することと、
を含む、システム。
【請求項６】
請求項１記載のシステムであって、前記メモリーは更に命令を含み、該命令は、実行されると前記システムに、
前記アバターの前記エンド・エフェクターの前記位置を受けるアプリケーションの実行中に、前記アプリケーションから前記アバターの前記モデルの要求を受けることと、
前記アプリケーションの実行中に、モデルのライブラリーから前記アバターの前記モデルを選択することと、
をさせる、システム。
【請求項７】
請求項１記載のシステムであって、前記メモリーは更に命令を含み、該命令は、実行されると前記システムに、
前記ユーザーの特定の関節と前記アバターの特定の関節との間の関係を生成することと、
前記アバター・モデルのサイズに当てはまるように、前記ユーザーのエンド・エフェクターを前記ユーザーの前記特定の関節に結合する相互接続を生成することと、
をさせる、システム。
【請求項８】
請求項１記載のシステムであって、前記メモリーは更に命令を含み、該命令は、実行されると前記システムに、
前記ユーザーのエンド・エフェクターを、前記ユーザーとは異なるスケルトン・アーキテクチャーを有する前記アバター・モデルにマッピングすること、
をさせる、システム。
【請求項９】
物理環境にあるユーザーに仮想環境にあるアバターを関連付けるための、コンピュータにより実行される方法であって、
前記コンピュータが、アバター・モデルのロードを受けるステップであって、前記アバター・モデルが、エンド・エフェクターと、複数のノードとを含み、該複数のノードが、階層構造の親子関係によって相互接続された、ステップと、
前記コンピュータが、前記ユーザーのエンド・エフェクターについての第１位置情報を受け取るステップであって、前記ユーザーの前記エンド・エフェクターが、前記ユーザーの画像において含まれ、前記物理環境と相互作用する前記ユーザーの一部と関連付けられ、前記第１位置情報が、前記画像から決定される、ステップと、
前記コンピュータが、前記アバター・モデルの前記エンド・エフェクターの第１位置を決定するステップであって、前記第１位置が、前記ユーザーの前記エンド・エフェクターについての前記第１位置情報を使って計算される、ステップと、
前記コンピュータが、前記ユーザーの前記エンド・エフェクターについての第２位置情報を受け取るステップであって、前記第２位置情報が前記ユーザーの第２画像から決定される、ステップと、
前記コンピュータが、前記アバター・モデルの前記エンド・エフェクターの前記第１位置を第２位置に更新するステップであって、前記第２位置が、前記ユーザーの前記エンド・エフェクターについての前記第２位置情報を使って計算される、ステップと、
前記コンピュータが、前記アバター・モデルに解剖学的に可能なポーズを得るために、前記ノードの位置を決定するステップであって、前記位置が、前記アバター・モデルの前記エンド・エフェクターの前記第２位置と前記ノードにおいて可能な動きを定める情報とに基づいて決定され、前記解剖学的に可能なポーズが、前記アバター・モデルの前記エンド・エフェクターの前記第２位置を変更せずに前記ノードを前記決定された位置に設定し、前記解剖学的に可能なポーズが、存在しないまたはサイズ変更されたノードの位置を決定するために逆運動学システムを使って決定される、ステップと、
を含む、方法。
【請求項１０】
請求項９記載の方法であって、更に、
前記コンピュータが、前記ユーザーの前記エンド・エフェクターを含むユーザー・モデルを生成するステップと、
前記コンピュータが、前記ユーザー・モデルから、前記ユーザーの前記エンド・エフェクターについての前記位置情報を決定するステップと、
を含む方法。
【請求項１１】
請求項９記載の方法であって、前記アバター・モデルは、ヒトでないアバター・モデルを含む、方法。
【請求項１２】
請求項９記載の方法であって、更に、
前記コンピュータが、前記ユーザーの関節の向きに少なくとも近づけるように、前記アバター・モデルの関節の向きを設定するステップを含み、前記ユーザーの前記関節の向きが、生成されたユーザー・モデルから決定される、方法。
【請求項１３】
請求項９記載の方法であって、更に、
前記コンピュータが、前記アバター・モデルからアニメーション・ストリームを生成するステップと、
前記コンピュータが、前記アニメーション・ストリームを予め定められたアニメーションと混合するステップと、
を含む、方法。
【請求項１４】
プロセッサ実行可能命令を含むコンピュータ読み取り可能記憶媒体であって、前記プロセッサ実行可能命令が、プロセッサにより実行されると、前記プロセッサに請求項９から１３のいずれかに記載の方法を実行させる、コンピュータ読み取り可能記憶媒体。
【発明の詳細な説明】
【従来技術】
【０００１】
[0001]  コンピューター・ゲーム、マルチメディア・アプリケーションなどのような多くの計算アプリケーションは、アバターまたはキャラクターを含み、これらは、典型的なモーション・キャプチャー技法を用いて動画化される。例えば、ゴルフ・ゲームを開発するとき、プロのゴルファーを、モーション・キャプチャー機器を有するスタジオに連れてくることができる。モーション・キャプチャー機器は、例えば、スタジオ内の特定ポイントに向けられている複数のカメラを含む。次いで、プロのゴルファーに、複数のポイント・インディケータを有するモーション・キャプチャー・スーツを着用させる。モーション・キャプチャー・スーツは、カメラが、例えば、プロのゴルファーのゴルフをする動きを取り込むことができるように構成され、カメラによって追跡させることができる。次いで、これらの動きを、ゴルフ・ゲームの開発中に、アバターまたはキャラクターに適用することができる。ゴルフ・ゲームが完成したとき、アバターまたはキャラクターは、ゴルフ・ゲームの実行中にプロのゴルファーの動きで動画化することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００２】
生憎、典型的なモーション・キャプチャー技法は、費用がかかり、特定のアプリケーションの開発に結びつけられており、実際のプレーヤーまたはアプリケーションのユーザーと関連付けられた動きを含まない。
【課題を解決するための手段】
【０００３】
[0002]  本開示の一実施形態例では、方法について記載する。この例では、本方法は、限定ではなく、アプリケーションのリアル・タイム実行中に、アバターのエンド・エフェクターの位置を受け取るステップであって、ユーザーのエンド・エフェクターの位置を用いて計算された位置にアバターのエンド・エフェクターが設定され、ユーザーのエンド・エフェクターの位置が、ユーザーの画像から予め形成されている、ステップと、アプリケーションのリアル・タイム実行中に、アバター・モデルに解剖学的に可能なポーズを求めるために、アバター・モデルの関節の位置を判定するステップであって、アバター・モデルの関節の位置が、少なくともアバターのエンド・エフェクターの位置から決定される、ステップとを含む。以上に加えて、本開示の一部をなす特許請求の範囲、図面、および本文において、他の態様について説明する。
【０００４】
[0003]  本開示の一実施形態例では、方法について記載する。この例では、本方法は、限定ではなく、ビデオゲームを実行するステップとビデオゲームから受け取った情報に基づいて、アバター・モデルをロードするステップであって、アバター・モデルが、アバターのエンド・エフェクターと、複数のアバターの関節とを含む、ステップと、ユーザーのエンド・エフェクターについての位置情報を受け取るステップと、ビデオゲームのリアル・タイム実行中に、アバターのエンド・エフェクターの位置を判定するステップであって、アバターのエンド・エフェクターの位置が、ユーザーのエンド・エフェクターについての位置情報を用いて計算される、ステップと、ユーザーのエンド・エフェクターについての第２位置情報を受け取るステップと、ビデオゲームのリアル・タイム実行中に、アバターのエンド・エフェクターの位置を第２の位置に更新するステップであって、アバターのエンド・エフェクターの位置が、ユーザーのエンド・エフェクターについての第２位置情報を用いて計算される、ステップと、ビデオゲームのリアル・タイム実行中に、アバター・モデルに解剖学的に可能なポーズを求めるために、アバターの関節の位置を判定するステップであって、このポーズが、アバターのエンド・エフェクターの更新された位置を維持する、ステップとを含む。以上に加えて、本開示の一部をなす特許請求の範囲、図面、および本文において、他の態様について説明する。
【０００５】
[0004]  本開示の一実施形態例では、方法について記載する。この例では、本方法は、限定ではなく、画像からユーザー・モデルを生成するステップであって、ユーザー・モデルがユーザーエンド・エフェクターを含む、ステップと、アプリケーションのランタイム実行中に、ユーザーのエンド・エフェクターをアバター・モデルにマッピングするステップと、アプリケーションのランタイム実行中に、モデルに解剖学的に可能なポーズを求めるためにアバターの関節の位置を設定するステップと、アプリケーションのランタイム実行中に、ユーザー・モデルに対する変更に基づいて、アバターのエンド・エフェクターおよびアバターの関節の位置を修正するステップとを含む。 以上に加えて、本開示の一部をなす特許請求の範囲、図面、および本文において、他の態様について説明する。
【０００６】
[0005]  尚、本開示の１つ以上の種々の態様は、本明細書において言及した本開示の態様を実施するための回路および／またはプログラミングを含むことができるが、これらには限定されるのではなく、回路および／またはプログラミングは、システム設計者の設計選択に依存して、本明細書において言及した態様を実施するように構成されたハードウェア、ソフトウェア、および／またはファームウェアの 事実上あらゆる組み合わせとすることができることは、当業者であれば認めることができよう。
【０００７】
[0006]  以上に述べたのは摘要であり、したがって、簡略化、一般化、および詳細の省略を必要上含む。この摘要は例示であり、限定であることは全く意図されていないことは、当業者には認められよう。
【図面の簡単な説明】
【０００８】
【図１】図１は、本開示の態様を実現することができる、マルチメディア・コンソールの一例を示す。
【図２】図２は、本開示の態様を実現することができる、コンピューター・システムの一例を示す。
【図３】図３は、ターゲット認識、分析、および追跡システムの一実施形態例を示す。
【図４】図４は、ターゲット認識、分析、および追跡システムの構成の一実施形態例を示す。
【図５】図５は、計算環境に結合されたキャプチャー・デバイスの一実施形態例を示す。
【図６】図６は、ユーザー・モデルの一例を示す。
【図７】図７は、アバター・モデルの一例を示す。
【図８Ａ】図８Ａは、ユーザー・モデルを示す。
【図８Ｂ】図８Ｂは、ユーザー・モデルから発生されたアバター・モデルを示す。
【図９】図９は、アバターの一例を示す。
【図１０】図１０は、本開示の態様を実施する動作手順を示す。
【図１１】図１１は、図１０の動作手順の代替実施形態を示す。
【図１２】図１２は、本開示の態様を実施する動作手順を示す。
【図１３】図１３は、図１２の動作手順の代替実施形態を示す。
【図１４】図１４は、本開示の態様を実施する動作手順である。
【図１５】図１５は、図１４の動作手順の代替実施形態を示す。
【発明を実施するための形態】
【０００９】
[0023]  本明細書において記載するように、ユーザーは、ゲーム・コンソール、コンピューター等のような計算環境において実行するアプリケーションを制御することができ、および／または１つ以上のジェスチャおよび／または動きを行うことによって、アバターまたは画面上のキャラクターを動画化することができる。一実施形態によれば、ジェスチャおよび／または動きは、例えば、キャプチャー・デバイスによって検出することができる。例えば、キャプチャー・デバイスは、シーンの深度画像を取り込み、この画像を計算環境に送ることができる。アプリケーションにおいてアバターを動画化するために使うことができるモデルを生成することができる。
【００１０】
[0024]  図１および図２は、本開示を実現することができる計算環境の一例を示す。当業者は、計算環境が、図１のマルチメディア・コンソール１００および図２のコンピューター・システム２００に関して説明するコンポーネントの一部または全部を有することができることを、認めることができよう。
【００１１】
[0025]  本開示にわたって用いられる回路という用語は、特定用途集積回路、ハードウェア割り込みコントローラー、ハード・ドライブ、ネットワーク・アダプター、グラフィクス・プロセッサー、ハードウェア・ベースのビデオ／オーディオ・コデックというようなハードウェア・コンポーネント、およびこのようなハードウェアを動作させるために用いられるファームウェア／ソフトウェアを含むことができる。また、回路という用語は、ある種の方法または１つ以上の論理プロセッサーにおいてファームウェアまたはスイッチ・セットによって機能（１つまたは複数）を実行するように構成されているマイクロプロセッサー、 例えば、マルチコア汎用処理ユニットの１つ以上のコアを含むことができる。この例における論理プロセッサー（１つまたは複数）は、メモリー、例えば、ＲＡＭ、ＲＯＭ、ファームウェアなどからロードされる、機能（１つまたは複数）を実行するように動作可能なロジックを具体化するソフトウェア命令によって構成することができる。回路がハードウェアおよびソフトウェアの組み合わせを含む実施形態例では、実施者(implementer)が、ロジックを具体化するソース・コードを書くことができ、その後このソース・コードをコンパイルして、論理プロセッサーによって実行することができるマシン読み取り可能コードにする。ハードウェア、ソフトウェア、またはハードウェア／ソフトウェアの組み合わせの間に殆ど差がないところまで技術的現状が発展していることを当業者は認めることができるので、機能を実行するためのハードウェアまたはソフトウェアの選択は、単なる設計選択事項に過ぎない。つまり、ソフトウェア・プロセスを等価のハードウェア構造に変換することができ、そしてハードウェア構造自体を等価のソフトウェア・プロセスに変換することができることは、当業者が認めることができるのであるから、ハードアウェアの実施態様またはソフトウェアの実施態様の選択は、本開示には意味のないことであり、実施者に委ねられることである。
【００１２】
[0026]  図１は、図４のターゲット認識、分析、および追跡システムによって表示されるアバターまたは画面状のキャラクターを動画化するために使うことができる計算環境の一実施形態例を示す。このような計算環境は、ゲーミング・コンソールのような、マルチメディア・コンソール１００とすればよい。図１に示すように、マルチメディア・コンソール１００は、レベル１キャッシュ１０２、レベル２キャッシュ１０４、およびフラッシュＲＯＭ（リード・オンリー・メモリー）１０６を有する論理プロセッサー１０１を有する。レベル１キャッシュ１０２およびレベル２キャッシュ１０４は、一時的にデーターを格納し、こうしてメモリー・アクセス・サイクルの回数を減らすことによって、処理速度およびスループットを向上させる。論理プロセッサー１０１は、１つよりも多いコア、したがって追加のレベル１およびレベル２キャッシュ１０２および１０４を有して設けることもできる。フラッシュＲＯＭ１０６は、実行可能コードを格納することができる。実行可能コードは、マルチメディア・コンソール１００の電源をオンにしたときに、ブート・プロセスの初期段階中にロードされる。
【００１３】
[0027]  グラフィクス処理ユニット（ＧＰＵ）１０８およびビデオ・エンコーダー／ビデオ・コデック（コーダー／デコーダー）１１４が、高速および高分解能グラフィクス処理のためにビデオ処理パイプラインを形成する。データーは、バスを通して、ＧＰＵ１０８からビデオ・エンコーダー／ビデオ・コデック１１４に伝達される。ビデオ処理パイプラインは、テレビジョンまたは他のディスプレイに送信するために、データーをＡ／Ｖ（オーディオ／ビデオ）ポート１４０に出力する。メモリー・コントローラー１１０がＧＰＵ１０８に接続されており、限定ではなく、ＲＡＭ（ランダム・アクセス・メモリー）のような、種々のタイプのメモリー１１２にプロセッサーがアクセスし易くなる。
【００１４】
[0028]  マルチメディア・コンソール１００は、Ｉ／Ｏコントローラー１２０、システム管理コントローラー１２２、オーディオ処理ユニット１２３、ネットワーク・インターフェース・コントローラー１２４、第１ＵＳＢホスト・コントローラー１２６、第２ＵＳＢコントローラー１２８、およびフロント・パネルＩ／Ｏサブアセンブリ１３０を含む。好ましくは、これらをモジュール１１８に実装する。ＵＳＢコントローラー１２６および１２８は、周辺コントローラー１４２（１）〜１４２（２）、ワイヤレス・アダプター１４８、および外部メモリー・デバイス１４６（例えば、フラッシュ・メモリー、外部ＣＤ／ＤＶＤ  ＲＯＭドライブ、リムーバブル媒体等）のためのホストとしての役割を果たす。ネットワーク・インターフェース・コントローラー１２４および／またはワイヤレス・アダプター１４８は、ネットワーク（例えば、インターネット、ホーム・ネットワーク等）へのアクセスを与え、イーサネット・カード、モデム、Ｂｌｕｅｔｏｏｔｈモジュール、ケーブル・モデム等を含む広範囲の種々の有線またはワイヤレス・インターフェース・コンポーネントのうち任意のものとすることができる。
【００１５】
[0029]  システム・メモリー１４３は、ブート・プロセスの間にロードされるアプリケーション・データーを格納するために設けられている。メディア・ドライブ１４４が設けられており、ＤＶＤ／ＣＤドライブ、ハード・ドライブ、またはその他のリムーバブル・メディア・ドライブ等を備えることができる。メディア・ドライブ１４４は、マルチメディア・コンソール１００の内部にあっても外部にあってもよい。アプリエーション・データーは、実行、再生等のためにマルチメディア・コンソール１００によってアクセスすることができる。メディア・ドライブ１４４は、シリアルＡＴＡバスまたはその他の高速接続（例えば、ＩＥＥＥ１３９４）のようなバスを通して、Ｉ／Ｏコントローラー１２０に接続されている。
【００１６】
[0030]  システム管理コントローラー１２２は、メディア・コンソール１００の可用性を確保することに関する種々のサービス機能を提供する。オーディオ処理ユニット１２３およびオーディオ・コデック１３２は、高忠実度およびステレオ処理を行う、対応のオーディオ処理パイプラインを形成する。オーディオ・データーは、通信リンクを通して、オーディオ処理ユニット１２３とオーディオ・コデック１３２との間で伝達される。オーディオ処理パイプラインは、外部オーディオ・プレーヤまたはオーディオ処理能力を有するデバイスによる再生のために、データーをＡ／Ｖポート１４０に出力する。
【００１７】
[0031]  フロント・パネルＩ／Ｏサブアセンブリ１３０は、電力ボタン１５０およびイジェクト・ボタン１４２の機能をサポートするだけでなく、マルチメディア・コンソール１００の外面上に露出する任意のＬＥＤ（発光ダイオード）またはその他のインディケータもサポートする。システム電源モジュール１３６が、マルチメディア・コンソール１００のコンポーネントに電力を供給する。ファン１３８は、マルチメディア・コンソール１００内部にある回路を冷却する。
【００１８】
[0032]  論理プロセッサー１０１、ＧＰＵ１０８、メモリー・コントローラー１１０、およびマルチメディア・コンソール１００内部にある種々のその他のコンポーネントは、１系統以上のバスを通して相互接続されている。これらのバスには、シリアルおよびパラレル・バス、メモリー・バス、周辺バス、および種々のバス・アーキテクチャのうち任意のものを使うプロセッサー・バスまたはローカル・バスが含まれる。一例として、このようなアーキテクチャーは、ペリフェラル・コンポーネント相互接続（ＰＣＩ）バス、ＰＣＩ−Ｅｘｐｒｅｓｓバス等を含むことができる。
【００１９】
[0033]  マルチメディア・コンソール１００の電源をオンにすると、システム・メモリー１４３からメモリー１１２および／またはキャッシュ１０２、１０４にアプリケーション・データーをロードし、論理プロセッサー１０１において実行することができる。アプリケーションは、グラフィカル・ユーザー・インターフェースを提示することができる。グラフィカル・ユーザー・インターフェースは、マルチメディア・コンソール１００において利用可能な異なるタイプのメディアにナビゲートするときに、一貫性のあるユーザー体験を提供する。動作において、アプリケーションおよび／またはメディア・ドライブ１４４に含まれている他のメディアをメディア・ドライブ１４４から起動または再生して、マルチメディア・コンソール１００に追加の機能を設けることもできる。
【００２０】
[0034]  マルチメディア・コンソール１００は、単にシステムをテレビジョンまたはその他のディスプレイに接続することによって、単独システムとして動作させることができる。この単独モードでは、マルチメディア・コンソール１００は、一人以上のユーザーがシステムと相互作用を行い、ムービーを見ること、または音楽を聞くことを可能にする。しかしながら、ネットワーク・インターフェース・コントローラー１２４またはワイヤレス・アダプター１４８によって利用可能となるブロードバンド接続機能を統合することにより、マルチメディア・コンソール１００を更に大きなネットワーク・コミュニティにおける関与個体(participant)として動作させることもできる。
【００２１】
[0035]  マルチメディア・コンソール１００の電源をオンにすると、マルチメディア・コンソールのオペレーティング・システムによって、設定されている量のハードウェア・リソースがシステムの使用のために確保される。これらのリソースは、メモリー（例えば、１６ＭＢ）、ＣＰＵおよびＧＰＵサイクル（例えば、５％）、ネットワーキング帯域幅（例えば、８ｋｂｓ）等の確保を含むことができる。これらのリソースは、システムのブート時に確保されるので、確保されたリソースは、アプリケーションの視点からは存在しない。
【００２２】
[0036]  特に、メモリーの確保は、起動カーネル、コンカレント・システム・アプリケーション、およびドライバーを含めるのに十分大きいことが好ましい。ＣＰＵの確保は、一定レベルに維持することが好ましい。
【００２３】
[0037]  ＧＰＵの確保に関して、ＧＰＵ割り込みを使うことによって、システム・アプリケーション（例えば、ポップアップ）によって発生される軽量メッセージ(lightweight message)を表示して、ポップアップをオーバーレイにレンダリングするコードをスケジューリングする。オーバーレイに使われるメモリー量は、オーバーレイのエリア・サイズに依存し、オーバーレイは画面の解像度と共にスケーリングする(scale)ことが好ましい。コンカレント・システム・アプリケーションによってフル・ユーザー・インターフェースが使われる場合、ゲーム解像度とは独立した解像度を使うことが好ましい。周波数を変更しＴＶの同期を取り直す必要性をなくすように、この解像度を設定するためにスケーラーを使うとよい。
【００２４】
[0038]  マルチメディア・コンソール１００がブートして、システム・リソースを確保した後、コンカレント・システム・アプリケーションが実行してシステム機能を提供する。システム機能は、前述の確保したシステム・リソースの内部で実行する１組のシステム・アプリケーションの中にカプセル化されている。オペレーティング・システム・カーネルは、システム・アプリケーション・スレッドと、マルチメディア・アプリケーション・スレッドとの間でスレッドを識別する。一貫したシステム・リソース・ビューをアプリケーションに提供するために、システム・アプリケーションは、所定の時点および間隔で論理プロセッサー１０１において実行するようにスケジューリングされていることが好ましい。このスケジューリングは、コンソールにおいて実行しているマルチメディア・アプリケーションに対するキャッシュの分裂(disruption)を最少に抑えるためにある。
【００２５】
[0039]  コンカレント・システム・アプリケーションがオーディオを必要とする場合、時間に敏感であるため、オーディオ処理を非同期にマルチメディア・アプリケーションにスケジューリングする。マルチメディア・コンソール・アプリケーション・マネージャー（以下で説明する）は、システム・アプリケーションがアクティブのとき、マルチメディア・アプリケーションのオーディオ・レベル（例えば、無音化、減衰）を制御する。
【００２６】
[0040]  入力デバイス（例えば、コントローラー１４２（１）および１４２（２））は、マルチメディア・アプリケーションおよびシステム・アプリケーションによって共有される。入力デバイスは、確保されるリソースではないが、システム・アプリケーションとマルチメディア・アプリケーションとの間で切り換えられて、各々が対象のデバイスを有するようにする。アプリケーション・マネージャは、好ましくは、マルチメディア・アプリケーションの知識を用いずに入力ストリームの切換を制御し、ドライバーはフォーカス・スイッチ(focus switches)に関する状態情報を維持する。カメラ２６、２８およびキャプチャー・デバイス２０は、コンソール１００のための追加の入力デバイスを定めることができる。
【００２７】
[0041]  これより図２を参照すると、計算システムの一例２００が示されている。コンピューター・システム２００は、論理プロセッサー２０２、例えば、実行コアを含むことができる。１つの論理プロセッサー２０２が示されているが、他の実施形態では、コンピューター・システム２００は、複数の論理プロセッサー、例えば、プロセッサー基板毎に複数の実行コア、および／または各々複数の実行コアを有することもできる複数のプロセッサー基板を有することもできる。図に示すように、種々のコンピューター読み取り可能記憶媒体２１０は、種々のシステム・コンポーネントを論理プロセッサー２０２に結合するシステム・バスによって相互接続することができる。このシステム・バスは、メモリー・バスまたはメモリー・コントローラー、ペリフェラル・バス、および種々のバスのうち任意のものを使うローカル・バスを含む、様々なタイプのバス構造のうち任意のものとすることができる。実施形態例では、コンピューター読み取り可能記憶媒体２１０は、例えば、ランダム・アクセス・メモリー（ＲＡＭ）２０４、記憶デバイス２０６、例えば、電気機械式ハード・ドライブ、ソリッド・ステート・ドライブ等、ファームウェア２０８、例えば、フラッシュＲＡＭまたはＲＯＭ、および、例えば、ＣＤ−ＲＯＭ、フロッピー・ディスク、ＤＶＤ、フラッシュ・ドライブ、外部記憶デバイス等のようなリムーバブル記憶デバイス２１８を含むことができる。尚、磁気カセット、フラッシュ・メモリー・カード、ディジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ等のような、他のタイプのコンピューター読み取り可能記憶媒体を使ってデーターを格納することもできることは、当業者には認められてしかるべきである。
【００２８】
[0042]  コンピューター読み取り可能記憶媒体は、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、およびコンピューター２００の他のデーターの格納を行う。基本入出力システム（ＢＩＯＳ）２２０は、起動中のように、コンピューター・システム２００内のエレメント間における情報転送を補助する基本的なルーティンを含み、ファームウェア２０８に格納することができる。ファームウェア２０８、記憶デバイス２０６、ＲＡＭ２０４、および／またはリムーバブル記憶デバイス２１８には、複数のアプリケーションおよびオペレーティング・システム２２２を格納し、論理プロセッサー２０２によって実行することができる。
【００２９】
[0043]  コマンドおよび情報は、入力デバイス２１６を通して、コンピューター２００によって受け取ることができる。入力デバイス２１６は、キーボードおよびポインティング・デバイス、ジョイスティック、および／または図５のキャプチャー・デバイス３０６を含むことができるが、これらに限定されるのではない。他の入力デバイスには、マイクロフォン、スキャナー等を含むことができる。これらおよび他の入力デバイスは、多くの場合、論理プロセッサー２０２に、システム・バスに結合されているシリアル・ポート・インターフェースを通して接続されているが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）のような、他のインターフェースによって接続することもできる。また、ディスプレイまたは他のタイプのディスプレイ・デバイスも、ビデオ・アダプターのようなインターフェースを通して、システムに接続することができる。ビデオ・アダプターは、グラフィクス・プロセッサー２１２の一部とすることができ、またはこれに接続することもできる。ディスプレイに加えて、コンピューターは、通例、スピーカーおよびプリンターのような、他の周辺出力デバイス（図示せず）も含む。図１のシステム例は、ホスト・アダプター、小型コンピューター・システム・インターフェース（ＳＣＳＩ）バス、およびＳＣＳＩバスに接続される外部記憶デバイスも含むことができる。
【００３０】
[0044]  コンピューター・システム２００は、リモート・コンピューターのような１つ以上のリモート・コンピューターへの論理的接続を用いて、ネットワーク接続環境において動作することもできる。リモート・コンピューターは、他のコンピューター、サーバー、ルーター、ネットワークＰＣ、ピア・デバイス、または他の共通ネットワーク・ノードであってもよく、通例、コンピューター・システム２００に関して先に説明したエレメントの多くまたは全てを含むことができる。
【００３１】
[0045]  ＬＡＮまたはＷＡＮネットワーキング環境において使うとき、コンピューター・システム１００は、ネットワーク・インターフェース・カード２１４（ＮＩＣ）を通してＬＡＮまたはＷＡＮに接続することができる。ＮＩＣ２１４は、内部でも外部でもよく、システム・バスに接続することができる。ネットワーク接続環境では、コンピューター・システム１００に関して示したプログラム・モジュールまたはその一部を、リモート記憶デバイスに格納することもできる。尚、ここで説明するネットワーク接続は一例であり、コンピューター間に通信リンクを作る他の手段を用いてもよいことは認められよう。更に、本開示の数多くの実施形態が、特に、コンピューター化されたシステムに適しているが、本文書には、本開示をそのような実施形態に限定することを意図するものはなにもないことは想起されよう。
【００３２】
[0046]  図３および図４は、ターゲット認識、分析、および追跡システム３００の構成の一実施形態例、およびボクシング・ゲームをプレーしているユーザー３０２を示す。一実施形態例では、ターゲット認識、分析、および追跡システム３００は、ユーザー３０２のような、ヒトのターゲットを認識、分析、および／または追跡するために使うことができる。
【００３３】
[0047]  図３に示すように、ターゲット認識、分析、および追跡システム３００は、計算環境３０４を含む。計算環境３０４は、コンピューター、ゲーミング・システムまたはコンソール等とし、図１および図２において説明したのと同様のコンポーネントを含むことができる。
【００３４】
[0048]  図３に示すように、ターゲット認識、分析、および追跡システム３００は、更に、キャプチャー・デバイス３０６を含むことができる。キャプチャー・デバイス３０６は、例えば、ユーザー３０２のような、一人以上のユーザーを視覚的に監視するために使うことができるカメラとすればよく、一人以上のユーザーによって行われるジェスチャおよび／または動きを取り込み、分析し、そして追跡して、アプリケーションにおいて１つ以上の制御または動作を実行する、および／またはアバターまたは画面上のキャラクターを動画化することができる。これについては、以下で更に詳しく説明する。
【００３５】
[0049]  一実施形態によれば、ターゲット認識、分析、および追跡システム３００は、テレビジョン、モニター、高品位テレビジョン（ＨＤＴＶ）等のような、ゲームまたはアプリケーションの映像(visual)および／または音声(audio)をユーザー３０２のようなユーザーに与えることができるオーディオビジュアル・デバイス３２０に接続することができる。例えば、計算環境３０４は、グラフィクス・カードのようなビデオ・アダプターおよび／またはサウンド・カードのようなオーディオ・アダプターを含むことができる。これらは、ゲーム・アプリケーション、ゲーム以外のアプリケーションなどと関連のあるオーディオビジュアル信号を供給することができる。オーディオビジュアル・デバイス３２０は、計算環境３０４からオーディビジュアル信号を受け取ることができ、次いで、これらのオーディオビジュアル信号と関連付けられたゲームまたはアプリケーションの映像および／または音声をユーザー３０２に出力することができる。一実施形態によれば、オーディオビジュアル・デバイス３２０は、例えば、Ｓ−Ｖｉｄｅｏケーブル、同軸ケーブル、ＨＤＭＩケーブル、ＤＶＩケーブル、ＶＧＡケーブルなどによって、計算環境３０４に接続することができる。
【００３６】
[0050]  図３および図４に示すように、一実施形態例では、計算環境３０４において実行するアプリケーションは、ユーザー３０２がプレーすることができるボクシング・ゲームとすることができる。例えば、計算環境３０４は、オーディオビジュアル・デバイス３２０を使って、ボクシングの相手３３８の視覚表現をユーザー３０２に与えることができる。また、計算環境３０４は、オーディオビジュアル・デバイス３２０を使って、ユーザー３０２が彼または彼女の動きで制御することができるプレーヤー・アバター３２４の視覚表現を与えることができる。例えば、図３に示すように、ユーザー３０２はプレーヤー・アバター３２４にゲーム空間においてパンチを打たせるために、実空間おいてパンチを打つことができる。このように、一実施形態例によれば、計算環境３０４、ならびにターゲット認識、分析、および追跡システム３００のキャプチャー・デバイス３０６は、実空間におけるユーザー３０２のパンチを認識および分析するために使うことができ、このパンチをゲーム空間におけるプレーヤー・アバター３２４のゲーム制御として解釈することができ、および／またはパンチの動きを使って、ゲーム空間におけるプレーヤー・アバター３２４を動画化することができる。
【００３７】
[0051]  ユーザー３０２による他の動きも、軽く叩く、行ったり来たりする、あちこち動き回る、防御する、ジャブする、または種々の異なる力のパンチを出すように制御するというように、プレーヤー・アバター３２４を動画化するために使われる他の制御または動作として解釈することができる。更に、動きの中には、プレーヤー・アバター３２４を制御する以外の動作に対応することもできる制御として解釈してもよい場合もある。例えば、プレーヤーは、動きを用いて、ゲームを終了する、一時停止する、またはセーブする、レベルを選択する、高スコアを見る、友人と通信する等を行うこともできる。加えて、アプリケーションと相互作用するために、ユーザー３０２の動きの最大範囲が利用可能であるとよく、任意の適した方法で用いて分析するとよい。
【００３８】
[0052]  実施形態例では、ユーザー３０２のようなヒトのターゲットが、アプリケーションにおけるオブジェクトと相互作用するために、アバター３２４を制御する。例えば、ユーザー３０２は、オブジェクトを用いるために、ゲームにおいてそのオブジェクトに達することができる。この例では、ターゲット認識、分析、および追跡システム３００は、アバター３２４がそのオブジェクトを取り上げ、ゲームにおいてそのオブジェクトを用いることを可能にするように構成することができる。特定の例では、ユーザーのアバター３２４が、電子スポーツ・ゲームにおいて用いられるラケットを取り上げて持ち続けることもできる。
【００３９】
[0053]  他の実施形態例では、ターゲット認識、分析、および追跡システム３００は、更に、ターゲットの動きを、ゲームの範囲の外側にあるオペレーティング・システムおよび／またはアプリケーション制御として解釈するために使うこともできる。例えば、オペレーティング・システムおよび／またはアプリケーションの事実上あらゆる制御可能な態様を、ユーザー３０２のようなターゲットの動きによって制御することができる。
【００４０】
[0054]  図５は、ターゲット認識、分析、および追跡システム３００において使うことができるキャプチャー・デバイス３０６の実施形態例を示す。一実施形態例によれば、キャプチャー・デバイス３０６は、例えば、飛行時間、構造化光、立体画像などを含む任意の適した技法によって、深度値を含むことができる深度画像を含む深度情報と共にビデオを取り込むように構成することができる。一実施形態によれば、キャプチャー・デバイス３０６は、深度情報を「Ｚレイヤー」、即ち、深度カメラからその視線に沿って延びるＺ軸に対して垂直となることができるレイヤーに編成することができる。
【００４１】
[0055]  図５に示すように、キャプチャー・デバイス３０６は、画像カメラ・コンポーネント５０２を含むことができる。一実施形態例によれば、画像カメラ・コンポーネント５０２は、シーンの深度画像を取り込むことができる深度カメラとするとよい。深度カメラは、取り込まれたシーンの二次元（２Ｄ）画素エリアを含むことができ、この２Ｄ画素エリアにおける各画素は、カメラから取り込まれたシーンにおけるオブジェクトの、例えば、センチメートル、ミリメートル等の単位の長さまたは距離というような、深度値を表すことができる。
【００４２】
[0056]  図５に示すように、一実施形態例によれば、画像カメラ・コンポーネント５０２は、ＩＲ発発光コンポーネント５２４、三次元（３Ｄ）カメラ５２６、およびシーンの深度画像を取り込むために使うことができるＲＧＢカメラ５２８を含むことができる。例えば、飛行時間分析では、キャプチャー・デバイス３０６のＩＲ発光コンポーネント５２４は、シーンに向けて赤外線光を放出することができ、次いでセンサ（図示せず）を用いて、そのシーンの中にある１つ以上のターゲットおよびオブジェクトの表面から散乱される光を、例えば、３Ｄカメラ５２６および／またはＲＧＢカメラ５２８を用いて検出することができる。実施形態の中には、パルス状赤外線光を用いて、出射光パルスと対応する入射光パルスとの間の時間を測定し、キャプチャー・デバイス３０６からシーン内にあるターゲットまたはオブジェクト上における特定の場所までの物理的距離を判定するために使うことができるようにするとよい場合がある。加えて、他の実施形態例では、出射光波の位相を入射光波の位相と比較して、位相ずれを判定するとよい場合もある。次いで、位相ずれを使うと、キャプチャー・デバイスからターゲットまたはオブジェクト上の特定の場所までの物理的距離を判定することができる。
【００４３】
[0057]  他の一実施形態例によれば、例えば、散乱光パルス撮像を含む種々の技法によって、経時的な光の反射ビームの強度を分析することによって、飛行時間分析を用いて、キャプチャー・デバイス３０６からターゲットまたはオブジェクト上の特定の位置までの物理的距離を間接的に判定することができる。
【００４４】
[0058]  他の一実施形態例によれば、キャプチャー・デバイス３０６は、構造化光を用いて深度情報を取り込むことができる。このような分析では、パターン光（即ち、格子パターン、縞パターンのような既知のパターンとして表示される光）を、例えば、ＩＲ発光コンポーネント５２４によってシーンに向けて投射する。そのシーンにおいて１つ以上のターゲットまたはオブジェクトの表面に衝突したときに、パターンが、それに応答して、変形する可能性がある。このようなパターンの変形を、例えば、３Ｄカメラ５２６および／またはＲＧＢカメラ５２８によって取り込むことができ、次いで分析して、キャプチャー・デバイスからターゲットまたはオブジェクト上における特定の場所までの物理的距離を判定することができる。
【００４５】
[0059]  他の実施形態によれば、キャプチャー・デバイス３０６は、２つ以上の物理的に分離されたカメラを含むことができ、これらが異なる角度からのシーンを捕らえて、視覚的な立体像を得て、これを解明することによって深度情報を発生することができる。
【００４６】
[0060]  キャプチャー・デバイス３０６は、更に、マイクロフォン５３０を含むことができる。マイクロフォン５３０は、音響を受信し電気信号に変換するトランスデューサまたはセンサを含むことができる。一実施形態によれば、マイクロフォン５３０を使うと、ターゲット認識、分析、および追跡システム３００においてキャプチャー・デバイス３０６と計算環境３０４との間におけるフィードバックを低減することができる。加えて、マイクロフォン５３０を使うと、ユーザーによって供給することもできるオーディオ信号を受信し、計算環境３０４において実行することができるゲーム・アプリケーション、ゲーム以外のアプリケーションなどのようなアプリケーションを制御することができる。
【００４７】
[0061]  一実施形態例では、キャプチャー・デバイス３０６は、更に、画像カメラ・コンポーネント５０２と動作的に通信することができる論理プロセッサー５３２を含むことができる。更に、キャプチャー・デバイス３０６は、メモリー・コンポーネント５３４を含むことができる。メモリー・コンポーネント５３４は、プロセッサー５３２によって実行することができる命令、３ＤカメラまたはＲＧＢカメラによって取り込まれた画像またはフレーム、あるいは任意の他の適した情報、画像等を格納することができる。一実施形態例によれば、メモリー・コンポーネント５３４は、ランダム・アクセス・メモリー（ＲＡＭ）、リード・オンリー・メモリー（ＲＯＭ）、キャッシュ、フラッシュ・メモリー、ハード・ディスク、または任意の他の適した記憶コンポーネントを含むことができる。図５に示すように、一実施形態では、メモリー・コンポーネント５３４は、画像キャプチャー・コンポーネント５２２および論理プロセッサー５３２と通信する別のコンポーネントとすることができる。他の実施形態によれば、メモリー・コンポーネント５３４をプロセッサー５３２および／または画像キャプチャー・コンポーネント５２０に統合してもよい。
【００４８】
[0062]  キャプチャー・デバイス３０６は、例えば、キャプチャー・デバイス３０６の３Ｄカメラ４２６および／またはＲＧＢカメラ５２８によって取り込まれたシーンの画像またはフレームを得るように構成することができる。一実施形態例では、深度画像は、ヒトのターゲットと、取り込まれたシーンの中にあるテーブル、モニターなどのような、１つ以上のヒト以外のターゲットとを含む場合もある。深度画像は、複数の被観察画素を含むことができ、各被観察画素には、被観察深度値が関連付けられている。例えば、深度画像は、取り込まれたシーンの二次元（２Ｄ）画素エリアを含むことができ、この２Ｄ画素エリアにおける各画素は、キャプチャー・デバイスから取り込まれたシーンの中にあるターゲットまたはオブジェクトの、例えば、センチメートル、ミリメートル等を単位とする長さまたは距離のような、深度値を表すことができる。一実施形態例では、深度画像に着色して、深度画像の画素の異なる色が、キャプチャー・デバイスからのヒトのターゲットおよびヒト以外のターゲットの異なる距離に対応するようにすることができる。例えば、一実施形態によれば、キャプチャー・デバイスに最も近いターゲットと関連のある画素には、深度画像において赤および／またはオレンジ色の濃淡で着色することができ、一方それよりも離れたターゲットと関連付けられた画素には、深度画像において緑および／または青の濃淡で着色することができる。
【００４９】
[0063]  加えて、前述のように、キャプチャー・デバイスは、「Ｚレイヤー」、またはカメラからその視線に沿って延びるＺ軸に対して垂直となることができるレイヤーを含む、算出深度情報に編成することができる。Ｚレイヤーにおいて同様のＺ値がある場合、決定されたエッジに基づいて、塗りつぶす(flood filled)ことができる。例えば、決定されたエッジと関連付けられた画素、およびその決定されたエッジの内部にあるエリアの画素を互いに関連付けて、シーンの中にあるターゲットまたはオブジェクトを定めることができ、このシーンをパターンと比較することができる。以下で説明するが、その後、この画像は、ユーザーのスケルトン・モデルを生成するために使うことができる。
【００５０】
[0064]  図の概略的な説明を続けると、キャプチャー・デバイス３０６は、通信リンク５３６を通して、計算環境３０４と通信状態におくことができる。通信リンク５３６は、例えば、ＵＳＢ接続、Firewire接続、イーサネット・ケーブル接続などを含む有線接続、および／またはワイヤレス８０２．１１ｂ、ｇ、ａ、またはｎ接続のようなワイヤレス接続とすることができる。一実施形態によれば、計算環境３０４は、クロックをキャプチャー・デバイス３０６に供給することができ、通信リンク５３６を通して、例えば、いつシーンを取り込むか判断するために、このクロックを使うことができる。
【００５１】
[0065]  加えて、キャプチャー・デバイス３０６は、例えば、３Ｄカメラ５２６および／またはＲＧＢカメラ５２８によって取り込まれた深度情報および画像、および／またはキャプチャー・デバイス３０６によって生成することができるスケルトン・モデルを、計算環境３０４に通信リンク５３６を通して供給することができる。次いで、計算環境３０４は、このモデル、深度情報、および取り込まれた画像を用いて、例えば、ゲームまたはワード・プロセッサーのようなアプリケーションを制御すること、および／またはアバターまたは画面上のキャラクターを動画化することができる。
【００５２】
[0066]  例えば、図５に示すように、計算環境３０４は、アプリケーション５６０、モデル・ライブラリー５７０、マッピング・システム５８０、および／または逆運動学システム５９０を含むことができる。一般に、エレメント５６０〜５９０の各々は、回路によって実現することができ、説明を容易にするためにエレメント５６０〜５９０は離散エレメントで表されているが、他の実施形態では、エレメント５６０〜５９０に関して説明した機能の一部または全部を、同じ回路または異なる回路によって実行することもできる。
【００５３】
[0067]  一般に、アプリケーション５６０は、アバターを含むビデオゲームまたは任意の他のアプリケーションとすることができる。一実施形態では、計算環境３０４は、異なるアバターを格納することができるモデル・ライブラリー５７０を含むことができる。アバターは、ターゲット認識、分析、および追跡システム３００によって取り込まれたユーザーの動きと一致するように、アプリケーションにおいて動画化することができる。特定の例には、モンスター・キャラクター・モデルとこのモンスターについての一連のデフォルト・ポーズとを含むモデル・ライブラリー５７０を含むとよい場合がある。このモンスター・キャラクター・モデルは、この特定のアプリケーションにおいてモンスターがどのように見えるか定めるために使うことができる。アバターは、特定のポーズを有するモンスターのゲーム内におけるコピーを発生するために使うことができる。一実施形態例では、モデル・ライブラリー５７０をアプリケーション５６０と関連付けることができるが、他の実施形態では、モデル・ライブラリー５７０をアプリケーション５６０から離して、アプリケーション５６０によって用いるだけにすることもできる。
【００５４】
[0068]  図５の説明を続けると、マッピング・システム５８０は、ユーザー空間におけるユーザーの位置を反映するユーザー・モデルを、モデル・ライブラリー５７０から得られたアバター・モデルをマッピングするように構成することができる。例えば、そして以下で更に詳しく説明するが、ノードを含むユーザー・モデルを発生することができる。ユーザー・モデルにおける各ノードには、ユーザーの一部を関連付けることができ、例えば、一部のノードは、関節ノード、例えば、２本以上の骨が相互作用する位置、または手のような四肢を表すノードとすることができる。ノードは、相互接続部、例えば、骨によって接続することができ、ツリーのような親−子関係を定める階層的関係を作ることができる。親ノード自体が子になることもあり、他のノードに接続することができる。特定の例では、手首は肘の子となることができ、肘は肩の子となることができる。この再帰的関係は、１つ以上のルート・ノードまで継続することができる。ルート・ノードは、ノードをユーザー・モデルからアバター・モデルにマッピングするための規準フレームとして使うことができる。一般に、モデルは、エンド・エフェクター(end-effector)を含むことができる。エンド・エフェクターは、アニメーターが直接位置付けたい、例えば、環境と相互作用させたい、階層内部における任意のノードである。例えば、手、足、および頭部は、典型的なエンド・エフェクターである。しかしながら、アプリケーションによってはある種の状況において、アニメーターが肩、膝、または胸板を操作することを望むこともある。
【００５５】
[0069]  前述のように、一実施形態では、アバター・モデル７００は少なくとも１つのルート・ノードを有することができ、このアバターのルート・ノード、およびユーザー・モデル６００の対応するルート・ノード（複数のノード）を用いて、関係を作ることができる。アバター・ノードの位置は、ユーザー・モデルのノードの位置から計算することができる。例えば、エンド・エフェクターの親ノードおよび祖父ノードについての位置情報を得ることができ、対応する親ノードおよび祖父ノード間における関係を作ることができる。
【００５６】
[0070]  マッピング・システム５８０に加えて、図５は、逆運動学システム５９０も示す。一般に、逆運動学は、階層構造における所与のノードの位置に基づいて、１組のノードの位置を判定するために用いられる。例えば、ユーザー・モデルはマーカーレス・システム(marker-less system)から発生されるので、ノード角の一部が受け取られない場合があり、またはユーザー・モデルよりもかなり多いノードをアバターが有することもある。このため、一実施形態例では、逆運動学システム５９０を使うことができる。逆運動学システム５９０は、エンド・エフェクターの位置をマッピング・システム５８０から受け取ることができ、エンド・エフェクターの少なくとも位置を真似るアバター・モデルのポーズを生成することができる。実施形態の中には、エンド・エフェクター以外の位置を用いて、ユーザー・モデルのポーズを真似ることができる場合もある。逆運動学システム５９０の出力をアプリケーション５６０に供給することができ、アプリケーション５６０において、この出力を標準的なアニメーションと混合すること、または標準的なアニメーションによって修正することができる。
【００５７】
[0071]  一実施形態例では、逆運動学システム５９０は、入力として、１組の所望のエンド・エフェクターの位置／向きのターゲットを受け取ることができる。この１組から、逆運動学システム５９０は、これらのターゲットを満たすことを可能にする１組のノード角を与えることができる。逆運動学問題は、正力学に密接に関係付けられており、正力学は以下の式によって簡潔に表すことができる。
【００５８】
【数１】
0005639646.tif 000002
【００５９】
この式において、エンド・エフェクターの位置ｘのベクトルを、全ての関節角θのベクトルに、何らかの関数ｆ（多くの場合、複雑で殆ど常に非線形）によって関係付けることができる。つまり、逆運動学方程式は、次の式によって表すことができる。
【００６０】
【数２】
0005639646.tif 000003
【００６１】
ここからは、このシステムを解く多くの方法がある。一実施形態例では、ヤコビに基づく線形か技法を用いて、式２を解くことができる。しかしながら、本開示は、ＩＫ方程式を解くいずれの特定の方法にも限定されることはない。
【００６２】
[0072]  一般に、ヤコビＩＫは、現在の対象ポーズについての問題の線形化を伴う。このために、ヤコビ号列を、全ての関節角に対する全てのエンド・エフェクターの寸法の導関数の行列として形成することができる。
【００６３】
【数３】
0005639646.tif 000004
【００６４】
【数４】
0005639646.tif 000005
【００６５】
ユーザー・モデルが非冗長キャラクター・スケルトンである場合（エンド・エフェクターの寸法が、関節角の寸法と同等である。線形代数の用語では、未知数と同じ数の方程式を有する）、逆運動学システム５９０は、標準的な逆行列を用いてＩＫ問題を解くように構成することができる。
【００６６】
【数５】
0005639646.tif 000006
【００６７】
[0073]  しかしながら、実施形態例の中には、標準逆行列を使うことができる場合もある。何故なら、所与のエンド・エフェクターベクトル
【００６８】
【数６】
0005639646.tif 000007
【００６９】
について式５を満足する、無限に多い関節角ベクトル
【００７０】
【数７】
0005639646.tif 000008
【００７１】
があるからである。これらの場合、何らかの性能規準にしたがって「最良の」解を求めるために、置換行列(replacement matrix)を、標準行列の代わりに使うことができる。一実施形態では、この規準は、最小二乗誤差であり、それを解くためには、ムーア−ペンローズの擬似逆行列（＋の上付き文字で示す）を使うことができる。例えば、未定系に対する解を記述することができ、特定解および斉次解双方の和を、次のように表すことができる。
【００７２】
【数８】
0005639646.tif 000009
【００７３】
ここで、（１＋Ｊ＋（θ）Ｊ（θ））は、ヌル空間投影であり、ｙは、エンド・エフェクターの速度に寄与しないが、スケルトンにおける任意の冗長性を利用させる任意のベクトルである。
【００７４】
[0074]  一実施形態では、ベクトル
【００７５】
【数９】
0005639646.tif 000010
【００７６】
を用いて、エンド・エフェクターの位置を制御することができ、ベクトルｙは、ソース・スケルトン関節角がエンド・エフェクターの位置決めと干渉しないことを条件に、ソース・スケルトン関節角に一致するようにポーズを駆動するために用いられる。
【００７７】
[0075]  図６は、ターゲット認識、分析、および追跡システム３００によって生成することができるユーザー・モデルを示す。例えば、ターゲット認識、分析、および追跡システム３００は、キャプチャー・デバイス３０６によって得られる深度画像からモデル６００を生成するように構成することができる。この例では、ターゲット認識、分析、および追跡システム３００は、深度画像における各ターゲットまたはオブジェクトを塗りつぶし、塗りつぶした各ターゲットまたはオブジェクトを、種々の位置またはポーズにあるヒトの体モデルと関連付けられたパターンと比較することによって、深度画像が、例えば、図３および図４に関して先に説明したユーザー３０２のような、ユーザーに対応するヒトのターゲットを含むか否か判断することができる。塗りつぶしたターゲットまたはオブジェクトがパターンと一致した場合、これを分離しそして走査して、例えば、種々の体部分の測定値を含む値を決定することができる。一実施形態例によれば、次いで、スケルトン・モデル、メッシュ・モデル等のようなモデルを、この走査に基づいて生成することができる。例えば、一実施形態によれば、走査によって決定することができる測定値を、１つ以上のデーター構造に格納することができ、このデーター構造を用いて、モデルにおける１つ以上の関節を定めることができる。１つ以上の関節は、ヒトの体部分に対応することができる１本以上の骨を定めるために使うことができる。
【００７８】
[0076]  図６の説明を続けると、モデル６００は、例えば、ヒトのターゲットを表すことができる１つ以上のデーター構造を、三次元モデルとして含むことができる。各体部分は、モデル６００のノードおよび相互接続部を定める数学的ベクトルとして特徴付けることができる。図６に示すように、モデル６００は、関節ｊ１〜ｊ１８のような、１つ以上のノードを含むことができる。一実施形態例によれば、関節ｊ１〜ｊ１８の各々は、それらの間に定められた１つ以上の体部分が、１つ以上の他の体部分に対して動くことを可能にすることができる。例えば、ヒトのターゲットを表すモデルは、複数の剛体の体部分および／または変形可能な体部分を含むことができ、これらの体部分は、「骨」のような１つ以上の構造的部材と、隣接する骨の交点に位置する関節ｊ１〜ｊ１８とによって定めることができる。関節ｊ１〜ｊ１８は、骨および関節ｊ１〜ｊ１８と関連付けられている種々の体部分が、互いに独立して動くことを可能にすることができる。例えば、図６に示す接合部ｊ７およびｊ１１間に定められている骨は、前腕に対応することができ、この前腕は、例えば、ふくらはぎに対応することができる関節ｊ１５およびｊ１７間に定められている骨とは独立して動かすことができる。
【００７９】
[0077]  前述のように、体部分の各々は、図６に示す関節および骨を定める、Ｘ値、Ｙ値、およびＺ値を有する数学的ベクトルとして特徴付けることができる。一実施形態例では、図６に示す、骨と関連付けられたベクトルの交点は、関節ｊ１〜ｊ１８と関連付けられたそれぞれのポイントを定めることができる。
【００８０】
[0078]  一般に、ターゲット認識、分析、および追跡システム３００は、ユーザーからの動きを取り込み、この動きを用いてモデルを調節することができる。例えば、前述したキャプチャー・デバイス３０６のようなキャプチャー・デバイスは、シーンの深度画像、ＲＧＢ画像等のような複数の画像を取り込むことができ、モデルを調節するために使うことができる。一実施形態によれば、これらの画像の各々は、定められた頻度に基づいて観察するまたは取り込むことができる。例えば、キャプチャー・デバイスは、シーンの新たな画像を、ミリ秒毎、マイクロ秒毎等で観察するまたは取り込むことができる。画像の各々を受け取ると、個々の画像と関連付けられた情報を、モデルと関連付けられた情報と比較して、ユーザーによって動きが行われた可能性があるか否か判断することができる。例えば、一実施形態では、モデルは、合成深度画像のような合成画像に、ラスタライズ(rasterize)することができる。合成画像における画素を、受け取った画像の各々におけるヒト・ターゲットと関連付けられた画素と比較して、受け取った画像においてヒト・ターゲットが動いたか否か判断することができる。
【００８１】
[0079]  一実施形態例によれば、合成画像と受け取った画像との間における画素の比較に基づいて、１つ以上の力ベクトルを計算することができる。次いで、モデルの関節のような１つ以上の力を受ける態様に、１つ以上の力を加えて、実空間にいるヒト・ターゲットまたはユーザーのポーズに一層近く対応するポーズに、モデルを調節することができる。例えば、前述のように、種々の時点において受け取られた深度画像において観察されたまたは取り込まれた、種々の地点におけるユーザーの動きまたはジェスチャに基づいて、モデルを調節することができる。特定の例では、ユーザーが彼または彼女の左腕を上げたときに、画像を取り込むことができる。画像追跡システムは、ユーザーのポーズに当てはめるために、１つ以上の力ベクトルを摘要する、またはユーザー・モデル６００を調節することができる。
【００８２】
[0080]  図７は、例えば、ヒトのターゲットを三次元モデルとして表すことができる１つ以上のデーター構造を含むことができるアバター・モデル例７００を示す。アバター・モデル７００は、ユーザー・モデル６００のノードをアバター・モデル７００のノードにマッピングすることによって、マッピング・システム５８０によって生成することができる。図示した実施形態では、アバター・モデル７００は、ユーザー・モデル６００と同様のアーキテクチャーを有することができるが、アバター・モデルは、ユーザー・モデル６００とは多少異なるアーキテクチャーまたはノード階層を有してもよい。加えて、アバター・モデル７００は、ユーザー・モデルよりも多いノードを有してもよく、あるいはユーザー・モデル６００よりも大きくてもまたは小さくてもよい。図示する例では、アバター・モデルの方が小さくそして広い。前述したことと同様、各体部分は、アバター・モデル７００のノードおよび相互接続部を定める数学的ベクトルとして特徴付けることができる。
【００８３】
[0081]  マッピング・システム５８０は、ユーザー・ノードの位置を受け取り、アプリケーション５６０のリアル・タイム実行中に、これらをアバターのノードにマッピングし直すように構成することができる。一実施形態では、アバター・モデル７００は、ルート・ノードを有することができ、それとユーザー・モデルのルート・ノードとの間に関係を作ることができる。例えば、モデル・ライブラリー５７０は、実行時に使うべき関係を定める情報を含むことができる。この関係を用いて、ユーザーのノードの位置から、アバターのノードの位置を計算することができる。
【００８４】
[0082]  図８Ａは、ユーザー・モデル６００を示し、図８Ｂは、アバター・モデル７００を示す。アバター・モデル７００は、モデル６００から生成されていてもよい。例えば、図８Ａにおいて、ユーザーが彼または彼女の左腕を振っているユーザー・モデル６００を生成することができる。マッピング・システム５８０は、例えば、図８Ｂの小さくしたアバター・モデル７００に当てはめるように、ユーザー・モデル６００のサイズを変更するために使うことができる。一実施形態では、例えば、ノードｊ１２がエンド・エフェクターとなることができ、その位置を逆運動学システム５９０に供給することができる。逆運動学システム５９０は、アバター・モデルに解剖学的に可能なポーズを取らせ、しかもエンド・エフェクターの位置に達するように、ｊ８の位置を決定することができる。これらの図によって示されるように、実施形態の中には、アバター７００のサイズが異なるという事実のために、アバター７００のポーズが、ユーザー・モデル６００のポーズに一致しないこともあり得る。例えば、アバター７００の腕が、その位置に達するために、ユーザー・モデル６００の腕よりも伸びることもある。
【００８５】
[0083]  図９は、アバター・モデル７００から動画化することができるアバターまたはゲーム・キャラクター９００の一実施形態例を示す。図９に示すように、アバターまたはゲーム・キャラクター７００は、前述した被追跡モデルについて取り込まれた腕を振る動きを真似るように動画化することができる。例えば、図８Ａおよび図８Ｂに示したモデル６００の関節ｊ８およびｊ１２、ならびにそれらの間に定められた骨を、左肘関節ｊ８’および左手首関節ｊ１２’にマッピングすることができる。次いで、アバターまたはゲーム・キャラクター９００を動画化してポーズ９０２を取らせることができる。
【００８６】
[0084]  以下には、プロセスの実施態様を示す一連のフローチャートが続く。理解を容易にするために、初めの方のフローチャートは全体的な「全体像」の視点から実施態様を紹介し、その後のフローチャートが更なる追加および／または詳細を提示するように編成されている。更に、破線によって示される動作手順は随意選択肢と見なされることは、当業者には認めることができよう。
【００８７】
[0085]  図１０は、動作１０００、１００２、および１００４を含む本手順の態様を実施する動作手順を示す。この図に示すように、動作１０００は動作手順を開始し、動作１００２は、アプリケーションのリアル・タイム実行中に、アバターのエンド・エフェクターの位置を受け取ることを示す。アバターのエンド・エフェクターは、ユーザーのエンド・エフェクターの位置を用いて計算された位置に設定されており、ユーザーのエンド・エフェクターの位置は、ユーザーの画像から予め求められている。例えば、図５に移ると、本開示の一実施形態では、ユーザーの画像から生成されるデーター、例えば、ユーザー・モデル６００を用いて、ビデオゲームのようなアプリケーション５６０の実行中に、アバターのエンド・エフェクターの位置を求めることができる。例えば、計算環境３０４はマッピング・システム５８０を含むことができ、このマッピング・システム５８０は、例えば、ルート・ノードを基準点として用いて、ユーザー・モデル６００からアバター・モデル７００にノードをマッピングするために使うことができる。データー構造における各ノードは、例えば、その親からのオフセットとすることができる位置を有することができ、その位置は、長さ値、垂直角、および水平角を含む。他の実施形態では、各ノードは地理的空間座標、例えば、Ｘ値、Ｙ値、およびＺ値を有することができる。この実施形態例では、マッピング・システム５８０は、ユーザーのエンド・エフェクターの位置を特定する情報を受け取ることができる。
【００８８】
[0086]  一実施形態では、ユーザーのエンド・エフェクターの位置は、計算環境３０４のメモリー、ＲＡＭ、ＲＯＭに格納されている画像から生成することができる。この実施形態では、キャプチャー・デバイス３０６は、カメラ・コンポーネント５０２を用いて、ユーザー３０２の画像を取り込むことができる。この画像は、先に説明した技法を用いてユーザー・モデル６００を生成するために使うことができる。
【００８９】
[0087]  図１０の説明を続けると、動作１００４は、アプリケーションのリアル・タイム実行中に、アバター・モデルに解剖学的に可能なポーズを得るためにアバター・モデルの関節の位置を判定することを示し、アバター・モデルの関節の位置は、少なくともアバターのエンド・エフェクターの位置から決定される。例えば、そして先の例を続けると、一旦マッピング・システム５８０がアプリケーション空間におけるエンド・エフェクターの位置を得たなら、これらの位置を逆運動学システム１９０に供給することができる。逆運動学システム５９０は、先に説明した技法を用いて、エンド・エフェクターの位置を考慮に入れたアバターのポーズを決定するように構成することができる。
【００９０】
[0088]  一実施形態では、逆運動学システム５９０は、種々のノードによって行うことができる動きを定める情報を用いて、モデルに解剖学的に可能なポーズを決定することができる。例えば、肘を表すノードを、そのノードにおいて可能な２つの動き、即ち、蝶番のような屈曲および伸張、ならびに前腕を回す動きを定める情報と関連付けることができる。逆運動学システム５９０は、この情報を用いて、この情報に基づいて有効であり、エンド・エフェクターが所望の位置に達することを可能にする位置を求めることができる。
【００９１】
[0089]  これより図１１に移ると、動作１１０６から１１１８を含む、図１０の動作手順１０００の代替実施形態が示されている。ここで、動作１１０６に移ると、ユーザーの関節の向きに少なくとも近ずけるように、特定のアバター・モデルの関節の向きを決定することが示されている。ユーザーの関節の向きは、ユーザーの画像から生成されたデーターから求められる。例えば、一実施形態では、ユーザー・モデル６００を生成しメモリーに格納することができる。この例では、ユーザー・モデル６００は、エンド・エフェクター以外のノードの位置を特定する情報を有することができる。例えば、エンド・エフェクターが手であることもあり、ユーザー・モデルは、ユーザーの肘およびユーザーの肩を表すノードについての位置情報を有するとよい。マッピング・システム５８０を実行することができ、これら追加のノードについての座標を、アバター・モデル７００の位置に変換することができる。これらの位置は、エンド・エフェクターの位置と共に、逆運動学システム５９０に送ることができる。すると、逆運動学システム５９０は、他のノードについての位置情報を考慮に入れた、アバター・モデル７００のポーズを決定することができる。この例では、エンド・エフェクターを動かす必要なく、エンド・エフェクターを正しく位置付けし、他のいずれのノードの向きとも一致させようとするために、逆運動学システム５９０を優先させることができる。このように、実施形態例の中には、逆運動学システム５９０が、ユーザーの向きを真似するために精度高くノードを配置することができるものや、ユーザーの向きに近づけるようにノードを位置付けできるものもある。
【００９２】
[0090]  図１１の説明を続けると、動作１１０８は、ユーザーの画像からユーザー・モデルを発生することを示す。ユーザー・モデルは、ユーザーのエンド・エフェクターの位置を含む。例えば、この実施形態では、図５および図６に関して先に説明した技法を用いて、ユーザー・モデルを生成することができる。この実施形態例では、ユーザー・モデル６００は、ノード、例えば、相互接続部、例えば、骨によって接続することができる、エンド・エフェクターおよび複数の関節を含むことができる。
【００９３】
[0091]  動作１１１０に移ると、アニメーション・ストリームを生成することが示されている。このアニメーション・ストリームは、モデルの関節の位置、およびエンド・エフェクターの位置を含む。動作１１１０は、更に、このアニメーション・ストリームをグラフィクス・プロセッサーに送ることを示す。例えば、一実施形態では、アバター・モデル７００を用いて、アニメーション・ストリームを生成することができる。この例では、アニメーション・ストリームを、例えば、プリミティブ(primitive)に変換し、グラフィクス・プロセッサーに送ることができる。すると、グラフィクス・プロセッサーはこのプリミティブを実行し、アバター・モデルを用いて、メモリー内にあるゲームにキャラクターをレンダリングし、次いでレンダリングしたキャラクターを示す情報をオーディオビジュアル・デバイス３２０に送ることができる。
【００９４】
[0092]  図１１の説明を続けると、動作１１１２は、アバター・モデルの関節位置を決定することが、限定ではないが、特定のアバター・モデルの関節を特定のユーザーの関節と関連付けないことを決定することを含む実施形態を示し、特定のアバター・モデルの関節を特定のユーザーの関節と関連付けないのは、データーが、その特定のユーザーの関節についての位置情報を含まないときである。動作１１１２は、デフォルト位置に近づくように、特定のアバター・モデルの関節の位置を設定することも含む。例えば、一実施形態では、アバター・モデルのデフォルト・ポーズを定める情報、およびアバター・モデルにおける関節についての位置情報を、メモリー・ライブラリー５７０に格納することができる。例えば、アバター・モデルには、「Ｔ」に似たポーズを形成する関節の位置を定める情報と関連付けることができる。また、モデル・ライブラリー５７０は、走行または歩行しているポーズ、あるいは物体を保持しているアバターを示すポーズというような、種々の他のポーズも含むことができる。この例では、逆運動学システム５９０に、エンド・エフェクターの位置、および取り込まれた任意の関節の位置を供給することができる。また、逆運動学システム５９０は、システムに位置情報が欠ける場合、関節のデフォルト位置を定める情報を受け取ることもできる。例えば、右膝が対象の関節となる場合があっても、取り込まれた画像に、右膝についての情報が全くない場合や、何らかの理由で情報が使用できない場合もある。この例では、逆運動学システム５９０がデフォルト位置情報を用いて、デフォルト位置を考慮に入れたアバター・モデルのポーズを生成することができる。
【００９５】
[0093]  この例では、ユーザー・モデル６００と、モデル・ライブラリー５７０の中にあるモデルとの間の比較に基づいて、マッピング・システム５８０がデフォルト位置を選択することができる。この例では、エンド・エフェクターおよび任意の関節の既知の位置を定める情報を、ライブラリーと比較することができ、最も良く当てはまるデフォルト・モデルを使うことができる。デフォルトの関節位置は、未知のユーザーの関節であればいずれのためにでも、逆運動学システム５９０に送ることができる。
【００９６】
[0094]  一実施形態例では、逆運動学システム５９０は、アバター・モデルにどのようなポーズを取らせるか決定するために優先度の設定値を使うように構成することができる。例えば、エンド・エフェクターには、これらを最高の優先度として識別する情報と関連付けることができる。この場合、逆運動学システム５９０は、エンド・エフェクターを所望のスポットに当てはめることを優先する。マッピング・システム５８０が情報を有する関節には、エンド・エフェクターの位置よりも低い優先度レベルを設定することができる。この場合、逆運動学システム５９０はユーザー・モデルの関節と少なくとも同様であるがエンド・エフェクターの位置付けに影響を及ぼさない位置に、これらの関節を当てはめようとすることができる。最終的に、情報が受け取られていない関節を当てはめることができる。この場合、逆運動学システム５９０は、デフォルト位置と少なくとも同様であるがエンド・エフェクターの位置付けに影響を及ぼさない位置に、これらの関節を当てはめようとする。
【００９７】
[0095]  図１１の説明を続けると、動作１１１４は、アプリケーションの実行中に、アプリケーションからのアバター・モデルの要求を受け、アプリケーションの実行中に、モデルのライブラリーからアバター・モデルを選択することを示す。例えば、一実施形態では、アプリケーションを実行するときに、モデルのタイプをモデル・ライブラリー５７０からロードすることができる。この実施形態例では、アプリケーションは、用いられようとしているモデルのタイプ、例えば、ヒトモデル、馬モデル、龍モデルなどを定めることができる。マッピング・システム５８０は、用いられようとしているモデルのタイプを定める要求を受けることができ、モデル・ライブラリー５７０からそのアバター・モデルを選択することができる。
【００９８】
[0096]  加えて、マッピング・システム５８０は、アプリケーションからそれに与えられたパラメーターに基づいて、アバター・モデルのサイズを変更することができる。例えば、モデルには１つのサイズしかない場合もあり、アプリケーションが、何倍も大きいまたは小さいモデルを要求することもある。この場合、アプリケーションは所望のサイズを指定することができ、マッピング・システム５８０はしかるべくモデルを拡大縮小することができる。
【００９９】
[0097]  動作１１１６は、特定のユーザーの関節と特定のモデルの関節との間の関係を求め、アバター・モデルのサイズに当てはまるようにユーザーのエンド・エフェクターをユーザーの関節に結合する相互接続部を形成することを示す。一実施形態では、マッピング・システム５８０は、ある種の関節をモデルの既知の関節にマッピングする情報を含むことができる。例えば、各モデルは、ユーザーの膝、手首、足首、肘、または他の特定の関節にマッピングするノードを有することができる。これらのノードとアバター・モデル７００のノードとの間に関係を作ることができる。一旦関係が作られたなら、相互接続部、例えば、骨を形成して、モデルにおける種々のノードを一緒につなぐことができる。マッピング・システム５８０は、ユーザー・モデルのノードの位置を入手し、アバター・モデルのノードの位置を計算することができる。次いで、アバター・モデルのノードを逆運動学システム５９０に供給し、モデルのポーズを形成することができる。
【０１００】
[0098]  図１１の説明を続けると、動作１１８は、ユーザーのエンド・エフェクターを、ユーザーとは異なるスケルトン・アーキテクチャーを有するアバター・モデルにマッピングすることを示す。例えば、一実施形態では、モデルは、ユーザーとは異なるスケルトン・アーキテクチャーを有することができる。この例では、このアバター・モデルは、ヒトのスケルトン・アーキテクチャーを有していなくてもよい。例えば、アバター・モデルがケンタウル（一部がヒトで、一部が馬である神話上の生き物）のアーキテクチャーを有することができる。つまり、この例では、アバター・モデルは、ヒトとは異なる骨または骨格を有してもよい。この実施形態では、マッピング・システム５８０は、ヒトの種々のノードとケンタウルのノードとの間における関係を定める情報を含むことができる。例えば、ヒトの足のノードを、ケンタウルの４本の足全てにマッピングすることができ、ヒトの腕をケンタウルの腕にマッピングすることができる。
【０１０１】
[0099]  図１２に移ると、動作１２００から１２１４を含む動作手順が示されている。動作１２００は動作手順を開始し、動作１２０２は、ビデオゲームを実行することを示す。例えば、一実施形態では、アプリケーション１６０はビデオゲームであることができる。このビデオゲームは、ゲームにおいてアバターをどのように動画化するか決定するために、ターゲット認識、分析、および追跡システム３００を使うように構成することができる。
【０１０２】
[0100]  図１２の説明を続けると、動作１２０４は、ビデオゲームから受け取った情報に基づいて、アバター・モデルをロードすることを示す。このアバター・モデルは、アバターエンド・エフェクターと、複数のアバター・ノードとを含む。例えば、一実施形態では、ビデオゲームが実行されるときに、モデル・ライブラリー５７０からアバター・モデルをロードすることができる。この実施形態例では、ビデオゲームは、どの種類のアバター・モデルを使うのか、例えば、ヒト・モデル、馬モデル、龍モデル等を示す信号を、計算環境３０４に送ることができる。マッピング・システム５８０は、用いられようとしているモデルのタイプを定める要求を受けることができ、そのモデルをモデル・ライブラリー５７０から選択することができる。
【０１０３】
[0101]  加えて、マッピング・システム５８０は、ビデオゲームからそれに与えられるパラメーターに基づいて、アバター・モデルのサイズを変更することができる。例えば、アバター・モデルが１つのサイズしかない場合もあり、アプリケーションが、何倍も大きいまたは小さいモデルを要求することもある。この場合、アプリケーションは所望のサイズを指定することができ、マッピング・システム５８０はしかるべくモデルを拡大縮小することができる。
【０１０４】
[0102]  図１２の説明を続けると、動作１２０６は、ユーザーのエンド・エフェクターについての位置情報を受け取ることを示す。例えば、一実施形態では、キャプチャー・デバイス３０６は、先に説明した技法を用いて、ユーザー・モデルを形成することができる画像から、ユーザー３０２の画像を取り込むことができる。
【０１０５】
[0103]  モデルにおける各ノードの位置は、例えば、その親の位置からのオフセットとすることができ、各ノードは長さ値、垂直角、および水平角を含む。他の実施形態では、各ノードは、空間における地理的座標、例えば、Ｘ値、Ｙ値、およびＺ値を有することができる。この実施形態例では、マッピング・システム５８０は、アニメーターによって選択されたユーザーのエンド・エフェクターの位置を特定する情報を受け取ることができる。例えば、ユーザーの３Ｄモデルを、基準点、例えば、ルート・ノードから広がる座標系と共にメモリーに格納することができる。エンド・エフェクターの位置を追跡することができ、座標をメモリーに格納することができる。
【０１０６】
[0104]  図１２の説明を続けると、動作１２０８は、ビデオゲームのリアル・タイム実行中に、アバターのエンド・エフェクターの位置を判定する。ここで、アバターのエンド・エフェクターの位置は、ユーザーのエンド・エフェクターについての位置情報を用いて計算される。例えば、マッピング・システム５８０は、ユーザーのエンド・エフェクターの位置を受け取り、ビデオゲームのリアル・タイム実行中にそれをしかるべきアバターのエンド・エフェクターにマッピングし直すように構成することができる。例えば、一実施形態では、アバターは、ルート・ノードを有することができ、このアバターのルート・ノードとユーザー・モデルのルート・ノードとを用いて、関係を作ることができる。この関係を用いて、ユーザーのエンド・エフェクターの位置から、アバターのエンド・エフェクターの位置を計算することができる。他の実施形態では、他のノードの位置を用いて、アバターのエンド・エフェクターの位置を決定することができる。例えば、エンド・エフェクターの親ノードおよび祖父母ノードに(grandparent node)ついての位置情報を入手することができ、対応する親ノードと祖父ノードとの間における関係を作ることができる。この関係を用いて、アバターのエンド・エフェクターの位置を、ユーザーのエンド・エフェクターの位置から計算することができる。
【０１０７】
[0105]  動作１２１０に移ると、ユーザーのエンド・エフェクターについての位置情報を受け取ることが示されている。後のある時点、例えば、５ｍｓ後に、またはキャプチャー・デバイスが新たな画像を得ることができ、更新されたモデルを形成することができる速度で、カメラはユーザー３０２の画像を取り込むことができ、マッピング・システム５８０は、ユーザーのエンド・エフェクターの更新された位置を特定する情報を受け取ることができる。例えば、ユーザーの３Ｄモデルを、基準点、例えば、ルート・ノードから広がる座標系と共に、メモリーに格納することができる。エンド・エフェクターの第２の位置を追跡することができ、その座標をメモリーに格納することができる。
【０１０８】
[0106]  次に、動作１２１２は、ビデオゲームのリアル・タイム実行中に、アバターのエンド・エフェクターの位置を第２の位置に更新することを示す。アバターのエンド・エフェクターの位置は、ユーザーのエンド・エフェクターについての第２位置情報を用いて計算される。例えば、マッピング・システム５８０は、ユーザーのエンド・エフェクターの更新された位置を受け取り、ビデオゲームのリアル・タイム実行中にしかるべきアバターのエンド・エフェクターの位置を更新するように構成することができる。
【０１０９】
[0107]  動作１２１４は、ビデオゲームのリアル・タイム実行中に、アバター・モデルに解剖学的に可能なポーズを得るために、アバターのノードの位置を判定することを示す。このポーズは、アバターのエンド・エフェクターの更新された位置を維持する。例えば、エンド・エフェクターの更新された位置を、逆運動学システム５９０に供給することができ、システムは、関節、および／またはアニメーターによって直接的に位置付けされなかった任意のエンド・エフェクターというようなアバター・ノードの位置を判定することができる。逆運動学システム５９０は、前述した技法を用いて、アバターのエンド・エフェクターの位置に一致するポーズを、アバター・モデルに決定するように構成することができる。例えば、腕を表すノードを、このノードにおいて可能な２つの動きを定める情報、即ち、蝶番のような屈曲および伸張、ならびに前腕を回す動きを定める情報と関連付けることができる。逆運動学システム５９０は、この情報を用いて、この情報に基づいて有効でありつつ、しかもエンド・エフェクターが所望の位置に達することを可能にする位置を、ノードに形成することができる。このように、この例におけるエンド・エフェクターは、正しい位置に配置されることになるが、アバター・モデルにおける他のノードは、ユーザー・モデルの向きを必ずしも反映しない場合もある。
【０１１０】
[0108]  これより図１３に移ると、動作１３１６から１３２２を含む、図１２の動作手順の代替実施形態が示されている。動作１３１６は、カメラによって、ユーザーの画像を取り込み、ユーザーのエンド・エフェクターを含むユーザー・モデルを形成し、このユーザー・モデルから、ユーザーのエンド・エフェクターの位置情報を判定することを示す。例えば、一実施形態では、キャプチャー・デバイス３０６を用いて画像を取り込むことができる。この例では、ターゲット認識、分析、および追跡システム３００は、画像を取り込み、それを用いてユーザー・モデル６００を形成することができる。ユーザー・モデル６００をメモリーに格納することができ、マッピング・システム５８０を実行させて、エンド・エフェクターの位置を判定することができる。
【０１１１】
[0109]  図１３の説明を続けると、リファインメント(refinement)１３１８は、一実施形態において、アバター・モデルがヒト以外のアバター・モデルを含むことを示す。先に説明したことと同様、一実施形態では、このアバターは、ヒト以外のスケルトン・アーキテクチャーおよび／または異なるノード階層を有することができる。例えば、ヒト以外のアーキテクチャーは、ヒトの同等物とは異なる動きの範囲を有するノードを含むことができ、あるいはこのアーキテクチャーは、ヒトよりも多いまたは少ないノードを有すること、あるいはヒトにおける場合とは異なるやり方で接続されたノードを有することができる。例えば、アバターは、４本の腕と鰭とを有するシー・モンスターであることもできる。この例では、ユーザー・モデル６００上においてユーザーの腕を表すノードを、４本の腕にマッピングすることができ、ユーザーの足にマッピングするノードを、鰭にマッピングすることができる。この例では、ユーザーが彼の足を上げたり下げたりすると、鰭を前後に動かすように、 ユーザーの足のノードをアバターの鰭にマッピングすることができる。
【０１１２】
[0110]  図１３の説明を続けると、動作１３２０は、ユーザーの関節の向きに少なくとも近づけるように、特定のモデルの関節の向きを設定することを含む。このユーザーの関節の向きは、形成されたユーザー・モデルから判定される。例えば、一実施形態では、ユーザー・モデルを形成しメモリーに格納することができる。この例では、ユーザー・モデルは、エンド・エフェクター以外のノードの位置を特定する情報を有してもよい。例えば、エンド・エフェクターが手であってもよく、ユーザー・モデルは、ユーザーの肘およびユーザーの肩を表すノードについての位置情報を有することができる。マッピング・システム５８０を実行することができ、これら追加のノードについての座標を、アバターの位置に変換することができる。
【０１１３】
[0111]  図１３の説明を続けると、動作１３２２は、アバター・モデルからアニメーション・ストリームを形成し、このアニメーション・ストリームを、予め定められているアニメーションと混合することを示す。例えば、一実施形態では、アバター・モデル７００を用いて、アニメーション・ストリームを形成することができる。アニメーターは、追加のエフェクトをアニメーションに加えるために、予め定められているアニメーションをアニメーション・ストリームに追加することができる。例えば、予め定められているアニメーションは、呼吸するアニメーションを含むことができる。アバターをレンダリングしたときに、呼吸しているように見えるように、このアニメーションをアバターと混合することができる。一旦アニメーション・ストリームが完結されたなら、例えば、プリミティブに変換し、グラフィクス・プロセッサーに送ることができる。次いで、グラフィクス・プロセッサーはプリミティブを実行し、アバターをメモリーにレンダリングすることができ、そしてレンダリングされたアバターをモニターに送ることができる。
【０１１４】
[0112]  これより図１４に移ると、動作１４００から１４１０を含む動作手順が示されている。動作１４００はこの手順を開始し、動作１４０２は、画像からユーザー・モデルを生成することを示す。このユーザー・モデルは、ユーザーのエンド・エフェクターを含む。例えば、一実施形態では、図５のターゲット認識、分析、および追跡システム３００は、画像を取り込むために使うことができる。例えば、一実施形態では、ターゲット認識、分析、および追跡システム３００は、画像を取り込み、それを用いてユーザー・モデル６００を生成することができる。ユーザー・モデル６００をメモリーに格納することができ、マッピング・システム５８０を実行して、エンド・エフェクターの位置を判定することができる。
【０１１５】
[0113]  データー構造における各ノードは、例えば、その親の位置からのオフセットとすることができる位置を有することができ、長さ値、垂直角、および水平角を含む。他の実施形態では、各ノードは、空間における地理的座標、例えば、Ｘ値、Ｙ値、およびＺ値を有することができる。この実施形態例では、マッピング・システム５８０は、アニメーターによって選択されたユーザーのエンド・エフェクターの位置を特定する情報を受け取ることができる。例えば、ユーザーの３Ｄモデルを、基準点、例えば、ルート・ノードから広がる座標系と共にメモリーに格納することができる。エンド・エフェクターの位置を追跡することができ、座標をメモリーに格納することができる。
【０１１６】
[0114]  図１４の説明を続けると、動作１４０４は、アプリケーションのランタイム実行中に、ユーザーのエンド・エフェクターをアバター・モデルにマッピングすることを示す。例えば、マッピング・システム５８０は、ユーザーのエンド・エフェクターの位置を受け取り、アプリケーション５６０のリアル・タイム実行中に、それらをアバターのエンド・エフェクターにマッピングし直すように構成することができる。例えば、一実施形態では、アバター・モデル７００がルート・ノードを有することができ、アバターのルート・ノードとユーザー・モデルのルート・ノードとを用いて、関係を作ることができる。この関係を用いて、図５および図６に関して先に説明したのと同様に、ユーザーのエンド・エフェクターの位置から、アバターのエンド・エフェクターの位置を計算することができる。
【０１１７】
[0115]  図１４の説明を続けると、動作１４０６は、アプリケーションのランタイム実行中に、モデルに解剖学的に可能なポーズを得るために、アバターの関節の位置を設定することを示す。例えば、エンド・エフェクターの位置を逆運動学システム５９０に供給することができ、システムは、関節、および／またはアニメーターによって直接的に位置付けされなかった任意のエンド・エフェクターというようなアバター・ノードの位置を判定することができる。逆運動学システム５９０は、前述した技法を用いて、アバターのエンド・エフェクターの位置に一致するポーズを、アバター・モデルに決定するように構成することができる。逆運動学システム５９０は、この情報を用いて、この情報に基づいて有効でありつつ、しかもエンド・エフェクターが所望の位置に達することを可能にする位置を、ノードに形成することができる。このように、この例におけるエンド・エフェクターは、正しい位置に配置されることになるが、アバター・モデルにおける他のノードは、ユーザー・モデルの向きを必ずしも反映しない場合もある。
【０１１８】
[0116]  図１４の説明を続けると、動作１４０８は、アプリケーションのランタイム実行中に、アバターのエンド・エフェクターおよびアバターの関節の位置を、ユーザー・モデルに対する変更に基づいて、修正することを示す。例えば、マッピング・システム５８０は、ユーザー・モデルのエンド・エフェクターについての更新された位置情報を受け取るように構成することができ、逆運動学システム５９０は、ユーザー・モデルに対する変更に基づいて、関節について更新された位置を形成するように構成することができる。一実施形態では、ユーザー・モデルは、例えば、５ｍｓ毎に変化することができ、またはキャプチャー・デバイスが新たな画像を得ることができ、更新されたモデルを生成することができる速度で変化することができる。一実施形態では、実行環境１２は、ユーザー・モデルに対する変更に基づいて、アバターを修正するように構成することができる。
【０１１９】
[0117]  これより図１５に移ると、動作１５１０から１５２０を含む動作手順１４００の代替実施形態が示されている。例えば、動作１４１０は、ユーザーの関節の向きに近づけるように、特定のアバターの関節の向きを設定することを示す。このユーザーの関節の向きは、ユーザー・モデルから得られる。例えば、一実施形態では、ユーザー・モデルを生成しメモリーに格納することができる。この例では、ユーザー・モデルは、エンド・エフェクター以外のノードの位置を特定する情報を有することもできる。例えば、エンド・エフェクターが手であってもよく、ユーザー・モデルは、ユーザーの肘およびユーザーの肩を表すノードについての位置情報を有することができる。マッピング・システム５８０を実行することができ、これら追加のノードについての座標を、アバター・モデルの位置に変換することができる。この位置、または複数の位置は、エンド・エフェクターの位置と共に、逆運動学システム１９０に送ることができる。逆運動学システム５９０を実行することができ、他のノードについての位置情報を考慮に入れたポーズをアバターに決定することができる。この例では、エンド・エフェクターを動かす必要なく、エンド・エフェクターを正しく位置付けし、他のいずれのノードの向きとも一致させようとするために、逆運動学システム５９０を優先させることができる。このように、実施形態例の中には、逆運動学システム５９０が、精度高くノードを配置することができるものや、ユーザーの向きに近づけるようにノードを位置付けできるものもある。
【０１２０】
[0118]  図１５の説明を続けると、動作１５１２は、アバター・モデルからアニメーション・ストリームを生成し、このアニメーション・ストリームを、予め定められているアニメーションと混合することを示す。例えば、一実施形態では、アバター・モデルを用いて、アニメーション・ストリームを生成することができる。アニメーターは、追加のエフェクトをアニメーションに加えるために、予め定められているアニメーションをアニメーション・ストリームに追加することができる。例えば、予め定められているアニメーションは、呼吸するアニメーションを含むことができる。アバターをレンダリングしたときに、呼吸しているように見えるように、このアニメーションをアバター・モデルと混合することができる。一旦アニメーション・ストリームが完結されたなら、例えば、プリミティブに変換し、グラフィクス・プロセッサーに送ることができる。次いで、グラフィクス・プロセッサーはプリミティブを実行し、アバターをメモリーにレンダリングすることができ、そしてレンダリングされたアバターをモニターに送ることができる。
【０１２１】
[0119]  動作１５１４に移ると、特定のアバターの関節を特定のユーザーの関節と関連付けないことを決定することが示されている。特定のアバターの関節を特定のユーザーの関節と関連付けないのは、ユーザー・モデルが、その特定のユーザーの関節についての位置情報を含まないときである。動作１５１４は、デフォルト位置に近づくように、特定のアバターの関節の位置を設定することも含む。例えば、一実施形態では、アバター・モデルのデフォルト・ポーズを定める情報、およびアバター・モデルにおける関節についての位置情報を、メモリー・ライブラリー５７０に格納することができる。例えば、アバター・モデルには、「Ｔ」に似たポーズを形成する関節の位置を定める情報と関連付けることができる。また、モデル・ライブラリー５７０は、走行または歩行しているポーズ、あるいはある種の普通の物体を保持しているポーズというような、種々の他のポーズも含むことができる。この例では、逆運動学システム５９０に、エンド・エフェクターの位置、および取り込まれた任意の関節の位置を供給することができる。また、逆運動学システム５９０は、システムに位置情報が欠ける場合、関節のデフォルト位置を定める情報を受け取ることもできる。例えば、右膝が対象の関節となる場合があっても、取り込まれた画像に、右膝についての情報が全くない場合や、何らかの理由で情報が使用できない場合もある。この例では、逆運動学システム５９０がデフォルト位置情報を用いて、デフォルト位置を考慮に入れたアバター・モデルのポーズを生成することができる。
【０１２２】
[0120]  この例では、ユーザー・モデル６００と、モデル・ライブラリー５７０の中にあるモデルとの間の比較に基づいて、マッピング・システム５８０がデフォルト位置を選択することができる。この例では、エンド・エフェクターおよび任意の関節の既知の位置を定める情報を、ライブラリーと比較することができ、最も良く当てはまるデフォルト・モデルを使うことができる。デフォルトの関節位置は、未知のユーザーの関節であればいずれのためにでも、逆運動学システム５９０に送ることができる。
【０１２３】
[0121]  一実施形態例では、逆運動学システム５９０は、アバター・モデルにどのようなポーズを取らせるか決定するために優先度の設定値を使うように構成することができる。例えば、エンド・エフェクターには、これらを最高の優先度として識別する情報と関連付けることができる。この場合、逆運動学システム５９０は、エンド・エフェクターを所望のスポットに当てはめることを優先する。マッピング・システム５８０が情報を有する関節には、エンド・エフェクターの位置よりも低い優先度レベルを設定することができる。この場合、逆運動学システム５９０はユーザー・モデルの関節と少なくとも同様であるがエンド・エフェクターの位置付けに影響を及ぼさない位置に、これらの関節を当てはめようとすることができる。最終的に、情報が受け取られていない関節を当てはめることができる。この場合、逆運動学システム５９０は、これらの関節を当てはめようとするが、いずれのエンド・エフェクターの位置も、システムが位置情報を有するいずれの関節の位置も変化させない。
【０１２４】
[0122]  図１５の説明を続けると、動作１５１６は、アプリケーションによって用いられるアバターのタイプを定める情報を受け取り、アプリケーションの実行中に、アプリケーションによって用いられるアバターのタイプを定める情報に基づいて、アバター・モデルのライブラリーからアバター・モデルを選択することを示す。例えば、一実施形態では、アプリケーションを実行するときに、モデルのタイプをモデル・ライブラリー５７０からロードすることができる。この実施形態例では、アプリケーションは、モデル、例えば、ヒト・モデル、馬モデル、龍モデルなどを要求することができる。マッピング・システム５８０は、用いられようとしているモデルのタイプを定める要求を受けることができ、モデル・ライブラリー５７０からそのモデルを選択することができる。
【０１２５】
[0123]  加えて、マッピング・システム５８０は、アプリケーションからそれに与えられたパラメーターに基づいて、アバター・モデルのサイズを変更することができる。例えば、モデルには１つのサイズしかない場合もあり、アプリケーションが、何倍も大きいまたは小さいモデルを要求することもある。この場合、アプリケーションは所望のサイズを指定することができ、マッピング・システム５８０はしかるべくモデルを拡大縮小することができる。
【０１２６】
[0124]  図１５の説明を続けると、動作１５１８は、アバター・モデルのサイズに当てはまるようにユーザーのエンド・エフェクターを関節に結合する相互接続部のサイズを変更することを示す。一実施形態では、マッピング・システム５８０は、ある種の関節をモデルの既知の関節にマッピングする情報を含むことができる。例えば、各モデルは、ユーザーの膝、手首、足首、肘、または他の特定の関節にマッピングするノードを有することができる。これらのノードとユーザー・モデル６００のノードとの間に関係を作ることができる。一旦ユーザー・モデル６００のノードとアバター・モデル７００におけるノードとの間に関係が作られたなら、相互接続部、例えば、骨を形成して、アバター７００における種々のノードを一緒につなぐことができる。マッピング・システム５８０は、ユーザー・モデルのノードの位置を入手し、アバター・モデルのノードの位置を計算することができる。次いで、アバター・モデルのノードを逆運動学システム５９０に供給し、モデルのポーズを生成することができる。
【０１２７】
[0125]  図１５の説明を続けると、動作１５２０は、ユーザーのエンド・エフェクターを、ユーザー・モデルとは異なるスケルトン・アーキテクチャーを有するアバター・モデルにマッピングすることを示す。前述したことと同様、一実施形態では、アバターは、ヒト以外のスケルトン・アーキテクチャーおよび／または異なるノードの階層を有することができる。例えば、ヒト以外のアーキテクチャーは、ヒトの相当部分とは異なる動きの範囲を有するノードを含むことができ、あるいは、このアーキテクチャーは、ヒトにおけるよりも多いまたは少ないノード、あるいはヒトにおけるのとは異なるやり方で接続されたノードを有することができる。
【０１２８】
[0126]  以上の詳細な説明は、例および／または動作図を通して、本システムおよび／またはプロセスの種々の実施形態を明記した。このようなブロック図、および／または例が１つ以上の機能および／または動作を含む限りにおいて、このようなブロック図または例における各機能および／または動作を、広範囲のハードウェア、ソフトウェア、ファームウェア、または事実上そのあらゆる組み合わせによって、個々におよび／または集合的に実現できることは、当業者には言うまでもないことであろう。
【０１２９】
[0127]  本明細書では、本主題の特定の態様について示しそして説明したが、本明細書における教示に基づけば、本明細書において記載した主題から逸脱することなく、種々の変更や修正を行うことができ、そのより広い態様、したがって、添付した特許請求の範囲は、その範囲内に、本明細書において記載した主題の真の主旨および範囲に該当するような変更や修正を全て包含するものとすることは、当業者には明白であろう。
【図１】
0005639646.tif 000011
【図２】
0005639646.tif 000012
【図３】
0005639646.tif 000013
【図４】
0005639646.tif 000014
【図５】
0005639646.tif 000015
【図６】
0005639646.tif 000016
【図７】
0005639646.tif 000017
【図８Ａ】
0005639646.tif 000018
【図８Ｂ】
0005639646.tif 000019
【図９】
0005639646.tif 000020
【図１０】
0005639646.tif 000021
【図１１】
0005639646.tif 000022
【図１２】
0005639646.tif 000023
【図１３】
0005639646.tif 000024
【図１４】
0005639646.tif 000025
【図１５】
0005639646.tif 000026