西川善司の3DGE：最新の技術やテクニックがてんこ盛りだった「アサシン クリード シャドウズ」のグラフィックスの秘密

アサシン クリード シャドウズ

　いろいろな意味で話題となったUbisoft Entertainment（以下，Ubisoft）の新作「アサシン クリード シャドウズ」（以下，ACシャドウズ）。GDC 2025で行われた本作のグラフィックスに関するセッション「Rendering Assassin's Creed Shadows」は，筆者が聴講したセッションの中でも，トップクラスに興味深いものとなった。

　というのも，ACシャドウズのグラフィックスエンジンは，レイトレーシング対応GPU世代の3Dゲームグラフィックスにおけるお手本，あるいはひとつの到達点とも言うべきレベルにあることが分かったからだ。
　そこで本稿では，ACシャドウズのグラフィックスエンジンについて解説したい。

講演者のNicolas Lopez氏（左，Technical Architect，Ubisoft Montreal）と，Lopez氏が開発に携わったUbisoftのタイトル一覧（右）

Ubisoftの自社製ゲームエンジン

　まずは，セッション冒頭で軽く触れられた，Ubisoft Entertainmentのゲームエンジンの系譜について触れておこう。

　日本ではあまり知られていないが，Ubisoftは，タイトルや開発スタジオごとに，自社製ゲームエンジンを複数運用しており，技術力はかなり高いと評価されてきた。
　Ubisoftが開発，運用するゲームエンジンとして名高いのは，「Anvil」「Snowdrop」「Dunia」の3つだろう。

　Anvilは，初代「アサシンクリード」のために開発されたゲームエンジンで，現在もUbisoftの主力エンジンとして活用されているものだ。

　Snowdropは，Ubisoftのスウェーデンスタジオが開発したゲームエンジンで，オープンワールド系ゲームの開発を得意としている。代表作としては「The Dvision」シリーズがあり，「Avatar: Frontiers of Pandora」や「Star Wars Outlaws」も，Snowdropベースのタイトルだ。
　Anvilの開発チームとの技術交流も深く，ACシャドウズの開発においても，Snowdropを参考に開発した部分も多かった。

　Duniaは，言わずと知れた「Far Cry」シリーズのゲームエンジンで，起源がCrytekの「CRYENGINE」であることは有名な話だ。
　そのほかにもUbisoftでは，「WatchDogs」シリーズのエンジン「Disrupt」や，「Splinter Cell」後期シリーズを支えた「LEAD Engine」などもある。

　今回のテーマであるAnvilは，ゲームグラフィックス技術の世代が刷新されるたび，精力的にアップデートを重ねてきたエンジンだ。PlayStation 4世代の「アサシン クリード ユニティ」（以下，ACユニティ）では，当時のプログラマブルシェーダ技術で実現しうる最高レベルの表現に達しており，筆者も興奮気味にレポートしたことを覚えている。

　2025年の最新作であるACシャドウズでは，本作開発のために，かなり広範囲にわたって新技術を投入したことが，本セッションで明らかにされた。
　本稿では，AnvilがACシャドウズの開発のために投入した新技術2つにテーマを絞って紹介しよう。

ACシャドウズの背景におけるLODシステム

　ACシャドウズは，オープンワールドスタイルのゲームであり，フィールドは16×16kmの広さを有する。
　オープンワールド型ゲームの開発経験が豊富なUbisoftだが，ACシャドウズの開発に当たり，「エンジン世代が変わった」と多くのプレイヤーが気づけるほどの技術的革新を，Anvilに盛り込むと決意したそうだ。

ACシャドウズのゲーム世界は，歴代シリーズ最大級の16×16kmサイズとなった

　Lopez氏によると，ACシャドウズでは情景を6段階の距離に分けて，描画システムを切り分けているとのこと。大枠としての「Level of Detail」（以下，LOD）システムは，6段階ということになる。
　一方で，3Dモデルに対しては，先進的な無段階LODシステムを採用した。侮りがたしである。

ACシャドウズは6段階LODシステムを採用。ただ，3Dモデルに対しては，新開発の連続LODシステムを導入した

　プレイヤー位置から最も近い「近景」（Short Range Grid）は，半径96mと設定したそうだ。この範囲内では，小型3Dオブジェクトを含めたすべてのオブジェクトを表示する。Short Range Gridにおける関連データの読込グリッドサイズは，32×32mとのこと。
　半径96〜128mの範囲は，NPCも表示される距離となっている。この範囲は「中景」（Main Grid）と呼ばれており，標準サイズの3Dモデルまで表示される仕組みだ。読込グリッドサイズは，ここも32×32mだ。
　半径128〜384mの範囲は，「遠景」（Long Range Gird）となる。この範囲では，建物や樹木などの大型の3Dモデルだけを描く。ここから読込グリッドサイズは，128×128mに広がる。

　半径384〜4096mまでの範囲は，とくに呼び名はないようだが，いわゆる「超遠景」といったところか。ここに描画するのは，3Dモデルではなく，いわゆる板ポリゴンにテクスチャを貼り付けたビルボード（書割）的な疑似3Dオブジェクトである。読込グリッドサイズは512×512mだ。

　半径4096〜8192m（※スライドでは8182mとなっていた）の範囲になると，3Dオブジェクトは，ポリゴン化していない「ポイントクラウド」^※で表現する。この領域になると，地形もポリゴン化はしないで，板ポリゴンに情景を描いたビルボードでの表現となる。
※3D座標を持ったドット（ポイント）によって表現される，離散的かつ立体的なドット絵のようなもの

　各要素を描画したサンプルのスライドを見ると分かりやすい。

地形のみの描画

地形＋遠景の描画

地形＋遠景に加えて，ビルボードやポイントクラウドなどを加えた完成画面

　感心させられたのは，超遠景のビルボードやポイントクラウドなどの品質だ。
　完成画面だけを見ると，どこからがフェイク的な2.5Dオブジェクトなのか，見分けは付きにくい。このあたりにも，長年にわたるオープンワールド型ゲームの開発経験が生きているのであろう。

　次に示すのは，ビルボードレベルの超簡易表示（Fake Entities）と，そこからLODレベルに従った3Dモデルを表示した状態のスクリーンショットだ。
　1枚目は，超簡易表示のみの状態。本来は，こんな近景でここまでの超簡易表示が行われることはないが，これはデモのために作ったものだ

ビルボードレベルの超簡易表示表示のみ

超簡易表示とLODレベル制御を受けた3Dモデルの表示。いわゆる完成画面

　次のサンプル画像は，ポイントクラウドで表現される超遠景オブジェクトをオン，オフした場合の違いを示す。

ポイントクラウドがオフの状態

ポイントクラウドがオンの状態

ビルボード状オブジェクトの描画数をヒートマップで示したスライド

　ポイントクラウド描画は，基本的に1ポイントを1ピクセルで描画する。ポイントサイズを与えることで，2ピクセル以上で描画することも可能だ。
　個人的な感想だが，スクリーンショットを見た感じ，超遠景の樹木の葉がモコモコしているようなので，画面解像度や視点からの距離に応じて，ポイントサイズを変えているようにも見える。

　いずれにせよ，超遠景まで連続的かつ，スケーラブルな描画となっているのはお見事である。

独自実装したマイクロポリゴン型の無段階LODシステム

　先述したように，Ubisoftは，ポリゴンモデルの3Dオブジェクトに対する連続的（≒無段階）LODシステムを独自開発して，ACシャドウズの新世代Anvilに統合した。
　ちなみに，PS4世代のACユニティで使ったAnvilでは，無段階LODの一歩手前である，当時としてはかなり先進的な離散的（≒有段階）LODシステムを採用していた。

