JP4937907B2 - ルールベースの手続的地形生成 - Google Patents

Description

本発明は一般に、地形生成の分野に関する。より詳細には、本発明は、実時間の仮想ワールドの表示を対象とする、ルールベースの地形メタデータの手続的生成(procedural generation of terrain metadata)に関する。

ある種のコンピュータアプリケーション、例えば膨大な数のプレーヤが参加する(massively multiplayer)3次元(3D)オンラインゲームなどのパーソナルコンピュータ(PC)ゲームでは、仮想地形を有する仮想ワールドが作成されることがある。地形生成は、河川、道路、植物相(flora)、照明、大陸、天体、環境的特徴、泥地、岩場などの物体および特徴を生成することを含む可能性がある。従来の地形生成システムでは、3D地形アーティストが非常に詳細で冗長な地形定義を手動で入力し、それを1つまたは複数の地形データベースに記憶する必要がある。

膨大な数のプレーヤが参加するオンラインコンピュータゲームでは、アバターとは、実際の人物またはキャラクタを表すグラフィックアイコンまたは画像を指す。例えば、ゲームプレーヤがゲームシステムに入場するときはしばしば、いくつかのアバターの内から選択を行うことができる。高度な3Dアバターは、自身の現在の行動に応じて、例えば歩く、座る、走るなどの行動に応じて姿を変えることさえできる。

従来の地形生成およびレンダリングシステムは、多くの欠点および制限に悩まされている。例えば、地形データの入力はしばしば時間の掛かるプロセスとなり、そのため、地形アーティストが入力および修正を行うのに膨大な時間を割くこともある。また、地形生成システムは典型的には、地形データを記憶し、生成し、レンダリング（可視化、画像化）するために、非常に多くのデータベース記憶空間および処理資源を消費する。さらに、ネットワークを介してユーザのコンピュータシステム上でレンダリングすべき地形データを転送する必要がある地形生成システムでは、地形の滑らかなレンダリングに必要な更新レートをサポートするのに十分な速度で地形データを転送することができない。

したがって、仮想ワールドアプリケーション、例えば膨大な数のプレーヤが参加する3Dオンラインゲーム向けの実時間における地形データを非常に効率的な形で定義し、生成し、レンダリングするためのルールベースのシステムおよび方法が、必要とされている。

本発明のいくつかの実施形態は、仮想ワールド内の地形を生成するためのシステムを対象とする。前記システムは、仮想ワールド内の仮想地形を生成するように構成された複数の手続的ルール(procedural rule)と、前記複数の手続的ルールを処理して前記地形の仮想表現を生成するように構成された地形生成器(terrain generator)とを備える。

前記システムはまた、生成された前記地形の仮想表現を表示するモジュールを備える。前記システムでは、前記手続的ルールの内の少なくとも1つは、前記仮想ワールド内の区域を定義することができる。また、前記システムでは、前記手続的ルールの内の少なくとも1つは、前記手続的ルールが作用する区域を画定する境界を含む。前記境界は、円、矩形、および多角形の内の1つを含むことができる。さらに、前記システムでは、前記手続的ルールの内の少なくとも1つは、前記手続的ルールを適用する前に満足されるべき1つまたは複数の条件を定義するフィルタを含むこともできる。前記フィルタは、傾斜、高度、シェーダ(shader)、方向、およびフラクタルの内の1つを含むことができる。さらに、前記システムは、高度、色、シェーダ、植物相、および放射状植物相(radial flora)の内の1つの地形特性に影響を及ぼす前記複数の手続的ルールを含むこともできる。前記システムは、前記複数の手続的ルールに従って実時間で生成される前記地形の仮想表現を含むことができる。前記システムはまた、前記地形生成の内の、サーバ上で実施されるある部分と、前記地形生成の内の、クライアントコンピュータ上で実施される別の部分とを含むこともできる。

別の実施形態は、仮想ワールド内の地形を生成する方法を対象とする。前記方法は、前記仮想ワールド内の前記地形を定義する複数の手続的ルールを受信するステップと、前記複数の手続的ルールに従って、前記仮想地形を地形生成器内で生成するステップとを含む。

前記方法はまた、生成された前記仮想地形を表示するステップを含むこともできる。前記方法では、前記手続的ルールの少なくとも1つは、前記手続的ルールが作用する区域を画定する境界を含むことができる。前記境界は、円、矩形、および多角形の内の1つとすることができる。前記方法では、前記手続的ルールの内の少なくとも1つは、前記手続的ルールを適用する前に満足されるべき1つまたは複数の条件を定義するフィルタを含むことができる。前記フィルタは、傾斜、高度、シェーダ、方向、およびフラクタルの内の1つとすることができる。前記方法では、前記複数の手続的ルールは、高度、色、シェーダ、植物相、および放射状植物相の内の1つの地形特性に影響を及ぼすことができる。

別の実施形態は、仮想ワールド内の地形を生成するための方法を対象とする。前記方法は、仮想ワールド内の地形を定義する複数の手続的ルールを受信する手段と、前記複数の手続的ルールに従って前記仮想ワールド内の地形を生成する手段とを備える。

前記システムはまた、生成された前記仮想地形を表示する手段を備えることもできる。前記システムでは、前記手続的ルールの内の少なくとも1つは、前記手続的ルールが作用する区域を画定する境界を含むことができる。前記境界は、円、矩形、および多角形の内の1つとすることができる。前記システムでは、前記手続的ルールの内の少なくとも1つは、前記手続的ルールを適用する前に満足されるべき1つまたは複数の条件を定義するフィルタを含むことができる。前記フィルタは、傾斜、高度、シェーダ、方向、およびフラクタルの内の1つとすることができる。前記システムでは、前記複数の手続的ルールは、高度、色、シェーダ、植物相、および放射状植物相の内の1つの地形特性に影響を及ぼすことができる。

別の実施形態は、実行されたときに、仮想ワールド内の前記地形を定義する複数の手続的ルールを受信するステップと、前記複数の手続的ルールに従って前記仮想ワールド内の仮想地形を生成するステップとを含む方法を実施する命令を記憶したプログラム記憶装置を対象とする。

前記プログラム記憶装置はまた、生成された前記仮想地形を表示するステップを含むこともできる。前記プログラム記憶装置では、前記手続的ルールの内の少なくとも1つは、前記手続的ルールが作用する区域を画定する境界を含むことができる。前記境界は、円、矩形、および多角形の内の1つとすることができる。前記システムでは、前記手続的ルールの内の少なくとも1つは、前記手続的ルールを適用する前に満足されるべき1つまたは複数の条件を定義するフィルタを含むことができる。前記フィルタは、傾斜、高度、シェーダ、方向、およびフラクタルの内の1つとすることができる。前記システムでは、前記複数の手続的ルールは、高度、色、シェーダ、植物相、および放射状植物相の内の1つの地形特性に影響を及ぼすことができる。

別の実施形態は、仮想ワールド内の地形を生成する方法を対象とする。前記方法は、前記仮想ワールド内の道路を定義する少なくとも1つの手続的ルールを受信するステップと、前記手続的ルールに従って前記仮想ワールド内の前記道路を生成するステップとを含む。前記方法では、前記手続的ルールは、前記道路が配置される前記仮想ワールド内の複数の点を定義することができる。前記方法では、前記手続的ルールはまた、路肩の幅(shoulder width)を定義することもできる。前記方法では、前記道路の路肩の高度は、前記仮想ワールド内の前記道路の高度と、前記道路に近接する前記仮想地形の高度とに基づいて判定することができる。

別の実施形態は、仮想ワールド内の地形を生成する方法を対象とする。前記方法は、前記仮想ワールド内の河川を定義する複数の手続的ルールを受信するステップと、前記複数の手続的ルールに従って前記仮想ワールド内の前記河川を生成するステップとを含む。前記方法では、前記手続的ルールは、前記仮想ワールドにおいて前記河川が配置される複数の点を定義することができる。

別の実施形態は、仮想ワールド内の地形を生成する方法を対象とする。前記方法は、仮想ワールド内のアバターの周囲のユーザ定義領域を識別するステップと、予め定義された前記領域内に植物相を生成するステップとを含む。前記方法はまた、植物相の密度を判定するステップと、前記ユーザ定義領域内の位置を植物相位置として識別するステップと、識別された前記位置に基づいて、前記アバターの移動中に新しい植物相位置を識別するステップとを含むことができる。

別の実施形態は、仮想ワールド内の地形を生成する方法を対象とする。前記方法は、仮想ワールドで発生する活動を監視するステップと、前記アバターによって実施された前記活動を監視したことに応答して、前記仮想ワールド内の前記地形を定義する手続的ルールを生成するステップと、生成された前記手続的ルールに従って前記仮想ワールド内の地形を生成するステップとを含む。前記方法では、監視される前記活動は、前記仮想ワールドにおけるプレーヤ以外のキャラクタ(non-player character)の活動を含むことができる。

別の実施形態は、仮想ワールド内の地形を生成するコンピュータ環境を対象とする。前記コンピュータ環境は、前記コンピュータ環境によって実行され、複数の手続的ルールを使用して地形を実時間で生成し表示するように構成された1つまたは複数のプログラムを備える。

前記システムでは、前記手続的ルールの少なくとも1つは、前記手続的ルールが作用する区域を画定する境界を含むことができる。前記境界は、円、矩形、および多角形の内の1つとすることができる。また、前記システムでは、前記手続的ルールの内の少なくとも1つは、前記手続的ルールを適用する前に満足されるべき1つまたは複数の条件を定義するフィルタを含むことができる。前記フィルタは、傾斜、高度、シェーダ、方向、およびフラクタルの内の1つとすることができる。前記システムでは、前記複数の手続的ルールは、高度、色、シェーダ、植物相、および放射状植物相の内の1つの地形特性に影響を及ぼすことができる。

本発明の上記およびその他の態様、特徴、および利点は、添付の図面と併せて読むべき以下の詳細な説明を参照すればより良く理解されるであろう。添付の図面およびそれに関する説明は、本発明のある実施形態を例示するために与えられるものであり、本発明の範囲を限定するものではない。

ある実施形態に関する以下の詳細な説明は、本発明の個々の実施形態に関する様々な説明を提示する。しかしながら、本発明は、添付の特許請求の範囲によって定義され包含される数多くの異なる手法で実装され得る。本明細書では、その全体を通して同様の部分が同様の参照番号で指定される添付の図面を参照する。

一実施形態では、地形生成システムは、地形ルールに基づいて、地形ジオメトリデータを手続的に生成するためのシステムおよび方法を含む。これらのルールは、本明細書では影響因子(affector)とも呼ばれる。実際の地形ジオメトリデータを記憶するのではなく、ルールを用いて手続的に地形を記述することで、必要に応じて地形を実時間で即座に（on-the-fly）生成することによるメモリおよびディスク空間の大幅な節約が実現される。地形生成システムは、例えば地形の高度、色、シェーダおよびテクスチャ、植物相、および環境を修正する。また、手続的に地形を生成することにより、地形生成システムは、地形ジオメトリを作成するのに使用されるパラメータを変更することで、事実上無制限の詳細を生成しレンダリングすることができる。地形ルールと呼ばれることもあるこれらのパラメータは、動的に追加することも除去することもでき、そのため、実時間の地形の修正が可能となる。

いくつかの実施形態では、デフォルトの地形サイズは、16キロメートル×16キロメートルである。地形は、1キロメートル×1キロメートル程の小さなサイズとすることができ、16キロメートル×16キロメートルよりも大きなサイズとすることさえ可能である。クライアント側地形生成システムのある実施形態では、地形生成システムは、昼、夜、太陽、月、星、および他の天体を含めたフルタイムのデイサイクルに対応することができる。しかしながら、環境、気象効果、または照明条件は、惑星全体にわたって必ずしも同じではないことが多い。例えば、ジャングル地帯は一般に、密集し薄暗く照らされて見え、湿地領域は、霧が立ちこめるように見える。環境ブロックとは、例えば照明、霧、および背景のパラメータを変更することができる地形に関してユーザが定義した区域を指す。地形生成システムのある実施形態では、環境ブロック間の遷移は、時間にわたって容易に変更することができる。

地形生成システムにおけるルールは、影響因子とも呼ばれ、複数のレイヤに編成される。境界とは、所望のルールが作用する仮想地形に関して地形デザイナまたは地形アーティストが定義した区域を指す。フィルタとは、影響因子を適用するときに考慮されるべき条件を指す。レイヤは、親/子関係または木/葉関係を有する階層の形で配列することができる。境界の例としては、円、矩形、および多角形が挙げられる。フィルタの例としては、傾斜、高度、シェーダ、方向、およびフラクタルによるフィルタリングが挙げられる。影響因子の例としては、高度、色、シェーダ、植物相、および放射状植物相に影響を及ぼすものが挙げられる。境界、フィルタ、およびレイヤについては、以下でより詳細に説明する。

ルールのレイヤ階層では、ルールの重複が許容される。ルールが重複したときの、目に見える強い(hard)不連続性を最小限に抑えまたは防止するために、地形生成器は、境界エッジとフィルタとをフェザリングすることができる。フェザリングは、混合(blend)区域を指定する手法であり、高度と色を混合する操作である。

地形生成システムは、テクスチャやジオメトリさらにはアルゴリズムなどの資産群(groups of assets)を指すファミリーも含む。ファミリーは、重みを有する子を含むことができる。これには、重み付けされた1つの子を選択することによって資産を選択することが必要となる可能性もある。これにより、例えばある区域用の「草」ファミリーをユーザが選択するのを可能とし得るが、地形システムは、草ファミリーを生成したときは、草ファミリーの子の内の1つを選択し、それにより単一の草シェーダをレンダリングすることができる。

ファミリーの例としては、シェーダファミリー、混合ファミリー、植物相ファミリー、放射状植物相ファミリー、およびフラクタルファミリーが挙げられる。シェーダファミリーとは、テクスチャの配置用にシェーダをグループ化することを指す。混合ファミリーとは、アルファ混合マスクの選択用にシェーダをグループ化することを指す。植物相ファミリーとは、植物相の選択用にジオメトリをグループ化することを指す。放射状植物相ファミリーとは、放射状植物相の配置用にシェーダをグループ化することを指す。フラクタルファミリーとは、様々なルールの再使用のためにフラクタルをグループ化することを指す。

境界、フィルタ、および影響因子は、地形内の単一の位置が複数の地形ルールを有することができるようにレイヤおよびサブレイヤ内で定義することができる。境界(またはフィルタ)を伴わないレイヤは、「無境界(unbounded)」であり、風景全体にわたって影響を及ぼすことができる。境界を伴うレイヤを用いると、その境界で特定される区域にレイヤおよびサブレイヤ内の影響因子を適用することが可能になる。

