JP6942300B2 - コンピュータグラフィックスのプログラム、表示装置、送信装置、受信装置、動画生成装置、データ変換装置、データ生成装置、情報処理方法及び情報処理システム - Google Patents

Description

本発明は、３次元コンピュータグラフィックスに関するプログラム、表示装置、送信装置、受信装置、動画生成装置、データ変換装置、データ生成装置、情報処理方法及び情報処理システムに関する。

近年、ハードウェアの高性能化に伴って、３次元コンピュータグラフィックス（３ＤＣＧ（Three Dimensional Computer Graphics）、単にＣＧ（Computer Graphics）などともいう）が盛んに利用されるようになってきている。また、３ＤＣＧでキャラクタ（ＣＧモデル）を表現するために、様々なデータ構造が提案されている。例えば、人間などの複雑な骨格構造を持つキャラクタに適したデータ構造が提案されている（例えば、特許文献１及び２）。このようなＣＧモデル及びデータ構造を用いて、ＣＧのアニメーション動画を作成することができる。

特許第３３３７９３８号公報 特許第３３８０１５８号公報

ＣＧモデルの動き（モーション）は、モーションキャプチャと呼ばれるシステムを用いて、現実世界の人や動物などの動きをデジタル化してコンピュータに取り込むことで作成できる。また、コンピュータ上でアプリケーションを用いてＣＧモデルのモーションを作成することも行われている。

しかしながら、ＣＧモデルのモーションを、音データ（例えば、楽曲データ、音声データなど）と同期させることは未だに困難である。例えば、ＣＧモデルが楽曲に合わせて踊るモーションを作成することを考えると、モーションキャプチャシステムを用いる場合には、キャプチャ対象（例えば、人）として優れたダンサーを採用しなければならず、気軽に作成できない。また、優れたダンサーであっても、微妙に楽曲と踊りのずれが生じる場合がある。

一方、アプリケーションを用いる場合であっても、アプリケーションの操作者（ユーザ）は踊りの振り付けに詳しいことが求められる。さらに、踊りの振り付けに詳しいとしても、従来のアプリケーションでは動きを音データに同期させるための微妙な調整が必要であり、完全に音データとモーションを同期させることは難しい。

本発明は、かかる点に鑑みてなされたものであり、ＣＧモデルの動作を音データと容易に同期させることができるプログラム、表示装置、送信装置、受信装置、動画生成装置、データ変換装置、データ生成装置、情報処理方法及び情報処理システムを提供することを目的の１つとする。

本発明の一態様に係るプログラムは、コンピュータに、２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを取得する手順と、前記第１の時系列情報に基づいて、前記ＣＧモデルの表示を行う手順と、を実行させるためのプログラムである。

本発明によれば、ＣＧモデルの動作を音データと容易に同期させることができる。

本発明の一実施形態に係る情報処理システムの概略構成の一例を示す図である。 本発明の一実施形態に係るユーザ端末の機能構成の一例を示す図である。 骨格構造（多関節構造）を有するスケルトンモデルの一例を示す図である。 ノートオン信号の概念説明図である。 本発明におけるデータ構造における各チャンネルのノートオン信号と、所定の構成要素との対応関係の一例を示す図である。 本発明に係るコリオデータフォーマットに準拠する具体的なデータ例を示す図である。 コリオデータフォーマットに従うモーションデータの作成フローの一例を示す図である。 図７のステップＳ１２及びＳ１３の概念説明図である。 １拍の中における典型的な角度変化のパターンの一例を示す図である。 １拍の中における各８分の１拍を抽出する一例を示す図である。 コリオデータフォーマットに準拠したモーションデータを用いてＣＧモデルを表示する場合のフローの一例を示す図である。 保存されたコリオデータを再生する場合の一例を示す図である。 リアルタイムでコリオデータを再生する場合の一例を示す図である。 加速度パラメータの算出例の一例を示す図である。 コリオデータフォーマットにおける加速度パラメータの格納方法の一例を示す図である。 加速度パラメータを用いる場合の角度変化の再現度の説明図である。 時間経過による角度変化と、各時間に対応する加速度パラメータの変化の一例を示す図である。 最高速を考慮した拍とフレームの対応付けの一例を示す図である。 基本となるＢＰＭにおける角度及び速度の時系列データを示す図である。 図１９の時系列データのＢＰＭを、半分にした場合の角度及び速度の時系列データを示す図である。 図１９の時系列データのＢＰＭを、２倍にした場合の角度及び速度の時系列データを示す図である。 コリオデータフォーマットとして保存されたムーブを活用してダンスＣＧ動画を作成するフローの一例を示す図である。 編集画面の一例を示す図である。 楽曲に合わせたダンスの振り付けを作成できるソフトウェア（アプリケーション）のビジネスモデルの概念説明図である。 コリオデータとして保存されたムーブを活用してダンスＣＧ動画を作成するフローの別の一例を示す図である。 編集画面の別の一例を示す図である。 パレット編集画面の一例を示す図である。 編集画面の別の一例（ステップモード）を示す図である。 関節角度の異なる２拍のモーションを２つ接続する場合の一例を示す図である。 アクションのモーションデータが上半身のみに関する情報を含む場合における、アクションとステップのブレンドの一例を示す図である。 ユーザの入力が、所望のタイミングより遅い場合の一例を示す図である。 ユーザの入力が、所望のタイミングより早い場合の一例を示す図である。 本発明で想定されるモーションデータの一例を示す図である。 ユーザの入力が、所望のタイミングより遅い場合の別の一例を示す図である。 ユーザの入力が、所望のタイミングより早い場合の別の一例を示す図である。

ＣＧのアニメーション動画の従来の作成に関する問題について、より具体的に説明する。従来、コンピュータ上でのＣＧ動画の作成は、フレーム（動画を構成する静止画）単位で行われている。一般的なＣＧ動画は、単位時間あたりのフレーム数（例えば、ＦＰＳ（Frames Per Second））を固定して作成される。

したがって、ＣＧモデルのモーションを、所定のコンテンツ（例えば、楽曲、音声などの音データ）と同期させたい場合には、ユーザ自らが当該コンテンツの再生時間の長さを考慮して各フレームの動きを細かく調整しなければならない。特に、ライブ演奏などリアルタイム性の高いコンテンツにダンスＣＧを同期させる場合、演奏の微妙なテンポの変化に同期させることが難しく、ずれが生じてしまうという問題があった。

上述の問題を解決するため、本発明者らは、音データと同期が容易にできるＣＧモデルの動きデータ（モーションデータ）のデータ構造を検討した。この結果、ＣＧモデルの動きをテンポベースで時系列に指定する新たなデータ構造を着想し、本発明に至った。具体的には、本発明の一態様によるデータ構造によれば、フレーム単位や実時間単位ではなく、テンポに応じて実際の時間の長さが変化する拍単位（ビート単位）でＣＧモデルのモーションデータを構成することができる。これにより、ＣＧモデルの動作にかかる時間を、音データと同期させるように、容易に調整することができる。

また、本発明に係るデータ構造に基づいたデータを組み合わせると、拍単位でＣＧモデルの動作を指定できるため、従来のようなフレーム単位でＣＧモデルのポーズを１つ１つ入力する方法に比べて、楽曲などのテンポに同期したＣＧ動画を作成することが容易になる。また、音データに限らず、音声その他のコンテンツにも、ＣＧモデルの動作を容易に同期させることができる。

なお、本発明に係る上記データ構造は、振り付け（choreography）データフォーマット、コリオデータフォーマットなどと呼ばれてもよい。また、コリオデータフォーマットで表現されるデータ、コリオデータフォーマットに準拠するデータ（例えば、コリオデータフォーマットに変換可能なフレーム単位の時系列データを含む）などのコリオデータフォーマットと互換性のあるデータは、コリオデータ、ダンスコリオデータなどと呼ばれてもよい。

一方、単にいろいろな動作を組み合わせただけでは、不自然なＣＧ動画になってしまうことがある。例えば、ＣＧモデルを踊らせる動画を作成する場合には、ダンスの振り付けを理解したユーザでなければ、ダンスらしく見える動画の作成は非常に困難である。

そこで、本発明者らはさらに、振り付けに不慣れなユーザであっても、簡単にＣＧキャラクタにダンスらしい振り付けを行わせることについて検討し、フレームごとのポーズではなく、一定の時間ごとの「流れ」が重要であることに着眼した。また、この「流れ」は、多くのダンスにおいては、以下の（１）〜（３）の要素で構成されていることを発見した：
（１）「エイト」（８拍）単位で振り付けがまとめられる、
（２）一定の「型」がある、
（３）「型」をつなげ、変化をつけることでダンスが完成する。

具体的に各要素を説明する。要素（１）については、８拍単位（ワンエイト）や、８拍×４の３２拍単位（フォーエイト）で振り付けが作成されることが多い。要素（２）については、ダンスのジャンルごとに、いわゆる「ムーブ」と呼ばれる基本型（ベーシックムーブともいう）がある。要素（３）については、ダンスは基本的にムーブの連続であり、ムーブに腕の振りなどのバリエーション（バリエーションムーブともいう）をつけたり、ムーブが変わるときのターンなどのアクセント（アクセントモーションともいう）をつけたりすることでダンスが完成するということである。

本発明者らは、これらの着眼点に基づいて、「流れ」を考慮したコリオデータを用いることで、音データと同期してＣＧモデルにダンスらしいダンスをさせる方法を見出した。具体的には、本発明の一態様に係るアプリケーションによれば、コリオデータを利用してエイト単位でムーブを設定することにより、ＣＧ動画の作成やダンスの振り付けに不慣れなユーザであっても、ＣＧのダンス動画を容易に編集及び作成することができる。

以下、本発明に係る実施形態について、添付図面を参照して詳細に説明する。

＜情報処理システム＞
まず、本発明が適用される情報処理システムについて説明する。図１は、本発明の一実施形態に係る情報処理システムの概略構成の一例を示す図である。図１に示す情報処理システム１は、ユーザ端末１０と、サーバ２０と、電子楽器３０と、ネットワーク４０と、を含む。

ユーザ端末１０、サーバ２０及び電子楽器３０は、ネットワーク４０を介して相互に接続可能であり、コリオデータを用いて、ＣＧモデルに関する処理（送受信、変換、動画生成、表示など）を行う。

ユーザ端末１０は、携帯電話、スマートフォン、タブレット型端末などの携帯端末（移動通信端末）であってもよいし、パソコン、多機能テレビ、セットトップボックス（例えば、Apple TV（登録商標）、Chromecast（登録商標））などの固定通信端末であってもよい。

サーバ２０は、ユーザ端末１０及び／又は電子楽器３０との間でコリオデータを送信及び／又は受信する機能を有する装置である。なお、当該コリオデータの送受信は、ユーザ端末１０及び／又は電子楽器３０からの要求により行われてもよいし、周期的又は所定のタイミングで行われてもよい。また、サーバ２０は、コリオデータを用いて生成したデータ（例えば、動画など）を、ユーザ端末１０及び／又は電子楽器３０との間で送受信してもよい。

電子楽器３０は、ＭＩＤＩ（Musical Instrument Digital Interface）データ等の演奏情報に応じた音を発生する機能を有する装置である。例えば、電子楽器３０は、電子ピアノ、シンセサイザーなどであるが、これに限られない。

ネットワーク４０は、機器間を接続し情報の通信を可能とする。例えば、ネットワーク４０は、インターネット、モバイルネットワーク、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などの様々なネットワークを含む。なお、ネットワーク４０は、無線で構成されてもよいし、有線で構成されてもよい。

なお、当該システム構成は一例であり、これに限られない。例えば、ユーザ端末１０、サーバ２０及び電子楽器３０は、図１ではそれぞれ複数含まれる構成としたが、各機器の数はこれに限られない。また、情報処理システム１は、ユーザ端末１０、サーバ２０及び電子楽器３０の一部を含まない構成であってもよい。また、ネットワーク４０に接続していないユーザ端末１０などであっても、所定の記憶媒体を接続することで、当該記憶媒体を介してコリオデータの入出力を行ってもよい。

図２は、本発明の一実施形態に係るユーザ端末の機能構成の一例を示す図である。図２に示すように、ユーザ端末１０は、送受信部１１と、取得部１２と、再生部１３と、出力部１４と、入力部１５と、生成部１６と、制御部１７と、を有する。ユーザ端末１０は、本発明に係るデータ構造を用いてＣＧモデルに関する情報処理を行う工程を有する情報処理方法を実現する。また、ユーザ端末１０は、本発明に係る情報処理装置として、表示装置、送信装置、受信装置、動画生成装置、データ変換装置、データ生成装置などを構成することができる。

なお、図２では、本実施形態における特徴部分の機能ブロックを主に示しており、ユーザ端末１０は、他の処理に必要な他の機能ブロックも有してもよい。また、サーバ２０や、電子楽器３０も、図２に示す機能ブロックの全部又は一部を有してもよく、ユーザ端末１０と同様に本発明に係る情報処理装置（表示装置、送信装置、受信装置、動画生成装置、データ変換装置、データ生成装置など）を構成してもよい。

送受信部１１は、ネットワーク４０を介して、他のユーザ端末１０、サーバ２０、電子楽器３０との間で、コリオデータや必要な情報などの送受信を行う。送受信部１１は、受信したコリオデータを、取得部１２に出力する。また、送受信部１１は、受信した所定のデータ（例えば、ＣＧモデルのモーションデータ）を、生成部１６に出力してもよい。また、送受信部１１は、受信した種々の情報を制御部１７に出力する。送受信部１１は、本発明に係る技術分野での共通認識に基づいて説明されるトランスミッター／レシーバー、送受信回路又は送受信装置により構成することができる。なお、送受信部１１は、送信部１１１及び受信部１１２から構成されてもよい。

取得部１２は、送受信部１１及び／又は生成部１６からコリオデータを取得する。取得部１２は、取得したコリオデータを、送受信部１１及び／又は再生部１３に出力する。

再生部１３は、取得部１２から入力されたデータの再生を行って、出力部１４に出力する。例えば、コリオデータを解釈して、ＣＧ動画の再生に係る信号を出力部１４に出力する。また、所定のコンテンツ（例えば、楽曲、音声などの音データ）の再生を行って、出力部１４に出力してもよい。例えば、コンテンツが音データであれば、コンテンツに係る音声ファイルフォーマットに従って、出力部１４が認識できる形式で再生用信号に変換する。再生部１３は、本発明に係る技術分野での共通認識に基づいて説明されるプレイヤー、画像／映像／音声処理回路、画像／映像／音声処理装置、アンプなどにより構成することができる。

出力部１４は、再生部１３から入力されたコンテンツの再生信号の出力を行う。出力部１４は、複数の機能部から構成されてもよい。例えば、出力部１４は、視覚的なデータ（例えば、ＣＧ動画）を表示する表示部と、音データを出力する音声出力部と、から構成されてもよい。表示部は、本発明に係る技術分野での共通認識に基づいて説明されるディスプレイ、モニタなどの表示装置により構成することができる。また、音声出力部は、本発明に係る技術分野での共通認識に基づいて説明されるスピーカーなどの出力装置により構成することができる。

入力部１５は、ユーザからの操作により、ユーザ端末１０に対する入力を受け付け、入力結果を制御部１７に出力する。入力部１５は、本発明に係る技術分野での共通認識に基づいて説明されるキーボード、マウスなどの入力装置により構成することができる。また、入力部１５は、表示部と一体となった構成（例えば、タッチパネル）としてもよい。

また、入力部１５は、所定の機器や記憶媒体と接続され、データの入力を受け付けてもよい。当該入力結果は、制御部１７や、生成部１６に出力される。この場合、入力部１５は、本発明に係る技術分野での共通認識に基づいて説明される入出力端子、入出力回路などを含んで構成することができる。