　最もシンプルかつ原始的なLODシステムといえば，視点からの距離に応じて，遠ければ低ポリゴンモデルで描画して，視点に近づくにつれて高ポリゴンモデルに切り換えていくものだ。
　こうしたLODシステムでは，同じ3Dモデルでポリゴン数の異なるもの数体を，事前に作成しておく必要があった。この原始的な離散的LODシステムは，2025年現在でも，採用するゲームは多い。

　この離散的LODシステムでは，LODレベルが切り替わるごとに，ポリゴン数の異なる3Dモデルに切り換えて描画する。しかし，ポリゴン数が違うので，切り換えた瞬間，3Dモデルの輪郭や体積が突然変化するため，ユーザーに切り換えを気付かれることがある。
　「ポッピング」と呼ばれるこの現象は，3Dゲームグラフィックスが長年抱える弱点，永遠のテーマだった。

　ACユニティ世代のAnvilでは，これを発展させた半連続LODシステムを実装していた。
　この半連続LODシステムは，「クラスタベースLOD」とも呼ばれるテクニックにより，各LODレベルの3Dモデルを，数個から百数十個のポリゴンからなるグループ（クラスタ）に分割して管理するものだ。

ACユニティは，10年前としては斬新な「クラスタベースLOD」を採用していた。ポッピング現象がなくなるわけではないが，LOD品質は高かったというスライド

　半連続LODシステムでは，LODレベルの異なる3Dモデルを，3Dモデル単位だけでなく，部位単位で管理する仕組みを取り入れた。たとえば人体モデルなら，頭部の前後，胴体の前後，腕や脚の前後といったパーツに分けて管理するのだ。

　LODレベルが変わらないときは，そのLODレベルに対応した人体モデルを描画するだけだが，LODレベルが切り替わりそうなタイミングでは，半連続LODシステムを利用して描画する。
　たとえば，人体モデルが正面（視点側）を向いていた場合，高ポリゴン3Dモデルの頭部と胴体，腕，脚の前面パーツを視点から近い側に描画して，低ポリゴン3Dモデルの背面パーツを視点から遠い側に描画する。
　すると，LODレベルが切り替わるギリギリのタイミングでは，結果として，LODレベル±0.5とでも言うような，中間精細度っぽい3Dモデルで描画できるわけだ。

　実際には，頭部，胴体，腕のような部位単位で管理するのではなく，もう少し細かい単位で分けて運用するのだが，半連続LODシステムの大雑把なイメージとしてはこんな感じだ。
　この半連続LODシステムはAnvilだけでなく，「Horizon」シリーズの開発元として知られるGuerrilla Gamesのゲームエンジン「Decima」にも採用されている。

　さて，この半連続LODシステムを進化させたのが，本稿のテーマである連続LODシステムである。ACシャドウズでは，「Unreal Engine 5」（以下，UE5）のマイクロポリゴンによる無段階LODシステム「Nanite」（関連記事）のアイデアを取り入れた，とLopez氏は述べている。

　半連続LODシステムでは，LODレベルごとにポリゴン数の異なる3Dモデルを複数用意していた。それに対して，ACシャドウズで実装された連続LODシステムは，用意する3Dモデルはひとつだ。
　一方で，頭部，胴体，腕のような部位よりも，少し細かい単位でグループ分け（クラスタ化）して管理する半連続LODシステムのアイデアは，そのまま継承する。そして，視点から距離に応じたポリゴン数の制御（以下，LOD制御）は，3Dモデル全体に対してではなく，クラスタ化したポリゴングループに対して行うのだ。
　ポリゴングループは，テクスチャマップのMIP-MAPのような階層構造になっている。この階層構造のポリゴングループを，講演では「Micropolygon Geometry Hierarchy」（以下，MPH）と呼んでいた。

スライド下にある色分けされた3DモデルがMPHである。3Dモデルの部位分けのようなものだ

　たとえば，手のモデルのMPHなら，多ポリゴン状態から低ポリゴン状態まで，LODレベルごとに精細さの異なる複数バリエーションの手モデルを，階層構造で持っているようなイメージだ。
　なお，ポリゴン数の削減はリアルタイムで行うわけではなく，ゲーム開発時やゲーム初回起動時などで，プレイ前に済ませている。また，3Dモデルの低ポリゴン化処理に関しては，ACシャドウズでは3Dモデルのポリゴン削減ツール「Simplygon」を活用したそうだ。

　テクスチャマップには，貼り付けるポリゴンの大きさに適した複数の解像度のテクスチャマップを，階層構造で持たせるMIP-MAP構造という概念がある。MPHとは，MIP-MAPと発想が似たもので，LODレベルに応じたポリゴン数で表現する部位モデルのようなものを，階層構造で持たせたものだ。

MPHの例。上の画像のMPHを色分けして示したのが下のスライドだ

　視点から距離が近ければ，ポリゴン数の多いLODレベルのMPHで描画して，視点からの距離が遠ければ，ポリゴン数の少ないLODレベルのMPHで描画する。LODレベルが切り替わっても，3Dモデル全体で描画するモデルを切り換える仕組みではないので，ポッピングが起きにくいというわけだ。

　それに加えて，実際にMPHを描画するときには，もうひとつ別の工夫を行うのが，連続LODシステムの重要な点である。
　描画対象の各ポリゴンをラスタライズしてピクセル化するときは，対象のポリゴンが1ピクセル未満であれば，描画せず破棄する。1ピクセル未満のポリゴンを1ピクセルで描画したところで，重複描画によってグラフィックスメモリバス帯域幅を無駄に消費するだけなので，描画前にカリングするわけだ。
　微細ポリゴンを描画するか，しないかを決める制御が，連続LODシステムの重要なプロセス，「マイクロポリゴン描画工程」である。

　MPHを描画するときに，視点から近いLODレベルのMPHを選択しても，1ピクセル未満のポリゴンは描画しないので，過剰描画は起きにくい。むしろ，あえて描画するほうが，輪郭形状や体積の変化が起きにくい，つまりポッピングがほとんど生じない描画になりやすいので，いいことずくめとなる。

　ポッピングが起きるか起きないかのギリギリを攻めるのか，それとも，常に距離の近いLODレベルを選択することで，ポッピングが起きない安定した描画を実現するのか。こうした最適なLODレベルの選択にこそ，連続LODシステムにおけるチューニングの妙がある。
　なお，Lopez氏によれば，プレイヤーキャラクターがゲーム世界の中を移動していくと，メモリ上にない世界のデータをストレージから読み込むが，3Dモデルに関しては，MPH単位で読み込むとのこと。

　ACシャドウズでは，マイクロポリゴン描画を伴った連続LODシステムを，3Dオブジェクトの描画だけでなく，影生成に対しても適用しているという。また，このシステムは，静的3Dオブジェクトで，なおかつ不透明ポリゴンのみを扱い，透明要素を持ったポリゴンは扱えない。このあたりの仕様は，UE5のNaniteと同じだ。

ACシャドウズの連続LODシステムは，Deferred Rendering用のG-Buffer出力と影生成用に使われている

　ポリゴンのラスタライズ工程は，ある程度面積の大きいポリゴンの場合，GPU側のハードウェアラスタライザを利用する。一方で，サイズの小さいポリゴンについてはソフトウェア（Compute Shader）で実装したラスタライザで処理する。Mesh Shaderを高速に処理できるGPUでは，ソフトウェアラスタライザをMesh Shaderで記述しているそうだ。