レイヤの例としては、次のものが挙げられる。

1.レイヤ
a.AffectorHeightConstant、10
b.AffectorShaderConstant、岩
2.レイヤ
a.BoundaryCircle、x = 500, y = 500, r = 500, feather = InOut
b.AffectorHeightConstant、0
c.AffectorShaderConstant、泥地
d.レイヤ
i.FilterHeight min=13, max=17
ii.AffectorColorConstant、黒
3.レイヤ
a.BoundaryRectangle、min=-500, -500、max=500, 500
b.AffectorFloraStaticCollidableConstant、針葉樹
c.AffectorFloraDynamicNearConstant、枯れ草
この例は、ルールの実際のコードではなくルールのテキスト表現を示すものである。先に列挙した階層化ルールの例では、様々な境界、フィルタ、および影響因子には、論理的なテキスト形式で所望の属性を表す数値またはテキスト値(例えば、「feather =InOut」)を割り当てることができる。いくつかの実施形態では、コンパイル時にテキスト値を特定の数値に割り当てることができる。

対応するルールの記述は、先に列挙した例示的なルールを使用して次のことを実施することができる。すなわち、あらゆる場所の地形高度を10メートルに設定し、岩シェーダを割り当てる。次いで、座標(500, 500)を原点とする500メートルの円内で、10メートルから0メートルまで高度を徐々に減少させ、泥地シェーダを配置し、所与のサンプル点の地形高度が13メートルから17メートルの間となる黒い帯を作成する。最後に、座標(-500, -500)から(500, 500)に及ぶ矩形内で、当該矩形範囲内の針葉樹および枯れ草を配置する。

地形生成システムは、ルールを追加または削除することによって地形を修正する実行時のレイヤの追加をサポートする。これは、例えば植物相または放射状植物相をそこから取り除きながら建造物下の地形を平坦化するような機能や、ある種のオンラインゲームでは上方に浮上する周回宇宙船からのイオン砲の爆風に続いて地形にクレータを形成するような機能に使用することもできる。同様に、ルールセットを削除すると、当該ルールセットの提供する任意の特徴が取り除かれる。例えば、ユーザは、湖の除去、湖の移動、湖の複製などを行うことができる。

一例として、ユーザは、地形生成システムで崖を定義するために、地形のある領域の高度を例えば隣接する領域よりもかなり低くなるように修正する高度ルールを作成することもできる。地形生成システムがそれ自体の高度データについて通常のグリッドを使用する場合に、隣接する高度極(height poles)の高度差があまりにも大きい場合には、地形テクスチャは、地形のポリゴン全域に伸張するように見えることもある。かかる伸張は、許容されることもあれば訂正されることもある。

膨大な数のプレーヤが参加するオンラインコンピュータゲームでは、アバターとは、実際の人物またはキャラクタを表すグラフィックアイコンまたは画像を指す。例えば、ゲームプレーヤがゲームシステムに入場するときはしばしば、いくつかのアバターの内から選択を行うことができる。高度な3Dアバターは、自身の現在の行動に応じて、例えば歩く、座る、走るなどの行動に応じて姿を変えることさえできる。

地形生成システムは、多くのグラフィックスレンダリング用ハードウェアおよび慣行の内の1つまたは複数を使用することができる。かかるグラフィックスレンダリング用プラットフォームの1つは、業界標準のDirectX9である。地形生成システムは、DirectX9の上位のレイヤに位置する既存の3Dグラフィックスエンジンおよびオブジェクトシステムの上位のレイヤに位置する。

地形生成システムはまた、手続的に生成された地形の実時間修正も含む。地形生成システムは、ある区域と変形パラメータとを指定することにより、クレータや、家屋または他の建造物を対象とする地形の平坦化など、様々な地形特徴に関して地形を実時間で修正する(または変形させる)ことができる。例えば、地形システムは、次の機能拡張の必要に対処するように、すなわち、大陸の拡大、ルールの追加、惑星の追加、急峻な崖、詳細レベルポッピング(level-of-detail popping)、環境ブロック、衝突可能植物相、表面特性、静的メッシュの付加、および資源配置の必要に対処するように設計された。

地形生成システムはまた、仮想ワールド内のグローバル水面(global water)に関するルールを定義することも含む。グローバル水面とは、惑星または地形ワールドの全域で指定されるある高度の1枚の水面(a sheet of water)を指す。いくつかの実施形態では、グローバル水面は、チャンクがレンダリングされると、当該チャンクでレンダリングされる単一の平面として、チャンク毎に実装される。グローバル水面は、海洋などに使用することができる。水面は、写実的に波打ち、高品質のシェーダ効果を伴ってレンダリングされる。

表面の地形特性には、プレーヤ体験に影響を及ぼすゲーム特有のデータを用いた、地形タイルのタグ付けが含まれる。例えばいくつかの例を挙げると、タイルは、滑りやすい箇所、ダメージを与える箇所、または通り抜け不可能な箇所としてマーク付けすることができる。タイル毎に1つのシェーダを用いると、表面特性をシェーダ毎に関連付けることができる。

地形生成システムはまた、地形システムの植物相オブジェクトを配置するためのシステムおよび方法も含む。植物相高速配置は、現在視点の周囲の植物相が最小となり、正確かつ詳細に示されることを保証する。従来の方法は一般に、全ての植物相を予め作成し、レンダリングシステムまたは場面グラフシステムを使用して、それらのオブジェクトの一部を、例えばより近くにある他のオブジェクトから閉ざされるために、見えないオブジェクトを、レンダリングしないように処理（culling）る。例えば、植物相高速配置のいくつかの実施形態は、必要な場合にだけ地形上の植物相を作成する。

また、地形生成システムは、地形内の実時間道路生成を対象とするシステムおよび方法も含む。手続的地形生成は、山、谷、起伏をもつ丘、平原など、地球と同様のジオメトリを作成することを含むことができる。手続的地形生成システム用のデータを定義するユーザは、道路など人工的な地形構造物を作成したいと思うこともある。ユーザは、道路の経路に影響する制御ポイントを設置し、道路の幅を割り当て、道路の地形に適用すべきシェーダを割り当てることによって、地形生成システム用の道路データを定義する。地形生成システムは、道路のない地形を生成し、次いで道路用の地形を修正し、道路を平坦に保つために道路の幅に沿って地形を平滑化し、道路の長さに沿って地形の傾斜の極端な変動を最小限に抑えようと試みる。

さらに、地形生成システムは、地形内の実時間の河川生成を対象とするシステムおよび方法も含む。手続的地形生成は、山、谷、起伏をもつ丘、平原など、地球と同様のジオメトリを作成することを含むことができる。手続的地形生成システム用のデータを定義するユーザは、河川などの水流システムを作成したいと思う可能性がある。ユーザは、河川の経路に影響する制御ポイントを設置し、河川幅および深さを割り当て、河川床側、河川床の底、および河川の水自体に適用すべきシェーダを割り当てることによって、地形生成システム用の河川データを定義することができる。地形生成システムは、河川のない地形を生成し、次いで河川用の地形を修正し、河川を形成するために河川の幅および深さに沿って地形を彫り込み、そうしない場合は水が強制的に上り方向に流れることになるが、河川の長さに沿って地形の傾斜のどのような変動も排除することによって、水が平坦に流れ、または下り坂を流れることを保証する。

ここで添付の図面を参照すると、図1は、ルールベースの地形生成システムの諸実施形態を実行するためのコンピュータシステム100の一例を示す図である。コンピュータシステム100は、少なくとも1つのコンピューティングデバイス110、例えば図1の実施形態におけるコンピュータを含む。地形生成システムが2つ以上のコンピュータシステム100を含む諸実施形態では、コンピュータシステムは、ネットワーク120を介して、例えばネットワーク化されたコンピューティング環境(図1Aおよび2を参照)を形成するインターネットなどの公衆ネットワークを介して相互接続することができる。

図1のコンピューティングデバイス110は、地形生成システムモジュール(例えば、図3および4を参照)を実行するマイクロプロセッサおよび他のハードウェアを含む。マイクロプロセッサは、従来の任意の汎用型単一チップまたは複数チップマイクロプロセッサ、例えばいくつかの例を挙げると、Pentium（登録商標）プロセッサ、Pentium（登録商標） Proプロセッサ、8051プロセッサ、MPSプロセッサ、Power PCプロセッサ、あるいはALPHAプロセッサとすることができる。また、マイクロプロセッサは、特定用途向け集積回路(ASIC)プロセッサなど、従来の任意の専用マイクロプロセッサとすることもできる。

コンピューティングデバイス110は、表示装置125および少なくとも1つの入力デバイスに接続されている。ユーザは、入力デバイスおよび表示装置125を使用して、地形生成システムにユーザ入力を供給することができる。入力デバイスは、キーボード130、マウス135、ローラーボール(図示せず)、ペンおよびスタイラスペン(図示せず)、あるいは音声認識システム(図示せず)であってもよい。入力デバイスは、表示装置125に関連するタッチスクリーン(図示せず)であってもよい。ユーザは、タッチスクリーンを使用して、表示装置上のプロンプトに応答することができ、また、表示画面のある領域に触れることによって他のユーザ選択を入力することもできる。また、ユーザが入力デバイスを介してテキストデータを入力することもできる。他の実施形態では、コンピューティングデバイス110は、例えば携帯情報端末(PDA)、セルラー電話、無線コンピューティングデバイス、ラップトップコンピュータ、セットトップボックスなどとすることもできる。

ネットワーク120は、例えば次のネットワーク、すなわち、インターネット、イントラネット、ローカルエリアネットワーク(LAN)、またはワイドエリアネットワーク(WAN)を含めた、任意のタイプの電子的に接続されたコンピューティングデバイス群を含むことができる。また、ネットワークとの接続性は、例えばリモートモデム、イーサネット（登録商標）(IEEE 802.3)、トークンリング(IEEE 802.5)、ファイバ分散データリンクインターフェイス(FDDI)、または非同期転送モード(ATM)を介するものであってもよい。ネットワーク化されるコンピューティングデバイスは、デスクトップタイプ、サーバタイプ、ポータブルタイプ、ハンドヘルドタイプ、セットトップタイプ、または他の任意の所望のタイプの構成とすることができる。本明細書で使用されるように、インターネット網は、公衆インターネット、私設インターネット、セキュアインターネットなどのネットワークの変形形態を含むことができる。さらに、ネットワークは、私設ネットワーク、公衆ネットワーク、付加価値通信網、イントラネットなどとして構成することができる。

図1Aは、地形生成システムのネットワーク構成の一例を示すブロック図である。図1に示されるように、地形生成システムは任意選択で、ネットワーク120を介して接続される複数のコンピュータを含むことができる。図1Aに示される地形生成システムは、サーバ1 160と、サーバ2 164と、サーバN 168とを含む。地形生成システムの別の実施形態は、1つのサーバコンピュータだけを含むことも、サーバN 168の記号「N」で表されるように任意の数の複数のサーバを含むこともできる。地形生成システムはまた、クライアントコンピュータ1 180と、クライアントコンピュータ2 184と、クライアントコンピュータN 188とを含むこともできる。サーバコンピュータの場合と同様に、地形生成システムの別の実施形態は、1つのクライアントコンピュータだけを含むことも、クライアントコンピュータN 188の記号「N」で表されるように任意の数の複数のクライアントコンピュータを含むこともできる。「クライアントコンピュータ」および「ユーザコンピュータ」という用語は、本明細書では相互に置換え可能に使用される。

図2は、例示的な地形生成システムのネットワーク構成200を示すブロック図である。地形生成システムは、1つまたは複数のサーバコンピュータと、1つまたは複数のデータベース記憶システムと、1つまたは複数のクライアントコンピュータとを含むことができる。図2に示される地形生成システムの例は、ゲームサーバ1 210、ゲームサーバ2 214、ゲームサーバ3 220、およびゲームサーバN 224として指定される1つまたは複数のゲームサーバ(これらはまとめて、ゲームサーバ210、214、220、224と呼ばれる)を含む。ゲームサーバ210、214、220、224のそれぞれは、惑星またはワールドの所定の区域に関する地形データを生成する。ゲームサーバ210、214、220、224は、ネットワーク120を介して中央サーバ260に接続される。また、データベースサーバ250は、ネットワーク120に接続することができ、例えばオブジェクトの位置、プレーヤ情報、およびゲームサーバ210、214、220、224上で実行されている地形生成システムのモジュールによって生成される他のワールド情報を記憶するために、データベース記憶システム254に接続することもできる。中央サーバ260上の処理としては、相互に接続され、ゲームサーバ210、214、220、224と通信する、ゲームサーバ210、214、220、224のリストを維持することが挙げられる。

図2に示される地形生成システムはまた、接続サーバ1 270、接続サーバ2 274、および接続サーバN 278 224として指定される1つまたは複数の接続サーバ(これらはまとめて、接続サーバ270、274、278と呼ばれる)も含む。地形生成システムは、クライアントコンピュータ1-1 280、クライアントコンピュータ1-N 284、クライアントコンピュータ2-1 288、クライアントコンピュータ2-N 290、クライアントコンピュータN-1 294、クライアントコンピュータN-N 298として指定される1つまたは複数のクライアントコンピュータ(これらはまとめて、クライアントコンピュータ280、284、288、290、294、298と呼ばれる)も含む。図2は、1つまたは複数の接続サーバ270、274、278のそれぞれに2つのクライアントコンピュータが接続されている様子を示しているが、他の実施形態では、接続サーバ270、274、278のそれぞれに2つよりも少ないまたは多いクライアントコンピュータを接続することができる。

中央サーバ260は、ネットワーク120を介して接続サーバ270、274、278と通信する。接続サーバ270、274、278は、中央サーバ260との通信に加えて、それ自体が接続されている1つまたは複数のクライアントコンピュータ280、284、288、290、294、298との通信も行う。手続的に生成される地形は、クライアントコンピュータ280、284、288、290、294、298上でレンダリングされる(写実的に表示される)。

図3は、図1Aおよび2に示される様々なサーバの内の1つまたは複数のサーバ上で実行され得る、地形生成システムのサーバ側地形システムモジュール300に関する一実施形態を示すブロック図である。サーバ側地形システムモジュール300は、例えば図2に示されるゲームサーバ210、214、220、224上で実行される。サーバ側地形システムモジュール300は、惑星または仮想ワールド内の区域に関する地形メタデータを手続的に生成する。サーバ側地形システムモジュール300は、地形オブジェクトモジュール(terrain object module)310と、衝突システムモジュール(collision system module)350と、ワールドオブジェクトモジュール(world objects module)360とを含む。