生成部１６は、送受信部１１、入力部１５などから入力されたデータを用いて、コリオデータを生成する。生成したコリオデータは、送受信部１１や取得部１２に出力される。生成部１６は、本発明に係る技術分野での共通認識に基づいて説明される演算器、演算回路、演算装置などにより構成することができる。

制御部１７は、ユーザ端末１０全体の制御を実施する。例えば、制御部１７は、取得部１２がコリオデータを取得したり、出力したりするタイミングを制御してもよい。また、制御部１７は、生成部１６が生成したコリオデータをユーザ端末１０に保存するように制御してもよい。制御部１７は、本発明に係る技術分野での共通認識に基づいて説明されるコントローラ、制御回路又は制御装置により構成することができる。

以下に、より具体的な本発明に係る情報処理装置の一例を示す。ここでは、図２で示した機能ブロックを用いて構成の説明を行う。

本発明の一実施形態に係る表示装置は、取得部１２と、再生部１３と、出力部１４と、制御部１７と、を有する。当該表示装置によれば、例えば、再生部１３で再生され出力部１４から出力される楽曲に同期するように、再生部１３がコリオデータを用いてＣＧ動画の再生を行って出力部１４を介して表示することができる。なお、本発明の一実施形態に係る表示装置の表示部は、再生部１３及び出力部１４で構成することができる。

本発明の一実施形態に係る送信装置は、送信部１１１と、取得部１２と、制御部１７と、を有する。本発明の一実施形態に係る受信装置は、受信部１１２と、取得部１２と、制御部１７と、を有する。当該送信装置又は受信装置によれば、コリオデータを含む信号を送信又は受信することができ、コリオデータのやり取りを容易に行うことができる。

本発明の一実施形態に係る動画生成装置は、取得部１２と、再生部１３と、制御部１７と、を有する。当該動画生成装置によれば、コリオデータを用いて音データと同期がとれたＣＧ動画を生成することができるため、コリオデータを利用できない装置でも当該ＣＧ動画を再生することが可能となる。なお、本発明の一実施形態に係る動画生成装置の生成部は、再生部１３で構成することができる。

本発明の一実施形態に係るデータ変換装置は、取得部１２と、生成部１６と、制御部１７と、を有する。当該データ変換装置によれば、既存のモーションデータ（例えばモーションキャプチャシステムにより取得されたデータ）などを、コリオデータに変換することができ、コリオデータの作成を容易に行うことができる。なお、本発明の一実施形態に係るデータ変換装置の検出部、抽出部及び選択部は、生成部１６で構成することができる。

本発明の一実施形態に係るデータ生成装置は、取得部１２と、再生部１３と、出力部１４と、入力部１５と、生成部１６と、制御部１７と、を有する。当該データ生成装置によれば、例えば制御部１７がアプリケーションを実行し、入力部１５がユーザの入力を受け付け、当該入力に応じて制御部１７が各機能ブロック（再生部１３、出力部１４など）を制御することで、コリオデータの組み合わせから新たなコリオデータや、ＣＧ動画を生成することが可能となる。なお、本発明の一実施形態に係るデータ生成装置の選択部は、入力部１５及び／又は制御部１７で構成することができる。

なお、上記実施形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及びソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的に結合した１つの装置により実現されてもよいし、物理的に分離した２つ以上の装置を有線又は無線で接続し、これら複数の装置により実現されてもよい。

例えば、ユーザ端末１０やサーバ２０の各機能の一部又は全ては、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを用いて実現されても良い。また、ユーザ端末１０やサーバ２０は、プロセッサ（ＣＰＵ：Central Processing Unit）と、ネットワーク接続用の通信インターフェースと、メモリと、プログラムを保持したコンピュータ読み取り可能な記憶媒体と、を含むコンピュータ装置によって実現されてもよい。つまり、本発明の一実施形態に係るユーザ端末、サーバなどは、本発明に係るデータ構造（コリオデータ）を用いてＣＧモデルに関する処理を行うコンピュータとして機能してもよい。

ここで、プロセッサやメモリなどは情報を通信するためのバスで接続される。また、コンピュータ読み取り可能な記録媒体は、例えば、フレキシブルディスク、光磁気ディスク、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＣＤ−ＲＯＭ（Compact Disc−ＲＯＭ）、ＲＡＭ（Random Access Memory）、ハードディスクなどの記憶媒体である。また、プログラムは、電気通信回線を介してネットワーク４０から送信されても良い。

ユーザ端末１０やサーバ２０の機能構成は、上述のハードウェアによって実現されてもよいし、プロセッサによって実行されるソフトウェアモジュールによって実現されてもよいし、両者の組み合わせによって実現されてもよい。プロセッサは、オペレーティングシステムを動作させてユーザ端末の全体を制御する。また、プロセッサは、記憶媒体からプログラム、ソフトウェアモジュールやデータをメモリに読み出し、これらに従って各種の処理を実行する。

ここで、当該プログラムは、本発明に係るデータ構造を用いたＣＧモデルに関する情報処理を、コンピュータに実行させるプログラムであれば良い。例えば、ユーザ端末１０の制御部１７は、メモリに格納され、プロセッサで動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。

本発明においては、上述したような各装置がコリオデータを利用する。以下では、まずコリオデータフォーマットについて説明し、その後コリオデータの生成及び当該コリオデータを用いたＣＧ動画の作成について説明する。

＜コリオデータフォーマット＞
本発明に係るコリオデータフォーマットは、ＣＧモデルの構成要素の座標を、拍単位で時系列に指定するための時系列情報を含むデータのフォーマットである。なお、「拍単位」とは、「拍」で特定可能な単位であることをいい、１拍単位に限られず、８分の１拍単位などの分数拍単位や、２拍単位などの複数拍単位も含む。

上述のように、本発明者らは、音データと同期が容易にできるＣＧモデルの動きデータを検討した。動きの再現性やデータ量、他システムとの連携などを鑑みた結果、本発明者らは、電子楽器の演奏情報の保存形式が、拍単位でのデータ構造の表現に好適であることを見出し、本発明に係るコリオデータフォーマットに至った。

具体的なフォーマットの説明の前に、まずＣＧモデルの表現方法について説明する。本明細書では、骨格構造（多関節構造）を有するスケルトンモデルをＣＧモデルとして用いる場合を例に説明するが、本発明を適用可能なＣＧモデルはこれに限られるものではない。

図３は、骨格構造（多関節構造）を有するスケルトンモデルの一例を示す図である。図３Ａは、スケルトンモデルの各構成要素及び基準姿勢を示し、図３Ｂは、スケルトンモデルの構成要素間の関係を示す。なお、図３に示す例は基本的な構成であり、さらに追加の構造（例えば、皮膚、指、毛髪、衣装、帽子、ステッキなど）を有していてもよい。

図３Ａに示すモデルは、複数の骨格から構成されており、各骨格は２つの間接点及びこれらをつなぐ骨（ボーン）から構成されている。図３Ａの「Ｎ」、「ＲＳ」などは骨の名称であり、この例では１８本の骨が示されている。

一般的にスケルトンモデルは、ある間接点を基準点（ルート）として、各間接点を介して接続される骨が階層構造を有するように構成されている。例えば、図３Ａの階層構造は図３Ｂのように表される。図３の場合、Ｂ１及びＷの間の間接点がルートである。また、間接点や骨を比較する際、ルートに近い方を親といい、ルートから遠い方を子という。

ＣＧモデルを３次元空間に配置する際は、当該モデルを、ルートの位置を基準とした当該モデル用の座標系（ローカル座標系）上にモデリングする。そして、３次元空間全体を表す座標系（ワールド座標系、グローバル座標系）に、モデリングされたＣＧモデルをマッピングする。

構成要素（間接点、骨など）の座標は、３次元空間の絶対座標又は相対座標として表されてもよいし、所定の間接点を基準とした所定の骨の相対角度として表されてもよい。例えば、骨の相対角度で座標を表現する場合、ＣＧモデルの基準姿勢を図３ＡのようなＴ字姿勢とし、当該姿勢時の各骨の角度を０°としてもよい。

なお、階層構造やルートの位置は図３の例に限られない。例えば、ルートの位置は両足の間（ＲＦ３とＬＦ３との間）であってもよい。また、各構成要素の座標及び／又は角度は、ルートから末端にかけて順番に計算するフォワードキネマティクスを用いて算出してもよいし、子の位置から親の位置を逆計算するインバースキネマティクスを用いて算出してもよいし、両者の組み合わせ又はその他の方法を用いてもよい。また、骨格構造においては、上記の階層構造だけでなく、階層構造の初期状態や、各骨の長さや、各関節の可動範囲などが設定されてもよい。

＜ＳＭＦフォーマットとコリオデータフォーマット＞
上述のように、本発明の一態様におけるコリオデータフォーマットは、電子楽器の演奏情報の保存形式に準拠することが好ましい。特に、広く普及しているＭＩＤＩデータの保存形式が好適である。次に、ＭＩＤＩデータの保存形式の１つであるＳＭＦ（Standard MIDI File）フォーマットの概略を説明し、ＳＭＦフォーマットに準拠するコリオデータフォーマットを説明する。

ＳＭＦフォーマットは、所定の制御情報を含むヘッダチャンクと、演奏データを含むトラックチャンクから構成される。演奏データは、デルタタイム及びＭＩＤＩイベントの組み合わせで構成される。ここで、デルタタイムは次のＭＩＤＩイベントが起こるまでの時間を表す。また、ＭＩＤＩイベントは演奏内容を表すものであり、例えば、ノートオン（音を出す）、ノートオフ（音を止める）などがある。

ノートオン信号は、対応するデルタタイムの経過後に特定の音を出すという信号である。ノートオン信号は、例えば、１６進数で「9n kk vv」という３ｂｙｔｅで表現でき、これは「チャンネルnでノート番号kkの音をベロシティvvで発音する」ということを意味する。図４は、ノートオン信号の概念説明図である。図４に示すように、チャンネルは楽譜におけるパート（所定の楽器の演奏パート）、ノート番号は音の高さ、ベロシティは楽器（鍵盤）を叩く速度（強さ）を表す。

ノートオフ信号は、対応するデルタタイムの経過後に特定の音を消すという信号である。ノートオフ信号は、例えば、１６進数で「8n kk vv」という３ｂｙｔｅで表現でき、これは「チャンネルnでノート番号kkの音をベロシティvvで消音する」ということを意味する。

ノート番号及びベロシティはいずれも１０進数で０〜１２７の数値を取ることができる。なお、ベロシティが０のノートオン信号「9n kk 00」は、「チャンネルnでノート番号kkの音を消音する」というノートオフ信号と同じ意味を表す。

図４におけるチャンネル０及び１に示される４分音符に対応するノートオン信号は、それぞれ「90 3E 04」及び「91 3C 02」のように表すことができる。

本発明の一態様においては、各チャンネルを、それぞれＣＧモデルのいずれかの構成要素の座標に関する情報として扱う。つまり、コリオデータフォーマットは、ＣＧモデルの構成要素の座標に関する拍単位の時系列情報を、複数含んで構成されてもよい。ここで、構成要素（例えば、骨、間接点など）の座標に関する情報とは、例えば、構成要素の絶対座標又は相対座標に関する情報であってもよいし、構成要素（例えば、骨）の相対角度として表されてもよい。

ＣＧモデルの構成要素の座標に関する情報としては、ノートオン信号のノート番号及び／又はベロシティを用いることができる。この場合、あるタイミングにおいて、所定の構成要素の特定の軸の角度及び／又は座標は、当該タイミングに対応する拍に配置されたノートオン信号から取得することができる。また、ノートオン信号及び／又はノートオフ信号のデルタタイムは、ＣＧモデルの構成要素の座標が変化する拍の長さに関する情報として用いられてもよい。

例えば、ノートオフ信号に対応するデルタタイムは、当該ノートオフ信号の直前のノートオン信号から算出される角度（又は座標）から、当該ノートオフ信号の直後のノートオン信号から算出される角度（又は座標）に遷移するのにかかる拍の長さを示してもよい。各ノートに関連付けられた所定の構成要素の角度及び／又は座標の遷移は、所定の規則に従って行われてもよい。例えば、所定の補間方法に基づいて、遷移中の速度や加速度を決定して用いてもよい（後述）。なお、デルタタイムは、正数であることが好ましい。

ノートオン／オフ信号はＳＭＦフォーマットで最も頻繁に用いられる信号であるため、ＭＩＤＩに対応した電子楽器などにおいて、処理を高速に行うことが可能である。

ノートオン信号においては、ノート番号により、比較的大きな単位で座標又は角度を大まかに特定し、ベロシティにより、比較的小さな単位で座標又は角度を詳細に特定してもよい。例えば、あるチャンネルにおけるノートオン信号が特定の軸方向の角度（例えば、ｘ軸相対角度）を示す場合には、以下の式１で当該角度θを算出してもよい。

（式１）
θ＝（Ｎ−Ｎ_０）×θ_Ｎ＋（Ｖ−Ｖ_０）×θ_Ｖ
ここで、Ｎはノート番号、Ｎ_０は基準とするノート番号、θ_Ｎはノート番号増分あたりの角度増加量、Ｖはベロシティ、Ｖ_０は基準とするベロシティ、θ_Ｖはベロシティ増分あたりの角度増加量である。

例えば、Ｎ_０は６０（鍵盤の中央の「Ｃ（ド）」音に対応）、Ｖ_０は１、θ_Ｎは５°、θ_Ｖは０．０５°としてもよい。なお、Ｎ_０、Ｖ_０、θ_Ｎ、θ_Ｖなどは上記の値に限られない。

また、あるチャンネルにおけるノートオン信号が特定の軸方向の座標を示す場合には、以下の式２で当該座標位置Ｐを算出してもよい。

（式２）
Ｐ＝（Ｎ−Ｎ_０）×Ｐ_Ｎ＋（Ｖ−Ｖ_０）×Ｐ_Ｖ
ここで、Ｎはノート番号、Ｎ_０は基準とするノート番号、Ｐ_Ｎはノート番号増分あたりの座標増加量、Ｖはベロシティ、Ｖ_０は基準とするベロシティ、Ｐ_Ｖはベロシティ増分あたりの座標増加量である。

例えば、Ｎ_０は６０（鍵盤の中央の「Ｃ（ド）」音に対応）、Ｖ_０は１、Ｐ_Ｎは６４ｃｍ、Ｐ_Ｖは０．５ｃｍとしてもよい。また、Ｐ_Ｎは１２７ｃｍ、θ_Ｖは１ｃｍとしてもよい。なお、Ｎ_０、Ｖ_０、Ｐ_Ｎ、Ｐ_Ｖなどは上記の値に限られない。

また、上記とは逆に、ベロシティにより、比較的大きな単位で座標又は角度を大まかに特定し、ノート番号により、比較的小さな単位で座標又は角度を詳細に特定する構成としてもよい。さらに、システムエクスクルーシブイベントなど、ノートオン／オフ以外の信号を用いてＣＧモデルの構成要素の座標に関する情報が特定されてもよい。

構成要素の座標に関する情報は、例えば、ポジション情報及びポーズ情報に分類することができる。ポジション情報は、ＣＧモデルの初期位置（例えば、ＣＧ動画の開始時における位置）からの相対位置を示す情報であり、例えばＣＧモデルの基準点（ルート）のｘ軸座標、ｙ軸座標、ｚ軸座標及び当該基準点の回転角度で表されてもよい。また、ポーズ情報は、ＣＧモデルの基準姿勢に基づく角度又は位置を示す情報であり、例えば図３ＡのようなＴ字姿勢を０°とし、いくつかの数の指定ボーンに関して、親骨と子骨との間のｘ軸相対角度、ｙ軸相対角度及びｚ軸相対角度で表されてもよい。

