2021年8月24日（火）～26日（木）の3日間に渡り、オンライン開催されたCEDEC 2021。
8月25日にはバンダイナムコスタジオの『ブループロトコル』エグゼクティブテクニカルディレクター・大井隆義氏による講演“BLUE PROTOCOLにおけるアニメ表現技法について ～実装編～”が行われた。その内容をリポートする。
昨今はゲームエンジンの進歩により、オブジェクトの描画はよりリアルに近付けられるようになった。そんな中、『ブループロトコル』はアニメ表現にとことんこだわっている。一見するとリアルな描写よりもアニメ表現は簡易に見えるが、むしろリアル描写よりもこだわりが多いようだ。
今回の講演では、ライティングを始めとするさまざまなアプローチと、それを実際のレンダリング過程でどのように盛り込んでいくのか、一連の流れが紹介された。
なお、CEDEC 2021の初日にはアニメ表現のノウハウや苦労がキャラクター描画の視点から語られている。こちらも併せてご参照いただきたい。
デファードレンダリングの基礎構造を振り返る
『ブループロトコル』は、バンダイナムコオンラインとバンダイナムコスタジオで共同開発中のオンラインアクションRPGだ。2020年4月にはクローズドβテストも実施され、好評を博した。
現段階では開発に“Unreal Engine4”の最新バージョン4.26を使用している。昨年のCEDEC 2020でも、アートスタイルや背景などの担当者が講演でこだわりが語られたが、今回はキャラクターのレンダリングを中心に実装内容を解説していくという。
Unreal Engine4のレンダラーは、デファードレンダリングによるPBR（物理ベースレンダリング）だ。つまり、2次元の平面的なスクリーン上で複数段階の処理（パス）を重ねていく方式で、そこに物理法則処理が重なるようになっている。
描画の対象物はノードベースエディタで多彩にカスタマイズできる。だが、その処理が可能なのは基本的なパス内に限られており、パス自体を増やすことは難しい。
まずはデファードレンダリングを例に、重要なパスのみを大まかに追ってみよう。最初は基本となる“BasePass”の複数のバッファに情報を書き込み、“ShadowDepth”パスでシャドウマップを生成。
それらの情報をもとに“Lighting”パスで照明による効果や影の生成が行なわれ、“Translucency”パスで半透明関連の情報を書き込み、“PostProcess”パスでさまざまな効果を加えることでレンダリングが完了する。
このうちBasePassで情報を書き込むバッファは“G-Buffer”と呼ばれる。エンジンによって書き込まれる情報は異なり、Unreal Engine4では世界単位の法線（そこが物体の表面であることを表す線）、金属質であったりや鏡のようであったりなどといった質感のパラメーター、物体の色などがここに含まれる。
ShadoｗDepthパスでは、光源からオブジェクトまでの距離を表すシャドウマップが書き込まれる。この情報と、BasePassのG-BufferをもとにLightingパスで実際のライティングが行なわれる。これが動的な光源の数だけくり返され、続くTranslucencyパスで半透明オブジェクトを描画する。
デファードレンダリングは、端的に言うと半透明オブジェクトの描画が苦手。シーンの描画結果にブレンドしていく必要があるため、このように最後のほうで反映するわけだ。
ゲーム開発のためには、このプロセスに改良を加えていく。まず一般的なセルシェーディング（3Dオブジェクトをアニメ調に表現する技法）の方法としては、“Surfaceマテリアル”と“PostProcessマテリアル”を使用するものがすでに多く出回っている。
Surfaceマテリアルの場合、Unreal Engine4自体のライティング機能をオフにし、マテリアル自体のライティングを反映する。PostProcessでは、ライティング自体はUnreal Engine4で行ない、その結果にエフェクトをかけていく。
どちらの方法にも、メリットとデメリットがある。いずれもUnreal Engine4自体の改造はしないためエンジンのアップデートによる影響が少ないが、Surfaceだと機能をオフにする時点でUnreal Engine4が持つ豊富な機能を使用できなくなる。
格闘ゲームのような限られた空間でライティングがほぼ固定されるタイトルなら問題ないと思われるが、『ブループロトコル』のような広大な空間を扱うタイトルには不向きだ。
PostProcessの場合、見方にもよるがせっかく出た描画の結果を塗りつぶすことにもなりかねない。Unreal Engine4の機能を活かしきれない場面が出てしまう懸念がある。
これらを解決するために、『ブループロトコル』では最小限のエンジン改造を実施したという。
ライティングのこだわりを実現するための改造
まずはライティングについてだ。『ブループロトコル』のライティング情報のメッシュ（※）には、アーティストがツールから設定した法線と、インポートした際に物理計算から算出されて決まる法線という、ふたつの法線が保持されている。
※メッシュ：線を組み合わせて網状に表現されたオブジェクト形式。表面のカラー情報や接触判定の情報などを流動的に管理できる。
また、ライティングの際に暗く見えにくくするための“Diccuse Offset”や、暗く見せるための“Ambient Occlusion”などの値が“頂点カラー”（※）の情報として書き込まれている。
※頂点カラー：メッシュの頂点に登録できる色情報。これをもとに、メッシュ各所の面の色や影などが反映される。
アーティストが設定した法線は、ライティングによってアニメ調の影が入るように作られている。これにより、キャラクターの頬の三角形の影など、アニメ表現ならではの独特な影が入るわけだ。
アーティストに設定してもらう法線は陰影を重視。物質形状を無視しているため、インポート時の法線には物理法線を面法線から計算した結果を書き加えている。
本作のアバターはいくつかのパーツの組み合わせでできているため、メッシュもパーツごとにバラバラだ。そのままインポートすると、隣り合うパーツの三角形どうしが判定の齟齬を起こし、エッジが立ってしまう。このパーツごとの法線をつなげて判定するために、一括インポートする仕様も取り入れている。
レンダリングの最初の段階となるBasePass部分にも、ライティングに関わる情報がG-Bufferとして複数書き込まれている。その中でもキーとなるものが、以下の5点だ。
BaseColor（明るいところの色）
オブジェクトの色として、テクスチャーをもとに書き込まれたG-Buffer。よく見ると少し暗くなっている部分がある（キャラクターの足部分など）。ライティング時に地面との接地感などを出すための処理だ。このように、色情報の段階から特殊な処理が施されたオブジェクトも存在する。
ShadowColor（暗いところの色）
ライティングによって暗くなる部分の色指定をするG-Buffer。アニメ風に陰影を表現するために、単にBaseColorの明度を下げたものではなく、微妙に色相を変えるケースが多い。本作でも影色は別に保持されている。
開発当初は影色のテクスチャーを別に用意していたが、アーティストへの負担やキャラクタークリエイション（近付いてきた別キャラクターをプレイヤーが見ている画面内に描画すること）の負荷を考え、BaseColorのテクスチャーから変換させて補うことにした。
こちらの処理では、色相を10段階に分けたインデックスから算出して数値化、変化分をさらに数値化して加算し、結果を出す。明度と彩度は輝度を8段階インデックスに分け、それぞれ変化分を加算。このふたつのインデックステーブルの計算結果を反映し、RGBに戻すことで最終的な色が決定する。
このテーブルは服用や肌用などに分類。たとえば肌についてはやや赤みがかった結果が出るという。
なお、髪色はBaseColorとShadowColorの両方を使い、マテリアルごとに色を指定している。ShadowColorがBaseColorに一切依存していないため、まったく関係ない色を指定したりと、よりアニメ調の表現に近付けることができる。
NdotL（光源を受けた際の明るさ）
NdotLは主光源との距離とアーティストが設定した法線の内積をもとに、BasePassの段階で求める。また、G-Bufferとしてインポート時に計算されるCompute Normalを格納し、形状面を優先。
ライティングやポストプロセスなど、この段階以降のパスでNdotLの処理を行なってみると、角度によってはきれいな陰影が生まれなかったという。問題はG-Bufferの精度。とはいえ、陰影をコントロールするパラメーターすべてをG-Bufferに乗せることはできない。
そもそもアニメ表現はリアルとは異なる。複数の光源からそれぞれ陰影が生まれるのはおかしいのだ。このため、本作では主光源からのみ陰影を求めることとなった。
SpecularMask（主光源に対する、鏡のような反射率の設定）
ライティングに対するスペキュラーによるハイライトの設定もBasePassで行なっている。特殊な反映が必要なこともあるため、マニュアルのノードグラフでバリエーションを出している。
スペキュラーとしては“Blinn-Phong反射モデル”で求めた結果を2値化し、それをスペキュラーマップに掛け合わせたものが反映される。こうしてキャラクターの太ももなどに発生した反射が、G-Bufferに書き込まれる。
髪のスペキュラーはさらに特殊だ。カメラ視点の端に行くほど大きく、中心に近いほど小さくなる。アーティストが用意したマスク画像を多機能な画像処理ライブラリ“OpenCV”で解析し、各ハイライトの重心からの距離を設定。その重心をもとに拡大・縮小処理を行なうわけだが、ハイライトがはみ出ないようにIDで設定も行なっている。
SpecularValue（スペキュラーの明度設定）
スペキュラーにはBaseColorから明度を上げた色が使用される。SpecularValueには明度をどれくらい上げるかの値が入っており、暗く見える部分は明度上昇を抑え、明るい部分は明度が大きく上がるように設定されている。
これらBasePassの段階での設定に続いて、Lightingパスで光源が当てられ、G-Bufferによって設定された結果が反映されていく。このLightingによってシーンに描画されるのが“SceneColor”だ。
ディレクショナルライト（その場面に合わせた主光源）による陰影の計算は、すでにBasePassの時点で終わっているので、あとは結果が反映されるのみ。NdotLで作成されたマップの中で、白い部分にBaseColorが、黒い部分にShadowColorが適用される。そこにライトの強度などが掛け合わさり、ライティングの結果が出る。
スペキュラーも同様で、ここでの処理はシンプルだ。SpecularValueをBaseColorの明度に加算して色を決め、SpecularMaskで指定した箇所に適用していく。
このように、ディレクショナルライトのライテイングについては、G-Bufferで求めていた情報にライトを適用するだけで完成するわけだ。
あわせて、ほかのライトの処理も行なわれる。ポイントライトをふつうに使うと余計な立体感が出てしまうため、法線を無視した距離のみから陰影を計算し、グラデーションをかけたような見た目にする。
ただし、このままでは明るくなりすぎるため、トゥーン用の調整パラメーターを設けたという。
スカイライトや間接光などの別光源についても、そのまま適用するとアニメ表現らしからぬ立体感が出てしまう。そこで法線をすべてキャラの真上として処理し、こちらも調整パラメーターを付け加えた。
こちらのパラメーターでは光の色などについても設定可能で、空の青い光のせいでキャラが青みがかって見えてしまったり、キャラが背景の色になじみすぎるといった問題を解決できる。
リムライト（半逆光。髪などの細かな部分のディテールを強調する）で輪郭を明るくする処理にも工夫がある。このときキャラは2D的に見えてほしいため、輪郭線の太さが均一に見えるようにプロセスを加えているのだ。
このための情報も、BasePassのG-Bufferにふたつ含まれている。
このうち“RimLightMask”はリムライトの入りやすさをテクスチャー各部にパラメーターで設定し、“RimLightWidth”は各部のリムライトの太さを指定している。
この結果が反映されるのは、Lightingパスのつぎに追加した“PostRimLight”パスの段階でのことだ。ライティングの一種ということで、このタイミングに適用している。
実際のパス内では、まず“Sobel”というフィルターで隣り合う画素の差からX方向とY方向のエッジを抽出し、ふたつを加算して平滑化する。これにより輪郭の結果を抽出し、その結果はさらにRimLightWidthにもとづいてサンプリングして調整することができる。
その結果にRimLightMaskを当てはめ、光ってほしくない部分をマスクしたあと、スペキュラーカラーと同じ値で光る部分の処理がされていく。
キャラの存在を際立たせる、輪郭線の工程
本作では輪郭線についても、一部はポストプロセスのような手法を使って描画している。その情報は輪郭線のメッシュにまとめられており、頂点カラーの各チャンネルに必要な情報を入れている。
まず頂点カラー1（Green）には、デプスシフトの情報が入っている。これはデプス（該当部位のカメラから見た深度）による輪郭線の変化に使用するパラメーターだ。
頂点カラー2（Red、Green）では、Xに輪郭線の太さを、Yに内部輪郭線のためのIDを設定している。なお、Unreal Engine4ではふたつの頂点カラーを持たせることができないので、こちらはインポート時にコピーして格納するようにしている。
また、この頂点情報とは別に、テクスチャーの中にもラインをざっくりと書き込んだものが含まれている。
さらにBasePassの中にも、輪郭線を設定するためのG-Bufferがひとつ含有。そのG-BufferのRGBA（Red・Green・Blue・Alpha）の4つのチャンネルには、それぞれ以下の設定が格納されている。
Red：輪郭線の太さ
輪郭線の描画はポストプロセスで行なわれるため、調整しないとすべて同じ太さに。キャラが遠くにいても太いままだと不自然に見えてしまう。このチャンネルでは保持された輪郭線の太さをカメラからの距離やアスペクト比に従って調整し、カメラの中心に近いほど太く、遠いほど細くする。
Green：内部輪郭線用のID
メッシュの頂点情報の頂点カラー2の部分で格納された値がそのまま入力される。
Blue：描きこみ
テクスチャーに描き込まれた輪郭ラインに加えて輪郭モデルも書き込む。特定の部分に対して、色関連のオーバーハング（上層と下層の入れ違い）が起きないようにするためだ。
Alphe：デプスシフト
こちらのチャンネルには、頂点カラーに格納されたデプスシフトの値が入力される。デプスに従って輪郭を抽出し、それに反転やパラメーターによる調整を加えた最終値を算出する。
G-Bufferの準備ができたところで、やっと輪郭線の抽出に入れるようになる。そのためのパスはLightingの後、Translucencyの前に追加される。
Translucencyパスでは半透明処理により屈折が起こって輪郭線がずれてしまうため、その処理の前に行なわなくてはならないわけだ。この順番だと半透明オブジェクトには輪郭線が描けないという問題が出てくるが、いまの開発段階ではそれが問題になるケースはまだ出てきていないとのこと。
輪郭線を描くための処理方法もいくつか用意されている。デプスによる処理では、ライトの際にも使ったSobelフィルターによるふたつの値を参照し、大きな値（モデルの外側）のほうに輪郭線を引く。
このとき小さな値（内側）に線を引くと、少しやせたように見えたり、挙動のうえで矛盾が生じる場合もある。また、デプスシフトの値によって顔などの部位には余計な線が描かれにくくなっている。
また、IDによって判定して線を引く場合も、Sobelフィルターで求めた値のうち大きいほうに輪郭線を引くようになっている。
法線による判定で、線を引く処理方法もある。これは法線の内積で線を引く箇所を求めるため、デプスの差が少なかったり、IDを分けられないほど細かな部分に対して使用される。指の境目などが代表例だ。
また、G-Bufferに描き込まれたテクスチャーの線と輪郭モデルから算出された線を、そのまま輪郭線とするケースもある。
この4つの方法によって輪郭線が抽出される。アニメ表現では輪郭線はとても重要なので、多少煩雑になったとしても、狙った箇所に狙った輪郭線が引かれるようにしないといけない。適度な輪郭線で、キャラクターの描画がより引き締まる。
特殊な輪郭線として、眉の輪郭線が髪の上にかかるケースがある。アニメなどではおなじみの、表情をわかりやすくするための手法だ。
本作ではこの処理を、髪が眉を透かしているという形で行なっている。そのため、髪の描画をBasePassとは異なる“ToonHairPass”というパスに分けている。
このため、BasePassで描画されるのは髪以外の部分となり、なかなかショッキングな見た目となる。この段階で眉の部分のマテリアルを分け、マスクを取っておく。
続いて、ToonHairPassで髪を描画するのだが、このとき眉のマスクされている部分は内部輪郭用IDを更新しない。これにより、髪に重なっている判定であっても、ポストプロセスの段階で眉に輪郭線が引かれることになる。
こういった輪郭線を処理するうえで問題も発生した。当初採用していた“TemporalAA”というアンチエイリアス（画像のギザギザなどを滑らかにする処理）により、輪郭線が溶けてしまったのだ。
下画像を比べてみると、袖付近などで輪郭線が消えているのがわかる。
TemporalAAは複数フレームを合成することで効果を実現する。ほかのアンチエイリアスを使用する案もあったが、こちらが高性能なため、できればそのまま使いたいというのが主流の意見だった。
この問題を解決するために“ResponsiveAA”を利用した。Unreal Engine4に実装されている機能で、特定の条件（動いている状態など）でアンチエイリアスがかからなくなるように設定できるというものだ。輪郭線をステンシル（ピクセル単位で描画の有無を指示する手法）として描き込むことで、ResponsiveAAの処理を働かせたのだ。
影とトゥーンレンダリングの関係にもこだわりが！
トゥーンレンダリングされた箇所は、自身によるセルフシャドウの影響を受けないようになっている。シャドウマップによって発生させられるセルフシャドウは、解像度次第ではあまりきれいにならない。陰影部分のカラーは設定次第で明るめになるため、完全に暗くなる箇所がなく、色の汚れが目立つケースもあったのだ。
そこで本作ではシャドウマップをふたつ用意。トゥーン処理されたマテリアルか否かで使い分けている。
“背景用シャドウマップ”ではキャラクターは描画されない。ここで発生した別オブジェクトの影はキャラクターにもかかるため、キャラクターが建物に入ったときなどには正しく影が差し、暗く表示されるようになる。
逆に“キャラクター用シャドウマップ”にはキャラクターしか描画されない。ここで発生した影は背景などには反映されるが、キャラクター生成時にはキャラクター自身に影を落とすことはない。
このふたつを重ねることで、背景の影とキャラクターの影が重なる部分はしっかりと濃い影になる。
キャラクターにはセルフシャドウがかからない代わりに、情報量を増やすためにオフセット処理で影をかけている。これにより、着ている服の影が足に表示されるなどの描写ができるわけだ。
この処理には、影を落とす対象のデプスを設定する“OffsetShadowDepth”と、その設定によってG-Bufferを書き換える“OffsetShadowMerge”というふたつのパスを追加している。
最後におまけと言いつつ、興味深いプロセスが……
キャラクターのアニメ表現に特化したポストプロセスのひとつとして“ディフュージョン”が紹介された。これはアニメなどでよく使われるフィルターの一種。全体的にぼやけた印象を与えることで、リッチな表現を生み出すものだ。
既存のブルーム演出などでも同じような効果が出せるが、ブルームでこの効果を出すには閾（しきい）値を下げることになるため、同時にブルームをエフェクトとして使用することができなくなってしまう。そのため、ブルームとは別の効果としてディフュージョンを用意している。
『ブループロトコル』のアニメ表現のために使用されているG-Bufferは、個別に紹介したものだけでもかなりの数となる。レイアウトを整理すると下図のようになっており、ほぼすべてのチャンネルを、なんらかのG-Bufferで使っている状態だ。
さらにBasePass以外の部分でも、さまざまなパスで改良を実施。これらは既存のUnreal Engine4の機能と共存できるように追加されている。
「アニメ表現ってフォトリアルよりも描画が軽いんじゃない？」といった声もよく挙がるが、フォトリアル用の機能も有用なら積極的に利用していくため、むしろアニメ表現のほうが処理が重くなる場面も多いという。
講演の最後のまとめでは、「むしろ講演のために資料をまとめるうちに気になる点が出てきた」など、今後の変更の可能性が高いと思われる発言も。
大井氏は、技術的には目新しいものを使っていない分、アニメ表現には細かいこだわりと手法が大事であると総括。アップデートが多少しんどくてもエンジンソースを直接いじったり、レイトレースなどの新技術を試したりも、そうしたこだわりの一環なのだろう。
……と、ここで講演は終了かと思いきや、時間が少し余ることを見越して用意したという、おまけの講演がスタートした。
“交易都市アステルリーズ”における背景の最適化
追加されたのは、開発当初から増改築を繰り返している街“交易都市アステルリーズ”で使用している背景の最適化手法について。
アステルリーズの描画において、木や草についてはUnreal Engine4の機能をそのまま使っており、大量に配置しても軽量な動作を保てる。ただし、建物や岩といったアクター（背景に配置されるオブジェクトの単位）は2万個を超え、そこに配置されたメッシュアセットは約2700にも及ぶ。このままでは負荷があまりにも重い。
お手軽な対策として、まずは“DirectX12”の使用をデフォルトに設定した。これにより、並列処理機能でCPU負荷を改善できた。ただし、Windows 8.1のサービスがまだ続いていることもあり、DirectX11を無視するわけにもいかない。
では、テーブルや椅子といったアクターをひとまとめにマージ化して、ひとつのオブジェクトとして扱うのはどうだろうか。アステルリーズの規模まで巨大化した街では、手動でのマージ化作業はあまりにたいへんだ。今後も増改築が予想されるため、もとに戻せない点も問題となる。
同じアクターを位置だけ変えて複数一気に描画する（複数あるように見えても、データ的にはひとつしかない扱いになる）という、インスタンス化はどうだろうか。だが、これにもマージ化と同じ問題があった。
最適な方法に思えたのは“Hierarchical Level of Detail”（HLOD）。表示距離が遠いアクターをひとまとめにして、ひとつのアクターとして処理できる機能を使う方法だ。
しかし、開発初期の当時はまだ新しい機能だったためスタッフも不慣れで、設定項目も多く時間がかかってしまった。ほかの方法を模索することに。
結果として、いちばん負荷を減らせる見込みがあったインスタンス化を選択。実行するためのツールを新開発した。ある程度のインスタンス化のためのルールを設け、増改築を見越してもとに戻す機能も用意した。
インスタンス化には先ほど触れた“Hierarchical Level of Detail”を使用する“HierarchicalStaticMesh”と、“InstancedStaticMesh”のふたつの方法がある。
InstancedStaticMeshは、一定のまとまった範囲でアクターがひとつにまとめられ、LODなどの判定がされる。カリング（不要な情報を選択し除去する機能）については全体、かつ並列で処理される。
HierarchicalStaticMeshは、すべてのアクターをまとめたうえで空間を分割し、階層化していく。分割された空間単位ではカリングが並列処理されないが、同じ空間内のものは並列でカリングされる。
一見すると並列処理がされにくく見えるので処理が遅そうだが、インスタンス化されたアクターが大量にあるほど、十分な処理速度が出るという。
機能としてはこちらのほうが優秀なのだが、インスタンスが少ししかない場合は並列処理が起きないため、逆にCPU負荷が上がってしまう。それを踏まえてツールを作成することとなった。
まずはインスタンス化できるものを集めつつ、インスタンス化できないものを省いていく。そしてどちらのStaticMeshを適用するかを判定する基準として、数が多いものをHierarchicalStaticMeshで処理するようにしつつ、ライトマップの解像度に収まる上限を定めた。
残りのアクターに対しては、一定範囲ごとにまとめてInstancedStaticMeshを適用。ある程度の範囲ごとに分けないとLODやカリングが適用されないので、k-mean法に基づき、半径2000（20m）に収まるように設定した。
また、インスタンス化したメッシュにはパラメーターをコピーするようにした。変更するパラメーターを制限したことで、メッシュ単体に戻すことも容易になった。
このツールの適用により、アクター数は半分以下の8000に収まったとのことだ。
講演は以上で終了となった。最後はおまけと言いつつも、本講演と同じくらい濃い内容になっていたように思える。
今後『ブループロトコル』をプレイする機会が訪れた際には、街のNPCやテーブルなどの存在に対しても、ぜひその工夫を思い返しながらじっくり観察してみたいものだ。
※本記事の画像は配信画面をキャプチャーしたものです。
