DirectX9リアル対応3Dゲームが出てこない理由（その1）（2/3 ページ）

[トライゼット西川善司，ITmedia]

プログラマブルピクセルシェーダとはなにか?

　プログラマブルシェーダという概念が導入されたDirect X 8世代以降、3Dグラフィックスの世界はプログラマブルシェーダ時代に突入した。この概念の導入により、もはやテクスチャはポリゴンに貼り付ける画像だけを入れておくだけの存在ではなくなったのだ。

　例えば、テクスチャのR、G、B各データ領域に凹凸を構成する面の向きを表す法線ベクトルX、Y、Zのデータを格納できるようになった。これをとくに「法線マップ」という。

　この法線マップを最終レンダリング段階で画像として貼り付けるのではなく、法線ベクトルとして取り出し、プログラマブルピクセルシェーダにて、光源ベクトルと視線ベクトルに配慮してピクセル単位の陰影演算を行って描画してやる。

　これで、ポリゴンに凹凸を貼り付ける(貼り付けたかのように見える)「バンプマッピング」の出来上がりだ。あるいは、この法線ベクトルを使い環境マップを参照する形で陰影処理を行ってやれば、「環境バンプマッピング」が出来上がる。さらに、この法線ベクトルを正負逆にして、オブジェクトの向こう側の環境マップを参照するようにしてやれば、疑似屈折表現になる。

　このように、

「テクスチャにどんなベクトルデータを入れておくか」

「そのベクトルデータをプログラマブルピクセルシェーダでどう料理するか」

この二つがプログラマブルピクセルシェーダ活用形の基本スタイルであり、その工夫次第では、自然界で目にする様々な光学現象に近い視覚表現が再現出来るのである。

　その意味で、プログラマブルピクセルシェーダは、テクスチャとの合わせ技で威力を発揮する、といっていいかもしれない。

　プログラマブルピクセルシェーダ1.xを組み込んだDirect X 8は、プログラマブルピクセルシェーダ黎明期とも言うべき世代であり、こうしたベクトルデータの格納には一般的な画像テクスチャのフォーマットである「αRGB各8ビット幅」のごく普通の32ビットカラーテクスチャフォーマットなどを活用するしかなかった。すなわち、各種ベクトルの要素であるX、Y、Zデータは、8ビット整数(固定小数点実数)で表現するしかなかったのだ。

　もっとも、Direct X 8世代のプログラマブルピクセルシェーダ1.xの演算精度は固定小数点どまりだったので、演算能力とデータフォーマットのバランスは取れていたわけなのだが。

　さて、満を持して登場したDirect X 9ではプログラマブルピクセルシェーダに大きな革新が施された。それは「シェーダの演算精度を8ビット固定小数点の呪縛から解き放す」というアイデアだった。

プログラマブルピクセルシェーダを使ったバンプマッピングの概念図

プログラマブルピクセルシェーダ2.0のもたらした革新とは?

　ご存じの読者も多いと思うが、Direct X 9で採用されたプログラマブルピクセルシェーダ2.0ではピクセル陰影演算を固定小数点実数だけでなく、浮動小数点実数でも行えるようになっている。これにより、高精度、かつ複雑なビジュアル表現が可能となるはずだった。

　プログラマブルピクセルシェーダ2.0仕様で追加された浮動小数点実数のバリエーションは二つ。32ビット浮動小数点(FP32)と16ビット浮動小数点(FP16)だ。

　FP32のほうはIEEE 754準拠のもので、一方のFP16は国際規格ではないが、フル3DCGアニメ「トイストーリー」で有名なPIXARスタジオがリリースしている3D-CG制作システム「RENDERMAN」で活用されており、3D-CGの世界ではデファクトスタンダードとして認知されている。

　なお、RADEON 9500以上では、内部演算精度は24ビット浮動小数点だが、こちらでもフォーマットとしてサポートしているのはFP32とFP16の二つだ。FP24という表現はあくまでRADEON 9500以上の内部演算精度であって、Direct X 9が規定する浮動小数点実数フォーマットとして存在しない。よく混同している記述を見かけるので注意してほしい。

Direct X 9で新設されたテクスチャ形式・その1〜浮動小数点実数の値が格納出来るテクスチャ

　プログラマブルピクセルシェーダとテクスチャは切っても切り離せない深い間柄であることは、既に述べたとおりだ。

　そんなわけで、Direct X 9のDirect3D(以下、慣例に従いD3D9と呼ぶ)では、テクスチャフォーマットもプログラマブルピクセルシェーダの演算精度の浮動小数点実数化に伴って、「浮動小数点実数テクスチャ」がサポートされることになった。

　一口に浮動小数点実数テクスチャといっても、いくつかのバリエーションがあり、D3D9では以下のようなフォーマットが規定されている。

D3DFMT_R16F

D3DFMT_G16R16F

D3DFMT_A16B16G16R16F

D3DFMT_R32F

D3DFMT_G32R32F

D3DFMT_A32B32G32R32F

　末尾の“F”は「浮動小数点表現」の意味で、“A”“R”“G”“B”はαチャネル、赤、緑、青をそれぞれ何ビットで表現するか、を表している。例えば「D3DFMT_A16B16G16R16F」は、αRGBがそれぞれFP16表現で、1テクセルあたり合計64ビット(16ビット×4)の表現と言うことになる。

　「Rのみ」「GとRだけ」といった記述があるが、これらは、テクスチャに入れ込むベクトルが1次元ベクトル(Xのみ)や2次元ベクトル(X,Yだけ)の場合に利用するものだ。

　「D3D9で規定されているフォーマットなのだから、どのGPUでもサポートしているのでは?」多くの一般ユーザーはそう思うだろう。ところが、その対応するフォーマットがGPUごとにバラバラという現実があるのだ。

　今給黎隆氏制作のフリーソフトウェア「CheckDeviceFormatViewer」(http://www.t-pot.com/より入手可能)で調べてみると下の表のようになる。なお、いずれも2004年2月時点における最新ドライバによる調査だ。また、3Dゲームグラフィックスから縁遠いフォーマットについては表に含めていない。

	GeForceFX系	RADEON9500以上	DeltaChrome系	Volari系
D3DFMT_R16F	×	○	×	○
D3DFMT_G16R16F	×	○	○	○
D3DFMT_A16B16G16R16F	×	○	×	×
D3DFMT_R32F	×	○	○	○
D3DFMT_G32R32F	×	○	×	×
D3DFMT_A32B32G32R32F	×	○	×	×

　結果を見て驚いた人も多いだろう。

　もっとも汎用性の高そうなフォーマットである「D3DFMT_A16B16G16R16F」「D3DFMT_A32B32G32R32F」の二つはRADEON9500以上でしかサポートされていないというのがなんとも信じられない。

　そしてなにより一番、驚かされるのがNVIDIAのGeForce FXシリーズにおける対応状況だ。「Direct X 9」「プログラマブルシェーダ2.0“＋”」という触れ込みのGPUであるのにかかわらず、浮動小数点実数テクスチャがまったくサポートされていない。

　ソフトの開発サイドで、浮動小数点実数テクスチャを活用してプログラマブルピクセルシェーダ2.0ならではのユニークなシェーダを思いついたとしても、ユーザーが多く、影響力の強いGeForce FX系で動作できないとあっては、おいそれと3Dゲームのエンジンに組み込むことは出来ない。NVIDIAは、この問題について「ドライバで対応可能な問題として認識している」と1年以上説明し続けているが、改善されそうな兆しが見えない。