さてこのジョン・カーマックのコメント，いつものことながら，かなり専門的な用語バリバリの独り言ではあるが，その中でARB2エクステンション（拡張）機能をサポートしたOpenGL 2.0だけを使ってプログラムすることを表明。つまり，DOOMIIIでフィーチャーされるグラフィックス機能を楽しむには，NV30もしくはR300以上のグラフィックカードが必要だと言明したわけだ。もちろん，OpenGL APIをサポートしたNV10系のグラフィックカードでも遊べないことはないが，id Software社とカーマック氏のグラフィック知識が詰まった最新作だけに，最高の状態のゲームマシンでプレイしたくなるのもファンの欲望のうちだろう。

※カーマックは，途中，ATIやNVIDIAというメーカー名をそれぞれR300，NV30と同義に使っている箇所が見られるので，その点は意味を組んで加筆してある

　新DOOMの画面描写に関していえば，現段階ではNV30のほうが少し速いようだけど，R300が上を行く場合が時々ある。グラフィックカードがどうやって画像を処理しようとしているのがが違うので，この問題は複雑なんだよね。

　R300は，DOOMを三つの異なるモードで描写する。ARB（最低限の拡張命令の使用，スペキュラ・ハイライティング機能オフ，頂点シェーダプログラム無効），R200（全オプション有効，ほぼシングルパスでのリアルタイム・レンダリング），そしてARB2（浮動小数点フラグメント・シェーダー，ある程度の画質向上，シングルパス）の3種類だ。

※"ARB"とはOpenGLアーキテクチャ・レビュー・ボードの略で，簡単にいえばOpenGL規格化機構みたいなもの

　一方NV30のほうには5種類のモードがあって，ARB，NV10（全オプション有効，五段のレンダリング・パス，頂点シェーダプログラム無効），NV20（全オプション有効，二段か三段のレンダリングパス，NV30（全オプション有効，シングルパス），そしてARB2となる。

※R300＝RADEON9700，NV30＝GeForceFX

　R200パスは，R300のARBパスよりも少しだけスピードが速いのだけど，それは"ほんの少し"でしかないから画質性能を考慮してARB2のパスをデフォルトで使っている。それに比べてNV30のARB2パスは，NV30パスよりもずっと遅い。現時点でのテストでは半分くらいかな。ハードウェアを比較するときには同じAPIを使うと正確な数値を引き出せるので，これは残念な結果だ。R300のほうが2倍速く思えるけど，NVIDIAが規定したNV30パスを使えば，NV30が勝利する。

　その理由は，ATI R300パスは，常に最高精度の出力を行うのに比べ，NVIDIA NV30パスは3段階の精度をその時のパフォーマンスに応じて出してくる，ということにある。話をさらに複雑にしているのは，ATI R300パスが出力する精度は，元々NVIDIAが提出した複数の浮動点精度の中間的なものであるということ。だから，NVIDIA NV30でフラグメント・プログラム（注：シェーダ・プログラム）を動かすと，もともと妥協しているATI R300よりも遅いものの，高精度になる。NVIDIAがいうには，まだまだドライバコンパイラ技術のバージョンアップでフラグメント・プログラムのパフォーマンスを改善する余地はたくさんある，とのこと。
　現在のNV30にも問題はある。（通風孔用に）二つのスロットを割り当てなければいけないってことと，クーリングファンが作動し始めたときには非常にうるさくなるってことだ。僕は音には無頓着なほうだけど，NV30は耳障りなほどの騒音なのだ。

　現在，僕の開発メインマシンにはNV30を入れている。だからほとんどのレンダリングパスのテストはこのマシンでできるようになっている。なぜって，NVIDIAには，今後ドライバの更新でまだまだ性能を向上させていけるという期待もあるからね （ATIもドライバサポートを向上させてはいる）。エンドユーザーにとっては，まだどちらの製品がお勧めかってのは判断できない状況だと思う。
　開発者にとっては，どちらかを使用するには異なるトレードオフがあって，NV30はフラグメントプログラムの処理は遅いが，膨大なステップ数の命令が使えるという利点がある（注：R300は1024ステップ，NV30は65536ステップ）。（しばらく使っていた）R300では，僕の場合すでにプログラムの性能の極限を見てしまったような気がするんだ。いつものことだけど，より良いカードがどんどん出てくるしね。