Ubi独自のGPU自律駆動型グラフィックスサブシステム「GPUIR」

　ACシャドウズのAnvilでは，マイクロポリゴン描画を使った連続LODシステムが担当しない3Dオブジェクトを，Ubisoftが独自開発したGPU自律駆動型のグラフィックサブシステム「GPU Instance Renderer」（以下，GPUIR）で描画する。
　GPUIRは，描画コマンドをCPU側のサブシステムで制御するのではなく，GPU側で制御，生成するものだ。いわばGPUが，自らを駆動して描画を進めるグラフィックスパイプラインで，具体的には，DirectX 12の「ExecuteIndirect」を活用した，Draw Indirectタイプのグラフィックス描画システムである。

　Anvilは，このサブシステムを「アサシン クリード ヴァルハラ」や「アサシン クリード ミラージュ」世代から採用している。Lopez氏は明言しなかったが，おそらく，動的3Dオブジェクトは，ACユニティと同じ半連続LODシステムのままであろう。

　次のスライドは，GPUIRのパイプラインの概要になる。

GPUIRは，各種カリングやLODレベルの選択などもGPUが自律的に行う，最新のグラフィックサブシステムとなっているようだ

　ここまでを踏まえて，Lopez氏は2つのシーンを示しながら，それぞれのシーンをどのように描画しているかを解説した。
　次のスライドは，高所から街並みを見下ろしているシーンだ。このシーンは，はるか遠方までが見えるパノラマ映像で，オープンワールドらしい情景だ。

遠くまで描画したシーンでのポリゴン描画数

　このシーンで，マイクロポリゴン描画を使った連続LODシステムが担当したオブジェクト総数は，約2万8000個で，約3400万ポリゴンを描画した。内訳は，3Dオブジェクトが約1800万ポリゴンで，残りの約1600万ポリゴンは，影生成用を含めた見えないポリゴンだ。
　ラスタライズされた約3400万ポリゴンのうち，ソフトウェアラスタライザが担当したのは約3000万ポリゴンで，GPUのハードウェアラスタライザが担当したのは約400万ポリゴンにすぎない。

　さらに，このシーンでGPUIRが扱った3Dオブジェクトの総数は，約130万個。そのうちの99％，ポリゴン数にすると約4億1000万ポリゴンがカリングされ，約9000個ほどの3Dオブジェクト，約170万ポリゴンが実際に描画されたとのこと。
　つまり，不可視のポリゴンも合わせたシステム全体での総描画ポリゴン数は，約3570万ポリゴンということになる。

　Lopez氏は，もうひとつ，別のシーンにおける描画ステータスについても説明した。先ほどとは打って変わって，大きな樹木が生い茂る森の前にプレイヤーキャラクターがいるという，近景主体のシーンとなる。

森を目前にして，眼下を観察しているシーン。密度の高い画面だが，眼前の木々が遠方の情景を遮っているので，カリングされるポリゴンも多そうだ

　このシーンでは，連続LODシステムが担当したオブジェクト総数はわずか1000個で，約760万ポリゴンを実際に描画したという。内訳は，3Dオブジェクトが約160万ポリゴンで，残りの約600万ポリゴンは，影生成用を含めた不可視ポリゴンだ。
　ラスタライズされた約760万ポリゴンのうち，ソフトウェアラスタライザが担当したのは約730万ポリゴン，ハードウェアラスタライザが担当したのは約30万ポリゴンだとのこと。

　このシーンで，GPUIRが扱った3Dオブジェクトの総数は約300万個。見れば一目瞭然だが，プレイヤーキャラクターの周囲を大きな樹木モデルが囲んでいることもあり，先述のシーンよりも，3Dオブジェクトの数がかなり多い。
　とはいえ，こちらのシーンでも，その99％がカリングされ，実際に描画された3Dオブジェクトは，約3万1000個ほど。ポリゴン数にすると，約15億ポリゴンがカリングされ，実際に描画されたのは約680万ポリゴンとのこと。
　両システムでの，不可視ポリゴンも合わせた総描画ポリゴン数は，約1440万ポリゴンということになる。

　こうして見てくると，近代3Dゲームグラフィックスの総描画ポリゴン数は数千万単位に到達していることが分かり，感慨深い。それと同時に，その背後で，億単位のポリゴンが破棄されていることも興味深いと言えよう。

アサシンクリードシリーズの大局照明

　ACシャドウズでは，どのような大局照明（Global Illumination，GI）技術を使っていたのだろうか。Lopez氏は，ACシャドウズでのGI技術について説明する前に，アサシンクリードシリーズにおける同技術について振り返った。

　シリーズにおいて，GI技術の本格導入が始まったのは，ACユニティあたりからだ。ACユニティでは，「Irradiance Volume」（放射輝度ボリューム）法を活用していた。
　Irradiance Volume法は，開発段階で，事前にGI情報を計算しておく方法だ。事前計算は，ゲーム世界全域を直方体のグリッド単位で分割したうえで，各グリッドの頂点単位で行う。つまり，各グリッドは8つの頂点があるので，事前計算したGI情報は，グリッドごとに8つとなる。

　各頂点のGI情報には，全方位にどんな光（色と強さ）を放出しているかが記録されており，これをIrradiance値と称する。近年では，データ形式を球面調和関数（Spherical Harmonics，SH，関連記事）で持つのが一般的だ。
　ゲーム世界を分割するグリッドのサイズは，大きいものだと数mから十数m単位，小さなものだと50cm〜1m単位と言った具合だ。大きなグリッドは，小さなグリッドを複数内包した階層構造となっている。
　大きなグリッドが持つGI情報は，中景や遠景の大型オブジェクトにおける間接照明に用いられ，同様に，近景に置かれる人体サイズ以下の小型オブジェクトに対しては，小さなグリッドが持つGI情報を用いて間接照明を行う。ちなみに，同階層で隣接するグリッド同士の頂点は共有されるが，異なる階層同士のグリッドは，頂点を共有しない。

　Irradiance Volume法は，技術力の高いゲーム開発スタジオではPS3世代後期から使われ，PS4世代のころには，多くのスタジオで採用が進んだテクニックである。
　ACユニティでは，1日を朝昼夕夜の4つの時間帯に分けて，各時間帯ごとの太陽の位置に対応する4種類のIrradiance Volumeを事前計算しておく。これを表現したい時間帯ごとに，適宜切り換えて間接照明を行っていた。つまり当時は，4段階の離散的な時間帯表現だったわけだ。

ACユニティでは，4段階の事前計算されたIrradiance Volumeで朝昼夕夜を離散的に表現していた

　ACユニティの後に登場した「アサシン クリード シンジケート」（以下，ACシンジケート）や，「アサシン クリード オリジンズ」（以下，ACオリジンズ）においても，Irradiance Volume法ベースの大局照明技術を採用している。
　ACシンジケートの場合，1日の時間分割数を9に，ACオリジンズでは11に増やしたそうだ。その代わり，グリッドの最小サイズは50cmから，1mへと粗くなっている。

　下のスライドは，Lopez氏が示した，ACユニティ以降の各作品群における事前計算にかかった時間数と，そのデータ容量についてまとめた表だ。ゲーム世界が大きくなればなるほど，そして保持しておく時間帯のバリエーションが増えれば増えるほど，GI情報のデータ量も大きくなり，時間もかかっている。

ACユニティ，ACシンジケート，ACオリジンズにおけるグリッドサイズや時間分割数，生成に必要な時間，データサイズを示したスライド

