図面 (/)

技術 描画装置、その描画方法、プログラム及び記録媒体

出願人 株式会社スクウェア・エニックス・ホールディングス
発明者 フォーティン,ジャン‐フランソワエフ
出願日 2014年8月15日 (6年2ヶ月経過) 出願番号 2016-500426
公開日 2016年11月24日 (3年10ヶ月経過) 公開番号 2016-536654
状態 特許登録済
技術分野 イメージ生成 電子ゲーム機 イメージ処理・作成
主要キーワード 要素バッファ ステップセット 描画表現 幾何プリミティブ テクスチャデータベース GPUコア 仮想時刻 シェーディング値
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年11月24日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題・解決手段

描画装置は複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部は、該複数の画面間で共通である。装置は、共通の描画オブジェクトを、描画属性が固定の第1の描画オブジェクトと、描画属性が変更可能な第2の描画オブジェクトとに識別する。装置は、第1の描画オブジェクトについての描画処理を複数の画面についてまとめて行い、第2の描画オブジェクトについての描画処理を複数の画面の各々について行う。

概要

背景

ビデオゲーム産業は、スタンドアロン型アーケードゲームの導入から、家庭用コンピュータゲーム、専門コンソール用に作られたゲームの出現まで、目覚ましい発展が見受けられる。そして、インターネットの広範な一般利用は、所謂「クラウドゲーミング」等の他の主要な発展を導いた。クラウド型ゲーミングシステムでは、プレイヤはインターネットを介してビデオゲームサーバに接続するスマートフォンタブレットのような、一般的なインターネット対応電子機器を使用することが可能である。ビデオゲームサーバは、プレイヤについてセッションを開始し、複数のプレイヤについてそのようにしてもよい。ビデオゲームサーバは、プレイヤ行動(例えば移動、選択)及びゲームについての他の属性に基づいて、プレイヤについての映像データの描画、及び音声の生成を行う。符号化された映像及び音声は、インターネットを介してプレイヤの装置に配信され、視聴可能な画像及び音声として再生される。このようにして、世界中のあらゆる場所のプレイヤは、専用のビデオゲームコンソール、ソフト、描画処理ハードウェアを使用せずに、ビデオゲームをプレイすることができる。

マルチプレイヤ用ビデオゲームに係るグラフィックスを生成する際、同一の画像が複数のプレイヤに重複される場合、描画、処理または帯域リソースのような特定のリソース共有することが可能である。一方で、ゲーム体験をより明るくかつ楽しく認識させるために、シーン内オブジェクト描画表現は、同一のシーンを共有している場合であっても、様々なプレイヤにカスタマイズされる必要がある。リソース共有の必要性と及びカスタマイズの必要性は互いに反するものであるため、双方を実現する解決策が業界で望まれる。

概要

描画装置は複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部は、該複数の画面間で共通である。装置は、共通の描画オブジェクトを、描画属性が固定の第1の描画オブジェクトと、描画属性が変更可能な第2の描画オブジェクトとに識別する。装置は、第1の描画オブジェクトについての描画処理を複数の画面についてまとめて行い、第2の描画オブジェクトについての描画処理を複数の画面の各々について行う。

目的

本発明は、ステートセーブデータを容易に他の機器に提供可能なゲームシステムゲーム装置制御方法プログラム及び記録媒体を提供する

効果

実績

技術文献被引用数
1件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部が該複数の画面間で共通である描画装置であって、前記共通の描画オブジェクトを、描画属性が固定の第1の描画オブジェクトと描画属性が変更可能な第2の描画オブジェクトとに識別する識別手段と、前記第1の描画オブジェクトについての描画処理を前記複数の画面についてまとめて行う第1の描画手段と、前記第2の描画オブジェクトについての描画処理を前記複数の画面の各々について行う第2の描画手段と、を有する描画装置。

請求項2

前記第2の描画手段は、前記第1の描画手段による描画処理が行われた後に描画処理を行う請求項1に記載の描画装置。

請求項3

前記第2の描画手段は、前記第1の描画手段による描画結果を複製し、前記複数の画面の各々について行った描画結果を該複製した描画結果に反映させる請求項2に記載の描画装置。

請求項4

前記第1の描画手段による描画処理と前記第2の描画手段による描画処理は並行して行われる請求項1に記載の描画装置。

請求項5

前記第1の描画手段は、描画処理において同一の演算結果を、前記複数の画面の各々についての描画結果として出力し、前記第2の描画手段は、描画処理において前記複数の画面の各々について異なる演算結果を、前記複数の画面の各々についての描画結果に反映する請求項1、2及び4のいずれか1項に記載の描画装置。

請求項6

前記第2の描画手段は、前記第2の描画オブジェクトのうち、描画属性が共通する描画オブジェクトの描画処理は共通して行う請求項1乃至5のいずれか1項に記載の描画装置。

請求項7

前記第2の描画手段は、前記第1の描画手段による描画結果の少なくとも一部を変更する描画処理を含む請求項1乃至6のいずれか1項に記載の描画装置。

請求項8

前記複数の画面は、それぞれ異なる外部機器に接続された表示装置に表示される画面であり、前記描画装置は、前記外部機器の各々について、前記第2の描画オブジェクトの描画属性の情報を取得する取得手段をさらに有し、前記第2の描画手段は、前記第2の描画オブジェクトの描画属性の情報に基づいて、前記複数の画面の各々についての描画処理を行う請求項1乃至7のいずれか1項に記載の描画装置。

請求項9

前記第2の描画オブジェクトの変更可能な描画属性は、前記第2の描画手段による描画結果において前記第2の描画オブジェクトに対応する画素値を変更し得る属性である請求項1乃至8のいずれか1項に記載の描画装置。

請求項10

前記第2の描画オブジェクトの変更可能な描画属性は、適用するテクスチャ及び影響を考慮する照明の少なくともいずれかを含む請求項1乃至9のいずれか1項に記載の描画装置。

請求項11

前記複数の画面は、同一の視点について描画される画面である請求項1乃至10のいずれか1項に記載の描画装置。

請求項12

複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部が該数の画面間で共通である描画方法であって、前記共通の描画オブジェクトを、描画属性が固定の第1の描画オブジェクトと描画属性が変更可能な第2の描画オブジェクトとに識別し、前記第1の描画オブジェクトについての描画処理を前記複数の画面についてまとめて行い、前記第2の描画オブジェクトについての描画処理を前記複数の画面の各々について行う描画方法。

請求項13

複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部が該複数の画面間で共通する1以上の描画機能を有するコンピュータを含む1以上のコンピュータを、請求項1乃至11のいずれか1項に記載の描画装置の各手段として機能させるためのプログラム

請求項14

請求項13に記載のプログラムを記録したコンピュータが読み取り可能な記録媒体

技術分野

0001

本発明は、該して画像処理に関し、特に複数ユーザ鑑賞可能な画像をカスタマイズする方法及び装置に関する。

背景技術

0002

ビデオゲーム産業は、スタンドアロン型アーケードゲームの導入から、家庭用コンピュータゲーム、専門コンソール用に作られたゲームの出現まで、目覚ましい発展が見受けられる。そして、インターネットの広範な一般利用は、所謂「クラウドゲーミング」等の他の主要な発展を導いた。クラウド型ゲーミングシステムでは、プレイヤはインターネットを介してビデオゲームサーバに接続するスマートフォンタブレットのような、一般的なインターネット対応電子機器を使用することが可能である。ビデオゲームサーバは、プレイヤについてセッションを開始し、複数のプレイヤについてそのようにしてもよい。ビデオゲームサーバは、プレイヤ行動(例えば移動、選択)及びゲームについての他の属性に基づいて、プレイヤについての映像データの描画、及び音声の生成を行う。符号化された映像及び音声は、インターネットを介してプレイヤの装置に配信され、視聴可能な画像及び音声として再生される。このようにして、世界中のあらゆる場所のプレイヤは、専用のビデオゲームコンソール、ソフト、描画処理ハードウェアを使用せずに、ビデオゲームをプレイすることができる。

0003

マルチプレイヤ用ビデオゲームに係るグラフィックスを生成する際、同一の画像が複数のプレイヤに重複される場合、描画、処理または帯域リソースのような特定のリソース共有することが可能である。一方で、ゲーム体験をより明るくかつ楽しく認識させるために、シーン内オブジェクト描画表現は、同一のシーンを共有している場合であっても、様々なプレイヤにカスタマイズされる必要がある。リソース共有の必要性と及びカスタマイズの必要性は互いに反するものであるため、双方を実現する解決策が業界で望まれる。

0004

本発明はこのような従来技術の課題に鑑みてなされたものである。本発明は、ステートセーブデータを容易に他の機器に提供可能なゲームシステムゲーム装置制御方法プログラム及び記録媒体を提供する。

0005

本発明の第1の態様は、複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部が該複数の画面間で共通である描画装置であって、共通の描画オブジェクトを、描画属性が固定の第1の描画オブジェクトと描画属性が変更可能な第2の描画オブジェクトとに識別する識別手段と、第1の描画オブジェクトについての描画処理を複数の画面についてまとめて行う第1の描画手段と、第2の描画オブジェクトについての描画処理を複数の画面の各々について行う第2の描画手段と、を有する描画装置を提供する。

0006

本発明の第2の態様は、複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部が該数の画面間で共通である描画方法であって、共通の描画オブジェクトを、描画属性が固定の第1の描画オブジェクトと描画属性が変更可能な第2の描画オブジェクトとに識別し、第1の描画オブジェクトについての描画処理を複数の画面についてまとめて行い、第2の描画オブジェクトについての描画処理を複数の画面の各々について行う描画方法を提供する。

0007

さらに、本発明の特徴は、(添付の図面を参照して)以下の例示的な実施形態の記載により明らかになるだろう。

図面の簡単な説明

0008

本発明の非限定的な実施形態に係る、サーバシステムを含むクラウド型ビデオゲームシステムアーキテクチャブロック図
本発明の非限定的な実施形態に係る、ゲームプレイ中におけるデータネットワークを介したクライアント装置のセットとのインタラクションを示した、図1Aのクラウド型ビデオゲームシステムアーキテクチャのブロック図
本発明の非限定的な実施形態に係る、図1Bのアーキテクチャの様々な物理的構成要素を示したブロック図
図2Aの変形例
図2A及び2Bの物理的構成要素により実現され得、かつゲームプレイ中に動作しうる、図1Bのアーキテクチャにおけるサーバシステムの様々な機能モジュールを示したブロック図


本発明の非限定的な実施形態に係る、ビデオゲームの実行中に行われる処理セットの実行を示したフローチャート

