<a href="http://22centuryboy.blog28.fc2.com/" accesskey="0" title="22世紀少年">22世紀少年

［GDC 2014］PowerVRがついにリアルタイムレイトレーシングエンジンを統合。ゲームグラフィックスはハイブリッド時代へ

Imaginationのブースで，実動デモを食い入るように見る来場者達

　2014年3月19日の記事でお伝えしたとおり，組み込み機器向けグラフィックスIPの大手であるImagination Technologies（以下，Imagination）は，北米時間3月17～21日に開催されたGDC 2014で，新しいGPUコアIP「PowerVR Wizard」を発表した。製品型番は「PowerVR GR6500」だ。
　展示会場となる「Expo」ではプロトタイプとなるテストシリコンによる実動デモが行われ，来場者の注目を集めていた。

　PowerVR Wizardの目玉は，レイトレーシングユニット（Ray Tracing Unit，以下 RTU）の搭載である。
　Imaginationは，2010年12月に，レイトレーシング用プロセッサを開発するベンチャー企業，Caustic Graphicsを買収済み（関連記事）。この旧Caustic Graphicsが開発したRTUを，基礎設計から見直して最適化し，PowerVRへの統合を果たしたものが，今回のPowerVR Wizardとなる。

　もっとも，製品としてのPowerVR Wizardは，開発コードネーム「Rogue」と呼ばれていたPowerVR Series6シリーズに属する上位モデル「PowerVR Series6XT」にRTUを統合したものである。Imaginationの担当者も「“PowerVR WizardのRTU抜き”はPowerVR Series6の新製品そのもの」と述べていたが，実際，下に示したブロック図でも，PowerVR Wizardならではの部分は紺色のところだけで，基本的なグラフィックスIPコア部分はPowerVR Series6XTと変わっていない。
　ImaginationはIP企業なので，PowerVR WizardのデザインをSoC（System-on-a-Chip）メーカーなどといった顧客に販売するカスタマーに販売するわけだが，要は，「今回の発表によって，PowerVR Series6XTに，RTU付きのラインナップが加わった」というわけだ。

PowerVR Wizardのブロック図

RTUとは何か？

　PowerVR WizardのRTUとは一体どのようなものなのだろう。「RTUなのだから，当然，レイトレーシングをするユニット」なのは漠然と分かるが，それで何ができるのか気になる読者も多いと思う。

　結論から先に述べると，RTUは，DirectX 11で採用されているテッセレータのような，特定用途専用の固定機能エンジンである。しかも，RTUという命名からするとやや語義矛盾的なのだが，RTU自体はレイトレーシングにおける実際の描画処理を行わない。レイ（ray，光線）を投げる処理のみを行う。
　「レイを投げる」ことを「レイをキャストする」などと言うこともあるが，いずれにせよ，分かりやすい言葉で言い換えると，「指示された方向に何があるのかを探査する」という意味になる。つまりRTUというのは，「指示された開始地点から指示された方向に向かって探査する」処理を行うものなのだ。

　どこを調査するのかというと，それはもちろん，3Dグラフィックスで描画されたCG世界の中となる。
　冒頭で紹介したように，PowerVR Wizardの中身は「PowerVR Series6XT＋RTU」なわけだが，ごくごく普通のGPUといえるPowerVR Series6XTでCGをレンダリングすると，頂点シェーダなどが働いて，PowerVR Series6XTの中でジオメトリがセットアップされる。平たく言うと，仮想世界が組み上がる。
　通常のレンダリングパイプラインでは，このセットアップされたジオメトリを，視点から見た視界（＝2次元平面）で切り取って，さらにピクセルへ分解する。これがラスタライズ処理というヤツだ。続けて，この各ピクセルでピクセルシェーダを起動させ，テクスチャを貼ったり，ライティングを行ったりする。

　それに対してPowerVR Wizardでは，ラスタライズ処理によってピクセルに分解された，各ピクセル位置に対応するジオメトリ世界，いわば「頂点シェーダによってセットアップされた仮想世界」の一点から，RTUによってレイを投げるようになっている。

統合開発環境「Unity 5」には，Imaginationの開発したレイトレーシングエンジンが組み込まれた。これはCPUベースでの実行となる

　レイトレーシングでは，視点の位置からスクリーン上の各ピクセルに向かってレイを飛ばすことで描画を行っていく。レイが空間内で最初にぶつかったオブジェクトが，すなわち視点から見えているオブジェクトというわけだ。オブジェクトと衝突したあとは，表面で反射させたレイが光源に到達するまで繰り返し，明るさを計算するのが基本である。
　基本どおりにやるのもよいのだが，このあたりはプログラマーのアイデア次第でいろいろ応用ができる。たとえば，オブジェクトの表面から光源（※太陽など）に向かってレイを投げるとしよう。投げられたレイが第三者にぶつからず，光源にまで辿り着いた場合，レイを投げる起点に光が当たっていることになる。通常のレンダリングでいえば「ライティングされるべき場所」というわけだ。ここでピクセルシェーダを起用してライティングやシェーディングをすれば，そのピクセルの色が決定される。

　では，投げる起点から光源までの間にレイが第三者に当たってしまったらどうかというと，そう，そこは影になるのだ。ここでピクセルシェーダを起用して“影色”を付ければ，そのピクセルは影色で描かれる。
　ここまで読んでもらうと分かってもらえたと思うが，PowerVR WizardのRTUとは，プログラマーの知りたい情報を得るためにジオメトリ世界の中でレイを投げて，何かに衝突するかどうかを検出する装置（ユニット）なのだ。

RTUがあれば，シャドウマップなしに，広大なシーンに対して1ピクセル単位の影生成を行える

RTUが生み出す「ハイブリッドレンダリング」とは何か

