プロシージャルデータ


概要

Terragenはプロシージャル(手続き型)データを広く利用しています。「プロシージャル」とは、データが数式またはアルゴリズムを使用して必要に応じて生成される事を意味します。簡単に言えば、データが手順に沿って生成されます。

プロシージャルで生成されるもので最も有名な例は、おそらくフラクタルです。フラクタルの形状は、計算に基づいて生成されます。さまざまな種類のフラクタルが異なる数式を使用して生成されます。フラクタルビューアを使う事があれば、フラクタルをほぼ無限に拡大する事が出来る事に気付きます。これは、フラクタルが計算上で生成され、拡大するたびにフラクタルの新しいビューが計算されるためです。ディテールの量は多かれ少なかれ無制限です。

プロシージャルデータの重要な概念は、「データの増幅」です。少しのデータを使って大量のデータを生成する事が出来るという考え方です。これは、TGプロジェクトファイルのサイズが非常に小さい理由の大きな部分です。視覚的に複雑なシーンに必要な大量のデータを生成するために、ほんの僅かなデータだけをファイルに格納するだけで済むのです。

もう一つの重要な概念は、データを生成するために使用される手続きが「決定論」である事です。つまり、同じ初期値を使用すると、同じ結果が得られます。これが、プロシージャルデータを使用して保存されたプロジェクトを読込む事ができ、シーンを作成した時と同じように見える理由です。

プロシージャルデータの「反意語」は、静的データと呼ばれるものです。静的データはあらかじめ計算され、使用する際に完全に生成されています。TGによって使用される静的データの例としては、ポリゴンオブジェクト(通常はインポートによって)、ハイトフィールド、マスクやテクスチャとして使用される画像ファイルなどがあります。

事例: プロシージャル vs 静的データ = フラクタル地形 vs ハイトフィールド

プロシージャル地形とハイトフィールド型地形の違いを見てみましょう。プロシージャル地形の代表例は、『Power Fractal』または『Alpine Fractal』の地形です。どちらもフラクタルに基づいています。 【Terrain】のノードリスト上にある[Add Terrain]ボタンを使用して、これらの地形の1つを作成する事が出来ます。

デフォルトのTGプロジェクトは、すぐに生成可能なハイトフィールドが設定されています。ハイトフィールドを生成するだけでなく、TGはさまざまな種類のファイルからハイトフィールド地形データを読み込む事も出来ます。

プロシージャル地形とハイトフィールドの1つ目の大きな違いは、それら地形がカバーするエリアの大きさです。プロシージャル地形は理論的には無限です。TGでプロシージャル地形を作成すると、それは惑星全体をカバーします。それとは対照に、ハイトフィールドのデフォルトサイズは正方形で、両辺10kmに設定されています。勿論、大きなハイトフィールドを作成する事は出来ます。実際、惑星全体をカバーするハイトフィールドを作成する事も出来ます。当wikiでも紹介しているリアルな惑星はその一例です。しかし、それは多くのデータを必要としますが、これは後で見ていく事にします。

プロシージャル地形

ハイトフィールド型地形
2つ目の大きな違いは、解像度やディティールです。繰り返しますが、プロシージャル地形のディティール量は理論的に無限です。ディティールにはいくつかの事実上の制限があります。しかし、プロシージャル地形に近接するまでズームインしても、細かいディテールを見る事が出来るという事実に変わりはありません。対照のハイトフィールドは通常、非常に粗い固定された解像度を有しています。測高値は固定グリッドになっています。このグリッドの共通のサイズは10mです。それは基本的に、10m以下の距離を目視した時に、地形にディティールがない事を意味しています。プロシージャル地形には、ミリメートル未満レベルまでディティールを有しているかもしれません。