各構成要素（例えば、骨）の各座標に関する情報を、いずれのチャンネルに割り当てるかは、システムの運用形態などに応じて適宜選択することができる。１チャンネルにつき１つの構成要素の座標に関する情報を割り当てる場合、ＣＧモデルを表現するのに必要なチャンネル数は、指定ボーン数を１８とすると計５８チャンネルである。具体的には、ポーズ情報のために１８（ボーン数）×３（軸数）＝５４（チャンネル）が必要となり、ポジション情報のために３（ポジション座標）＋１（ポジション基準角度）＝４（チャンネル）が必要となる。ＭＩＤＩポートは１６チャンネルを含むことができるため、４ＭＩＤＩポートあれば、ボーン数１８から成るＣＧモデルの座標及び姿勢を表現することができる。なお、ＣＧモデルの表情や指先などを表現する場合には、さらに追加でチャンネルが必要になるため、必要なＭＩＤＩポート数も増加する。

一方、１チャンネルにつき構成要素の座標に関する情報を複数割り当ててもよい。例えば、１チャンネルで、所定の骨のｘ軸相対角度、ｙ軸相対角度及びｚ軸相対角度を表現するように構成することができる。この場合、例えば、ノート番号を３分割して、比較的小さなノート番号（例えば、０〜４２）をｘ軸相対角度、比較的中間のノート番号（例えば、４３〜８５）をｙ軸相対角度、比較的大きなノート番号（例えば、８６〜１２７）をｚ軸相対角度として用いてもよい。なお、割り当て方法はこれに限られない。

また、コリオデータフォーマットが準拠するＳＭＦフォーマットは、特に制限されない。例えば、１トラックに全チャンネルの情報を含むフォーマット０であってもよいし、複数トラックで構成されるフォーマット１であってもよいし、フォーマット２であってもよい。さらに、既存のフォーマット０〜２でない新たなフォーマットを用いてもよい。また、コリオデータフォーマットは、ＣＧモデルの構成要素の座標を拍単位で時系列に指定するための情報を有するものであれば、ＳＭＦフォーマットに限られない。

図５は、本発明におけるデータ構造における各チャンネルのノートオン信号と、所定の構成要素との対応関係の一例を示す図である。上述のように、スケルトンモデルの一実施形態としては、各関節（又は骨）の角度はｘ軸角度、ｙ軸角度及びｚ軸角度の３要素で表現される。図５においては、図３で示した「ＲＡ１」部分の骨のｘ軸角度、ｙ軸角度及びｚ軸角度を示す情報が、それぞれ異なるチャンネルに割り当てられている。なお、図５のｘ軸角度、ｙ軸角度及びｚ軸角度が示す方向は一例であり、これに限られない。また、図５に示す五線譜の中央の線に対応するノート番号が１０進数で６０であるものとし、式１においてＮ_０を６０、Ｖ_０を１、θ_Ｎを５°、θ_Ｖを０．０５°とする。

図５において、ｘ軸角度に対応するチャンネルのノートオン信号は、ノート番号が１０進数で７０、ベロシティが１である。したがって、式１によればｘ軸角度は＋５０°となる。また、ｙ軸角度に対応するチャンネルのノートオン信号は、ノート番号が６２、ベロシティが３である。したがって、式１によればｙ軸角度は＋１０．１°となる。また、ｚ軸角度に対応するチャンネルのノートオン信号は、ノート番号が６０、ベロシティが１である。したがって、式１によればｚ軸角度は０°となる。

図６は、本発明に係るコリオデータフォーマットに準拠する具体的なデータ例を示す図である。図６では、バイト単位のデータ列と、対応する情報と、が示されている。なお、図６ではデータ列が複数の行に亘って示されているが、実際には連続したデータである。また、図６のコリオデータフォーマットはＳＭＦフォーマット１に準拠するものであるが、これに限られない。

図６の一行目のデータ列は、ＭＩＤＩヘッダに対応している。ここでは四分音符の分解能は４８と設定されている。図６の二行目のデータ列は、コンダクタトラックに対応している。一般的に、テンポはＢＰＭ（Beats Per Minute）単位を用いてコンダクタトラックで指定される。図６ではＢＰＭは１２０に設定されている。図６の三行目及び四行目のデータ列は、通常のトラック（演奏トラック）に対応している。

ノートオン信号１００は、チャンネル０（例えば、ボーンＩＤ ０のｘ軸角度に対応する）においてノート番号３Ｃ、ベロシティ７Ｆの発音開始を指示している。ノートオン信号１００は、対応するノートオフ信号１１０によって終了する。また、ノートオフ信号１１０のデルタタイムは６（８分の１拍に相当）である。このため、ノートオン信号１００によって示される角度から、次のノートオン信号（ノートオン信号１２０）によって示される角度への遷移時間が８分の１拍であることを示している。

また、同じチャンネルの信号が連続する場合には、ランニングステータスを用いて２回目以降のステータスバイトを省略することができる（ノートオン信号１１０、１２０）。ノートオン信号１３０は、別のチャンネル（チャンネル１）に関する情報を含んでいる。また、ノートオフ信号１４０及び１５０は、それぞれノートオン信号１２０及び１３０に対応する。

以上説明したように、本発明に係るコリオデータフォーマットは、例えばＳＭＦフォーマットと互換性を持ち、ＭＩＤＩにおけるチャンネルごとに、ＣＧモデルの構成要素の座標を拍単位で時系列に指定するための時系列情報（ノートオン／オフ信号の繰り返し）を含む。データ構造をＳＭＦフォーマットとすることで、ＣＧモデルの動作と、電子楽器など他の機器又はシステムとの連携が容易になる。

＜コリオデータフォーマットに準拠するモーションデータの生成＞
図７は、コリオデータフォーマットに従うモーションデータの作成フローの一例を示す図である。なお、図７では、コリオデータを、ＣＧモデルの構成要素の座標をフレーム単位で時系列に指定するための時系列情報を含むモーションデータ（フレーム単位のモーションデータ）に基づいて生成する例を示すが、これに限られない。例えば、コリオデータを、ＣＧモデルの構成要素の座標を拍単位で時系列に指定するための時系列情報を含むモーションデータ（拍単位のモーションデータ）に基づいて生成してもよい。

また、図７のフローの実施例として、図２に示した各機能ブロックが行う具体的な処理内容の一例についても説明する。ここではユーザ端末１０における各機能ブロックを例に説明するが、上述のようにサーバ２０なども図２の各機能ブロックを有する場合に同様の処理を行ってもよい。

図７のフローでは、まず、モーションデータを取り込む（ステップＳ１１）。当該モーションデータは、例えばモーションキャプチャシステムにより取得されたデータであってもよいし、３ＤＣＧ対応ソフトウェアから出力されたＣＧデータ（例えば、ｆｂｘ形式、ｖｍｄ形式など）であってもよい。具体的には、ステップＳ１１においては、生成部１６は、送受信部１１が受信したモーションデータ又は入力部１５から入力されたモーションデータを取り込む。

次に、上記モーションデータの抽出に用いるための所定のフレーム周期を特定する（ステップＳ１２）。当該所定のフレーム周期は、所定のテンポ（例えば、ＢＰＭ）に基づいて特定することができる。例えば、当該所定のフレーム周期は、所定のテンポにおけるある拍の長さ（例えば、１拍分、８分の１拍分など）に対応する周期であってもよい。また、当該所定のフレーム周期は、拍の長さに、単位時間あたりのフレーム数（例えば、ＦＰＳ（Frames Per Second））を掛けることで算出できる。

ステップＳ１２において、所定のテンポとは、例えば、モーションデータから検出されたテンポであってもよいし、モーションデータと同期して再生される他のデータ（例えば、楽曲データ）から検出されたテンポであってもよいし、外部から設定された又は予め設定されたテンポであってもよい。

具体的には、ステップＳ１２においては、生成部１６は、ステップＳ１１で取り込んだモーションデータのＦＰＳを算出する。また、生成部１６は、当該ＦＰＳと、コリオデータフォーマットの基準ＢＰＭ（例えば、ＢＰＭ１２０）と、に基づいて、所定のフレーム周期を算出する。

図８は、図７のステップＳ１２及びＳ１３の概念説明図である。図８は、６０ＦＰＳのモーションデータをＢＰＭ１２０における８分の１拍間隔で抽出する場合の一例を示しており、上側（ステップＳ１１で取り込んだモーションデータ）から下側（ステップＳ１３で抽出すべきデータ）を抽出することになる。

この場合、生成部１６は、ＢＰＭ１２０の８分の１拍に対応する秒数を算出し、６０（秒）／１２０（ＢＰＭ）×１／８＝１／１６（秒）を得る。そして、生成部１６は、この拍の長さをフレームの長さに変換し、１／１６（秒）×６０（ＦＰＳ）＝３．７５（フレーム）を得る。つまり、モーションデータを抽出する周期は３．７５フレーム間隔と算出できる。

所定のフレーム周期の特定後、モーションデータに含まれる時系列情報から、当該所定のフレーム周期の各タイミングに対応するデータを抽出する（ステップＳ１３）。データ抽出対象となるタイミングは、モーションデータが含む時系列情報の特定の時間（例えば、最初のフレーム）を基準として算出されてもよい。

データ抽出対象となるタイミングに対応するフレームのデータがモーションデータに含まれる場合には、当該データをそのまま抽出することができる。一方、データ抽出対象となるタイミングに対応するフレームのデータがモーションデータに含まれない場合には、当該タイミングの近傍のフレームのデータに基づいてデータを抽出してもよい。

例えば、図８のようにモーションデータが整数フレームのデータのみを含む場合、３．７５フレーム周期のような非整数のフレーム周期のタイミングに対応するデータがないことがある。ここで、データ抽出対象となるタイミングが非整数のフレーム周期Ｆの倍数に相当する場合を考える。この場合、以下の式３で補間した値を、存在しない仮想フレームｎ（＝Ｆの倍数）に対応するデータＤ_ｎとして扱うことができる。

具体的には、ステップＳ１３においては、生成部１６は、ステップＳ１２で算出したフレーム周期Ｆに基づいて、ステップＳ１１のモーションデータをＦの倍数に相当する各フレームで抽出する。図８の場合、８分の４拍や８分の８拍に対応するフレームは存在するため補間は必要ないが、他の拍（斜線でハッチングされた部分）は式３のような補間を行う必要がある。例えば、仮想フレームｎ＝３．７５では以下の式を用いることができる。
Ｄ_３．７５＝Ｄ_３×０．２５＋Ｄ_４×０．７５

この式によれば、仮想フレームに対応する拍のタイミングの前後フレームのデータを線型補間して、仮想フレームの値とすることができる。なお、非整数のフレーム周期のタイミング（例えば、７．５（＝３．７５×２）フレーム）では、同様の補間を行ってもよい。なお、補間の方法は線型補間に限られない。また、補間に用いられるフレームは前後１フレームに限られず、例えば、前後複数フレームや前複数フレームなどであってもよい。

また、ステップＳ１１で拍単位のモーションデータを取り込んだ場合は、ステップＳ１２及びＳ１３の代わりに、所定の拍周期に対応するデータを抽出するステップを実行してもよい。

次に、抽出した各タイミングに対応するデータについて、ＣＧモデルの構成要素の座標に関する情報を生成する（ステップＳ１４）。あるタイミングに対応するデータにより、特定のポーズが構成されることになる。

より具体的には、ステップＳ１４においては、生成部１６は、抽出した各タイミングに対応するデータについて、以下のステップでポーズ情報を生成する。まず、当該データから、所定の数の指定ボーンを選択する（ステップＳ１４１）。例えば、図３に示したような１８本のボーンを選択してもよいし、他のボーンの組み合わせを選択してもよい。

各指定ボーンについて、相対位置を特定するための３つの相対角度（ｘ、ｙ、ｚ軸角度）を抽出する（ステップＳ１４２）。そして、各相対角度に対して、規定の最小単位（例えば、０．０５°）を丸め幅として端数処理を行う（ステップＳ１４３）。ステップＳ１４３の端数処理後の各相対角度が、ポーズ情報となる。

一方、抽出した各タイミングに対応するデータについて、以下のステップでポジション情報が生成される。まず、当該データが示すＣＧモデルの位置が、初期位置から移動しているかを検出する（ステップＳ１４４）。そして、移動していると検出された場合（ステップＳ１４４−ＹＥＳ）、ＣＧモデルの初期位置からの相対位置を示す情報を特定する（ステップＳ１４５）。例えば、ＣＧモデルの基準点（ルート）の初期位置からのｘ軸相対座標、ｙ軸相対座標、ｚ軸相対座標及び当該基準点の回転角度を抽出する。なお、ステップＳ１４４を行わずステップＳ１４５を実施してもよい。

そして、各座標及び角度に対して、規定の最小単位（例えば、座標の場合０．５ｃｍ、角度の場合０．０５°）を丸め幅として端数処理を行う（ステップＳ１４６）。ステップＳ１４６の端数処理後の各座標及び角度が、ポジション情報となる。

ステップＳ１４で生成された各データを時系列にまとめて、コリオデータを生成する（ステップＳ１５）。また、コリオデータを、コリオデータフォーマットに変換する（ステップＳ１６）。なお、コリオデータは、ステップＳ１５でフレーム単位の時系列情報として保存されてもよく、ステップＳ１６は省略されてもよい。また、保存されたフレーム単位の時系列情報に対して、ステップＳ１６を実施することによりコリオデータフォーマットへの変換が行われてもよい。

具体的には、ステップＳ１５においては、生成部１６は、時系列にデータをまとめてコリオデータの生成を行う。また、ステップＳ１６においては、図６に示したようなＳＭＦフォーマット１に準拠するように、ＣＧモデルの構成要素の座標に関する情報を、各チャンネルのノートオン／オフ信号に対応付けて、コリオデータフォーマットに変換する。

ステップＳ１５で生成されたコリオデータ及び／又はステップＳ１６で変換されたコリオデータフォーマットに準拠するデータは、保存されてもよい。例えば、制御部１７は、生成部１６に生成したコリオデータを保存させる制御を行ってもよい。これにより、ＣＧモデルの動作を音データと容易に同期できる形で保存することができる。

なお、ステップＳ１４及び／又はＳ１５では、ステップＳ１３で抽出した全てのタイミングに対応するデータについて処理を行わなくてもよい。例えば、生成部１６は、ステップＳ１１で取り込んだモーションデータに関して、所定のフレーム区間を選択し、当該フレーム区間内のデータに限定してコリオデータを生成してもよい。具体的には、当該所定のフレーム区間は、ステップＳ１２で利用した所定のテンポにおける８拍分の長さであることが好ましい。８拍分の長さのコリオデータは、上述した「流れ」を考慮したコリオデータに相当しており、ワンエイト単位でのＣＧ動画の編集（後述）に好適である。

コリオデータとしては、所定の拍の長さに対応するフレーム周期ごとに、所定の数の指定ボーンの３つの特定角によるポーズ情報と、４軸からなるポジション情報と、を持つデータが好適である。

より具体的には、コリオデータは、８分の１拍単位で情報を保持することが好ましい。この理由について図９及び１０を用いて説明する。図９は、１拍の中における典型的な角度変化のパターンの一例を示す図であり、図１０は、１拍の中における各８分の１拍を抽出する一例を示す図である。

