JP2019046430A - ビデオゲーム画像レンダリング方法及びシステム - Google Patents

Abstract

【課題】仮想環境内で該仮想カメラの動きに応じて、前記画像フレーム内に該環境素子の動きの様子をレンダリングする方法を提供する。
【解決手段】仮想環境における仮想カメラの視野にシーンの展開を描写させる形で、画像フレームを作成し、該仮想環境内で仮想カメラの動きに応じて、該シーンに該環境素子の動きの様子を前記画像フレーム内にレンダリングする。他の方法においては、仮想環境には仮想カメラ、注目のオブジェクト、少なくとも一部が仮想カメラと注目のオブジェクト間に配置されている環境素子が含まれて、シーンの展開を描写しつつ、一連の画像フレームを作成し、多数の画像フレームの進行に亘り、環境素子の一部の動きの様子をレンダリングして、移動した環境素子の一部がそれまで占領していた少なくとも１部のシーンに注目のオブジェクトを更に現わす。
【選択図】図１１

Description

本発明は、概して画像のレンダリングに関し、特に、ビデオゲームのコンテクスト内での画像のレンダリングに関する。

ビデオゲームの仮想環境には、仮想カメラ、プレイングキャラクタ、その他のオブジェクト等、各種のオブジェクトが含まれている。３人称ビデオゲームの場合、仮想カメラはユーザがそのアクションを制御するプレイングキャラクタを「見ている」。しかしながら、仮想カメラとプレイングキャラクタの間にある特定のオブジェクトが、プレイングキャラクタの表示を遮ることがある。これは、特に、仮想カメラがブッシュや他の植物近くにある時に発生しうる。この場合、プレイングキャラクタはもはや十分にスクリーン上にレンダリングされず、ユーザ（プレーヤ）は目視で自分のプレイングキャラクタと接触できず、ゲーム経験値に否定的な影響を及ぼし得る。仮想カメラの位置を障害物から離すことは簡単な解決法であるように思われるが、プレイヤは、常に仮想カメラの位置を独立的に制御できるとは限らない。更に、カメラがどこに配置されようと、植物はカメラに写りこまないままであることが多々ある。それ故、この問題の解決は、これからの研究に期待される。

第１の広い観点によると、処理実体により実行させることにより、該処理実体に方法を実行させることが出来るコンピュータ可読命令からなるコンピュータ可読媒体において、該方法は、仮想環境における仮想カメラの視野にシーンの展開を描写させる形で、画像フレームを作成し、該シーンには、環境素子が含まれており、該仮想環境内で仮想カメラの動きに応じて、前記画像フレーム内に該環境素子の動きの様子をレンダリングする、ことからなることを特徴とする、コンピュータ可読媒体を提供する。

第２の広い観点によると、仮想環境における仮想カメラの視野にシーンの展開を描写させる形で、画像フレームを作成し、該シーンには、環境素子が含まれており、該仮想環境内で仮想カメラの動きに応じて、前記画像フレーム内に該環境素子の動きの様子をレンダリングすることからなる方法を提供する。

第３の広い観点によると、処理実体により実行させることにより、該処理実体に方法を実行させることが出来るコンピュータ可読命令からなるコンピュータ可読媒体において、該方法は、ビデオゲーム用の仮想環境を維持し、該仮想環境には仮想カメラ、注目のオブジェクト、少なくとも一部が該仮想カメラと該注目のオブジェクト間に配置されている環境素子が含まれており、該ビデオゲーム内でシーンの展開を描写しつつ、一連の画像フレームを作成し、該シーンには該仮想カメラの視野内に前記仮想環境からのオブジェクトが含まれており、多数の画像フレームの進行に亘り、前記環境素子の一部の動きの様子をレンダリングして、移動した環境素子の一部がそれまで占領していた少なくとも１部のシーンに前記注目のオブジェクトを更に表す、ことからなることを特徴とする、コンピュータ可読媒体を提供する。

第４の広い観点によると、ビデオゲーム用の仮想環境を維持し、該仮想環境には仮想カメラ、注目のオブジェクト、少なくとも一部が該仮想カメラと注目のオブジェクト間に配置されている環境素子が含まれており、該ビデオゲーム内でシーンの展開を描写しつつ、一連の画像フレームを作成し、該シーンには該仮想カメラの視野内に前記仮想環境からのオブジェクトが含まれており、多数の画像フレームの進行に亘り、前記環境素子の一部の動きの様子をレンダリングして、移動した環境素子の一部がそれまで占領していた少なくとも１部のシーンに前記注目のオブジェクトを更に表すことからなる方法を提供する。

図１は、本発明の限定されない例示的な実施例を実装したゲーム装置の構成を示すブロック図である。 図２は、図１のゲーム装置によって実行されるゲームプログラムの要素を示す図であり、ゲームデータ処理機能及びゲームレンダリング処理機能を有するものである。 図３は、本発明の実施例によるゲームデータの一例を示す図である。 図４は、３Ｄグラフィック情景をディスプレィ装置に表示するためのゲーム画面に変換する処理の一例を示す図である。 図５は、各種の環境素子に関係付けられた衝突プリミティブ（要素）を有するシーンの一例を示す概略図である。 図６は、図５のシーンの概略図であり、仮想カメラ、関連付けされたカメラ衝突プリミティブ及びキャラクタを示す斜視図である。 図７は、キャラクタの「前に」環境素子（草木）をレンダリングすることにより、キャラクタのレンダリングを省いたシーンの一例を示す、スクリーン上のレンダリングを示す図である。 図８は、非限定的実施例による、環境素子の衝突プリミティブとカメラ衝突プリミティブとの衝突があった際に、環境素子の移動を演算する処理を示すフローチャートである。 図９は、カメラ衝突プリミティブと環境素子の衝突プリミティブが均衡状態で相互貫通した例を示す概略図である。 図１０は、図７のシーンをスクリーン上にレンダリングした図であり、キャタがスクリーン上にレンダリングされ、観者の視覚に入るように草木を後退させたシーンの図である。 図１１は、非限定的実施例による、環境素子が動く様子をレンダリングする処理を示すフローチャートである。 図１２は、他の非限定的実施例による、環境素子が動く様子をレンダリングする処理を示すフローチャートである。

図１は、本発明の限定されない例示的な実施例を実装したゲーム装置１の構成を示すブロック図である。ある場合には、ゲーム装置１は、Ｘｂｏｘ（登録商標）、Ｐｌａｙｓｔａｔｉｏｎ（登録商標）又はＮｉｎｔｅｎｄｏ（登録商標）ゲーム筐体といった専用のゲーム筐体である。また他の場合には、ゲーム装置１は、多目的ワークステーション又はラップトップコンピュータである。更に他の場合、ゲーム装置１は、スマートフォンのようなモバイル装置であり、また更に他の場合には、ゲーム装置１は携帯型ゲーム装置である。

ゲーム装置１は、少なくとも一つの処理装置１０、少なくとも一つのコンピュータ可読メモリ１１，少なくとも一つの入出力モジュール１５及び少なくとも一つの電源２７を有し、更にビデオゲームを遊ぶのに使用されるゲーム装置で見受けられるさまざまな部品も含まれる。ゲーム装置１の様様な部品は、データバス、コントロールバス、パワーバスなどのような一つ以上のバスを介して互いに通信することが出来る。

