「こんなハズでは……」 理論性能は良いのにベンチマークスコアが奮わない？ 「モンスターハンターワイルズ」にピッタリなGPUの選び方（3/4 ページ）

[西川善司，ITmedia]

※本記事はアフィリエイトプログラムによる収益を得ています

決定的な要素2：物理ベースレンダリングとテクスチャーマップ

　そして、グラフィックスメモリの容量と帯域を消費する要素の2つ目だ。

　近代ゲームグラフィックスでは、材質表現を「物理ベースレンダリング（PBR：Physically-based Rendering）」で実践している。このレンダリング手法こそが、グラフィックスメモリの容量をかなり消費するものだ。具体的にいえば「PBRテクスチャーマップ」だ。

　PBRとは、各材質の屈折率／反射率／吸収率／散乱率／透過率といった光学的なパラメーターを、現実世界に実在する材質と合わせる前提のレンダリング技術となる。加えて、ライティングやシェーディングといった各種処理系も「エネルギー保存の法則」に従って行うことを前提とする。

　具体的に例を挙げると、「量として100の光」がある材質にやってきた場合、先述した屈折／反射／吸収／散乱／透過といった現象で方々に散っていった光の総和は“100”にならないといけない。

　PBRは「リアリティーの追求」を第一の目標としているが、副次的恩恵として「描画結果が不自然にならない」という特性も得られる。端的にいえば現実世界と同じ照明結果が得られるということだ。そして現実世界にあるカメラ／照明／光学機器に関する技術や知見をそのまま応用できることも、PBRの大きな利点として挙げられる。

　この技術自体は「プレイステーション3」世代の後期からゲームグラフィックスに導入され始め、「プレイステーション4」世代になる多くのゲームグラフィックスで実践されるようになった。今でも、ごくありふれた技術として浸透している。

プレイステーション3で約11年前にリリースされた「BEYOND: Two Souls」のプロモーション動画。技術力の高いゲームメーカー（開発者）は、プレイステーション3世代からPBRを実践していた

プレイステーション4用ゲーム「The Order 1886」も、PBRを効果的に活用したグラフィックスの表現力が注目を集めた

　さて、PBRでは1つの材質ごとに複数枚のPBRテクスチャーマップが必要となる。テクスチャーマップというと、今でも「ポリゴンに貼り付けるステッカー画像」のようなものをイメージする人は多いとは思うが、PBRテクスチャはいわば「2次元空間に展開された数値パラメーター（2次元配列データ）」というイメージの方が正確だ。

　またPBRテクスチャーは、1つの材質につき「ベースカラー（アルベド）」「法線（微細な起伏の面の向き分布）」「メタリック（金属性）」「ラフネス（粗さ）」「アンビエントオクルージョン（自己遮蔽（しゃへい）性）」「ハイト（微細な起伏の高低分布）」など、複数枚のマップが必要になる。

グラフィックスエンジンによる違いもあるが、基本的にPBRでは1つの素材表現に複数枚のテクスチャーマップが必要となる。一例として「建造物の屋根材」に対するPBRテクスチャーを紹介する。画像の左から「ベースカラー」「法線マップ」「ARM（自己遮蔽性／ラフネス／メタリック）」「ハイトマップ」のテクスチャーなのだが、これらは全て“数値データ”で、陰影はピクセル単位で色を計算して表現している（出典：Poly Haven）

　もちろん、テクスチャーマップ群は「BC3」「BC7」といった不可逆圧縮技術によって、元容量の約25％以下に圧縮されてはいる。また、ゲーム進行に応じてSSD／HDDなどのストレージから必要分だけをメモリに読み出す、いわゆる「テクスチャストリーミング」技術を活用することも多い。

　しかし、特にオープンワールド系ゲームにありがちな広大なシーンでは、登場する材質やオブジェクトが膨大なので、グラフィックスメモリ上に常駐“させられる”PBRテクスチャの容量は相応に巨大だ。今やPBRテクスチャだけで数GBのグラフィックスメモリを使うゲームは珍しくない。