本発明者らは、生物（例えば、人、動物など）の構成要素の動き（例えば、角度）の変化が、拍単位で見ると、図９に示すような加減、減加、単調増加又は単調減少のいずれかのパターンでほとんど表現されることに着目した。また、本発明者らは、当該着目点を鑑みた結果、図１０に示すように、１拍中に８つの点を抽出することで、動きの変化のパターンの判別と、動きが遷移するカーブの大まかな形の再現と、を行えることを見出し、コリオデータとして８分の１拍単位で情報を保持するという発想に至った。

なお、コリオデータとして含まれる時系列情報は、８分の１拍単位に限られず、データ量と元モーションデータの再現性とのトレードオフなどを考慮して適宜増減させてもよい。

＜コリオデータフォーマットに従うデータを用いたＣＧモデル表示フロー＞
図１１は、コリオデータフォーマットに準拠したモーションデータを用いてＣＧモデルを表示する場合のフローの一例を示す図である。また、図１１のフローの実施例として、図２に示した各機能ブロックが行う具体的な処理内容の一例について、図１２及び１３を参照して説明する。

図１２は、保存されたコリオデータを再生する場合の一例を示す図である。図１３は、リアルタイムでコリオデータを再生する場合の一例を示す図である。図１２では、ユーザ端末１０が、別のユーザ端末１０又はサーバ２０に保存されるコリオデータを用いて再生する場合を示し、図１３では、ユーザ端末１０が、電子楽器３０から出力されるコリオデータを用いて再生する場合を示すが、これに限られるものではない。

図１２において、シーケンサはＭＩＤＩデータ（コリオデータ）を取得するものであるから、図２の取得部１２に相当する。また、図１３において、シーケンサはＭＩＤＩ信号（コリオデータ）を生成して取得するものであるから、図２の生成部１６（及び取得部１２）に相当する。また、図１２及び１３において、ＭＩＤＩスルーボックスは、ＭＩＤＩ信号（コリオデータ）を取得するものであるから、図２の取得部１２に相当する。なお、図１２及び１３では簡単のため省略しているが、ＭＩＤＩ信号は送受信部１１を用いてネットワーク４０を介して送受信される。

また、図１２及び１３では、ユーザ端末１０が受信するＭＩＤＩ信号は、コリオデータを示すチャンネル（モーションチャンネルなどと呼ばれてもよい）及び音データを示すチャンネル（音声チャンネル、音楽チャンネルなどと呼ばれてもよい）を含むものとするが、これに限られない。

まず、各所定の拍におけるＣＧモデルの構成要素の座標に関する情報（相対角度など）を取得する（ステップＳ２１）。具体的には、ステップＳ２１において、ＭＩＤＩスルーボックスはＭＩＤＩ信号を取得して、モーションチャンネル及び音声チャンネルに分離し、再生部１３に出力する。また、再生部１３は、デコーダにより、コリオデータ（ＳＭＦフォーマット）を解析し、各チャンネルのノートオン／オフ信号に基づいて、各構成要素の座標に関する時系列情報を取得する。

次に、取得した各座標に関する情報を、フレームに対応付ける（ステップＳ２２）。この対応付けは、所定のテンポ（例えば、ＢＰＭ）と、ＣＧモデルを表示する際に単位時間あたりに処理させるフレーム数（例えば、ＦＰＳ）と、に基づいて行うことができる。

ここでの所定のテンポは、コリオデータがテンポに関する情報を含む場合には、当該情報から取得されてもよい。また、ＣＧモデルの表示と同期して再生される他のデータ（例えば、楽曲データ）から検出されたテンポであってもよいし、外部から設定された又は予め設定されたテンポであってもよい。

具体的には、ステップＳ２２においては、再生部１３は、ステップＳ２１のコリオデータから第１のＢＰＭを取得する。また、再生部１３は、ＣＧ動画と同期して再生するデータ（例えば、楽曲データ）から第２のＢＰＭを取得する。そして、再生部１３は、ステップＳ２１で取得された時系列情報を、第１のＢＰＭと第２のＢＰＭとに基づいて時間方向に調整する。例えば、再生部１３は、第１のＢＰＭと第２のＢＰＭとが異なる場合、ステップＳ２１で取得された時系列情報を、第１のＢＰＭを第２のＢＰＭで割った値だけ伸縮させる。

また、再生部１３は、ステップＳ２１で取得された時系列情報又は上記伸縮が適用された時系列情報に基づいて、ＣＧ動画を表示するＦＰＳに対応するフレームにおける各構成要素の座標（位置、角度など）を決定する。具体的には、図７のフローの処理とは逆に、図８の下側（ステップＳ２１のコリオデータ）から上側（ステップＳ２２で対応付けるフレームのデータ）を算出することになる。

上記時系列情報の所定の拍のタイミングについて、一致するフレームがある場合には、当該データをそのままフレームに割り当て、当該フレームをキーフレームとすることができる。一方、上記時系列情報の所定の拍のタイミングについて、一致するフレームがない場合には、当該拍及び近傍の拍のデータに基づいて、近傍のフレームに割り当てるデータを算出し、近傍のフレームをキーフレームとしてもよい。

例えば、各データ（角度）の拍のタイミングが非整数のフレーム周期Ｆに相当する場合を考える。この場合、割り当てたいデータの拍のタイミングが、Ｆの倍数で非整数のｎフレームであるならば、ｎフレームの近傍フレームに割り当てるデータを式４及び式５で算出する。

この式によれば、拍のタイミングにおける仮想フレームのデータを線型補間して、仮想フレームの近傍フレームの値とすることができる。なお、他の非整数のフレーム周期のタイミング（例えば、７．５（＝３．７５×２）フレーム）でも、同様の補間を行ってもよい。なお、補間の方法は線型補間に限られず、近傍フレームも上記のような直近のフレームに限られない。また、補間に用いられる拍も１つ前の拍に限られない。

コリオデータが含む角度又は座標に関する情報は、図７のステップＳ１４３及びＳ１４６で述べたように量子化されているため、元データが閾値付近で微動するものであった場合は、表示されるアニメーションにガタツキが生じる恐れがある。そこで、再生部１３は、フレームに対応付けられたデータに対して、レンダリング前に補間処理を適用することで、ガタツキを抑制してもよい。この補間処理としては、例えば、図１３に示すように、ローパスフィルタを用いた指数移動平均などを用いることができる。図１３のようなリアルタイム再生の場合、未来のデータは利用できないため、ローパスフィルタの処理が好適である。

ステップＳ２２でフレームに対応付けられたデータを用いて、ＣＧ動画を表示する（ステップＳ２３）。具体的には、ステップＳ２３においては、再生部１３は、レンダラにより、キーフレームについて、指定されるデータを用いてＣＧ動画の再生に係る信号を生成する。また、再生部１３は、キーフレーム以外については、所定の補間方法（例えば、サインカーブ補間）を用いてＣＧ動画の再生に係る信号を生成する。そして、出力部１４は、ディスプレイにより、再生部１３から出力されたＣＧ動画の再生に係る信号を出力して表示する。

なお、図１２及び１３に示すように、再生部１３は、音声チャンネルを入力された場合には、ＭＩＤＩ音源によりモーションチャンネルが示すＣＧ動画の再生と同期するように再生を行って、出力部１４がスピーカーにより出力して音を出す構成とすることができる。

また、ステップＳ２３でレンダリングされたＣＧ動画については、図示しない記憶部に動画ファイル形式で保存されてもよいし、送受信部１１を介して他のユーザ端末１０などに動画ファイル形式又はストリーミング形式で送信されてもよい。

なお、図１３の例において、ＣＧモデルの表示と同期して再生される他のデータ（例えば、楽曲データ）もコリオデータと同様にリアルタイムで取得される（ストリーミング配信される）構成としてもよい。当該構成では、通信状況の悪化により、パケットロス、遅延などが発生してストリーミング音源の再生が停止などする場合であっても、ストリーミングの進行に従って、適切に楽曲の拍に合わせてＣＧモデルの動作を再生することができる。

＜コリオデータフォーマットの変形例＞
モーションデータに関しては、更なる課題が存在する。以下では、当該課題について説明した後、これを解決するコリオデータフォーマットの変形例について説明する。

モーションデータは、できるだけ小さなデータ量で所定のモーションを再現できることが好ましい。しかしながら、単純にデータ量を減らしただけでは、動きの滑らかさが失われてしまうという問題がある。

また、ＣＧモデルの動きのテンポを単純に変更する場合、動きのキレがなくなるという課題がある。例えば、単にＢＰＭを低下してＣＧモデルを再生すると、ただのスローモーションとなってしまい、ダンスＣＧなど動きにキレが要求される動画の場合は、視聴者の受ける印象が大きく変化してしまう。

そこで、本発明者らは、ＣＧモデルの動きの滑らかさが、ポーズ間の遷移速度に対応することに着目した。また、本発明者らは、動きにメリハリを出すには、動きのキレと溜めが重要であり、動きのキレは、動きの速度の最高値によって良く表されることに着目した。本発明者らは、これらの着眼点に基づいて、加速度を考慮することにより、動きのキレの再現性を向上することを見出した。これにより、データ量の増大を抑制しつつ、モーションデータの高精度な再現が可能となる。例えば、元のモーションからＢＰＭを変えてＣＧ動画を表示する場合であっても、高速な動きの部分の長さをできるだけ維持することにより、動きのキレの劣化を抑制することができる。

本発明の一実施形態においては、コリオデータフォーマットにおいて、構成要素の座標に関する情報として、さらに別の情報を含む。具体的には、構成要素の座標又は角度について、速度系（例えば、速度、角速度、加速度、角加速度など）に関する情報を含む。当該情報を用いることにより、ＣＧモデルの動きがより滑らかとなるとともに、テンポが変動する場合に動きのキレを保持することが可能となる。

速度系に関する情報は、例えば、加速度又は角加速度に関する情報（加速度パラメータ、加速度情報などともいう）や、速度又は角速度に関する情報（以下、速度パラメータなどともいう）である。なお、以下の説明では、速度系に関する情報として角度データについての加速度パラメータ（つまり、角加速度に関する情報）の例を示すが、座標データを用いる場合も同様であり、角度を座標で読み替えてもよい。また、加速度パラメータの代わりに、構成要素の座標又は角度について、速度パラメータから加速度パラメータを算出する構成としてもよい。

本発明の一実施形態においては、コリオデータが示す所定の期間（例えば、８分の１拍の期間）で、構成要素の動作の加速度（又は角加速度）が一定である（つまり、等加速度運動）と近似することができる。具体的には、当該所定の期間は、所定のノートオン信号の開始拍から、対応するノートオフ信号によりノートオフが完了するまでの期間（又は次のノートオン信号の開始拍までの期間）であってもよい。

図１４は、加速度パラメータの算出例の一例を示す図である。図１４Ａは加速度パラメータが正の場合を示し、図１４Ｂは加速度パラメータが負の場合を示す。図１４に示すように、加速度パラメータは、所定の単位の期間の開始時及び終了時の角度の中点（２つの角度を直線で結んだ中点）と、実際の（データが詳細な場合の）角度の曲線と、の差で求めることができる。加速度パラメータが正の場合、角度変化量は時間経過とともに大きくなる一方、負の場合、角度変化量は時間経過とともに小さくなる。このように、速度系に関する情報は、コリオデータに含まれる時間的に隣接するデータ（構成要素の座標、角度など）の平均値に基づいて算出することができる。

図１５は、コリオデータフォーマットにおける加速度パラメータの格納方法の一例を示す図である。図１５は、図６で示したようなバイト列を示している。例えば、加速度パラメータは、ノートオフ信号２１０、２４０及び２５０のように、ノートオフ信号のベロシティで表現してもよい。これにより、対応するノートオン信号の開始からノートオフ信号により指定されるデルタタイムの期間の加速度パラメータを指定できる。また、従来あまり有効活用されてこなかったノートオフ信号のベロシティを利用できるため、データ量の増大を抑制しつつ加速度パラメータを含むことができる。

なお、加速度パラメータの正負は、所定のベロシティ値Ｖ_０を基準として、判断されてもよい。例えば、加速度パラメータ＝（Ｖ−Ｖ_０）として算出してもよい。ここで、Ｖはベロシティであり、Ｖ_０は例えば６０とすることができる。また、加速度パラメータの正負は、ベロシティの２進数表現における所定のビットの値に応じて、判断されてもよい。また、加速度パラメータは、ノートオフ信号のベロシティに限って表されるものではなく、他のイベント（ＭＩＤＩイベント、ＳｙｓＥｘイベントなど）を用いて実現されてもよい。

加速度パラメータは、コリオデータの作成時において、例えば、図７のステップＳ１４にて算出される。また、加速度パラメータは、コリオデータを用いたＣＧ動画表示／作成時において、例えば、図１１のステップＳ２３にて、フレーム補間に利用される。

以下、加速度パラメータを用いる利点について説明する。図１６は、加速度パラメータを用いる場合の角度変化の再現度の説明図である。図１６Ａは、元のモーション（６０ＦＰＳ）の角度変化の曲線（実線）と、抽出した８分の１拍に対応する角度をスプライン補間した曲線（破線）と、を示している。なお、図１６Ａの実線上にある点線の丸は、６０ＦＰＳ間隔のデータに対応する。この例では、８分の１拍間隔のデータは、１５ＦＰＳに相当している。

多くのＣＧ動画表示手法では、キーフレームの補間は、スプライン補間や、パラメータを設定したサインカーブ補間などによって行われる。したがって、図１６Ａに示すように、データが８分の１拍間隔に減少すると、スプライン補間では元のモーションの角度変化の形状を維持できず、再現度が劣化する場合があることがわかる。

一方、図１６Ｂは、抽出した８分の１拍に対応する角度をスプライン補間した曲線（破線）と、抽出した８分の１拍に対応する角度を、加速度を考慮して補間した曲線（実線）と、を示している。加速度を考慮することで中点における予測と実際との差が認識できるため、カーブの勾配を高精度に補間することができる。

以下では、テンポが変動する場合に動きのキレを保持するための、最高速度維持調整について説明する。本発明の一実施形態では、速度系に関する情報の正負の変化点に着目して一定期間における各構成要素の最高速度の部分を判断し、最高速度を変化させないように時系列データの伸縮を行う。なお、ＣＧモデルの構成要素の最高速度とは、ＣＧモデルの構成要素の座標（例えば、角度、位置など）が遷移する最高速度（又は最高角速度）のことをいう。

図１７は、時間経過による角度変化と、各時間に対応する加速度パラメータの変化の一例を示す図である。図１４でも示したように、加速度パラメータが正の場合後半の角度変化が大きくなり（速度が増加し）、負の場合後半の角度変化が小さくなる（速度が減少する）。すなわち、加速度パラメータが正から負に切り替わる拍で、角度が増加していく一定期間における最高速となる。また、加速度パラメータが負から正に切り替わる拍で、角度が減少していく一定期間における最高速となる。

このように、加速度パラメータを用いることで、当該パラメータの正負の変化点により一定の時間区間における最高速を容易に判断することができる。

なお、加速度パラメータの代わりに、上記中点における加速度自体を用いてもよい。この場合、隣接する拍間の加速度を比較することにより、最高速の判断を行ってもよい。また、速度パラメータの代わりに、速度自体を用いてもよい。また、速度系に関する情報として、所定の期間の中点に対応するもの以外を用いてもよい。例えば、所定の単位の期間の開始時、終了時などについて、加速度を算出してこれを加速度パラメータとしてもよい。

図１８は、最高速を考慮した拍とフレームの対応付けの一例を示す図である。図１８Ａは、単純にＢＰＭの変化に応じて拍を伸長させてフレームに対応付けした例である。データの元の速さはＢＰＭ１８０であり、再生したい速さはＢＰＭ９０であるため、テンポは半分になっている。このため、各拍の長さを単純に２倍にして、対応するフレーム又は近傍のフレームにデータをマッピングしている。このようにすると、動きの速度は全て２分の１になってしまうため、動きのキレがなくなる。