　「そんな面倒臭いことをして何の意味が？」と思うことなかれ。先ほどの例で挙げた「影か否かの判定」は非常にすごいことなのだ。

　現在の一般的な3Dグラフィックスのライティングシステムに，影か否かを判定する仕組みはない。なので，デプスバッファ（＝デプステクスチャ）にシーンの深度をレンダリングしてシャドウマップを生成し，このシャドウマップ情報を基にピクセルシェーダで当該ピクセルが影か否かを判断する「デプスシャドウ技法」が考案されて実用化されている。
　ただ，デプスシャドウ技法において，影の精細度はデプステクスチャ（＝シャドウマップ）の解像度に依存してしまう。たとえば4km×4kmの世界を4096×4096テクセルのシャドウマップで影を生成するとしたら，1×1テクセルに格納できる影の情報は約1m×1mという広い範囲になる。影の解像度としてはとてつもなく粗い解像度になってしまうのだ。

　GPUと組み合わされるグラフィックスメモリ容量が有限である以上，確保できるシャドウマップの解像度には限界がある。そのため，現在のゲームグラフィックスでは，近場しか影を表示しなかったり，遠くの影は適当に手を抜いたりするのが常態化している。
　一方，レイトレーシングであれば，影の解像度は確実に1ピクセル単位で生成できる。レイをピクセル単位で飛ばすのだから，ピクセル単位の影を生成できるのは自明なことである。

　これまでの3Dグラフィックスレンダリングは有効に活用しつつ，特定の表現手段や局所的な表現手段にレイトレーシングを用いる。このテクニックをImaginationは「Hybrid Rendering」（ハイブリッドレンダリング）法と命名し，今回，強く訴求している。

広がるハイブリッドレンダリングの世界

　ここまで影の話を進めてきたが，RTUでできるのは影の処理だけではない。
　Imaginationのブースでは，実際に部分的なレイトレーシングを使ったハイブリッドレンダリングの事例をデモンストレーションしていた。そのうちのいくつかを紹介しよう。

　1つは，映り込み（Reflection）の表現だ。
　現在の3Dゲームグラフィックスにおいて，映り込み表現は実のところ，とても難しいテーマの1つとなっている。

局所的な映り込み表現は，通常のレンダリング手法では難しいテーマ。RTUはこうした表現には強い

ガラスに投射される情景と，ガラス越しに見える車内の情景。両方を正確に表現するにあたって，RTUによるハイブリッドレンダリングは有効だ

　映り込み表現においては，「周囲の情景をテクスチャにレンダリングし，これを無限遠に存在するものとして扱い，3Dモデル上にテクスチャマッピングする」という環境マッピング技法がオーソドックスだ。しかし環境マッピングの概念だと，「2台の車が並んだときに，相手の車が自分の車に映り込む」といった表現の実現は難しい。CrytekがCryENGINEで採用しているような，画面座標系のポストプロセス処理を使う手立てはあるものの，画面外に存在するものまで映り込ませることはできないという制限もある。

　そこで，RTUの出番だ。プレイヤー視線の反射ベクトル方向に当該ピクセルからレイを投げて，第三者のオブジェクトに衝突したときは，当該オブジェクトの衝突箇所でピクセルシェーダを起動してライティングなりシェーディングなりを行って結果を持ち帰ることにすれば，正確な映り込みを実現できる。
　ブースでは「画面に見えていない，視点側の後ろを走るクルマの映り込み」が実現するさまを確認できた。

RTUを使った映り込み表現の実演

　ブースでは，ガラス瓶や水面などを通すことで歪んで見える情景のデモも実演された。これはガラス瓶の表面上のピクセルから視線が屈折する方向へレイを投げることによって実現されている。

レストラン内の光が，「半透明の瓶が持つ色」の影を屋外に映しだしている。これはレイトレーシングを使わない限り実現できない表現だ

　なお，RTUは再帰的に，あるいは反復的にレイを投げられるので，たとえば，「投げたレイが第三者に衝突したら，そこからまた別のレイを投げる」なんてことも可能だ。「合わせ鏡」のような，無限にレイを投げ合うような情景の再現は難しいとしても，間接照明や大域照明といった表現などを行うことはできるだろう。
　また，1点から複数のレイを投げることもできる。これは，物理的に正しいソフトシャドウ表現（半影表現）を近似するのに有効だ。

RTUの性能を考察しつつ，まとめ

　さて，現時点でPowerVR WizardのRTUは，1秒間に3億本のレイを投げられると説明されている。
　ちょっとイメージが湧きにくいので，もう少し具体的に分析してみよう。

　仮に毎秒30コマの映像を作るとすれば，1フレームあたりに投げられるレイの数は1000万本ということになる。なので，1280×720ドットの100万画素の場合，1ピクセルあたりのレイ数は10本だ。これを60fps化すれば5本となり，さらに1920×1080ドットの200万画素化すれば2.5本となっていく。
　もちろんこれは理論値でしかなく，実際に衝突を取ってくるまでの時間はシーンに依存するので，実際のところ，実効性能はよく分からない。ただ，できることの規模感は，こうやって計算してみると，なんとなく見えてくるのではないだろうか。

　まとめると，RTUは「レイをジオメトリ空間に投げて衝突をとる固定ユニット」なので，実際の衝突を取ったあとのライティングやシェーディングといった計算は，従来のGPUでいうところのプログラマブルシェーダユニットをそのまま利用できる。ここがポイントだ。

　つまり，PowerVR Wizardは，従来のGPUに最低限の固定ユニットを組み合わせて，プログラマブルシェーダユニットを必要に応じて起用しつつレイトレーシンクを行えるGPUなのだ。この発想は，別に「PowerVRだからできた」というわけでもなく，NVIDIAやAMDなどといった他社のGPUにも応用できるので，技術としてその有効性が確立されてくれば，ほかのGPUベンダーが採用に乗り出してくる可能性はある。