本発明の非限定的な実施形態に係る、受信した映像及び音声の各々を処理するためのクライアント装置の動作を示したフローチャート
本発明の非限定的な実施形態に係る、一般オブジェクト及びカスタマイズ可能オブジェクトを含む、複数ユーザの画面描画範囲内のオブジェクトを示した図
本発明の非限定的な実施形態に係るオブジェクトデータベース概念的に示した図
本発明の非限定的な実施形態に係るテクスチャデータベースを概念的に示した図。
グラフィックスパイプラインを概念的に示した図
本発明の非限定的な実施形態に係る、グラフィックスパイプラインの画素処理サブプロセスの工程を例示したフローチャート
本発明の非限定的な実施形態に係る、描画されるオブジェクトが一般オブジェクトである場合の画素処理サブプロセスの更なる詳細を例示したフローチャート

本発明の非限定的な実施形態に係る、描画されるオブジェクトがカスタマイズ可能オブジェクトである場合の画素処理サブプロセスの、第1パス及び第2パスの各々の更なる詳細を示したフローチャート
本発明の非限定的な実施形態に係る、複数ユーザのフレームバッファ内のオブジェクトを示した図
本発明の非限定的な実施形態に係る、2人の参加者についてのフレームバッファ時間を越える発展を概念的に示した図

実施例

0009

《1.クラウドゲーミングアーキテクチャ》
図1Aは、本発明の非限定的な実施形態に係るクラウド型ビデオゲームシステムアーキテクチャを概略的に示している。該アーキテクチャは、インターネット130等のデータネットワークを介してサーバシステム100に接続されたクライアント装置120、120Aを含みうる。2つのクライアント装置120、120Aのみが示されているが、クラウド型ビデオゲームシステムアーキテクチャ内のクライアント装置の数は特に限定されるものではないことは理解されるべきである。

0010

クライアント装置120、120Aの構成は、特に限定されるものではない。いくつかの実施形態において、1以上のクライアント装置120、120Aは、例えばパーソナルコンピュータ(PC)、家庭用ゲーム機(XBOX(登録商標)、PS3(登録商標)、Wii(登録商標)等のコンソール)、携帯ゲーム機スマートテレビセットトップボックス(STB)等であってもよい。他の実施形態において、1以上のクライアント装置120、120Aは、携帯電話電子手帳(PDA)、タブレットのような通信または計算装置であってもよい。

0011

クライアント装置120、120Aの各々は、各々のローカルアクセスネットワーク(不図示)を介することを含む、あらゆる好適な方式でインターネット130に接続していてもよい。また、サーバシステム100は、ローカルアクセスネットワーク(不図示)を介してインターネット130に接続してもよいが、サーバシステム100はローカルアクセスネットワークの媒介なく、インターネット130と直接接続してよい。サーバシステム100と1以上のクライアント装置120、120Aとの接続は、1以上のチャネルを含んでいてもよい。これらのチャネルは、物理的及び/または論理リンクによりなされ、無線周波数光ファイバ光空間(free-space optical)、同軸ケーブル、及びツイストペアを含む様々な物理的媒体回遊してもよい。チャネルはUDPやTCP/IPのようなプロトコルに従ってもよい。また、1以上のチャネルが、仮想プライベートネットワーク(VPN)でサポートされていてもよい。いくつかの実施形態では、1以上の接続はセッションベースでなされてもよい。

0012

サーバシステム100は、クライアント装置120、120Aのユーザが、ビデオゲームを個々に(即ち、シングルプレイヤ用ビデオゲーム)または集団で(即ち、マルチプレイヤ用ビデオゲーム)プレイすることを可能であってもよい。またサーバシステム100は、他のプレイヤによりプレイされるゲームを観戦することを、クライアント装置120、120Aのユーザに可能にさせてもよい。ビデオゲームの非限定的な例は、レジャー教育及び/またはスポーツについてプレイされるゲームを含みうる。しかし、ビデオゲームは貨幣損益の可能性を参加者に提示する必要はない。

0013

またサーバシステム100は、ビデオゲームをテストする、及び/またはサーバシステム100を管理することをクライアント装置120、120Aのユーザに可能にさせてもよい。

0014

サーバシステム100は、場合によっては1以上のゲームサーバを含む1以上の演算リソースを含んでもよいし、場合によっては参加者データベース10を含む1以上のデータベースを有するあるいは該データベースにアクセスするものであってもよい。参加者データベース10は、識別データ財務データ、位置データ、人口統計データ接続データ等のような、様々な参加者及びクライアント装置120、120Aについてのアカウント情報を格納しうる。ゲームサーバは、共通のハードウェア内に統合される、あるいは場合によってはインターネット130を介することを含む通信リンクを介して接続される異なるサーバ群であってもよい。同様に、データベースはサーバシステム100内に統合される、あるいは場合によってはインターネット130を介する通信リンクを介してサーバシステム100に接続されるものであってもよい。

0015

サーバシステム100は、ゲームプレイより前等、ゲーム環境外のクライアント装置120、120Aとのインタラクションを扱うための管理アプリケーション実装してもよい。例えば、該管理アプリケーションは、ユーザクラス(「プレイヤ」、「観戦者」、「管理者」または「テスター」等)に属する1つのクライアント装置120、120Aのユーザを登録し、インターネットを介してユーザの接続性が追跡され、ゲームのインスタンスを開始する、参加する、終了する、または終了させるために、非限定的ないくつかの機能のうちのユーザコマンド応答する。該目的の達成のため、管理アプリケーションは参加者データベース10にアクセスする必要があってもよい。

0016

管理アプリケーションは、非限定的な2〜3の可能性を挙げると、「プレイヤ」、「観戦者」、「管理者」及び「テスター」を含む異なるユーザクラスのユーザと、異なるインタラクションをしてもよい。

0017

故に、一例において管理アプリケーションは、参加者データベース10へのアカウントの設定及びプレイするビデオゲームの選択をプレイヤ(即ち「プレイヤ」ユーザクラスのユーザ)が可能なように、プレイヤとのインタフェースとして機能しうる。該選択に従い、管理アプリケーションはサーバ側ビデオゲームアプリケーション起動しうる。サーバ側ビデオゲームアプリケーションは、仮想世界内のキャラクタアバターレースカーコックピット等の制御をプレイヤに可能ならしめる、プレイヤについての機能モジュールセットを実行するコンピュータ読み取り可能な命令により定義されうる。マルチプレイヤ用ビデオゲームの場合、仮想世界は2以上のプレイヤにより共有され得、1人のプレイヤのゲームプレイが他のプレイヤに影響を及ぼし得る。

0018

他の例では管理アプリケーションは、参加者データベース10へのアカウントの設定、及びユーザが観戦を所望する進行中のビデオゲームのリストからのビデオゲームの選択を観戦者(即ち「観戦者」ユーザクラスのユーザ)に可能ならしめる、観戦者とのインタフェースとして機能しうる。該選択に従い、管理アプリケーションは、観戦者が他のユーザのゲームプレイを観賞できるが該ゲーム内アクティブキャラクタの制御はできないように、該観戦者についての機能モジュールセットを起動しうる(別段の指示がない限り、「参加者」との文言が使用された場合、「プレイヤ」ユーザクラスと「観戦者」ユーザクラスの両方に等しく適用されることを意味する)。

0019

更なる例において、管理アプリケーションは、ゲームサーバアプリケーションの様々な機能の変更、更新の実行、及びプレイヤ/管理者アカウントの管理を管理者(即ち「管理者」ユーザクラス)が可能なように、管理者とのインタフェースとして機能しうる。

0020

さらに別の例では、ゲームサーバアプリケーションは、テスト用のビデオゲームの選択をテスター(即ち「テスター」ユーザクラスのユーザ)が可能なように、テスターとのインタフェースとして機能しうる。該選択に従い、ゲームサーバアプリケーションは、ビデオゲームのテストをテスターに可能ならしめる、テスター用の機能モジュールセットを起動しうる。

0021

図1Bは、「プレイヤ」または「観戦者」ユーザクラスのユーザについての、ゲームプレイ中におけるクライアント装置120、120Aとサーバシステム100との間に生じるインタラクションを示している。

0022

いくつかの非限定的な実施形態において、サーバ側ビデオゲームアプリケーションは、クライアント装置120、120Aのようなクライアント装置において実行中のコンピュータ読み取り可能な命令セットにより定義されうるクライアント側ビデオゲームアプリケーションと協働してもよい。クライアント側ビデオゲームアプリケーションの使用は、ゲームをプレイまたは観戦するため及びゲーム機能にアクセスするために、参加者用にカスタマイズされたインタフェースを提供してもよい。他の非限定的な実施形態において、クライアント装置は、該クライアント装置により直接的に実行可能なクライアント側ビデオゲームアプリケーションを特徴づけるものではない。むしろ、Webブラウザがクライアント装置の視点(perspective)からのインタフェースとして使用されてもよい。該Webブラウザは、サーバ側ビデオゲームアプリケーションとのインタラクションを最適化するように、自身のソフトウェア環境におけるクライアント側ビデオゲームアプリケーションのインスタンスを自身で作成してもよい。

0023

クライアント装置120、120Aのうちの任意の1つは、該任意のクライアント装置のユーザが入力を提供し、ビデオゲームに参加することを可能ならしめるために、1以上の入力装置タッチスクリーンキーボードゲームコントローラジョイスティック等)が備えられていてもよいことは理解されるべきである。他の実施形態において、ユーザは身体動作を行う、外部オブジェクトを振る等してもよく、これらの動作はカメラや他のセンサ(例えばKinect(登録商標))により検出され、該任意のクライアント装置で動作するソフトウェアは、ユーザが該任意のクライアント装置に対して入力を提供しようとしているか、もしそうであれば該入力の本質を正確に推測することを試みる。任意のクライアント装置において(独立にまたはブラウザ内で)実行されるクライアント側ビデオゲームアプリケーションは、受信したユーザ入力及び検出されたユーザ動作を、インターネット130を介してサーバシステム100に送信されうる「クライアント装置入力」に変換しうる。

0024

図1Bに示されている実施形態では、クライアント装置120はクライアント装置入力140を生成し、クライアント装置120Aはクライアント装置入力140Aを生成してもよい。サーバシステム100は、様々なクライアント装置120、120Aから受信したクライアント装置入力140、140Aを処理し、該様々なクライアント装置120、120Aについての「メディア出力」150、150Aをそれぞれ生成しうる。メディア出力150、150Aは、(スクリーン上に表示された場合に画像を示す)符号化された映像コンテンツストリーム及び(スピーカを介して再生された場合に音を示す)音声を含みうる。メディア出力150、150Aは、パケットの形でインターネット130を介して送信されうる。クライアント装置120、120Aの特定の1つに向けられたパケットは、インターネット130を介して該装置にルートされるように、このような方法でアドレスされうる。クライアント装置120、120Aの各々は、サーバシステム100から受信したパケット内のメディア出力をバッファして処理する電気回路、画像を表示するためのディスプレイ、及び音声を出力する振動子(例えばスピーカ)を含んでいてもよい。また、追加の出力装置は、動作を誘導するための電気機械システム等を提供してもよい。