　といっても，スライドの値はちょっと分かりにくい。実は，表にあるACオリジンズの値は，「もし，ACオリジンズと同等のIrradiance Volume法のパラメータ設定で，計算対象エリアをACシャドウズの16×16kmまで広げたら」という想定値なのだ。
　言い方を変えると，ACオリジンズのGI情報事前計算パラメータ設定で，ゲーム世界を16×16kmに広げれば，ACシャドウズの計算時間やGI情報データサイズが求められるという仮定で計算した値である。

　なぜ，そんな仮定の値を計算しているかというと，最新作のACシャドウズも，時間分割数や最小グリッドサイズはACオリジンズと同じためだ。想定計算の結果は表のとおりで，計算時間は約156日，しかもデータサイズは468GBという見積もりなった。
　実際のACシャドウズでは，春夏秋冬の四季の要素が加わるので，計算時間もデータサイズも4倍となると予想できる。つまり，GI情報だけで1.9TB（468GB×4），計算には1年8か月かかることになる。これが無理な見積もりなのは，素人目にも明らかだ。

ACシャドウズの大局照明（1）〜拡散反射光にはIrradiance Volume法を用いる

　そこで開発チームは，ACユニティと同じIrradiance Volume法を使うことを基本方針としつつ，アグレッシブなデータ削減に取り組むことにした。
　まず，従来作とは異なり，ゲーム世界全体を自動でグリッド分割するのは止める。そして，ゲーム世界のどの部分を，どのくらいのグリッド精度でGI情報を事前計算するかの分割を，ゲーム世界のデザイナーによる人力で行うこととした。

　とはいえ，16×16kmの広大なゲーム世界の全域を手動で振り分けるのは大変だ。そこで，まずはゲーム世界を，8m×8mというかなり粗いグリッドで分割した状態を初期状態とする。そのうえで，プレイヤーが念入りに探索しそうな集落やランドマーク的なエリアに対して，グリッドの一辺サイズを，最小50cmまで精細度を上げたIrradiance Volume法を採用したのだ。

ACシャドウズでは，オープンワールド型ゲームに適した大局照明技術の実装に取り組んだ

　次のスライドは，グリッド分割の一例になる。ヒートマップ的に，そのグリッドの一辺サイズごとに，青（50cm），赤（1m），橙（2m），黄（4m），緑（8m）という感じで，ゲーム世界のグリッドサイズの「粗密」が振り分けられているのが一目瞭然だ。
　点在する青や赤のエリアが，ゲーム進行にとって重要な地点であろうことが，ここから読み取れる。

ACシャドウズにおけるIrradiance Volumeのグリッドサイズの粗密を示したスライド

　グリッドの一辺サイズが一様でなくなることから，データ表現方式としては粗い八分木構造（Sparse Octree）で管理しているとのこと。
　各グリッド内に，静的な3Dオブジェクトのポリゴンがひとつでも存在すれば，そのポリゴンを含む最小サイズのグリッドまで分解していく。また，最小グリッドが3Dモデルの内側に入ってしまった場合は，そのグリッドを破棄する。どんなサイズのグリッドでも，グリッドの頂点が3Dモデルの内側に入った場合は，その頂点でのGI情報は，計算せず破棄するといった具合だ。

　こうすることで，静的な3Dオブジェクトが何もない空間は，最大サイズのグリッドの各頂点だけでGI情報を事前計算しておく。逆に，建物内のGI情報は，事前計算をしない。
　こうした工夫によって，16×16kmの広大なゲーム世界の事前計算で，対象のグリッド頂点（プローブ）総数を10分の1くらいまで削減できたと，Lopez氏は振り返った。ちなみに，室内のGI情報については，別の手法による間接照明技術で計算するのだが，その話は後述しよう。

ポリゴンを含むグリッドは，人力で設定した最小グリッドサイズまで，細かく分割する

　ACシャドウズの場合，1日の時間分割数は10分割，1分割単位を144分(＝24時間÷10)として，分割ごとの天球（太陽，月，空など）からのGI情報を事前計算している。また，それとは別に，松明やたき火のように固定された局所光源からのGI情報も，別データで持っている。

8つ並んだ画像の左上は，松明やたき火などの固定的な局所光源からのGI情報だ。それ以外の7種類は，各時間帯別の天球からのGI情報。天球からのGI情報は，ここにある7種類以外に3種類ある

　ランタイム時に，任意の時刻が与えられた場合，その時刻に一番近い時間帯の天球から計算したGI情報を2種類選ぶ。そのうえで，2種類のGI情報を線形補間して，指定時刻の天球からのGI情報を計算する。さらに，固定的な局所光源によるGI情報を加算して，その時間における最終的なGI情報を作り出すメカニズムを，ACシャドウズでは構築しているそうだ。

　ACシャドウズでは，事前計算するGI情報の表現形式も刷新した。
　これまでは，RGB三原色の全方位放射を表す球面調和関数で表現していたが，ACシャドウズの場合，球面調和関数の表現は，輝度（Y）情報だけは方向情報ありの「SH4」（球面調和関数の次数はl＝4）で表現して，色情報は，方向情報なしの色差情報によるスカラ値で表現したそうだ。

GI情報は，輝度情報のみ方向情報あり，色情報に付いては方向情報なしの色差（CoCg）とした。スライドでは「CoCg」となっているが，意味は「CbCr」と同じだ

　ただ，このやり方だと，「天井は青」「床は茶」といった，方向ごとの色は失われてしまう。素人考えでは，せめて方向情報が2方向分ある「SH1」（l＝1）程度にして，2方向くらいの方向情報は残したほうがよかったのではないかと思うのだが。

　こうした理由についてLopez氏は，「四季ごとのGI情報を持たなければならないACシャドウズにおいては，できるだけGI情報を削減したかったから」と述べていた。
　たしかに，輝度のGI情報自体は，どの季節でも流用できることは確実だ。季節ごとの違いは，草木が緑主体の夏や，葉が紅葉する秋，雪で白っぽくなりがちな冬といった具合なので，季節の色情報は曖昧でも，間接照明においては十分事足りるだろうと判断したわけだ。ちなみに，四季のうち春と夏の色差GI情報は，同じ情報で十分と判断したとのこと。
　Lopez氏によると，この手法によって間接照明の色表現がおかしくなる部分もあったが，そうした部分については，間接照明の影響を下げたり，3Dオブジェクトを間引いたりといった，デザイナーの手作業によって対処したようだ。

　さて，GI情報を各頂点に含んだグリッドは，ランタイムでも順次ストリーミングで読み込む方式を採用した。また，グリッドに対するアクセスは，LODの概念を導入したという。
　カメラから遠方にあるGIグリッドは，粗いグリッドの頂点にアクセスする。LODレベルの切り換えポイントぎりぎりの場合，そのポイントに隣接する2つのLODレベルのGIグリッドにアクセスして，補間した情報で間接照明を計算する。これにより，LODレベルの切り換えポイントで間接照明が急激に変化するポッピング現象を起こさないわけだ。

GI情報は，カスケード式のLOD制御を採用する

　こうした工夫の結果，最適化前は1.9TBになりそうだった事前計算GI情報を，約9GBにまで削減できたとのこと。

事前計算GI情報は，最適化前の約200分の1にまで圧縮できた

　ACシャドウズにおける，季節ごとの情景事例を次に示す。色情報は，かなり大ざっぱになっているにもかかわらず，パッと見にはまったく違和感を感じない。

同じ情景を各季節ごとに描画した例。上段が最終描画結果，下段が間接照明のみを適用して，テクスチャ等の適用を省いた状態の描画結果だ

