Render To VertexBuffer その4

ここのところこの話題が多いですが、結構気になってます。

さて、『Render To VertexBuffer』だと頂点テクスチャでの変位(displacement mapping)とことなり、シミュレーション適用後の変位した頂点データにアクセスが可能です。

これが頂点テクスチャの場合、結局はシェーダパイプライン内でのジオメトリ処理なんでCPUからのアクセスは不可能です。そうするとCPUからプログラムの途中で頂点配列に細工がしたい場合に不都合ですね（本当はCPUからアクセスし無いで済む仕組みが欲しい。でも、衝突判定やインタラクティブな入力にはCPUからアクセスの必要が…）。

じゃあそう考えると完全に『Render To VertexBuffer』の方が優位かと言うとそうではありません。頂点テクスチャを用いるディスプレースメントマッピングの場合、もともと頂点バッファがあってそれを変位させるので変位量(法線方向にしかディスプレースしないならスカラー型でいいわけだし)をテクスチャに書き込むだけでいいのですが、『、『Render To VertexBuffer』ではテクスチャ自体が頂点バッファとなるわけで同じテクスチャのディメンジョン(単純に解像度と言うか幅、高さ)なら確実に格納できるデータサイズが大きくなります(テクスチャにポジションや法線、頂点色やUV値を格納することを考えると)。さらにRADEONのようにテセレーション(動的なポリゴン分割。ATIやMatroxではNパッチ※を採用。余談だがNパッチの基礎論文はカナダのトロント大の修士学生の修論だったハズ、やばいなぁ･･･（汗。)が可能なハードウェアなら確実に頂点テクスチャでのディスプレースメントマッピングのほうが詳細な表示が可能です。

そう考えると手放しにはこれ自体がありがたいともいえません。しかし、用途で確実に使い分けをすべきかと思います。このあたりはGeforce 6の発売後に実証実験をすべきなのかも。

※Nパッチ…ポリゴンの各辺をベジェ曲線で描き、指定した分割数で線形(まぁ、通常の方法ですね)に近似して分割を行う手法だったハズ(あまり自信は無いが…)。学部の頃に卒業研究をやってたころにはプログレッシブメッシュのようにメッシュのエッジ削減は出来ても動的分割はあんまり出来ないんじゃないかと思ってた(もちろん当時でもROAMなんかの手法は知っていたけどね)。RADEON 9500以上だと大体8分割までいけるんだけど、経験上4以上はフレームレートが下がる。