0025

映像データのストリームは、「フレーム」に分割されうることは理解されるべきである。ここでは、「フレーム」との文言は映像データのフレームと該映像データによりあらわされる画像との間の1対1対応の存在を要求するものではない。即ち、映像データの1つのフレームについて、表示される各画像の全体を示すデータを含めることも可能であるし、映像データの1つのフレームについて、画像の一部のみを示すデータを含めること、及び適切に再構成されて表示されるために、画像についてさらに2以上のフレームを要求することも可能である。同様に、映像データの1つのフレームは、M<NであるN個の画像が映像データのM個のフレームを用いて示される等、1以上の完全な画像を示すデータを含んでいてもよい。

0026

《2.サーバシステム100(分散型アーキテクチャ)》
図2Aは、サーバシステム100の構成要素の非限定的な物理的構成の第1の態様を示している。本実施形態では、サーバシステム100の個々のサーバが、専用の機能を実行するよう構成されうる。例えば、計算サーバ200Cは、ユーザ入力に基づいてビデオゲーム内の状態変化の追跡についての役割を担い、描画サーバ200Rは、グラフィック(映像データ)の描画についての役割を担い得る。

0027

以下に記載される実施形態の例のために、クライアント装置120及びクライアント装置120Aの両方は、プレイヤまたは参加者としてビデオゲームに参加しているものとする。しかしながら、いくつかのケースでは1人のプレイヤと観戦者なし、複数のプレイヤと1人の観戦者、1人のプレイヤと複数の観戦者、及び複数のプレイヤと複数の観戦者等で構成されてもよいことは理解されるべきである。

0028

簡単のため、以下の説明では単一の描画サーバ200Rに単一の計算サーバ200Cが接続されているものとする。しかしながら、1以上の描画サーバ200Rが同一の計算サーバ200Cに接続される、あるいは1以上の計算サーバ200Cが同一の描画サーバ200Rに接続されるものであってもよいことは理解されるべきである。複数の描画サーバ200Rが存在する場合、あらゆる適切な地理的領域に分散されるものであってもよい。

0029

図2Aの構成要素の非限定的な物理的構成に示されるように、計算サーバ200Cは1以上の中央演算装置(CPU)220C、222C及びランダムアクセスメモリ(RAM)230Cを有していてもよい。CPU220C、222Cは、例えば通信バスアーキテクチャを介してRAM230Cにアクセス可能である。2つのCPU220C、222Cのみが示されているが、計算サーバ200Cのいくつかの実装例では、より多数のCPUあるいは単一のCPUのみが提供されてもよい。また、計算サーバ200Cは、ビデオゲームに参加しているクライアント装置の各々から、インターネット130を介してクライアント装置入力を受信する、ネットワークインタフェース要素(NIC)210C2を有していてもよい。以下に記載される実施形態の例では、クライアント装置120及び120Aの両方は、ビデオゲームに参加しているものとし、従って、受信したクライアント装置入力はクライアント装置入力140及びクライアント装置入力140Aが含まれうる。

0030

さらに計算サーバ200Cは、描画命令セット204を出力する他のネットワークインタフェース要素(NIC)210C1を有していてもよい。NIC210C1を介して計算サーバ200Cから出力された描画命令セット204は、描画サーバ200Rに送信されうる。一実施形態において計算サーバ200Cは、描画サーバ200Rに直接接続されてもよい。他の実施形態では計算サーバ200Cは、インターネット130であってもよいし、その他のネットワークであってもよいネットワーク260を介して描画サーバ200Rに接続されてもよい。仮想プライベートネットワーク(VPN)は、ネットワーク260を介して計算サーバ200Cと描画サーバ200Rとの間に確立されてもよい。

0031

描画サーバ200Rにおいて、計算サーバ200Cにより送信された描画命令セット204は、ネットワークインタフェース要素(NIC)210R1において受信され、1以上のCPU220R、222Rに対して導かれうる。CPU220R、222Rは、グラフィック処理装置(GPU)240R、250Rに接続されてもよい。非限定的な例として、GPU240Rは、GPUコア242Rのセット及びビデオランダムアクセスメモリVRAM)246Rを含んでもよい。同様に、GPU250RはGPUコア252Rのセット及びビデオランダムアクセスメモリ(VRAM)256Rを含んでもよい。CPU220R、222Rの各々は、GPU240R、250Rの各々に接続されていてもよいし、GPU240R、250Rの集合に接続されていてもよい。CPU220R、222RとGPU240R、250Rとの間の通信は、例えば通信バスアーキテクチャを用いて確立されてよい。2つのCPU及び2つのGPUのみが示されるが、描画サーバ200Rの特定の実装例では、2以上のCPU及びGPUがあってもよいし、単一のCPUまたはGPUだけであってもよい。

0032

CPU220R、222Rは、描画命令セット204を参加する各クライアント装置用グラフィック出力ストリームに変換するために、GPU240R、250Rと協働しうる。本実施形態では、クライアント装置120、120Aの各々について2つのグラフィック出力ストリーム206、206Aがあり得る。このことは、さらに詳細が後述されるだろう。さらに描画サーバ200Rは、これを介してグラフィック出力ストリーム206、206Aがクライアント装置120、120Aの各々に送信されうる、ネットワークインタフェース要素(NIC)210R2を有していてもよい。

0033

《3.サーバシステム100(ハイブリッドアーキテクチャ)》
図2Bは、サーバシステム100の構成要素の非限定的な物理的構成の第2の態様を示している。本実施形態ではハイブリッドサーバ200Hは、ユーザ入力に基づいてビデオゲーム内の状態変化の追跡とグラフィック(映像)の描画の両方の役割を担いうる。

0034

図2Bの構成要素の非限定的な物理的構成に示されるように、ハイブリッドサーバ200Hは1以上の中央演算装置(CPU)220H、222H及びランダムアクセスメモリ(RAM)230Hを有していてもよい。CPU220H、222Hは、例えば通信バスアーキテクチャを介してRAM230Hにアクセスできる。2つのCPU220H、222Hのみが示されているが、より多数のCPUまたは単一のCPUのみがハイブリッドサーバ200Hのいくつかの実装例において提供されてもよいことは理解されるべきである。またハイブリッドサーバ200Hは、ビデオゲームに参加するクライアント装置の各々からインターネット130を介してクライアント装置入力が受信されるネットワークインタフェース要素(NIC)210Hを有していてもよい。以下に記載される実施形態の例では、クライアント装置120及びクライアント装置120Aの両方は、ビデオゲームに参加しているものとし、故に受信したクライアント装置入力は、クライアント装置入力140及びクライアント装置入力140Aを含んでもよい。

0035

また、CPU220H、222Hは、描画処理装置(GPU)240H、250Hに接続されていてもよい。非限定的な例ではGPU240Hは、GPUコア242のセット及びビデオランダムアクセスメモリ(VRAM)246Hを含んでいてもよい。同様にGPU250Hは、GPUコア252Hのセット及びビデオランダムアクセスメモリ(VRAM)256Hを含んでいてもよい。CPU220H、222Hの各々は、GPU240H、250Hの各々またはGPU240H、250Hの集合に接続されていてもよい。CPU220H、222HとGPU240H、250Hとの通信は、例えば通信バスアーキテクチャを用いて確立されてもよい。2つのCPUと2つのGPUのみが示されているが、ハイブリッドサーバ200Hの特定の実装例では、2以上のCPUがあってもよいし、CPUまたはGPUが単一のみであってさえよい。

0036

描画命令セット204を、参加している各クライアント装置につき1つであるグラフィック出力ストリームに変換するために、CPU220H、222HはGPU240H、250Hと協働する。本実施形態では、参加しているクライアント装置120、120Aの各々に対して、2つのグラフィック出力ストリーム206、206Aが存在しうる。グラフィック出力ストリーム206、206Aは、NIC210Hを介してクライアント装置120、120Aの各々に送信されうる。

0037

《4.サーバシステム100(機能概要)》
ゲームプレイの間、サーバシステム100は、機能モジュールセットで構成されうるサーバ側ビデオゲームアプリケーションを実行する。図2Cを参照すると、これらの機能モジュールはビデオゲーム機モジュール270、描画機能モジュール280、及び映像符号化器285を含んでいてよい。これらの機能モジュールは、上述した計算サーバ200Cと描画サーバ200R(図2A)及び/またはハイブリッドサーバ200H(図2B)の物理的構成要素により実現されうる。例えば、図2Aの非限定的な実施形態に関しては、ビデオゲーム機能モジュール270は計算サーバ200Cにより実現され、描画機能モジュール280及び映像符号化器285は描画サーバ200Rにより実現されうる。図2Bの非限定的な実施形態に関しては、ハイブリッドサーバ200Hはビデオゲーム機能モジュール270、描画機能モジュール280、及び映像符号化器285を実現しうる。

0038

本実施形態の例は、図を簡略化するために単一のビデオゲーム機能モジュール270について議論する。しかしながら、サーバシステム100の実際の実装において、ビデオゲーム機能モジュール270と同様の多くのビデオゲーム機能モジュールが平行に実行されうる。したがって、サーバシステム100は、同一のビデオゲームの複数の独立したインスタンス化または複数の異なるビデオゲームの同時のインスタンス化をサポートしうる。また、ビデオゲームは、あらゆる種類の1人プレイヤ用ビデオゲームまたはマルチプレイヤ用ゲームであってもよいことは理解されるべきである。

0039

ビデオゲーム機能モジュール270は、計算サーバ200Cまたはハイブリッドサーバ200Hの所定の物理的構成要素により実現されてもよい。具体的には、ビデオゲーム機能モジュール270は、ビデオゲーム機能モジュール270は、(計算サーバ200CのCPU220C、222Cやハイブリッドサーバ200HのCPU220H、222Hのような)CPUにより実行可能なコンピュータ読み取り可能な命令として符号化されうる。該命令は、(計算サーバ200Cの)RAM230C、(ハイブリッドサーバ200Hの)RAM230H、あるいは他の記憶領域に、ビデオゲーム機能モジュール270により使用される定数変数及び/または他のデータとともに明白に(tangibly)格納されうる。いくつかの実施形態においてビデオゲーム機能モジュール270は、(計算サーバ200CのCPU220C、222Cやハイブリッドサーバ200HのCPU220H、222Hのような)CPUにより実行されているオペレーティングシステムによりサポートされうる、バーチャルマシンの環境において実行されてもよい。

0040

描画機能モジュール280は描画サーバ200R(図2A)あるいはハイブリッドサーバ200H(図2B)の所定の物理的構成要素により実現されてもよい。一実施形態において、描画機能モジュール280は、1以上のGPU(図2Aの240R、250R、図2Bの240H、250H)が引き受けてもよいし、CPUリソースを利用してもよいししなくてもよい。