地形オブジェクトモジュール310は、地形生成モジュール320と、チャンクマネージャモジュール330と、参照オブジェクトマネージャモジュール340とを含む。本明細書に記載のチャンクは、地形データがそれについて生成される全体の地形の一部分を指す。言い換えれば、地形の風景は論理的に、チャンクと呼ばれる複数の正方形片に分割される。チャンクのジオメトリについては、少なくとも図5〜7に関して以下で説明する。チャンクマネージャモジュール330は、どのチャンクについて地形を生成すべきかを判定する。例えば、チャンクマネージャモジュール330は、移動オブジェクトを有するチャンクならびに隣接するチャンクについて地形を生成することができる。地形生成モジュール320は、上述のチャンクマネージャモジュール330によって識別されたチャンクの周囲の地形を生成する。参照オブジェクトマネージャモジュール340は、地形生成システム内の参照オブジェクトの位置および状態を維持する。

衝突システムモジュール350は、可動オブジェクトが地形システム内の他のオブジェクトと衝突したかどうか判定する。衝突が発生したことが判定されると、衝突システムモジュール350は、それが衝突可能オブジェクトとの衝突であるのかそれとも衝突不可能オブジェクトとの衝突であるのか判定する。例えば、いくつかの植物相タイプ(例えば、樹木)は、可動オブジェクトがその植物相タイプを通り抜けることはできない衝突可能タイプである。他の植物相タイプ(例えば、草の葉身)は、可動オブジェクトの動きを隠さずあるいは妨害しない衝突不可能タイプである。

地形生成システム内の衝突の判定は、クライアントコンピュータ上とサーバ上のどちらにおいても正確なポリゴン(polygon accurate)である。衝突の判定は、任意の線との衝突検査をサポートする。地形は4分木の形に編成されることから、子を検査すべきかどうかを決定するために、4分木内の各ノードに対する天球(sphere)チェックが行われる。子が4分木内の葉にあたるならば、その子は、実際のジオメトリを含んでおり、その線との衝突の有無について各ポリゴンが検査される。ユーザは、衝突点と、地形のポリゴン法線の両方を求めることができる。衝突検出に最適な1つの事例は、所与の(x, y)座標の高さを求めることである。

地形生成システムのいくつかの実施形態における植物相の特徴は、大型の植物相(樹木、岩など)をプレーヤが通り抜けることが許可されないように、ゲームの衝突システムと統合される。ユーザには、植物相ファミリー内のどの子が衝突可能であるかを指定する能力がある。放射状植物相は衝突可能でないものと仮定される。サーバはまた、移動および経路発見を有効化する衝突可能植物相を認識している。

ワールドオブジェクトモジュール360は、ワールド内の複数の非地形オブジェクトに関する位置および状態情報を維持することができる。非地形オブジェクトの例としては、地形生成システムに関するマルチプレーヤ型オンラインゲームの諸実施形態におけるゲームのキャラクタやプレーヤ(アバターとも呼ばれる)などのオブジェクトが挙げられる。

図4は、図1Aおよび2に示される様々なクライアントコンピュータの内の1つまたは複数のクライアントコンピュータ上で実行され得る、地形生成システムのクライアント側地形システムモジュール400に関する一実施形態を示すブロック図である。クライアント側地形システムモジュール400は、例えば図2に示されるクライアントコンピュータ280、284、288、290、294、298上で実行される。クライアント側地形システムモジュール400は、ユーザの表示画面上で地形を生成しレンダリングする。クライアント側地形システムモジュール400は、地形オブジェクトモジュール410を含んでおり、地形オブジェクトモジュール410は、地形生成モジュール420と、チャンクマネージャモジュール430と、植物相マネージャ440と、参照オブジェクトマネージャ450とを含む。

チャンクマネージャモジュール430は、どのチャンクについて地形を生成すべきかを判定する。クライアント側地形システムモジュール400内のチャンクマネージャモジュール430は、現在の地形の視点から地平線までの地形を生成する。いくつかの実施形態では、チャンクマネージャモジュール430は、ある距離までは高水準の(詳細な)地形を生成し、その距離を超える地形は詳細さがより低くなるように生成することができる。チャンクマネージャモジュール430は、より性能が高いクライアントコンピュータ280、284、288、290、294、298上では、より大きな距離にまでより詳細な地形を生成するように構成され得る。同様に、チャンクマネージャモジュール430は、より性能が低いクライアントコンピュータ280、284、288、290、294、298上では、より小さな距離にまで高水準の地形を生成するように構成され得る。クライアント側地形システムモジュール400上のチャンクマネージャモジュール430は、地形を空間的に複数の象限に細分化する4分木として、チャンクのジオメトリをセットアップする。クライアント側のチャンクマップについては、以下でより詳細に説明する。

地形生成モジュール420は、上述のチャンクマネージャモジュール430によって識別されたチャンクの周囲の地形を生成する。植物相マネージャモジュール440は、更新済みの参照オブジェクトの位置に基づいて新しい植物相の位置データを計算する。参照オブジェクトマネージャモジュール450は、地形生成システム内の参照オブジェクトの位置および状態を維持する。

図5は、図2および4に示されるチャンクマネージャモジュールによって管理される、地形生成システム内の地形チャンク500に関する構成の一例を示す図である。チャンクは多くの様々なサイズおよび形状となるように定義することができるが、本明細書に記載の諸実施形態は、固定幅の各辺を有する正方形チャンク、例えば各辺の長さが8メートルの正方形を有する。同様に、各チャンクは様々な実施形態において、多くの様々な手法で細分化することができる。例えば、図5の例に示されるように、チャンクは、2メートルの正方形タイルである複数のタイルに細分化することができる。図5にも示されているが、これらのチャンクは、上記のタイルを例えば等しいサイズの8つの三角形に細分化することによって、さらに細分化することができる。したがって、地形全体の風景が論理的にチャンクと呼ばれる複数の正方形片に分割される諸実施形態では、地形は、一時に1つのチャンクずつ生成され得る。

地形生成システムは、チャンクサイズまたはタイルサイズの変更をサポートする。チャンクサイズおよびタイルサイズのパラメータは、ユーザが地形データを構成するときに設定することができる。例示的なコンピュータシステム上の地形生成システムの性能を最適化するために、2×2のタイルジオメトリを有する8メートルのチャンクを選択することができる。しかしながら、例えば使用されるコンピュータシステムまたはオペレーティングシステムのタイプに基づいて、他の多くのチャンクおよびタイルのサイズおよびジオメトリを使用することもできる。また、より強力なハードウェアが開発され利用されるのに従って、チャンクサイズおよびタイルサイズの値を増加させることも可能であり、それにより、製品発売後もゲームの視覚的競争力を保つために、かなり長期にわたって使用され得る視覚的品質が高められることになる。また、クライアントは、サーバよりも高い解像度で地形を表示させることができる。

図6は、図5に示される複数の隣接地形チャンクのワールド座標の一例を示す図である。いくつかの実施形態では、各チャンクのワールド座標は、当該チャンクの左下隅の位置で決定される。地形生成システムの諸実施形態では、地形チャンクは、チャンク空間内の座標を有する。どのようなワールド座標もチャンク空間にハッシュ化または変換することができ、チャンク座標およびチャンク幅を用いて任意の地形チャンクのワールド空間座標を計算することができる。空間データベース(場合によっては地図)は、チャンクと共に一意のチャンク識別子を記憶することができる。いくつかの実施形態では、ダブルワードメモリ位置のハイワード(high word)内のチャンクのx座標と、ダブルワードメモリ位置のローワード(low word)内のチャンクのz座標とをハッシュ化することによって、一意のチャンク識別子を作成することができる。チャンクが存在するかどうか判定するために、空間データベース内でチャンク識別子を探索することができる。

図6の例に示されるように、チャンク空間座標(0, 0)は、ワールド位置(0メートル, 0メートル)および(8メートル, 8メートル)の範囲のワールド空間チャンクを定義する。ワールド空間位置をチャンク空間に翻訳することは、各座標をチャンク幅で分割することによって達成することができる。座標が初めから0未満である場合は、結果として得られるチャンク空間座標から1が減じられる。一例として、ワールド空間の(100, 100)は、チャンク空間では100/8=12、すなわち(12, 12)と翻訳される。同様に、ワールド空間の(-100, -100)は、チャンク空間では-100/8=-12-1=-13、すなわち(-13, -13)と翻訳される。

図7は、図5および6に示されるチャンクに関して、地形チャンク全体を複数のタイルおよび三角形に分解する一例を示す図である。上述のように、いくつかの実施形態では、各チャンクは、16個のタイルからなる8メートル×8メートルの区画である。タイルは、それぞれの幅と長さを1mとする8つの三角形からなる2メートル×2メートル区画となっている。このようにしてチャンクを複数の三角形に分割することによって、グリッドのサンプル点を1m置きに配置することができる。したがって、各チャンクは、9×9のサンプル点、合計で81個のサンプル点を有する。これらのサンプル点は、生成されるバッファに関するピクセル単位の値を表す。

いくつかの実施形態では、地形生成システムは、地形の生成されるべき詳細レベルを判定する。地形生成システムは、サイズが異なることもある地形の各チャンク毎に、一般にはチャンクサイズおよびバッファサイズを満たすある量のデータを地形生成器に供給する。地形生成器は、ルールを通してバッファをざっと読み、後に地形に関する実際の3Dジオメトリを作成するのに使用される、ビットマップを出力する。このジオメトリは4分木に追加され、それにより、詳細レベル間の継目が縫合され得る。さらに、混合シェーダも作成することができる。

図8は、図3に示されるサーバ側地形システムモジュールによって実行される、地形生成システムのサーバ側システムにおける最上位実行プロセス800に関する一実施形態を示す流れ図である。いくつかの実施形態では、最上位実行プロセス800は、サーバ側地形システムモジュール300の地形オブジェクト310(図3を参照)によって実行することができ、より具体的には、地形オブジェクト310の地形生成器320によって実行することができる。実施形態に応じて図8の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

最上位実行プロセス800は、開始状態810を含む。最上位実行プロセス800は、生成対象の個々の地形について定義され保存されているルールおよびメタデータをロードする、地形ロード状態820に進む。最上位実行プロセス800は、地形データに関する様々な前処理操作を実施する、地形前処理状態(preprocess terrain state)830に進む。前処理操作としては、例えば道路セグメントデータおよび河川セグメントデータを前処理することや、植物相リストデータを作成することを挙げることができる。地形前処理状態830の操作は、図24に関して以下でより詳細に説明する。

最上位実行プロセス800は引き続き状態840に進んで、非地形サーバ側システムを初期化する。状態850で、最上位実行プロセス800は、ワールドオブジェクト、例えばゲームキャラクタ、構造物、船などを更新する。ワールドオブジェクトの更新としては、可動オブジェクトの位置を更新することおよびオブジェクトの状態を更新することが挙げられる。最上位実行プロセス800は、少なくとも図10〜18にさらに示され、各図に関して以下でより詳細に説明される地形更新状態860に進む。

最上位実行プロセス800は引き続き状態870に進んで、非地形サーバ側システムを更新する。判断状態880で、最上位実行プロセス800は、例えばユーザ選択に基づいて、ゲームから退場すべきかそれともメインのサーバ側処理ループを続行すべきかを判定する。状態880でループ内に留まるべきであると(退場すべきでないと)判定された場合には、最上位実行プロセス800は引き続き状態850に戻って、上述の通りワールドオブジェクトを更新する。その代わりに、状態880で、ループを抜けるべきであると判定された場合には、最上位実行プロセス800は、終了状態890に進む。最上位実行プロセス800は、終了状態890で終了する。

図9は、図4に示されるクライアント側地形システムモジュールによって実行される、地形生成システムのクライアント側システムにおける最上位実行プロセス900に関する一実施形態を示す流れ図である。いくつかの実施形態では、最上位実行プロセス900は、クライアント側地形システムモジュール400の地形オブジェクト410(図4を参照)によって実行することができ、より具体的には、地形オブジェクト410の地形生成器420によって実行することができる。実施形態に応じて図9の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

最上位実行プロセス900は、開始状態910から開始する。最上位実行プロセス900は、生成対象の個々の地形について定義され保存されているルールおよびメタデータをロードする、地形ロード状態920に進む。最上位実行プロセス900は、地形データに関する様々な前処理操作を実施する、地形前処理状態930に進む。前処理操作としては、例えば道路セグメントデータおよび河川セグメントデータを前処理することや、植物相リストデータを作成することを挙げることができる。地形前処理状態930の操作は、図10に関して以下でより詳細に説明する。

最上位実行プロセス900は引き続き状態940に進んで、ワールドオブジェクトを仮想ワールド内の初期位置または状態にロードする。状態950で、最上位実行プロセス900は、図1Aおよび2に示されるサーバの内の1つまたは複数のサーバから、オブジェクトまたは地形の更新に関するデータを受信する。最上位実行プロセス900は引き続き状態960に進んで、ユーザ入力を処理する。クライアントコンピュータのユーザ入力としていくつかの例を挙げると、ユーザがゲームに入場することまたはゲームから退場することを求める要求、自身のキャラクタを指定された方向に移動させることを求める要求、あるいは別のキャラクタを攻撃することを求める要求を挙げることができる。

状態970で、最上位実行プロセス900は、ワールドオブジェクト、例えばゲームキャラクタ、構造物、船などを更新する。ワールドオブジェクトの更新としては、可動オブジェクトの位置を更新することおよびオブジェクトの状態を更新することが挙げられる。最上位実行プロセス900は、少なくとも図10〜18にさらに示され、各図に関して以下でより詳細に説明される地形更新状態974に進む。

最上位実行プロセス900は引き続き状態980に進んで、オブジェクトおよび地形を含むワールドを実際に描画(レンダリング)する。ワールド描画状態980の処理は、図20に関して以下でより詳細に説明する。判断状態984で、最上位実行プロセス900は、メインのクライアント側処理ループを抜けるべきかそれとも続行すべきかを判定する。状態984でループ内に留まるべきであると(退場すべきでないと)判定された場合には、最上位実行プロセス900は引き続き状態950に戻って、上述の通り1つ(または複数)のサーバからデータを受信する。状態984でループを抜けるべきであると判定された場合には、最上位実行プロセス900は、終了状態990に進む。最上位実行プロセス900は、終了状態990で終了する。

図10は、図8に示されるサーバ側システムにおける最上位実行プロセスの地形前処理プロセス(preprocess terrain process)830に関する一実施形態を示す流れ図である。実施形態に応じて図10の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

地形前処理プロセス830は、開始状態1010から開始する。地形前処理プロセス830は引き続き状態1020に進んで、道路セグメントデータの前処理を行う。状態1020における道路セグメントデータの前処理は、道路セグメントに基づいて、例えば道路の経路と道路の幅とを定義するように連接されたラインセグメントに基づいて、道路ポイントの座標を判定することを含む。実時間道路生成のプロセスは、図23に関して以下でより詳細に説明する。