　そして、実際の描画処理では、画面上の描画対象ピクセルを描画する際に、その都度、複数枚からなるPBRテクスチャーマップにアクセスし、複数のPBRパラメーターを使って、描画対象ピクセルが何色になるのかを演算している（これを「ライティングシェーディング」という）。1ピクセル描画する度に、PBRテクスチャーへのアクセスが発生する――これはすなわちグラフィックスメモリへのアクセスに他ならない。

　もちろん、一連の処理をスムーズにこなすには、グラフィックスメモリに“圧倒的な”帯域が必要となる。

決定的な要素3：さまざまな「中間バッファー」の生成

　近代ゲームグラフィックスでは、不可視な「中間バッファー」の生成数が多いことも見逃せない。これこそが、グラフィックスメモリの容量と帯域を消費する3つ目の要素だ。

　「不可視」というだけあって、この中間バッファは画面には表れない。しかし、最終的な映像を作り上げるためには欠かせない。いわば「メモ書き」「計算用紙」的な役割を果たす、一時的なデータなのだ。

　その一例として「シャドウマップ」がある。これは、影の生成に用いる、シーンの遮蔽構造を書きためておく不可視な中間バッファーだ。これを生成するためには、シーン内の各動的光源の位置から、光の照射方向に向かって「その3Dシーンの深度情報」をGPUに描画させる必要がある。

　イメージ的には、3Dシーン内の各動的光源位置から、自動運転技術に用いられる「LiDAR（Light Detection and Ranging）センサー」の出力画像のようなものを描画させるといった感じだ。シャドウマップの描画は影を出力したい動的光源の数だけ必要なので、光源の数に比例してグラフィックスメモリの容量を消費する。

　そして影生成の際には、このシャドウマップにアクセスして、描画対象の1ピクセル単位で「このピクセルは影になっているかどうか」を判定する。これはグラフィックスメモリーのアクセスの増加（＝帯域消費）に他ならない。

シャドウマップ自体は古くからある概念だが、近代的なゲームでもよく用いられる。画面には現れていないが、かなりの数の不可視な中間バッファーが生成されていることもある（出典：Microsoft）

　また、近代ゲームグラフィックスでは、過去フレームのバッファリングも日常茶飯事だ。過去フレームを4K解像度で複数バッファリングすることだってあり得る。いうまでもなく、画面に表示した映像フレームを複数保持することはグラフィックスメモリの容量を消費する。

　そして、過去フレームと現在フレームのポリゴン位置の推移から、1ピクセル単位の速度情報（速度ベクトル）を描画した「ベロシティーバッファ」を生成するのも当たり前だ。この生成にはグラフィックスメモリの帯域を消費するし、バッファ分のメモリ容量も必要だ。

　このベロシティーバッファにアクセスして、1ピクセル単位の「速度ベクトル」を取り出して、その速度ベクトルの逆方向に対応する過去フレームにアクセスしてモーションブラー効果を描画したり、アンチエイリアス処理や超解像処理を行ったり、その他のポストエフェクト処理を行ったり……と、これらの処理は全てグラフィックスメモリの帯域を大きく消費する。

　ゲームタイトルによっては、「半透明パーティクル描画用バッファ」を生成する場合もあるし、霧や煙のようなオブジェクトをボリュメトリックレンダリングするために「三次元バッファ」（イメージ的には3次元配列で「3Dテクスチャ」とも呼ばれる）を確保して、このバッファに煙や煙の密度値をGPUを使って描画することもある。これはグラフィックスメモリの容量を消費する。

　3Dバッファに書き込まれた密度値から煙や霧を描画するには、3Dバッファに対してレイマーチングを使って可視化する必要がある。これはグラフィックスメモリの帯域を消費する。

　これらの「中間バッファ」の描画解像度は用途に応じてさまざまで、GPUの負荷低減やグラフィックスメモリの帯域／容量を節約するために、本来の解像度の4分の1に抑えるという話もよくある。

　仮に4K解像度で中間バッファを持つとしても、1枚当たりの容量はせいぜい数十MBだが、その数が多くなれば数百MB、気が付いたら数GBになっていた――なんていうことも、珍しくはない。

　結局のところ、これらの中間バッファ生成はグラフィックスメモリの容量と帯域の消費を意味し、中間バッファへのアクセスもグラフィックスメモリの読み書き（＝帯域消費）となる。