　新DOOMでは，ベンダー固有の頂点シェーダプログラム（NV_vertex_programとEXT_vertex_prgram）はサポートしないことを決定した。すべてのレンダリングパスは，ARB_vetex_programを使用することになる。ATIもNVIDIAもARBのサポートを表明したので，これは僕にとっては嬉しいことだ。 ARB_vertex_programの規格化は大変だったけど，最終的にはベンダー固有の拡張仕様よりも断然よいものになった。
　実際のところ，幅広いドライバ互換性を考慮して古いAPIをサポートすべきだとも考えていたのだけど，より進化したモードでのプレイを楽しめるように最新のドライバのサポートが必須になる。古いドライバでも，ARBパスやNV1パスを実行できるのでプレイできないことはないしね。
　新しいARB_vertex_buffer_object拡張は，おそらくNV_vertex_array_rangeやATI_vertex_array_objectと同じように使えるはずだ。

　OpenGLやDirect XにおけるAPIの進化に関しては，肯定的にも否定的にも論議することができる。ベンダーが供給する独自拡張は，新しい機能を迅速に使えるようにしてくれるけど，その効果がベンダーごとにバラバラで標準的なものに落ち着くまで時間がかかることがある。中央で明確な規格ができれば，ハードウェアとソフトウェアのリリース時期に誤差があっても歩調を合わせることができるし，非常にまずい採択が業界全体に悪影響を及ぼすことはあっても，ある程度強制的な規格化は開発者を助けることもあるし。
　何年にも渡ってDirect X嫌いを自負する自分がWindows Graphics Summitに行っていた理由はここにあるわけだけど。でも，いまだにOpenGLでしかゲームを作ってないけどね。

　新世代グラフィックカードの中で一番素晴らしい機能が，ARB_fragment_programをサポートしたことによる非常にフレキシブルなフラグメントプログラミングの達成だろう。"スイッチとダイアル"というようなスタイルの画一的なグラフィック機能から，高精度でフレキシブルなプログラミングへの移行は，グラフィックエンジン開発を次なるステップへと進ませてくれるに違いない。

　新しい機能の可能性をグラフィックスエンジンに完全に搭載するのには，プログラムに慣れるのに時間がかかり，過去のドライバとは互換性がなくなってしまうというマイナス点もある。しかしARB_vetex_programを触っているのは楽しいし，遊んでいるうちにARB2パスのコードベースを改良することもできた。
　非常にダイナミックなカラーレンジ(監修者注:色深度。RGB各色が32ビット浮動小数点で表されるフレームバッファにおける表現範囲を言っていると思われる)はポストブレンディング処理ではなく，エンジン内部で処理されるようにした。グラフィックを見ていて感じるようなものではないけど，より高品位な描画を実現できるようになった。

　頂点単位ではなく，ピクセル単位での環境マッピング。これは，これまで僕が感じていた不満を解消してくれる。これまで，大きな窓ガラス上で表現する環境マッピングは十分にテッセレートされていなくて，プレイヤーが通り過ぎるたびに奇妙なワープがあったんだ。
　光源ベクトルと視線ベクトルが，キューブマップではなくリアルタイム演算で正規化できるようになった。これは，今後登場してくるグラフィックカードを考慮したもので，帯域幅の減少による大きなパフォーマンスの向上が期待できる。ただ，現行のハードウェアでは演算量と帯域幅のバランスの制約に阻まれて，この仕様は何の意味も持っていない。この仕様で将来期待できるのは（浮動小数演算性能に依存するが），スペキュラ・ハイライトとかが，これまでのようにピクセルの固まりのようなっぽいものではなくなり，非常に自然なものになることだ。

　このほかにもいろいろと遊んでいることがあって，エンジンにも残るだろうけどサポートはされないフィーチャーもある。

　（視線ベクトルと光源ベクトルの半分で表される）ハーフアングルベクトルの差し替えではない，スペキュラー用のピクセル単位での反射ベクトルの計算。ジオメトリに依存した視覚効果として残された課題としては，スペキュラー・ハイライトの形状が挙げられる。
　理想的には，（ある大きさのサーフェイスが）二つの大きなポリゴンで表されようが，1024分割されたポリゴンで表されようが，最終的には同質のイメージを作り出したい。しかし，線形演算処理された（注：線形補間された？）頂点を計算に用いてしまうと，これは実現されない。
　スペキュラのハーフアングルベクトル計算には，正規化が関わってくる。だから，サーフェイス上のトライアングルの書き換えは，頂点の位置に依存してしまうんだ。