　ちなみにブースの担当者は「RTUの応用は，グラフィックスレンダリング用途に留まらない可能性も秘めている」とも語っていた。
　たとえば，ジオメトリ空間内で第三者との衝突を取れる以上，それこそ物理シミュレーションなどにおける衝突判定にも応用できるという。あるいは，障害物を回避して移動するためのAIや，もっとシンプルに，スニーキングゲームなどで必要となる可視判定処理にも使える可能性がある。

　期待を込めて述べるならば，RTUには，今後のGPUが向かうべき拡張の方向性を指し示しているほどの可能性を感じる。今後，どういった影響が業界へもたらされるかにも注目していきたい。

●マメ情報

　Imaginationは，ハイブリッドレンダリングをソフトウェア実装したデモを「OpenRL Hybrid Example」として公開している。実行にはImagination製のレイトレーシングライブラリ「OpenRL」のRuntimeが必要だ。興味のある人は下記リンク先から入手のうえ，実行してみてほしい。

→PowerVR Wizard製品情報ページ（OpenRL Hybrid Example公開中）
→OpenRL SDK＆Runtime配布ページ

OpenRL Hybrid Example。筆者のノートPCでも実行できた

［GDC 2014］実写にしか見えないCGが新世代ゲーム機で動く。シリコンスタジオが「物理ベースレンダリング」の新型エンジンを発表

　ポストエフェクトミドルウェア「YEBIS」やゲームエンジン「OROCHI」などで知られるシリコンスタジオは，Game Developers Conference 2014（以下，GDC 2014）に，毎年恒例のブースを出展していた。
　中でも注目の話題は，新世代ゲーム機向けに開発したという，物理ベースレンダリング（Physically Based Rendering，以下 PBR）ベースとなる新開発のエンジンである。開発コンセプトは「新世代ゲーム機向けの物理ベースレンダリングエンジン」で，実写レベルのCGをリアルタイムレンダリングで実現するのが目標になっているという。

実写レベルのCGをリアルタイムレンダリングで実現する。これが新エンジンの目標となる。この目標に向けて，まずは優先順位の高い要素を実装していき，ほぼ同時に，技術デモの制作にも乗り出したのだそうだ

　シリコンスタジオは従来から，製品には日本神話などにインスパイアされた和名を付けてきた。そのため今回も名称は気になるところだが，「商標などの問題がクリアになっていない」とのことで，公式には「名称未公開」というステータスになっている（※現地では名称を聞けたのだが，明かしてほしくないとのことだった）。そのため本稿では以下，便宜的に「新PBRエンジン」と呼ぶことにしたい。

PlayStation 4＆Xbox One世代を狙う物理ベースレンダリングエンジン

　シリコンスタジオ製のレンダリングエンジンとしては「DAIKOKU」が存在するが，今回の新PBRエンジンは，その後継的存在として位置づけられるという。ただし，現時点で決まっているのは，将来的に同社のオールインワンゲームエンジンであるOROCHIへ統合されることのみ。単体リリースされるかどうかは未定とのことだ。

新PBRエンジンは，ゲームエンジンであるOROCHIへの統合を想定して開発が進められている

　ちなみにOROCHIは，スクウェア・エニックス製アーケードタイトルであるガンスリンガーストラトスシリーズで採用されていることで有名だが，タイトル名こそ非公開であるものの，国産ゲームデベロッパが開発したPlayStation 3（以下，PS3）やPlayStation Vita用の著名タイトルに採用された実績もあるとのこと。そんなOROCHIで将来的に今回の新PBRエンジンを統合するのは，OROCHIをPlayStation 4（以下，PS4）やXbox One世代のゲームグラフィックス表現に対応させるためという理解でよさそうである。

「シャイニネス」の活用が鍵となる新PBRエンジンの仕組み

　さて，新PBRエンジンは，ディファードレンダリング（Deferred Rendering）とフォワードレンダリング（Forward Rendering）の両技法に対応している。新鋭のレンダリング技法である「Forward＋」（フォワードプラス）への対応は見送られたそうだ。
　基本的なマテリアルを「ベースカラー」や「シャイニネス」（Shininess）といったパラメータで表現し，これらの基本マテリアルを多層構造で重ね合わせていくような概念で，より複雑なマテリアル表現を可能にするという。
　ちなみにシャイニネスとは，光沢具合を表すパラメータで，表面状態の「粗さ」を表す「ラフネス」（Roughness）の対義語的な用語だが，「シャイニネスを上げる＝ラフネスを下げる」というイメージでいい。

　そして重要なのは，新PBRエンジンが，物理ベースレンダリングを採用するということもあり，BRDF（Bidirectional Reflectance Distribution Function，双方向反射率分布関数）の概念を導入していることだ。
　光のエネルギーは，物質の表面に衝突すると，衝突した表面の材質特性に応じて反射したり屈折したりしてから外に出て行く。BDRFはこれを表した関数のことだが，要するに新PBRエンジンは，入射光の総和と出射光の総和が一致する，エネルギー保存の法則に則ったシェーディングモデルを実装しているのである。

　新PBRエンジンでBRDFは，拡散反射のライティングモデルとして，PS3以前からある「Lambert」（以下，ランバート）法を採用している。また，鏡面反射のライティングモデルには，従来の「Blinn-Phong」モデルよりもハイライトのピークまでが柔らかい「Trowbridge-Reitz」（GGX）を採用しているとのことだ。
　GGXの計算量はBlinn-Phongモデルよりも多いのだが，現行世代のGPUなら十分にリアルタイムの処理が実現可能ということで採択されたという。

新PBRエンジンによるサンプル映像。なお，レンズのピンぼけ効果は「YEBIS 2」によるものだ。実は，YEBISも「3」へのバージョンアップが計画されている