　春夏と秋は，うっすらと季節らしい木々の色に合わせた間接光が乗っているのが分かる。一方，冬になると間接光に色味がなく，まるでAmbient Occlusion（疑似的な環境光に対する自己遮蔽影）のようになっているのが面白い。
　Lopez氏も，「200倍に圧縮されたGI情報による描画として見れば，その結果には十分に満足している」と振り返っていた。

ACシャドウズの大局照明（2）〜多段構成の鏡面反射

　鏡像，つまり映り込みを含むような鏡面反射要素の大局照明について，ACシャドウズでは，描画品質や対象プラットフォームごとに，最適な描画性能を発揮できるように3段階で行う多段構成で実現している。
　多段構成の様子を示したのが，次のスライドだ。なお，スライド中の矢印は，描画パイプラインの順序を示す。

ACシャドウズにおける鏡面反射要素の大局照明は，3段構成で処理する。ちなみに，情景によっては，3段階の要素をすべて描くこともある

　まず1段目は，動的なキャラクターを含む映り込みに，定番の「Screen Space Reflections」（以下，SSR）を活用する。局所的な簡易ソフトウェアレイトレーシングを，描画結果の最終フレームに対して行う疑似鏡像表現だ。
　このテクニックは，画面外のオブジェクトや，視点から見えるオブジェクトであっても，裏側や遮蔽されている領域の鏡像は作れないので，うまく制御しないと，へんてこな鏡像となってしまう弱点を持つ。しかし，静的な環境マップでは表現できない，動的キャラクターの映り込みまで表現できるメリットが大きいことから，PS4世代のゲームで定番となった疑似鏡像表現である。

　続く2段目の「Local Cube Maps」（LCM）は，静的な環境マップによる静的な鏡像表現だ。ゲーム世界から選ばれた要所において，全方位360度カメラを設置するような感じで，全方位の情景を開発段階において事前に取得して，キューブ環境マップを作っておき，ランタイム時に利用する手法だ。
　本来，キューブ環境マップは，かなり遠方の映り込みを表現するために用いることが多い。しかし，視差補正を行ってキューブ環境マップへアクセスする「Parallax Corrected Cubemaps」の手法を活用することで，近景の映り込み表現にも利用できる。LCMは，近景の映り込み用に利用するだけでなく，LCMに近づいた動的キャラクターに対するライティングのために活用することも可能だ。いわゆる「Image-Based Lighting」（IBL）である。
　なお，ACシャドウズのLCMには，もうひとつ隠し球的なすごいアイデアが仕込まれているが，それについては後述する。

　最後の3段目が，動的なキューブ環境マップ「Dynamic Cube Maps」（DCM）だ。
　ACシャドウズでは，プレイヤーを中心に置いた座標系からの全方位360度の情景を，キューブ環境マップとして取得している。これがDCMだ。DCMの用途としては，プレイヤーに対するIBL用の全方位光源として利用したり，あるいはプレイヤーやその装備品（※刀や鎧など），はたまた眼球への映り込み表現などに用いられる。

　描画負荷が高そうなDCMだが，描画性能を稼ぐために，3Dオブジェクトを最も粗く描写する低ポリゴンLODレベルで描画している。それこそ，樹木などの一部のオブジェクトは，ビルボードレベルの疑似3Dオブジェクトを用いるくらいだ。
　なお，DCMの取得頻度は毎フレームではなく，適当なタイミング（いわゆる半リアルタイム）で取得している。

左がDCM，右がLCMの例。細部は異なるが，かなりよく似ている

ACシャドウズの大局照明（3）〜SSR的な手法なのに画面外の情景も映り込む「G-Buffer LCM」

　ACシャドウズでは，ユニークなLCM生成を採用している。LCM自体の描画は，ゲーム開発段階で行うのだが，ACシャドウズでは，ひとつの地点におけるLCMについて，多くのバリエーションを生成するのだ。
　まず，アルベド（ベースカラー），法線ベクトル，深度，影について，それぞれ4つのLCMを個別に同時生成する。いわゆるマルチレンダーターゲット（MRT）というやつだ。

　そして影のLCMについては，筆者も「頭良すぎだろ」と感心したほどの技巧的な手法で，影の有無を表現している。
　まず，朝昼夕夜24時間の時間帯を8分割して，8バリエーションの影を生成する。といっても8枚のテクスチャを作るのではなく，生成する影のLCMは，8bit様式の1枚だけというのが賢いところ。
　影のLCM上のテクセルで，最下位ビットから最上位ビットまでの8bitそれぞれを，8分割した各時間帯で，そのピクセルが影か，影ではないかを表すフラグに割り当てるのだ。この方法ならば，8つの時間帯ごとに異なる太陽の位置に応じた影の出方を，たった1枚の影LCMで表現できることになる。

　たとえば，テクセルの各ビットが2進数表記で「1」だと影あり，「0」だと影なしを表すとしよう。ある地点のテクセルが「11001001」だった場合，最下位ビットに対応する時間帯から順に，以下のような遷移を表すことになる。

1	0	0	1	0	0	1	1
影あり	影なし	影なし	影あり	影なし	影なし	影あり	影あり

　指定時刻のDCMは，最も近い時間帯に対応する影LCMから2bit分を選択して，それら2つを算術補間した濃淡値を採用すればいいというわけだ。よくこんな賢い方法を思いつくものである。
　次に示すスライドの下側左に並ぶ4枚の画像は，左からそれぞれ，アルベド，法線ベクトル，深度，影のLCMだ。

事前生成したLCMは，アルベド，法線ベクトル，深度，影の4種類。MRTで一気に生成する

　LCMはアルベド，法線ベクトル，深度，影の4種類なのかというと，それだけではない。ACシャドウズでは，四季の要素があるので，さらに，バリエーションは増加する。
　先述した拡散反射の大局照明と同様に，鏡面反射要素においても，春と夏は1種類にまとめるので，結局，1地点あたり4パラメータ×3季節＝12枚ものLCMを生成することになるのだ。最終的にACシャドウズでは，総数1万6000枚のLCMを用いているとのことだ。

スライド下に並ぶ3枚のLCMは，3つの季節（春夏，秋，冬）のものだ

LCMの季節ごとのバリエーション（LCM seasons）と，朝昼夕夜の時間帯ごとの変化（LCM time of day）

　そもそも，なぜ環境マップテクスチャであるLCMが，画像的なテクスチャでなく，アルベド，法線ベクトル，深度，影という描画に必要な4種類のパラメータになっているのかと，疑問に思った人もいるだろう。逆に，ゲームグラフィックス技術に詳しい人ならば，すでにピンと来ていると思う。これは，Deferred Shadingに用いる「G-Buffer」のフォーマットそのものだ。

　ACシャドウズでは，LCMをキューブ環境マップとして活用する前に，LCM自体をDeferred Shadingで描画する仕様となっているのだ。この斬新なテクニックには，「Relightable Local Cubemaps」（RLCM）という名称が付けられている。
　RLCMでは，LCMをG-Bufferと見なして，Deferred Rendering的にライティングとシェーディングを行ってから，静的光源や動的光源で活用するという。こうしてできたRLCMは，その地点における動的光源や静的光源からの影響を反映した，キューブ環境マップに相当する。
　つまり，RLCMを用いて隣接する3DオブジェクトをIBL方式で描画すれば，事実上，1バウンス分のレイトレーシングを行ったと同等の，鏡面反射や拡散反射の間接光照明が得られることになる。なんとも賢いテクニックだ。

