ステンシルシャドウボリューム技法の問題
ステンシルシャドウボリューム技法の弱点は、影の生成単位がポリゴン単位に限定されてしまうという点にある。
例えば、葉っぱのテクスチャを貼り付けた四角形のポリゴンがあったとする。見た目は「葉っぱ」だが、実際には、葉っぱの画の外周は透明色なだけで、実態は四角形ポリゴンのままだ。この葉っぱに影を生成してしまうと、この技法は頂点単位の影生成技法になるので、四角形ポリゴンの形状の影が出てしまう。
そして、この技法の実装における悩み所は、頂点を引き伸ばしてシャドウボリュームを生成する処理系だ。
ひと口に「影生成のために引き伸ばす」とはいっても、引き伸ばし元の頂点と引き伸ばし先の頂点を用意しておかなければ、影領域、シャドウボリュームが生成できない。しかも3Dキャラクタが動き回り、光源が動くような動的なシーンでは、その瞬間において、シーン中のどの頂点が影領域として引き伸ばされるか分からない。
そのため、この技法を採用するにあたっては、3Dモデルを構成する各頂点に対し、影生成専用の引き伸ばし用頂点(実際にはポリゴン)を仕込んでおくような工夫が必要であった。どの頂点がいつ引き伸ばされるか分からないので、3Dモデルの頂点全てに引き伸ばし用のポリゴンを仕込む必要がある。さらに引き伸ばされた/されなかった、に関係なく、頂点シェーダは仕込まれた全ての頂点について処理をすることになるので、必然的に頂点シェーダへの負荷が高くなってしまう。
3Dモデルのデザインの際も、あらかじめ影領域引き伸ばし用の頂点をポリゴン予算に入れておかなければならず、形状表現に用いられるポリゴン数は控えめにならざるを得なくなってしまっていた。前出の「DOOM3」の写真見ても分かるように2004年に登場したタイトルの割には妙に3Dモデルがカクカクしているのはこうした理由からだ。
グラフィックスエンジン側(CPU側)で、どの頂点が今回引き伸ばされるのかを判定して引き伸ばし用の頂点を仕込むようなアイディアを実装しているケースもあるが、その場合はCPUに高負荷がかかり、(CPU性能が十分でないと)こちらにボトルネックが発生しがちになる。
互換性が高く、アルゴリズムも比較的シンプルな技法だが、この引き伸ばし頂点をどう実装するかが厄介であったため、DirectX 9/SM3.0時代では、この技法は採用例が減る傾向に向かってしまう。
ところが、DirectX 10/SM4.0時代に突入した今では状況が変わりつつある。というのも動的に頂点を増減できるジオメトリシェーダが実装されたからだ。
ジオメトリシェーダを活用すれば、この技法のポイントとなる影領域の引き伸ばし用頂点を、「事前仕込み」で行わずともレンダリング時に臨機応変に生成できる。ジオメトリシェーダを活用することによって、この技法も再び脚光を浴びるようになるかもしれない。(続く)
(トライゼット西川善司)