　ライティングは，基本的にイメージベースドライティング（IBL）モデルを採用しており，事前に生成したキューブ環境マップを光源にしてライティングを行うイメージだ。
　「キューブ環境マップでライティングすると，すべてが環境マッピングによる（鏡のような）映り込み表現になってしまわないか」と懸念する人がいるかもしれないが，シリコンスタジオ側によれば，きちんと対策も取っているという。具体的には，シャイニネス（つまりは逆ラフネス）のパラメータに対応する「ぼやけたキューブ環境マップ」を，MIP-MAP（ミップマップ）のテクスチャ階層と似たようなイメージで持つように設計されているとのこと。つまり，粗い面の光沢は「ぼやけたキューブ環境マップ」を参照してライティングすることで，ぼやけた光沢が出るようにしているわけだ。

この画面の右上にある2つのキューブ環境マップ（※十字型の画像）はIBL用に用意されたもの。見たところ屋外の情景に使うもののようなので、屋外に向いた材質のライティングに使われていると思われる。右端の荒いキューブマップはシャイニネスの低い素材のIBLで使うものだ

　もう1つ，ランバート法の拡散反射では，視線によって見えたり見えなかったりする「視線依存のハイライト」を表現できないのではないかと思った人もいるだろう。実際，カプコンは，自社開発のゲームエンジン「Panta Rhei」（関連記事）で，視線依存のハイライトを表現可能な拡散反射モデル「Oren-Nayar」（オーレン・ネイヤー）法を採用していたが，この点，新PBRエンジンにはシャイニネスの仕組みがあるため，ザラザラしたした材質であっても，視線依存の鈍いハイライトを表現可能だ。
　ちなみに，この「ランバート法＋GGX」という組み合わせの物理ベースレンダリングエンジンは，「Unreal Engine 4」でも採用されている。


SIGGRAPH 2013でEpic Gamesが披露したスライドより。Unreal Engine 4も拡散反射モデルにランバート法，鏡面反射モデルにGGXを採用したことを明らかにしている

　動的なキャラクターの局所的な映り込みは，画面座標系でレイトレーシングを行う「リアルタイムローカルリフレクション」（RLR）を実装することで対応している。これは，Crytekの「Crysis 2」で注目を集めた表現だ（関連記事）。この表現を行うときにも，材質に設定されたシャイニネスの効果がきちんと反映されるので，毎回鏡のようになってしまうことなく，鈍い映り込みも出るようになっている。

　なお，新PBRエンジンは，リアルタイムの間接照明や大局照明を今のところ実装していない。開発担当者によれば，「現状のIBLとRLRの仕組みだけでかなりのレベルに到達しているので，業界動向を静観しつつ導入を検討したい」とのことだった。DirectX 11世代GPUの新要素であるテッセレーションステージも現時点では未対応だが，これも「将来的には対応したい」とのコメントが得られている。

ショートムービー仕立ての技術デモはプリレンダムービーにしか見えない

　今回，新PBRエンジン上で動作するデモとしては，未来の図書館を舞台に1人（？）まじめに働くロボットの孤独を描いた作品が公開された。担当者によれば，Alex Roman氏が制作したCGショートムービー「The Third＆The Seventh」にインスパイアされたモノだそうで，わずか数分程度の作品なのだが，映像をぱっと見た感じでは，ほとんどプリレンダムービーにしか見えない。

「プリレンダ」と言われたらほとんどの人が信じると思うが，新PBRエンジンのリアルタイムデモを撮影したものだ。一編のショートフィルムスタイルにはなっているが，もちろん視点の移動は自由自在

　先ほども述べたとおり，新PBRエンジンは，ディファードレンダリングとフォワードレンダリングの両方に対応しているが，このデモでは前者を使っているとのこと。デモ機は「GeForce GTX 780 Ti」を搭載しており，レンダリング解像度は説明員いわく「3K相当」で，スーパーサンプリングして1920×1080ドット表示しているという。フレームレートは30fpsだ。

　マテリアルは，制作に参加した2人のアーティストが2～3か月かけて制作。モデリングにも非常に時間をかけており，劇中に出てくるレトロなカメラモデルだけで，300万ポリゴンを使っているそうだ。今回はあくまで技術デモであるため，ポリゴンモデルの「Level of Detail」化システム^※などは導入していないため，1フレームあたり1000万ポリゴンを超えることはザラだという。

※ 視点からの距離に応じてポリゴン数を調整したり，あるいは低ポリゴンモデルに切り換えたりする仕組み。

現状は過剰なほどのポリゴン数でモデリングされているが，最適化せずとも普通に動いてしまっているので，そのまま公開してしまったのだとか

デモ中は一瞬しか現れないが，図書館にはさまざまな小物が置いてあり，それぞれの小物に，異なった材質（マテリアル）表現が適用されている。ライティングだけでなく，映り込む情景までもが，その材質パラメータの違いによって異なる表情を見せる

　なお，新PBRエンジンで実装されている動的光源は，今のところキューブ環境マップによるIBLと，太陽光である平行光源のみ。デモでもこの2種類しか使われていない。
　担当者によれば，「将来的にはそのほかの光源も実装したい」とのことで，クラシックな点光源などではなく，エリアライト（面光源）を実装しようと検討しているそうだ。

　動的光源を面光源で実装する手法は，Guerrilla Gamesの「KILLZONE SHADOW FALL」でも実現されている。シリコンスタジオ側では，新PBRエンジンのキューブ環境マップによるIBLを応用して，3Dテクスチャのような形で持つ方式を検討しているようだ。

こちらは，GDC 2014で開かれた「KILLZONE SHADOW FALL」のセッションより。「点光源にさよならして，面光源の概念を標準化する」という記述が見られる