　レイトレーシングで言うところの1バウンス目に相当する描画は，先述したSSRでも表現できなくはない。だが，SSRでは画面外オブジェクトの存在に配慮した描画ができないし，画面内にあるオブジェクトであっても，その背面の影響を反映できないという弱点がある。
　それに対してLCMでは，ゲーム世界の要所要所で生成されているため，LCMが視点から離れた位置にある場合も多い。つまり，視点からは見えないジオメトリの情景も，360度全周囲分を保持している可能性がある。そのためRLCMでは，SSRでは描画できない画面外領域の影響を考慮した表現が可能なのだ。

　なお，さすがのRLCMも，元になるLCMが事前生成されたものであるため，シーン内の動的なオブジェクトは反映できない。そうした要素は，SSRが受け持つという補完関係になりそうだ。

　ちなみに，ACシャドウズにおいて，拡散反射要素と鏡面反射要素のどちらもレイトレーシングで行うのは，PS5 ProのQuality Modeと，ハイエンドPCのみとなっている。
　逆に，PS5 ProのPerformance ModeとPS5，Xbox Series X，ミドルクラス以下のPCにおける間接照明の鏡像生成には，RLCMだけを活用して，レイトレーシングは使わない仕様となっている。

各プラットフォームごとの大局照明ソリューションの違い

ACシャドウズの大局照明（4）〜独自のフォールバックシステム付きレイトレーシングパイプライン

　Lopez氏の講演は多岐にわたったが，本講の最後に，筆者がRLCMの次に驚いた，ACシャドウズのレイトレーシングパイプラインについて解説したい。

ACシャドウズのレイトレーシング技術は，ソフトウェアアプローチと，ハードウェアアプローチを組み合わせている

　Lopez氏によると，ACシャドウズのレイトレーシングパイプラインは，冒頭で紹介したUbisoftのSnowdropエンジンを参考にしたそうだ。
　具体的には，ソフトウェアアプローチのレイトレーシングと，ハードウェアアプローチのレイトレーシングを組み合わせ，対象プラットフォームに応じて，それらを取捨選択して使い分けていくようなパイプラインだ。

　そして，ACシャドウズは，据え置き型ゲーム機やWindows PCだけでなく，Apple Mシリーズ搭載のMacやiPad，Steam Deckにも対応することが前提となったため，独自APIを介して制御するミドルウェアタイプのグラフィックサブシステム（※事実上のグラフィックスエンジン）も開発したという。
　「Fusion」と呼ばれるグラフィックスサブシステムは，Microsoftの「DirectX 12/11」，Appleの「Metal 3」に対応するほか，Steam Deckへの対応を睨んで，Khronosの「Vulkan」にも対応する。やろうと思えば，このFusionを統合することで，他のゲームエンジンからもFusionが使えるようになるようだ。

Fusionの構成。「GraphicsCore」はAPI部分，「GraphicsHal」はその抽象化レイヤーとなり，ここでプラットフォームごとのAPI動作を吸収する。Fusion Halが，実際にグラフィックスドライバに対するコマンド発行などを行う

　ACシャドウズにおいては，Fusionを用いて，レイトレーシングを描画するが，独自のサブシステムを開発するだけあって，かなりユニークな構成になっている。結論から言えば，描画品質よりも描画性能重視の設計，といったところだ。

　まず，レイトレーシングの描画対象となるのは，静的な3Dオブジェクトに限定している。アニメーションする3Dモデルは対象外だ。
　プレイヤーの視点（＝ゲーム内カメラ位置）から発せられるレイは，画面上のピクセルを通って進み，レイトレーシング対象となる3Dシーン内の静的な3Dオブジェクトに衝突する。

レイトレーシングの概念図。図ではレイをロケットのイラストで置き換えている

　一般には，このレイを「プライマリレイ」と呼ぶ。そして，プライマリレイが衝突した場所（≒画面上では各ピクセル）から，描画に必要な情報ごとに「セカンダリレイ」を飛ばすことになる。これがレイトレーシングの基本的な流れだ（関連記事）。
　そして，セカンダリレイの扱いが，ACシャドウズにおけるFusionの特徴的な部分となる。

　最初のセカンダリレイは，BVH（Bounding Volume Hierarchy）化された3Dシーンに対してレイトレーシングを行うのではない。ラスタライズ法で描画するために用意したDeferred Rendering用のG-Bufferに対して，レイトレーシングを行うというのだ。考え方としては，先述のRLCMと似ている。

セカンダリレイは，BVH化した3Dシーンの中を推進せず，画面座標系のG-Bufferの中を推進する。つまり，SSRなどと同じ，2.5D的なレイトレーシングだ

　処理系としては，プライマリレイが衝突したピクセルから飛ばしたセカンダリレイが，G-Buffer上のどこかに衝突したら，そこに描かれている物理ベースレンダリング（Physically Based Rendering）用のパラメータをサンプリングする。

• アルベド（ベースカラー。拡散反射要素）
• メタリック（金属性。特定の色になりやすい要素）
• ラフネス（面の粗さ。鏡面反射要素）
• 法線ベクトル（微細凹凸の向き）

　そのうえで，衝突点に影響を及ぼす光源を選択して，光源ベクトルでライティングとシェーディングを行うという流れだ。
　レイトレーシングとは言っても，画面座標系だけでの処理なので，処理系の精度は，SSRと同等にすぎない。画面外の情景は無視されるし，視点からは見えない3Dオブジェクトの裏面も影響を与えない。

画面内に見えている情景に対するレイトレーシングは，2.5D的なG-Bufferに対して行われる。なんと大胆な！

　だが，レイトレーシング対応と謳っていながら，SSRに毛の生えた程度の描画で終わってしまっては，レイトレーシングの名に傷が付くようなもの。
　そこで，Fusionでは，G-Bufferへの放ったセカンダリレイが，画面外に出てしまったり，あるいは遮蔽物（※3Dオブジェクトの背面も含む）に到達したりしたら，このときだけBVHを活用した，普通のハードウェアレイトレーシングを実行するのだ。
　この処理では，画面座標系ではなく，ゲーム世界まるごとをターゲットにしたワールド座標系なので，画面外の情景や，遮蔽物の向こう側の情景などを反映したレイトレーシングを行える。SSR的なアプローチでは不可能な表現を，この方法で面倒を見るわけだ。よく考えられている。

　ちなみに，ワールド座標系による（普通の）レイトレーシングは，GPUのCompute Shader（≒GPGPU）性能が十分に高ければ，GPU内のレイトレーシングユニットを使わずに，GPGPUによる手法で行うそうだ。フォールバックシステムも用意しているのは，さすがである。

ACシャドウズのレイトレーシングパイプライン。レイトレーシング性能がそれほど高くない据え置き型ゲーム機では，このやり方が最適なのかもしれない

　GPUのレイトレーシング性能が高い場合，拡散反射要素もレイトレーシングで描画する。とはいえ，BVHを活用した，普通のハードウェアレイトレーシングではない。ただ，考え方は，先述のIrradiance Volume法にかなり近い。

　Irradiance Volume法では，各グリッドの頂点で大局照明情報を事前計算で求めていたが，拡散反射要素のレイトレーシングは事前計算ではなく，リアルタイムに行う。
　プレイヤーがいる場所を起点として，大局照明の情報（GI情報）の演算ポイント（Probe，以下 GI情報測定ポイント）は，プレイヤー位置に近いものから2m，4m，8m，16m，32mの5段階とする。
　各段階におけるGI情報測定ポイントは，横幅（W）16個×奥行き（D）16個×高さ（H）8個という構成を取る。そして，プレイヤーがいる位置から離れるに従って，GI情報測定ポイント間の距離を，2倍ずつ離してカスケード状に配置するのだ。