0041

映像符号化器285は、描画サーバ200R(図2A)またはハイブリッドサーバ200H(図2B)の所定の物理的構成要素により実現されてよい。本技術分野に属する当業者は、映像符号化器285を実現する種々の手法があることは容易に理解するだろう。図2Aの実施形態において、映像符号化器285はCPU220R、222R及び/またはGPU240R、250Rにより実現されうる。図2Bの実施形態では、映像符号化器285はCPU220H、222H及び/またはGPU240H、250Hにより実現されうる。その他の実施形態では、映像符号化器285は、分離された符号化チップ(不図示)により実現されてもよい。

0042

動作において、ビデオゲーム機能モジュール270は、受信したクライアント装置入力に基づいて描画命令セット204を生成しうる。受信したクライアント装置入力は、行き先となるビデオゲーム機能モジュールを示すデータ(例えばアドレス)、及び由来するユーザ及び/またはクライアント装置を示すデータを運ぶものであってよい。クライアント装置120、120Aのユーザは、ビデオゲームに参加(即ちプレイヤまたは観戦者)しており、受信したクライアント装置入力は、クライアント装置120、120Aから受信したクライアント装置入力140、140Aを含みうる。

0043

描画命令は、映像データのフレームまたは映像データの一連のフレームを生成するように専用グラフィック生成装置(GPU)に導くために用いられうる命令を示す。図2Cを参照すると、描画命令セット204は、描画機能モジュール280による映像データのフレームの生成をもたらす。これらのフレームにより示される画像は、ビデオゲーム機能モジュール270にプログラムされた、クライアント装置入力140、140Aに応じた機能として変更されうる。例えば、ビデオゲーム機能モジュール270は、所定の特定の要因に応じてユーザに(将来のインタラクションが異なる、より挑戦的とさせる、あるいはより刺激的とさせる)進行体験を提供するような方法でプログラムされ得、一方で、他の特定の要因への応答は、回帰や終了の体験をユーザに与えるだろう。ビデオゲーム機能モジュール270への指示はバイナリ実行可能なファイルの形式で固定され得るが、クライアント装置入力140、140Aは対応するクライアント装置120、120Aを使用するプレイヤのインタラクション動作があるまで不明である。結果として、提供される特定のクライアント装置入力に応じて、様々な種類の生じ得る結果が存在してもよい。プレイヤ/観戦者とビデオゲーム機能モジュール270の間のクライアント装置120、120Aを介した該インタラクションは、「ゲームプレイ」や「ビデオゲームをプレイしている」等として言及されうる。

0044

描画機能モジュール280は、複数の映像データストリーム205を生成するために描画命令セット204を処理しうる。一般に、参加者ごとに(あるいはクライアント装置ごとにも同等)、1つの映像データストリームが存在してよい。描画が実行されている場合、3次元空間(例えば物理オブジェクト)あるいは2次元空間(例えばテキスト)に示される1以上のオブジェクトについてのデータは、特定のGPU240R、250R、240H、250Hのキャッシュメモリ(不図示)に展開される。該データは、GPU240R、250R、240H、250Hにより、適切なVRAM246R、256R、246H、256Hに格納されうる2次元画像を示すデータに変換されうる。このようにして、VRAM246R、256R、246H、256Hは、ゲーム画面についての画素値の一時的な格納領域を提供しうる。

0045

映像符号化器285は、映像データストリーム205の各々に含まれる映像データを、対応する圧縮/符号化された映像データのストリームに圧縮及び符号化しうる。グラフィック出力ストリームとして言及される、圧縮/符号化された映像データの結果であるストリームは、クライアント装置基準で生成されうる。本実施形態の例では映像符号化器285は、クライアント装置120についてのグラフィック出力ストリーム206及びクライアント装置120Aについてのグラフィック出力ストリーム206Aを生成しうる。追加の機能モジュールが、インターネット130を介して送信可能なように映像データをパケット形式にするよう提供されてもよい。映像データストリーム205に含まれる映像データ、及び任意のグラフィック出力ストリームに含まれる圧縮/符号化された映像データは、複数のフレームに分割されうる。

0046

《5.描画命令の生成》
以下、ビデオゲーム機能モジュール270による描画命令の生成が、図2C、3A及び3Bを参照してより詳細に説明される。具体的には、ビデオゲーム機能モジュール270の実行は、いかに詳細が説明されるメインゲームプロセス300Aとグラフィック制御プロセス300Bを含むいくつかのプロセスを伴いうる。

0047

〈メインゲームプロセス〉
メインゲームプロセス300Aは、図3Aを参照して説明される。メインゲームプロセス300Aは、連続的なループとして繰り返し実行しうる。メインゲームプロセス300Aの一部として、実行中、クライアント装置入力が受信されうる動作310Aが提供されうる。ビデオゲームが観戦の可能性がない1人プレイヤ用ビデオゲームである場合、単一のクライアント装置(例えばクライアント装置120)からのクライアント装置入力(例えばクライアント装置入力140)が動作310Aの一部として受信される。ビデオゲームがマルチプレイヤ用ビデオゲームまたは観戦の可能性がある1人プレイヤ用ゲームである場合、1以上のクライアント装置(例えばクライアント装置120及び120A)からのクライアント装置入力(例えばクライアント装置入力140及び140A)が、動作310Aの一部として受信されうる。

0048

非限定的な例示の目的で、任意のクライアント装置からの入力は、該任意のクライアント装置のユーザが、制御下にあるキャラクタに対して移動、ジャンプキック旋回揺動、押す、引く等をさせることを所望していることを伝送しうる。代替的あるいは追加的に、該任意のクライアント装置からの入力は、1以上の音声、映像またはゲームプレイ設定を変更する、ゲームをロード/セーブする、あるいはネットワークセッションの作成やセッションへの参加を行うために、該任意のクリア案と装置のユーザによりなされたメニュー選択を伝送しうる。代替的あるいは追加的に、該任意のクライアント装置からの入力は、該任意のクライアント装置のユーザが特定のカメラ視野(例えば1人称または3人称)の選択、あるいは仮想世界内の視野再配置を所望していることを伝送しうる。

0049

動作320Aで、ゲームステートは、動作310Aにおいて受信したクライアント装置入力の少なくとも一部及び他のパラメータに基づいて更新されうる。ゲームステートの更新は、次の動作を伴いうる。

0050

第1に、ゲームステートの更新は、クライアント装置入力が受信されうるクライアント装置に関連付けられた参加者(プレイヤまたは観戦者)の所定の特性(property)を更新することを伴いうる。これらの特性は、参加者データベース10に格納されうる。参加者データベース10に保持されて動作320において更新されうる参加者特性の例は、カメラ視野の選択(例えば1人称、3人称)、プレイモード、選択された音声または映像の設定、スキルレベル顧客グレード(例えばゲストプレミアム等)を含みうる。

0051

第2に、ゲームステートの更新は、クライアント装置入力の解釈に基づいて、仮想世界内の所定のオブジェクトの属性を更新することを伴いうる。属性が更新されるオブジェクトは、いくつかのケースでは2次元または3次元モデルにより示されてもよいし、プレイキャラクタ、非プレイキャラクタ及び他のオブジェクトを含みうる。プレイヤキャラクタである場合、更新されうる属性はオブジェクトの位置、強さ、武器防具、経過した寿命、特殊能力、速さ/方向(速度)、アニメーション視覚的効果エネルギ弾薬等を含みうる。他のオブジェクト(背景、植物、建物乗り物スコアボード等)である場合、更新されうる属性は、該オブジェクトの位置、速度、アニメーション、ダメージ体力、視覚的効果、テキスト内容等を含みうる。

0052

クライアント装置入力とは別のパラメータは、上述した(参加者の)特性及び(仮想世界オブジェクトの)属性に影響を与えうることは理解されるべきである。例えば、様々なタイマー(経過時間、特定のイベントからの時間、一日の仮想時刻、プレイヤ総数、参加者地理的位置等)が、ゲームステートの様々な態様に影響を及ぼしてもよい。

0053

動作320Aの実行に加えてゲームステートが更新されると、メインゲームプロセス300Aは動作310Aに戻ってもよく、前回のメインゲームプロセスを終了してから受信した新たなクライアント装置入力が収集され、処理される。

0054

〈グラフィック制御プロセス〉
以下、グラフィック制御プロセスとして言及される第2のプロセスについて、図3Bを参照して説明する。メインゲームプロセス300Aとは分離されて示されるが、グラフィック制御プロセス300Bはメインゲームプロセス300Aの延長として実行してもよい。グラフィック制御プロセス300Bは継続的に実行し、描画命令セット204の生成をもたらす。観戦の可能性がない1人プレイヤ用ビデオゲームの場合、1人のプレイヤのみが存在し、故に衛星される描画命令セット204の結果は1つのみである。マルチプレイヤ用ビデオゲームの場合、複数の独立した描画命令セットが複数のプレイヤについて生成されることが必要であり、従って各プレイヤについて1つである複数のサブプロセスが並行して実行しうる。観戦の可能性がある1人プレイヤ用ゲームの場合、また単一の描画命令セット204のみが存在し得るが、結果である映像データストリームは、描画機能モジュール280により複数の観戦者にも複製されうる。もちろん、これらはただの実装の例であり、限定として取られるべきものではない。

0055

映像データストリーム205の1つを要求する任意の参加者についてのグラフィック制御プロセス300Bの動作を考える。動作310Bにおいて、ビデオゲーム機能モジュール270は該任意の参加者について描画されるオブジェクトを決定しうる。この動作は、以下の種類のオブジェクトを識別することを含んでいてよい。

0056

第1に、この動作は、仮想世界から任意の参加者についての「ゲーム画面描画範囲」(「シーン」としても知られる)内にある、これらのオブジェクトを識別することを含みうる。ゲーム画面描画範囲は、任意の参加者のカメラの画角(perspective)から「観ることが可能」な、仮想世界の一部を含みうる。これは、仮想世界内のオブジェクトに関連するカメラの位置及び方向に依るものであってもよい。動作310Bの非限定的な実装例において、錐台が仮想世界に適用され、該錐台内のオブジェクトが保持またはマークされる。錐台は、任意の参加者のカメラの位置に置かれた頂点を有し、該カメラの方向性により規定される方向を有するものであってもよい。

0057

第2に、この動作は、仮想世界内に現れないが、それにも関わらず任意の参加者について描画される必要がありうる追加のオブジェクトを識別することを含みうる。例えば、これらの追加のオブジェクトは、非限定的な2〜3の可能性を挙げると、テキストメッセージ、グラフィック警告及びダッシュボードインジケータを含んでもよい。

0058