状態1030で、地形前処理プロセス830は、河川セグメントデータの前処理を行う。状態1030における河川セグメントデータの前処理は、上述の状態1020における道路の前処理と同様である。しかしながら、道路がそうすることはあっても、河川は上り坂に向かって流れることはないので、状態1030における河川の前処理は、河川が平らな方向又は下り坂の方向にしか流れないことを保証するのに必要なだけ、既存の地形に切込みを入れる。さらに、河川は道路と異なり河川の深さを定義する地形中の深さを有することから、状態1030における河川の前処理は、既存の地形に溝深度を追加することを含んでいる。

地形前処理プロセス830は引き続き状態1040に進んで、植物相リストデータを作成する。植物相タイプとしては、キャラクタなどの可動オブジェクトがその植物相を通過できるのか、それともその植物相を迂回しなければならないのかに基づく、衝突可能植物相と、衝突不可能植物相とを挙げることができる。植物相の管理および配置は、図21および22に関して以下で説明する。地形前処理プロセス830は、終了状態1090に進む。地形前処理プロセス830は、終了状態1090で終了する。

図11は、地形生成システムにおける地形生成プロセス1100の一実施形態を示す流れ図である。地形生成プロセス1100は、例えばオブジェクトの位置に基づいてチャンク生成を判定し、生成されたチャンクを有するリストを管理する。いくつかの実施形態では、地形生成プロセス1100は、地形生成器320とチャンクマネージャ330(図3を参照)の内の1つまたは複数によって実施される。実施形態に応じて図11の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

地形前処理プロセス1100は、開始状態1110から開始する。地形前処理プロセス1100は引き続き状態1120に進んで、チャンククリーンアップ処理を実施する。状態1120におけるチャンククリーンアップ処理としては、生成されたチャンクの数が閾値の値を超えているかどうか判定すること、各チャンク毎に割り当てられた優先順位に基づいてチャンクを削除すること、およびチャンクのメモリを地形生成システムに返却することが挙げられる。状態1120におけるチャンククリーンアップ処理は、図18に関して以下でより詳細に説明する。

状態1130で、地形生成プロセス1100は、オブジェクトの位置に基づいて、生成すべきチャンクのリストを作成する。例えば、いくつかの実施形態では、地形生成プロセス1100は、仮想ワールド内で定義される各可動オブジェクト下のチャンクを生成する。したがって、あるオブジェクトが1つのチャンクから別のチャンクに移動する時点でチャンクがまだ生成されていないときに、チャンクが生成される。このようにしてチャンクは、それらが必要とされているものの、他のどの場所でもまだ生成されていないという場合に生成され、その結果不必要なチャンクの生成が回避される故に、優れた性能がもたらされる。

地形生成プロセス1100は引き続き状態1140に進んで、チャンクリスト内の次に生成すべきチャンクを判定する。判断状態1144で、地形生成プロセス1100は、生成すべきチャンクが既に生成済みのものであるかどうか判定する。判断状態1144で、当該チャンクがまだ生成されていないと地形生成プロセス1100が判定した場合には、状態1150でリスト内の次のチャンクが生成される。状態1150における次のチャンクの生成プロセスは、図12に関して以下でより詳細に説明する。地形生成プロセス1100は引き続き状態1160に進んで、生成されたチャンクを追跡し管理するために、生成済みチャンクを生成済みチャンクリストに挿入する。

地形生成プロセス1100は引き続き判断状態1164に進んで、生成すべきチャンクがそれ以上存在するかどうか判定する。判断状態1144で、当該チャンクが既に生成済みのものであると判定された場合には、地形生成プロセス1100は、判断状態1164に進む。判断状態1164で、生成すべきチャンクがそれ以上存在すると判定された場合には、地形生成プロセス1100は引き続き状態1140に戻って、リスト内の次に生成すべきチャンクを判定する。一方、判断状態1164で、生成すべきチャンクがそれ以上存在しないと地形生成プロセス1100が判定した場合には、状態1170で、植物相マネージャ更新プロセス(flora manager update process)が実施される。状態1170における植物相マネージャ更新プロセスは、参照オブジェクト同士の位置の差に基づいて植物相の新しい位置を判定する。状態1170における植物相マネージャ更新プロセスは、図19に関して以下でより詳細に説明する。地形生成プロセス1100は、終了状態1190に進む。地形生成プロセス1100は、終了状態1190で終了する。

図12は、図11に示される地形生成プロセス1100のチャンク生成プロセス1150に関する一実施形態を示す流れ図である。いくつかの実施形態では、チャンク生成プロセス1150は、地形オブジェクト310のチャンクマネージャモジュール330(図3を参照)によって実施される。他の実施形態では、チャンク生成プロセス1150は、地形生成システムの他のモジュールに移動されることもある。実施形態に応じて図12の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

チャンク生成プロセス1150は、開始状態1210から開始する。チャンク生成プロセス1150は引き続き状態1220に進んで、他のチャンクが削除されたときに返却されるメモリバッファから、またはオペレーティングシステムから割り付けられたメモリバッファから、2次元(2D)バッファの割付けを行う。2Dバッファ割付け状態1220の処理は、図13に関して以下でより詳細に説明する。

状態1230で、チャンク生成プロセス1150は、上述のように状態1220で割り付けられた2Dバッファをクリアする。状態1230では例えば、高度、色、植物相、および環境に関する値がクリアされる可能性がある。チャンク生成プロセス1150は引き続き状態1240に進んで、2D影響配列(2D influence array)を初期化する。2D影響配列は、例えばフィルタや境界に関してそのルールがどの程度影響を有するかを判定するのに使用される。チャンク生成プロセス1150は引き続き状態1250に進んで、2Dチャンクの範囲を計算する。2Dチャンクの範囲は、チャンクのワールド座標とチャンク幅とに基づいて、ワールド原点からチャンクの4端までの距離を示す。

チャンク生成プロセス1150は引き続き状態1260に進んで、生成対象のチャンクに関するルールの処理を行う。ルール処理状態1260の処理は、図14に関して以下でより詳細に説明する。状態1270で、チャンク生成プロセス1150は、平面法線および頂点法線を生成する。表面法線は、図7に示されるあらゆる三角形を対象に計算され、頂点法線は、図7に示されるあらゆるサンプル点を対象に計算される。このデータは、地形をレンダリングするときの衝突検出と照明計算の両方に役立つデータである。チャンク生成プロセス1150は、終了状態1290に進む。チャンク生成プロセス1150は、終了状態1290で終了する。

図13は、図12に示されるチャンク生成プロセス1150の2Dバッファ割付けプロセス1220に関する一実施形態を示す流れ図である。地形生成システムは、クライアントコンピュータ上のメモリをキャッシュし、再利用するように構成される。チャンクデータに関するメモリは、チャンクが追加されるときも除去されるときも再利用することができる。シェーダは参照カウントされ、それらが既に構築されている場合は再利用される。実施形態に応じて図13の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

いくつかの実施形態では、チャンクのメモリは、既存のチャンクの削除を基に地形生成システムに返却されたメモリから、またはオペレーティングシステムから直接割り付けられる。オペレーティングシステムからのメモリの割付けは、チャンクの削除に由来するメモリの再利用よりも多くの時間を消費するので、2Dバッファ割付けプロセス1220のかかる諸実施形態は以下で説明するように、メモリを可能な限り再利用する。

2Dバッファ割付けプロセス1220は、開始状態1310から開始する。2Dバッファ割付けプロセス1220は引き続き状態1320に進んで、次に割り付けるべき2Dバッファを判定する。2Dバッファ割付けプロセス1220は引き続き判断状態1330に進んで、オペレーティングシステムから既に割り付けられ使用可能な状態にある未使用メモリを、バッファリストが有するかどうか判定する。割付けは既に済んでいるが現時点で未使用状態にあるメモリは、オペレーティングシステムから追加的なメモリを割り付ける場合よりも少ないシステム資源を消費するメモリとしてそれが使用可能である場合に割り付けられる。判断状態1330で、使用可能な未使用メモリをバッファリストが確かに有していると判定された場合には、2Dバッファ割付けプロセス1220は引き続き状態1340に進んで、バッファリストから新しい2Dバッファ用の未使用メモリを返却する。

その代わりに、判断状態1330で、使用可能な未使用メモリをバッファリストが有していないと判定された場合には、2Dバッファ割付けプロセス1220は引き続き状態1350に進んで、オペレーティングシステムから2Dバッファのメモリの割付けを行う。2Dバッファ割付けプロセス1220は引き続き判断状態1360に進んで、メモリを割り付けるべき2Dバッファがそれ以上存在するかどうか判定する。判断状態1360で、割り付けるべき2Dバッファがそれ以上存在すると判定された場合には、2Dバッファ割付けプロセス1220は引き続き状態1320に進んで、次に割り付けるべき2Dバッファを判定する。その代わりに、判断状態1360で、割り付けるべき2Dバッファがそれ以上存在しないと判定された場合には、2Dバッファ割付けプロセス1220は、終了状態1390に進む。2Dバッファ割付けプロセス1220は、終了状態1390で終了する。

図14は、図12に示されるチャンク生成プロセス1150のルール処理プロセス1260に関する一実施形態を示す流れ図である。地形生成システムは、実際のジオメトリデータを記憶するのではなく、ルール(本明細書では影響因子とも呼ばれる)を用いて手続的に地形を定義する。地形生成システムは、地形を実時間で即座に（on-the-flyで）生成し、また、地形の高度、色、シェーダ、テクスチャ、植物相、環境などのパラメータを修正することを可能にする。また、手続的に地形を生成すると、地形ジオメトリを作成するのに使用されるパラメータを変更することにより、ほぼ無制限の詳細化が可能となる。これらのルールはまた、動的に追加することも除去することもでき、そのため、地形が実時間で修正される。ルールは、境界、フィルタ、高度、色、シェーダ、植物相などのパラメータおよび他の多種多様なパラメータに影響を及ぼす可能性がある。実施形態に応じて図14の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

ルール処理プロセス1260は、開始状態1410から開始する。ルール処理プロセス1260は引き続き判断状態1414に進んで、処理対象のルールについてレイヤ範囲がチャンク範囲と交差するかどうか判定する。判断状態1414で、レイヤ範囲がチャンク範囲と交差しないと判定された場合には、ルール処理プロセス1260は引き続き状態1420に進んで、サブレイヤが存在する場合は影響マップ(influence map)の割付けを行う。状態1430で、ルール処理プロセス1260は、処理対象のルールについてチャンク内の次のサンプル点を判定する。ルール処理プロセス1260は、チャンク内の次のサンプル点のチャンク座標を基にワールド座標を計算する、状態1440に進む。

状態1450で、ルール処理プロセス1260は、現在のサンプル点のルールに関する境界影響(boundary influence)を計算する。上述のように、境界とは、所望のルールが作用するように地形設計者または地形アーティストが定義した区域を指す。レイヤは、親/子関係を有する階層の形で配列することができる。例示的な境界としては、円、矩形、および多角形が挙げられる。地形生成システム内のレイヤでは、ルールの重複が許容されることから、地形生成システムは、重複区域における、目に見えて強い不連続性を最小限に抑えまたは回避するために、境界エッジとフィルタとをフェザリングすることができる。フェザリングは、区域を指定された形で混合する手法であり、これには重複区域における高度と色の混合が含まれる。境界影響を計算する状態1450の処理は、図15に関して以下で説明する。

ルール処理プロセス1260は、現在のサンプル点におけるルールのフィルタ影響(filter influence)を計算する、状態1460に進む。フィルタとは、影響因子を適用するときに考慮されるべき条件を指す。例示的なフィルタとしては、傾斜、高度、シェーダ、方向、またはフラクタルによるフィルタリングが挙げられる。フラクタルシステムが生成するパターンは、資源システムが惑星を資源で埋めるのに使用することができる。ユーザは、資源の割付けのためのフラクタルパラメータを区域毎に構成することができる。例示的な影響因子としては、高度、色、シェーダ、植物相、および放射状植物相に影響を及ぼすものが挙げられる。

フィルタ影響を計算する状態1460の処理は、図16に関して以下で説明する。ルール処理プロセス1260は、現在のサンプル点の影響因子の処理を行う状態1470に進む。影響因子の処理を行う状態1470の処理は、図17に関して以下で説明する。

状態1480で、ルール処理プロセス1260は、状態1450、状態1460、および状態1470で計算された影響に基づいてサブレイヤの処理を行う。ルール処理プロセス1260は引き続き判断状態1484に進んで、処理すべきチャンク内のサンプル点がそれ以上存在するかどうか判定する。状態1484で、サンプル点がそれ以上存在すると判定された場合には、ルール処理プロセス1260は引き続き状態1430に戻って、上述のようにチャンク内の次のサンプル点を判定する。一方、状態1484で、チャンク内のサンプル点がそれ以上存在しないと判定された場合には、ルール処理プロセス1260は、状態1490に進む。さらに、判断状態1414で、レイヤ範囲がチャンク範囲と交差しないと判定された場合には、ルール処理プロセス1260は、終了状態1490に進む。ルール処理プロセス1260は、終了状態1490で終了する。

図15は、図14に示されるルール処理プロセスの境界影響計算プロセス(boundary influence computation process)1450に関する一実施形態を示す流れ図である。ルールの階層化では、ルールの重複が許容されることから、地形生成器は、ルールが重複したときの目に見えて強い不連続性を最小限に抑えまたは防止するために、境界エッジをフェザリングすることができる。フェザリングは、混合区域を指定する手法であり、高度と色を混合する操作である。実施形態に応じて図15の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

境界影響計算プロセス1450は、開始状態1510から開始する。境界影響計算プロセス1450は引き続き状態1520に進んで、処理対象のルールについてレイヤ内の次の境界を判定する。状態1530で、境界影響計算プロセス1450は、状態1520で判定されたレイヤ内の次の境界の影響を計算する。状態1540で、境界影響計算プロセス1450は、影響値のフェザリングを行う。上述のように、フェザリングは、混合区域を指定する手法であり、地形ルールの重複時の視覚可能な強い不連続性が回避されるように高度と色を混合する操作である。

境界影響計算プロセス1450は引き続き状態1550に進んで、最大の影響値を保持する。境界影響は、重複境界区域のいずれかに地形ポイントが所在する場合に適用されるものなので、最大の影響値が保持される。判断状態1560で、境界影響計算プロセス1450は、レイヤ内に処理すべき境界がそれ以上存在するかどうか判定する。判断状態1560で、境界がそれ以上存在すると判定された場合には、境界影響計算プロセス1450は引き続き状態1520に戻って、レイヤ内の次の境界を判定する。一方、判断状態1560で、境界がそれ以上存在しないと判定された場合には、境界影響計算プロセス1450は引き続き判断状態1570に進んで、境界が反転されているかどうか判定する。