図１に示すように、プレイヤ７は、ディスプレィ装置５のスクリーンに表示されるゲーム画像を見ながら、ゲームコントローラ３を介してゲームの局面を制御することでゲームをプレイする。従って、ゲーム装置１はゲームコントローラ３から入出力モジュール１５を介して入力を受ける。ゲーム装置１は、また、ディスプレィ装置５及び／又はオーディオ装置（例えば、スピーカ、図示せず）に入出力モジュール１５を介して出力を供給する。他の実施例では、入出力モジュール１５に接続されるのは、一つ以上のゲームコントローラ３及び／又は一つ以上のディスプレィ装置５でもよい。

処理装置１０は、一つ以上のコアを有する一以上の中央処理ユニット（ＣＰＵ）を有する。また処理装置１０は、出力データを、ディスプレィ装置５のディスプレィの入出力モジュール１５に供給するためのビデオエンコーダ／ビデオコーデック（コーダ／デコーダ、図示せず）と接続された、少なくとも一つのグラフィック処理ユニット（ＧＰＵ）を有する。更に該処理装置１０は、オーディオ装置の入出力モジュール１５に供給される出力データを生成するためのオーディオエンコーダ／オーディオコーデック（コーダ／デコーダ、図示せず）と接続された少なくとも一つのオーディオ処理ユニットを有する。

コンピュータ可読メモリ１１は、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（リードオンリーメモリ）、フラッシュメモリ、ハードディスク駆動装置、ＤＶＤ／ＣＤ／Ｂｌｕｅｒａｙ（登録商標）及び／又は他の適切なメモリ装置、技術又は構成を有する。コンピュータ可読メモリ１１は、ゲームプログラム３３，ゲームデータ３４及びオペレーティングシステム３５などの多様な情報を格納している。

ゲーム装置１の電源が入ると、処理装置１０は処理装置１０を起動するブート処理を実行し、コンピュータ可読メモリ１１と通信する。特にこのブート処理ではオペレーティングシステム３５を実行する。オペレーティングシステム３５は、ゲーム装置に適した何らかの商用又は専用オペレーティングシステムである。オペレーティングシステム３５が実行されると、処理装置１０はディスプレィ装置５に表示する画像を生成し、ゲーム装置１はゲームコントローラ３を介してプレイヤ７が選択することの出来る多様なオプションや、プレイするビデオゲームを選択、及び／又は開始するオプションを表示する。プレイヤ７により選択／開始されたビデオゲームは、ゲームプログラム３３によってエンコードされている。

処理装置１０は該ゲームプログラム３３を実行して、エンコードされたビデオゲームに関連する多様な種類の情報処理機能を実行することが出来るように構成されている。特に、図２に示すように、ゲームプログラム３３を実行することで処理装置は、以下に述べるゲームデータ処理機能２２及びゲームレンダリング処理機能２４を実行することとなる。

ゲームレンダリング処理機能２４はディスプレィ装置５に表示されるゲーム画像の生成を含むものである。ここで、ゲームデータ処理機能２２は、ゲームの進行やゲームの現在状態を表す情報を処理することを含む（例えば、ディスプレィ装置５に表示する必要のないゲームに関する情報の処理）。図２では、ゲームデータ処理機能２２及びゲームレンダリング処理機能２４は、単一のゲームプログラム３３の一部を構成している。しかし、他の実施例では、ゲームデータ処理機能２２及びゲームレンダリング処理機能２４は、別個のメモリに格納された別個のプログラムであり、分かれた、恐らく遠方の処理装置により実行される場合もある。例えば、ゲームレンダリング処理機能２２は、ＣＰＵで実行することもでき、ゲームレンダリング処理機能２４はＧＰＵで実行することも出来る。

ゲームプログラム３３の実行中には、処理装置１０は、オブジェクト、キャラクタのような構成物、及び／又はあるゲームの規則に従ったレベルを操作し、ある種の人工的な知的アルゴリズムの適用を行う。ゲームプログラム３３の実行中、処理装置１０は、生成、ロード、格納、読み込みを行い、また、オブジェクトやキャラクタ及び／又はレベルに関するデータを持ったゲームデータ３４に全般的なアクセスを行う。図３は、本発明の実施例に基づくゲームデータ３４の例を説明する一例である。ゲームデータ３４は、前述の構成に関するデータを有しており、従って、オブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６を含む。

オブジェクトとは、ゲーム画像のフレーム（コマ）にグラフィカルに表示することの出来るゲーム環境における何らかの素子又は素子の部分を表す。オブジェクトは、建物、車両、家具、植物、空、大地、大洋、太陽及び／又は何らかの適当な素子を３次元的に表現したものである。オブジェクトは、数字、幾何学又は数学的な表現のような、他の非グラフィカルな表現であることもある。オブジェクトデータ４２は、ゲーム画像のフレーム内でのグラフィカルな表現のような、オブジェクトの現在表現についてのデータや、数字、幾何学又は数学的な表現についてのデータを格納する。オブジェクトデータ４２としては、画像データ、位置データ、材料／テクスチャデータ、物理状態データ、可視性データ、照明データ（例えば、方向、位置、色及び／又は強度）、サウンドデータ、モーションデータ、衝突データ、環境データ、タイマーデータ及び／又は該オブジェクトに関連する他のデータなどの属性データも格納することができる。オブジェクトの特定の属性データはゲームプログラム３３で制御可能である。

キャラクタは、オブジェクトに類似するが、属性は本質的により動的であり、オブジェクトが通常持たない追加的な属性を持っている。プレイングキャラクタのある属性は、プレイヤ７により制御することが出来る。またキャラクタ（プレイングキャラクタ又はノンプレイングキャラクタ）のある属性は、ゲームプログラム３３により制御され得る。キャラクタの一例をいくつかの非制限的可能性としてあげると、人、アバター、動物などである。キャラクタは、数字、幾何学又は数学的な表現のような他の非視覚的表現も持つことがある。キャラクタは、キャラクタが装備する武器、又はキャラクタが着る衣服などの1以上のオブジェクトと関連することがある。キャラクタデータ４６は、ゲーム画面のフレームにおけるグラフィカルな表現、又は数字、幾何学又は数学的の表現のような、キャラクタの現在表現についてのデータを格納する。キャラクタデータ４６は、画像データ、位置データ、材料／テクスチャデータ、物理状態データ、可視性データ、照明データ（例えば、方向、位置、色及び／又は強度）、サウンドデータ、モーションデータ、衝突データ、環境データ、タイマーデータ及び／又は該キャラクタに関連する他のデータなどの属性データも格納することができる。

ゲームデータ３４は、オブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６の表現及び／又は属性の一部である、ディスプレィ装置５に表示される際のゲームの現在の視野又はカメラアングルに関するデータ（例えば、１人称視点、３人称視点など）を含む。