プロシージャル地形は、よりずっと効率的に保存する事が出来ます。地形の形状は、地形の特性のいくつかを定義する数式と数値の組み合わせに基づいています。プロシージャル地形でプロジェクトまたはクリップを保存すると、その値はファイル内の容量をほとんど占有しません。対照のハイトフィールドはより多くの容量を占有します。惑星全体を覆うプロシージャル地形は、1キロバイト未満の容量も占有する事はないでしょう。リアルな惑星のような惑星全体をカバーするハイトフィールド(標高マップ画像)は、ギガバイトまで稼働する事が出来ますが、それはハイトフィールド画像の解像度に正確であるだけです。非科学的用語では、ハイトフィールドは通常数十億倍のデータで構成されています。

もうひとつの重要な違いは、ハイトフィールドはオーバーハングのような突き出た地形や、洞窟を有する事が出来ません。特にオーバーハングは自然の地形でよく見られ、不自然な地形でも非常に望ましい事があります。これらの種類の特色はTGのプロシージャル地形では問題ありません。もっとも洞窟の作成に関してはTGの中でも難しい部類に入りますが、これは機能の制限と言うよりツールの工夫次第で可能です。

オーバーハング

洞窟

もちろん、実際の地形や架空の世界の特殊な型状に地形に興味がある時は、ハイトフィールドの方がこの作業には適しています。例えば、完全なプロシージャルデータを使用して実際の風毛であるセントヘレンズ山などを再現する事は非常に困難です。実際の場所のDEMを使う方がはるかに簡単です。同様に、具体的な風景画を作り上げた後の場合は、ハイトフィールドエディタやイメージエディタを使用してハイトフィールドとして作成する方が簡単かもしれません。

TGによるプロシージャルのより多くの例

TGのプロシージャルデータの実例のいくつかを下記に挙げます:
  • シェーダ: 多くのシェーダは手続き型です。1つの例として『Simple Shape Shader』があります。これは画像マップでも可能な基本的な図形を作成しますが、手続き型の生成を使用すると、縁がぼやけたりアンチエイリアスが掛かる事無く図形を拡大/縮小したり回転させる事が出来ます。
  • ポピュレータ: ポピュレータは、手続き的にインスタンスの位置を生成します。ポピュレータがポピュレートされている時、実際には各インスタンスの位置を生成するアルゴリズムを使用しています。手続き型のポピュレータによってほんの僅かな数を格納するだけで済むので、プロジェクトファイルに数百万のインスタンスの位置を格納する大量のディスクスペースを必要としません。
  • サーフェスレイヤー: サーフェスレイヤーは、サーフェス効果を作成するためにフラクタルや他の種類のプロシージャルシェーダを使用します。画像マップは効果的に使う事が出来ますが、ズームにより遠すぎたり、接近し過ぎると、物がぼやけて見える事があります。遠く離れていると、画像マップが明らかにタイルが貼られた状態に見える可能性があります。プロシージャルデータはこれらの問題を回避します。
  • オブジェクト: 特定のビルトインオブジェクトには、例えば『Sphere』などの手続き型のオブジェクトがあります。これらは、個々のポリゴンで構成されているのではなく、数式によって生成されます。『Grass Clump』や『Rock』のようなオブジェクトは多角形オブジェクトとしてレンダリングされますが、手続き型アルゴリズムを使用して生成されます。オブジェクトを構成するポリゴンはファイルに格納されないためディスク容量を占有しません。
  • Functionノード・ネットワーク: Functionノード・ネットワークとある程度の他の部分のノードネットワークは、それらの結果を生成させるレンダリング時間が評価に値します。これは、TG内でプログラム自身で作成出来る手続き型データ生成の例です。
  • アニメーションカーブ: 一見分かりにくいであろうプロシージャルの1つの有用法として、アニメーションカーブがあります。アニメーションカーブは、キーフレーム間で補間します。これは、キーフレーム間のフレームの値が数学的に計算される事を意味します。複雑な曲線全体を、ほんの少しのキーフレームの使用で格納する事が出来ます。

静的データを使う理由

プロシージャルデータが非常に大きい場合、なぜ静的データを使用するのか? 多くの場合において、静的データは必要な存在です。上記のハイトフィールドの議論はその一例です。別の分かりやすい例は多角形の3Dモデルです。もちろん多くの場合、画像はテクスチャを貼り付ける時やマスキングに必要なものです。静的データとプロシージャルデータの組み合わせは、度々望む結果を達成する最良の方法となります。