判断状態1570で、境界が反転されていると判定された場合には、境界影響計算プロセス1450は引き続き状態1580に進んで、境界がそれ以上反転されないように境界影響を調整する。一方、判断状態1570で、境界が反転されていないと判定された場合には、または状態1580の後、境界影響計算プロセス1450は、終了状態1590に進む。境界影響計算プロセス1450は、終了状態1590で終了する。

図16は、図14に示されるルール処理プロセス1260のフィルタ影響計算プロセス1460に関する一実施形態を示す流れ図である。フィルタルールの階層化では、ルールが互いに重複することが許容されることから、地形生成器は、ルールが重複したポイントにおける目に見えて強い不連続性を最小限に抑えまたは防止するために、フィルタルールのフェザリングを行うことができる。実施形態に応じて図16の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

フィルタ影響計算プロセス1460は、開始状態1610から開始する。フィルタ影響計算プロセス1460は引き続き状態1620に進んで、処理対象のルールについてレイヤ内の次のフィルタを判定する。状態1630で、フィルタ影響計算プロセス1460は、状態1620で判定されたレイヤ内の次のフィルタの影響を計算する。状態1640で、フィルタ影響計算プロセス1460は、影響値のフェザリングを行う。上述のように、フェザリングは、混合区域を指定する手法であり、地形ルールの重複時の目に見えて強い不連続性が防止されるように高度と色を混合する操作である。

フィルタ影響計算プロセス1460は引き続き状態1650に進んで、最小の影響値を保持する。フィルタ条件は、定義された全ての重複フィルタ区域を地形ポイントが満足する場合に適用されるものなので、最小の影響値が保持される。判断状態1660で、フィルタ影響計算プロセス1460は、レイヤ内に処理すべきフィルタがそれ以上存在するかどうか判定する。判断状態1660で、フィルタがそれ以上存在すると判定された場合には、フィルタ影響計算プロセス1460は引き続き状態1620に戻って、レイヤ内の次のフィルタを判定する。一方、判断状態1660で、フィルタがそれ以上存在しないと判定された場合には、フィルタ影響計算プロセス1460は引き続き判断状態1670に進んで、フィルタが反転されているかどうか判定する。

判断状態1670で、フィルタが反転されていると判定された場合には、フィルタ影響計算プロセス1460は引き続き状態1680に進んで、フィルタがそれ以上反転されないようにフィルタ影響を調整する。一方、判断状態1670で、フィルタが反転されていないと判定された場合には、または状態1680の後に、フィルタ影響計算プロセス1460は、終了状態1690に進む。フィルタ影響計算プロセス1460は、終了状態1690で終了する。

図17は、図14に示されるルール処理プロセス1260の影響因子処理プロセス(affectors processing process)1470に関する一実施形態を示す流れ図である。地形生成システムにおけるルールは、影響因子とも呼ばれ、複数のレイヤに編成することができる。影響因子の例としては、高度、色、シェーダ、植物相、および放射状植物相に影響を及ぼすものが挙げられる。実施形態に応じて図17の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

影響因子処理プロセス1470は、開始状態1710から開始する。影響因子処理プロセス1470は引き続き状態1720に進んで、ワールド原点における影響を判定する。判断状態1730で、影響因子処理プロセス1470は、状態1720で判定された影響がゼロよりも大きいかどうか判定する。判断状態1730で、影響がゼロよりも大きいと判定された場合には、影響因子処理プロセス1470は引き続き状態1740に進んで、修正すべき地形バッファを選択する。

状態1750で、影響因子処理プロセス1470は、状態1740で選択された2D地形バッファを修正する。一例として、地形高度に影響を及ぼすルールの場合では、所与の影響について地形高度が計算され、2D高度バッファに書き込まれる。色バッファも修正されるべき場合には、所与の影響について新しい色が計算され、色バッファに書き込まれる。バッファ修正状態1750の後、または判断状態1730で影響がゼロより大きくないと判定された場合には、影響因子処理プロセス1470は、終了状態1790に進む。影響因子処理プロセス1470は、終了状態1790で終了する。

図18は、サーバ側のチャンクマネージャモジュール330またはクライアント側のチャンクマネージャモジュール430によって実行される、地形生成プロセス1100のチャンククリーンアッププロセス1120に関する一実施形態を示す流れ図である。任意の所与の時点に生成され得る地形チャンクの数は、使用可能なシステムメモリなどのシステム資源によって制限される。チャンク数がチャンク限界を超えたときは、以下で説明する優先順位に基づいてチャンクが削除される。実施形態に応じて図18の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

チャンククリーンアッププロセス1120は、開始状態1810から開始する。チャンククリーンアッププロセス1120は引き続き判断状態1820に進んで、チャンク数が閾値の値を超えているかどうか判定する。チャンクに関する閾値の値は、サーバまたはクライアントコンピュータのシステム構成に適した数となるように修正することができる。例えば、閾値の値は、システムが大容量のコンピュータメモリを有する場合は増加させることができ、システムが小容量のコンピュータメモリを有する場合は減少させることができる。

判断状態1820で、チャンク数が閾値の値を超えていると判定された場合には、チャンククリーンアッププロセス1120は引き続き状態1830に進んで、各チャンクに優先順位を割り当てる。いくつかの実施形態では、チャンクの優先順位は、高(high)優先順位と、中(medium)優先順位と、中低(medium-low)優先順位と、低(low)優先順位とを含む。高優先順位のチャンクは、移動オブジェクトが惑星中を動き回るのに従って移動オブジェクト下の地形が生成されるような、移動オブジェクト下のチャンクである。中優先順位のチャンクは、移動オブジェクト下のチャンクに隣接するチャンクであり、当該オブジェクトが現在移動している方向にあるチャンクである。中低優先順位のチャンクは、移動オブジェクト下のチャンクに隣接するチャンクであり、当該オブジェクトが現在移動している方向とは反対方向にあるチャンクである。低優先順位のチャンクは、移動オブジェクト下に所在せず、移動オブジェクト下のチャンクに隣接しないチャンクである。他の実施形態では、他の優先順位およびスキームならびに上述の優先順位以外の優先順位を判定する他の基準が、利用されることもある。

状態1840で、チャンククリーンアッププロセス1120は、優先順位に基づいてチャンクを削除する。いくつかの実施形態では、チャンククリーンアッププロセス1120は、残りのチャンク数がチャンクの閾値の値と等しくなるようにするのに十分な数のチャンクを削除する。別法として、チャンククリーンアッププロセス1120は、残りのチャンク数がチャンクの閾値の値を幾分下回るようにするのに十分な数のチャンクを削除することもでき、このため、追加的なチャンクを削除する必要が生じる前に、ある数の追加的な新しいチャンクを生成することができるようになる。

状態1850で、チャンククリーンアッププロセス1120は、新たに生成されるチャンクでの再利用を目的とする保存、またはさらなるメモリ割付けを目的とするオペレーティングシステムへの返却のために、チャンクのメモリをバッファマネージャに返却する。図13に関して上述したように、オペレーティングシステムからのメモリ割付けは、新しいチャンクに既に割り付けられているメモリを再利用することよりも長い時間が掛かる。状態1850の後、または判断状態1820でチャンク数が閾値の値を超えていないと判定された場合には、チャンククリーンアッププロセス1120は、終了状態1890に進む。チャンククリーンアッププロセス1120は、終了状態1890で終了する。

図19は、植物相マネージャモジュール440によって実行される、図11に示される地形生成プロセス1100の植物相マネージャ更新プロセス1170に関する一実施形態を示す流れ図である。実施形態に応じて図19の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

地形生成システムにおける植物相の特徴としては、プレーヤと共に移動するワールド空間ポイントにおける固定サイズの天球が挙げられる。例えば、植物相ポイントがこの天球の外にあるときは、植物相ポイントを反対側に鏡映することができ、また、タイル毎にデータが指定される地形生成器の放射状植物相マップから、パラメータを割り当てることができる。植物相の特徴は、「計画的植物相構成(planned flora arrangement)」を作付けしようとする地形デザイナまたは地形アーティストの望みを体現した物理ジオメトリの作付け構成(seeded arrangement)に対処することもできる。植物相は実際のジオメトリであることから、本影を使用して植物相を遮蔽物としてマーク付けすることも、植物相を遮蔽することもできる。

地形生成システムの放射状植物相の特徴としては、プレーヤと共に移動するワールド空間ポイントにおける固定サイズの天球が挙げられる。上述した植物相ポイントの場合と同様に、放射状植物相ポイントがこの天球の外にあるときは、放射状植物相ポイントを反対側に鏡映することができ、また、タイル毎にデータが指定される地形生成器の放射状植物相マップから、パラメータを割り当てることができる。放射状植物相は、シェーダ単位のレンダリングのためにバッファにソートすることができる。放射状植物相はシェーダ内で、正しいアルファソートのために逆順にソートすることができる。現在の放射状植物相の特徴の最適化には、いくつかの植物相を単一のシェーダにまとめることを要することもある。

植物相マネージャ更新プロセス1170は、開始状態1910から開始する。植物相マネージャ更新プロセス1170は引き続き状態1920に進んで、参照オブジェクト同士の位置の差分(差)を計算する。例えばこの差分は、オブジェクトの位置が最後にチェックされ記憶された時点からある移動オブジェクトが移動した分の距離とすることができる。植物相マネージャ更新プロセス1170は引き続き状態1930に進んで、次に配置すべき植物相ポイントを判定し、その植物相のレンダリングを行う。いくつかの実施形態では、移動オブジェクトの周囲の所与の距離範囲内すなわち半径範囲内に、あるタイプの植物相だけが表示される。

判断状態1940で、植物相マネージャ更新プロセス1170は、次の植物相ポイントが、更新された移動オブジェクトの位置を取り囲む新しい円の外側にあるかどうか判定する。判断状態1940で、そのポイントが新しい円の外側にないと判定された場合には、植物相マネージャ更新プロセス1170は引き続き状態1950に進んで、ワールド内のオブジェクトの新しい位置に基づいて新しい植物相位置を計算する。状態1950の後、または判断状態1940で次のポイントが新しい円の外側にないと判定された場合には、植物相マネージャ更新プロセス1170は引き続き判断状態1960に進んで、処理すべき植物相ポイントがそれ以上存在するかどうか判定する。

判断状態1960で、処理すべき植物相ポイントがそれ以上存在すると判定された場合には、植物相マネージャ更新プロセス1170は引き続き状態1930に戻って、次の植物相ポイントを判定する。一方、判断状態1960で、処理すべき植物相ポイントがそれ以上存在しないと判定された場合には、植物相マネージャ更新プロセス1170は、終了状態1990に進む。植物相マネージャ更新プロセス1170は、終了状態1990で終了する。

図20は、図9に示される最上位実行プロセス900のワールド描画プロセス(world draw process)980に関する一実施形態を示す流れ図である。ワールド描画プロセス980は、クライアントコンピュータの表示画面上に仮想ワールド内の地形を写実的にレンダリングする。実施形態に応じて図20の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

ワールド描画プロセス980は開始状態2010から開始する。ワールド描画プロセス980は引き続き状態2020に進んで、仮想ワールド内のアバターなどレンダリング対象の他の非地形関連オブジェクトをグラフィックスシステムに提供する。ワールド描画プロセス980は引き続き状態2030に進んで、手続的地形生成システムによって生成された地形を写実的にレンダリングする。状態2040で、ワールド描画プロセス980は、図19に関して上述した植物相マネージャ更新プロセス1170によって判定された植物相をレンダリングする。ワールド描画プロセス980は、終了状態2090に進む。ワールド描画プロセス980は、終了状態2090で終了する。

図21は、地形生成システムの植物相高速配置プロセス(fast flora placement process)2100に関する一実施形態を示す流れ図である。植物相高速配置プロセス2100は、現在視点の周囲に最小数の正確かつ詳細な植物相を生成する。例えば、植物相高速配置プロセス2100は、地形の植物相を必要な場合にだけ生成する。実施形態に応じて図21の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

植物相高速配置プロセス2100は、開始状態2110から開始する。植物相高速配置プロセス2100は引き続き状態2120に進んで、次に配置すべき植物相ポイントを判定し、その植物相のレンダリングを行う。いくつかの実施形態では、移動オブジェクトの周囲の所与の距離範囲内すなわち半径範囲内に、あるタイプの植物相だけが表示される。判断状態2130で、植物相高速配置プロセス2100は、次の植物相ポイントが、更新された移動オブジェクトの位置を取り囲む新しい円の外側にあるかどうか判定する。判断状態2130で、そのポイントが新しい円の外側にあると判定された場合には、植物相高速配置プロセス2100は引き続き状態2140に進んで、ワールド内のオブジェクトの新しい位置に基づいて新しい植物相位置を計算する。状態2150で、植物相高速配置プロセス2100は、作成すべき植物相タイプの地形を照会する。植物相タイプのいくつかの例は、草、低木、および樹木である。状態2150の後、または判断状態2130で次のポイントが新しい円の外側にないと判定された場合には、植物相高速配置プロセス2100は引き続き判断状態2160に進んで、処理すべき植物相ポイントがそれ以上存在するかどうか判定する。

判断状態2160で、処理すべき植物相ポイントがそれ以上存在すると判定された場合には、植物相高速配置プロセス2100は引き続き状態2120に戻って、次の植物相ポイントを判定する。一方、判断状態2160で、処理すべき植物相ポイントがそれ以上存在しないと判定された場合には、植物相高速配置プロセス2100は、終了状態2190に進む。植物相高速配置プロセス2100は、終了状態2190で終了する。

図22は、図10に示される地形前処理プロセス930の植物相リスト作成プロセス1040に関する一実施形態を示す流れ図である。実施形態に応じて図22の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

植物相リスト作成プロセス1040は、開始状態2210から開始する。植物相リスト作成プロセス1040は引き続き状態2220に進んで、植物相リスト内の次の植物相タイプを判定する。状態2230で、植物相リスト作成プロセス1040は、植物相タイプに関する植物相ポイントの密度を計算する。植物相リスト作成プロセス1040は引き続き判断状態2240に進んで、リスト内に植物相タイプがそれ以上存在するかどうか判定する。

判断状態2240で、リスト内に植物相タイプがそれ以上存在すると判定された場合には、植物相リスト作成プロセス1040は引き続き状態2220に戻って、次の植物相タイプを判定する。一方、判断状態2240で、植物相タイプがそれ以上存在しないと判定された場合には、植物相リスト作成プロセス1040は、終了状態2290に進む。植物相リスト作成プロセス1040は、終了状態2290で終了する。

