3.5 General
このカテゴリーは自主的な指令を再編成します。
プログラムの最も進歩したレンダリング機能の３つを有効にします。
それはモンテカルロ照射、フォトンマップそして関係メディアです。
3.5.1 Version
Version: float release
この指令はレンダリングの権限を与えるために入力ファイルの中で一度要求されます。
なぜならそれはすでにアーカイブファイル "statics.vib"中で指定されいて、VS入力ファイルの中でReadArchiveでこのファイルをincludeすることが推奨されているからです、絶対にそれを忘れる事は出来ません。
もし、何らかの理由で "statics.vib" をinclude しないなら、記述ファイルの先頭にVersion:1.２を指定する事は推奨されます。
バージョンは２つの用途を持っています：
1)どのリリースの入力ファイルを解析するかをレンダラに知らせます。
2)バージョンの互換性を異なったセッティングに切り替えます。
浮動小数点番号は１.０から１.３までであり得ます。
3.5.2 ReadArchive
ReadArchive string filename
この指令は名前を付けられたファイルを読むことを解析系に知らせます。
これは一種の"VIB-file 包含"メカニズムです。
このファイルのなかのそれぞれのコマンドあるいはリクエストは、それが読み込まれた所から解析されそして実行されるでしょう。
ネストもまた可能です(VIBのなかのVIBのなかのVIB etc.)。しかし、最大の深さは10です。
読み込まれるファイルのディレクトリ内の位置、環境変数VLIGHT_ROOTで指定されるルートフォルダの下にある、はレンダラによって知られていなければなりません。
環境変数VLIGHT_ROOT(この変数に関するさらなる情報についてはユーザマニュアル参照)で指定されるルートフォルダの下(あるいは同じレベルの)にあることを意味します。
e.g.
ReadArchive “statics.vib”
3.5.3 ReadMeshFile
ReadMeshFile string filename
VIB開発キットはこのファイルフォーマットを書き込むことを可能にします。
メッシュファイルは、三角形パッチのメッシュのシーン幾何学図形(オブジェクトのみ)のコンパクトなバイナリ記述を含むために使用されます。(少数の他の基本的なシェイプもまたメッシュ記述のなかに含めることが可能です)
全てのオブジェクトはこのファイル内で最初に定義されそして定義されなければなりません。
もし必要なら、それらもそれらから呼び出す(それらのシェーダと変形の修飾を含む)事が可能です、したがってASCII VIBファイル内からの他のコールは必要ではありません。
この指令はこのフォーマットを処理するために使用されます。
このフォーマットの記述の仕方を知るには、VIB開発キットのドキュメンテーションを参照してください。
e.g.
ReadMeshFile ibmw.mshi
3.5.4 Background
Background rgbexpr color [‘0,0,0’]
背景色（あるいはカラー式）を設定します。
背景色はカレントの光線が何のオブジェクトにも当たらなかった時に返す色です。
単純な色を指定する事は、同じ色が、背景を表している全てのピクセルに使用されることを意味します。
しかし式を指定する事は、背景のおのおののピクセルは、式を評価し得られた色を受け取ることを意味します。
これにより簡単に、イメージマッピングや、どのような手続きでもポイントの色機能を返すことが可能になります。
そして背景色に"ヒットする"とは光線が無限遠に行くことを意味するので、実行時変数はそのポイントに適合させなければなりません。
そのため、Backgroundコマンドのために、様々の実行時変数の意味はユニークに設定されます。
Name Type Description
I vector カレントの光線の方向(Direction of the current ray)
Level int カレントの反射レベル(Current level of recursion)
u float アウトプットイメージの向こう側にどのくらい(左0.0から右1.0まで)
v float アウトプットイメージの下方にどのくらい(下0.0から上1.0まで)
P vector (u, 0, v)と同等
他の関数変数は使用されていません。
次の例は背景にイメージを表示させる単純な方法です、しかし反射や屈折(代わりに白色 '1,1,1' が使われます)はありません。
e.g.
Background (Level == 0 ? UVImageMapping(ImageFile(“test.jpg”,1)) : ‘1,1,1’)
3.5.5 Fog
Fog (float distance, float coeff, rgb color)
シーンで全体的なFog(霧)を有効にします。
これは、カレントの光線がサーフェイスとぶつかる前に進んだ距離に基づき、すべてのピクセルに色を加えることによってシミュレートします。
最初の引数は開始する距離を設定し、他方第２は密度係数を表します。
0に近い値はFogを薄くまばらにし、そして1に近い値はFogを濃くします。
最後の引数は色を設定します。
e.g.
Fog(5, 0.1, '.95,.95,.975')
3.5.6 GroundFog
GroundFog (float distance, float height, rgb color)
濃さで霧を発達させるFogとは異なり、GroundFogはｙ軸上の0から始まる垂直方向の霧効果を発達させます。
最初の引数は距離を設定し、一方２番目は高さを表します。
この種類の霧では、密度はｙ軸の正方向に沿って指数関数的に消失します。
y=0において密度は100パーセントフルの値で、y=height(高さ)で37パーセント、y=4*heightで2パーセント、最終的にy=無限大で0パーセントになります。
正確にはground fogはカメラの上方向ベクトル(0,1,0)で機能するだけです。(詳細はセクション3.6参照)
その効果もまたはy軸の正の位置でのみ目に見えるだけです。
最後の引数は色を設定します。
3.5.7 ComputeIrradiance
ComputeIrradiance int pgs
Global illuminationは他のオブジェクトからの光の伝導を考慮したレンダリング技法です。
標準的なレイトレーシングはローカルのilluminationモデルと考えられます、なぜならそれは光源からシェードが始まるサーフェイスまでダイレクトパスのみでilluminationを確定するからです。
現実では、サーフェイスは間接的な、光源から直接来る光の代わりに別のサーフェイスから反射した光で、照らされることが可能です。
VirtuaLightインターフェイスはGlobal illuminationを計算するふたつのアルゴリズム(関連付ける事が出来る)を提供します：間接拡散照明のためのモンテカルロ照射、と間接鏡照明(caustics)のためのフォトンマッピングです。
ComputeIrradiance は間接拡散照明のためのglobal illuminationを有効にする指令です。
コマンドラインの -g オプションはこの指令をオーバライドします。
放射測定は、電磁気スペクトラムの任意の部分で光を測定する科学です。
放射測定で照射は、サーフェイス上の点の単位当たりに到達する放射束です。
この流れはサーフェイス上の任意の方向から達することができます。
逆に放射および(または)反射によりサーフェイスの上から任意の方角の中に去る流出は、放射発散と呼ばれます。
この照射アプローチは、レンダラにより間接拡散照明の計算に使用されるひとつの方法です。
そのレンダリング時、間接的な照明に関する情報が必要な場合、アルゴリズムはそのポイントの照射を評価するために余分なレイトレーシングの束を実行します。
見出された全ての照射の値は、処理中はメモリに格納されます、なぜならレンダラはすぐ近くのポイントがオーダされる時にあまりに多くの余分な計算をさけるために再利用しようと試みるからです。
整数の引数はプライマリのモンテカルロ照射の初期設定グリッドのサイズ(ピクセル単位)を表します。
それは2の倍数を指定することが推奨されます。
同じ様に、サイズは4かそれ以上そしてイメージの解像度の50パーセント以下でなければなりません。(e.g. もし解像度が640x480なら、サイズは320以下でなければならない)
小さすぎる値はより長い初期化処理の原因になりますが、より正確な初期値を照射データにキャッシュします、そしてそれは正しいglobal illmination
を得るために重要です。
そのため、8から32の値を使用することを推奨します。
e.g.
ComputeIrradiance 16
3.5.8 Photons
Photons (int count, float density, int media)
or
Photons (int count, float density, int media, int volume)
フォトンのマッピングは VirtuaLight インタフェースによって提供される２番目のglobal illumination アルゴリズムです、しかしこれは
caustics としても知られている間接的な鏡のようなライティングを計算するために使用されます。
単純化された定義を与えるため、caustics の、鏡面から他のサーフェイス上のフォーカスの反射あるいは屈折する光について言及します。
このアルゴリズムの原理は、光源からシーン中へフォトン(光子)を打ち出す事です。
これらのフォトンは、causticサーフェイス属性を持つオブジェクトの方に向けられます。
ひとつのフォトンがオブジェクトにヒットした後で貫通するかサーフェイスから跳ねるたびに、光線の交点がマップに格納されます。
このデータはあとで、反射と屈折のcausticsの光の貢献の量の評価に使われます。
Photonの指令は３つあるいは４つの引数で書かれることが可能です、しかし適切に働くために２つのうちの１つは最初に値0を持っていなければなりません。
これはそれらが両方とも生成するフォトンの数を設定するために使用されるからです、しかしそれは異なる方法です。
最初の引数はフォトンの、フォトンマップを構築するために打ち出される
平均の数を設定します。(２番目の引数は0でなければなりません)
開始のためのよい推測値は30000フォトンかもしれません。
この方法の結果によるフォトンの実際の数はこのカウントより常に大きいでしょう。
２番目の引数は、サーフェイス(最初の引数は0でなければなりません)上のフォトンのおよその密度を、0と1の間に含まれる10進の値で指定します。
より大きな値がより多くのフォトンを作成します。
実際に、値が２倍されるたびに(e.g. 0.1 が 0.2,にあるいは 0.2 が 0.4に)、アルゴリズムは４倍のフォトンを作成するでしょう、したがって0.6より大きな値はcausticのサーフェイスの数に依存して多くのメモリを必要とします。
もし３番目の引数が0より大きいなら、メディアフォトンが有効になります。
もし関係するメディアがMedia指令でセットアップされるなら、この機能は関係メディアとフォトンの相互作用、結果としてフォトンビームあるいは容積測定causticsを作成することを可能にします。
しかしながら、これは非常に計算集約的な処理です。
指定された値は、容積測定間隔(ふたつの散在したポイントを分けているスペース)を越えて集積されるフォトンの数を表します。
良い結果が値40から得られます。120を越える事は危機的に成り得ます。
メディアフォトンの最終番号は、同じく生成されたサーフェイスフォトンの数に依存するでしょう、なぜなら光線としてメディアのセクションを通過する、預けられた容積測定のフォトンの密度はおおよそサーフェイスのフォトンと同じだからです。
もし４番目の引数が使用されるならば、それにはcausticsの評価用に発射するためのサーフェイスボリューム(シェイプの境界に基づく)の最大パーセンテージを設定します。
通常レンダラは自身で、オブジェクトに向かってフォトンを発射し続ける事がもう必要ではないではない事、を決定します。そしてほとんどいつもそれはとても上手く働きます。
しかし時々、シーン中(特に中心が空の時)の複合のシェイプの数に依存して、それは間違ってあまりにも早くフォトンの発射を止めるてしまうかもしれない。
したがって、もしこの引数が使用されるなら、レンダラは発射する事をオブジェクト境界の指定されたパーセンテージに達するまで、決して止めないでしょう。(100パーセント完全にシェイプをカバー)
e.g.
Photons(0, 0.45, 52)
3.5.9 Media
Media (int sm, int sa, float de, float sc, float filt)
or
Media (int sm, int sa, float de, float sc, float filt, float aalias)
or
Media (int sm, int sa, float de, float sc, float filt, float aalias,
rgb col)
この指令は関係しているメディアを有効にします。それは5,6か7つの引数で記述する事が可能です。
この機能は、ボリュームサンプリングを使用する空中のパーティクルの、光の相互作用のモデル化で使用する事が可能です。
光のビームは眼に見えるようになるでしょう、そしてオブジェクトは空中を満たす煙や埃の中に影を投じるでしょう。
しかし、空中にはあらゆるところに固定のパーティクル密度があると想定します。
ボリュームサンプリングは、計算集約的な方法です、そのため関係メディアを使用するシーンはもう少し多くの時間を必要とします。
フォトンマッピングと関係メディアは完全に相互作用します、そのため両方の機能の組み合わせは、容積測定causticsを作成します。(大きなレンダリング時間を犠牲にして)
最初の引数は分散モデル(scattering model)で使用するタイプを指定します。
それは4です。"statics.vib"アーカイブファイル内ではそれぞれのモデル名は静的に宣言されています。
ISOTROPIC = 1
RAYLEIGHT = 2
MIE = 3
HENYEY = 4
ISOTROPICは分散の最も速い形式です、なぜなら大気中のパーティクルの光の拡散の量は、見ている方向と入ってくる光との角度には依存しないからです。
Rayleight は、空気の分子のように極端に小さなパーティクルのための拡散をモデル化します。
光が見ている方向と平行あるいは逆平行のとき、拡散する光の量が最も多くなり、そして見ている方向と垂直の時最も小さくなります。
Mieは霧や雲の極めて小さな水滴の小さなパーティクルのモデル化が可能です。
それはとても方向性のある拡散、光が見ている方向と平行のときそれは最小で見ている方向と逆平行のとき最大になる、を作成します。
Henyeyは異なる拡散タイプの多種多様のモデル化が可能です、なぜならそれは、与えられた離心率による楕円モデルの、分析的な機能に基いているからです。
この離心率はオプション構造体のHenyeyGreenstein指令で設定されます。
値0が与えられた場合はIsotropic拡散モデルと同じ結果になります。
正の値は光の方向の拡散で、負の値は光の方向の反対の拡散に導きます。
それはまた、より大きな正の値と小さすぎる負の値は拡散の方向の特性を増加させることを意味します。
２番目の引数はどれだけのサンプルが見ている光線に沿って１つの間隔の中で計算されるか決定します。
より大きな値はスムーズなボリュームを発達させますが、レンダリング速度は遅くなります。
開始への良い推測値は50であるかもしれません。
３番目の引数は空中のパーティクルの密度を設定します。
実際に、これは、もしその値が0より大きい場合は関係メディアを有効にします。
より大きな値は濃い大気になり、一方より小さい値は大気を薄くする原因になります。
10と20の間の値は興味深い結果になります。
４番目の引数は、大気によって拡散する光の量を決定します。
より小さな値は輝きを減少させ、より大きな値は輝きを増大させます。
これは絶対値ではありません。
その影響は使用されている拡散モデルのタイプに依存します。
しかし、大部分のケースで0.1から2.0の範囲で働きます。
もし５番目の引数が0より大きな値で使用されるなら、それはカラー減衰係数を決定します。
それは大気のグローバルな半透明をコントロールする一種のフィルタです。
それは常に0と1の間に含まれる値でなければなりません。
1に近い値は大気の不透明さを減じます。
もし６番目の引数が0より大きな値で使用されているなら、ローカル適応性アンチエイリアシングは、サンプリングのゆがみが見える程度を減らします。
それは拡散と、高輝度変化が起こる場所にサンプルを追加し色のにじみを改善します。
しかし、常にアンチエイリアシングはレンダリングの速度を遅くします。
この引数の値は細分化(ひとつの新しいサンプルが高輝度変化が起こるふたつのサンプルの間に配置される)が起こるレベルを設定します。
したがって、レベル1は１つのサンプルの追加を、レベル2は三つのサンプルの追加を、レベル3は五つのサンプルの追加 etc. を意味します。
もし６番目の引数が使用されているなら、それは大気の基本的な色を記述します。
それは光が通り過ぎるフィルターのパーティクルを得るのに使用可能です。
e.g.
Media(MIE, 55, 11, 0.25, 0.13, 1)