図１８Ｂは、ＢＰＭの変化の際、最高速を考慮して拍の長さを調整させてフレームに対応付けした例である。図１８Ｂでは、加速度パラメータの正負が反転した拍と、当該拍の前後の拍と、の実時間（フレーム）の間隔が、ＢＰＭを変更しても変わらないように調整されている。一方、それら以外の拍については、図１８Ａよりも引き伸ばされている（間隔が広くなっている）。これにより、全体としての角度の変化量が同じとなっている。

図１９〜２１は、最高速度維持調整の別の例を示す図である。図１９は、基本となるＢＰＭにおける角度及び速度の時系列データを示す図である。また、図２０及び２１は、図１９の時系列データのＢＰＭを、それぞれ半分及び２倍にした場合の、単純な拍の伸縮の結果（破線）と、最高速度維持の調整の結果（実線）と、を比較して表示したものである。各図Ａ及びＢは、時系列に伴う角度の変化と、当該角度の変化に対応する速度の変化を示す。

図１９Ａに示すように、当該時系列データは、時刻０において角度０、その後角度が増加していき、時刻ｔ_２で最大角度θ_ｍａｘとなり、その後角度が減少していき、また角度が０となるデータである。図１９Ｂの対応する速度は、時刻ｔ_１で最高速度Ｓ_ｍａｘとなり、時刻ｔ_２で速度０となり、時刻ｔ_３で負方向の最高速度−Ｓ_ｍａｘとなっている。

図２０の破線に示すように、ＢＰＭが半分になった場合、各拍の長さを単純に２倍にすると、最高速度が半分になってしまうことがわかる。一方で、図２０の実線に示すように、最高速度維持調整によれば、最高速度を保つことができる。

図２１の破線に示すように、ＢＰＭが２倍になった場合、各拍の長さを単純に半分にすると、最高速度が２倍になってしまうことがわかる。これでは動きが早すぎてしまい、不自然になってしまう。一方で、図２１の実線に示すように、最高速度維持調整によれば、最高速度を保つことができる。

なお、図２０Ｂ及び２１Ｂに示すように、最高速度維持調整においては、調整後の速度の積分値（実線と時間軸が囲む面積）が、調整前の速度の積分値（破線と時間軸が囲む面積）と等しくなる必要がある。しかしながら、テンポや拍の間隔によっては、これらの面積を等しくすることが難しい場合がある。このような場合には、最高速度維持の制限を緩和して面積を等しくする。例えば、図２０のようにＢＰＭが減少する場合には最高速度をＳ_ｍａｘより下げて面積を等しくし、図２１のようにＢＰＭが増加する場合には最高速度をＳ_ｍａｘより上げて面積を等しくしてもよい。

以上のような速度系に関する情報を用いた最高速度維持調整は、コリオデータの作成時において、図７のステップＳ１６にて利用されてもよい。例えば、ステップＳ１２の所定のテンポと異なるテンポへの変換を行う場合に、当該調整を利用して動きのキレを保持することができる。また、当該調整は、コリオデータを用いたＣＧ動画表示／作成時において、図１１のステップＳ２２にて利用されてもよい。例えば、ステップＳ２１のコリオデータのテンポと、ＣＧ動画と同期して再生するデータのテンポと、が異なる場合に、当該調整を利用して動きのキレを保持することができる。

なお、図９、１０、１６などに示したように、本発明者らは、生物（例えば、人、動物など）の構成要素の動き（例えば、角度）の変化量や変化パターンに着目した。この観点から、本発明の更なる一態様としては、ＣＧモデル及び／又はモーションの特徴（種類、大きさ、形状、角度など）によって、モーションデータを圧縮してもよい。例えば、ＣＧモデルによって、所定の拍単位で実現可能な動きの最大量が制限されることから、構成要素の座標に関する情報（例えば、相対角度）が取り得る値の範囲を限定して、情報量を削減してもよい。

＜コリオデータを用いたＣＧ動画の作成＞
以下では、ユーザがアプリケーションを操作し、複数のコリオデータを組み合わせて新たなＣＧ動画を生成する例について説明する。

図２２は、コリオデータとして保存されたムーブを活用してダンスＣＧ動画を作成するフローの一例を示す図である。なお、図２２では、図２に示したユーザ端末１０（以下、単にユーザ端末と呼ぶ）が所定のアプリケーション（アプリ）を介してユーザの操作によりダンスＣＧ動画を作成する場合を例に説明する。例えば、制御部１７がアプリケーションを実行し、入力部１５がユーザの入力を受け付け、当該入力に応じて制御部１７が各機能ブロック（再生部１３、出力部１４など）を制御し、出力部１４が編集画面などを適宜表示する構成としてもよい。なお、アプリによりダンス以外のＣＧ動画を作成してもよい。

まず、ユーザ端末は、所定のアプリを起動する（ステップＳ３１）。ユーザ端末は、ダンスＣＧ動画に利用するコンテンツ（例えば、ダンスと同期再生したい楽曲、動画など）を選択する（ステップＳ３２）。例えば、所定のアーティスト名と、所定のサーバが提供可能な当該アーティストに係る楽曲名と、が並んだコンテンツ選択画面が表示され、アプリのユーザインターフェースを介して、ユーザの操作によりいずれかの楽曲が選択され、ダウンロード及び／又はストリーミング配信されてもよい。また、ユーザ端末に保存されている楽曲から選択されてもよい。

次に、ユーザ端末は、選択されたコンテンツのテンポ（例えば、ＢＰＭで表される）を取得する（ステップＳ３３）。例えば、テンポは、所定のメタデータから取得されてもよいし、楽曲を解析して自動で検出されてもよいし、ユーザが手動で入力してもよいし、外部から設定されてもよいし、規定のテンポであってもよい。

ユーザ端末は、楽曲の再生位置とムーブを関連付けるためにユーザが視認する編集画面３００を表示する（ステップＳ３４）。図２３は、編集画面の一例を示す図である。図２３に示すように、編集画面３００は、第１領域３１０と、第２領域３２０と、第３領域３３０と、第４領域３４０と、を含んで構成される。また、ムーブ候補表示領域３５０及びアクセント候補表示領域３６０は、ポップアップ表示、スライド表示などにより適宜表示される。

さらに、ユーザの操作により楽曲の再生、停止などが可能に構成された楽曲操作領域３７０が表示されてもよい。なお、編集画面３００の構成は、図２３の配置に限られない。例えば、図２３では、ムーブ候補表示領域３５０及びアクセント候補表示領域３６０は、第１領域３１０にオーバレイされているが、他の領域にオーバレイされてもよい。

第１領域３１０には、ＣＧモデルが表示される。第１領域３１０は、編集作業中に、編集されたダンスのプレビューを適宜表示するために利用される。例えば、ユーザ端末は、ユーザの操作によって所定のムーブが選択された場合に、楽曲と同期再生したＣＧモデルの動作のプレビューを第１領域３１０に適宜表示してもよい。

第２領域３２０には、拍点を示す拍点軸３２１が規定される。拍点軸３２１上には複数の拍点が所定の間隔（等間隔）で離散的に設定され、拍点を示す直線状の基準線３２２が拍点軸３２１上の各拍点の位置に配置される。なお、図２３では、基準線３２２の一部を表示している。また、拍点軸３２１や基準線３２２は表示されなくてもよい。

また、ユーザ端末は、第２領域３２０に、各拍のタイミングにおけるＣＧの動きを時系列に表示する。具体的には、第２領域３２０内の、所定数の拍を表す区間について、選択されたダンスの内容がユーザに理解可能な態様で表示される。例えば、「Ａ」という名称のダンスが選択されたことを、文字「Ａ」と表示することで表してもよい。図２３では、第２領域３２０において、左から８拍分毎に、ダンス「Ａ」、「Ｄ」、「Ｂ」、「Ｃ」の順で選択されている。

また、ユーザ端末は、第２領域３２０に、選択されたダンスの内容によって対応するパターンを付して表してもよい。例えば、パターンは、それぞれ異なる形状、模様、色彩又はこれらの組み合わせなどによって、区別可能に構成される。また、文字及びパターンを組み合わせて、ＣＧの動きの内容を表示してもよい。

ユーザ端末は、第３領域３３０に、第２領域３２０に表示される拍に対応した歌詞を表示する。なお、ユーザ端末は、対応する歌詞の情報を有さない場合には、歌詞を表示しなくてもよい。

ユーザ端末は、第４領域３４０に、第２領域３２０の表示対象となる区間を選択するための楽曲の時系列情報を表示する。第４領域３４０において、第２領域３２０の表示対象となる区間に相当する部分は、選択されていることが視認可能なように表示されることが好ましい。例えば、当該部分は、所定のパターンを付して表示されてもよい。なお、図２３では、楽曲の時系列情報として、楽曲の音声信号の波形が表示されているが、これに限られるものではない。

なお、第２領域３２０の表示対象となる区間は、図２３に示すような８拍×４の３２拍単位（フォーエイト）が好適である。また、第２領域３２０では８拍単位（ワンエイト）で大まかなダンスの内容（ムーブ）を指定できることが好ましい。これは、上述の振り付けの「流れ」の特徴を考慮した編集を容易に行うためである。

次に、ユーザ端末は、編集に利用可能なベーシックムーブのジャンルを特定し、当該ジャンルのベーシックムーブのセットを編集画面３００に表示する（ステップＳ３５）。具体的には、ユーザ端末は、編集画面３００に、ムーブ候補表示領域３５０を表示する。

ムーブ候補表示領域３５０は、例えば図２３に示すようにベーシックムーブのセットとして複数のムーブ候補３５１を表示する。各ムーブ候補３５１は、プレビュー映像のように再生されつつ表示されてもよい。なお、ムーブ候補３５１の表示は、図２３に示すような静止画又は動画に限られない。例えば、ムーブ候補３５１として、ムーブの内容を示すテキストが表示されてもよい。また、ムーブ候補表示領域３５０は、図２３のレイアウトに限られず、例えば領域をスクロール可能に構成されてもよい。

また、ジャンルは、所定のメタデータから特定されてもよいし、楽曲を解析して（楽曲の内容（曲調、テンポなど）によって）自動で特定されてもよいし、ユーザが手動で入力して特定されてもよいし、外部から設定されてもよいし、規定のジャンルが選択されてもよい。

ユーザ端末は、ユーザからの操作によって、編集対象となる（ムーブ選択を行う）ワンエイトを選択する（ステップＳ３６）。ここで、ユーザ端末は、ユーザからの操作によって、第４領域３４０から所定のフォーエイトを特定して、当該フォーエイトを第２領域３２０に表示してもよい。なお、ステップＳ３５は、ステップＳ３６で編集対象が選択された後に行われる構成としてもよい。

ユーザ端末は、ユーザからの操作によって、選択されたワンエイトに割り当てるベーシックムーブを指定する（ステップＳ３７）。ムーブ候補３５１の中から区別できるように、指定されたムーブ候補３５１には所定のパターン（例えば、下線など）が付されてもよい。例えば、図２３では、指定されたムーブ候補３５１の下に、下線３５２が付されて表示される。

また、ユーザ端末は、ステップＳ３７でベーシックムーブが指定されると、さらに当該ベーシックムーブに対応したバリエーションムーブのセットを表示する（ステップＳ３８）。ここで、バリエーションムーブのムーブ候補は、ムーブ候補表示領域３５０のベーシックムーブのムーブ候補３５１と置き換わるように表示されてもよいし、ムーブ候補表示領域３５０を表示したままさらに異なるムーブ候補表示領域に表示されてもよい。

ユーザ端末は、ユーザからの操作によって、選択されたワンエイトに割り当てるムーブを、上記ベーシックムーブ又はバリエーションムーブの中から決定する（ステップＳ３９）。

ユーザ端末は、全小節でムーブが決定されたか否かを、適宜判定する（ステップＳ４０）。決定されていない場合（ステップＳ４０−ＮＯ）、ステップＳ３６〜Ｓ３９は、楽曲の全ての小節でムーブが決定されるまで、繰り返し行われる。なお、一度決定されたムーブであっても、再度ステップＳ３６〜Ｓ３９を実施して別のムーブに変更されてもよい。

全小節でムーブが決定されていれば（ステップＳ４０−ＹＥＳ）、ユーザ端末は、ユーザからの操作によって、ムーブが決定された部分について、編集対象となる（アクセント選択を行う）拍を選択する（ステップＳ４１）。

また、ユーザ端末は、編集に利用可能なアクセントのセットを編集画面３００に表示する（ステップＳ４２）。具体的には、ユーザ端末は、編集画面３００に、アクセント候補表示領域３６０を表示する。なお、ステップＳ３５におけるベーシックムーブのジャンルのように、編集に利用可能なアクセントのジャンルも特定されてもよい。

アクセント候補表示領域３６０は、例えば図２３に示すようにアクセントモーションのセットとして複数のアクセント候補３６１を表示する。各アクセント候補３６１は、図２３に示すようにアクセントの内容を示すテキストで表示されてもよいし、ムーブ候補３５１のように静止画又は動画で示されてもよい。また、アクセント候補表示領域は図２３のレイアウトに限られず、例えば領域をスクロール可能に構成されてもよい。

ユーザ端末は、ユーザからの操作によって、選択された拍に割り当てるアクセントを決定する（ステップＳ４３）。アクセント候補３６１の中から区別できるように、指定されたアクセント候補３６１には所定のパターン（例えば、下線など）が付されてもよい。

ユーザ端末は、アクセント選択が完了したか否かを、適宜判定する（ステップＳ４４）。例えば、ユーザ端末は、ユーザによってアクセント選択の操作が続いて行われる場合（ステップＳ４４−ＮＯ）、ステップＳ４１〜Ｓ４３を繰り返し行う。なお、一度決定されたムーブであっても、再度ステップＳ３６〜Ｓ３９を実施して別のムーブに変更されてもよい。アクセント選択の完了（ステップＳ４４−ＹＥＳ）は、例えばユーザが所定の操作を行う（保存ボタンを押すなど）ことにより判断されてもよい。

ユーザ端末は、各拍に設定されたムーブ、アクセントなどのコリオデータフォーマットを用いて、ダンスＣＧのモーションデータを生成する（ステップＳ４５）。そして、ユーザ端末は、生成したモーションデータを用いてダンスＣＧ動画を作成して、保存する（ステップＳ４６）。なお、ステップＳ４５で生成されたモーションデータは、別途コリオデータとして保存／利用されてもよい。

なお、図２２では、ステップＳ４０で全小節のムーブが決定されるまでステップＳ４１〜Ｓ４４のアクセント選択工程を行わない例を示したが、これに限られない。例えば、全小節でムーブが決定されていなくても、ステップＳ３６〜Ｓ３９でムーブが決定された部分についてアクセント選択を行う構成としてもい。また、ムーブが決定されていなくてもアクセント選択可能な構成としてもよい。

以上示した本発明の一実施形態によれば、コリオデータを利用したアプリケーションを操作して拍単位でモーションを設定することにより、ＣＧ動画の作成やダンスの振り付けに不慣れなユーザであっても、ＣＧのダンス動画を容易に編集及び作成することができる。また、当該アプリケーションは、「流れ」を考慮するプロセスを学習するための教材としても好適に利用可能である。

図２４は、楽曲に合わせたダンスの振り付けを作成できるソフトウェア（アプリケーション）のシステムの概念説明図である。図２４に示すソフトウェアでは、本発明に係るコリオデータを利用して、例えば図２２のようなフローによりＣＧ動画の作成などの処理が可能である。

