『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】 | GameBusiness.jp

『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】

オンラインアクションRPG『ブループロトコル』のセルシェーディング表現の技術的解説。加えて都市描写の軽量化も語られた

ゲーム開発 ビジュアル
『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】
  • 『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】
  • 『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】
  • 『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】
  • 『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】
  • 『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】
  • 『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】
  • 『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】
  • 『BLUE PROTOCOL』アニメ表現はどのように実装されたのか?都市描写の軽量化施策の事例も紹介【CEDEC2021】

2021年もオンライン開催となったCEDEC2021にて、オンラインアクションRPG『BLUE PROTOCOL』のアニメ的表現がどのような処理で行われたか技術的を語る「BLUE PROTOCOLにおけるアニメ表現技法について ~実装編~」のセッションが実施されました。バンダイナムコスタジオのエグゼクティブテクニカルディレクターの大井隆義氏が細部まで本作のアニメ表現を解説したセッションの模様をお届けします。

『BLUE PROTOCOL』とは?

『BLUE PROTOCOL』はバンダイナムコオンラインとバンダイナムコスタジオ共同開発によるオンラインアクションRPGです。Unreal Engine 4で開発しており、昨年2020年4月にクローズドβテストが実施される注目タイトルで、そのアニメ的なビジュアルも国内外から高い注目を集めています。UE4のレンダラーはデファードレンダリングによるPBRで表現されており、ノードベースのエディターでBasePassやPostprocessに限定されているためパス自体を増やすことは難しいとのこと。

デファードレンダリング

デファードレンダリングの描画順を簡潔に説明すると、BasePassでジオメトリの情報を複数のバッファに書き込み、ShadowDepthでシャドウマップを生成し、ライティングを描写→半透明の描き込み→ポストプロセスによってトーンマップのような画像処理を行い表現しています(その他にも細かい処理がある)。なおBasePassでジオメトリの情報を書き込むバッファはG-Bufferと呼ばれています。

UE4におけるセルシェーディングの方法は多く存在するなかでも一般的なものではスライドの通り2種類あります。どちらの方法でもメリット・デメリットの2種類あり、UE4の機能を活用するためエンジンアップデートの影響を受けにくいものの、既存のライティング機能を無効化するためにUE4を活かしきることができません。そのため、大井氏は格闘ゲームなどライティングがほぼ固定されるタイトルでは問題ないのかもと指摘しています。それらはPostProcessマテリアルも同様にUE4を活かしきれないため『BLUE PROTOCOL』ではエンジンを小改造することにしたということです。

ライティング

アーティストが設定する法線はライティングによってアニメのような影が入るよう調整されており、3Dモデルの頬にある三角形のような影が該当します。先のキャラクリエーション講演でも説明されていた通り、アバターのパーツはバラバラであることに加え少しづつインポートするとエッジが立ってしまうために、パーツをまとめてインポートできるようにしています。

BaseColorはオブジェクトの色で、テクスチャを元にいくつかのパラメーターで調整しG-Bufferへ書き込みます。またエッジとの接地感を出すためキャラクターの脚部分が少し暗くしてあるとのこと。ShadowColorは文字通り影となる色で、アニメ表現の一つとして影を表現するときに明度を下げず、微妙に違う色相を使うことがあるために影色を別に保持しています。また、当初は影色のテクスチャを別に用意していたものの、アーティストの作業負荷やキャラクリを考慮し、ベースカラーのテクスチャから変換。服用や肌用のテーブルがそれぞれ分けられています。

髪の色指定は先のルールと異なりBaseColor/ShadowColor共にマテリアルで色を指定。BaseColorからShadowColorを求めない理由では、BaseColorに依存しない色を指定できるようにするためです。NdotLをBasePassで求めるのは、G-Bufferの容量が限られており法線を2つ保持できないためでもあります。

光沢の表現については、髪のハイライトなど特殊な入り方をするものがいくつかあり、マニュアルのノードグラフでバリエーションを表現。スペキュラの色はベースカラーから明度を上げた色を使っています。

シーンカラーは、NdotLの明るい方にBaseColorが、暗い方にShadowColorが適応され、ライティングを合わせたものとして成り立っています。ポイントライトは、普通に計算してしまうと立体感が出てしまうため法線を無視し、ライトとの距離だけで適応。スカイライト&間接光も同様に立体感が出ないように調整しています。リムライトは、モデルの輪郭の太さを均一にするためSobelフィルターによってエッジを抽出し合成することで表現しています。

輪郭線の描画

輪郭線もポストプロセスのような手法を活用して表現。輪郭線のチャンネルはRGBαそれぞれに格納しており、G-Bufferも一つ増やしています。またUE4は頂点カラーを2つ持つことが出来ないためインポート時に、頂点カラー2に設定されている値をTexCoord1へ格納しているとのこと(また、テクスチャにも輪郭線が事前に描き込まれている)。また輪郭線の太さはどの距離でも同じだと違和感があるため、RedチャンネルにはTexCorrd1.xに輪郭線の太さが保持され、入力をカメラやアスペクト比によって調整されています(Greenは内部輪郭用IDが、Blueはテクスチャの描き込みが、Alphaはデプスシフトがそれぞれ書き込まれる)。