ゲームプログラム３３を実行する際には、処理装置１０は、プレイヤ７がゲームを選択／スタートした後に、イニシャライズ段階を行い、ゲームをイニシャライズする。イニシャライズ段階は、必要なゲームのセットアップを実行し、ゲームの開始に際してゲームデータ３４を準備するために使用される。ゲームデータ３４は、ゲームプログラム３３の処理に伴って変化（即ち、ゲームのプレイ中）する。ここで“ゲームの状態”という用語は、ここではゲームデータ３４の現在の状態又は性質、従って、多様なオブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６及びそれらの対応する表現及び／又は属性を定義するために使用される。

イニシャライズ段階の後、ゲームプログラム３３を実行する処理装置１０は、一つ以上のゲームループを実行する。一つ以上のゲームループは、ゲームプレイ中継続的に実行され、ゲームデータ処理機能２２及びゲームレンダリング処理機能２４はルーチン的に実行されるようになる。

ゲームループは、（i）ゲームデータ処理機能２２がゲームコントローラ３を介したプレイヤの入力処理を行い、ゲーム状態をアップデートし、その後（ii）ゲームレンダリング処理機能２４がアップデートされたゲーム状態に基づいてディスプレィ装置５に表示すべきゲーム画像を生成するように機能する。ゲームループは時間経過を追跡し、ゲームプレイの進行を制御する。プレイヤが入力する以外のパラメータが、ゲーム状態に影響を与える点は注目すべき点である。例えば、多様なタイマー（即ち、経過時間、特定のイベントからの時間、一日のバーチャル時間など）がゲーム状態に影響を与え得る。別の言い方をすると、ゲームは、プレイヤ７が入力を行わなくても進行しており、従って、プレイヤの入力が無くてもゲーム状態はアップデートされるのである。

一般的に、ゲームデータ処理機能２２が毎秒実行する回数は、ゲーム状態に対する毎秒のアップデート回数を規定し（以後、「アップデート／秒」と称する）、ゲームレンダリング処理機能２４が毎秒実行する回数は、毎秒のゲーム画像のレンダリングを規定する（以後、「フレーム／秒」と称する）。理論的には、ゲームデータ処理機能２２とゲームレンダリング処理機能２４は、毎秒の実行回数が同じと考えられる。特定の非限定的な例として、目標が毎秒２５フレームだとすると、ゲームデータ処理機能２２とゲームレンダリング処理機能２４は、共に４０ｍｓ毎に実行可能な能力（即ち、１ｓ／２５ＦＰＳ）が望ましい。ゲームデータ処理機能２２が実行し、その後にゲームレンダリング処理機能２４が実行する場合、ゲームデータ処理機能２２とゲームレンダリング処理機能２４は共に４０ｍｓのタイムウインド（time window）で実行される必要がある。その時のゲーム状態によって、ゲームデータ処理機能２２及び／又はゲームレンダリング処理機能２４を行う時間は変わり得るものである。もしゲームデータ処理機能２２とゲームレンダリング処理機能２４が共に４０ｍｓ以下で実行されるなら、ゲームデータ処理機能２２とゲームレンダリング処理機能２４の次のサイクルを実行する前にスリープタイマーを使用することが出来る。しかし、ゲームデータ処理機能２２とゲームレンダリング処理機能２４が与えられたサイクルを実行するのに４０ｍｓ以上掛かる場合には、一定のゲームスピードを維持するためにゲーム画像の表示をスキップするのも一つのテクニックである。

目標となる毎秒フレーム数が、２５フレーム／秒以上又は以下の場合（例えば、６０フレーム／秒）もあるが、人間の目がゲーム画像フレームのレンダリングにおいて何らの遅れも感じないように、ゲームデータ処理機能２２とゲームレンダリング処理機能２４は２０から２５回／秒以下とならないように実行されることが望ましい。当然、フレームレートが高くなればなるほど、画像間の時間は短くなり、ゲームループを実行するに必要な処理装置もより高性能となり、ＧＰＵのような特別な処理装置に頼ることとなる。

他の実施例では、ゲームデータ処理機能２２とゲームレンダリング処理機能２４は別々のゲームループで、従って独立した処理で実行されることもある。こうした場合、ゲームレンダリング処理機能２４が実行中の時であっても、ゲームデータ処理機能２２は特別のレート（即ち、特別なアップデート回数／秒）でルーチン実行することが出来、またゲームデータ処理機能２２が実行中かどうかに関係なく、ゲームレンダリング処理機能２４は特別のレート（即、特別なフレーム数／秒）でルーチン実行することが出来る。

ゲームデータ処理機能２２とゲームレンダリング処理機能２４をルーチン的に行う処理は、当業者の範囲における多様な技術に基づいて実行され、そうした技術は本明細書において、ゲームデータ処理機能２２とゲームレンダリング処理機能２４がどのように実行されるかの非限定的な一例として述べられる。

ゲームデータ処理機能２２が実行されると、ゲームコントローラ３を介したプレイヤ入力（もし有れば）及びゲームデータ３４が処理される。特に、プレイヤ７がビデオゲームをプレイする際には、プレイヤ７は、いくつかの例を挙げるが、左に移動せよ、右に移動せよ、ジャンプせよ、撃て、などの多様なコマンドをゲームコントローラ３を介して入力する。プレイヤが入力すると、ゲームデータ処理機能２２はゲームデータ３４をアップデートする。別の言い方をすると、オブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６がゲームコントローラ３を介したプレイヤの入力に反応してアップデートされる。なおゲームデータ処理機能２２が実行するたびにゲームコントローラ３を介したプレイヤ入力がある訳では無い。プレイヤ入力が入力されなくても、ゲームデータ３４は処理され、アップデートされる。こうしたゲームデータ３４のアップデートは、表現及び／又は属性がゲームデータ３４に対するアップデートを規定しているとき、オブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６の表現及び／又は属性に応じて行われる。例えば、タイマーデータは一つ以上のタイマー（例えば、経過時間、特定のイベントからの経過時間、一日のバーチャル時間など）を規定し、それらはゲームデータ３４（例えば、オブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６）のアップデートを生じさせる。他の例として、プレイヤ７によって制御されないオブジェクトが衝突すると（跳ね返ったり、合流したり、砕けたりなど）、ゲームデータ３４、例えばオブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６は衝突によりアップデートされる。

一般的に、ゲームデータ３４（例えば、オブジェクト、レベル及び／又はキャラクタの表現及び／又は属性）はゲームの３次元（３Ｄ）グラフィックシーンを規定するデータを表す。一つ以上の３Ｄグラフィックオブジェクトを含む３次元（３Ｄ）グラフィックシーンを、ディスプレィ装置５に表示する２次元（２Ｄ）のラスタライズされたゲーム画像に変換する処理は、一般的にレンダリングと呼ばれる。図４に、３Ｄグラフィックシーンをディスプレィ装置５にスクリーンを介して表示するためのゲーム画像に変換する処理の例を示す。ステップ５２で、ゲームデータ処理機能２２は、ゲームの３次元（３Ｄ）グラフィックシーンを表現するデータを処理して、このデータを複数のバーテックスデータに変換する。バーテックスデータはレンダリングパイプライン５５（グラフィックパイプラインとしても知られている）により処理するのに適している。ステップ５５では、ゲームレンダリング処理機能２４がレンダリングパイプラインによりバーテックスデータを処理する。レンダリングパイプラインの出力は、スクリーンを介してディスプレィ装置５に表示する一般的なピクセルである（ステップ６０）。

