3.13.4 Functional surface
functional surface は、ライティングモデルのコンポーネントのために与えられた式に基いて、実行時(レンダリングプロセスの実行中に)に評価されるすべてのサーフェイスシェーダについて言及します。
それはVirtuaLight インタフェースによって提供される最も強力なタイプのサーフェイスです、なぜならそれは光線の前のサーフェイスの振る舞いを数学的に定義する事がユーザ次第であるからです。
このサーフェイスの主要な特徴は：
-その指令の各引数は、実行時変数や組込関数を使用する式でありえます。
-このサーフェイスは式に従ってシェーディングをする前に交点ポイントを修正することを可能にする指令を提供します。
-このサーフェイスは式に従ってサーフェイスの法線を逸らす事を可能にする指令を提供します。
-サーフェイスの実体色のために式に従って色の値のスペクトルを使用します。
-透明色と不透明のより柔軟性のある使用。
-このサーフェイスはテクスチャマッピングをマネッジする幾つかの関数を提供します。
それはそのようなサーフェイスの使用が、最小のプログラミングの経験とシェーディングとライティングの原理の良質な知識を要求することはかなり明瞭です、
しかし、そのケースの場合はとてもバラエティーに富んだ種々のそして良質な外観のサーフェイスを作成することが可能です
PlaneSurface(セクション3.13.2)からの全ての指令はFunctionalSurfaceと共に使用されます。
しかしPlainSurfaceとは異なり、それらはすべて引数として式を使用することが可能です。
例えば、外観の良質なグラスは、次のもので簡単に達成可能です。
Kt(0.975*|N . I|, 1.34, '1,1,1')
色のスペクトル(セクション3.13.3.1)はFunctionalSurfaceと共に非常に有用です。
また、２つの新しい指令は：
IntersectionPointModifier
NormalModifier
追加として、テクスチャマッピングのための16の特定の関数が設定を完了します。
3.13.4.1 Intersection point modifier
IntersectionPointModifier 指令はシェーディング(とマッピング)より前に式に従って交点ポイント(実行時変数 Po にオブジェクト座標でセットされている位置)の修正を可能にします。
そこには、とりわけ交点ポイントのためにsolidノイズを追加することでturbulence の効果を成し遂げるために、多くの興味深いものがあります。
シンタックスは：
IntersectionPointModifier point newip
この point は宣言された関数で返す事が可能です。
それは義務ではありませんが、turbulence のように幾つかの興味深い効果のために Po 変数を使用することは、しばしば推奨されます。
IntersectionPointModifier(Po + 2.0 * dnoise(Po, 4))
3.13.4.2 Normal modifier
NormalModifier 指令は式に従って法線(実行時変数 N 内位置する)を逸らすことを可能にします。
これはカスタムなバンプマッピング効果を作成する特定の関数によって、どのようにサーフェイスの法線が光に影響を与えるかについて良好なコントロールを与えることが出来ます。
シンタックスは：
NormalModifier vector normal
この vector も宣言された関数によって返される事が可能です。
それは義務ではありませんが、それは変数 N を使用することはしばしば推奨されます。
この様に：
NormalModifier(N[X]+0.2*(cos(7*x)+1)/2.0,
N[Y]+0.5*sin((cos(PI*y)+1)/2.0),
N[Z]+sin(10*x)*sin(10*z)/2.0)
3.13.4.3 A simple Color evaluation
Color 指令は式の関数に従って色のスペクトルを操作するために、PlainSurfaceあるいはPatternSurfaceよりもより適応可能な方法で使用可能です。
例えば、色のスペクトルを宣言してみましょう：
Declare SFX = SpectrumOfColors(
[0.000, e0.973, 0.973, 0.976i, 0.241, e0.973, 0.973, 0.976i]
[0.241, e0.973, 0.973, 0.976i, 0.284, e0.600, 0.741, 0.608i]
[0.284, e0.600, 0.741, 0.608i, 0.336, e0.820, 0.643, 0.537i]
[0.336, e0.820, 0.643, 0.537i, 0.474, e0.886, 0.780, 0.714i]
[0.474, e0.886, 0.780, 0.714i, 0.810, e0.996, 0.643, 0.537i]
[0.810, e0.996, 0.643, 0.537i, 0.836, e0.973, 0.973, 0.976i]
[0.836, e0.973, 0.973, 0.976i, 1.001, e0.973, 0.973, 0.976i])
次の関数は単純な回転を記述します。
static swirl = (fmod((Po + 6 * dnoise(Po)) . (1,1,1), 1))
この関数に従った色でSFXスペクトラムから色の評価するために、このシンタックスを使用しなければなりません：
Color SFX[swirl]
Color指令によって見つかったカレントの色は、ライティングモデルと給する実行時変数 color に格納されることに注意が必要です。
それで、それは他のどの式の関数内部でも再利用することが可能です。
そして、単純な例を完成するために、同じ関数はNormalModifier指令のために使用されることが可能です。
条件付き処理式で現在の結果の swirl を使用します。
NormalModifier(N + (swirl > 0.5 ? 2.0 * (dnoise(20*Po)n(0.5,0.5,0.5))
: (0,0,0)))
これは FunctionalSurface の多くの可能性のひとつです。
3.13.4.4 Functional opacity
セクション3.13.3.1で言われているように、サーフェイスで使用される、色のスペクトルで提出されたどのアルファ値も、伝達の構成要素を設定します。
もしそこに色と共に既に伝達ステートメントがあるなら、その色はサーフェイスを通り抜ける光をろ過するために使用されるでしょう。
もしそこに伝達ステートメントがないなら、伝達される色はスペクトルから出てきた色に設定されるでしょう。
実行時変数 Opacity は自動的なスケーリングファクタのように作用します、それは透明に基く拡散あるいは鏡面ライティングを調整するために有用であり得ます。
ただ Kd あるいは/そして Ks 要素に、この Opacity 値を掛け算しさえすればよいのです。
例：
Kd 0.75 * Opacity
Ks(0.3 * Opacity, e1,1,1i)
Kt とともに、不透明(opacity)マッピングは簡単にサポートされる事が可能です。
ここに 不透明マッピングのためのイメージファイルのアルファチャネルの使用方法を示す簡単な例があります。
Declare treemat = Shader [ FunctionalSurface [
Color PlanarImageMapping(ImageFile("Tree03.tga",NORMALIZED),(u, 0,
v),0)
Kd 0.9*Opacity
Ks(0.1*Opacity,'1,1,1')
Kt(1.0-Opacity,1,'1,1,1')
BlinnSpecularBRDF 2
]
]
イメージファイル Tree03.tga は 32ビットの targa ファイルです。Color は最初の8ビットチャネル(RGB)の3つを使用するでしょう、一方Opacityはアルファチャネルを使用します。
Kt が不透明マッピングで使用されるとき、それは一種の特定の光伝達を持つようであることを覚えておいてください。
従ってレイトレーシングレベルは、opacityと共にサーフェイスにぶつかった後自動的に増加させられます。(本当の屈折のように)
Functionalサーフェイスのいかなる瞬間においても、それは評価の後にColor指令によって何の色が見出されるかを知る事は可能です、なぜならそれはライティングモデル内でそれを共有するためにColor実行時変数に格納されているからです。
3.13.4.5 Texture mapping
テクスチャマッピングの一般的な定義は、
ディテールを追加するために2Dのビットマップイメージファイルを3Dシェイプの回りに投影して包み込む方法です。
VirtuaLight インタフェースはこの効果を達成するために５つのタイプの投影を提供します：UV-マッピング、平面(planar)マッピング、球状マッピング、円柱マッピング、そしてToroidalマッピングです。
-UV-マッピングはナチュラルなオブジェクトのU/V座標に基いてイメージをラップします。
- 平面マッピングは座標 0<= x <= 1、0 <= z <= 1の中にイメージをマップします。
- 球形マッピングは原点中心の任意のサイズの球をイメージでラッピングします。
y軸は球状マッピングの北極/南極です。
イメージのエッジの上端と下端はどんなスケールに関わらず極にぴったり触れます。
イメージの左エッジはx軸の正方向で開始され、ｙか回転の西から東へ球体をイメージでラッピングします。イメージは球体を正確に覆い隠します。
- 円柱マッピングは任意の半径と、y=0からy=1までのy軸に沿った1ユニットの高さの円柱をイメージでラッピングします。
円柱回りのイメージラップは、球形マッピングと同じ様になされます。
- Toroidal マッピングはメジャー半径のx-z平面基点の円環面の回りを
イメージでラッピングします。
イメージは、球体あるいは円柱マッピングと同じ様に周りにラップされます。
しかしマップの上端と下端のエッジは、torus の上と下の内部の縁の上にお互いに会合するところにラップされます。
合計16の組込関数は関数サーフェイスでテクスチャマッピングを作成する事を
可能にします。
テクスチャマッピングは３つのカテゴリーに分類されます：イメージマッピング(ファイルベース)、バンプマッピング、indexedマッピングです。
共通関数の全てのカテゴリは：
ImageFile(string filename, int interpolate)
ImageFile1 は任意のテクスチャマッピングで再利用するために、グラフィックイメージファイルから色値を収集してメモリに格納します。
filename は引数は単に問題のイメージ・ファイルを指摘します。
データは任意のTGA、JPG、TIF、BMPあるいはPNGフォーマットファイルから読むことが可能です。
レンダラは自動的に対応するフォーマット・タイプを認識するべきです。
２番目の引数は必要とされる色の補間法のタイプの設定を可能にします。
アーカイブファイル "statics.vib" 内には、各タイプの名称が静的に宣言されています。
NONE = 0
BILINEAR = 1
NORMALIZED = 2
タイプ1と2はイメージによりスムーズな外観を与えます。
どのImageFileの定義も名称で指定された幾つかのサーフェイスあるいは幾つかのシェーダを再利用するために宣言可能です。
例：
Declare the_moon = ImageFile("moon.tga", BILINEAR)
もしイメージファイルにアルファ値があるなら、opacity の量はサーフェイスの伝達構成要素のためにスケールのように使用されます。
この自動的な透明を無効にするために、Kt は0が設定されなければなりません。
3.13.4.5.1 Image mapping
オブジェクトのサーフェイス上にイメージファイルの色データを投影する手法について言及します。
多くの場合、 Color 指令でイメージマップを使用することを望みます。
u/v マッピング関数はちょうどイメージファイルの定義を必要とします。
UVImageMapping(ImageFile definition)
例：
Color UVImageMapping(the_moon)
or
Color UVImageMapping(ImageFile("moon.tga", BILINEAR))
全ての他の投影タイプはイメージファイルの定義と、しばしば実行時変数 Po により指定される座標を必要とします。
オプションである tile 値はサーフェイスを覆うイメージの繰返しオーダを指定する事が可能です。
PlanarImageMapping(ImageFile definition, point coord, int tile)
座標値として与えられた point 値は、x値に行数を掛ること、そしてz値に列数を掛けることにより色を選択するため使用します。
CylindricalImageMapping(ImageFile definition, point coord, int tile)
SphericalImageMapping(ImageFile definition, point coord, int tile)
ToroidalImageMapping(ImageFile definition, point coord, int tile)
これらの３つの関数のために、もし tile 値が与えられtらイメージはy軸に沿って tile 回数分だけ繰り返されるでしょう。
もし与えられないなら、イメージによって覆われないシェイプのどの部分もピクセル(0,0)の色を与えられるでしょう。
例：
Color SphericalImageMapping(the_moon, Po)
or
Color SphericalImageMapping(ImageFile("moon.tga", BILINEAR), Po)
3.13.4.5.2 Bump mapping
イメージマッピングとは異なり、バンプマッピングはイメージのそのポイントにおける現実の色の輝きに基いて、サーフェイスの法線を乱すためにデータに色を使用します。
結果は、もしイメージがサーフェイスに浮き彫りにされたらそのように見えます。
色は高さが計算される前に内部的にグレースケールに変換されます(黒は低いスポットで、白は高いスポット)、しかしイメージマッピングとバンプマッピングはカラーピクセルを調べるために同じ規則を尊重します。
一般にバンプマッピングは NormalModifier 指令を共に使用します。
次の関数で、バンサイズ値はバンプの見掛けの奥行きを設定します。
でフィルト値は 1.0 です、しかし負のバンプサイズ値も可能です、そしてバンプの違う投影方法になります。
より大きな値ははっきりとしたバンプになります。
u/v マッピング関数はイメージファイル定義とバンプサイズ値を必要とします。
UVBumpMapping(ImageFile definition, float size)
例：
NormalModifier UVBumpMapping(the_moon, 2.0)
or
NormalModifier UVBumpMapping(ImageFile("moon.tga", BILINEAR), 2.0)
全ての他の投影タイプはイメージファイル定義、座標(しばしば実行時変数 Po で指定された)、そしてバンプサイズ値を必要とします。
PlanarBumpMapping(ImageFile definition, point coord, float size)
Noe: u/v 座標にタイルを貼り付けるバンプマッピングのトリックは、平面のバンプマッピング関数で座標として、ポイント (u * i , 0
, v * j)を使用することです、そしてそれは i はu方向のタイルの数に等しく、そして j はv方向のタイルの数に等しくなります。
CylindricalBumpMapping(ImageFile definition, point coord, float size)
SphericalBumpMapping(ImageFile definition, point coord, float size)
ToroidalBumpMapping(ImageFile definition, point coord, float size)
3.13.4.5.3 Environment mapping
６つの異なるイメージファイルが環境(environment)マッピングを実行するのに必要です。
その技法は空間中のどのポイント回りにでも環境マップ(６つのイメージ)によるラッピングを可能にします。
この機能は EnvironmentMapping 指令でコントロールされます。
シンタックスは：
EnvironmentMapping (Maps("list of image files"), point coord)
or
EnvironmentMapping (Maps("list of image files"), point coord, int tile)
シンタックスは、ImageFile が Maps に置き換えられている事以外は、他のイメージマッピング関数に非常に近くなっています。
この関数 Maps は、次のように６つのイメージファイルを再編成して宣言する事が可能です。
Maps("file1", "file2", "file3", "file4", "file5", "file6")
それぞれのイメージが環境上の "立方体" の上に特定の位置を持っています。
この図式は展開された環境の立方体を表します。 (for a positive FrameAspectRatio)
各サイドの番号はリスト中のイメージファイルの番号に相当します。
VirtuaLight の仮想世界は、常にこの環境box内に含まれています。
環境マッピングは色の式を使用可能です。
それは Background、Skylight、そして FunctionalSurface あるいは AreaLight で要求される色の式に適合させる事が可能です。
完全なパノラマを表すイメージの使用は、Skylight 指令と共に大きな効果を達成することが可能でした。
例：
static environment = Maps("img1.tga", "img2.tga", "img3.tga", "img4.tga",
"img5.tga", "img6.tga")
Background EnvironmentMapping(environment, I)
3.13.4.6 Examples of functional surface
ここに異なる関数サーフェイスに基いたシェーダ定義の少数の単純なサンプルがあります。
黒と白のチェッカーサーフェイス：
static checker = |fmod(floor(x)+floor(y)+floor(z), 2)|
static checker_map = SpectrumOfColors(
[0.0, '0,0,0', 0.5 , '0,0,0']
[0.5, '1,1,1', 1.001, '1,1,1'])
Declare BWchecker = Shader [ FunctionalSurface [ Kd 0.9 Color checker_map[checker]
] ]
ワイアフレームのサーフェイスシェーダ：
static grid = 5
static thickness = 0.14
Declare wireframe = (|fmod(Po[X]*grid, 1)| < thickness ? TRUE :
(|fmod(Po[Y]*grid, 1)| < thickness ? TRUE : FALSE))
Declare WF = Shader [ FunctionalSurface [
Color '.96, .8, .69'*wireframe
Kd 0.85
Ks(0.25,'1,1,1'*wireframe)
Kt(1.0-wireframe, 1.0, '1,1,1')
Kr 0.1
BlinnSpecularBRDF 10 ] ]
ウッドサーフェイスシェーダ手続き：
static turb = 1.1
static wood_colors = SpectrumOfColors(
[0.000, '0.80, 0.67, 0.25', 0.222, '0.80, 0.67, 0.25']
[0.222, '0.80, 0.67, 0.25', 0.342, '0.60, 0.34, 0.04']
[0.342, '0.60, 0.34, 0.04', 0.393, '0.80, 0.67, 0.25']
[0.393, '0.80, 0.67, 0.25', 0.709, '0.80, 0.67, 0.25']
[0.709, '0.80, 0.67, 0.25', 0.821, '0.53, 0.29, 0.02']
[0.821, '0.53, 0.29, 0.02', 1.000, '0.80, 0.67, 0.25'])
Declare Woody = (sawtooth(2.0*sqrt(x*x+y*y)+turb*noise(Po, octaves))+1)/2.0
Declare mywood = Shader [ FunctionalSurface [
Color wood_colors[Woody]
IntersectionPointModifier(Po + 0.25 * dnoise(Po, 4))
Kd 0.75
Ks(0.4 + 0.5*pow(Woody,4), '1,1,1')
Kr 0.05
PhongSpecularBRDF 10*(1.0 - Woody) ]
Scale(0.5, 0.5, 0.5) ]
青く輝くシェーダ：
Declare glow = pow((1.0 - |N . I|), 0.15) + 0.5*scnoise(Po, 2)
Declare Glowing = Shader [ FunctionalSurface [
Color SpectrumOfColors([0, '0,0,1', 0, 1, '0,0,0', 1])[glow]
Ka 1 Kd 0
Kt(1.0, 1.0, '1,1,1')
]
]
3.13.5 Multi layer shader
可視レベルを定義するためにそれらの不透明値をお互いに使用し、その上に多数のシェーダのスタッキングを可能にする技法について記述します。
multi layer shader はそれは部分的に透明で、そしてより複雑なシェーダを作成するために他のうえに置かれた、幾つかのシェーダから成ります。
異なるシェーダレイヤは、幾つかのシェーダの組み合わせである、あるグローバルシェーダの外観を作成するために、透明な部分を通して見えます。
少なくとも２つのシェーダがmulti layer shader 形式で必要とされます。
リストされている最後のシェーダは最下位のレイヤになり、リストされている最初のものは最上位のレイヤになるでしょう。
最下位のレイヤ以外の全てのシェーダは、この効果を達成するために幾らかの透明性を持つべきです。
もしレイヤリスト中のひとつのシェーダが不透明である時は、それより下にあるものは可視ではないでしょう。
シンタックスは：
Shader [ MultiLayer [ list of shader names separated by a comma ] ]
Of course, any multi layer shader can be declared.
もしろん、どのようなマmulti layer shader でも宣言可能です。
例：
Declare final_wood=Shader [ MultiLayer [ tan_wood, drift_wood, oak, olddrywood
] ]
最終のスタックを作成するために、レンダラはリスト中に含まれる全てのシェーダを個々に評価しなければならない事に注意してください。
これは最終的なレンダリング時間に含められます。
3.13.6 Composite shader
おのおののシェーダの合成を評価した、最終的なシェーダを構築するために、異なるシェーダを一緒にした数の加重量の加算を可能にする技法について記述します。
すくなくとも２つのシェーダがcomposite shader形式に必要です。
シェーダの加重された量はリスト中の可視のパーセンテージ(存在)で定義されます。(e.g. 0.25 は 25％を意味します)
トータルの加重の量は1.0(100％)と等しくなければなりません。
シンタックスは：
Shader [Composite [(shader1,percent), (shader2,percent), O, (shaderN,percent)]]
もちろん、どんなcomposite shaderでも宣言可能です。
例：
Declare final_wood = Shader [Composite [
(tan_wood, 0.3),
(drift_wood, 0.2),
(oak, 0.4),
(olddrywood, 0.1)]]
最終の合成物を構築するために、レンダラはリスト中に含まれる全てのシェーダを個々に評価しなければならない事に注意してください。
これは最終的なレンダリング時間に含められます。
さらに同じシェーダリストを使用しても、multi layer shaderを構築するよりもcomposite shader を構築するのにはもっと多くの時間が掛かります。
3.13.7 Indexed shader
任意の3Dオブジェクトの回りに、2Dビットマップのシェーダパターンをラッピング可能にする技法について記述します。
そこにはindexed shaderのための２つの別個のコンポーネントがあります：シェーダのスペクトルとindex関数です。
それらは次の一般的なシンタックス中で使用されます。
Shader [ Indexed [ index_function , spectrum_of_shaders ] ]
そこにはindex関数の２つの典型的な使用法がさらにあります：
最初は正当な色ではなく完成したシェーダ間の選択と混合のためにsolidテクスチャ関数を使用します。
そして２番目はサーフェイス上にシェーダをマップする方法としてイメージマッピングを使用します。
3.13.7.1 Spectrum of shaders
イメージマップ(セクション3.13.4.5.1)のようにシェーイプにイメージのsolidの色を単に置く代わりに、シェーダはそのポイントのイメージのindexあるいは色に基いて指定します。
シェーダのリストは普通のカラーパレットよりもむしろ "シェーダパレット"のように使用されるために指定されます。
この "シェーダパレット" はSpectrumOfShadersとして知られています、なぜならそれはSpectrumOfColors よりも同じ手法に基いているが、しかしそれはシェーダに関係があるからです。
さらにそれは色のスペクトルのために同じような方法で宣言可能です。
シンタックスは：
SpectrumOfShaders( [int low_index0, low_shader0, int hi_index0, hi_shader0]
[int low_index1, low_shader1, int hi_index1, hi_shader1]
[ ... ]
[int low_indexN, low_shaderN, int hi_indexN, hi_shaderN]
)
基本的にindex関数がイメージマップ関数である時、ピクセルのインデックスはSpectrumOfShaders内で供給されるシェーダのリスト内のインデックスとして使用されます。
マッピングされていないファイルタイプ(16、24、あるいは32ビット/ピクセルのイメージ)のために、0から255の範囲の8ビットの赤の要素はインデックスのように使用されます。
もしピクセルのインデックスがシェーダのスペクトルで指定されたシェーダの番号よりも大きい場合は、インデックスは供給されたシェーダのリストの長さのどこを取るか(？？-
modulo L where L is )になります。
どのインデックス付けられたシェーダ内ででも再利用されるために、どのシェーダのスペクトルでも宣言可能です。
3.13.7.2 The Index function
インデックス関数は、それに続くシェーダのスペクトルから選択するためのまさにルックアップ関数です。
どの実行時変数の要素あるいは組込関数の返すfloat値(それは内部的に整数に変換されるでしょう)でもインデックス関数の役割をする事が可能です。
例えば：
x
or
scnoise(2.0*Po, 2)
or
次の５つのインデックスイメージマッピング関数のひとつ：
CylindricalIndexedMapping(ImageFile definition, point coord, int tile)
PlanarIndexedMapping(ImageFile definition, point coord, int tile)
SphericalIndexedMapping(ImageFile definition, point coord, int tile)
ToroidalIndexedMapping(ImageFile definition, point coord, int tile)
UVIndexedMapping(ImageFile definition)
インデックスイメージマッピング関数のシンタックスは、正確に標準的なイメージマッピング関数と同じであるから、全ての引数の意味についての説明はセクション3.13.4.5を参照してください。
それらの間で唯一異なるのは、第一に(インデックスイメージマッピング関数の場合)イメージの色のインデックスを返す事と、そして第２に色それ自身を返す事です。
どのようなインデックス関数も宣言可能です。
3.13.7.3 A simple example
ここにどのようにインデックスシェーダを記述すべきかを示す例があります：
Declare list = SpectrumOfShaders( ... )
Declare indexfunc = ...
Declare myIdxshader = Shader [ Indexed [ indexfunc, list ] ]
したがって、これは次のとおりでありえます:
Declare list = SpectrumOfShaders([-2, tan_wood, 25, drift_wood]
[25, drift_wood, 50, oak]
[50, oak, 75, olddrywood]
[75, olddrywood, 255, tan_wood])
Declare indexfunc = UVIndexedMapping(ImageFile("woodmap.png", NORMALIZE))
Declare myIdxshader = Shader [ Indexed [ indexfunc, list ] ]
もちろん、シェーダの各構成要素を宣言する必要はありません、しかしそれを読み込んで修正する事は容易です。
next