輪郭線の抽出方法ですがデプスとID、法線、描き込み(G-Bufferに出力された箇所)の4種類から判定をしています。アニメ表現を行うために輪郭線は重要で、輪郭線ON/OFFの出力結果を見ると、よりハッキリとしたシルエットが浮かび上がっています。

他にも、アニメなどで時折描かれる眉の線がハッキリと描かれる表現も眉の輪郭線も描画。このため髪のBasePassをToonHairPassの二つに別け、Lightingとの間に挿入。BasePassで髪以外を描画し眉部分をマスク、続いてToonHairPassで髪を描画し、眉でマスクされている箇所の内部輪郭用IDを更新しないことで眉が強調されます。

輪郭線IDが残っているため、眉に輪郭線が現れている

しかしながらTemporalAAを使用すると輪郭線が溶けてしまう問題が発生(1ピクセルほど溶けてしまうことがある)。そのため、輪郭線をステンシルに描き込み、ResponsiveAAを利用しています。

影の描画方法

セルシェーディングされた箇所はシャドウマップによるセルフシャドウは受けません。なぜなら、シャドウマップによるセルフシャドウは解像度が足りないと綺麗に影が落ちないことや、陰影の影部分はシャドウカラーによって色が明るめに設定されるため、完全に暗くなる場所が無いためです。そのため、トゥーンか否かでシャドウマップを使い別け、オフセットシャドウを導入しました。

最後のポストプロセスでは、アニメなどでも使われる光の拡散手法のデフュージョンを適応させています。

まとめ

G-Bufferやパスのまとめなどを披露。またアニメ表現はフォトリアルより描画が軽いのかという印象に対し、フォトリアル用の機能であっても有用な物は積極的に利用するため、「どちらかと言えば普通に使うより重くなっているのではないか?」と言及しました。現在開発中であるため、今後実装が変わる可能性があるとのこと(今回のセッションためまとめたら気になった部分があったそう)。アニメ表現にはアーティストのこだわりがあり、エンジニアとしてどうやって実現するかが大切です。

G-BufferEは以前使っていたものの、現在では使っていないそう

おまけ: 背景のはなし

ここでセッションの内容自体は終了しましたが、時間が余ったために本作の背景(マップ)についての言及がありました。ユーザーが最初に訪れる交易都市アステルリーズの映像を披露。開発当初から着手し、レギュレーションもまとまらない中から仕様変更と共に増改築を繰り返したとのこと。

開発スタッフも大規模なマップを開発した経験が無かった事に加え、タイムスタンプを確認したところ2017年から着手していたよう。そのため、入り組んだ街の作りをみると歴史を感じるそうです。木はFoliage、草はGrassで配置しているため多く配置しても軽く動くそうですが、それ以外はアクターが大量に存在するため処理負荷が重く、CPU/GPU負荷も、メモリも厳しいために対策を取る必要がありました。

まずDirectX12への対応です。UE4におけるDirectX12が安定し、描画スレッドのCPU負荷はそれなりに改善しましたがDirectX11の存在も無視できません(Windows8.1へのサポートもある)。またアクターのマージも考えられましたが(オブジェクトを合体させて少なくすればCPU負荷を下げられる)、オブジェクトの数が大量で手作業でやるにも多すぎることや、元に戻せず今後の増改築も予想すると難しいとなったとのこと。

インスタンス化も考えられましたがアクターのマージと同様の問題もあり断念。UE4的に最も高度なアプローチとして、HLODが一番良い方法であると思っていましたが開発当時として新しい技術あったことから検証も出来なく、結局他の方法を模索しました。

そこでインスタンス化ツールの作成と、増改築を考慮した逆変換も同時に作ることになりました。Instanced Static MeshとHierarchical Instanced Static Mesh2種類のインスタンスを考慮し、インスタンス化ツールを開発。このツールを使用した結果、アクター数が半分以下となったことで60fpsが出るようになり解決しました。以降、短時間のQ&Aを実施しセッションを締めました。

アニメ表現についての技術側からのアプローチとして、様々なフィルターを用いてセルアニメな見た目を実現している『BLUE PROTOCOL』。特に筆者が興味深かったのはついでとして語られた都市描写に関する技術的な内容でした。DirectX12対応など様々な方法を模索・対策できたことで、60fpsでの動作という副産物を生んだのかと思えます。本作の正式サービスについては現時点でも告知されていませんが、プレイヤーとしても続報を期待したいタイトルですね。

《G.Suzuki》

この記事の感想は?

  • いいね
  • 大好き
  • 驚いた
  • つまらない
  • かなしい

関連ニュース

特集

人気ニュースランキングや特集をお届け…メルマガ会員はこちら