プロシージャルデータを使用して静的データを改善する事が可能です。これの良い例は、フラクタルを使ってハイトフィールドに余剰のディティールを追加する事です。TGはデフォルトで『Heightfield Shader』ノードでこれを行います。シェーダは、基礎となるハイトフィールドの制限された解像度を補うのに役立つ小さなスケールのフラクタルディテールを付け加える事が出来ます。もちろん、この余剰ディティールは"偽物"ですが、ほとんどのシーンにおいては実用に差し支えがありません。フラクタルディテールが追加された場合と、されていない場合のハイトフィールドのサンプルを下記に示します:

フラクタルディティール追加

フラクタルディティール無し

余剰のディティールによってまったく異なる画像の違いに気づく事でしょう。ディティールの追加は、小さな外観に限定されません。ハイトフィールドにも手続き型の大きな外観を簡単に作成する事が出来ます。

プロシージャルデータの強みの1つは弱点でもあります。プロシージャルデータを生成する事は、計算集約的である可能性もあります。プロシージャルデータよりも静的データを使用する方が効率的な場合もあります。 これの一例として、多くの手続き要素からなるマスクがあるとします。計算が遅く、解像度があまり問題にならない場合は、マスクを画像エディタで描画し、その静止画像をマスクとして使用する方がよい場合があります。同様に手続き型の地形は計算が遅くなる可能性があります。地形をハイトフィールドとして保存する事には利点があるかもしれませんが、もちろん、オーバーハングの欠如などハイトフィールドの制限を考慮する必要があります。このような種類の状況では、計算時間とデータサイズ間に妥協点を見いだす必要ががあります。画像はマスクとして機能し、計算が高速になりますが、レンダリング中にディスクやメモリに多くの容量が必要になります。

プロシージャルデータのもう一つの潜在的な弱点は、それがアルゴリズムに基づいているという事実です。インポートとエクスポートとなると、これは難問かもしれません。これの代表例は手続き型のシェーダです。多くのレンダリングアプリケーションでは手続き型シェーダがサポートされていますが、アプリケーション間でシェーダをインポート/エクスポートする事はあまり一般的ではありません。これは、各アプリケーションが他のアプリケーションの正確なシェーディングアルゴリズムを識別していないからです。そのため、アプリケーション間で同じ結果を再現する事が出来ません。『 Corona Renderer 』と『 Maxwell Render 』が違うのと同様に。

もう1つの例は地形です。TGは地形のエクスポートに対応していますが、静的データに制限されています。地形をハイトフィールドとしてエクスポートするか、または『Micro Exporter』を使用して、レンダリングされた地形をポリゴンメッシュとしてエクスポートする事が出来ます。別のアプリケーションでは、TGが地形を生成するために使用するアルゴリズムを識別していないため、TGからのプロシージャル地形を再生成する事は出来ません。


アルゴリズムが一般的に知られている場合(プロシージャル地形= フラクタル地形 )でも、依然として扱いにくい事があります。これの最も良い例はアニメーションカーブです。多くのアプリケーションでは、同じ種類の曲線をアニメーションに使用します。しかし、正確なアルゴリズムを識別していない限り、曲線を正確に再現する事は困難です。TGからのカメラの動きを別のアプリケーションでカメラの動きを一致させようとすると、問題を生じる可能性があります。曲線は大体同じ形状であるかもしれませんが、小さな違いは結果としてジッタ(画面の乱れ)や振れを引き起こす可能性があります。このため、アニメーションカーブはインポート/エクスポート時にベイク処理する事をお勧めします。ベイク処理は、キーフレームをすべてのフレームに固定配置する工程を言います。これによりプロシージャル曲線が事実上静的な曲線に変わり、計算結果をアニメーションカーブに固定する事で、他アニメーションソフトに移行した際にカメラの変動を無くす事が出来ます。