本システムでは、ダンスＣＧの振り付け作成／表示機能に特化した一般向けソフトウェアが、ユーザに無償又は安価に提供される。一般向けソフトウェアでは、所定数の楽曲、キャラクターモデリングデータ、ムーブデータなどについては、プリインストールされ、無償で提供される。

一方、一般向けソフトウェアの持つ機能に加え、オリジナルのムーブデータをユーザが自分で作成できる機能と、ユーザが自分で作成した楽曲及びキャラクターモデリングデータを一般向けソフトウェアで利用できるように加工、取り込みなどができる機能と、が追加された上級者向けソフトウェアが、有償で提供される。ここで、データの作成は、別ソフトウェアを用いて行われてもよい。

また、一般向けソフトウェア向けの追加アイテムマーケットを提供する追加アイテムマーケットサーバが設置される。ここで、追加アイテムマーケットには、上級者向けソフトウェアを有するユーザが、ダンスＣＧ動画の素材（例えば、オリジナル楽曲、オリジナルキャラクターモデリングデータ、オリジナルムーブデータなど）をアップロードすることができる。アップロードされたデータは、単一の追加アイテムマーケットサーバではなく、クラウドで管理されてもよい。

一般向けソフトウェアは、上記追加アイテムマーケットにアクセスすることが可能であり、当該ソフトウェアのユーザは、欲しいアイテム（ダンスＣＧ動画の素材）を選択し、所定の金額で購入することができる。なお、追加アイテムマーケットに表示されるアイテムは、所定の審査を経て合格することが好ましい。

そして、購入されたアイテムをアップロードした、上級者向けソフトウェアを有するユーザには、レベニューシェアが支払われる。

また、上級者向けソフトウェア及び一般向けソフトウェアは、作成したダンスＣＧ動画を、動画サイト、アップロードサーバなどにアップロードすることができる。ここで、アップロードされたダンスＣＧ動画により広告収入が発生する場合、ダンスＣＧ動画の作成者及びダンスＣＧ動画の素材の提供者には、レベニューシェアが支払われる。

本ビジネスモデルによれば、ユーザによる楽曲、モーションデータなどの作成意欲が刺激され、本発明に係るコリオデータの利用が活性化される。

＜コリオデータを用いたＣＧ動画の作成２＞
以下では、ユーザがアプリケーションを操作し、複数のコリオデータを組み合わせて新たなＣＧ動画を生成する別の実施例について説明する。

本実施例のアプリケーションインタフェースは、図２２及び２３で示したアプリケーションインタフェースよりも、所定のデータ（例えば、音データ）を再生しながらのリアルタイムなＣＧ編集に好適である。本実施例の構成によれば、ユーザは、リズムゲームを行うような感覚で楽しみながらＣＧ編集を行うことができる。

また、本実施例では、ユーザの操作により、複数の編集モードを切り替えることで、所定の構成単位ごとの編集を容易に行うことができる。本実施例における編集モードは、当該モードで選択可能なダンス候補を、共通の特徴を持つモーション（例えば、身体の特定の部位に関するモーション）に制限するためのものである。例えば、編集モードとして、アクションモードとステップモードを規定してもよい。

ここで、アクションモードで選択可能なダンス候補は、上半身の動きが多い／大きいダンス（「アクション」と呼ぶ）から構成される。例えば、アクションは、クラップ（拍手）、ターン、ポーズ、腕ふり、ガッツポーズ、しぐさなどの動きで構成されてもよい。

ステップモードで選択可能なダンス候補は、下半身の動きが多い／大きいダンス（「ステップ」と呼ぶ）から構成される。例えば、ステップは、サイド、ホップ、ウォーク、キック、ステイなどの足の動きを中心とした動きで構成されてもよい。

なお、アクション及び／又はステップは、上半身／下半身だけでなく、全身の動き（全身に関する関節角度）を規定するように構成されてもよい。また、アクション及びステップとしては、上述のベーシックムーブ、バリエーションムーブ、アクセントなどと同様のモーションを用いることができる。

図２５は、コリオデータとして保存されたムーブを活用してダンスＣＧ動画を作成するフローの別の一例を示す図である。なお、図２５では、図２２の例と同様に、図２に示したユーザ端末１０（以下、単にユーザ端末と呼ぶ）が所定のアプリケーション（アプリ）を介して、ユーザの操作により、楽曲に同期したダンスＣＧ動画を作成する場合を例に説明する。また、図２５では、アクションモード及びステップモードを用いて編集する例を示すが、利用する編集モードはこれらに限られない。例えば、身体の特定の部位（右半身など）に関する動きを含む別のモードを規定して用いてもよい。

ステップＳ５１〜Ｓ５３は、図２２のステップＳ３１〜Ｓ３３と同様であってもよいため、説明を省略する。

ユーザ端末は、楽曲の再生位置とムーブを関連付けるためにユーザが視認する編集画面４００を表示する（ステップＳ５４）。図２６は、編集画面の別の一例を示す図である。図２６に示すように、編集画面４００は、ＣＧモデルを表示するための第１領域４１０と、ユーザによって選択されたダンスをタイムライン表示するための第２領域４２０と、選択可能なダンスの候補を表示する第３領域４３０と、当該ダンスの候補を切り替えるための第４領域４４０と、メニュー表示部４５０と、再生指示部４６０と、パレット編集指示部４７０と、編集モード指示部４８０と、を含んで構成される。

第１領域４１０は、編集作業中に、選択されたダンスのプレビューを適宜表示するために利用される。

第２領域４２０は、楽曲の再生位置を可視化するために用いられる。第２領域４２０には、タイミングマーカ４２１（例えば、点）が配置されるマーカ線４２５が規定される。現在の再生位置は、第２領域４２０の中央部に配置される現在再生位置指示線４２２によって示されている。

ここで、タイミングマーカ４２１は、マーカ線４２５上に、所定の拍数間隔（例えば、２分の１拍間隔）を示すように配置される。また、ユーザ端末は、楽曲の再生とともに、マーカ線４２５上の各タイミングマーカ４２１を、マーカ線の延在方向（例えば、左方向）に沿って移動するように表示させる。図２６においては、マーカ線４２５上に２分の１拍間隔で点が配置されており、表拍が裏拍よりやや大きな点で示されている。なお、マーカ線４２５は表示されなくてもよい。また、表拍と裏拍の区別はこれに限られず、区別されなくてもよい。

また、マーカ線４２５上には、各再生位置において選択されたダンスの内容がユーザに理解可能な態様で表示される。具体的には、マーカ線４２５上に、選択されたダンスを特定するためのダンスマーカ４２３が配置される。例えば、所定の再生位置で１拍分の長さのダンスがユーザによって選択された場合、当該再生位置から１拍分の長さを示すダンスマーカ４２３が配置される。つまり、ダンスマーカ４２３の開始位置は選択されたダンスの再生開始位置を示す。言い換えると、ダンスの開始位置は、楽曲の所定の再生位置と関連付けて選択されることになる。

また、各ダンスマーカ４２３は、選択されたダンスの内容によって異なるパターンにより表されてもよい。例えば、パターンは、それぞれ異なる形状、模様、色彩又はこれらの組み合わせなどによって、区別可能に構成される。また、文字及びパターンを組み合わせて、ダンスの内容を表示してもよい。

なお、現在再生位置指示線４２２は、第２領域４２０の中央部以外に配置されてもよい。また、マーカ線４２５は、図２６では直線であるが、これに限られない。例えば、マーカ線４２５は、曲線、ジグザグ線、螺旋状の線などであってもよい。さらに、マーカ線４２５の代わりに、マーカ面（例えば、四角形、円など）を用いてもよい。この場合、ユーザ端末は、例えば、現在再生位置指示線４２２をマーカ面の辺として、楽曲の再生とともに、マーカ面の中心から辺に伸びる方向（径方向）にマーカ面と同じ形状のタイミングマーカ４２１が広がっていくように表示させてもよい。

第３領域４３０には、選択可能なダンス候補４３１が表示される。ここで、所定数（例えば、４つ）のダンス候補４３１のセットを、「パレット」ともいう。各ダンス候補４３１は、ダンスマーカ４２３と同様に、ダンスの内容によって異なるパターンにより表されてもよい。

また、各ダンス候補４３１は、対応するダンスの拍数がユーザに認識されるように表示されることが好ましい。ダンスの拍数は文字で表示されてもよい。例えば、図２６では、「顔横クラップ」のダンス候補４３１に「１／２」の文字が付されているため、ユーザは当該ダンスが１／２拍の長さであることを認識できる。

ユーザの操作により所定のダンス候補４３１が選択された場合、現在再生位置指示線４２２が示す現在の再生位置に基づいて、ダンスマーカ４２３が配置される。ダンスマーカ４２３が実際に配置される再生位置は、現在の再生位置であってもよいし、現在の再生位置をシフトした位置であってもよい。

具体的には、ダンスマーカ４２３の開始位置は、楽曲のテンポに基づいて、補正（調節）されることが好ましい。例えば、ダンスマーカ４２３の開始位置は、現在の再生位置に最も近い表拍（又は裏拍）に挿入されるようにシフトされることが好ましい。つまり、ユーザ端末は、中途半端なタイミングでの入力を、当該タイミングに一番近い所定の拍（例えば、２分の１拍）のタイミングでの入力に変換してもよい。なお、ダンスマーカ４２３の開始位置の補正方法は、これに限られない。

また、楽曲の再生中に、所定のダンス候補４３１が一定時間に渡って選択された場合（例えば、編集画面４００がタッチパネルで構成される場合には、長押しされた場合）、当該一定時間に含まれる表拍及び／又は裏拍、当該一定時間に近傍する表拍及び／又は裏拍などにダンスマーカ４２３が連続して配置されてもよい。

第４領域４４０には、パレット選択部４４１が表示される。パレット選択部４４１は複数表示されてもよく、図２６には、パレット１、パレット２などと表示されたパレット選択部４４１が表示されている。ユーザ端末は、ユーザの操作により所定のパレット選択部４４１が選択された場合、当該選択されたパレットを第３領域４３０に表示する。第３領域４３０にどのパレットが表示されているかが視認できるように、パレット選択部４４１が構成されることが好ましい。図２６では、パレット１が選択されている。

なお、第３領域４３０に同時に表示可能な数以上のダンス候補４３１が１つのパレットに含まれる場合、ユーザが第３領域４３０に所定の操作（例えば、編集画面４００がタッチパネルで構成される場合には、フリック操作）を行うことにより、第３領域４３０に表示されるダンス候補４３１が変更されてもよい。また、この場合、第４領域４４０及びパレット選択部４４１は、省略することができる。

メニュー表示部４５０は、ユーザの操作により編集画面４００にメニューを表示するために用いられる。ユーザは、表示されたメニューから、過去に作成したダンスリスト（履歴）の選択や、新しいダンスの作成、ＣＧモデルの変更、編集画面４００の背景（ステージ）の変更、作成したダンスモーション／動画の保存、１つのパレット内のダンス候補４３１の数の変更、第４領域４４０に表示されるパレットの数の変更、その他設定の変更などを選択し、ユーザ端末は選択された処理を実施する。

再生指示部４６０は、ユーザの操作により楽曲の再生／停止を指示するために用いられる。楽曲の再生に伴って、上述のように第２領域４２０の各タイミングマーカ４２１及びダンスマーカ４２３がマーカ線４２５の延在方向に移動し、ダンスマーカ４２３が現在再生位置指示線４２２上に到達したタイミングで、第１領域４１０に表示されるＣＧモデルが当該ダンスマーカ４２３に対応するダンスを踊る。

なお、再生中及び／又は再生停止中に、ユーザが第２領域４２０に所定の操作（例えば、編集画面４００がタッチパネルで構成される場合には、フリック操作）を行うことにより、楽曲の再生位置を変更できる（シークできる）構成としてもよい。また、当該シークは、停止中に限って実施できる構成としてもよい。

また、再生停止中に、ユーザが第２領域４２０のダンスマーカ４２３に所定の操作（例えば、編集画面４００がタッチパネルで構成される場合には、タップ操作）を行うことにより、当該ダンスマーカ４２３を削除できる構成としてもよい。

なお、ユーザの操作により所定のダンス候補４３１が選択された場合、ユーザ端末は、ダンス候補４３１が示すダンスをＣＧモデルに実施させる処理を行うが、この際当該ダンスに応じて所定の音を鳴らす構成としてもよい。所定の音としては、ダンスの動作に関連する音（例えば、「クラップ」であれば手を叩く音）が再生されてもよいし、ダンスが選択されたことを示す効果音が再生されてもよい。当該構成によれば、例えばダンスモーションのリアルタイム再生にずれが生じる場合であっても、ユーザにずれを気づかせにくくすることができる。

パレット編集指示部４７０は、ユーザの操作によりパレットの内容の編集を開始する（パレット編集画面に移行する）ことを指示するために用いられる。図２７は、パレット編集画面の一例を示す図である。例えば、図２６において、パレット編集指示部４７０がユーザによって操作されると、編集画面４００が図２７のように変化する。

図２７において、編集画面４００は、所定のダンス候補４３１に対応するダンスを選択するためのダンス選択部４９０を含む。編集対象となる所定のダンス候補４３１は、第３領域４３０をユーザが操作することで決定される。また、第３領域４３０に表示されるパレットの内容は、パレット表示部４４１をユーザが操作することで決定される。

ダンス選択部４９０は、例えば、各ダンスのプレビューを表示するダンス表示部４９１を含む。ユーザの操作によりいずれかのダンス表示部４９１が選択されると、ダンス候補４３１が、選択されたダンス表示部４９１のダンスに設定される。

ここで、ダンス表示部４９１に表示されるダンスを、類似するダンスに限定するためのダンスグループタブ部４９５が表示されることが好ましい。ユーザは、所定の特徴を持ったダンスから構成されるダンスグループを特定するため、ダンスグループタブ部４９５に含まれるダンスグループタブ４９６を選択する。例えば、図２７に示すように、ダンスグループタブ４９６として「ターン」が選択される場合、ダンス表示部４９１には「ターン」、「バレエターン」などのターンに関するダンスが表示される。

なお、同じダンスグループに含まれるダンスに関して、ダンスマーカ４２３及びダンス候補４３１に付されるパターンは同じとしてもよいし、ダンスごとに異なるとしてもよい。

編集モード指示部４８０は、複数のダンス編集モードがある場合に、ユーザの操作により、編集モードの切り替えを指示するために用いられる。編集モードが切り替わると、第２領域４２０、第３領域４３０及び第４領域４４０の表示が、対応する編集モードの情報に切り替わる。つまり、本実施例では、複数のダンス編集モードを別々に編集することができるため、例えば上半身のみの編集作業を行ってから、下半身のみの編集作業を行うというような、ＣＧモデルの部位ごとの柔軟な編集が可能となる。

図２８は、編集画面の別の一例（ステップモード）を示す図である。例えば、図２６において、編集モード指示部４８０がユーザによって操作されると、編集画面４００が図２８のように変化する。

なお、編集モード指示部４８０は、現在の編集モードを表示するために用いられてもよい。例えば、図２６及び２７では、現在の編集モードがアクションモードであることが示され、図２８では、現在の編集モードがステップモードであることが示されている。

さらに、編集画面４００は図２６〜２８に示す構成に限られない。例えば、本実施例では、楽曲の再生に伴って、第２領域４２０の各タイミングマーカ４２１及びダンスマーカ４２３がマーカ線の延在方向に移動する構成としたが、現在再生位置指示線４２２が移動する構成としてもよい。また、編集画面４００には、ヘルプやチュートリアルの表示を指示するヘルプ指示部を設けてもよいし、ＣＧ動画の録画を指示する録画指示部を設けてもよい。