図23は、地形生成システムの実時間道路生成プロセス(real-time road generation process)2300に関する一実施形態を示す流れ図である。仮想ワールド内の道路を生成するために、地形生成システムは、道路のない基礎地形を生成し、次いで道路用の地形を修正し、道路を比較的平坦に保つために道路の幅に沿って地形を平滑化し、道路の長さに沿って地形の傾斜の極端な変動を最小限に抑えようと試みる。実施形態に応じて図23の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

さらに、実時間道路生成プロセス2300は、既存の地形をシェーディングし平坦化することと、道路に路肩を追加することと、その路肩を周囲の地形とフェザリング(混合)し、それによって路肩と境界地形の間の鮮鋭なコントラストまたは不連続性を地形にもたせる代わりに、地形が周囲の地形に滑らかに遷移するようにすることとを含む。

実時間道路生成プロセス2300は、開始状態2310から開始する。実時間道路生成プロセス2300は引き続き状態2320に進んで、道路の影響が及ぶ地形上の次のポイントを判定する。判断状態2324で、実時間道路生成プロセス2300は、次のポイントが道路の範囲内にあるかどうか判定する。言い換えれば、道路の影響が及ぶ地形ポイント内に次のポイントがあるかどうかが判定される。上記のポイントが道路の範囲内にあると判定された場合には、実時間道路生成プロセス2300は引き続き状態2330に進んで、そのポイントから道路セグメントまでの距離、または道路の中心からの距離を判定する。

判断状態2334で、実時間道路生成プロセス2300は、状態2330で計算された距離が道路の幅に路肩の幅を足した距離よりも小さいかどうか判定する。判断状態2334で、その距離が道路の幅に路肩の幅を足した距離よりも小さいと判定された場合には、実時間道路生成プロセス2300は引き続き判断状態2338に進んで、その距離が道路の幅よりも小さいかどうか判定する。判断状態2338で、その距離が道路の幅より小さくないと判定された場合には、実時間道路生成プロセス2300は引き続き状態2340に進んで、道路の影響が及ぶポイントに関する元の地形高度を保存する。

状態2344で、実時間道路生成プロセス2300は、道路セグメント沿いの高度を判定する。実時間道路生成プロセス2300は引き続き状態2350に進んで、道路の路肩と、その道路の影響が及ばない周囲の地形との間の、どのような鮮鋭な不連続性も取り除く路肩のフェザリングに関する高度を補間する。状態2354で、実時間道路生成プロセス2300は、結果的に得られるシェーダを道路の路肩のシェーダと同じになるように設定する。

一方、判断状態2338で、次のポイントから道路セグメントまでの距離が道路の幅よりも小さいと判定された場合には、実時間道路生成プロセス2300は引き続き状態2360に戻って、道路セグメント沿いの高度を補間する。状態2370で、実時間道路生成プロセス2300は、その結果得られたシェーダを道路シェーダにセットする。

状態2354および状態2370の後に、判断状態2324で、次のポイントが道路の範囲内にないと判定された場合、または判断状態2334で、上記の距離が道路の幅に路肩の幅を足した距離より小さくないと判定された場合には、実時間道路生成プロセス2300は引き続き判断ブロック2374に進んで、道路の影響が及ぶポイントがそれ以上存在するかどうか判定する。状態2374で、道路の影響が及ぶポイントがそれ以上存在すると判定された場合には、実時間道路生成プロセス2300は引き続き状態2320に進んで、道路の影響が及ぶ次のポイントを判定する。一方、状態2374で、道路の影響が及ぶポイントがそれ以上存在しないと判定された場合には、実時間道路生成プロセス2300は、終了状態2390に進む。実時間道路生成プロセス2300は、終了状態2390で終了する。

図24は、地形生成システムのサーバ側システムにおける地形前処理プロセス830に関する一実施形態を示す流れ図である。実施形態に応じて図24の各状態の順序付けを再編成することができ、また、別の状態を追加することも他の状態を省略することもできる。

地形前処理プロセス830は、開始状態2410から開始する。地形前処理プロセス830は引き続き状態2420に進んで道路セグメントデータの前処理を行う。状態2420における道路セグメントデータの前処理は、道路セグメントに基づいて、例えば道路の中心経路と道路の幅とを定義するように連接されたラインセグメントに基づいて、道路ポイントの座標を判定することを含む。さらに、状態2420における道路の前処理は、既存の地形をシェーディングし平坦化することと、道路に路肩を追加することと、その路肩を周囲の地形とフェザリング(混合)し、それによって路肩と境界地形の間の鮮鋭なコントラストまたは不連続性を地形にもたせる代わりに、地形が周囲の地形に滑らかに遷移するようにすることとを含む。実時間道路生成のプロセスは、図23に関しては上述した通りである。

状態2430で、地形前処理プロセス830は、河川セグメントデータの前処理を行う。状態2430における河川セグメントデータの前処理は、上述の状態2420における道路の前処理と同様である。しかしながら、道路がそうすることはあっても、河川は上り坂に向かって流れることはないので、状態2430における河川の前処理は、河川が平らな方向又は下り坂の方向にしか流れないことを保証するのに必要なだけ、既存の地形に切込みを入れる。さらに、河川は道路と異なり河川の深さを定義する地形中の深さを有することから、状態2430における河川の前処理は、既存の地形に溝深度を追加することを含んでいる。地形前処理プロセス830は、終了状態2490に進む。地形前処理プロセス830は、終了状態2490で終了する。

図25は、何らの地形特徴も定義されていない仮想ワールドを示す画面表示2500の一例を示す図である。この例では、地形についてシェーダが定義されていない場合はデフォルトで、所定のシェーダ2510が適用される。画面表示2500は、何らかの地形特徴が定義される前のワールドに関する地形開始ポイントを示している。後続の4つの図面、すなわち以下で説明する図26〜29は、図25のデフォルト画面表示に様々な地形特徴が追加された別の画面表示を示している。

図26は、何らの地形特徴も定義されていない図25に示されるデフォルト地形に山および他の様々な地形高度が追加された画面表示の一例を示している。

図27は、図26に示される地形高度の特徴に加えて、地面テクスチャ用のシェーダ特徴(shader feature)も定義された画面表示の一例を示す図である。

図28は、図27に示される他の地形特徴に加えて、草、低木、および樹木を含めた植物相も定義された画面表示の一例である。

図29は、図28に示される他の地形特徴に加えて、河川も定義された画面表示の一例である。

図30は、地形ルールを入力および修正するための地形エディタツールに関する画面スナップショット3000の一例である。地形デザイナまたは地形アーティストは、地形エディタツール、デザイナおよびアーティストが区域およびファミリーを作成するのを可能にするカスタムグラフィカルユーザインターフェイスツール、ならびにそれらの区域およびファミリーに関連するルール(影響因子)を使用して、地形特徴を編集することができる。いくつかの実施形態では、地形エディタツールは、地形エディタツールを使用してデザイナまたはアーティストによって定義された地形に従って地形を生成しレンダリングするために、地形生成器によって使用されるバイナリファイルを生成する。

地形エディタツールのマップビューは、2Dの地形ビューである。ユーザは、地形のメタデータ表現を見ることができ、これには、高度 (例えば、グレースケール高度フィールド)、色(例えば、色と高度フィールドとの混合)、シェーダ(例えば、シェーダの配置を表す色)、植物相(例えば、植物相の配置を表す色)、放射状植物相(例えば、放射状植物相の配置を表す色)、および水面(例えば、青色で表される)を見ることができる能力が含まれる。地形メタデータとは、地形生成器(2Dバッファ)内を流れるデータを指し、地形ジオメトリを作成し、植物相、表面特性、環境データなどの地形オブジェクトをどこに配置すべきかを地形生成システムに記述するために使用されるものである。ユーザは、ユーザ自身がそのような選択を行えば、個々の各表現をオフに切り換えることもできる。このマップビューでは、地形データの視覚的表現に加えて、境界の編集も行われる。ユーザは、例えば円、矩形、および多角形の境界を作成することができる。

レイヤビューは、地形ルールの階層的(ツリー)ビューである。ユーザは、例えばルールを作成、削除、移動、複製、インポート、およびエクスポートすることができる。ユーザは、レイヤビューを利用して、特性ビュー内のどのルールを編集するか選択することができる。

特性ビューは、ユーザがそこから個々のルールのパラメータを修正することができる制御部を有するフォームビューである。ファミリービューは、デザイナまたはアーティストが、例えばシェーダ、混合物、フラクタル、植物相、および放射状植物相のファミリーを作成し編集することを可能にする。ファミリービューは、資産のプレビューも可能にする。地形ルールに加えられた変更をデザイナまたはアーティストが迅速に閲覧することを可能にするために、一人称ビュー(first-person view)は、ユーザがあたかもゲーム内の地形中を歩き回っているかのように地形を見せる。

地形エディタツールは、例えば以下の機能を含むことができる。

1) 惑星パラメータを設定する:惑星パラメータ、惑星サイズ、チャンクおよびタイルサイズ、植物相の総数など。

2) コンパイル完了警告/エラーをルール化する:資産の有効化だけでなく、無効または未完了のパラメータを示し、ゲームでロードされたデータが正しいことを保証する。例えば、FilterHeightに関して高い高度が低い高度よりも高くなることを保証することや、AffectorShaderを適用する場合に、適用されるシェーダが使用可能な資産として存在するのを保証することが挙げられる。

3) ルールのボトルネックを判定するルールプロファイリング:地形エディタツールを用いたルールの適用に関する完全な制御をユーザが有する。惑星は、数百ものルールを用いて記述することができるので、組込型プロファイラは、どのレイヤで最も資源が集中するかをユーザに示す。いくつかの実施形態では、地形エディタツールは、他の地形区域よりも生成に多くの時間が掛かる地形生成区域を写実的に識別することができる。

4) 資源マップの閲覧:資源システムはフラクタルを使用しており、そのため、デザイナは、資源を区域と関連付け、地形エディタ内のデータを閲覧することができる。

5) 静的な環境ブロックをレイアウトする:環境ブロックデータは、環境ブロックが区域と関連付けられるときに、地形エディタツール内で編集することができる。例えば、照明、背景、環境マップ、霧、および気象を指定することができる。

6) 表面特性:シェーダファミリーを用いると、デザイナおよびアーティストがシェーダに関する表面特性を編集することが可能になる。

地形デザイナおよび地形アーティストは、地形エディタツール、デザイナおよびアーティストが区域およびファミリーを作成するのを可能にするカスタムユーザインターフェイスツール、ならびにそれらの区域およびファミリーに関連するルール(影響因子)を使用して、地形特徴を定義し編集することができる。地形エディタツールは、2Dの地形ビューであるマップビューを含む。地形エディタツールはまた、地形ルールの階層(ツリー)ビューであるレイヤビューを含む。地形エディタツールはさらに、ユーザがそこから個々のルールのパラメータを修正することができる制御部を有するフォームビューである、特性ビューを含む。地形エディタツールは、地形デザイナおよび地形アーティストによって入力された地形定義に従って地形特徴を定義する、手続的ルールを自動的に生成することができる。地形は、実時間で解釈されレンダリングされる地形特徴を定義する、1組のルールとして記憶される。地形エディタツールは、図30〜34に関して以下でより詳細に説明する。

高度フィールドに由来する地形生成用データを用いて、地形生成システムは通常、尖塔、アーチ、および人の関心を引くような造岩向けの地形を垂直壁上に作成することができない。その代わりに、ユーザは、地形上に静的メッシュを配置することによって垂直壁を作成することができる。

図30に示される地形エディタツールの画面スナップショット3000は、2Dの地形ビューを表示する2Dマップウィンドウ3010を含む。図30に示される2Dマップウィンドウ3010では、ユーザは、矩形、円、多角形、および線分群(ラインセグメントの周りに構築される多角形)を定義している。これらの定義済みオブジェクト内に示されるシェーディングは、オブジェクトの境界のフェザリング効果を示している。

図30の地形エディタツールの画面スナップショット3000はさらに、構成レイヤウィンドウ(construction layers window)3020も含んでいる。構成レイヤウィンドウ3020は、地形ルールの階層(ツリー)ビューを表示する。地形エディタツールの画面スナップショット3000はさらに、ユーザがそのウィンドウを介して地形内のオブジェクトの様々な特性を閲覧し修正することができる、特性ウィンドウ3030を含むこともできる。

図31は、地形エディタツールを使用してマップパラメータおよびシェーダの子特性を表示および入力するためのウィンドウを示す画面スナップショット3100の一例である。図31に示される地形エディタツールの画面スナップショット3100は、ファミリーデータやシェーダデータなどシェーダの子特性を閲覧し修正するための、特性ウィンドウ3110を含む。地形エディタツールの画面スナップショット3100はさらに、グローバルパラメータ、グローバル水面のテーブルパラメータ、およびグローバル環境パラメータなど様々なマップパラメータを閲覧し修正するための、マップパラメータウィンドウ3120を含む。

図32は、地形エディタツールを使用して植物相パラメータを表示および入力するためのウィンドウを示す画面スナップショット3200の一例である。植物相パラメータの画面スナップショット3200は、現在値をユーザに表示し、距離、タイルサイズ、タイルの境界およびシードに関する最大値および最小値をユーザが修正することを可能にする。植物相パラメータの画面スナップショット3200は、衝突可能植物相および衝突不可能植物相、ならびに近隣放射状植物相および遠方放射状植物相に関する値をユーザに表示し、これらの値をユーザが修正することを可能にする。さらに、地形エディタツールは、上記のパラメータに関する現在の設定に基づいて生成されレンダリングされる概算的な植物相の合計を計算し表示する。概算的な植物相の合計に関するこれらの計算値は、表示専用パラメータであり、ユーザが修正することはできない。

図33は、地形エディタツールを使用して入力される2D地形マップの一例を示す画面スナップショット3300の一例である。図33に示される画面スナップショット3300は、シェーダファミリーウィンドウ3310と、放射状植物相ファミリーウィンドウ3320と、環境ウィンドウ3330と、構成レイヤウィンドウ3340と、特性ウィンドウ3350と、2Dマップウィンドウ3360とを含む。

図34は、地形エディタツールを使用して入力される2D地形マップの別の例を示す画面スナップショット3400の一例である。図34に示される画面スナップショット3400のウィンドウは、例えば図33に示されるものと同様である。しかしながら、図34の画面スナップショット3400では、2Dマップウィンドウ3410は、異なる地形を示しており、図34の構成レイヤウィンドウ3420は、画面スナップショット3400のほぼ全体の高さまで拡大するようにサイズが増加されている。

図30〜34の例示的なスクリーンショットは、閲覧および修正され得るパラメータおよび特性に関するいくつかの例を示しているが、図示されていないより多くのパラメータおよび特性が存在する。地形エディタツールを使用して閲覧および修正され得る追加的なパラメータおよび特性を、以下の表(表I)に列挙する。