動作320Bで、ビデオゲーム機能モジュール270は、動作310Bにおいて識別されたオブジェクトを、グラフィック(映像データ)に描画するための命令セットを生成しうる。描画は、視野及び適用される照明状態に従って、1つのオブジェクトまたはオブジェクト群の3次元または2次元座標の、表示可能な画像を示すデータへの変換を参照してもよい。これは、例えばここに参照により組み込まれる「"Computer Graphics and Geometric Modelling: Implementation & Algorithms", Max K. Agoston, Springer-Verlag London Limited, 2005」に記載されるような、あらゆるアルゴリズム及び技術を用いて達成されうる。描画命令は、ワシントン州レドモンドのマイクロソフト(登録商標)社の「Direct3D」及びオレゴン州ビーバートンクロノスグループにより管理される「OpenGL」等の3Dアプリケーション・プログラミング・インタフェース(API)に適合する形式を有するものであってもよい。

0059

動作330Bで、動作320Bにおいて生成された描画命令は描画機能モジュール280に出力されうる。これは、描画機能モジュール280に送信する描画命令セット204への、生成された描画命令のパケット化を伴いうる。

0060

《6.グラフィック出力の生成》
描画機能モジュール280は、描画命令セット204を解釈し、参加しているクライアント装置ごとに1つである、複数の映像データストリーム205を生成しうる。描画は、(図2Aの)CPU220R、222Rまたは(図2Bの)CPU220H、222Hの制御の下、GPU240R、250R、240H、250Hにより実現されうる。1つの参加者のクライアント装置に係る映像データのフレームが生成されるレートは、フレームレートとして参照されうる。

0061

N名の参加者が存在する実施形態において、N個の描画命令セット204(各参加者について1つ)が存在し、N個の映像データストリーム205(各参加者について1つの)が存在し得る。この場合、描画機能は参加者間で共有されない。しかしながら、2〜3の描画命令セットが描画機能モジュール280により処理される必要があるように、M個(M<N)の描画命令セット204からN個の映像データストリーム205が生成されてもよい。この場合、少ない数の描画命令セット204からより多い数の映像データストリーム205を生成するために、描画機能モジュール280は共有または複製を行ってもよい。このような共有または複製は、複数の参加者(例えば観戦者)が同一のカメラ画角を観ることを所望した場合に普及するものであってもよい。故に、描画機能モジュール280は、生成された映像データストリームが1以上の観戦者に複製されるように機能を実行してもよい。

0062

次に、映像データストリーム205の各々における映像データは、映像符号化器285により符号化され、グラフィック出力ストリームとして参照され得、各クライアント装置に関連付けられた一連の符号化映像データが得られる。図2A〜2Cの実施形態の例において、クライアント装置120についての一連の符号化映像データはグラフィック出力ストリーム206として参照され、クライアント装置120Aについての一連の符号化映像データはグラフィック出力ストリーム206Aとして参照されてもよい。

0063

映像符号化器285は、デジタル映像についての映像圧縮または展開を可能にする、実行する、または定義する装置(またはコンピュータ読み取り可能な命令セット)であってもよい。映像圧縮は、(画素位置、色値等で表現される)デジタル画像データのオリジナルストリームを、より少ないビットを用いるが実質的に同一の情報を伝送するデジタル画像データの出力ストリームに変換しうる。あらゆる適切な圧縮アルゴリズムが用いられてよい。データ圧縮に加え、映像データの特定のフレームの符号化に用いられる符号化処理は、暗号化を伴ってもよいし、伴わなくともよい。

0064

上述の手法で生成されたグラフィック出力ストリーム206、206Aは、インターネット130を介して各クライアント装置に送信されうる。非限定的な例示目的で、グラフィック出力ストリームは、各々がヘッダ及びペイロードを有するパケットに、セグメント化あるいは形式化されてもよい。任意の参加者についての映像データに含まれるパケットのヘッダは、該任意の参加者に関連付けられたクライアント装置のネットワークアドレスを含んでもよく、ペイロードは全部または一部として映像データを含んでもよい。非限定的な実施形態において、所定の映像データを符号化するために用いられる圧縮アルゴリズムの身元(identity)及び/またはバージョンが、該映像データを伝送する1以上のパケットのコンテンツ内に符号化されてもよい。符号化映像データの他の送信手法は、本技術分野に属する当業者には思い当たるかもしれない。

0065

本開示は個々が2D画像を示す映像データの描画にフォーカスするものであるが、本発明は3次元効果を生成するために、フレームごとに複数の2D画像を示す映像データの描画の可能性を除外するものではない。

0066

《7.クライアント装置におけるゲーム画面再生》
以下、非限定的な例示の目的で、クライアント装置120またはクライアント装置120Aたり得る、任意の参加者に関連付けられたクライアント装置により実行されうるクライアント側ビデオゲームアプリケーションの動作を示す図4Aを参照する。動作にあたり、クライアント側ビデオゲームアプリケーションは、非限定的な2〜3の可能性を挙げると、クライアント装置により直接実行可能であってもよいし、Webブラウザにおいて起動してもよい。

0067

動作410Aで、1つのグラフィック出力ストリーム(例えば206、206A)は、実施形態に応じて描画サーバ200R(図2A)から、あるいはハイブリッドサーバ200H(図2B)から、インターネット130を介して受信されてもよい。受信されたグラフィック出力ストリームは複数のフレームに分割されうる圧縮/符号化された映像データを含みうる。

0068

動作420で、映像データの圧縮/符号化されたフレームは、符号化/圧縮処理に用いられた符号化/圧縮アルゴリズムを補間する展開アルゴリズムに従って復号/展開される。非限定的な実施形態において、映像データの符号化/圧縮に用いられた符号化/圧縮アルゴリズムの身元またはバージョンは、予め知らされていてもよい。他の実施形態において、映像データの符号化/圧縮に用いられた符号化/圧縮アルゴリズムの身元またはバージョンは、映像データ自体が添付されてもよい。

0069

動作430Aで、映像データの(復号/展開された)フレームが処理されうる。これは、バッファへの映像データの復号/展開されたフレームの配置、誤り訂正、複数の連続するフレームにおけるデータの順序付け及び/または合成、アルファブレンディング欠損したデータの一部の補間等を含みうる。該結果は、毎フレーム基準でユーザに提示される最終画像を示す映像データとなり得る。

0070

動作440Aで、最終画像がクライアント装置の出力機構を介して出力されうる。例えば、コンポジット映像フレームが、クライアント装置のディスプレイに表示されうる。

0071

《8.音声生成
以下、音声生成処理として言及される3番目の処理が、図3Cを参照して説明される。音声生成処理は、知覚可能な音声ストリームを要求する各参加者について、継続的に実行されうる。一実施形態において、音声生成処理はグラフィック制御プロセス300Bと無関係に実行されてよい。他の実施形態において、音声生成処理及びグラフィック制御処理の実行が連動されてもよい。

0072

動作310Cで、ビデオゲーム機能モジュール270は、生成される音声を決定しうる。具体的に該動作は、音量(音の強さ)及び/または仮想世界内において参加者への近さに応じて、地形音響特性に影響を及ぼす仮想世界内のオブジェクトに関連付けられたこれらの音声を特定することを含みうる。

0073

動作320Cで、ビデオゲーム機能モジュール270は音声セグメントを生成しうる。音声セグメントの継続期間は映像フレームの継続期間に及んでもよいし、いくつかの実施形態では音声セグメントは映像フレームよりも少ない頻度で生成されてもよいし、他の実施形態では音声セグメントは映像フレームよりも高い頻度で生成されてもよい。

0074

動作330Cで、音声セグメントは例えば音声符号化器により符号化され得、符号化音声セグメントが得られる。音声符号化器は、音声圧縮または展開アルゴリズムを可能にする、実行する、または定義する装置(または命令セット)であってもよい。音声圧縮は、(徐々に振幅及び位相が変化する音波として表現される)デジタル音声のオリジナルストリームを、より少ないビットを使用するが実質的に同一の情報を伝送するデジタル音声データの出力ストリームに変換しうる。あらゆる適切な圧縮アルゴリズムが用いられてよい。音声圧縮に加え、特定の音声セグメントの符号化に用いられる符号化処理は暗号化を適用してもよいし、しなくてもよい。

0075

いくつかの実施形態において、音声セグメントは計算サーバ200C(図2A)またはハイブリッドサーバ200H(図2B)のいずれかの専用ハードウェア(例えばサウンドカード)により生成されてもよいことは理解されるべきである。図2Aの分散型構成に適用可能な代替的実施形態において、音声セグメントはビデオゲーム機能モジュール270によりスピーチパラメータ(例えばLPCパラメータ)にパラメータ化されてもよく、スピーチパラメータは描画サーバ200Rにより、配信先のクライアント装置(例えばクライアント装置120またはクライアント装置120A)に再配信されうる。

0076

上述した方式で生成された符号化された音声は、インターネット130を介して送信される。非限定的な例示を目的として、符号化された音声入力は、各々がヘッダ及びペイロードを有するパケットに分解及び形式化されうる。ヘッダは、音声生成処理が実行される参加者に関連付けられたクライアント装置のアドレスを伝送してもよく、ペイロードは符号化された音声を含んでいてもよい。非限定的な実施形態において、任意の音声セグメントの符号化に用いられる圧縮アルゴリズムの身元及び/またはバージョンは、該任意のセグメントを伝送する1以上のパケットのコンテンツ内に符号化されてもよい。符号化された音声を送信する他の手法は、本技術分野に属する当業者には思い当たるかもしれない。

0077

以下、非限定的な例示を目的として、クライアント装置120またはクライアント装置120Aであってよい、任意の参加者に関連付けられたクライアント装置の動作を示す図4Bを参照する。

0078

動作410Bで、符号化された音声セグメントが(実施形態に応じて)計算サーバ200C、描画サーバ200R、またはハイブリッドサーバ200Hから受信されうる。動作420Bで、符号化処理に用いられた圧縮アルゴリズムを補間する展開アルゴリズムに従って、符号化された音声は復号されうる。非限定的な実施形態において、音声セグメントの符号化に用いられた圧縮アルゴリズムの身元またはバージョンは、音声セグメントを伝送する1以上のパケットのコンテンツ内で特定されてもよい。

0079

動作430Bで、(復号された)音声セグメントが処理されうる。これは、バッファ内への復号された音声セグメントの配置、誤り訂正の実行、複数の連続する波形合成等を含みうる。該結果は、毎フレーム基準でユーザに提示される最終音声となり得る。

0080

動作440Bで、最終的に生成された音声は、クライアント装置の出力機構を介して出力されうる。例えば、音声はクライアント装置のサウンドカードまたはスピーカを介して再生されうる。

0081

《9.非限定的な実施形態の具体的開示》
以下、本発明の所定の非限定的な実施形態のより詳細な説明が提供される。

0082