　今回は会場でリアルタイムデモが披露されただけで，誰でも見られるムービーはまだ公開されていない。ただ，近日中にシリコンスタジオのYouTubeチャンネルにアップロードされる予定があるとのことなので，公開されたらぜひとも，新PBRエンジンの実力をその目で確認してほしいと思う。

シリコンスタジオのYouTubeチャンネル

［GDC 2014］DirectX 12，ついに発表。その特徴に迫る

会場のスタッフは皆「XII」Tシャツを着ており，お祭りムード

　北米時間2014年3月20日，予告されていたとおりではあるが，Microsoftは，Game Developers Conference（以下，GDC）2014で「DirectX 12」を正式に発表した。
　DirectX 11が発表されたのは2009年。Windows 7とほぼ同時期にリリースされたことを憶えている人もいることだろう。2012年にWindows 8とDirectX 11.1が，2013年にはWindows 8.1とDirectX 11.2がリリースされているが，メジャーバージョンアップとしては本当に久しぶりということになる。

現地時間20日，朝一発めのセッションであるにもかかわらず，会場はオープン前から長蛇の列ができた。当然，会場は超満員状態に

DirectXの歴史

DirectX 12登場の背景

　「GPUの性能はどんどん向上している。CPUは，1コアあたりの性能向上率はそれほどでもなくなっている一方，CPUのコア数自体は増加傾向にある。では，そんな状況にあって，ゲーム開発者は一体何を欲しているのか」。DirectX 12の開発は，この問いかけが起点になっているという。

今日（こんにち）のプロセッサ技術トレンドは，「コア数増大」方向に舵を切っている。このアーキテクチャを効率よく扱えないプラットフォームは存在価値が低いと言わざるを得ないが，DirectXは大丈夫なの？

Anuj Gosalia氏

　セッションで登壇したMicrosoftのAnuj Gosalia氏によれば，ゲーム開発者が強く求めているものの1つに，ゲーム機ライクな「GPUを直接ドライブ（≒駆動）できるようなAPI」があったとされる。そして切望されるもう1つの要素が，「ゲームアプリケーションとGPUの間のオーバーヘッドを極力なくすこと」だったそうだ。

　氏は，そうした要望に応える形で提供されることとなるのがDirectX 12であると位置づけていた。

ゲーム開発者は何を求めているのか？

　なお，DirectXとは，Microsoftが自社プラットフォームに提供するマルチメディアプログラミングAPIのことで，本来はサウンドやネットワーク，入力インタフェース関連などまでを網羅したものとなるが，今回発表されたのは「DirectX 12」の3DグラフィックスAPI部分「Direct3D 12」になる。
　ただ，慣例的に「DirectX≒Direct3D」とされる傾向が強く，本セッションでもそのように扱われていたため，本稿もそれに倣い，Direct3D 12とDirectX 12を基本的に区別しない。この点はご了承のほどを。

　さて，今回発表されたDirectX 12だが，結論からいうと，実効パフォーマンスを改善する目的のアーキテクチャ改変がアップデートの中心となっている。「Direct」（ダイレクト）と言いながら，あまりダイレクト感がなくなってきたDirectXに，近代流のダイレクト感を持ち込もうとする方向の改変なのだ。

　DirectXが誕生した1990年代中期は，さまざまなメーカーがそれぞれ独特なアーキテクチャに基づくGPUを用意しており，そして，そこには機能差もあったことから，“違い”を吸収するための抽象化レイヤーを分厚くする必要があった。当時のGPUは，データやパラメータを与えて「GPUの機能を呼び出す」というプログラミングモデルだったこともあり，ゲームアプリケーションとGPUまでの“距離感”が相当に大きかった，という表現も可能だろう。

　しかし現在，PC向けGPUのメジャープレイヤーはIntelとNVIDIA，AMDの3社のみであり，モバイルデバイスや組み込み機器向けGPUですらも，3社いずれかのアーキテクチャに似た構造となった。かつてのような分厚い抽象化レイヤーはもはや必要なくなってきている。
　そこでMicrosoftは，1990年代に構築された古い土台をすべて取り去って，すっきりした透明性の高いアーキテクチャへと，DirectXを改変することにしたのである。

DirectX 12の進化ポイント

　またMicrosoftは，WindowsベースのPCだけでなく，Windows PhoneとXbox OneにもDirectX 12を提供する計画があると今回明らかにしており，グラフィックスAPIを一気に刷新する心づもりでいる。一時期は「DirectXはもう終わり」とまことしやかに囁かれるほどだったが，ここで心機一転の再スタートを図ろうということなのだ。

DirectX 12はすべてのMicrosoftプラットフォームに提供される

DirectX 12は何がどうすごいのか

　現状のDirectXは，「DirectX APIを通じてパラメータをドライバに受け渡し，ドライバ側がGPUに向けて（描画）コマンドとパラメータ列を形成して発行する」構造になっているが，ここに問題が2つある。

　1つは，DirectXが提供している「APIを利用してDirectX側が作り出すコマンドとパラメータのペア」が，GPU内部のハードウェアを直接ドライブするようにはなっていない点だ。これは，「DirectXのアーキテクチャが古すぎて，実在する最新世代のGPUアーキテクチャとかけ離れすぎてしまった」と考えれば分かりやすいだろうか。

DirectX 7～8時代，DirectX APIとGPUアーキテクチャは1対1にかなり近い構造だったのだが（左），DirectX 9以降で，ここに開きが生じ始めた（右）

上のスライドで言う「開いたところ」を埋める存在がDirectX 12だ。実のところ，AMDのMantleもまさにこの立ち位置にいる