より詳細に述べると、ステップ５２で、グラフィックシーンの３Ｄグラフィックオブジェクトは、一つ以上の３Ｄグラフィック要素（primitive）に細分化される。要素は、レンダリングのための幾何学的な存在（例えば、点、線、ポリゴン、表面、オブジェクト、パッチなど）を規定するために互いにグループ化され及び／又は接続された一つ以上のバーテックスのグループである。各３Ｄグラフィック要素毎に、バーテックスデータがこの段階で生成される。各要素のバーテックスデータは一つ以上の属性（例えば、位置、色、法線又はテクスチャ座標系情報など）を含むものである。バーテックスデータを引き出す際に、カメラ変換（a camera transformation）（例えば、回転変換）が行われ、３Ｄグラフィックシーンの３Ｄグラフィックオブジェクトを、現在の視点又はカメラアングルに変換する。また、バーテックスデータを引き出す際に、光源データ（例えば、方向、位置、色及び／又は強度）が考慮される。この段階で引き出されたバーテックスデータは、一般的にレンダリングパイプラインに送られるバーテックスの順序付きリストである。順序付きリストのフォーマットは一般的にレンダリングパイプラインの特定な実行に依存する。

ステップ５５で、ゲームレンダリング処理機能２４はバーテックスデータをレンダリングパイプラインにより処理する。レンダリングパイプラインはよく知られており（例えば、OpenGL、DirectXなど）、レンダリングパイプラインの実行に用いられる特定のレンダリングパイプラインに拘わらず、レンダリングパイプラインの一般的な処理は、３Ｄシーンの２Ｄラスタ表現（例えば、ピクセル）を生成することである。レンダリングパイプラインは、一般的に、バーテックスデータの２次元（２Ｄ）スクリーン空間への投影位置を計算し、ディスプレィ５に出力するためのゲーム画像（例えば、ピクセル）を引き出すために、光、色、位置、情報、テクスチャ座標を考慮に入れた多様な処理及び／又は他の適当な処理を行なう（ステップ６０）。

ある場合には、ゲーム装置１はインターネットのサーバーと一つ以上のインターネット設備の間に配置される。従って、複数のプレイヤが同じオンラインゲームに参加することが出来、ゲームプログラムの機能（ゲームレンダリング処理機能及び／又はゲームデータ処理機能）は、少なくとも一部をサーバーにより実行することも可能である。

ビデオゲームのゲーム環境は、仮想カメラ、プレイングキャラクタ、複数の環境素子、更に他のオブジェクト等、各種のオブジェクトを含んでいる仮想環境である。仮想環境内のカメラの位置やアングルは、仮想カメラから一般的に外に向けて広がる仮想環境の領域内に、オブジェクトを含んだ視界を定めている。仮想カメラからは、該仮想カメラの視界内にあるサブセットのオブジェクトだけを見ることができ、プレイングキャラクタを制御しているゲームのプレイヤが、該サブセットのオブジェクトをスクリーン上にレンダリングする。どのオブジェクトが見えるかは、仮想カメラに対してそれらオブジェクトが介在する位置（Ｚバッファ位置とも呼ばれる）に加えて、視界内にあるオブジェクトの透明度の機能による。

環境素子に関しては、柔軟なものもある。柔軟で適切な環境素子の例としては、（葦、枝、葉、つる、藻を含む）植物、無生物（旗、ビーズカーテン、垂直ブラインド等）、死骸等のオブジェクトがある。図５は、柔軟な環境素子の非限定的な例として、死骸５０２及び植物５０４を示している。図に示すように、各環境素子は、1以上の「骨」（セグメント）及び、スクリーン上にはレンダリングされない対応する「衝突プリミティブ」と関連しており、衝突計算に使われるが、これは後に説明する。例えば、植物５０４は、複数の枝を有しており、各枝は、1以上の骨５１４、５１６、５１８により、対応する囲み衝突プリミティブ５２４、５２６、５２８（カプセル等の、例えば、半球によって両端が覆われている円柱状のもので、簡単な形状を有している）と共に表現される。同様に、死骸５０２は、骨５３２、５３４、５３６に対応したカプセル様の衝突プリミティブ５４２、５４４、５４６に囲まれた該骨の配列により表現される。環境素子が多数の骨及び対応するカプセル様の衝突プリミティブと関連付けられている場合、カプセル同士は、異なる寸法を有するかもしれない。所定のカプセルの一端側半球の半径は変動し、変動することでランタイムを定義することが出来る。他の実施例では、衝突プリミティブはカプセルである必要は無く、その代わりにプリズム、又は他の３次元形状であり得る。

環境素子５０２、５０４は、柔軟な特性を有する。更に、仮想環境内では自然位置が存在しており、その位置に対して、各環境素子が、反発力や重力により偏向することが出来る。例えば、単一の骨によって表現される反発力のある葦の場合、ベースポイントが与えられ、その周りで骨が回転する。骨は仮想環境内で自然位置を有しており、その反発力は、ベースポイントに絶えず付随する形で、環境素子内で動かないままである自然位置に対する偏向力により決めることが出来る。もし偏向力が、他のオブジェクトと骨の衝突プリミティブとの衝突に負けたら、反発力のある葦は、ベースポイントの周りを揺れるようにレンダリングされ、その反発力により、弾力のある葦は、もしオブジェクトが動けば（オブジェクトが動いた時）その自然位置に戻るだろう。

例えば図５の植物５０４や死骸５０２のように、相互に連結した多数の骨を有する複雑な例では、それぞれの骨にベースポイントが設定されており、該ベースポイントの周りに対応する骨が回転しているが、ベースポイントも仮想環境内で動くことが出来る。そして、衝突の間に、骨同士の間で力の移動が起こる。例えば、骨は自然位置を有しており、該骨の反発力は、対応するベースポイントに絶えず付随する形で、自然位置に対する偏向力により決めることが出来る。もし偏向力が、他のオブジェクトと特定の骨の衝突プリミティブ（例えば、５２４、５２６、５２８、５４２、５４４、５４６）との衝突に打ち勝てば、対応する枝等はベースポイントの周りで揺れるようにレンダリングされるが、衝撃力のいくらかは、衝撃を与えられた骨に連結した他の骨に伝わる。このため、連結した骨は、更に他の連結した骨に移る移動を経験するだろう。もしオブジェクトが取り除かれると（取り除く時）、骨はその反発力により、骨の自然位置に戻るようにレンダリングされる。