以下のルールレイヤは、地形ルールの別の例を定義する。この例では、砂シェーダ、高度20メートルの緩やかな起伏の丘、照明用の砂漠環境、周囲音、太陽/月/空、砂丘色斜面(sand dune color ramp)、および小さな岩からなる惑星全体にわたって、ベース地形レイヤが適用される。次に、指定のフラクタル出力が0.45〜0.55の間となる領域内では、地形に対して7メートル置きに段を設け、地形の照明を褐色に色付けする。原点を中心とする半径100メートルの円内では、地形高度を0メートルまで徐々に低下させていき、湿地環境を適用し、湿地帯樹木を適用し、地下水面(water table)に高度4メートルの湿地水を配置する。さらに、高度17メートルを超える地形の任意の領域に関しては、砂シェーダを風に舞う砂で置き換える。次に、60度を超える急峻な斜面上で、色付き斜面(color ramp)が存在するどの場所にも崖面色斜面(cliff face color ramp)を適用する。次に、原点周囲にある500平方メートルの面積の多角形内において、北向きの任意の傾斜上に小草を配置する。次に、洞窟の入口として、地形内に20メートル×20メートルの小さな穴を開ける。最後に、西1メートルを始点とし、原点(0,0)を終点とする幅20メートルの河川を追加し、北1キロメートルを始点とし、原点を終点とする幅10メートルの道路を追加する。

1)レイヤ:ベース地形
1.AffectorShaderConstant、砂
2.AffectorHeightFractal、高度20メートルの起伏ある丘
3.AffectorEnvironment:砂漠
4.AffectorColorRampFractal、砂丘色斜面
5.AffectorFloraNonCollidableConstant:小さな岩
2)レイヤ:フラクタルフィルタに基づく段の高さ
1.FilterFractal、0.45、0.55
2.AffectorHeightTerrace、7mの段
3.AffectorColorConstant、照明を褐色にする
3)レイヤ:原点付近の高さを低下させる
1.BoundaryCircle、x=0, z=0, r=100
2.BoundaryRectangle、x=-100, z=-100, x=100, z=100、湿地水、高度4m
3.AffectorHeightConstant、0メートル
4.AffectorEnvironment、湿地帯
5.AffectorFloraCollidableConstant、湿地帯樹木
4)レイヤ:全ての砂丘の上面にシェーダバンドを作成する
1.FilterHeight、17m、100m
2.AffectorShaderReplace、砂を風に舞う砂で置き換える
5)レイヤ:砂シェーダが使用される場合は、急峻な傾斜上に色付き斜面を追加する
1.FilterSlope、(60度〜90度)
2.FilterShader、砂
3.AffectorColorRampHeight、崖面色斜面
6)レイヤ:原点付近の北向きの丘上の草だけが育つ
1.BoundaryPolygon、約500平方メートルの領域となる凸多角形を描画する
2.FilterDirection、北(-15度〜15度)
3.AffectorRadialNearConstant、小草
7)レイヤ:洞窟の入口用に地形を取り除く
1.BoundaryRectangle、x0=-30, y0=40, x1=-10, y1=60
2.AffectorExclude
8)レイヤ:道路および河川
1.AffectorRoad、startX=0, startZ=1000, endX=0, endZ=0, width=8
2.AffectorRiver、startX=-1000, startZ=0, endX=0, endZ=0, width=20, depth=10
地形生成システムにおける、実施形態は、ゲーム実行スレッドとは別の実行スレッド内の地形を生成することができる。走る速度または歩行速度で移動するシングルプロセッサマシーンを有するプレーヤは、地形生成の悪影響を見ることはほとんどない。走る速度または歩行速度を超えて移動するときは、地形生成の何らかの性能低下が認識され得る可能性もある。マルチプロセッサマシンを有するプレーヤは、地形内を横断するときは事実上、ほぼ全てのプレーヤ速度においていかなる地形生成の悪影響も受けることはない。

一実施形態では、地形生成システムは、フレーム単位の地形生成に関する性能コストを最小限に抑えるために、地形生成のロードをいくつかのゲームフレームに分散させようと試みている。さらに、プレーヤが移動していないときは、地形生成システムは、プレーヤの移動要求を見越して地形を構築することができる。

いくつかの実施形態では、地形生成システムは、2つの組込型プロファイラを含む。第1のプロファイラは、地形生成器内で実行されるものであり、地形生成に関してより多くの時間を要するレイヤを判定する、ルール単位のルール分析を可能にする。クライアントコンピュータ上とサーバ上の両方でルールが解釈される場合は、ユーザは、地形生成ツール内のデータを閲覧して、ユーザ自身が各自のルールを最適化することが可能になるよう望むこともある。

第2のプロファイラは、デバッグモードで使用され得るものであり、地形生成システムが地形をレンダリングしている効率性に関する情報をユーザに与えることができる。シェーダとなるバケツ、混合物、レンダリングされる植物相および放射状植物相の数などの情報は、ユーザがクライアント地形データを最適化する際に役立つ可能性がある。

地形生成システムは、クライアント/サーバ型アプリケーションで生成される地形の量を制限する技法など、様々な追加の最適化技法を含むこともできる。クライアント/サーバ型アプリケーションに関するメモリやディスク空間などの資源は、必要なときにだけ地形を生成することによって最小限に抑えることができる。例えば、地形生成システムは、これらの条件を識別するのに使用される様々なメトリクスおよび条件を詳細化することができる。

地形システムは、4分木のジオグラフィ(quad tree geography)を使用して、詳細レベルを表示すべきチャンクを判定することができる(これは詳細レベル技法すなわちLOD技法と呼ばれる)。所望の詳細レベルにチャンクが存在しない場合は、地形生成システムは、例えば高度情報、色情報、シェーダ情報、植物相情報、および放射状植物相情報に対応するビットマップを地形生成器に要求する。

いくつかの実施形態では、地形の詳細レベルは、サーバ側では使用されない。しかしながら、サーバ側地形生成システムは、クライアント側システムと同じチャンクおよびタイルの編成パターンを使用することができる。サーバは、地形生成が望まれるオブジェクト下の地形チャンクを生成する。

地形生成システムは、タイル型テクスチャのアプローチを使用することができる。シェーダマップは、(場合よっては一意の)テクスチャを特定のタイルと関連付けるために使用される。タイルが隣接する2つの異なるファミリーの場合では、混合シェーダは、適切なアルファマップを用いて、周囲のシェーダに応じて自動的に生成される。例えば、シェーダは、隣接シェーダと同じファミリーを共用することができ、ワンパスでレンダリングされ得る。別法として、シェーダは、最大4つのシェーダと、3つの混合物とを有することが可能である。ピクセル単位の照明用に標準マップ内にテクスチャを追加するときは、テクスチャの数が、例えばタイル毎に11個のテクスチャに達することもある。

タイル毎に異なる多数の描画コールが地形生成システムに届くのを回避するために、地形生成システムは、レンダリングすべきタイルを地形基本ソータ(terrain primitive sorter)内で整列させる。地形基本ソータは、柔軟な頂点フォーマット(flexible vertex format:FVF)の切換えに最も資源が集中することから、頂点バッファフォーマット(vertex buffer format)に従ってソートを行う。FVFリスト内で、地形基本ソータは、同様のシェーダを有するタイルを1つの束にする(batch up)。各FVF毎の各シェーダ束の内で、地形基本ソータは、1つの大きな動的頂点バッファを構築し、それにより、最適なレンダリング(例えば、256K)のための頂点バッファ毎のタイル数が最大化され、可能な限り少ない描画コールでジオメトリがカードに送られる。この技法だけでも、地形のレンダリング性能を300%向上させることができる。

地形生成システムのいくつかの実施形態は、頂点の色付け(vertex coloring)、動的照明、およびピクセル単位のバンプマッピングを使用して地形を照らす。頂点の色付けは、テクスチャ内で視覚可能なタイリングを解体するのに使用される。動的照明は、時刻を取り扱うのに使用される。地形生成システムは、地形のジオメトリを構築するときにこうした照明考慮事項を利用する。

地形生成システムは、影を付けることはないが、影を受けることはある。ただし、これは性能のトレードオフの結果であり、地形生成システムの他の実施形態は、影を付けることも影を受けることもできる。

仮想ワールドの管理者は、地形エディタツールの惑星サイズを変更することによって大陸を容易に拡大することができる。ユーザが別のルールで新しい領域を変更するまで、地形は、基本ルールセットが適用されるようにする。ユーザは、初期の地形が開発された後はいつでも、その地形システムに新しいルールを追加することができる。ユーザは、新しい機能を活用するように選択することができ、ルールを位置に依存させることもできる。一例は、侵食がシミュレートされるようにフィールドの高度を修正する侵食影響因子(erosion affector)を追加すること、または照明を頂点色に焼き付ける影響因子を追加することである。

地形生成システムは、ルールのライブラリを再利用することができ、フラクタルのシードまたはパラメータの変更など軽微な修正を施すことによって新しい地形を生成することができる。地形ファイルはサイズが小さいことから、パッチングを介して新しいクライアントに送信することができる。このようにして、資産を有利な形で再利用しながら多くの惑星を定義することができる。

上記の詳細な説明が図示され記載され、様々な実施形態に適用される本発明の新規な特徴が指摘されてきたが、当業者なら本発明の意図から逸脱することなく、例示のデバイスまたはプロセスの形態および詳細を様々な形で省略し、置換えを行い、変更を加えることができることが理解されるであろう。本発明の範囲は、上記の記載によってではなく、添付の特許請求の範囲によって示される。添付の特許請求の範囲の意味およびその均等範囲内にある全ての変更が、添付の特許請求の範囲に包含される。

ルールベースの地形生成システムに関する諸実施形態を実行するためのコンピュータシステムの一例を示す図である。 地形生成システムのネットワーク構成の一例を示すブロック図である。 例示的な地形生成システムのネットワーク構成を示すブロック図である。 図1Aおよび2に示される様々なサーバの内の1つまたは複数のサーバ上で実行され得る、地形生成システムのサーバ側地形システムモジュールに関する一実施形態を示すブロック図である。 図1Aおよび2に示される様々なクライアントコンピュータの内の1つまたは複数のクライアントコンピュータ上で実行され得る、地形生成システムのクライアント側地形システムモジュールに関する一実施形態を示すブロック図である。 図2および4に示されるチャンクマネージャモジュールによって管理される、地形生成システム内の地形チャンクの構成に関する一例を示す図である。 図5に示される複数の隣接地形チャンクのワールド座標の一例を示す図である。 図5および6に示されるチャンクに関して、全体の地形チャンクを複数のタイルおよび三角形に分解する一例を示す図である。 図3に示されるサーバ側地形システムモジュールによって実行される、地形生成システムのサーバ側システムにおける最上位実行プロセスに関する一実施形態を示す流れ図である。 図4に示されるクライアント側地形システムモジュールによって実行される、地形生成システムのクライアント側システムにおける最上位実行プロセスに関する一実施形態を示す流れ図である。 図8に示されるサーバ側システムにおける最上位実行プロセスの地形前処理プロセスに関する一実施形態を示す流れ図である。 地形生成システムにおける地形生成プロセスの一実施形態を示す流れ図である。 図11に示される地形生成プロセスのチャンク生成プロセスに関する一実施形態を示す流れ図である。 図12に示されるチャンク生成プロセスの2Dバッファ割付けプロセスに関する一実施形態を示す流れ図である。 図12に示されるチャンク生成プロセスのルール処理プロセスに関する一実施形態を示す流れ図である。 図14に示されるルール処理プロセスの境界影響計算プロセスに関する一実施形態を示す流れ図である。 図14に示されるルール処理プロセスのフィルタ影響計算プロセスに関する一実施形態を示す流れ図である。 図14に示されるルール処理プロセスの影響因子処理プロセスに関する一実施形態を示す流れ図である。 サーバ側のチャンクマネージャモジュールまたはクライアント側のチャンクマネージャモジュールによって実行される、地形生成プロセスのチャンククリーンアッププロセスに関する一実施形態を示す流れ図である。 植物相マネージャモジュールによって実行される、図11に示される地形生成プロセスの植物相マネージャ更新プロセスに関する一実施形態を示す流れ図である。 図9に示される最上位実行プロセスのワールド描画プロセスに関する一実施形態を示す流れ図である。 地形生成システムの植物相高速配置プロセスに関する一実施形態を示す流れ図である。 地形生成システムの植物相密度計算プロセスに関する一実施形態を示す流れ図である。 地形生成システムの実時間道路生成プロセスに関する一実施形態を示す流れ図である。 地形生成システムのサーバ側システムにおける地形前処理プロセスに関する一実施形態を示す流れ図である。 何らの地形特徴も定義されていない仮想ワールドを示す画面表示の一例を示す図である。 何らの地形特徴も定義されていない図25に示されるデフォルト地形に山および他の様々な地形高度が追加された画面表示の一例を示す図である。 図26に示される地形高度の特徴に加えて、地面テクスチャ用のシェーダ特徴も定義された画面表示の一例を示す図である。 図27に示される他の地形特徴に加えて、草、低木、および樹木を含めた植物相も定義された画面表示の一例を示す図である。 図28に示される他の地形特徴に加えて、河川も定義された画面表示の一例を示す図である。 地形ルールを入力および修正するための地形エディタツールに関する画面スナップショットの一例を示す図である。 地形エディタツールを使用してマップパラメータおよびシェーダの子特性を表示および入力するためのウィンドウを示す画面スナップショットの一例を示す図である。 地形エディタツールを使用して植物相パラメータを表示および入力するためのウィンドウを示す画面スナップショットの一例を示す図である。 地形エディタツールを使用して入力される2D地形マップの一例を示す画面スナップショットの一例を示す図である。 地形エディタツールを使用して入力される2D地形マップの別の例を示す画面スナップショットの一例を示す図である。

Claims (47)

1. 仮想ワールド内の地形を生成するためのシステムであって、
   前記仮想ワールド内の仮想地形を生成するように構成された複数の手続的ルールを備え、
   前記複数の手続的ルールは、前記地形の単一の位置が、重複する複数の手続的ルールを有するように、階層に有機的に構成され、前記地形は、重複するルールを有する少なくとも１つの位置を有し、各階層は、境界、フィルタ及び影響因子を定義しており、更に、
   前記複数の手続的ルールを処理して前記地形の仮想表現を生成するように構成された地形生成器を備え、
   複数の手続的ルールが重複するとき、高度及び色を混合して、手続的ルールが重複したときの鮮明で視認できる不連続性を妨げるために、前記地形生成器は混合領域を特定し、境界影響計算を開始し、
   前記境界、フィルタ及び影響因子が論理的なテキスト形式で所望の属性を表す数値を割り当てられるように、前記複数の手続的ルールはテキスト表現され、
   前記地形は前記複数の手続的ルールから少なくとも１つのルールを追加又は削除することによって変更されるシステム。
