ハードウェア・テッセレータ（Tessellator）を搭載した初の民生向けGPUは、MATROX「Parhelia-512」だった

　ポリゴンを、与えた条件で自動的に分割するテッセレーション（Tessellation）。すでにオフラインCG技術としては使いこなされたテクノロジーだが、これをリアルタイムに行なうための機能をGPUに搭載することは、何度か挑戦されてきたものの、積極的に活用されたことがない。

　振り返って印象深いのは、今は3Dグラフィックスプロセッサ（GPU）事業からほぼ撤退したMATROXが2002年に発表したDirectX 8世代GPU「Parhelia-512」だろうか。これがハードウェア・テッセレータ（Tessellator）を搭載した初めての民生向けGPUだ。

　その後、ATI RADEON 9000シリーズ（DirectX 9世代）、RADEON HD 2000/3000/4000シリーズ（DirectX 10世代）でもテッセレーション技術を提供する機能が搭載されたが、いずれも業界にて広く活用されることはなかった。

　その最大の理由は、そのGPU専用の独自機能であり、他社製GPUと機能互換性がなかったため。こうした経緯から、テッセレーション技術は「おもしろそう」とは言われつつも、本格活用されずに今の今まで来てしまったのだった。

　しかしDirectX 11では、ついにテッセレーション技術がプログラマブルシェーダーアーキテクチャの中に標準仕様として組み込まれることが決定したのだ。DirectX 11に必須仕様として組み込まれるため、「ATI、NVIDIAのどちらかでしか動かない」という踏み絵はない。

　本講では、GDCで詳細が明らかになったDirectX 11におけるテッセレーション技術について見ていくことにする。

テッセレーション技術セッションの様子

---

■ 現在の主流ゲームエンジンにおける3Dモデルの取り扱いの「無駄」とはなにか

「D3D11 Tessellation」セッションを担当したNVIDIA Sarah Tariq氏

　テッセレーション技術がDirectX 11にやっと実装されたのにはいくつかの理由がある。1つはこの技術が必要されてきたということ。もう1つは、これまでのGPUメーカー各社が提案しては消えていったさまざまなテッセレーション技術から、ちょうどよい実装の仕方がみえてきたということ。

　まずは、前者の理由「時代が必要としてきた」ということについて説明しよう。

　現在は映像機器が高解像度になり、ハイデフだ、ハイビジョンだと、高解像度映像をもてはやすようになり、これに伴って3Dゲームグラフィックスも多ポリゴンで表現されることが当たり前になりつつある。

　現在の3Dゲームグラフィックスではデザイナー/アーティストが100万ポリゴン・オーダーの多ポリゴンで3Dモデルを構築することが多いが、ゲームエンジンのランタイムで表示する際には、ポリゴン量を削減した数千から数万程度の3Dモデルを利用することが一般的だ。そして、100万ポリゴンオーダーで表現されていたディテール表現部分は、法線マップに落とし込んで、ランタイムではピクセルシェーダーにて法線マッピング（バンプマッピング）を適用して表現する。

テッセレーション技術のDirectX 11での標準化への動機とは？	多ポリゴンモデルと同じクオリティを、バス消費とメモリ消費を少なく抑えて実現するのにテッセレーション技術はおあつらえ向き？

　これでも表示するキャラクターが多くなったりするとGPU負荷が重すぎるため、視点から遠くに表示される3Dキャラクターに対しては、さらにポリゴン数を減らした低ポリゴンモデルで表示することが多い。

　この視点からの距離に応じて、ポリゴンモデルのクオリティを変化させる処理系はLevel of Detail（LOD）と呼ばれ、これも一般的な3Dゲームエンジンにはよく実装されている仕組みだ。しかし、このLODの現在の実装方法にはいくつかの問題点があるとされる。

　視覚的に問題となるのが、ポリゴン数の違う（クオリティの違う）3Dモデルに表示が切り替わった瞬間をユーザーに気づかれてしまうこと。一瞬だけキャラクターの体積が変わったように見えたり、あるいは遠ざかった3Dキャラクターが急に角張ったり、逆に近づいてきた3Dキャラクターが急になめらかな曲面で再現されたりと症状はさまざまだ。こうしたLODにまつわる不自然な表示異変現象は「ポッピング」（Popping）と呼ばれて忌み嫌われる。