ある実施例では、仮想カメラと関連付けられた衝突プリミティブが、環境素子（即ち、より具体的に言うと、上述した環境素子の衝突プリミティブ）と衝突ことがある。特に、図６に示すように、仮想カメラ６０２は、該カメラの衝突プリミティブ６０４（以降、「カメラ衝突プリミティブ」と呼ぶ）と関連付けられ、スクリーン上にはレンダリングされないものの、衝突計算に使用される（追って、説明する）。カメラ衝突プリミティブ６０４に関する更なる詳細は、図６を参照して説明する。特に、ある実施例では、仮想カメラ６０２は、カメラ衝突プリミティブ６０４内に（例えば、その端部に）配置される。別の実施例では、カメラ衝突プリミティブ６０４は、仮想カメラ６０２と注目のオブジェクトの間の、仮想カメラ６０２の前に配置される。ある実施例では、ゲームは３人称ゲームであり、注目のオブジェクトはプレイングキャラクタ６０６である。仮想カメラ６０２とプレイングキャラクタ６０６は相対的に動くが、仮想カメラ６０２は、プレイングキャラクタ６０６を含めるように絶えず正しい位置に置かれるので、カメラ衝突プリミティブ６０４は、仮想カメラ６０２とプレイングキャラクタ６０６の間に配置されるのである。仮想カメラ６０２の動きは、仮想環境内で仮想カメラ６０２が平行移動（translation）するか、仮想環境内で固定場所に対して仮想カメラ６０２の方位が変化するかのいずれかである。

カメラ衝突プリミティブ６０４は、多くの形状を取ることが出来、そのうちの１つはカプセロイドである。カプセロイドは、特定の長さを有する３Ｄ形状であり、その両端部は、潜在的に異なる半径を有する半球により覆われている。仮想カメラ６０２近くにあるカメラ衝突プリミティブ６０４の端部にある半球の半径は、プレイングキャラクタ６０６近くにあるカメラ衝突プリミティブ６０４の端部の半径より小さくすることが出来る。カプセロイドの両端の半球の半径は各種変えることができ、これによりランタイムを定義することができる。また、カメラ衝突プリミティブ６０４は、仮想カメラ６０２とプレイングキャラクタ６０６間の距離を延長する必要は無い。むしろ、カメラ衝突プリミティブ６０４は、その長さを短くすることができ、例えば、仮想カメラ６０２とプレイングキャラクタ６０６間の距離の、９０％、７５％、５０％、若しくはこれより短いところで終わることもある。絶対的な意味で、又は、仮想カメラ６０２とプレイングキャラクタ６０６間の距離に対する相対的な意味で、このカプセロイドの長さを各種変えることが出来、これによりランタイムが定義される。

図７は、仮想カメラ６０２から、３人称視点で見た例を示しており（図７には仮想カメラは示されていないが）、ここには仮想カメラの視野で見えるオブジェクトが含まれている。この例では、目に見えるオブジェクトは、床７０２、影７０４及び葉７０６、７０８、７１０である。葉７０６、７０８、７１０は、柔軟性及び弾力性があり、それらの自然位置は図７に示されている。葉７０６、７０８、７１０は、共通の植物の一部であり、互いに連結した骨と関連付けられる。このため、各葉の動きは、他の葉に対して影響を及ぼす。図７は、カメラ衝突プリミティブ６０４（図７には示されていない）の影響は無く、スクリーン上にレンダリングされた図を示しており、葉７０６の「後ろ」の位置にいるプレイングキャラクタ６０６は視界から遮られ、図には示されない。プレイングキャラクタ６０６は、環境素子（この場合は、葉７０６）を含む、少なくとも１つのオブジェクトにより視界が遮られることがわかる。

一実施例では、カメラ衝突プリミティブ６０４と、葉７０６、７０８、７１０と関連付けられた衝突プリミティブ（図７には示されていない）とが衝突すると、1以上の環境素子（この場合、葉７０６、７０８、７１０）を外側に曲げることが出来るが、以下説明する。

処理実体（即ち、プロセッサ１０）が行うレンダリング処理の概要を、図１１に言及して説明する。ステップ１１１０で、処理実体は、ビデオゲームの仮想環境を維持する。ここで思いおこすと、環境素子には、仮想カメラ６０２、注目のオブジェクト（プレイングキャラクタ等）及び、仮想カメラと注目のオブジェクト（葉７０６等）の間で少なくとも一部が配置された環境素子を含めることができる。ステップ１１２０で、処理実体は、ビデオゲーム内で、即ち、ゲームレンダリング処理機能２４の一部として、シーンの展開を描写している一連の画像フレームを作成している。シーンには、仮想カメラの視野内で、仮想環境からのオブジェクトが含められる。ステップ１１３０で、複数の画像フレームの進行に亘って、処理実体は、仮想カメラ６０２が仮想環境内で動くと環境素子の一部の動き（例えば、たわみ）の出現をレンダリングする。移動した環境素子の一部がそれまでに占領していたシーンは、それまで出現していなかった注目のオブジェクトの一部に取って代わる。このようにして、注目のオブジェクトが、移動した環境素子の一部がそれまでに占領していたシーンの少なくとも一部に更に現われる。

このために、図８に言及する。図８は、プレイングキャラクタの姿を仮想カメラから隠している環境素子の動きを出現させる処理のステップが示されている。この処理は、処理実体が実行するコンピュータ可読命令にエンコードされる。該処理は、関連付けられた衝突プリミティブを有するシーンで、一部又は全ての環境素子の、一部又は全てのセグメントに適用することができる。この処理は、フレーム毎に実行することが出来る。ただし、それは必ずしも必要ではなく、該処理は、計算資源を省くためにそれほど頻繁に実行しなくてもよい。カメラ衝突プリミティブ６０４を定義することが出来たと仮定し、これは初期化段階でなされる。

ステップ８１０で、処理実体は、環境素子の特定のセグメントの衝突プリミティブとカメラ衝突プリミティブとの新たな衝突があるか、又は進行中の衝突があるかを検知する。動いている仮想カメラと関連付けられたカメラ衝突プリミティブが特定のセグメントの衝突プリミティブと接触し始めたことがわかれば、衝突は「新しい」と考えることが出来る。衝突は、単一のフレームの間続くことがある。また、衝突は少なくとも数フレームに亘り続く場合もあり、このため、後続のフレームにおいて、最初に「新しい」衝突と考えられたものが、その後、「進行中の」衝突に考えられる。仮想カメラがパッタリ停止しても、カメラ衝突プリミティブと特定のセグメントの衝突プリミティブ間の接触はまだあるので、ステップ８１０で衝突は「進行中」と検知することが出来ると解釈すべきである。

ステップ８１０で新しい又は進行中の衝突が実際に検知されると、ここで処理は、ステップ８２０に進み、「接触トルク」を決定する。即ち、該衝突で発生した、特定のセグメントの衝突プリミティブにかかる力（及び／又はそのベースポイント周りのトルク）を演算する。「接触トルク」の演算を実行するための非限定的な技術については、後述する。

カメラ衝突プリミティブと環境素子の少なくとも１つの衝突プリミティブとの衝突が検知されたときは、仮想カメラそれ自体が環境素子と衝突したのではなく、あくまでその衝突プリミティブと衝突したと解釈すべきである。環境素子は、十分に仮想カメラと近いので、実際に該カメラと接触しなくてもその外観が隠れてしまう。