発明のある非限定的な実施形態の非限定的な説明の提示目的で、ビデオゲーム内の2以上の参加者(プレイヤまたは観戦者)が、同一の位置及びカメラ投影を有するものとする。即ち、同一のシーンが2以上の参加者により鑑賞される。例えば、1人の参加者はプレイヤであってよく、他の参加者は個々の観戦者であってよい。シーンは様々なオブジェクトを含むものとする。本発明の非限定的な実施形態において、これらのオブジェクトのいくつか(所謂「一般」オブジェクト)は一度描画されて共有され、故に参加者の各々に同一の描画表現がもたらされる。また、シーン内の1以上のオブジェクト(所謂「カスタマイズ可能」オブジェクト)は、カスタマイズされた方法で描画される。故に、これらは全ての参加者についてシーン内の共通の位置を占有するが、カスタマイズ可能オブジェクトは観戦者間で様々な描画表現をもたらす。結果として、描画されたシーンの画像は、全ての参加者について同一である、一般オブジェクトを含む第1の領域と、観戦者間で変化し得る、カスタマイズ可能オブジェクトを含む第2の領域とを含む。以下では、「参加者」との文言は、「ユーザ」との文言と同一の意味で用いられうる。

0083

図5は、参加者A、B、Cについて生成され得る、映像/画像データにより表される複数の画像510A、510B、510Cを概念的に示している。本例では3人の参加者A、B及びCが存在するが、任意の実装において、参加者の数がいずれであってもよいことは理解されよう。画像510A、510B、510Cは、全ての参加者に対し共通であってよいオブジェクト520を示す。参照を簡易にするため、オブジェクト520は「一般」オブジェクトとして参照される。また、画像510A、510B、510Cは、各参加者についてカスタマイズされ得るオブジェクト530を示す。参照を簡易にするため、オブジェクト530は「カスタマイズ可能」オブジェクトとして参照される。カスタマイズ可能オブジェクトは、異なる参加者について異なるテクスチャを有するように、カスタマイズされ得るが、これらの参加者間で共通の照明条件が適用される、シーン内のいずれのオブジェクトであってもよい。このように、カスタマイズ可能オブジェクトとは対照的に、一般オブジェクトであってよいオブジェクトのタイプには特定の限定を有しない。一例において、カスタマイズ可能オブジェクトはシーンオブジェクトであってよい。

0084

図示される例では、単一の一般オブジェクト520と単一のカスタマイズ可能オブジェクトとが示される。しかしながら、これは限定として考慮されるべきではなく、任意の実装において考慮されるように、あらゆる数の一般オブジェクトとあらゆる数のカスタマイズ可能オブジェクトが存在するものであってもよい。さらに、オブジェクトはいずれのサイズまたは形状であってもよい。

0085

描画される特定のオブジェクトは、一般オブジェクトまたはカスタマイズ可能オブジェクトとして分類され得る。オブジェクトが一般オブジェクトまたはカスタマイズ可能オブジェクトとして考慮されるか否かの決定は、様々な要素に基づきメインゲームプロセス300Aによってなされるものであってよい。これらの要素は、シーンにおけるオブジェクトの位置や深度を含むものであってもよいし、単純に任意のオブジェクトが一般またはカスタマイズ可能のいずれであるかをあらかじめ識別されされているものであってもよい。図6Aを参照されるように、一般またはカスタマイズ可能に係るオブジェクトの識別は、オブジェクトデータベース1120に格納されていてもよい。オブジェクトデータベース1120は、少なくとも一部においてコンピュータメモリを用いる態様であってもよい。実装される態様によって、オブジェクトデータベース1120はメインゲームプロセス300Aにより維持され、グラフィック制御プロセス300B及び/または描画機能モジュール280によりアクセス可能であってもよい。

0086

オブジェクトデータベース1120は、各オブジェクトについてのレコード1122と、該オブジェクトに係る種々の情報を格納する各レコード1122のフィールドセット1124、1126、1128を含んでよい。例えば、他者間で、(オブジェクトIDお格納する)識別フィールド1124、(不図示のテクスチャデータベースの画像ファイルにリンクするテクスチャIDを格納する)テクスチャフィールド1126、及び(該オブジェクトが一般オブジェクトとカスタマイズ可能オブジェクトのいずれであるかの識別子を格納する)カスタマイズフィールド1128があってよい。

0087

あるオブジェクトが(オブジェクトID「520」を有するオブジェクト用であって、カスタマイズフィールド1128の内容が「一般」を示すような)一般オブジェクトである場合、対応のテクスチャフィールド1126に格納されるテクスチャIDにより示されるテクスチャ(この場合「txt.bmp」)が、全ての参加者により鑑賞される最終画像における一般オブジェクトを表すために用いられるものである。テクスチャ自体は、テクスチャデータベース1190(図6B参照)に格納され、テクスチャID(この場合「txt.bmp」)によりインデックスが付されたファイルを構成する。テクスチャデータベース1190は、少なくとも一部にコンピュータメモリを用いる態様であってよい。

0088

あるオブジェクトが(オブジェクトID「530」を有するオブジェクト用であって、カスタマイズフィールド1128の内容が「カスタマイズ可能」を示すような)カスタマイズ可能オブジェクトである場合、複数の参加者は該オブジェクトに異なるテクスチャが適用されることを鑑賞し得る。故に、再び図6Aに関して、予定のテクスチャフィールドは、2以上の参加者の各々について1つである、サブレコードセット1142で置き換えられ得、各サブレコードは(参加者IDを格納する)参加者フィールド1144と(テクスチャデータベースの画像ファイルにリンクするテクスチャIDを格納する)テクスチャフィールド1146を含む。テクスチャ事態は、テクスチャデータベース1190に格納され、テクスチャID(この場合「txtA.bmp」、「txtB.bmp」及び「txtC.bmp」が各々参加者A、B及びCに関連付けられたテクスチャIDである)によりインデックスが付されたファイルを構成しうる。

0089

カスタマイズフィールド1128、サブレコード1142及びテクスチャフィールド1146の使用は、オブジェクトデータベース1120のカスタマイズ可能オブジェクト530に係る情報を符号化する1つの特定の手法に過ぎず、限定として考慮されるべきでない。

0090

故に、単一のカスタマイズ可能オブジェクトは、複数の参加者の各々に関連付けられた複数のテクスチャに関連付けされ得る。任意のカスタマイズ可能オブジェクトに係るテクスチャと参加者との関係は、種々の要素に依存し得る。これらの要素は、識別情報、財務データ、位置データ、人口統計データ、接続データ等のような、種々の参加者に係る参加者データベース10に格納される情報を含みうる。

0091

〈実装例〉
図7は、ビデオゲーム機能モジュール270から受信した描画命令に基づき、描画機能モジュール280により実施されうるグラフィックスパイプライン例を示している。ビデオゲーム機能モジュールが描画機能モジュール280として同一の計算装置に存在(図2B参照)または異なる計算装置に存在(図2A)し得ることが再度認識されるだろう。グラフィックスパイプラインの一部を形成する計算の実行が描画命令により定義される、即ち描画機能ユニット280にグラフィックスパイプライン動作を実行させるように、描画命令がビデオゲーム機能モジュール270により発行されることが理解されるべきである。この目的を達成するために、ビデオゲーム機能モジュール270及び描画機能モジュール280は、描画命令を符号化、復号及び解釈に所定のプロトコルを用いる。

0092

図7に示される描画パイプラインは、非限定的な例示手法として用いられる、WA、レドモンド州のマイクロソフト社のDirect3Dアーキテクチャの一部を形成する。他のシステムがグラフィックスパイプラインにおける変形例を実現し得る。図示されたグラフィックスパイプラインは、以下に列挙及び簡潔に記載される複数のブロック(またはサブプロセス)を含む:
710頂点データ
未変換のモデル頂点が、頂点メモリバッファに格納される。
720プリミティブデータ
点、線、三角形及び多角形を含む幾何プリミティブが、インデックスバッファを用いて頂点データから参照される。
730テッセレーション
テッセレータ部は、高次プリミティブ置換マップ及びメッシュパッチ頂点位置に変換し、これらの位置を頂点バッファに格納する。
740頂点処理
Direct3D変形が、頂点バッファに格納された頂点に適用される。
750ジオメトリ処理
クリッピング、背面カリング、属性評価及びラスタライズが、変形された頂点に適用される。
760テクスチャ適用される面:
Direct3D面に係るテクスチャ座標が、IDirect3DTexture9インタフェースを介してDirect3Dに供給される。
770 テクスチャサンプラ
テクスチャ詳細レベルフィルタリングが、入力テクスチャ値に適用される。
780画素処理
ピクセルシェーダ操作は、入力された頂点及びテクスチャデータ修正するためにジオメトリデータを用い、出力画素値を得る。
790画素描画:
最終描画処理は、アルファ、深度、またはステンシルテストを用いて、あるいは安生らブレンディングフォグを適用することにより、画素値を修正する。結果である全ての画素値は出力ディスプレイに提示される。

0093

以下、図8を参照し、本発明の非限定的な実施形態に係り適応された、グラフィックスパイプラインにおける画素処理サブプロセス780についての更なる詳細を提供する。特に画素処理サブプロセスは、オブジェクトに係る各画素について、受信した描画命令に基づき行われる、ステップ810〜840を含みうる。ステップ810で、拡散スペキュラ、環境等を含む照明成分演算を含んでいてよい、放射輝度が演算され得る。ステップ820で、該オブジェクトのテクスチャが取得され得る。テクスチャは、拡散色情報を含むものであってよい。ステップ830で、拡散色情報及び照明情報に基づき、各画素が画素値に起因する、画素ごとのシェーディングが演算され得る。最終的にステップ840で、各画素の画素値がフレームバッファに格納される。

0094

本発明の非限定的な実施形態に係り、該画素処理サブプロセスのステップ810〜840の実行は、画素が処理されるオブジェクトの種別、即ち、オブジェクトが一般オブジェクトとカスタマイズ可能オブジェクトのいずれであるかに依存するものであってよい。複数の参加者により観賞される一般オブジェクトの描画画素と、複数の参加者により観賞されるカスタマイズ可能オブジェクトの描画画素との違いを、以下により詳細に説明する。実質的には2以上の参加者が存在するものであればよいが、本議論のため、3人の参加者A、B及びCが存在するものとする。

0095

特定のオブジェクトに係る任意の画素セットに対していずれの処理ステップセットを提供するかを描画機能モジュール280が知るために、描画機能モジュール280が該特定のオブジェクトが一般オブジェクトとカスタマイズ可能オブジェクトのいずれであるかを知る必要があることが理解されるだろう。このことは、ビデオゲーム機能モジュール270から描画命令を受信することにより理解され得る。例えば、描画命令はオブジェクトIDを含んでいてよい。オブジェクトが一般オブジェクトとカスタマイズ可能オブジェクトのいずれであるかを判断するに際し、適切なレコード1122を検出するため、描画機能モジュール280は該オブジェクトIDに基づきオブジェクトデータベース1120を閲覧し、該レコード1122に係るカスタマイズフィールド1128の内容を判断してよい。他の実施形態では、描画命令は、それ自体が特定のオブジェクトが一般オブジェクトとカスタマイズ可能オブジェクトのいずれであるかを特定してもよいし、テクスチャ情報や該情報へのリンクを含むものであってさえよい。