　この問題を解決するために導入されるのが「Pipeline State Object」（以下，PSO）という概念だ。
　詳細は後日あらためてお伝えしたいと思うが，誤解を恐れずに簡略化して言うと，PSOというのは，グラフィックスパイプラインとGPU内部ハードウェアとの対応を一意的に定義づけて利用する仕組みのこと。PSOを定義づけておけば，それ以降はGPUに対し「これからお願いする描画は，PSOで定義した工程表（パイプライン）ベースでお願いします」と発注できる。
　従来のDirectXでは「頂点シェーダでこの処理を行う」「ピクセルシェーダでこの処理を行う」といった感じの，細切れな指示になっていたため，処理のストール（stall，停止）が生じやすかった。その点PSOなら，GPUはあらかじめ定義された工程表に基づいて，すぐに処理に取りかかれるのである。

　もう1つは，コマンドを伝送する仕組みそのものの問題だ。
　従来のDirectXでは，APIを通して，「描画の件なんですがね」「第一パラメータは●●です」「第二パラメータは××です」といった感じに，コマンドを逐次的に発行していた。砂時計にたとえるなら，上がCPU，下がGPUで，上下は大きく開いているのに，中央部がぎゅっとすぼまったイメージ。砂粒（≒仕事）は1本の線状でしか，GPUのほうに落ちていかないのである。

　その点，DirectX 12では，あらかじめ確保しておいたメモリバッファ上で描画コマンドやパラメータを形成しておき，これをドライバへ一気に渡せるようになった。当然，メモリバッファ上に描画コマンドやパラメータを形成する処理は複数のCPUスレッドで並列に実行できる。つまり，マルチスレッドを効果的に利用できるということだ。砂時計でいえば，中央のすぼまった部分が押し広げられたようなイメージだろうか。

DirectX 12における根幹的な進化ポイント。主にオーバーヘッドを減らし，大量に仕事を発注できる仕組みを実装したという感じ

　「ドライバを通じてGPU側に伝送される前の描画コマンド」はドライバ側でGPUのネイティブ命令に変換されるので，ここにまだ抽象化レイヤーは存在することになるが，まとまった量の描画コマンド列を一気に発行できる以上，効率は従来比で格段に改善する。
　さらにDirectX 12では，この「GPU側で直接実行できるように変換されたネイティブコマンド列」を保存しておける仕組みも導入された。これは「Bundles」（バンドル）と呼ばれ，そのままBundlesを再発行してGPUを駆動することもできる。うまく活用すれば，抽象化レイヤーを超えた先で，超高効率でGPUをドライブすることも可能なのだ。

DirectX 12では抽象化部分はものすごく薄く設計されている。もちろん，すべてのメーカーのGPUに対応する必要があるため，最低限の抽象化部分は残っているが，その抽象化を超えた先でのGPUドライブの仕組みも提供される。ここはDirectX 12の大きな進化ポイントといえるだろう。**Mantle的**とも言えるが

　また，テクスチャや各種データテーブルなどといった，レンダリングに必要な素材を，アプリケーション側が任意のスタイルでその素性を定義しつつグラフィックスメモリ上に置き，実際のレンダリング時には各種シェーダから自由にアクセスする仕組みも新設されている。DirectXのAPIを介して「これはテクスチャです」としていちいち宣言したり定義したりすることなく，かなりのダイレクト感をもって，グラフィックスメモリ上にデータや素材を自在に置けるようになったのである。

　CPUのプログラムにおいて，当該プログラムの開発者は，プログラム実行の各局面に応じて，確保したメモリ空間を好きに使っていた。そういった自由なメモリの使い方がGPUでもできるようになったことになる。
　もっともこれは，家庭用ゲーム機のGPUプログラミングでは結構前からそうだったので，概念的に新しいものではない。DirectX 12が，家庭用ゲーム機的なGPUプログラミング哲学を取り入れたという認識のほうが正しいので，この点は押さえておく必要があろう。

素材やリソース周りの取り扱いの改善ポイント。CPUプログラム的な自由な取り扱いが可能になった

DirectX 12のβ版は2014年後半リリース。正式リリースは2015年か

　DirectX 12にはどの程度の性能を期待できるのか。
　セッションでは，「3DMark 11」の「High Temple」を，従来どおりのDirectX 11で動作させたものと，DirectX 12に対応させて動作させたものとで，CPU負荷に違いが出るかどうかが披露された。

　その結果が下のスライドだが，DirectX 11では，4つあるCPUスレッドのうち1つで極端に負荷が高くなっている。それに対し，Bundlesを活用しているDirectX 12では，CPU負荷が極端に低い。

DirectX 11での実行結果。テキストで表示された「O＋」のバーが長いほど当該スレッドのCPU負荷が高いことを示すが，ここでは「Thread 0」の負荷が高い

DirectX 12での実行結果。「Thread 0」のCPU負荷は極端に下がっている

　処理の内訳も下のとおり示された。下の図は，上の「Thread 0」～「Thread 3」がDirectX 11，下の「Thread 0」～「Thread 3」がDirectX 12のそれぞれ内訳だ。「App Logic」はアプリケーション実行負荷。「Direct3D」はDirect3DのAPIオーバーヘッド，「UM Driver」はユーザーモードドライバ負荷，「Kernel」はOSカーネル負荷，「KM Driver」はカーネルモードドライバ負荷，「Present」は描画表示負荷を示しているが，違いは一目瞭然といえる。

DirectX 11（上）とDirectX 12（下）のそれぞれにおける処理の内訳

　セッションでは，NVIDIAによる評価版のDirectX 12ドライバ上で動作する「Forza Motorsport 5」の技術デモが公開された。こちらは性能を示すものではなく，「実際にゲームが動いている」ことを示すための目的で公開されたようだ。「PC版のForza Motorsport 5がDirectX 12ベースで開発されている」ことを示すものではないので，その点は注意してほしい。

「Forza Motorsport 5」ベースのDirectX 12技術デモ