ステップ８２０において衝突で発生する接触トルクの演算が終了すると、処理はステップ８３０に進み、特定のセグメントの次の位置及び速度を、数ある中で、ステップ８２０で演算した接触トルクに基づく一連の数学方程式に従って演算する。この演算を実行するための非限定的テクニックについては後述する。基本的に、ステップ８２０で演算した接触トルクは、セグメントのベースポイントに関して適用することが出来る他のトルクと共に、コンピュータで演算し、これがトルクの和となり、（その和がゼロで無い限り）特定のセグメントが移動する。トルク演算の例は、環境素子の固有の反発力又は重力に由来する。

新しい又は進行中の衝突がステップ８１０で検知されなければ、処理はステップ８４０に進み、処理実体は特定のセグメントが動いているかどうかを決定する。

ステップ８４０で処理実体が、特定のセグメントが動いていると決定すると、処理実体はステップ８３０に進み、前述したように、特定のセグメントの次の位置及び速度を一連の数学的方程式に従って演算する。もはや新しい、又は進行中の衝突は無いので、動きはもはや接触トルクによるものではなく、ゲーム中の他のファクタ、即ち、特定の環境素子を自然位置に戻す偏向力や、処理が実行され、特定のセグメントに連結した環境素子の他のセグメントを動かすことにより起こる力に基づいてなされるが、これに限定されるわけではない。

ステップ８４０で、処理実体が特定のセグメントが動いていないと決定すれば、その時次のステップはステップ８５０となる。この処理により、特定のセグメントの位置及び速度の変更は無い。

最終的には、カメラ衝突プリミティブと特定の環境素子に関連付けられた衝突プリミティブとは平衡状態に達すると理解される。この平衡状態では、トルクの和はゼロである。この点において、図９を見てみると、トウモロコシの茎９０２のカプセル様の衝突プリミティブ９０４とカメラ衝突プリミティブ９０６間で達した平衡状態が図示されている（カプセロイドの大端側視点から横方向に見て）。カメラ衝突プリミティブ９０６との衝突の結果、衝突プリミティブ９０４は、図の底部に対してわずかに回転している。このようにして、トウモロコシ９０２は、動いたり／撓んだりしてレンダリングされる。ゼロサムトルクはトウモロコシ９０２の反発力によりバランスを取った接触トルクから生じる。

図９の実施例では、平衡状態で、衝突プリミティブ９０４とカメラ衝突プリミティブ９０６が相互貫通している。その他の実施例では、トウモロコシ９０２の衝突プリミティブ９０４とカメラ衝突プリミティブ９０６は相互貫通しないで、平衡状態に達するよう強制される。これにより、トウモロコシ９０２がより撓んでレンダリングされる。何故なら、仮想カメラ６０２の位置は、ユーザによる制御に依存しつつ、ゲームプログラムにより決定されているが、該仮想カメラの位置に密接に係わっているカメラ衝突プリミティブ９０６により衝突プリミティブ９０４がより押しのけられるからである。

図７の葉７０６、７０８、７１０の例に戻り、各葉は個々の衝突プリミティブにより表わせられ、葉同士は共通の茎又は軸（図の底部の先にある）に連結していると仮定して、図１０を見ると、平衡状態に達した後、図８の処理の効果が視覚的に証明される。特に、プレイングキャラクタの姿を仮想カメラから隠していた葉７０６が、今移動し、どかされ、それまで隠れていたプレイングキャラクタ６０６が今見えている。特に、処理実体は、葉７０６の動きの様子をレンダリングすることにより、仮想カメラの視野を明確にした。

図７と図１０を比較すると、画像中心、即ちカメラ衝突プリミティブ（図１０には示されてはいないが）に対する方向においてとはいえ、葉７０８はわずかに移動している。これは、葉７０６、７０８が同じ軸に連結されているため、葉７０６の右側への大きな移動が、葉７０８の右側へのわずかな移動を誘発したという事実による。どの程度までモーションの移転が行われるかは、ゲームプログラムの洗練レベルに依存する。いずれにせよ、ゲームプログラムにより、葉７０８に大きな右方向の力がかかったとしても、葉７０８の衝突プリミティブに実行した時の図８の処理で、カメラ衝突プリミティブとの衝突が検知され、それ自身の部分だけで仮想カメラとプレイングキャラクタとの視線の障害は終わることはない。

仮想カメラが仮想環境内で移動し、環境素子の各衝突プリミティブとカメラ衝突プリミティブ間で新たに検出された衝突により、新たな環境素子が移動する時、上記した仮想カメラの視野の明確性はダイナミックに進行中である。

非限定的接触トルクの演算アルゴリズム
（カメラ衝突プリミティブと環境素子の衝突プリミティブとの）衝突の検知に付け加えて、環境素子の次の位置及び速度を演算するためにステップ８３０を実行する非限定的アルゴリズムについて説明する。ここで、環境素子の衝突プリミティブは、ベースポイント周りを回転するので、次の位置及び速度は角度測定であると考えられる。ただし、これはあらゆる実施例で必要ではない。一般的に言って、環境素子は初期自然位置及びバネ定数により決まる反発力を有する、減衰したバネとしてモデル化されるが、これはあらゆる実施例で必要なわけではない。

図８において、最初のステップは、衝突しているプリミティブ、即ち、柔軟な素子の衝突プリミティブであるＰ１（この場合、枝）とカメラ衝突プリミティブであるＰ２におけるセグメント上の３Ｄで、２つの最も接近した点を見つけることである。一旦この２つの最も接近した点が見つかれば、枝が回転する中心であるベースポイント、点Ｐｂを見つけることに進む。本非限定的モデルにおいては、枝は回転するだけであり、平行移動（translate）したり、引き伸ばされたりしない。ただし、他の実施例では、このより複雑な行動も考慮されるかもしれない。親枝及び子枝は、複雑に互いに影響を及ぼすだろうが、これはゲームプログラムにより処理される。

カメラ衝突プリミティブと特定の枝の衝突プリミティブとの衝突により、回転或いはその枝を軸としての回転が起こることを説明する。最初に、ｄベクトルを、Ｐ２からＰ１へ向かうベクトルと定義する。

そしてこの方向（単位ベクトル）を次のように記載する。

カメラ衝突プリミティブと、枝と関連付けられた衝突プリミティブの衝突により発生する力には、次の式を使うことができる。

ここで、ｒ＝ｒ_１+ｒ_２であり、ｒ_１は、枝のカプセルの半径であり、ｒ_２は、枝と衝突しているカメラ衝突プリミティブの半径（２半径のカプセルを有するカプセロイド用であり、ｒ_２は接触ポイントでの半径である）である。これらのパラメータは、ユーザが入力する。カッコ内の用語は、カプセル／カプセロイドが最もからみ合い、長さｄ（衝突プリミティブ間の最小距離）がゼロの時に最大の力が発揮されることを確実にする比率を差し引いた単位である。

ファクタｍは、多数の値で微調整することができる。

ここで、ｆは、メインファクタであり、柔軟なセグメントを有する各環境素子に対してユーザが入力する。また、ｐはカメラ衝突プリミティブに依存しており、ユーザにより入力する乗数である。ファクタμは、枝の衝突プリミティブとキャラクタ、又はカメラ衝突プリミティブとが衝突した際、該枝が異なる形で反応するようにするための別の乗数である。最終的に、ファクタｆｖは、速さ効果乗数であり、このため、もしキャラクタが枝の中に駆け込んだ場合、キャラクタがゆっくり枝に移動した場合と比較して植物はより大きく動く。即ち、