　このポッピングを回避するにはうまくLODシステムをチューニングするか、あるいは多ポリゴンモデルと低ポリゴンモデルをうまく作り込むか、人為的な工夫が必要で面倒だ。

　また、低ポリゴンモデルと一口に言ってもメモリ上に多ポリゴンモデルとは別に持つことになるので、メモリの消費量が増える。LODレベルを3段階にしたら、1つの3Dキャラクターについて3個分のクオリティの違う（ポリゴン数の違う）3Dモデルを用意してメモリ上に置かなければならない。これは情報として冗長である。

テッセレーション技術があれば無段階LODの実現が可能に	テッセレーション技術ならば、視点からの距離、画面解像度に最適なディテールでのLODを実現できる

アクション制御やアニメーション処理は低ポリゴンモデルでやっても実害はないはず。なら、多ポリゴンでやっている状況は無駄があると言うこと

　また3Dキャラクターが歩いたり、剣を振ったり、ジャンプしたりといったアクションを行なう場合のポーズ変更は、3Dキャラクターの外皮ポリゴンが変形することになり、これは頂点アニメーションの処理、スキニングの処理が行なわれるのだが、この処理を多ポリゴンモデルで行なうと、当然だが処理する頂点が多くなり演算量が増える。

　しかしこうした姿勢変更は、その3Dキャラクターに仕込まれたボーンをベースにして行なうことが基本であり、その外皮ポリゴンはこのボーンの動きに追従するように変形されているだけ。

　低ポリゴンのモデルでも多ポリゴンのモデルでも、そこで表現されるアクションの品質そのものには差がない。モーションキャプチャーの映像などで体に付けるドットマーカーの数があまり多くないのもそういう理由だ。少ないマーカーでも基本的なアクションが取れるからだ。つまり、見方を変えて極端に言えば、3Dキャラクターのアクション、アニメーションは「多ポリゴンモデルでやることは無駄」ということができる。

■ テッセレーション技術があるとこんなに「うれしい」？

DirectX 11テッセレーション技術が想定する新しい3Dモデル描画パイプラインの一例

　まとめると、「現状のゲームエンジン側で行なう手動式LODは無駄が多く、表現としても完璧でない」、「不必要なときに多ポリゴンモデルが利用されている局面がある」という問題点があり、これを解決しうるテクノロジーがDirectX 11に搭載されたテッセレーション技術だというのが今回のストーリーだ。

　ポリゴンを自動分割できるテッセレーション技術が、こうした問題をどう解決できるのか。DirectX 11側の用意した模範シナリオになるが、概念的に解説しよう。

　LODについては、多ポリゴン、低ポリゴンで切り換えることをやめる。その代わり、適当なテッセレーションメソッドで原型形状に復元できる程度にポリゴンをそぎ落とした適当なジオメトリ量のポリゴンモデルを用意する。

　そして、デザイン時に多ポリゴンで作り込まれた微細凹凸などのディテールは凹凸量をテクスチャ化したハイトマップ（ディスプレースメントマップ；変位マップ）に落とし込んでおく。

　ランタイムでの3Dモデル表示では、この基本形状モデルに対し、視点からの距離や表示解像度に応じて、適当なポリゴン数に増加させるテッセレーションを行なう。その際には、ポリゴンのそぎ落としで失われた曲面形状を復元できるようなテッセレーションメソッドを用いる。　　

　具体的にはCatmull Clarkサブディビジョン・メソッドやPNトライアングル（N-PATCH）メソッドといった多様なメソッドがあるが、どれを使うかは3Dグラフィックスエンジン上のデータ管理等の都合や、オーサリング時のツールとの相性などで適当に決めればよい。

ピクサーが採用するテッセレーション・メソッドが「Catmull-Clark」法		シンプルかつコストパフォーマンスの高いテッセレーション・メソッドである「PN Triangles」法。RADEON 8000/9000系で採用されていたN-PATCHと同種技術

　テッセレーションによって適当なポリゴン数の適度な形状の3Dモデルになるので、あらかじめ用意しておいたハイトマップを用いて必要なレベルの微細凹凸を、ディスプレースメントマッピングでポリゴンレベルで追加したり、あるいは視点からの距離が遠い場合はバンプマッピング程度でごまかす。