ユーザ端末は、編集画面４００を介したユーザからの操作により、アクションモードの編集及びステップモードの編集を実施する（ステップＳ５５、Ｓ５６）。そして、ユーザ端末は、各モードで設定されたダンスからモーションデータを生成する（ステップＳ５７）。ここで、モーションデータの生成はステップＳ５５、Ｓ５６などの編集に伴って行われてもよいし、編集後にステップＳ５７で所定の操作（例えば、メニューの「保存」の選択）を契機に行われてもよい。Ｓ５５、Ｓ５６でリアルタイムに生成されるモーションデータは、第１領域４１０において、編集作業中のプレビュー表示のために用いられてもよい。また、各モードの編集の実施は、図２５で示す順番に限られない。

そして、ユーザ端末は、生成したモーションデータを用いてダンスＣＧ動画を作成して、保存する（ステップＳ５８）。なお、ステップＳ５７で生成されたモーションデータは、別途コリオデータとして保存／利用されてもよい。

ステップＳ５７などにおいて、複数のモーションの遷移時や同時設定時のモーションデータの生成に関しては、さらなる課題が考えられる。当該課題について、本発明での解決方法を以下で説明する。

＜モーション間のブレンド＞
図２２、２３及び２５〜２８を参照して、コリオデータを用いたＣＧモデルのモーション作成方法について説明した。しかしながら、時系列で連続する拍に異なるモーションが設定される場合（モーションが遷移する場合）に、それぞれのモーションデータをそのまま適用すると、動作間の接続が不自然になってしまうという問題がある。

図２９を参照して当該問題を説明する。図２９は、関節角度の異なる２拍のモーションを２つ接続する場合の一例を示す図である。図２９において、横軸は時間（ｔ）を、縦軸は角度（θ）を示す。図２９Ａは、それぞれのモーションデータをそのまま適用した場合を示す。この場合、モーションの境界において、関節角度が不連続に遷移してしまうため、不自然な動作が描画されてしまう。

また、従来のモーションの遷移方法としては、遷移期間において前のモーションと後のモーションを一定の割合で接続するブレンド処理がある。例えば、ブレンドでは、あるモーションデータ１とモーションデータ２について、それぞれの重み付けを１０：０→５：５→０：１０と時間に従って変化させていくことで、２つのモーションを接続する。しかしながら、コリオデータでない従来のモーションデータを用いる場合には、モーション全体のデータを大まかに補間することしかできないため、ボーンの動きが不自然になってしまうことが考えられる。

そこで、本発明者らは、コリオデータが拍単位でのモーションデータを有していることに着目した。また、本発明者らは、モーションの終わりに近い拍における動作は、ユーザが当該動作から受ける印象が小さいことに着目した。さらに、逆にモーションの最初の拍における動作は、厳密に拍から開始されない場合、ユーザが当該動作から不自然な印象を受けることに着目した。本発明者らは、これらの着眼点に基づいて、モーションデータ間で自然な遷移を行う方法を見出した。

具体的には、図２９Ｂに示すように、モーションデータ間の遷移の際は、関節ごとに、前のモーションの後半の拍（例えば、最後の１拍）に含まれる各ポーズのモーションデータと、次のモーションの最初のポーズのモーションデータと、を時系列に沿って所定の規則に従いブレンドする。例えば、８分の１拍ごとのモーションデータを有する場合には、最後の１拍のうち８点分のブレンドされたモーションデータを生成して利用する。これにより、前のモーションの終わりを次のモーションの最初の拍に滑らかにつながるようにすることができ、自然なモーションを生成することが可能となる。

なお、モーションの補間とは、あるポーズの全体を所定の補間方法を用いて遷移後ポーズに遷移させることをいう。モーションの補間では、２つのポーズ間をつなぐいくつかのポーズが生成される。一方、本実施形態におけるモーションのブレンド（ボーンレベルブレンド）とは、所定の拍数分の複数のポーズと、遷移後ポーズをそれぞれ構成要素ごとに（ボーンレベルで）ブレンドして、各ブレンド後の構成要素（又はポーズ全体）をつなぎ合わせて遷移後ポーズに遷移させることをいう。言い換えると、本実施形態におけるモーションのブレンドでは、複数のモーションがボーン（間接）単位でブレンドされる。また、補間やブレンドの具体的な方法は、特に限定されず、既存の重み付け方法などが利用されてもよい。

＜同じタイミングで複数のダンスが設定される場合＞
上述したように、複数のモードで編集可能な場合などにおいては、同じタイミングで複数のダンスが設定されることが考えられる。この場合、ボーンによっては複数の角度などが設定されてしまうため、各ボーンの動きが不自然になってしまうおそれがある。

そこで、本発明者らは、複数のモーションデータが同時に設定される期間（「同時設定期間」とよぶ）に、いずれかのデータを優先してＣＧモデルの動作を決定することを着想した。

以下、４拍分のステップが設定される期間について、そのうちの後半２拍にアクションも設定される場合を例に説明するが、これに限られない。また、本例では、ステップのモーションデータには、ＣＧモデルの全身に関する構成要素の座標（関節角度）が格納されているものとする。

まず、アクションのモーションデータが上半身のみに関する情報を含む場合を説明する。図３０は、アクションのモーションデータが上半身のみに関する情報を含む場合における、アクションとステップのブレンドの一例を示す図である。図３０では、各部位に対応するステップ及びアクションのモーションデータ（間接角度）が示されている。

図３０Ａは、下半身の所定のボーンの間接角度を示す図である。本例では、同時設定期間において、下半身はアクションの影響を受けないため、ステップのモーションデータを用いる。

図３０Ｂは、上半身の所定のボーンの間接角度を示す図である。一方、同時設定期間において、上半身はアクションのモーションデータを採用する。ここで、上半身に関しては前半２拍と後半２拍との間で不連続な期間が生じるため、先に述べた本発明の一実施形態に係るボーンレベルブレンドを用いて、同時設定期間の前１拍で上半身（腕など）の各ボーン（例えば、図３のＬＡ２など）を滑らかに遷移させる。

また、一部のボーンの角度に関しては、ステップのモーションデータとアクションのモーションデータを重み付けすることで角度を補正してもよい。具体的には、体軸（背骨、首など）を構成するボーン（例えば、図３のＢ１、Ｂ２、Ｎなど）の角度に関しては、ステップのモーションデータとアクションのモーションデータを重み付けして角度を得ることが好ましい。

図３０Ｃは、上半身の体軸に関する所定のボーンの間接角度を示す図である。次のアクションのモーションは、図３０Ｃの点線で示す角度に対応するが、これを次のステップのモーションと重み付けすることで、後半２拍のモーションを新たに算出する。このようにすることで、より自然な遷移を実現することができる。

一方、アクションのモーションデータが全身に関する情報を含む場合、同時設定期間においては、アクションのモーションデータを採用する。つまり、同時設定期間では、ステップのモーションがアクションのモーションに差し替わったように描画される。この際、全身について、前半２拍と後半２拍との間で不連続な期間が生じるため、全てのボーンについて、上述のボーンレベルブレンドを用いて、同時設定期間の前１拍で上半身（腕など）の各ボーンを滑らかに遷移させる。

＜リアルタイム編集時及び編集後再生時のブレンド処理の違い＞
図２５〜２６で示したような、リアルタイムに編集されるモーションを表示する場合には、新たな課題が生じる。例えば、所定のモーションでＣＧモデルが動作中に、ユーザの操作によって別のモーションが指定された場合、いきなりモーションを切り替えると不自然に感じられる。

また、モーションデータの開始が、現在の再生位置に最も近い表拍（又は裏拍）に制限される場合、拍の途中でモーションが指定されると、本来意図しない拍にまで当該モーションが影響して再生されてしまう場合がある。一方で、編集後に改めて再生する場合（既に設定済みのモーションデータを再生する場合）には、拍の途中でモーションが始まることはない。

本発明者らは、このように、リアルタイムでモーションの編集可能なシステムにおいて、編集時と後の再生時とで、モーションの遷移タイミングが異なる点に着目した。その結果、本発明者らは、これら２つの場合で遷移中モーションの生成方法を変えることを着想した。

以下、遷移中モーションの生成方法を説明する。ユーザの入力が所望のタイミングより遅いか早いかで処理に違いがあるため、それぞれの場合について説明する。

（ユーザの入力が遅い場合）
図３１は、ユーザの入力が、所望のタイミングより遅い場合の一例を示す図である。図３１Ａは編集と同時に再生する場合を示し、図３１Ｂは既に編集されたモーションを改めて再生する場合を示す。いずれも、所定の関節について、角度θ_１のモーションから角度θ_２のモーションへと遷移する例を示す。ここで、角度θ_２のモーションは１拍分の長さとする。

図３１Ａにおいては、表拍５００を経過後、４分の１拍以内のタイミング（入力タイミング７００）で入力が行われている。したがって、角度θ_２のモーションは、表拍５００から表拍５０１までの期間に設定されることを意図して入力されたものである。しかしながら、表拍５００から入力までの期間は既にモーションの再生が終了している。このため、ユーザ端末は、入力タイミング７００から所定の長さ（例えば、５フレーム、１６分の１拍など）後の遷移完了タイミング８００で、入力されたモーションの表拍が表示されるように制御する。入力タイミング７００から遷移完了タイミング８００までの遷移は、これらのタイミングのポーズを補間して行われる。

遷移タイミング８００からは、本来入力を意図した拍（表拍５００）から遅延した分、次の表拍又は裏拍（図３１Ａの場合、裏拍６０１）に向けてモーションが早送りされるようにする。また、当該次の表拍又は裏拍から、通常の速度で再生されるように制御する。

図３１Ｂは、図３１Ａの編集を行った後のコリオデータを改めて再生した場合を示す。この場合、表拍５００の１拍前の表拍のθ_１のモーションと、表拍５００のθ_２のモーションと、を補完する。図３１Ｂでは、θ_２のモーションは表拍５００から表拍５０１で再生されるため、図３１Ａの場合と異なり早送りが行われることはない。なお、補間の代わりに、上述のボーンレベルブレンドを用いてもよい。

（ユーザの入力が早い場合）
図３２は、ユーザの入力が、所望のタイミングより早い場合の一例を示す図である。図３２Ａは編集と同時に再生する場合を示し、図３２Ｂは既に編集されたモーションを改めて再生する場合を示す。入力タイミング７００が異なる以外は、図３２と同様である。

図３２Ａにおいては、表拍５００の前、４分の１拍以内のタイミング（入力タイミング７００）で入力が行われている。したがって、角度θ_２のモーションは、表拍５００から表拍５０１までの期間を意図して入力されたものである。このため、ユーザ端末は、表拍５００から入力されたモーションの表拍が表示されるように制御する。一方、入力タイミング７００から表拍５００までの遷移は、これらのタイミングのポーズを補間（ブレンドではない）して行われる。つまり遷移完了タイミング８００は、表拍５００に一致する。

図３２Ｂは、図３２Ａの編集を行った後のコリオデータを改めて再生した場合を示す。この場合、再生処理は図３１Ｂと同様となる。

なお、図３１及び３２では、入力が表拍近傍で行われる場合を例に説明したが、これに限られるものではない。入力が裏拍近傍で行われる場合にも同様のアプローチをとることができる。

＜モーションデータの変形例＞
モーションデータは、一般的には表拍から始まり、表拍で終わるモーションを示すと想定されるが、本発明の実施形態は、これに限られない。例えば、裏拍から始まり、表拍で終わるモーションを規定してもよい。図３３は、本発明で想定されるモーションデータの一例を示す図である。

図３３Ａは、表拍から始まり、表拍で終わることを想定した２拍分の「でんぐり返り、決めポーズ」のモーションを示す。本来「でんぐり返り」の前には地面に手をつく前の予備動作が含まれるはずであるが、図３３Ａのモーションは予備動作を含んでいないため、不自然な動きとなるおそれがある。

図３３Ｂは、裏拍から始まり、表拍で終わることを想定した２拍分の「でんぐり返り、決めポーズ」のモーションを示す。ここで、予備動作に対応する最初の裏拍から表拍の期間は、動作の拍数としてカウントされないことが好ましい。図３３Ｂの例では、最初の裏拍を一度反り返るポーズとすることで、よりリアルなでんぐり返りが実現されている。

なお、裏拍から始まるモーションを示すコリオデータには、当該モーションが裏拍から始まることを示す情報を含めるように構成してもよい。これにより、ユーザ端末は所定のモーションが裏拍から始まる（予備動作を含む）ことを認識して、適切にモーションのブレンドを行うことができる。

裏拍から始まるモーションは、表拍から始まるモーションと比べてブレンド方法が異なる。以下で説明する。

（ユーザの入力が遅い場合）
図３４は、ユーザの入力が、所望のタイミングより遅い場合の別の一例を示す図である。図３４Ａは編集と同時に再生する場合を示し、図３４Ｂは既に編集されたモーションを改めて再生する場合を示す。角度θ_２のモーションが半拍分の予備動作を含むこと以外は、図３１と同様である。なお、本例では、ユーザの入力は、モーションの最初の表拍のタイミングを特定するために用いられるものとする。つまり、ユーザの入力のタイミングでは予備動作は開始されない。

図３４Ａにおいては、予備動作は無視され、ユーザ端末は、図３１Ａと同様に、入力タイミング７００から所定の長さ後の遷移完了タイミング８００で、入力されたモーションの表拍が表示されるように制御する。この場合、図３１Ａと同様に、遅れた分については早送り再生（高速再生）される。

図３４Ｂは、図３４Ａの編集を行った後のコリオデータを改めて再生した場合を示す。この場合、裏拍６００から表拍５００に渡る半拍分のθ_１のモーションと、θ_２のモーションの予備動作と、をボーンレベルブレンドする（補間はしない）。図３４Ｂでは、予備動作を除くθ_２のモーションは表拍５００から表拍５０１で再生されるため、図３４Ａの場合と異なり早送りが行われることはない。

（ユーザの入力が早い場合）
図３５は、ユーザの入力が、所望のタイミングより早い場合の別の一例を示す図である。図３５Ａは編集と同時に再生する場合を示し、図３５Ｂは既に編集されたモーションを改めて再生する場合を示す。入力タイミング７００が異なる以外は、図３２と同様である。

図３５Ａにおいては、予備動作は無視され、ユーザ端末は、図３２Ａと同様に、表拍５００から入力されたモーションの表拍が表示されるように制御する。

図３５Ｂは、図３５Ａの編集を行った後のコリオデータを改めて再生した場合を示す。この場合、再生処理は図３４Ｂと同様となる。

なお、図３４及び３５では、入力が表拍近傍で行われる場合を例に説明したが、これに限られるものではない。入力が裏拍近傍で行われる場合にも同様のアプローチをとることができる。

また、図３１Ａ及び３４Ａで、入力が遅れた場合には早送り再生がなされるものとして説明したが、これに限られない。例えば、本来想定したタイミングでモーションの切り替えが行われたと仮定して、遷移後のモーションを途中から再生するようにしてもよい。具体的には、図３１Ａにおいて、遷移完了タイミング８００では、当該タイミングで編集後に再生されるポーズを表示するものとして、表拍５００から遷移完了タイミング８００の時間で再生されるはずのデータを飛ばして表示するように制御してもよい。

＜コリオデータを用いる応用例＞
本発明に係るコリオデータを用いる応用例について、以下に説明する。

あるＣＧモデルのモーションデータとして作成されたコリオデータは、他のＣＧモデルのモーションデータとして変換されてもよいし、再生に用いられてもよい。当該変換は、ＣＧモデルの骨格構造、階層構造の初期状態、基準姿勢、各骨の長さ、各関節の可動範囲などを考慮して、ＣＧモデルの各構成要素について座標変換（例えば、位置、角度の調整）を行うことで実現されてもよい。また、当該変換で考慮されるこれらのパラメータは、コリオデータに含まれる構成としてもよい。