　気になるDirectX 12の提供時期だが，2014年後半にプレビュー版（β版）がリリースされる予定となっている。正式版は「2015年のクリスマス商戦に臨むPCゲームのリリースに間に合うような形で提供したい」という形で予告されたので，常識的に考えれば，正式リリースは2015年ということになるだろう。

DirectX 12のプレビューは2014年後半に登場。ゲーム開発者に向けては早期アクセスが提供されるという

DirectX 12にまつわる疑問に答えてみる

　最後に，セッション後の質疑応答や，セッション後に筆者が関係者に取材した情報を基に，想定される質問と回答を用意してみた。こちらも合わせて参考にしてもらえればと思う。

Q：DirectX 12はどのOSに提供されるのか

A：
　Windows 7とWindows 8.x（もしくはその後継OS）と見られる。間もなくサポートが終了するので当たり前といえばそれまでだが，Windows XPへの提供は「ない」と公式に否定されている。

Q：DirectX 12はWindows以外にも提供されるのか

A：
　セッションのレポートでも触れたとおり，Windows PhoneとXbox Oneには提供される見込み。Xbox One向けのゲームタイトルのPC向け移植やWindows Phoneへの移植が容易になるはずだ。

Windows 7＆8以降のPCだけでなく，Windows PhoneやXbox OneにもDirectX 12は提供される

Q：DirectX 12の対応GPUは？

A：
　当面はDirectX 11世代のGPUが対応製品となる見込み。NVIDIAならFermi世代，AMDならGraphics Core Next世代ということになる。

Q：DirectX 12向けに開発されたゲームはDirectX 11環境で動作するのか。逆に，DirectX 11向けのタイトルはDirectX 12で動作する？

A：
　DirectX 11とDirectX 12は，名前こそ「DirectX」ながら，基本アーキテクチャが異なるため，相互に互換性はない。
　実のところ，この仕切り直しは，DirectX 10の時も起こった。DirectX 10では基本アーキテクチャがDirectX 9から一新されたため，過渡期のPCゲームでは，タイトルによって，DirectX 9バイナリとDirectX 10バイナリの2つが提供されたりしていたが，DirectX 12の登場直後は同じようなことが起こるだろう。

Q：DirectX 12で実現されているのは性能向上のためのアーキテクチャ改変“だけ”で，新しいシェーダステージの追加や，新機能の搭載はない？

A：
　Microsoftの公式回答は「現時点では未定」。ただし，現段階でも「プログラマブルブレンド」（Programmable Blend）パイプラインと，順不同半透明描画（Order Independent Transparency），コンサバティブ・ラスタライゼーション（Conservative Rasterization）などの搭載は決定している。

コンサバティブ・ラスタライゼーションは，ポリゴンモデルのボクセル分解化処理などに有効とされる。「Unreal Engine 4」の発表時にデモがあった「SVO-GI」では，この処理を自前のシェーダで実装していた

Q：聞けば聞くほど，DirectX 12のコンセプトはMantleのそれと非常によく似ている。PSOやコマンドバッファの概念，素材の取り扱い概念はMantleと同じではないのか

DirectX 12発表を喜ぶ関係者達。左から順にTurn 10 StudiosのChris Tector氏，MicrosoftのAnuj Gosalia氏，IntelのEric Mentzer氏，AMDのRaja Koduri氏，NVIDIAのTony Tamasi氏，QualcommのEric Demers氏

A：
　そのとおり。経緯は不明ながら，仕様にはよく似ている部分がある。これまでAMD（や旧ATI Technologies）もしくはNVIDIAの提唱する「独自機能」がDirectXに採用されたことは過去にたくさんあるので，今回もそのパターンという可能性はあるが，この点についてMicrosoft，そしてAMDから公式の言及はない。
　この件に関して現時点で言えることは，AMDがDirectX 12を歓迎していることと，DirectX 12の登場によってMantleの立ち位置が微妙になることの2点だけだ。

Q：DirectX 12で，Compute Shaderはどう扱われるのか

A：
　Compute Shaderの取り扱いは未定。Mantleのような「非同期でのGPGPUとグラフィックスレンダリングの同時発行」も，対応するかどうかは未定とされている。

Q：DirectX 12が登場したことで，PlayStation 4に何らかの影響はある

A：
　直接的には「ない」が，間接的には「ある」と思われる。
　実のところ，現在PlayStation 4（以下，PS4）の開発者に向けて提供されているグラフィックスライブラリの1つに，「疑似DirectX 11ライブラリ」がある。そして，聞くところによれば，PCゲームを開発して，それをPS4にポーティングするスタイルのゲームスタジオは，この疑似DirectX 11ライブラリを活用することが多いという。正式にDirectX 12がリリースされた後は，“疑似DirectX 12ライブラリ”が提供されるはずだが，そこにタイムラグが発生したりする可能性はあるだろう。
　逆に言えば，PS4ネイティブに開発しているゲームスタジオへの影響は間接的にもあまりない。

Q：DirectSoundとかDirectInputとか，他のDirectXファミリーはどうなるのか

A：
　未定とのこと。ただ，「現在のところ話せる段階にはないが，最終版のDirectX 12には，これまでのDirectXと同じように，グラフィックス以外のAPIも含まれるだろう」とのコメントは得られている。

tag : GDC Game Developers Conference DirectX

［GDC 2014］次世代のキャラクターアニメーションはこうなる。フェイシャルキャプチャを用いたプロシージャル処理の実際

講演を担当したJohn Hable氏

　Game Developers Conference 2014の最終日である米国時間2014年3月21日に行われたセッションから，「Next-Gen Characters：From Facial Scans to Facial Animation」の模様を紹介したい。