　この仕組みにより、実質的に無段階のLODがGPU内部で実現されるので、手動LODの時のように低ポリゴン、多ポリゴンの3Dモデルを複数持っておく必要がなくなる。すなわち冗長性が解消される。

　さらに、実質的に無段階に低ポリゴンモデルから多ポリゴンモデルまでがレンダリング時にGPU側で動的に生成されることになるので、ポッピングも起こりづらい。

基本形状モデルにディスプレースメントマッピングなしの状態
基本形状モデルにディスプレースメントマッピングありの状態

　またこの仕組みならば、基本的なジオメトリ処理は3Dモデルに対する姿勢変更などの頂点アニメーション、スキニング処理は、最終的に表示される3Dモデルの精細度（ポリゴン数）とは無関係に、一貫して基本形状モデルに対して行なえばよくなる。

　なぜなら、基本形状モデルに対して頂点アニメーション、スキニング処理をしたあとにテッセレーションを行なって、必要に応じてディテールをディスプレースメントマッピングか、あるいはバンプマッピングで付加すればいいからだ。

　理想論ではあるが、DirectX 11のテッセレーション技術があれば、LOD処理と頂点アニメーション/スキニングを、必要最低限のジオメトリデータ（とハイトマップ）だけで、しかも的確な演算量にてリーズナブルな表示品質で描画できることになる。

■ DirectX 11テッセレーション技術を実現する3つの新シェーダーステージ

　理想論がわかったところで、DirectX 11ではどのようにテッセレーション技術を扱っているのか詳細を見ていくことにしよう。

　DirectX 11では、中編で取り扱った「演算シェーダー」（Compute Shader）以外に、3つのシェーダーステージが新設される。前編でも軽く触れたように、この3つの新シェーダーステージのうち2つが新しい「プログラマブルシェーダー」で、1つが固定機能シェーダーだ。

　2つの新設プログラマブルシェーダーは、「ハルシェーダー」（Hull Shader）と「ドメインシェーダー」（Domain Shader）、固定機能のシェーダーステージがテッセレーションを行なう「テッセレータ」（Tessellator）となる。

　これを聞くと「テッセレーションがプログラマブルに行なえないのか」という誤解を生みそうだが、ハルシェーダーとドメインシェーダーの2つのプログラマブルシェーダーの助けを借りて、結果的にはテッセレーションをプログラマブルに行なう仕組みが実現されている。

DirectX 11のDirect3Dのシェーダーパイプライン図。緑色のマスが新設されたシェーダーステージ	新設された3つのシェーダーステージのうち1つがプログラマブルシェーダー、1つが固定機能シェーダー	新設された3角シェーダーステージの主な役割とは？

　ここからは順番に実際のDirectX 11シェーダーパイプラインの流れに従って、3つのシェーダーステージの役割について見ていくことにしよう。

・ ハルシェーダーはテッセレーション方針を決めるところ

　ハルシェーダーのハルはHull、すなわち「外皮」を意味している。具体的にいうと、ハルシェーダーは着目している3Dモデルの表皮ポリゴンを、どんな形状にするかを計画して決定する役割を果たす。なお、ハルシェーダー自身は実際のポリゴン分割（テッセレーション）は行なわない。

　ハルシェーダーでは、取り扱っているポリゴンを「どんな曲面にするか」を決めうる制御点の算出を行なう。

　なおハルシェーダーには、インプット・アセンブラ → 頂点シェーダーという流れで、最大32頂点からなる「パッチ」（PATCH）と呼ばれるDirectX 11で新設された新しいプリミティブが入力される。逆に言うと、後段のパイプラインでテッセレーションをするためにはパッチのプリミティブタイプでなければならない。

　そしてパッチとは、ハルシェーダーとして各種計算を行なう際に分割対象ポリゴンの周辺のポリゴンの形状や頂点座標までが必要になる場合があるので、これに対応させるために作られた新しいプリミティブになる。

インプット・アセンブラから「パッチ」プリミティブを入力	実際の処理は1パッチ当たり2フェーズかかる。1つ目はコントロールポイント（制御点）単位、2つ目はパッチ単位