　GI情報測定ポイントの構成を，W 16×D 16×H 8とした場合，Irradiance Volume法のようなグリッドで考えると，プレイヤーに近い位置には，一辺2mのグリッドが8×8×4個並ぶ。一方，一番遠い位置には，一辺32mのグリッドが8×8×4個並ぶことになる。
　W 16×D 16×H 8×5カスケードなので，GI情報測定ポイントの総数は10240個だ。

　この仕組みで，どのようなレイトレーシングを行うのか。結論から言えば，BVHを活用した普通のハードウェアレイトレーシングで行う。ただ，実際にレイを放つ場所は，視点位置からではなく，10240個のGI情報測定ポイントから放つ。
　しかも，求めたいのは視点からの視線に依存しない，拡散反射要素の大局照明情報なので，レイは放射状に複数放つことになる。ここで放ったレイは，3Dシーンを表現したBVHの中を推進し，何らかの3Dオブジェクトを構成するポリゴンに衝突したら，ポリゴンの位置を，直接光でライティングやシェーディングした結果としての色を回収してくるのだ。

　なお，10240個のGI情報測定ポイントを，毎フレームごとに更新するわけではない。1フレームあたりのGI情報測定ポイント数は，1024個に留めているという。つまり，時間方向に分散して1024個ずつ，巡回するように大局照明情報を回収するので，10フレーム分の時間をかけて，10240個すべてのGI情報測定ポイントを更新するわけだ。大局照明，つまり間接照明は淡いものなので，時間方向の更新が若干遅れても，それほど不自然にはならない。そこは妥協するのだ。

　では，ひとつのGI情報測定ポイントから，いくつのレイを放つのか。これについて，Lopez氏は具体的な本数を示さなかったが，筆者の予想では，おそらくローエンドGPUで1桁台，ミドルクラスGPUで2桁台，ハイエンドGPUでは3桁行くか行かないかくらいだと思っている。
　少し多すぎると思うかもしれない。しかし，GI情報測定ポイントが10240個あっても，1フレーム/時間あたりに更新するGI情報測定ポイントは1024個までなので，これくらいが妥当だろうと考える。

　レイトレーシング完了後，各GI情報測定ポイントで求めた全方位のGI情報は，球面調和関数に変換して保持する。
　最終的なシーン映像の描画では，シーン内における描画対象の各3Dオブジェクトの位置から，近いところにあるGI情報測定ポイントを複数選択する。それらのGI情報を線形補間したものを用いて，各3Dオブジェクトのライティングとシェーディングを行うわけだ。

　さて，ACシャドウズのレイトレーシングパイプラインをもう一度見てもらおう。スライド下段中央にある「Irradiance from RT Probe Cascades」のところが，GI情報測定ポイントを使ったレイトレーシングに相当する。

ACシャドウズのレイトレーシングパイプライン（再掲）

　レイトレーシングの結果は，ノイジーな場合があるので，これを平滑化するのが，中段の右から2つめにある「Denoised Result」だ。
　影については，ここまでの描画結果で自動的に求められるはずだが，小さな3Dオブジェクトの接地感や，レイトレーシングの描画対象からは外されている一部のオブジェクト（※背の低い草など）に対する影表現を行うために，レイトレーシングベースのAmbient Occlusion（AO）を求めている。これがスライド下段右の「RT-AO term」の部分だ。これは，物理的な正確さを重視しない，見た目重視のアーティスティック要素を強化するために追加したとのこと。
　スライド上段にある「RT Specular」は，ハイエンドGPUなどで稼動する，レイトレーシングベースの鏡像生成部だ。ここは，BVHを活用した，普通のハードウェアレイトレーシングを行う。

　下のスクリーンショットは，レイトレーシングで描画された要素をひとつずつ追加していったものだ。

拡散反射要素のレイトレーシング結果

レイトレーシングによるAOを加えた状態

画面座標系ポストエフェクトによるAOを加えた状態

最終画像

　3枚目のスクリーンショットが，ゲームファンならばお馴染みの「SSAO」（Screen Space Ambient Occlusion）を適用していることに気付いた人もいるだろう。たしかに，SSAOはレイトレーシングではないし，物理的にも正しくないフェイクの陰影だが，Lopez氏によれば，「センチメートル級の微細な影が出ていたほうが，リアリティが上がるから」という理由で，お化粧的なポストエフェクトとして適用したそうだ。

ACシャドウズの大局照明（5）〜そのほかのテクニック

　Lopez氏が語ったACシャドウズのレイトレーシングにまつわる話題はまだまだあるのだが，ここから先は，残ったテーマをざっくりと解説していく。

　次のスライドは，ACシャドウズでハードウェアレイトレーシングを行うときに不可欠な構造体であるBVHの精度や，LODレベル，そしてハードウェアレイトレーシングにおけるライティングとシェーディングパラメータについてまとめたものだ。

マテリアル系のパラメータは，ラスタライズ法で描画する物理ベースレンダリング（PBR）パラメータとほぼ同じ

　次のスライドは，ハードウェアレイトレーシングで悩ましい問題となる，樹木の取り扱いにまつわるもので，ちょっと興味深い。

　樹木における葉のポリゴンには，葉の画像テクスチャを貼り付けている。葉のテクスチャは，葉の実体となるテクセルと，それ以外の不要部分を透明テクセルで表す。
　シールで表現すると，葉っぱの実体がシール本体で，シール本体の周囲にある枠は，本来なら不要なものだ。不要な部分を描かないために，テクスチャマップ上では透明テクセルで表現するのだが，レイトレーシングにおいては，この透明テクセルを破棄する処理系が余計な処理となる。かといって，おろそかにもできない。

葉や金網のように，実体テクセルと透明テクセルが混在するテクスチャを張り付けるポリゴンは，レイトレーシングで描画するのは面倒だ。この部分の最適化はオープンワールド系ゲームでは必須

　この面倒なテーマについてACシャドウズでは，各ポリゴンに対して，葉のテクスチャ形状をまじめに処理するのではなく，葉のテクスチャの不透明率をもとに，葉ポリゴンを縮小してしまうという荒技で対処したという。
　不透明率は，ポリゴンに適用する葉テクスチャの実体面積÷ポリゴンの全体面積で事前に求めておく。そのため，不透明率が100％を超えることはない。

　ACシャドウズでは，この不透明率を用いて，葉のポリゴンを縮小した樹木モデルで，レイトレーシング用のBVHを構築したそうだ。
　この手法では，たとえば，葉を表現するポリゴンに葉テクスチャを貼ったとして，対象のポリゴンの不透明率が10％だった場合，葉のポリゴンは10分の1に縮小され，そこに余すことなく葉のテクスチャが貼られる。

　この手法だと，葉の形状は完全に無視されてしまう。しかし，放たれたレイから見れば，レイがポリゴンにヒットするかしないかの確率は，葉の形状を考慮した場合と同じ10分の1のままである。だから，ACシャドウズでは，これで良しとしたのだ。
　そうすると，次に示すスライドの右下のように，三角形ばかりのヘンテコな形の葉に対してレイトレーシングが行われてしまう。だが，求めたいのは拡散反射要素のGI情報なので，それらはボヤっとしたものになる。正しい形状に即した葉の描画はラスタライズ法で行うから，十分ごまかせると判断したようだ。面白い手抜き型の最適化である。

不透明テクセルと透明テクセルが混在したテクスチャを適用するポリゴンは，テクスチャの不透明率でポリゴンを縮小した3Dモデルで，レイトレーシング用のBVHを構築する（右下）。レイトレーシング時にテクスチャの形状を考慮しなくて済む

