|
1984年、Cook、Porter、Carpenterの３人がSIGGRAPHで発表した革新的論文、分散レイトレーシングは、ルーカスフィルム（PIXAR）という権威から誰もが疑うことなく、未だ真理として崇められ、修正されていない。私が発表したふたつの論文、スーパー・サンプリングにおけるアンチ・エリアシング法(1999年)と、ピクセルレス・サンプリング(2000年)は、この権威に真っ向からの対立軸を示したはじめての論文である。信奉されている方法では、レンダリング時間にもっともクリティカルな、サンプリング情報の３／４がゴミ箱にドラッグ・アンド・ドロップされ、有効に利用されていない。即ち、計算コストを１／４にできる簡単な手法が見過ごされたまま放置されているのだ。コンピュータ・グラフィックスにおける全ての（例外はない）教科書は、この間違った信奉の礎に構築されている。 |
|
根本的ボタンの掛け違いが、いかなる要因に端を発するかは推測の域でしかない。が、おそらくは、レイトレーシングというアルゴリズムの本質的特性に根っこがあるように思える。レイトレーシングでは、レンダリング手続きをピクセル単位で完全に独立（PIXEL 独立）させることができる。そのことが、Whittedが1980年に発表した当時の陳腐なハードウェア環境と見事に適合し、一大ムーブメントに結びついた。 － フレームメモリや実行メモリの容量が、スキャンラインやZバッファに比較して、きわめて少なくて構わない － 実際、RayCustomの最初の版は、640KBというMS-DOS環境で動作していた。 現在（遥か昔から）において、数MBのフレームメモリなど、メモリ容量全体（例えば512MB）からみれば誤差の範囲になっていた。にも、関わらず、PIXEL独立の処理という呪縛のために、本質的誤りが理解されぬまま放置されたのではないだろうか？ |
|
詳細は、論文にゆずるが、ここで、ピクセルレス・サンプリングの概観を言及しておこう、RayCustom.NETに実装されたマイクロポイントは、この概念の拡張として定義されている。 スーパー・サンプリングあるいは確率的サンプリングとフィルタリングのウソ 分散レイトレーシングでは、あるピクセルに対して複数のレイを飛ばすことで、レンダリング処理に纏わる数々のエリアシングを除去している。で、モーションブラー、被写界震度、といったエフェクト、２次レイ以降の分散などを無視すれば、１ピクセルあたり８本程度のレイを飛ばすことでピクセルの輝度値は、ほぼ収束することが経験則と知られている。 しかしこの結果が、サンプリング定理に大きく矛盾していることは全く指摘されることはなかった。音の世界では、鼓膜を通しての可聴域である20KHzまでの高音域を再生するサンプリング周波数は、40KHz以上あれば充分で、実際、CD(44.1KHz)もDAT（４８KHｚ）もサンプリング定理に基づいて、サンプリング周波数を決定している。 音が１次元なのに対し、画像データは、２次元なので、４倍のサンプリング周波数 － ピクセルを縦、横に２分割したサブピクセル化 － が、必要であるが・・・・ オーディオ・ファンの反論：「音だって８倍オーバ・サンプリングしてスタジオ録音されていますよ」が、聴こえてきそうだが、これは、ハードウェア - デジタル回路設計に伴う問題（音の折り返しノイズなど）、純粋無垢なソフトウェアであるコンピュータ・グラフィックスにおいては無縁な事柄である。 |
|
では、この矛盾はどうして起きたのか？ 複数のサンプリングレイは、ピクセル単位で処理される。つまり、ピクセル内のどの位置にレイが飛ばされたかによるフィルタリング処理が行われる。例えば、正規分布関数でフィルタリングすると、サンプリングレイが、ピクセル中央に近いほど、ピクセルの輝度値への寄与率は高く、周辺部ほど寄与率が低くなる。しかし、ほんの少しだけ頭を廻らせれば判るとおり、特に周辺部のサンプリングレイでは、隣接する３つのピクセルに対して、それなりの影響を及ぼしてしかるべきである。信奉された方法では、サンプリングレイが影響を及ぼすであろう４ピクセルのうち、３ピクセルへの影響は何ら処理されることなく捨てられていた。 一方、ピクセルレス・サンプリングでは、この点に着目し、フィルタリング処理をピクセル領域に対して行う代わりに、サンプリングレイに対して行う。その結果、隣接する４ピクセルに対する影響を計算することが可能になり、計算コストを１／４に削減することができる。論文での詳細な比較結果では、平均して、１ピクセルあたり０．５回のサンプリングレイでも、実用上有効なアンチ・エリアシング処理を実現できることを示している。 |
|
レンダリング技術の革新の歴史を、ざっくり振り返る。
驚くべきは、多くの教科書に掲載されているレンダリング史の中に、歴史上最も高い評価を獲得し、20年近く、今も変わらず圧倒的支持を獲得し、ハリウッド映画には欠かすことのできないはずのマイクロポリンゴンが見当たらない。異才をはなった特異なアルゴリズム故、なのか？成功者への嫉妬なのか？いずれにしろ多くのレンダリング・アルゴリズムが歴史とともに過去の遺産となるなか、マイクロポリゴンがシーラカンスであり続ける理由を探ることは意味深い。 |
||||||||||||||||||||||||||||||||||||||||||||||
|
public void RenderGeometry() { while
(h.RenderA.Count > 0) { CSpaceTransform st = (CSpaceTransform)RiClass.h.space[
R.RI_RASTER ] ; double xscale = st.m[0,0]; double yscale = st.m[1,1]; CRenderShader
rs = (CRenderShader)h.RenderA[0] ; h.RenderA.Remove(rs)
; if (rs.R_diceable(xscale,yscale)) { MicroGrid
microgrid = rs.dice(xscale,yscale) ; microgrid.CalculateNormal(); if (RiClass.h.transform.Displacementshader != null) { microgrid.Displacement(); microgrid.CalculateNormal(); } microgrid.Surface(); for(int i = 0 ; i
< microgrid.usize ; i++) for(int j = 0 ; j
< microgrid.vsize ; j++) { MicroPolygon mp ; if ((mp = microgrid.CreateMicroPolygon(i,j)) == null) continue ; mp.TransformToScreenSpace()
; mp.Rasterize()
; } microgrid.finish(); } else rs.R_split(h.RenderA)
; } } |
||||||||||||||||||||||||||||||||||||||||||||||
|
いきなり、ソースコードで、面を食らったかもしれない。が、Inside RayCustom.NETの副題が示す通り、可能なかぎり生きた情報を提供していきたい。何より、「ソースコードは、嘘をつかない」という格言がある。 マイクロポリゴン・アルゴリズムの根幹は、DicingとSplittingに集約される。Dicingは、レンダリング対象となるオブジェクトをマイクログリッド化（U,V座標に沿ったグリッド分割）する手続きで、オブジェクトが定義されている座標系（自然座標系）で行われる。Splittingは、いきなり、マイクログリッド化するには大きすぎるオブジェクトを、適当な大きさ（通常は、４分割）に再分割し、再定義する手続きである。 Dicingされたマイクログリッドは、ラスタライズの過程でマイクロポリゴン化される。マイクロポリゴンは、各ピクセル単位の確率的サンプリングから得られた値（RGBA,法線,UV座標など）、光源情報、視線情報などからピクセルの輝度値が計算される。 |
||||||||||||||||||||||||||||||||||||||||||||||
|
|
マイクロポリゴンが、シーラカンスなりえた理由は、実は、自然座標系でのマイクログリッド化にある。プリミティブが保有する情報を最小単位へ縮小する － 巨大データをレンダリング可能にする － 試みとして、最近では、ポイントベースド・レンダリングが盛況だが、ポイントベースでは、ワールド座標系で定義された点データは直接、スクリーン座標系に変換される。 |
|||||||||||||||||||||||||||||||||||||||||||||
|
一方、マイクロポリゴンでは、自然座標系→ワールド座標系→スクリーン座標系という一見、無駄と思えるプロセスを踏む。しかし、この無駄が、おそらく開発者自身すら見落としていたシーラカンス化の主犯である。自然座標系でのマイクログリッド化には、通常、オブジェクトのテクスチャ座標Ｕ，Ｖが利用される。その結果、例えば、球体のマイクログリッド化では、幸いにも（不幸にも）球体の両極にマイクログリッド（とどのつまりマイクロポリゴン）が集中するする結果となる。不幸な事例の代表は、MipMapなどによる善後策を講じない配慮のないテクスチャー・マッピングで極の両極に皺がよることである。幸いな方はこれから議論する。 |
||||||||||||||||||||||||||||||||||||||||||||||
|
ここで、球体の極の近傍について考える。 この球体が、サーフェスモデルで、テクスチャも特に貼られていないと仮定すれば、近傍での属性要素の変化は、以下の表のようになる。
一方、確率的サンプリングによって、新たなサンプリングを行うか否かの判定（しきい値）には、属性要素中、色の変化が参照されることが大半である。もちろん、面の曲率や面の構造を考慮したしきい値の判定方法も提案されてはいるが、判定コストが高すぎたり、汎用性を欠くなどの事情から、積極的に利用されるに至っていない。 球の例では、確率的サンプリングが有効に機能しないのは勿論だし、MipMapによるテクスチャのアンチ・エリアシングも万能薬とはなり得ない。結局、テクスチャ・データ作成時に両極をボカして作成するという現場仕事におんぶすることになる。 ところがこのマイクログリッド化の過程では、マッピング座標値Uの分散が、最大になることは周知の事実である。実際、ラスタライズの結果、両極のマクロポリゴン密度は、赤道付近より極端に増えることになる。そして幸いなことに、確率的サンプリング・アルゴリズムは有効に働かない（本来必要なサンプル数以下で収束する）にも関わらず、マイクロポリゴン・アルゴリズムは、その他のレンダリング・アルゴリズムより綺麗なレンダリング結果として反映される。 この結末は、神が与え賜れた偶然の産子に過ぎない。仮にマイクロポリゴン・アルゴリズムの提案者が、この事に気づいていたなら、マイクログリッド化によって得られた貴重な情報は、確率的サンプリング過程に反映した実装をしてしかるべきであるからだ。 マイクロポイント・アルゴリズムは、この見過ごされた死角に焦点をあてたサンプリングを行う。 |
||||||||||||||||||||||||||||||||||||||||||||||