　昨今，スキンシェーダの進歩をはじめとする多くの要因により，ゲームに登場するキャラクターが非常にリアルになってきている。とくに3次元スキャナによって，本物の人間そのままのCGキャラクターを作ることも難しくなくなり，実際にそうしてキャラクターが作られることすらある。さらに，フェイシャルキャプチャで表情を読み取り，顔の動きを再現することもできるので，キャラクターのリアルさは格段の進化を遂げている。

　このような「リアルで当たり前」な時代における次世代キャラクターとは，なにか？　それは，さらにリアルに動くキャラクターのことである。
　Agni's Philosophyでのパフォーマンスキャプチャなどを見て，動きを取り込んで再生すれば，本物そっくりになることは決まっているのだから，それで問題は解決する，と思っている人もいるかもしれない。だが，話はそう簡単ではない。一定のカットシーンならそれで良いのだが，インタラクティブな動きをするキャラクターでは，お決まりの表情を繰り返すだけというわけにはいかない。かといって，ありとあらゆる顔の動きをキャプチャデータとして持っておくのも非現実的である。
　そこで登場するのが，アニメーションを自動で生成するプロシージャルアニメーションの手法だ。

［GDC 2014］次世代のキャラクターアニメーションはこうなる。フェイシャルキャプチャを用いたプロシージャル処理の実際

　前述のように，3次元キャプチャ技術によって，簡単にリアルなモデリングデータを取れるようになった。問題は，それにどうリグを入れてアニメーションさせるかだと，FilmicWorlds.comのJohn Hable氏は語る。
　単に基本的な顔を取り込んで，表情ごとに形状を変化させればよいかというと，それだけではなく，表情それぞれでテクスチャを変える必要もある。以下の写真は，表情を正面から撮影した顔写真と，それをテクスチャにしたときのデータだ。顔のデータの変形だけでは，血流量の変化などによる表情の違いまでは表現できないのだという。

　取り込んだ顔データをどのようにアニメーションさせるかについては，技術解説書『GPU Gems 3』で解説された「Playable Universal Capture」（Ucap）と，サウスカリフォルニア大学による「Polynomial Displacement Maps」（PDM）の手法を参考にし，高精度の基本データと低精度だが大量の表情データを組み合わせる手法を採用している。

　Hable氏が顔データの取得に利用したのは，Infinite-Realitiesによる高精度フェイシャルキャプチャだ。これにより，多くの表情の基本的な形状とテクスチャをデータ化している。キャプチャ時には，基本的なドットマーカーを付けているが，それで足りないものは手動で補完したという。そのマーカーをもとに，150ものリグを自動生成している。

　その際，ソルバーのアルゴリズムは，ニュートラルな表情の顔でのジョイントの位置と各表情でのドットの位置などから，ジョイントの動きベクトルを算出し，ジョイントによる動きを行った結果と実際のスキャンでの頂点位置の差を埋め，ラプラシアンフィルタを掛けるという手順になっている。

　次に，ニュートラルな表情から見たテクスチャのゆがみを検出し，それをデータ化するのだが，ディフューズデータは，表情ごとに撮影時のライティング条件が微妙に変わる関係で正確に解くことが難しいという。そこで，ニュートラルな表情以外に，近い表情を5個探して中央値を取ることで代用するなどの対策を立てたとのこと。

　ノーマル，アンビエントオクルージョン（AO）についても同様に処理し，ブレンドされた形状にまとめ上げる。これには，デザイナーによる作業が発生するので2日くらいかかるとのこと。

　これで基本的な表情を動かすフェイシャルアニメーションデータが完成したのだが，この段階ではすべての表情ができるわけではない。キャプチャされたのは70種類の表情でしかなく，これらをもとにさまざまな表情を作っていかなければならない。そのための手法としては，主成分分析（PCA）が使われている。以前，データ駆動型プロシージャルアニメーションの試みとして紹介した「こちら」の記事と同様の手法である。

　このあたりになると，もうなにが行われているのか理解が追いつかないのだが，各表情の差分データに加重を付けて加算し，希望のデータを得るということらしい。PCAを解くためには，特異値分解（SVD）の手法が取られている。
　PCAの要素としては，顔の各部分が使われているが，これはデータの圧縮も兼ねているようだ。例として紹介されたStretchというデータは，顎と額の両方に特徴的なしわが入ったもので，FACS02は額のみ，FACS27は顎のみにしわが入っている。そういったエリアを12個用意し，データとして入力している。

　そんなこんなで70種類の表情のデータが，PCAによって最終的に8.7MBにまで圧縮されたという。そして，12成分の値に応じて，中間モーションも自在に取り出せるようになった。

　これをモーションキャプチャデータに同期してレンダリングしたのが，以下の動画である。

　顔にマーカーを貼り付けた人物の表情が，見事に作成したキャラクターにリキャップされて再現されている。

これが「Powdered Doughnut」問題

　ちなみに，レンダリングにはNVIDIA式のテクスチャスペースによる表面化散乱を使ったスキンシェーダが使われている。後方からの光で望まない部分が明るくなる「Powdered Doughnut」問題を回避するため，セルフシャドウとSHアンビエントオクルージョン処理も追加されているほか，輪郭部分を重点的に補完するAdaptive Tessellationの導入で滑らかな形状を実現している。


表面化散乱はテクスチャスペースのブラーで近似されている

スキンシェーダの効果

「Powdered Doughnut」問題を回避するためのSHアンビエントオクルージョンとセルフシャドウの導入

Adaptive Tessellationの効果

　かなり高品質な素材から手間を掛けてデータを作っただけあって，表情はそれなりに自然だ。フォトリアルなキャラクターをレンダリングすることが当たり前にできるようになった現在だからこそ，それに見合った表情を持つキャラクターが求められている。パフォーマンスキャプチャに匹敵する表情が作れてこその次世代ゲームであり，今回の取り組みは，そこに向けた確かな一歩を感じさせるものだったと言えるだろう。