頂点シェーダーにて、テッセレーション前の基本形状モデルに対して頂点処理を行なってしまう。最終表示状態のポリゴン数には無関係に、固定予算内の頂点処理が行なえる

「DOOM III」より。法線マップによりディテール表現は魅力的だったが、輪郭がカクカクしていてあからさまにポリゴン数が少ないのが露呈してしまっていた

　入力されたパッチプリミティブは頂点シェーダーに入力され、姿勢変更のための頂点アニメーションや、これに伴うスキニング処理が実践される。これらの処理はテッセレーション前に行なわれることになる。すなわち、ポリゴンが増加する前の基本形状モデルに対して頂点シェーダー処理が行なわれるということだ。

　そして、頂点シェーダーからの出力がハルシェーダーへと受け渡され、ハルシェーダーでは前述したようなポリゴン分割計画に相当するシェーダープログラムを実行する。

　前述したようにハルシェーダーはプログラマブルシェーダーなので、多様なロジックを組み込むことが可能だ。公式通りの曲面生成ハルシェーダーではなく、異方性&適応型のハルシェーダーにすることもできる。

　例えば、法線マップでディテール表現に凝っていても「あ、ポリゴン数少ないじゃん」と気づけてしまうことがある。これは、輪郭のポリゴン数が少なくてカクカクしているときに気づきやすい。車のタイヤの丸い部分とか、人間の頭の輪郭などはポリゴン数が少ないとカクカクに見えて、不自然に感じてしまう。逆に輪郭が多ポリゴンでスムーズだとその中のポリゴン数が少なくても法線マップのディテールで十分ごまかしきれる。

　そこで、取り扱っているポリゴンと視線の位置関係を見て、輪郭付近と判断できる場合は、多ポリゴンにするような適応型のハルシェーダーを書くことができる。

ハルシェーダーに適応型の処理を実践させることも可能	ハルシェーダーで視線ベクトルと法線ベクトルを検査して視線に対する面の向きを検査	3Dモデルの輪郭周辺と判断できた場合はそこに限って多ポリゴンに分割すると言った適応型のテッセレーションを行なえば、ポリゴンを闇雲に増やさずに見た目的に高品質な3Dモデル表示が可能。そんな適応型のハルシェーダーもアリ

・ テッセレータはハルシェーダーの計画書に従って実際の分割を行なうが処理はここで終わらない

　続くテッセレータは固定機能シェーダーだが、「コンフィギュラブルである」という表現をMicrosoftは使っている。どういうことかというと「テッセレーションという機能は固定だが、テッセレーションの仕方をコントロールできる」という意味になる。

　逆に言うと、テッセレータをどう制御するかというのをハルシェーダーが担当するというイメージになる。

　テッセレータは、ハルシェーダーから与えられた「ポリゴン分割計画書」に従い、実際のポリゴン分割に取りかかる。「ポリゴンの分割」というとイメージがしにくいが、テッセレータ自体は入力されたパッチ単位に対し、そのパッチを拡張成形するような処理を行なう。

　ちなみに、分割単位は三角形、四辺形、あるいは線分で、その分割メソッドは離散的分割、連続的分割、2のべき乗単位分割といったものが用意されている。

テッセレータは固定機能シェーダーだがコンフィギュラブル	テッセレーションの例。左端は離散的分割。右2つは連続的分割	テッセレータの結果はドメインシェーダーに受け渡されて、ドメインシェーダーはハルシェーダーの計画書を見つつ分割後のポリゴンに最終処理を適用する

・ ドメインシェーダーは分割されたポリゴンに意味づけを行なうテッセレーション専用頂点シェーダーのようなもの

テッセレータで分割されたポリゴンに意味を持たせるのがドメインシェーダー

　テッセレータはただポリゴンを分割しただけで（実際には前述したように三角形、四辺形、線分といった分割単位があるが、便宜上、本稿では“ポリゴン”という表現を用いる）、分割生成されたポリゴンにはまだ意味がもたされていない。意味というのは「どんな曲面か」を表す、接平面上の変位のこと。

　ハルシェーダーで算出した曲面生成用の制御点などはドメインシェーダーに受け渡される。そして今度はドメインシェーダーが、この情報を元にテッセレータにて分割されたポリゴンたちがちゃんと曲面を形成するようにその構成頂点たちを変位させていく。