2. マルチプレーヤコンピュータゲームにおいて生成された前記地形の前記仮想表現を表示するモジュールをさらに備える、請求項1に記載のシステム。
3. 前記手続的ルールの内の少なくとも1つは、前記仮想ワールド内のある領域を定義する、請求項1に記載のシステム。
4. 前記境界の各境界は、前記手続的ルールが作用する領域を画定する、請求項1に記載のシステム。
5. 前記各境界は、円、矩形、および多角形の内の1つである、請求項4に記載のシステム。
6. 前記フィルタの各フィルタは、前記手続的ルールを適用する前に満足されるべき1つまたは複数の条件を定義する、請求項1に記載のシステム。
7. 前記各フィルタは、傾斜、高度、シェーダ、方向、およびフラクタルの内の1つである、請求項6に記載のシステム。
8. 前記影響因子の各影響因子は、高度、色、シェーダ、植物相、および放射状植物相の内の1つの地形特性に影響を及ぼす、請求項1に記載のシステム。
9. 前記地形の前記仮想表現は、前記複数の手続的ルールに従って実時間で生成される、請求項1に記載のシステム。
10. 前記地形生成のある部分は、サーバ上で実施され、前記地形生成の別の部分は、クライアントコンピュータ上で実施される、請求項1に記載のシステム。
11. 仮想ワールド内の地形を生成する方法であって、
    前記仮想ワールド内の前記地形を定義する複数の手続的ルールを受信するステップを備え、
    前記複数の手続的ルールは、前記地形の単一の位置が、重複する複数の手続的ルールを有するように、階層に有機的に構成され、前記地形は、重複するルールを有する少なくとも１つの位置を有し、各階層は、境界、フィルタ及び影響因子を定義しており、更に、
    前記複数の手続的ルールに従って、前記仮想地形を地形生成器内で生成するステップを備え、
    複数の手続的ルールが重複するとき、高度及び色を混合して、手続的ルールが重複したときの鮮明で視認できる不連続性を妨げるために、前記地形生成器は混合領域を特定し、境界影響計算を開始し、
    前記境界、フィルタ及び影響因子が論理的なテキスト形式で所望の属性を表す数値を割り当てられるように、前記複数の手続的ルールはテキスト表現され、
    前記地形は前記複数の手続的ルールから少なくとも１つのルールを追加又は削除することによって変更される方法。
12. 生成された前記仮想地形を表示するステップをさらに含む、請求項11に記載の方法。
13. 前記境界影響計算は、影響値を用いて境界を混合することを含む、請求項11に記載の方法。
14. 前記境界を混合することは、最大の影響値を保持することを含む、請求項13に記載の方法。
15. 前記フィルタの各フィルタは、前記手続的ルールを適用する前に満足されるべき1つまたは複数の条件を定義する、請求項11に記載の方法。
16. 前記各フィルタは、傾斜、高度、シェーダ、方向、およびフラクタルの内の1つである、請求項15に記載の方法。
17. 前記影響因子の各影響因子は、高度、色、シェーダ、植物相、および放射状植物相の内の1つの地形特性に影響を及ぼす、請求項11に記載の方法。
18. 仮想ワールド内の地形を生成するためのコンピュータ実装されるシステムを含むコンピュータ読み取り可能な媒体であって、
    前記システムは、
    仮想ワールド内の前記地形を定義する複数の手続的ルールを受信する手段を備え、
    前記複数の手続的ルールは、前記地形の単一の位置が、重複する複数の手続的ルールを有するように、階層に有機的に構成され、前記地形は、重複するルールを有する少なくとも１つの位置を有し、各階層は、境界、フィルタ及び影響因子を定義しており、更に、
    前記複数の手続的ルールに従って前記仮想ワールド内の前記地形を生成する手段を備え、
    複数の手続的ルールが重複するとき、高度及び色を混合して、手続的ルールが重複したときの鮮明で視認できる不連続性を妨げるために、地形生成器は混合領域を特定し、境界影響計算を開始し、
    前記境界、フィルタ及び影響因子が論理的なテキスト形式で所望の属性を表す数値を割り当てられるように、前記複数の手続的ルールはテキスト表現され、
    前記地形は前記複数の手続的ルールから少なくとも１つのルールを追加又は削除することによって変更されるコンピュータ読み取り可能な媒体。
19. 生成された前記仮想地形を表示する手段をさらに備える、請求項18に記載のコンピュータ読み取り可能な媒体。
20. 前記コンピュータ実装されるシステムは、更に、どの階層が地形生成に関して最大の時間を要するかを決定するためにルール毎のルールの分析を提供し、ユーザが前記ルールを最適化できように構成されている第1のプロファイラを含む、請求項18に記載のコンピュータ読み取り可能な媒体。
21. 前記コンピュータ実装されるシステムは、更に、どの程度効率的に前記システムが前記地形を描画するかをユーザに知らせるように構成される第２のプロファイラを含む、請求項20に記載のコンピュータ読み取り可能な媒体。
22. 前記フィルタの各フィルタは、前記手続的ルールを適用する前に満足されるべき1つまたは複数の条件を定義する、請求項18に記載のコンピュータ読み取り可能な媒体。
23. 前記各フィルタは、傾斜、高度、シェーダ、方向、およびフラクタルの内の1つである、請求項22に記載のコンピュータ読み取り可能な媒体。
24. 前記影響因子の各影響因子は、高度、色、シェーダ、植物相、および放射状植物相の内の1つの地形特性に影響を及ぼす、請求項18に記載のコンピュータ読み取り可能な媒体。
25. 実行されたときに、
    仮想ワールド内の地形を定義する複数の手続的ルールを受信するステップを含み、
    前記複数の手続的ルールは、前記地形の単一の位置が、重複する複数の手続的ルールを有するように、階層に有機的に構成され、前記地形は、重複するルールを有する少なくとも１つの位置を有し、各階層は、境界、フィルタ及び影響因子を定義しており、更に、
    前記複数の手続的ルールに従って前記仮想ワールド内の仮想地形を生成するステップを含み、
    複数の手続的ルールが重複するとき、高度及び色を混合して、手続的ルールが重複したときの鮮明で視認できる不連続性を妨げるために、地形生成器は混合領域を特定し、境界影響計算を開始し、
    前記境界、フィルタ及び影響因子が論理的なテキスト形式で所望の属性を表す数値を割り当てられるように、前記複数の手続的ルールはテキスト表現され、
    前記地形は前記複数の手続的ルールから少なくとも１つのルールを追加又は削除することによって変更される方法を実施する命令を記憶したプログラム記憶装置。
26. 生成された前記仮想地形を表示するステップをさらに含む、請求項25に記載のプログラム記憶装置。
27. 前記境界の各境界は、前記手続的ルールが作用する領域を画定する、請求項25に記載のプログラム記憶装置。
28. 前記各境界は、円、矩形、および多角形の内の1つである、請求項27に記載のプログラム記憶装置。
29. 前記フィルタの各フィルタは、前記手続的ルールを適用する前に満足されるべき1つまたは複数の条件を定義する、請求項25に記載のプログラム記憶装置。
30. 前記各フィルタは、傾斜、高度、シェーダ、方向、およびフラクタルの内の1つである、請求項29に記載のプログラム記憶装置。
31. 前記影響因子の各影響因子は、高度、色、シェーダ、植物相、および放射状植物相の内の1つの地形特性に影響を及ぼす、請求項25に記載のプログラム記憶装置。
32. 仮想ワールド内の地形を生成する方法であって、
    前記仮想ワールド内の道路を定義する少なくとも1つの手続的ルールを受信するステップを備え、
    前記複数の手続的ルールは、前記道路の単一の位置が、重複する複数の手続的ルールを有するように、階層に有機的に構成され、前記道路は、重複するルールを有する少なくとも１つの位置を有し、各階層は、境界、フィルタ及び影響因子を定義しており、更に、
    前記手続的ルールに従って前記仮想ワールド内の前記道路を生成するステップを備え、
    複数の手続的ルールが重複するとき、高度及び色を混合して、手続的ルールが重複したときの鮮明で視認できる不連続性を妨げるために、地形生成器は混合領域を特定し、境界影響計算を開始し、
    前記境界、フィルタ及び影響因子が論理的なテキスト形式で所望の属性を表す数値を割り当てられるように、前記複数の手続的ルールはテキスト表現され、
    前記道路は前記複数の手続的ルールから少なくとも１つのルールを追加又は削除することによって変更される方法。
33. 前記手続的ルールは、前記道路が配置される前記仮想ワールド内の複数の点を定義する、請求項32に記載の方法。
34. 前記手続的ルールは、路肩の幅を定義する、請求項32に記載の方法。
35. 前記道路の路肩の高度は、前記仮想ワールド内の前記道路の高度と、前記道路に近接する前記仮想地形の高度とに基づいて判定される、請求項32に記載の方法。
36. 仮想ワールド内の地形を生成する方法であって、
    前記仮想ワールド内の河川を定義する複数の手続的ルールを受信するステップを備え、
    前記複数の手続的ルールは、前記河川の単一の位置が、重複する複数の手続的ルールを有するように、階層に有機的に構成され、前記地形は、重複するルールを有する少なくとも１つの位置を有し、各階層は、境界、フィルタ及び影響因子を定義しており、更に、
    前記複数の手続的ルールに従って前記仮想ワールド内の前記河川を生成するステップを備え、
    複数の手続的ルールが重複するとき、高度及び色を混合して、手続的ルールが重複したときの鮮明で視認できる不連続性を妨げるために、地形生成器は混合領域を特定し、境界影響計算を開始し、
    前記境界、フィルタ及び影響因子が論理的なテキスト形式で所望の属性を表す数値を割り当てられるように、前記複数の手続的ルールはテキスト表現され、
    前記河川は前記複数の手続的ルールから少なくとも１つのルールを追加又は削除することによって変更される方法。
37. 前記手続的ルールは、前記河川が配置される前記仮想ワールド内の複数のポイントを定義する、請求項36に記載の方法。
38. 仮想ワールド内の地形を生成する方法であって、
    前記仮想ワールド内の植物相を定義する複数の手続的ルールを受信するステップを備え、
    前記複数の手続的ルールは、前記植物相の単一の位置が、重複する複数の手続的ルールを有するように、階層に有機的に構成され、前記地形は、重複するルールを有する少なくとも１つの位置を有し、各階層は、境界、フィルタ及び影響因子を定義しており、更に、
    前記仮想ワールド内のアバターの周囲のユーザ定義領域を識別するステップと、
    予め定義された前記領域内に前記植物相を前記複数の手続的ルールに従って生成するステップとを備え、
    複数の手続的ルールが重複するとき、高度及び色を混合して、手続的ルールが重複したときの鮮明で視認できる不連続性を妨げるために、地形生成器は混合領域を特定し、境界影響計算を開始し、
    前記境界、フィルタ及び影響因子が論理的なテキスト形式で所望の属性を表す数値を割り当てられるように、前記複数の手続的ルールはテキスト表現され、
    前記植物相は前記複数の手続的ルールから少なくとも１つのルールを追加又は削除することによって変更される方法。
39. 植物相の密度を判定するステップと、
    前記ユーザ定義領域内の位置を植物相位置として識別するステップと、
    識別された前記位置に基づいて、前記アバターの移動中に新しい植物相位置を識別するステップと
    をさらに含む、請求項38に記載の方法。
40. 仮想ワールド内の地形を生成する方法であって、
    仮想ワールドで発生する活動を監視するステップと、
    アバターによって実施された前記活動を監視したことに応答して、前記仮想ワールド内の前記地形を定義する手続的ルールを生成するステップとを備え、
    前記複数の手続的ルールは、前記地形の単一の位置が、重複する複数の手続的ルールを有するように、階層に有機的に構成され、前記地形は、重複するルールを有する少なくとも１つの位置を有し、各階層は、境界、フィルタ及び影響因子を定義しており、更に、
    生成された前記手続的ルールに従って前記仮想ワールド内の地形を生成するステップを備え、
    複数の手続的ルールが重複するとき、高度及び色を混合して、手続的ルールが重複したときの鮮明で視認できる不連続性を妨げるために、地形生成器は混合領域を特定し、境界影響計算を開始し、
    前記境界、フィルタ及び影響因子が論理的なテキスト形式で所望の属性を表す数値を割り当てられるように、前記複数の手続的ルールはテキスト表現され、
    前記地形は前記複数の手続的ルールから少なくとも１つのルールを追加又は削除することによって変更される方法。
41. 監視される前記活動は、前記仮想ワールドにおけるプレーヤ以外のキャラクタの活動を含む、請求項40に記載の方法。
42. 仮想ワールド内の地形を生成するためのコンピュータ環境を含むコンピュータ読み取り可能な媒体であって、
    前記コンピュータ環境は、
    前記コンピュータ環境によって実行され、複数の手続的ルールを使用して地形を実時間で生成し表示するように構成された1つまたは複数のプログラムを備え、
    前記複数の手続的ルールは、前記地形の単一の位置が、重複する複数の手続的ルールを有するように、階層に有機的に構成され、前記地形は、重複するルールを有する少なくとも１つの位置を有し、各階層は、境界、フィルタ及び影響因子を定義しており、
    複数の手続的ルールが重複するとき、高度及び色を混合して、手続的ルールが重複したときの鮮明で視認できる不連続性を妨げるために、地形生成器は混合領域を特定し、境界影響計算を開始し、
    前記境界、フィルタ及び影響因子が論理的なテキスト形式で所望の属性を表す数値を割り当てられるように、前記複数の手続的ルールはテキスト表現され、
    前記地形は前記複数の手続的ルールから少なくとも１つのルールを追加又は削除することによって変更されるコンピュータ読み取り可能な媒体。
43. 前記境界の各境界は、前記手続的ルールが作用する領域を画定する、請求項42に記載のコンピュータ読み取り可能な媒体。
44. 前記各境界は、円、矩形、および多角形の内の1つである、請求項43に記載のコンピュータ読み取り可能な媒体。
45. 前記フィルタの各フィルタは、前記手続的ルールを適用する前に満足されるべき1つまたは複数の条件を定義する、請求項42に記載のコンピュータ読み取り可能な媒体。
46. 前記各フィルタは、傾斜、高度、シェーダ、方向、およびフラクタルの内の1つである、請求項45に記載のコンピュータ読み取り可能な媒体。
47. 前記影響因子の各影響因子は、高度、色、シェーダ、植物相、および放射状植物相の内の1つの地形特性に影響を及ぼす、請求項42に記載のコンピュータ読み取り可能な媒体。

Images