0096

(i)一般オブジェクト520に係る画素処理
以下、オブジェクト520のような一般オブジェクトである場合の、画素処理サブプロセス780におけるステップ810〜840を示す図9を参照する。これらのステップは、一般オブジェクトの各画素pについて実行され、画素処理サブプロセスを介して単一のパスを構成するものであってよい。

0097

ステップ810において、描画機能モジュール280は、拡散光成分DiffuseLightingp、スペキュラ光成分SpecularLightingp、及び環境光成分AmbientLightingpを含むものであってよい、画素pにおける分光放射輝度を演算し得る。ステップ810への入力は、原点、方向、強度、描画される視点に影響する色及び/または形状、及び用いられる照明モデルの定義またはパラメータに加え、深度バッファ(「Zバッファ」としても言及される)、法線バッファ、スペキュラ要素バッファの内容のような項目を含むものであってよい。このように、放射輝度演算は計算的な集中操作であってもよい。

0098

非限定的な実施形態において、「DiffuseLighitingp」は「DiffuseLighting(p,i)」の(iに係る)合計である。ここで「DiffuseLighting(p,i)」は、画素pにおける、光源「i」からの拡散項の強度及び色を示す。非限定的な実施形態において、任意の光源「i」に係るDiffuseLighting(p,i)の値は、面法線光源方向内積(n・lとしても参照される)として演算され得る。また「SpecularLightingp」は、画素pにおけるスペキュラ光の強度及び色を表す。非限定的な実施形態において、SpecularLightingpの値は、反射光ベクトル視線方向の内積(r・vとしても参照される)として算出され得る。さらに、「AmbientLightingp」は、画素pにおける環境光の強度及び色を示す。また、画素pにおけるDiffuseLightingp、SpecularLightingp及びAmbientLightingpを演算するために用いられる的確な数学的アルゴリズムが、本技術分野に属する当業者により周知であることは理解されるべきである。

0099

ステップ820において、画素pにおける適切な色値を得るために、描画機能モジュール280は一般オブジェクト(この場合オブジェクト520)のテクスチャを参照しうる。テクスチャは、まずテクスチャIDを得るためにオブジェクトIDに基づきオブジェクトデータベース1120が参照されることにより識別され、そして画素pにおける拡散色値を得るために、該得られたテクスチャIDに基づきテクスチャデータベース1190が参照されるものであってよい。結果である拡散色値は、DiffuseColor_520pで示される。具体的には、DiffuseColor_520pは画素pに対応する点におけるオブジェクト520のテクスチャのサンプル値(あるいは補間値)で表され得る。

0100

ステップ830において、描画機能モジュール280は画素pに係る画素値を演算し得る。「画素値」との文言が、スカラ複数成分のベクトルを言及し得るものであることは留意されるべきである。非限定的な実施形態において、複数成分のベクトルのような構成要素は、色(または色相彩度)、彩度(色自身の強度)、及び輝度であってよい。「強度」との文言は、場合によって輝度成分を表すために用いられる。他の非限定的な実施形態において、複数成分の色ベクトルの複数の構成要素は、RGB(赤、緑及び青)であってもよい。1つの非限定的な実施形態において、画素pについてOutputpで示される画素値は、拡散色に拡散光成分を増殖的に組み合わせ、さらにスペキュラ光成分及び環境光成分を加算することにより演算されるものであってもよい。即ち、
Outputp = (DiffuseColor_520p * DiffuseLightingp) + SpecularLightingp + AmbientLightingp
となる。Outputpが画素pの複数成分(例えばRGB、YCbCr等)の各々について分離して演算されるものであってもよいことは理解されるべきである。

0101

そしてステップ840において、Outputpで示される画素pの画素値が、各参加者のフレームバッファに格納される。具体的には一般オブジェクト520に関連付けられた任意の画素は、参加者A、B及びCについてのフレームバッファを跨いで同一の画素値を有し、一般オブジェクト520に係る全ての画素が描画されると、一般オブジェクト520は全ての参加者についてグラフィックスとして同一に現れる。図11を参照すると、一般オブジェクト520は参加者A、B及びCについて同一であるように共有されていることが理解されよう。故に、画素値Outputpは一度演算されると、各参加者のフレームバッファに複製され得る。このように、画素値Outputpが全ての参加者A、B、C間で共有されるような場合のみ、一般オブジェクト520の描画についての演算量の低減が生じ得る。また画素値は、「画像データ」として言及されるものであってもよい。

0102

(ii)カスタマイズ可能オブジェクト530に係る画素処理
以下、オブジェクト530のようなカスタマイズ可能オブジェクトである場合の、画素処理サブプロセス780におけるステップ810〜840を示す図10A及び10Bを参照する。これらのステップは、カスタマイズ可能オブジェクトの各画素pについて実行され、画素処理サブプロセスを介して複数のパスを構成するものであってよい。具体的には図10Aは全ての画素について実行され得る第1のパスに関し、図10Bは全ての画素について実行され得る第2のパスに関する。また、第2のパスはいくつかの画素について、第1のパスが他の画素について実行されている際に開始することが可能である。

0103

ステップ810において、描画機能モジュール280は、拡散光成分DiffuseLightingq、スペキュラ光成分SpecularLightingq、及び環境光成分AmbientLightingqを含むものであってよい、画素pにおける分光放射輝度を演算し得る。図9に示したケースのように、(図10Aの)ステップ810への入力は、原点、方向、強度、描画される視点に影響する色及び/または形状、及び用いられる照明モデルの定義またはパラメータに加え、深度バッファ(「Zバッファ」としても言及される)、法線バッファ、スペキュラ要素バッファの内容のような項目を含むものであってよい。

0104

非限定的な実施形態において、「DiffuseLighitingq」は「DiffuseLighting(q,i)」の(iに係る)合計である。ここで「DiffuseLighting(q,i)」は、画素qにおける、光源「i」からの拡散項の強度及び色を示す。非限定的な実施形態において、任意の光源「i」に係るDiffuseLighting(q,i)の値は、面法線と光源方向の内積(n・lとしても参照される)として演算され得る。また「SpecularLightingq」は、画素qにおけるスペキュラ光の強度及び色を表す。非限定的な実施形態において、SpecularLightingqの値は、反射光ベクトルと視線方向の内積(r・vとしても参照される)として算出され得る。さらに、「AmbientLightingq」は、画素pにおける環境光の強度及び色を示す。また、画素qにおけるDiffuseLightingq、SpecularLightingq及びAmbientLightingqを演算するために用いられる的確な数学的アルゴリズムが、本技術分野に属する当業者により周知であることは理解されるべきである。

0105

さらに第1のパスの一部を形成するステップ1010において、描画機能モジュール280は画素qについてプリシェーディング値を演算する。非限定的な実施形態において、ステップ1010は、カスタマイズ可能オブジェクト530のテクスチャ値(拡散色)により乗算されるものと、該乗算結果を加算するものとに照明成分を細分することを含んでもよい。このように、プリシェーディング値の2つの成分、即ち「Output_1q」(乗法性)「Output_2q」(加法性)が、画素qについて識別され得る。非限定的な実施形態において、Output_1q = DiffuseLightingq(即ち、「Output_1q」は画素qにおける拡散光値を示す)、及びOutput_2q = SpecularLightingq + AmbientLightingq(即ち、「Output_2q」は画素qにおけるスペキュラ光値と環境光値の合計を示す)である。無論、環境光成分がない場合や、画素処理サブプロセス780内以外において該成分が加算される際はステップ1010がいずれの実際の演算も含む必要がない。

0106

同様に第1のパスの一部を形成するステップ1020において、描画機能モジュール280は画素qに係るプリシェーディング値を一時記憶媒体に格納する。プリシェーディング値は、同一の照明条件化で同一のオブジェクトを観賞する全ての参加者に共有され得る。

0107

以下、各参加者について実行される第2のパスを示した図10Bを参照する。任意の参加者について実行される第2のパスは、各画素qについて実行されるステップ820〜840を含む。

0108

まず参加者Aの例を考慮する。ステップ820において、描画機能モジュール280は、画素qにおける適切な拡散色値を得るために、参加者Aについてのカスタマイズ可能オブジェクト(この場合オブジェクト530)のテクスチャを参照し得る。テクスチャは、まずテクスチャIDを得るためにオブジェクトIDに基づきオブジェクトデータベース1120が参照されることにより識別され、そして画素qにおける拡散色値を得るために、該得られたテクスチャIDに基づきテクスチャデータベース1190が参照されるものであってよい。結果である拡散色値は、DiffuseColor_530Aqで示される。具体的には、DiffuseColor_530_Aqは(参加者Aについて)画素qに対応する点におけるオブジェクト530のテクスチャのサンプル値(あるいは補間値)で表され得る。

0109

ステップ830において、描画機能モジュール280は画素qに係る画素値を演算し得る。「画素値」との文言が、スカラや複数成分のベクトルを言及し得るものであることは留意されるべきである。非限定的な実施形態において、複数成分のベクトルのような構成要素は、色(または色相、彩度)、彩度(色自身の強度)、及び輝度であってよい。「強度」との文言は、場合によって輝度成分を表すために用いられる。他の非限定的な実施形態において、複数成分ベクトルの複数の構成要素は、RGB(赤、緑及び青)であってもよい。1つの非限定的な実施形態において、画素qについてOutput_Aqで示される画素値は、拡散色に(一時記憶媒体からOutput_1qとして取得される)拡散光成分を増殖的に組み合わせ、さらに(一時記憶媒体からOutput_2qとして取得される)スペキュラ光成分及び環境光成分の和を加算することにより演算されるものであってもよい。即ち、
Output_Ap = (DiffuseColor_530_Aq * Output_1q) + Output_2q
となる。Output_Aqが画素qの複数成分(例えばRGB、YCbCr等)の各々について分離して演算されるものであってもよいことは理解されるべきである。

0110

そしてステップ840において、参加者Aについて、Output_Aqで示される画素qの画素値が参加者Aのフレームバッファに格納される。

0111

同様に、参加者B及びCについて、描画機能モジュール280はステップ820において画素qにおける適切な拡散色値を取得するため、各参加者についてのカスタマイズ可能オブジェクト(この場合オブジェクト530)のテクスチャにアクセスし得る。テクスチャは、まずテクスチャIDを取得するために、オブジェクトID及び参加者IDに基づきオブジェクトデータベース1120を参照することにより識別され、そして画素qにおける拡散色値を得るために、該得られたテクスチャIDに基づいてテクスチャデータベース1190が参照されるものであってよい。参加者B及びCについて画素qに係る、結果である拡散色値はそれぞれDiffuseColor_530_Bq及びDiffuseColor_530_Cqで示される。