　折り紙で喩えるならば、
●ハルシェーダーは折り方を計画して
●テッセレータは折り目の線を引いて
●ドメインシェーダーで実際に折る
というイメージだろうか。

　このドメインシェーダーはプログラマブルシェーダーなので、これまた異方性&適応型の小細工を盛り込める。

　例えば、理想論のところで述べたような、微細凹凸などのディテール情報を記録したハイトマップを元に、分割されたポリゴンをへこませたり、突き出したりといったディスフレースメントマッピング処理が行なえる。

ドメインシェーダーは大胆に喩えるならばテッセレーション専用の頂点シェーダーのようなもの。出力は「意味」を持たせた分割後ポリゴンを形成する1個の頂点	つまり、ドメインシェーダーは分割されたポリゴンの頂点の個数分だけ仕事の発注があることになる	ディスフレースメントマッピングもドメインシェーダーで行なうことになる

■ まとめ～ 今度こそテッセレーションは成功できるのか

Xbox 360 GPUのテッセレーションの仕組みはDirectX 11のテッセレーションの仕組みのサブセットに相当する

　これまで生まれては消えた「サブディビジョン・サーフェース」、「テッセレーション」の仕組みを、初めてMicrosoftがイニシアチブを取って標準化し、プログラマブルシェーダーの一環に組み込めたことの意義は大きい。

　DirectX 11で実装されたテッセレーションの仕組みは、既存のグラフィックスパイプラインを大きく変えることなく、そして既存の3Dゲームグラフィックスエンジンの構成をあまり変えずに利用できる点でも優秀だ。テッセレーションの仕組みを使いたくなければハルシェーダー、テッセレータ、ドメインシェーダーをすっ飛ばせばいいし、現在のDirectX 10におけるジオメトリシェーダーのように、ワンポイントに“つまみ食い”的に活用すればいい。

　そして、DirectX 11に採用されたテッセレーションの仕組みはXbox 360 GPUのテッセレータの仕様をベースにして標準化されたと推察されている。Microsoftも公式に「DirectX 11のテッセレータのサブセットがXbox 360 GPUのテッセレータである」と述べており、Xbox 360 GPUとDirectX 11アーキテクチャの親和性は高い。

　さらに補足すると、Xbox 360 GPUのテッセレータはATI Radeon HD 2000/3000/4000シリーズのテッセレータとほぼ同一である。ATIはRadeon HD 2000/3000/4000シリーズのDirectX 11用ドライバを提供したときに、ハルシェーダーとドメインシェーダーをエミュレーション実装して、そのテッセレータをDirectX 11パイプラインから使える仕組みの実装を検討していることが、今回のカンファレンス中の質疑応答の中でほのめかされた。シェーダーモデルのバージョン管理がややこしくなりそうで賛否がありそうだが、なかなか面白いアイディアではある。

　さて、DirectX 11はDirectX 11対応GPUの提供が遅れそうだったり、シェーダーステージが一層複雑になったり、バージョン管理が面倒くさくなりそうだったりと、なにかと賛否の物議を醸してはいるが、おおむね開発者たちには歓迎ムードで迎えられているようではある。

　というのもDirectX 10がDirectX 9世代GPUを足切りしたのと違い、DirectX 11はDirectX 11世代GPU、DirectX 10世代GPU、DirectX 9世代GPUの3世代にわたってサポートされるということが歓迎されているようなのだ。

　DirectX 11は、Windows Vista、Windows 7での動作に限定されはするが、少なくともDirectX 11で3Dゲームエンジンを構築すれば、DirectX 11世代GPU、DirectX 10世代GPU、DirectX 9世代GPUのすべてでスケーラブルに動作する仕組みが提供できる。

　前述の、一部RADEON系GPUでのDirectX 11テッセレーション・エミュレーションまでが実装されるとなれば、DirectX 11ベースのゲームエンジンはXbox 360を含めたユニバーサルなエンジンにすることもできるかもしれない。実際、こうしたゲームエンジンの開発に乗りだしているということを、名前は明かせないが今回のGDCの非公式ミーティングにて、ある大手ゲームスタジオも述べていた。

　今回、新採用となったテッセレーション技術採用をコケさせないためには、DirectX 11の普及こそが第一条件。今後の動向が注目される。