　屋内シーンの間接照明は，屋外で用いた手法と同じだ。事前計算ベースならIrradiance Volume法を使い，ハードウェアレイトレーシングベースならGI情報測定ポイント方式を使う。
　屋内と屋外を分離して処理するのは，粗い近似的な大局照明演算で起こりがちな，ライトリークを防ぐためだ。ここで言うライトリークとは，屋外の間接照明が壁を越えて室内に入ってたり，屋内の間接照明が壁を越えて屋外へ漏れ出したりする現象だ。最近のゲームでも，そうした珍現象を見たことがある人もいるだろう。

屋内シーンの拡散反射要素の間接光もIrradiance Volume法で行う。ただ，GI測定情報は，屋内と屋外で別に管理する

　一方，日本の家屋で特徴的な障子（※プレゼン時はSojiと誤称していた）の表現については，特別な処理を行ったと述べていた。
　透過率は極めて低いが，半透明材質に類する障子は，屋外側のライティング結果を，障子紙の透過率に相当するランダムな低い透過率でフィルタしたうえで，屋内方向に光が透ける素材として処理している。これによって室内を柔らかい間接光で照らすことを実現した。
　同じテクニックは，葉の両面ライティングにも応用しているとのことである。

いわゆる両面ライティングを障子の表現に活用した

　松明や灯籠，提灯などの全方位（Omnidirectional）に自発光する発光体に対するレイトレーシングは，それらを配置した3Dシーンを表現する「Clustered Lights」として処理する方式とした。イメージ的には，「Frustum Clustered Rendering」に近い概念のものだ。

　一般的なタイルベースのDeferred Renderingでは，2Dベースのタイル状態にしてからライティングとシェーディングを行うので，3Dシーン内の奥行き方向に光源数が多くなると，処理効率が悪くなる。たとえば，2D画面上の1ピクセルに対して，複数の光源からのライティングとシェーディングが発生しがちだ。
　これを改善するのが，視錐台の奥行き方向にもタイル（Froxelと呼称する）の概念を導入したFrustum Clustered Renderingだ。ACシャドウズでは，その軽量版として，固定的な2階層グリッドで代行する簡易手法を実装した。
　簡易手法により，遠方にある全方位光源の影響を弱めたり，あるいは破棄したりして描画性能を稼いでいる。動的な光源表現（※移動や発光，消失）にも対応できるそうだ。

3Dタイルベースのレイトレーシング。タイル（グリッド）構造は，高階層（遠方）が4×4×4構成で，下階層（近法）が16×16×16構成となる。トータルでは，プレイヤー位置から視界方向に4^3×16^3=262144グリッドが展開しているイメージだ。全方位光源へのレイトレーシングはこのグリッド単位で行う

　ACシャドウズでは，2階層グリッドにレイトレーシングを行うことで，拡散光の大局照明を求めている。まじめにレイトレーシングを行うのと比べて，10倍もの性能向上が得られたそうだ。
　もちろん，それだけ表現は大ざっぱにはなるが，松明や灯籠，提灯などの輝度的に暗い照明が連なるようにして並ぶ戦国時代のライティング環境を再現するには，バランスの良い手法だったということだろう。
　また，こうした3D版のDeferred Rendering手法は，奥行き方向からの光筋（Light Shaft）表現にもプラスに働くので，導入したとみられる。

　拡散反射要素のレイトレーシング結果を，要素ごとに分解したスライドを示そう。

拡散反射光要素のレイトレーシング結果の生出力

一般的な空間方向と時間方向のデノイザを適用後の出力

輝度（Y）情報を優先したデノイザ適用後。ディテールを復元した

直接光ライティング結果

すべてをミックスした最終画像

　鏡面反射要素におけるレイトレーシングの大枠は，先述した拡散反射光のレイトレーシングと同じだ。視線から放ったレイの反射ベクトルでレイトレーシングを行えばいいので，それほど開発難度は高くなかったと，Lopez氏は振り返っていた。
　しかし，開発の最終盤で行ったこともあって，このことが発売延期の要因になったとも振り返っている。

鏡面反射要素のレイトレーシングは，拡散反射光のレイトレーシングと同じ

拡散反射要素のみのレイトレーシング結果

鏡面反射要素のみのレイトレーシング結果

各プラットフォームごとの描画性能の違い

　かなり長くなった本稿だが，最後に，Lopez氏が公開した，ACシャドウズのグラフィックス性能の話題で締めるとしよう。

　次のスライドは，各プラットフォームごとの映像解像度（Target Resolution）や，間接照明技術をどんなアプローチ（GI Technique）で処理したかを表したものになる。映像解像度（Target Resolution）は，GPUが描画した実際の解像度を示すが，負荷状況に応じては，意図的に描画解像度を下げる制御，いわゆるダイナミックレゾリューションを行う場合があるそうだ。
　横の行は，ゲームオプションで選べる，3つのグラフィック品質モードを表している。

PS5とXbox Series Xが同性能となっている。据え置き型ゲーム機では，PS5 Proが最も高品質なグラフィックスで表示できるようだ

　2枚目のスライドは，各プラットフォームごとに拡散反射要素のレイトレーシング性能を比較したものだ。レイトレーシングとは言っても，GI情報測定ポイント（Probes）ベースの軽量レイトレーシングになる。
　横の行は，各プラットフォームとGI情報測定ポイント数を，縦の列は，各処理系にかかる所要時間を表したものだ。

GI情報測定ポイントによる拡散反射要素のレイトレーシング性能

　PCのGeForce RTX 4080は，PS5 Proの3倍以上も速いように見えるが，GI情報測定ポイントが半分での計測なので，同条件だと1.5倍程度の差があるという感じだろうか。

　次のスライドも，各プラットフォームごとの拡散反射要素のレイトレーシング性能を比較したものだが，1ピクセル単位の，どちらかと言えば近景のレイトレーシング性能比較だ。なお，実際のレイトレーシング解像度は，表にある解像度の縦横半分である。

ハードウェアレイトレーシングを活用した拡散反射要素のレイトレーシング性能。イメージ的には，先述したレイトレーシングパイプラインのDenoised Resultまでの性能となる

　最後のスライドは，各プラットフォームごとの鏡面反射要素のレイトレーシング性能になる。といっても，据え置き型ゲーム機で鏡面反射要素をハードウェアレイトレーシングで処理しているのは，PS5 Proだけなので，PS5 ProとPC（GeForce RTX 4080）のみだ。それ以外の据え置き型ゲーム機では本稿で解説してきたDCM，RLCM，SSRといったフェイクの鏡像表現となる。
　GPUが描画するレイトレーシング映像の解像度は，表中では2560×1440ピクセルとなっているが，実際には，処理負荷軽減のため，横解像度を半分に減らした1280×1440ピクセルとしている。「それでも，品質は十分なものになった」と，Lopez氏は満足しているようだ。

ハードウェアレイトレーシングを活用した鏡面反射要素のレイトレーシング性能

　こちらも，PS5 Proと比較して，GeForce RTX 4080が3倍以上速い結果となった。

　発売前は，ゲームの世界観や歴史考証にまつわる部分でだいぶ混乱した本作だが，結果的にセールスはそれなりに好調であったし，最新技術の導入に積極的な姿勢を見せており，技術的にもとても興味深い作品になっていると思う。
　元々筆者も，本作のゲーム自体にはそれほど興味はなかったのだが，今回のセッションを聴いてから，PC版を購入した。3Dゲームグラフィックスの技術的な側面から見れば，2020年代中期の代表作と言っても過言ではないと思う。

Ubisoft Storeの「アサシン クリード シャドウズ」公式Webページ