ここで、ｖは仮想カメラ（或いは枝に駆け込むキャラクタ）の速度の標準であり、ｓは、（ユーザが定義可能な）速度効果乗数である。

このようにして、上記した数１により、枝の衝突プリミティブと（この場合）カメラ衝突プリミティブとの衝突構造から、フレーム毎に枝が受ける力を演算する。この力は耐えず作用し、プリミティブ同士が相互貫通している限り続く。それらがかろうじて接触している時は、力はとても小さいものとなり、相互貫通するにつれ、力は増してきて、やがて滑らかな動きになる。それらの構造は依然として、休み位置／平衡位置で相互貫通している。

上記したように演算した力は、接触トルクを発生させるために使用する。何故なら、枝はそのベースポイント周りを回転するからである。接触トルクに使用するレバーは、次のとおりである。

このようにして、枝に発生した接触トルクは、以下のようになる。

次の位置及び速度を演算するための非限定的アルゴリズム
枝と他の特定の柔軟環境素子は、減衰ばねとしてシミュレーションすることができる。接触トルクを演算している同じフレーム中、バネ力モデルをシュミレーションし、結果として生じたトルクを接触トルクに加える。枝はトルクを使用しているので、必然的にその量は、角度で測る。

このシミュレーションにおいて、減衰力は枝の速度を妨害し、次のように計算する。

ここでｋは、ユーザが入力することができる定数であり、「減衰ファクタ」と呼ばれるものである。ωは、このシステムの固有振動数であり、これもまたユーザが定義することができる。ｖは、角速度を示す。減衰力に加えて、バネ力は枝の転置を妨害し、次のように計算される。

ここで、ω（数３でも使用されている）は、このシステムの自然振動数である。Ｘは、枝の角度位置である。

次の角度位置は、現在の位置を知ることで見つけることができる。次の運動方程式を使用することが出来る。

ここで、Δｔは、1フレーム継続時間であり、定義によれば、速度は位置の微分

であり、加速度は、位置の２階微分値

であり、次の式に続く。

数５を使うためには、依然として、フレーム毎に変化する速度ｖ及び加速度aが必要となる。速度に関しては、依然として運動方程式を使用しつつ、第１近似度を使用することが出来る。即ち、

加速度は、速度の微分値であることは公知のことであり、即ち、

これが数６に繋がる。

数５及び数６において、加速度値を決定する必要がある。ニュートンの法則から、

。 パラメータは沢山あるので、便宜上、ｍ＝１を使用する。複数のトルクを使用しているので、加速度は、全てのトルクの和となる。即ち、

このように、フレームにおける次の角度位置及び速度を計算する最終式は次のようになる。

減衰バネモデルの下では、環境素子はその自然位置に戻りたいという傾向性（ばね定数により定義できる）がある。該自然位置は、環境素子の衝突プリミティブとカメラ衝突プリミティブとの間にそれ以上の接触が無いように仮想カメラが離れる時の位置であると再び仮定できる。

別の実施例では、環境素子の衝突プリミティブとカメラ衝突プリミティブとの間にまだ接触があるとしても、環境素子がその自然位置に戻ることが出来る。これは、仮想カメラが静止しているか、又は特定の閾値より速度が小さい時に設定することができる。即ち、カメラ衝突プリミティブが、低速度で視野明確化効果を持つのを止める。このようにして、環境素子がその自然位置に戻った結果、（図７に示すように）プレイングキャラクタが仮想カメラから再び姿を消すことになる。これにより、プレイヤが、プレイングキャラクタを十分に見ることができなくなるが、特定の柔軟な環境素子に追加したリアリズムとして感知できるかもしれない。例えば、一連のビーズを有するビーズカーテンを想像してみてほしい。該カーテンは、仮想カメラとプレイングキャラクタとの間のある距離にわたり、横梁から縦方向に垂れ下がっている。この一連のビーズは、重力により、まっすぐな垂直方向の位置に戻りたがる傾向がある。プレイヤは、プレイングキャラクタがもっとはっきりと見えるように（即ち、はっきりレンダリングされるように）動的シーンの間にビーズカーテンが仮想カメラの視界から動くことを期待しているが、それと等しく、シーンが静的になったときにビーズカーテンが垂直なもとの位置に戻ることからくるリアリズムを期待する。これは、カメラ衝突プリミティブに対応する実際とは異なる形態のビーズカーテンと比較してよりリアルなものとして感じることができる。

更に別の実施例では、プレイングキャラクタが仮想カメラの仮定上の視野から離れたらすぐに、環境素子がその自然位置に戻ることが出来る（即ち、プレイングキャラクタは仮想カメラの前に障害物が無くとももはや見えない）。

図１２においては、ビデオゲームの仮想環境を維持するステップ１２１０を有する処理が規定されている。仮想環境には、仮想カメラ、注目のオブジェクト及び、少なくとも一部が仮想カメラと注目のオブジェクトの間に配置されている環境素子が含まれている。この方法は、一連の画像フレームを、ビデオゲーム内でシーンの展開を描写しつつ作成するステップ１２２０を有している。このシーンには、仮想カメラの視野内に仮想環境からのオブジェクトが含まれている。該処理は、更に、環境素子の一部の動きをレンダリングするステップ１２３０が含まれ、移動した環境素子の一部がそれまでに占領していた少なくとも一部のシーンに注目のオブジェクトをよりあらわにさせるものであり、例えば図７と図１０にスクリーン上にレンダリングしたように変化する。これは、多数の画像フレーム中で起こる。仮想カメラ自体は可視できないが、カメラ衝突プリミティブの動きや衝突を介して効果を感じることができる。

当業者であれば、更なる実現方法や変形が可能であると考える。また、特定の実施例は、上述した特定の素子を省略している場合があるが、本発明の範囲内のすべては、添付のクレームにより定義されると理解される。

Claims (31)

1. 処理実体により実行させることにより、該処理実体に方法を実行させることが出来るコンピュータ可読命令からなるコンピュータ可読媒体において、該方法は、
   仮想環境における仮想カメラの視野にシーンの展開を描写させる形で、画像フレームを作成し、該シーンには、環境素子が含まれており、
   該仮想環境内で仮想カメラの動きに応じて、前記画像フレーム内に該環境素子の動きの様子をレンダリングする、ことからなることを特徴とする、コンピュータ可読媒体。