　この仕様の最終的な視覚的効果とは，テカテカとした大きな平面上で，丸いクリアなハイトライト反射光るとなって現れる。そしてそのハイライトはポリゴン分割されたエッジ付近に行くに従ってL字形に歪んでくれる。

　この機能をインプリメントする際に使用した追加命令によって，パフォーマンスに大きな違いが出てくるということに気付いた。ハイライトが，安定した形になっているだけでなく，ハイライトが実に鋭利なものになり，シーンを期待以上のものにしてくれるのに驚かされたよ。
　現状ではゲーマー向きの効果とはいえないが，将来の高品位レンダリングにおいては重要なものとなるに違いない。

　サーフェース上の法線マップの再正規化は，拡大したテクスチャ（注：法線マップが格納されたテクスチャのこと）を取り扱ったときのクオリティ向上に貢献する。たとえば見た目がはっきりしたものになるし，エッジのブラーもきらびやかになるし，バンプの窪みも滑らかになる。ただし，これは縮小したテクスチャに適用するととてつもない量のエリアシングを引き起こす。
　それぞれの段階をフラグメント・プログラムでブレンディングしてやることもできるが，これはオーバーヘッドが大きくてパフォーマンスに影響が出てしまう。また，これはMIPマップレベルと連動して変化するなんらかの付加情報を法線マップのアルファチャンネルに格納しておく必要も出てくる。
　スペキュラライティング（鏡面光源処理）された法線マップテクスチャの最良のフィルタリング手法は，微妙な問題点を含んだ興味深い命題だ。

※監修者注
DirectX 9で規定される浮動小数点実数テクスチャには，αブレンディングとMIPマップ，フィルタリングが適用できない。要するにこれまでのテクスチャに対して行えていたことが，高精度を売りにしているDirectX 9の実数テクスチャでは一切適用できないと言う重大な制約があるのだ。おそらくこの点をカーマック氏は指摘していると思われる。これは我々アナリストの間でもDirectX 9発表時に話題に登った部分で，ライターの後藤弘茂氏などは「マイクロソフトやGPUベンダが制約を与えたというよりも，現在の製造プロセスルールで現実的な価格で製作しなければならないコンシューマGPUにおいては，ロジック節約のために省略せざるを得なかった」と分析している。これはありうる話であり，DirectX 10以降，何の予告もなくこの制約が取り払われる可能性もある。

　バンプマッピングされた環境光源処理（Ambient lighting）は，アウトドアや明るい場所で効果を発揮する（注：イメージベース・ライティングのことをいっていると思われる）。これを実現するには，従属テクスチャ読み込みが必要不可欠であり，また，新しいデザインツールと，ツールと連携したサポートがなければうまく実現されない。だから，今のDOOMIIIのデータセットでは完全なテストをやるのは難しい。でもこうした単体デモを制作するのは面白いよ。

　未来は，浮動小数点フレームバッファにある。一番の利点は，基礎的なアルゴリズムを変更しなくても，暗色階調の品質を崩さずに正確なディスプレイ・ガンマ・カーブが使えるようになることだ。残念だけど，現行のグラフィックカード（注：現行のDirectX 9世代GPU）では，浮動小数点実数フレームバッファを利用するのは難しい。なぜならαブレンディング処理がサポートされていなくて，カラー値をフレームバッファで加算することを余儀なくされている。これを避けるには，これから参照するフレームバッファの内容を一度テクスチャにコピーし，独立したハードウェアレベルのブレンドユニットを利用する変わりに，自作のフラグメントプログラムを使って加算しなければならない。
　この手法は非常に裏技的で，自分が楽しみで作っているバージョン以外，つまりは今のDOOMIIIのコードに組み込むつもりはない。
　また，浮動小数点実数フレームバッファと複雑なフラグメントプログラムは，影付き，加減算による渦付きの霧領域に対するボリュームライティングなどのボリュームエフェクトをより行いやすくしてくれる。（News：奥谷海人，監修：トライゼット 西川善司）

※監修者注
Zバッファレンダリングしたフレームバッファ同士を加減算することで，ボリュームを生成する新しいボリュームレンダリング・テクノロジーが開発されており，これのことをいっていると思われる。