0112

ステップ830において、描画機能モジュール280は、画素qに係る画素値を演算し得る。非限定的な実施形態において、参加者BについてOutput_Bq及び参加者CについてOutput_Cqで示される画素値は、拡散色に(一時記憶媒体からOutput_1qとして取得される)拡散光成分と増殖的に組み合わせ、さらに(一時記憶媒体からOutput_2qとして取得される)スペキュラ光成分と環境光成分との和を加算することにより演算されるものであってよい。即ち、
Output_Bq = (DiffuseColor_530_Bq * Output_1q) + Output_2q
であり、
Output_Cq = (DiffuseColor_530_Cq * Output_1q) + Output_2q
となる。Output_Bq及びOutput_Cqの各々が、画素qの複数成分(例えばRGB、YCbCr等)の各々について分離して演算されるものであってもよいことは理解されるべきである。

0113

そしてステップ840において、参加者Bについて演算された画素qの画素値Output_Bqが参加者Bのフレームバッファに格納され、参加者Cと画素値Output_Cqについても同様である。

0114

画素値Output_Aq、Output_Bq及びOutput_Cqが異なることにより、カスタマイズ可能オブジェクト530は参加者A、B及びCにつき異なってシェーディングされることが、図11に示される。

0115

故に、本発明の実施形態に係り、カスタマイズ可能オブジェクトの画素の計算集約的な放射輝度演算の決定は全ての参加者について一度なされ、画素値は各参加者について異なって終了することは理解されよう。

0116

カスタマイズ可能オブジェクト530に係る放射輝度/照明演算(例えばDiffuseLightingq、SpecularLightingq、AmbientLightingq)は参加者毎というよりはむしろ参加者のグループ毎に、(第1のパスにおいて)一度なされるため、このことはカスタマイズ可能オブジェクト530の複数の「配列」の生成において、演算量の低減を導き得る。例えば、カスタマイズ可能オブジェクト530の任意の画素qの各々について、Output_1q及びOutput_2qは一度演算され、そして共通のOutput_1q及びOutput_2qの値に基づき、参加者A、B、Cの各々について、(第2のパスにおいて)分離してOutputqが演算される。

0117

[変形例1]
変形例として、ステップ1020においてプリシェーディング値が格納される一時記憶媒体は、1人の参加者についての最終画像データが格納されるフレームバッファであってもよい。故に、ステップ1020は真の画素値が格納される以外の目的で、画素qに対応するフレームバッファのデータ要素を使用することにより実現される。例えば、画素qに対応するデータ要素は、色情報(例えばR、G、B)について通常用意される成分と、透過情報(α)について通常用意される他の成分とを含むものであってよい。

0118

具体的には、及び非限定的な例では、スペキュラ光及び環境光成分は、輝度(YCbCr空間において「Y」として参照)のような単一の値(スカラー)に縮小される。この場合、Output_1qは3つの成分を有するが、Output_2qは1つのみを有する。結果として、画素qについての単一の4フィールドデータ構造に、画素qについてのOutput_1qとOutpuut_2qとを格納することが可能であろう。故に、例えば各画素に4フィールドRGBA配列(ここで「A」はαまたは透過成分を表す)が割り当てられる場合、「A」フィールドはOutput_2q値を格納するために取り込まれ得る。さらにこのことは、一般オブジェクトに関係するこれらの画素「p」に係る3次元値のOutputpと、カスタマイズ可能オブジェクトに関係するこれらの画素qについて同時に格納する3次元値のOutput_1qと1次元値のOutput_2qとの双方を格納するために、4次元のエントリを用いる単一バッファ許容しうる。

0119

これを示すために、各参加者A及びBについて1つである、2つのフレームバッファそれぞれを示す図12を非限定的に参照する。フレームバッファの各々は、4成分の画素値を有する画素を含む。図12は、以下のステージにおける、1200A、1200Bにおいて画素p及びqの内容の内容の変化を示しており:
1210:一般オブジェクト520の描画に加えてステップ840の後。なお、オブジェクト520についての画素は、オブジェクト520に係る最終画素値(強度/色)を含む。これらは一度演算され、両フレームバッファに複製される。
1220:カスタマイズ可能オブジェクト530についての第1の処理パスに加えてステップ1020の後。なお、オブジェクト530についての画素は、オブジェクト530に係るプリシェーディング値を含む。これらは一度演算され、両フレームバッファに複製される。
1230: カスタマイズ可能オブジェクト530についての第2の処理パスに加えてステップ840の後。なお、オブジェクト530についての画素は、参加者の各々について異なる、オブジェクト530に係る最終画素値(強度/色)を含む。

0120

従って、処理の重要な部分は共有され得、放射輝度(照明)が演算されてカスタマイズを実行することができれば、放射輝度演算の共有を考慮しないカスタマイズに比べ、演算効率化の観点で潜在的に著しい改良が導かれることは理解されよう。

0121

[変形例2]
さらに、カスタマイズ可能オブジェクトが全ての参加者についてカスタマイズされる必要がないことは理解されるべきである。また、任意の数の参加者(全ての参加者よりも少なくてよい)の画面描画範囲内のカスタマイズ可能オブジェクトが、これら全ての参加者について異なるようカスタマイズされる必要もない。特に、任意のオブジェクトについて、参加者の第1のサブセットについて1つの手法、参加者の他のサブセットについて他の手法でカスタマイズされる、または複数の異なるオブジェクトについて、任意の観察者と同一の手法でカスタマイズされるようにもできる。例えば、3人の参加者A、B、C、1つの一般オブジェクト520(手前)及び2つのカスタマイズ可能オブジェクトE、Fを考慮する。カスタマイズ可能オブジェクトEが参加者A及びBについて任意の手法でカスタマイズされるが、参加者Cについては異なる手法でカスタマイズされるようにしてもよい。同時に、カスタマイズ可能オブジェクトFは参加者A及びCについて任意の手法でカスタマイズされるが、参加者Bについては異なる手法でカスタマイズされるようにすることもできる。この場合、カスタマイズ可能オブジェクトEについての描画処理が、参加者A及びBについて集約的に実行され、カスタマイズ可能オブジェクトFについての描画処理が、参加者A及びCについて集約的に実行される。

0122

従って、照明効果が保たれている間、カスタマイズされたオブジェクトの描画をより効率的に描画するための方法が開示された。故に、同一の放射輝度を保つカスタマイズの種別は、設定、人口統計、位置等に基づいて異なるテクスチャを用いて異なる参加者に提供するという状況は有用であろう。例えば参加者は、同一の臨場効果を有するが、異なる色や異なるロゴフラッグデザイン、言語等を有する態様で同一のオブジェクトを観賞することができる。いくつかの態様では、カスタマイズは、例えば年齢や地域基準により訂正される必要である、「グレーアウト」または「暗化(darken)」オブジェクトにも、カスタマイズは用いることができる。このような個人ベルのカスタマイズを用いる場合であっても、参加者により求められ、かつ正確かつ複雑な照明演算に起因するリアリズム妥協されない。

0123

[変形例3]
上記説明した態様では、一般オブジェクト及びカスタマイズ可能オブジェクトの各々を、描画機能モジュール280が別々に描画する方法について説明した。一方で、照明のようなエフェクトも含めてカスタマイズする場合については、一般オブジェクトには共通のエフェクト、カスタマイズ可能オブジェクトの各々には各観戦者が所望するエフェクトを適用することになる。このような場合、これらの処理により生成された画素で構成された画面は、一部のオブジェクトのみがエフェクトが異なる不自然な画面が生成されうる。極端な例では、一般オブジェクトが大半を占めている場合において、1つのカスタマイズ可能オブジェクトのみが異なる方向からの光源による照明効果を含めて描画された場合、該カスタマイズ可能オブジェクトは画面において観戦者に異質印象を与えうる。

0124

従って、本変形例では、カスタマイズ可能オブジェクトについて適用される照明等のエフェクトを一般オブジェクトにも反映させることで、生成される画面における違和感を低減させる方法について説明する。

0125

具体的にはまず、複数の観戦者に提供する画面の演算量を低減するために、一般オブジェクトについては、上述した実施形態と同様に生成する。その後、例えばカスタマイズ可能オブジェクトについて定義される照明を考慮してカスタマイズ可能オブジェクトを描画する処理を行う際に、該照明を既に描画した一般オブジェクトにも適用した場合に生じるエフェクトに係る演算も行う。一般オブジェクトに適用した場合のエフェクト係る演算は、例えばDeferred Rendering等により描画を行う場合には、描画範囲に係る各種G-Bufferが生成されているため、カスタマイズにより定義された照明による各画素の輝度変化等は容易に演算することができる。故に、カスタマイズ可能オブジェクトの描画とともに既に描画された画素にこれらの輝度変化等による画素値を例えば加算すればよい。

0126

このようにすることで演算量は多少増加するものの、カスタマイズ可能オブジェクトについて適用されたその他のエフェクトにより画面全体に生じる違和感を低減することもできる。

0127

なお、一般オブジェクトとカスタマイズ可能オブジェクトに係る描画処理の順番が上述した実施形態や変形例で言及されたが、順番は描画機能モジュール280の態様に応じて変化されるものであってよい。例えば、一般オブジェクトに係る描画処理が参加者について集中的に行われ、一般オブジェクトの描画結果が単一のフレームバッファに格納される場合、該処理の終了後、各参加者についてのフレームバッファが該単一のフレームバッファを複製することにより生成されてもよい。この場合、各参加者に依存するカスタマイズ可能オブジェクトに係る描画処理は分離して実行され、カスタマイズ可能オブジェクトについての描画結果は参加者に対応するフレームバッファに格納される。一方で、例えば、一般オブジェクトについての描画結果が(複数の参加者の)複数のフレームバッファの各々に格納される場合、カスタマイズ可能オブジェクトに係る描画処理は、一般オブジェクトについての描画の終了を待たずに実行され得る。即ち、両描画処理は並行して実行され、各参加者についてのゲーム画面が該参加者に対応するフレームバッファに生成される。

0128

[その他の実施形態]
例示的な実施形態を参照して本発明を説明してきたが、記載した例示的な実施形態に発明が限られるものでないことは理解されよう。以下の特許請求の範囲は、このような変形、等価な構成及び機能の全てを包含するように、広範な解釈を許容されよう。また、本発明に係る情報処理装置及び制御方法は、コンピュータにおいて該手法が実行されるプログラムにより実現可能である。プログラムは、コンピュータ読み取り可能な記録媒体に格納されることで、または電気的な通信回線を介して、提供/配信可能である。

0129

本出願は、その全体がここに参照により援用される、2013年9月11日に出願された米国仮出願第61/876318号の利益を主張するものである。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