また、コリオデータを利用して動作させる対象は、ＣＧモデルに限られない。例えば、コリオデータを用いて、スケルトンモデルのような骨格構造で構成されたロボットを動作させてもよい。この場合、コリオデータの作成に用いたＣＧモデルと、当該ロボットと、の骨格構造や各部の長さなどを考慮して、ロボットが利用するコリオデータに上述のような座標変換が適用されてもよい。

コリオデータは、振り付けの著作権管理システムに応用することができる。例えば、様々なダンスを所定のＢＰＭで正規化したコリオデータとして保存することで、侵害判定を容易化することができる。当該システムは、例えば図１に示したサーバにより構成してもよく、以下ではサーバがコリオデータのデータベースや、振り付けの類似判定装置として機能するものとして説明する。

まず、著作権管理システムは、所定の長さ（又は所定の拍数分の長さ）の踊りの振り付けについて、コリオデータフォーマットでデータベースに登録する。ここで、あまりに短い振り付けは創作物と言えないため、所定の長さが要求される。当該長さについては、例えば所定の団体により決定されてもよい。なお、当該長さは、振り付けによって異なってもよい。

また、著作権管理システムは、ＣＧモデル又は生身の人間によるダンス動画、パフォーマンス、プログラムなどの振り付けについて、比較対象としてモーションデータを抽出し、上記データベースのコリオデータとの類似性を判定する。ここで、比較対象のモーションデータは、コリオデータフォーマットに変換されることで、容易に比較を行うことができる。例えば、身体の一部分のみの動きに着目して比較を行うことも可能である。

そして、各データのボーンの動きが、規定の誤差の範囲内であれば、元の著作物（振り付け）を侵害していると判定する。なお、音データとしてのＭＩＤＩデータの類似性を判断する方法は、コリオデータフォーマットに適用しても、適切にモーションデータの類似性を判断することが難しい。本発明の一実施形態においては、コリオデータフォーマットとしてＳＭＦフォーマットを採用する場合であっても、図６に示したようにノート番号及びベロシティが示す情報が通常のＳＭＦとは異なるためである。

また、著作権管理システムは、比較対象の動画などが商業利用されている場合には、所定の著作権管理団体に対し、当該団体の管理する著作物（振り付け）が商業利用されているという証明書を発行してもよい。これにより、当該団体は、この証明書を元に、著作物利用者に著作物利用料を徴収し、著作権者に分配することができる。

上述の実施形態では、主にダンス用のモーションデータとしてコリオデータを利用する場合を示したが、これに限られない。例えば、コリオデータは、セリフに合わせた人の動作（劇、漫才、コント、漫談など）のモーションデータに用いることができる。コリオデータを用いることで、様々に可変するセリフのテンポに同期して、ＣＧモデルに演技などをさせることができる。特に、漫才は、ボケと突っ込みに役割が分かれるとともに、それぞれ一定パターンの振りの組み合わせから動作が構成されることから、図２３に示したアプリケーションなどで誰でも漫才ＣＧ動画の作成が可能となる。

別の応用例として、コリオデータを利用して動作させるＣＧモデルの作成方法の一例を説明する。本例では、写真、イラストなどの静止画にボーン指定を行うことによって、オリジナルキャラクター（オリジナルＣＧモデル）を作成する。例えば図２に示したユーザ端末１０により当該作成処理が実現できる。

まず、人間の骨格と似た形態をしている対象物の写真データ又はイラストデータを取り込む。そして、当該データから、対象物の外形を判別する。ここで、外形の判別方法としては、背景色との差分によってソフトウェアで自動判別してもよいし、ユーザの操作（例えば、タッチスクリーンを介した操作）により対象物の外形を手動でなぞることで判別してもよいし、そもそも撮影の際に決まった外形に当てはめて撮影することで外形を判別してもよい。

次に、対象物に、一定数のボーンを設定する。設定するボーンの数は、例えば１０〜１８本程度であってもよい。また、対象物の外形を決定した時点で、その形状から、だいたいのボーンの位置が自動で設定される。さらに、ユーザの操作により、間接位置、ボーンの長さ等を調整できるようにしてもよい。

次に、対象物を動かしたいＢＰＭを決定する。例えば、楽曲を指定して、該楽曲に合わせたＢＰＭを取り込んでもよいし、ユーザの操作によりＢＰＭを手動で入力してもよい。

次に、コリオデータを用いて、対象物が振り付け通りに動くモーションデータを作成する。例えば、図２２のフローと同様に作成工程が実施されてもよい。ここで、対象物は２次元であるため、ユーザ端末は、対象物を厚さ一定の３次元データとして認識する。これにより、紙の人形が３次元に動くような感じで、モーションさせることができる。

作成された対象物のモーションデータは、動画データ／アニメーションデータとして、様々な形式でアップロード／ダウンロード可能な構成としてもよい。これにより、対象物のモーションデータは多様な場面で活用可能となり、例えば、壁紙、ＳＮＳ（Social Networking Service）への投稿、チャットのスタンプなどに利用可能である。

＜その他の構成＞
なお、上述の実施形態に係るサーバは、各種機能を有していてもよい。例えば、ユーザ端末上で動作するアプリの管理、モーションデータの管理、配信楽曲情報の管理、レシート情報（購入情報）の管理、ユーザが作成したＣＧ動画情報の管理、ユーザ管理、他サービス／システムとの連携ＡＰＩ、外部認証（例えば、ＯＡｕｔｈ ２．０）などの機能を有していてもよい。

また、上述の実施形態に係るユーザ端末で動作するアプリは、各種機能を有していてもよい。例えば、ユーザに対するチュートリアル、各種設定、バージョン管理、ＰＵＳＨ通知、課金（ストア課金、アイテム購入など）、編集ログ機能、ストリーミング再生、ニュース閲覧、コンテンツ（動画、音楽）のダウンロード、ＤＲＭにより保護されたコンテンツの再生、端末変更対応（例えば、機種変更）などの機能を有していてもよい。なお、アプリは、Ａｎｄｒｏｉｄ（登録商標） ＯＳ、ｉＯＳ（登録商標）などのＯＳで動作するネイティブアプリであってもよく、所定のブラウザで動作するＷｅｂアプリであってもよく、Ｆｌａｓｈで動作するものであってもよい。

また、上述の実施形態に示す情報処理システムは、他の装置を含んでもよい。例えば、大型ディスプレイなどを有する所定の視聴システムを採用してよく、本発明に係る情報処理システムを、放送やパブリックビューイングを始めとしたイベントに用いてもよい。例えば、本発明に係る情報処理システムを用いて、映画館、飲食店、イベントスペース、公共空間でのＣＧ動画の上映を行うことができる。

以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。例えば、上述の各実施形態は単独で用いてもよいし、組み合わせて用いてもよい。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。

本発明の一態様に係るデータ構造によれば、ＣＧモデルの動作を音データと容易に同期させることができる。このため、当該データ構造は、３次元コンピュータグラフィックスに関する情報処理装置で用いるデータ構造として有用である。

本出願は、２０１５年１月３０日出願の特願２０１５−０１６２１４及び２０１５年４月３日出願の特願２０１５−０７７１６２に基づく。この内容は、全てここに含めておく。

Claims (33)

1. コンピュータに、
   ２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを取得する手順と、
   前記第１の時系列情報に基づいて、前記ＣＧモデルの表示を行う手順と、を実行させるためのプログラム。
2. 前記データにおける前記ＳＭＦフォーマットのチャンネルは、１つ又は複数の前記第１の時系列情報に対応することを特徴とする請求項１に記載のプログラム。
3. 前記データにおける前記ＳＭＦフォーマットにおけるノートオン信号のノート番号及びベロシティは、前記コンピュータによって、前記ＣＧモデルの構成要素の座標に関する情報として用いられることを特徴とする請求項１又は請求項２に記載のプログラム。
4. 前記データにおける前記ＳＭＦフォーマットにおけるデルタタイムは、前記コンピュータによって、前記ＣＧモデルの構成要素の座標が変化する拍の長さに関する情報として用いられることを特徴とする請求項１から請求項３のいずれかに記載のプログラム。
5. 前記第１の時系列情報は、前記ＣＧモデルの骨の相対角度に関する情報を含むことを特徴とする請求項１から請求項４のいずれかに記載のプログラム。
6. 前記第１の時系列情報は、前記ＣＧモデルの初期位置からの相対距離に関する情報及び／又はＣＧモデルの基準点の回転角度に関する情報を含むことを特徴とする請求項１から請求項５のいずれかに記載のプログラム。
7. 前記第１の時系列情報は、前記ＣＧモデルの構成要素の座標について、速度、角速度、加速度及び角加速度の少なくとも１つに関する情報を含むことを特徴とする請求項１から請求項６のいずれかに記載のプログラム。
8. 前記速度、角速度、加速度及び角加速度の少なくとも１つに関する情報は、前記第１の時系列情報に含まれる時間的に隣接するデータの平均値を基準としたオフセットであることを特徴とする請求項７に記載のプログラム。
9. 前記データにおける前記ＳＭＦフォーマットにおけるノートオフ信号のベロシティは、前記コンピュータによって、前記速度、角速度、加速度及び角加速度の少なくとも１つに関する情報として用いられることを特徴とする請求項７又は請求項８に記載のプログラム。
10. 前記データは、テンポを設定するための情報をさらに含むことを特徴とする請求項１から請求項９のいずれかに記載のプログラム。
11. ２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを取得する取得部と、
    前記第１の時系列情報に基づいて、前記ＣＧモデルを表示する表示部と、を有することを特徴とする表示装置。
12. 前記表示部は、前記第１の時系列情報に指数移動平均を適用した結果に基づいて、前記ＣＧモデルを表示することを特徴とする請求項１１に記載の表示装置。
13. 音データを再生する再生部をさらに有し、
    前記表示部は、前記再生部が再生する前記音データと同期するように、前記ＣＧモデルを表示することを特徴とする請求項１１又は請求項１２に記載の表示装置。
14. 前記表示部は、各構成要素の座標が遷移する最高速度が、前記第１の時系列情報を含むデータに関するテンポで前記ＣＧモデルを表示する場合と等しくなるように、前記ＣＧモデルを表示することを特徴とする請求項１３に記載の表示装置。
15. ２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを取得する取得部と、
    当該データを受信装置に送信する送信部と、を有し、
    前記第１の時系列情報は、前記受信装置において前記ＣＧモデルの表示に用いられることを特徴とする送信装置。
16. ２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを取得する取得部と、
    当該データを含む信号を受信する受信部と、を有し、
    前記第１の時系列情報は、前記ＣＧモデルの表示に用いられることを特徴とする受信装置。
17. ２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを取得する取得部と、
    前記第１の時系列情報に基づいて、前記ＣＧモデルを表示する動画を生成する生成部と、を有することを特徴とする動画生成装置。
18. ２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルの構成要素の座標をフレーム単位で時系列に指定するための第３の時系列情報を含むダンスデータと、当該ダンスデータと同期して再生される音データと、を取得する取得部と、
    前記音データからテンポを検出し、当該テンポに基づいて所定のフレーム周期を特定する検出部と、
    前記第３の時系列情報から、前記所定のフレーム周期の各タイミングに対応するデータを第２の時系列情報として抽出する抽出部と、
    前記第２の時系列情報に基づいて、前記ＣＧモデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含むデータを生成する生成部と、を有することを特徴とするデータ変換装置。
19. 前記生成部は、前記第２の時系列情報に基づいて、前記第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを生成することを特徴とする請求項１８に記載のデータ変換装置。
20. 前記検出部は、前記ダンスデータを用いて表示される前記ＣＧモデルのＦＰＳ（Ｆｒａｍｅ Ｐｅｒ Ｓｅｃｏｎｄ）をさらに検出し、前記ＦＰＳ及び前記テンポに基づいて前記所定のフレーム周期を特定することを特徴とする請求項１８又は請求項１９に記載のデータ変換装置。
21. 前記抽出部は、前記所定のフレーム周期における所定のタイミングに対応するデータを、前記所定のタイミングの前後のフレームのデータから補間して抽出することを特徴とする請求項１８から請求項２０のいずれかに記載のデータ変換装置。
22. 前記第３の時系列情報における所定のフレーム区間を選択する選択部をさらに有し、
    前記抽出部は、前記第３の時系列情報における前記所定のフレーム区間のデータから、前記所定のフレーム周期の各タイミングに対応するデータを前記第２の時系列情報として抽出することを特徴とする請求項１８から請求項２１のいずれかに記載のデータ変換装置。
23. 前記所定のフレーム区間は、前記テンポにおける８拍分の長さを有することを特徴とする請求項２２に記載のデータ変換装置。
24. 前記所定のフレーム周期は、前記テンポにおける８分の１拍に対応することを特徴とする請求項１８から請求項２３のいずれかに記載のデータ変換装置。
25. ２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルの動作データを生成するデータ生成装置であって、
    前記ＣＧモデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを取得する取得部と、
    所定の拍数毎に、所定の拍数分の前記データで規定される基本動作の候補を複数含む基本動作候補セットから、基本動作を選択する選択部と、
    選択された動作に基づいて、前記動作データを生成する生成部と、を有することを特徴とするデータ生成装置。
26. 前記選択部は、前記基本動作に対応する変形動作の候補を複数含む変形動作候補セットから、変形動作を選択することを特徴とする請求項２５に記載のデータ生成装置。
27. 前記選択部は、前記基本動作より短い拍数で規定されるアクセント動作を選択し、
    前記生成部は、前記アクセント動作が設定された拍においては、前記アクセント動作に基づいて前記動作データを生成することを特徴とする請求項２５又は請求項２６に記載のデータ生成装置。
28. 所定の拍数は、８拍であることを特徴とする請求項２５から請求項２７のいずれかに記載のデータ生成装置。
29. 音データを再生する再生部をさらに有し、
    前記基本動作候補セットは、前記再生部が再生する前記音データに応じて、異なることを特徴とする請求項２５から請求項２８のいずれかに記載のデータ生成装置。
30. 前記音データが音声データを含む場合に、当該音声データに対応する歌詞を所定の拍数毎に時系列に表示する表示部をさらに有することを特徴とする請求項２５から請求項２９のいずれかに記載のデータ生成装置。
31. ２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルを表示する表示装置のための情報処理方法であって、
    前記ＣＧモデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを取得するステップと、
    前記第１の時系列情報に基づいて、前記ＣＧモデルの表示を行うステップと、を有することを特徴とする情報処理方法。
32. ２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルを表示する表示装置を有する情報処理システムであって、
    前記表示装置は、前記ＣＧモデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを取得する取得部と、
    前記第１の時系列情報に基づいて、前記ＣＧモデルを表示する表示部と、を有することを特徴とする情報処理システム。
33. ２つの間接点及びこれらをつなぐ骨から成る骨格により構成されるコンピュータグラフィックス（ＣＧ）モデルの動作データを生成するデータ生成装置であって、
    前記ＣＧモデルの構成要素の座標を拍単位で時系列に指定するための第１の時系列情報を含み、ＳＭＦ（Ｓｔａｎｄａｒｄ ＭＩＤＩ（登録商標）（Musical Instrument Digital Interface） Ｆｉｌｅ）フォーマットに準拠するデータを取得する取得部と、
    音データを再生する再生部と、
    前記第１の時系列情報を含むデータで規定される動作の開始位置を、前記再生部が再生する前記音データの再生位置と関連付けて選択する選択部と、
    選択された動作の開始位置に基づいて、前記動作データを生成する生成部と、を有し、
    前記動作の開始位置は、前記音データのテンポに基づいて、補正されることを特徴とするデータ生成装置。

Images