2. 前記方法は、更に、多数の画像フレームの進行に亘り、移動した環境素子の一部がそれまで占領していた少なくとも１部のシーンを、前記仮想環境中でそれまで現われていなかった注目のオブジェクトの一部に置き換えることを特徴とする、請求項１記載のコンピュータ可読媒体。
3. 前記注目のオブジェクトは、ビデオゲームのプレイングキャラクタであることを特徴とする、請求項２記載のコンピュータ可読媒体。
4. 前記方法は更に、カメラ衝突プリミティブと前記環境素子の少なくとも１つの衝突プリミティブとの衝突の発生を検知し、該検知に応答して、環境素子の動きの様子をレンダリングすることを特徴とする、請求項２記載のコンピュータ可読媒体。
5. 前記カメラ衝突プリミティブも、前記環境素子の衝突プリミティブも前記画像フレームにレンダリングしないことを特徴とする、請求項４記載のコンピュータ可読媒体。
6. 前記カメラ衝突プリミティブは、前記仮想カメラと前記注目のオブジェクトとの間にある仮想３Ｄ形状であることを特徴とする、請求項４記載のコンピュータ可読媒体。
7. 前記カメラ衝突プリミティブは、同一の、又は異なる半径を有するカプセロイドであることを特徴とする、請求項６記載のコンピュータ可読媒体。
8. 前記３Ｄ形状は、第1及び第２端部を有する細長形状であり、該第１端部は前記仮想カメラに近接し、該第２端部は、該仮想カメラと前記注目のオブジェクト間に配置されることを特徴とする、請求項６記載のコンピュータ可読媒体。
9. ３Ｄ形状は、前記第１端部に対してテーパー状であることを特徴とする、請求項８記載のコンピュータ可読媒体。
10. 前記３Ｄ形状は、前記第１及び第２端部間で長さ寸法を有しており、前記長さ寸法に直角な断面は、前記注目のオブジェクトにより近い、前記３Ｄ形状の半分部分よりも、前記仮想カメラにより近い該３Ｄ形状の半分部分がより小さいことを特徴とする、請求項８記載のコンピュータ可読媒体。
    
    
    
11. ３Ｄ形状は、前記仮想カメラから前記注目のオブジェクトに対して外側に大きさが広がっていることを特徴とする、請求項８記載のコンピュータ可読媒体。
12. 前記第２端部は、前記仮想カメラと前記注目のオブジェクトの略半分のところに位置していることを特徴とする、請求項６記載のコンピュータ可読媒体。
13. 前記第２端部は、前記仮想カメラと前記注目のオブジェクト間の距離の４分の３に満たないところに位置していることを特徴とする、請求項６記載のコンピュータ可読媒体。
14. 前記環境素子の少なくとも１つの衝突プリミティブは、該環境素子を囲む仮想３Ｄ形状を有していることを特徴とする、請求項６記載のコンピュータ可読媒体。
15. 前記環境素子が骨としてモデル化された時は、該環境素子の少なくとも１つの衝突プリミティブは、該骨を囲む仮想３Ｄ形状を有していることを特徴とする、請求項６記載のコンピュータ可読媒体。
16. 前記環境素子が相互に連結した複数の骨としてモデル化された時は、該環境素子の少なくとも１つの衝突プリミティブは、それぞれの骨を囲む仮想３Ｄ形状の配列を有していることを特徴とする、請求項６記載のコンピュータ可読媒体。
17. 前記環境素子の少なくとも１つの衝突プリミティブの少なくとも１つはカプセルを有していることを特徴とする、請求項１４記載のコンピュータ可読媒体。
18. 前記環境素子が動くと、前記カプセルがベースポイント周りで屈曲することを特徴とする、請求項１７記載のコンピュータ可読媒体。
19. 前記ベースポイントは、前記仮想カメラの視野内には存在しないことを特徴とする、請求項１８記載のコンピュータ可読媒体。
20. 前記環境素子の移動の程度は、該環境素子の前記衝突プリミティブに作用されたトルクに対応していることを特徴とする、請求項４記載のコンピュータ可読媒体。
21. 前記方法は更に、作用するトルクを演算することを特徴とする、請求項２０記載のコンピュータ可読媒体。
22. 作用するトルクの演算は、前記衝突により生じる衝突トルクの機能及び、前記環境素子に関連付けられた反発力を演算するによることを特徴とする、請求項２１記載のコンピュータ可読媒体。
23. 前記環境素子が動く前に、該環境素子は自然位置を占領しており、前記方法は更に、前記仮想カメラが追加的に動くと、該環境素子が、その自然位置に戻るようにレンダリングすることを特徴とする、請求項１記載のコンピュータ可読媒体。
24. 前記環境素子が動く前に、移動した該環境素子部分は自然位置を占領しており、前記方法は更に、前記カメラ衝突プリミティブと該環境素子部分の衝突プリミティブとがもはや衝突していないと検知されると、該環境素子部分が、その自然位置に戻るようにレンダリングすることを特徴とする、請求項４記載のコンピュータ可読媒体。
25. 前記カメラ衝突プリミティブと、前記環境素子の少なくとも１つの衝突プリミティブとの衝突が検知された時、前記仮想カメラは該環境素子と衝突しないことを特徴とする、請求項４記載のコンピュータ可読媒体。
26. 前記環境素子内で前記仮想カメラが動くと、該仮想環境内で該仮想カメラが平行移動（translation）するか、仮想環境内での固定位置に対して仮想カメラの方位を変化させるかのいずれかであることを特徴とする、請求項１記載のコンピュータ可読媒体。
27. 前記仮想カメラの動きは、前記ビデオゲームのプレイヤから受けた入力と、前記処理実体による処理の結果であることを特徴とする、請求項３記載のコンピュータ可読媒体。
28. 前記環境素子は、植物、葦、枝、葉、つる、藻、旗、ビーズカーテン、垂直ブラインド、及び死骸のいずれかであることを特徴とする、請求項１記載のコンピュータ可読媒体。
29. 仮想環境における仮想カメラの視野にシーンの展開を描写させる形で、画像フレームを作成し、該シーンには、環境素子が含まれており、
    該仮想環境内で該仮想カメラの動きに応じて、前記画像フレーム内に該環境素子の動きの様子をレンダリングする、
    ことからなることを特徴とする、方法
30. 処理実体により実行させることにより、該処理実体に方法を実行させることが出来るコンピュータ可読命令からなるコンピュータ可読媒体において、該方法は、
    ビデオゲーム用の仮想環境を維持し、該仮想環境には仮想カメラ、注目のオブジェクト、少なくとも一部が該仮想カメラと該注目のオブジェクト間に配置されている環境素子が含まれており、
    ビデオゲーム内でシーンの展開を描写しつつ、一連の画像フレームを作成し、該シーンには該仮想カメラの視野内に前記仮想環境からのオブジェクトが含まれており、
    多数の画像フレームの進行に亘り、前記環境素子の一部の動きの様子をレンダリングして、移動した環境素子の一部がそれまで占領していた少なくとも１部のシーンに前記注目のオブジェクトを更に現わす、ことからなることを特徴とする、コンピュータ可読媒体。
31. ビデオゲーム用の仮想環境を維持し、該仮想環境には仮想カメラ、注目のオブジェクト、少なくとも一部が該仮想カメラと該注目のオブジェクト間に配置されている環境素子が含まれており、
    ビデオゲーム内でシーンの展開を描写しつつ、一連の画像フレームを作成し、該シーンには該仮想カメラの視野内に前記仮想環境からのオブジェクトが含まれており、
    多数の画像フレームの進行に亘り、該環境素子の一部の動きの様子をレンダリングして、移動した該環境素子の一部がそれまで占領していたシーンの少なくとも１部に該注目のオブジェクトを更に現わす、ことからなることを特徴とする、方法。
    

Images