プロ野球スピリッツシリーズにおける観客ボーンウェイトモデルの多量描画について | Unreal Fest Tokyo 2025

プロ野球スピリッツシリーズにおける 観客ボーンウェイトモデルの多量描画について 株式会社コナミデジタルエンタテインメント ©Konami Digital Entertainment #unrealfest

本日の内容 基本的にはプロ野球スピリッツシリーズでの観客実装に関する事例報告ですが、今後の作品 に向けての研究内容が含まれています。 実装開始当初のエンジンバージョンは4.27を使用していましたが、今回発表する内容はバー ジョン5.5で動作を確認しています。 最後にモバイル対応に関する現状報告と今後の展望に関して軽く触れます。 2 #unrealfest

自己紹介 高橋 芳明 / シニアプログラマー 観客多人数描画において、GPUベースのカリング処理・モーション計算、関連ツール実装、データ変換フロー の構築、最適化を担当。現在はモバイル対応にも取り組んでいます。 松岡 志津 / デザイナー 観客モデルの制作ではモデリングやワークフロー構築、量産体制に向けたツール整備などを担当。 その他、野球選手の顔モデル制作やフォトスキャン撮影にも携わっています。 南 雄之 / プログラマー 観客の行動設計、試合の盛り上がりシミュレーションなど観客演出に関わる様々な業務を担当。 デザイナ、プログラマが使うデバッグ機能の設計実装にも携わる。 3 #unrealfest

観客の進化で求められたもの(1) 観客表現の不自然さを解消したい ── モデルバリエーションの拡充による自然な群衆表現の実現へ 観客が同じ見た目ばかりだとリアリティが損なわれる。 スタジアムでは観客が密集して並ぶため、同じモデルが隣接すると「クローン感」が生じや すい。 さらに応援席ではレプリカユニフォーム着用者が集中する傾向があり、配置の偏りも違和感 の原因となる。 これらを解消するには、モデルの種類を増やして多様性を確保する必要がある。 4 #unrealfest

観客の進化で求められたもの(2) 観客の動きにもっとリアリティを持たせたい ── モーションバリエーションの拡充による状況反映の実現へ 年齢や性別に応じた動きだけでなく、試合展開（得点、ピンチ、盛り上がり）に応じて観客 の反応を変えたい。 そのためには、多様なモーションを用意し、観客の属性と状況に応じて適切な動作を選択・ 切り替える仕組みが必要。 5 #unrealfest

観客の進化で求められたもの(3) 応援スタイルの多様性を表現したい ── 持ち物の切り替えによる応援表現の強化へ メガホンや旗など、実際の球場で使われる応援グッズをゲーム内でも再現したい。 応援グッズは観客の応援スタイルや文化を象徴する要素であり、持ち物の違いによって応援 の個性と臨場感を高めることができる。 6 #unrealfest

観客の進化で求められたもの(4) 観客の動きをもっと自然にしたい ── 個別制御による群衆のリアリティ向上へ 座席移動や売店への移動など、観客一人ひとりの動きを自然に見せたい。 群衆を一括で動かすと不自然になりがちなので、個別制御によって独立した行動を実現する。 また、手拍子などの集団動作も、数フレームのズレを加えることで自然な揃い方を演出でき る。 7 #unrealfest

技術的に求められたこと 観客表現に割けるリソースには限りがある ── 演算資源の制約下で成立させる観客表現の工夫が必要 野球ゲームにおいて主役は選手であり、観客は演出要素のひとつ。 CPUやGPUなどの演算資源を観客表現に過剰に割くことはできない。 限られたリソースの中で、自然で多様な観客表現を成立させるためには、描画負荷や制御コ ストを抑える工夫が不可欠となる。 8 #unrealfest

一般社団法人日本野球機構承認 および プロ野球フランチャイズ球場公認 9 #unrealfest

観客モデルについて 概要 ● モデル仕様について ▪ モデルの種類 ▪ モデル構造 ▪ バリエーション生成 ▪ マテリアル仕様 ● モデル確認について ▪ 確認環境の紹介など 10 #unrealfest

モデル仕様 種類 ● 制作モデル数 189体 ● 観客の多様性を実現するため様々な年齢層・属性を持ったモデルを用意した ▪ 応援客（レプリカユニフォーム着用） ▪ 一般客（私服や雨合羽着用） ▪ 高校野球用の観客（高校生モデル、バックネット裏の少年野球チームの子供） ▪ 球場スタッフ（売り子、ガードマン等） ▪ 外国人（国際試合用） ▪ その他 一般社団法人日本野球機構承認 11 #unrealfest

モデル仕様 メッシュ ● 1体の頂点数 7000～8000程度 ● 描画効率を高めるため、人体と全ての小物を1 つのメッシュにまとめている ● 頂点カラーに、各小物の表示制御に使用する オブジェクトIDを埋め込んでいる 12 #unrealfest

モデル仕様 ボーン ● 1体のボーン数と構成は全モデル共通 ボーン数 78個 ▪ 人体の基本部分用（緑のボーン） ▪ 表情用（赤のボーン） ▪ 髪や小物の制御用（紺のボーン） ● 身長を数種類用意 身長ごとにジョイントの位置が異なる ▪ 男性 ▪ 女性 ▪ 子供 ３種類 ２種類 ２種類 13 #unrealfest

モデル仕様 バリエーション生成 同じ観客が繰り返し出ている印象を軽減するため、1体のモデルから色違いなどのバリエー ションを生成。 ● バリエーション対応のため、モデルのUVを3種類用意 ▪ UV1：ベーステクスチャ用 ▪ UV2：服装や髪の色替えテクスチャ用 ▪ UV3：小物の模様替えテクスチャ用 14 #unrealfest

モデル仕様 バリエーション生成 ● ベーステクスチャ ▪ ベースカラー ▪ ノーマルマップ ▪ ORM（オクルージョン、ラフネス、メタリック） UV ベースカラー ノーマルマップ ORM 15 #unrealfest

モデル仕様 バリエーション生成 ● パーツごとに色を乗算するためのUVとテクスチャ UV 色指定テクスチャ ● 1体につき生成できるカラーバリエーションの例 （最大32パターン） 16 #unrealfest

モデル仕様 バリエーション生成 ● 小物の模様替えをするためのUVとテクスチャ UV 一般社団法人日本野球機構承認 球団ごとの小物の図柄をまとめたテクスチャ 17 #unrealfest

モデル仕様 マテリアル ● 親マテリアルは観客全体で１つ ▪ 一般客、応援客などのモデルグループごとにマテリアルインスタンスを作成。 ● 色替えテクスチャの合成 ▪ UVオフセット値はモデルインスタンスごとにランダム。 ▪ ベーステクスチャに乗算。 ● 模様替えテクスチャの合成 ▪ UVオフセット値をパラメータ化。 プログラム側で試合状況や再生モーションに応じて操作。 ▪ ベーステクスチャとLerp（線形補間）を使ってブレンド。 18 #unrealfest

モデル確認 ● 観客に適した確認環境を整備 ▪ 実行中でもエディタ上で任意の状態の観客を表示可能。 小物やプラカードの内容、LODの適応距離、指定した単一のモーション再生など。 ▪ 特殊な画角やプラカードの表示など、レアな条件の確認も容易になった。 ▪ デザイナー自身が質感やバリエーションをすぐに確認できるため、調整など試行錯誤がしやすい。 一般社団法人日本野球機構承認 19 #unrealfest

実装上の課題(1) モデルバリエーションの増加とインスタンシングの制約 多様な観客表現のためにモデルバリエーションを増やす必要がある。 しかし、インスタンシング描画は同一モデルに限定されるため、バリエーションが増えると 描画効率が低下する。 以下のシーンを想定した場合 描画人数：2,000人 モデルバリエーション：128体 描画に使用されるLOD：3段階 → 2,000(人) ÷ 128(バリエーション) ÷ 3(LOD) = 5.2(インスタンス/メッシュ) 平均インスタンス数 5.2 では、インスタンシングで大量描画というイメージとはかけ離れた状態になる。 20 #unrealfest

実装上の課題(2) 野球ゲーム特有のカメラ構図に起因するLODの非効率 ● 遠距離からのズーム撮影が多く、画角が狭いため、遠近感が出にくい構図となる。 ● このため、LODの距離による差異が視覚的に現れにくく、LODが効果的に働かない。 ● 結果として、広範囲に高詳細モデルが描画されてしまい、描画負荷が増大する。 一般社団法人日本野球機構承認 21 #unrealfest

実装上の課題(3) Draw Callの増加 → CPU負荷の上昇 ● 遠近感が出にくい構図により、LOD段階を細かく設定する必要がある。 ● さらに多様なバリエーションが存在することで描画単位が細分化され Draw Callが増加。 ● 結果としてCPU負荷が上昇する。 モデルバリエーション：128体 LOD段階：16 描画パス：Z PrePass(1) + BasePass(1) + ShadowDepthPass(4カスケード) → 128 × 16 × (1 + 1 + 4) = 12,288 Draws 22 #unrealfest

解決の方向性 ● 全バリエーション・全LODのモデルデータを一つに結合 ● GPU側でモデル配置・カリング・描画命令を生成 ● Multi-Draw Indirectによる効率的な一括描画 期待される効果 ● 描画命令の集約によるDraw Call削減 ● モデルバリエーションと描画効率の両立 ● CPU/GPU負荷のバランス改善 23 #unrealfest

ツール リソースデータ作成ツール ゲームで使用するすべての観客モデル (FBX)をあらかじめ登録しておきコンバートおよびデ ータ結合を行うスタンドアロンのWindowsアプリケーション。 以下のような機能を持つ。 ● LODモデル生成 ● モデルの変換と結合 ● テクスチャの結合 ● 軽量アセットの作成 24 #unrealfest

LODモデル生成(1) LODモデルの生成はUnreal Engineのスケルタルメッシュ削減ツールを使用。 Skeletal Mesh Reduction プラグインを有効化。 https://dev.epicgames.com/documentation/ja-jp/unreal-engine/skeletal-mesh-lods-in-unreal-engine?application_version=5.5 25 #unrealfest

• https://dev.epicgames.com/documentation/ja-jp/unreal-engine/skeletal-mesh-lods-in-unreal-engine?application_version=5.5

LODモデル生成(2) 全バリエーション・全LODのモデルデータを結合する関係で、Unreal Engineの標準的なアセット 登録の流れとは異なる手法が必要となり、エディタ上でLODを生成する通常の使い方は適さない。 そのためツール側からコマンドライン経由でエディタプロセスを起動し、Pythonスクリプトで FBXインポート → LOD生成 → FBXエクスポートの流れを自動化し、LODモデルを一括生成して いる。 26 #unrealfest

LODモデル生成(3) ● LOD生成の並列化 LOD生成、およびFBXインポート・エクスポート処理はゲームスレッドから呼ばれる前提 のコードであるためマルチスレッドによる並列化ができない。そのためツール側からエデ ィタプロセス(UnrealEditor-Cmd.exe)を複数同時起動する形で並列化を行っている。 モデル189体を制作用PC（Intel Xeon w7-3455/24Core-48Thread）でLOD生成した場合 並列化なし：約80分 並列化あり：約10分（8Process同時起動） ● 進捗状況の取得 進捗状況をプログレスバーで確認可能にするため、エディタプロセスの標準出力を定期的 に監視し進捗状況を取得。 27 #unrealfest

モデルの変換と結合(1) モデルの変換 モデルのチャンク化 ● モデルを128頂点・192ポリゴン以内に収まるよう分割 ● 分割されたチャンクは、コンピュートシェーダによるカリング処理や描画時に参照される ● カリング処理との親和性を考慮した分割構造 UV変換 ● 各モデルのUVを、結合済みテクスチャに合わせて調整 ● コンバート時に自動処理 28 #unrealfest

モデルの変換と結合(2) モデルの変換 ● ボーンLODの適用 ◼ボーン数に応じて16本単位で段階的に設定される。 ◼ボーン削減は末端ボーンの除去が基本だが、状況に応じて隣接ボーンへの置き換えも行う。 たとえば手の指の場合 親指と中指のボーンだけ残し、人差し指、薬指、小指のボーンは中指のボー ンに置き換えることでボーン数が削減されても、こぶしを握ったり開いたり といった動きは維持できるようになる。 29 #unrealfest

モデルの変換と結合(3) モデルの結合 ● 全てのモデルバリエーションとLODを、単一の頂点チャンク配列として結合 ● この結合によりシェーダから単一のバッファとして扱えるように 各LODごとの頂点数・ボーン数 ※LOD0の頂点数は目安とした目標頂点数 ボーンLODは16本単位で構成されるためボーンLOD段階は5段階になる。 ボーン数78本の場合、実際の割り当ては80本分となりメモリおよびGPUスレッドに若干の余剰が生じる。 30 #unrealfest

テクスチャの結合 ● テクスチャは縦横に並べて連結し、テクスチャアトラスとして結合 ● 1体あたりのテクスチャサイズは 1024×1024ピクセル ● 64体分をまとめると 8192×8192ピクセルとなり、比較的大きなサイズになる 31 #unrealfest

軽量アセットの作成 GPU性能の低い環境でも安定した描画を実現するため、従来の高品質アセットに加えて軽量な観客アセ ットを自動生成。 ● モデルのバリエーション数を削減 ● 高品質LODの省略 ● テクスチャの解像度削減 複数のバリエーションやLODを結合した結合済みアセットとして構築されているため、一部のLODを省 略する場合でも、それに対応した軽量構成の結合済みアセットを用意する必要がある。 32 #unrealfest

モデルの配置とカリング 観客モデルの配置とカリングはコンピュートシェーダで行っている。 • 個体単位のカリング 観客一人ごとに視野判定を行い、描画対象かどうかを判定する。 • 配置とメモリの割り当て カリングを通過したモデルを配置し、モーション計算に必要なメモ リ領域を割り当てる。 • モーション計算 ボーン階層に基づくモーション演算を行い、各モデルの姿勢を算出 する。 • ポリゴン単位のカリング BasePass、ShadowDepthPassそれぞれの描画パス用に、ポリゴン 単位でのカリングを行う。 • デバッグ用集計シェーダ カリング結果などを集計し、表示数や負荷の可視化などデバッグに 有用な情報を収集する。 33 #unrealfest

コンピュート処理の呼び出し(1) コンピュート処理がZ PrePassに先行して実行されるよう、コマンドリストを構築する必要がある。 SceneViewExtension::PreRenderView_RenderThread() を利用することで、描画スレッド上でビューごとの 処理を追加可能。 ただし、Cascade Shadow Mapに効率よく対応するのであれば追加のパラメータ取得が必要となりこの 方法は不十分。 34 #unrealfest

コンピュート処理の呼び出し(2) Cascade Shadow Map対応に必要な情報： ● FShadowCascadeSettings::SplitNear ● FShadowCascadeSettings::SplitFar ● FProjectedShadowInfo::TranslatedWorldToView これらのパラメータにアクセスするにはエンジンのカスタマイズが必要になるため、 FDeferredShadingSceneRenderer::Render() 内で RDG パスを追加し、必要な情報を取得した上でコン ピュート処理を実行している。 35 #unrealfest

コンピュート処理の呼び出し(3) FreezeRendering 対応 対応は必須ではないがカリング結果の挙動検証がしやすくなるため対応しておくことが望ましい。 必要な情報： ● FViewInfo::ViewState->bIsFrozenViewMatricesCached ● FViewInfo::ViewState->CachedViewMatrices これらの情報も同時に取得しておいて コンピュートシェーダで使用する。 36 #unrealfest

個体単位のカリング 判定基準：中心座標による簡易判定 ● カリングは NDC 空間で実施し、演算負荷を削減。 ● 判定は 個体の中心座標一点を基準に行う。 ● 基本的な判定範囲は XY が -1.0 ～ +1.0 に収まっているかどうか。 判定範囲の調整：視野・光源に応じた拡張 ● XY 判定では、モデルの投影サイズを考慮して判定範囲を拡張 → 視野周辺での不自然な消失を防止。 ● Z方向には拡張を行っていない → 観客モデルは near/far クリップにかかる対象ではないため。 ● ShadowMap 用カリングでは、光源方向に対して判定範囲を拡張 → 画面外から影を落とすモデルも描画対象に含める。 → 影の欠落を完全に防ぐことはできないが、実用上問題のないレベルに収まっている。 LOD の選択もこのタイミングで実施。 37 #unrealfest

配置とメモリの割り当て 個体単位カリングを通過したモデルに対して、後続のポリゴン単位カリングやモーション計算を行うた めの準備処理を行う。 ● スレッド起動数の決定 カリング済みモデルの数に基づき、後続処理に必要なGPUスレッド数を算出する。 ● パラメータのセットアップ 各モデルに対して配置座標、モデルID、LODレベル等の情報を構造化しバッファに格納する。 ● メモリの割り当て モーション計算で使用される出力バッファのサイズを算出し、必要な領域を割り当てる。 38 #unrealfest

モーション計算(1) 仕様 ● 体と顔それぞれに2モーションをブレンド可能 一体につき最大4モーション（体×2、顔×2）を同時再生 ● 描画対象のみ計算対象 画面内の観客に限定し、ボーンLODも適用して負荷を抑制 ● 首の向きは任意でプログラム制御可能 ボール、特定の野手、マウンドなどを注視するAI的挙動 必要な場面のみ、首のボーンに対して制御を適用 39 #unrealfest

モーション計算(2) シェーダ構成（2段階処理） 1. ボーン単位のモーション処理フェーズ 各ボーンに対して、モーションブレンド結果からローカル姿勢（回転・位置）を計算。 必要に応じて、首のボーンに対して視線方向を反映。 1ジョイントにつき1GPUスレッドを割り当て。 2. 階層変換フェーズ 各ボーンのワールド座標系での位置・向きを、親子関係に基づいて順に計算。 1人につき16GPUスレッドを割り当て。 40 #unrealfest

モーション計算(3) 約48,000人分のボーン変換行列をVelocity計算用も含めて2フレーム分保持すると、必要メモリサイズは 約340MBに達する。 ● 保持形式の最適化 ◼ボーン姿勢を行列ではなく、以下の形式で圧縮して保持 回転：16bit固定小数クォータニオン 位置：xy:22bit、z:20bitの固定小数 これにより、1ボーンあたり48バイト→16バイトに圧縮 ● メモリ使用量の削減 ◼カリングやLODを考慮し、必要なボーンにのみメモリを割り当て ◼使用メモリを24MBまで削減 ● 副次的な効果 ◼計算量は増加するが、シェーダのレジスタ消費量が減少しWaveの同時実行数が向上 ◼データサイズが小さくなったことでメモリ帯域の負荷も軽減 ◼結果として処理の高速化につながっている 41 #unrealfest

ポリゴン単位のカリング(1) コンピュートシェーダでポリゴン単位のカリングを行い、インデックスバッファを出力。 ● カリング手法 ● Backface Culling ● Frustum Culling（XY方向のみ） Near/Far方向でのカリングは不要なため、XY方向のみに限定して計算量を削減 (観客はZ方向(near/far)にカリングされる状況が起きないため) ● インデックスバッファ ◼Z PrePass / BasePass 用に共通バッファを出力 ◼ShadowDepthPass 用にはカスケード段数分を個別出力 511チャンク(65,408頂点)ごとに分割し、16bitインデックスでの描画に対応 ● 描画コマンド 分割された描画単位ごとに FRHIDrawIndexedIndirectParameters を生成し、GPU側で一括描画 (Multi-Draw Indirect)を行う 42 #unrealfest

ポリゴン単位のカリング(2) 小物の持ち替えはポリゴン単位のカリング処理の一環として実装。 ● コンバート時に各ポリゴンにオブジェクトIDを埋め込む ● カリング時にオブジェクトIDを参照し描画対象を選別、不要な小物を除外することで持ち替えを実現 ● オブジェクトIDは1～15を小物の種類として定義(0は常時表示されることを意味する) チャンク化されたインデックスバッファのフォーマット 小物の持ち替えによる描画負荷の増加はほとんどなく、効率的な制御が可能。 43 #unrealfest

デバッグ用集計シェーダ 各段階で生成された中間出力を集計し、統計情報としてリアルタイムに表示することで処理 状況や負荷の把握を支援する。 ● 特徴 カリングおよびモーション計算を行うシェーダは高速性を維持するため、デバッグに役立つ情報や統 計情報を一切出力しない。そのためデバッグ用集計シェーダが中間バッファに残った情報(残骸)を集 計し、統計情報を作成する。 ● 用途 ◼ バッファサイズの決定支援 頂点、インデックス、ボーン姿勢情報などを格納する各種バッファのサイズを決定する際に、統計情報を活用。 ◼ IndirectDrawによる描画プリミティブ数の集計 stat unit で表示される Prims の値には、IndirectDraw による描画プリミティブ数が含まれていな いため、別途集計処理を行い、統計情報として表示・確認できるようにしている。 44 #unrealfest

統計情報の表示 DECLARE_STATS_GROUP マクロを使用して統計情報の表示を追加。 コンソールコマンドを通じて、カリング処理に関する統計情報をリアルタイムに表示可能。 45 #unrealfest

描画処理(1):VertexFactoryの実装 独自の頂点構造（チャンク配列として構成された結合済みモデル）を扱う必要があるが、これはエンジ ンカスタマイズを行わずにゲームプロジェクト側でカスタムVertexFactoryを実装することで対応可能。 ● FLocalVertexFactoryを参考に、FCrowdVertexFactoryを実装 ● FVertexFactoryShaderParametersを継承したクラスの実装により、頂点シェーダへのパラメータ渡 しが可能 46 #unrealfest

描画処理(2):マテリアルとの連携 観客固有の情報や頂点由来のパラメータをマテリアルで使用するにはエンジンカスタマイズが必要。 Engine/Shaders/Private/MaterialTemplate.ush の以下の構造体に独自のパラメータを追加。 47 #unrealfest

描画処理(3):マテリアルとの連携 追加したパラメータの設定は CrowdVertexFactory.ush の以下の関数内で行う。 マテリアル側ではCustomノードで扱うことが可能。 必須ではないが、パラメータに対応したマテリアルエクスプレッションを実装。 48 #unrealfest

描画処理(4):Multi-Draw Indirect対応 16ビットインデックスを使用しながら一度の Draw Call で描画するために必要。 Multi-Draw Indirect 対応しない場合、予測に基づき繰り返し DrawIndirect を実行することになり、空の 描画コマンドが発生しやすく、描画効率が低下する。 対応にはエンジンカスタマイズが必要。 Engine/Source/Runtime/Engine/Public/MeshBatch.h FMeshDrawCommand::SubmitDrawEnd 関数に MultiDrawIndexedPrimitiveIndirect を呼び出すコード の追加も必要。 49 #unrealfest

描画処理(5):MeshComponentの実装 作成したカスタム VertexFactory を使用して描画を行うため、UMeshComponent および FPrimitiveSceneProxy を継承した独自の MeshComponent と SceneProxy クラスをゲームプロジェクト 側に実装。 これらのクラスは、結合済みモデルとカリング済みインデックスを用いた描画に対応しており、前述の VertexFactory や Multi-Draw Indirect 用のパラメータを描画処理に渡す役割を担う。 50 #unrealfest

描画処理(6):MeshComponentの実装 FCrowdMeshSceneProxy::GetDynamicMeshElements()では FMeshBatchを構築し、前述のカスタム VertexFactoryとともにMulti-Draw Indirect用のパラメータを設定している。 51 #unrealfest

パフォーマンス NVIDIA GeForce RTX 3060 Ti 環境での実行時間 打撃視点(描画人数約7000人、ボーン数約112,000本) ポリゴン単位のカリングによる描画負荷の削減が大きく、GPUでモーション計算を行ってもGPU全体の負荷 は従来より低減。 52 #unrealfest

各種データサイズ 53 #unrealfest

観客の制御(1) 観客制御は常に全員に対して実行される ゲーム中に球場内のどの部分がいつ映されるかは事前に確定できない → 観客は視野に入った瞬間に自然な状態で表示される必要がある → そのため、最大4万人規模の観客全員に対して制御処理を継続的に実行 ● 着席中の観客に対する制御 状況に応じたモーションの選択と再生制御 アニメーション進行管理 ボールや選手などの注目対象への視線追従 ● 移動中の観客に対する制御 移動専用の観客は存在せず、すべての観客が座席と紐づく 衝突判定・回避処理・混雑時の渋滞緩和などの移動ロジックを常時実行 移動人数は通常300～400人程度 → 試合の進行状況（イニングチェンジ・試合終了など）に応じて一時的に1000人以上が移動することも 54 #unrealfest

観客の制御(2) 観客の制御は人間の反応速度を再現するため、試合のイベ ントに対する反応は数フレームの遅延を伴う方が自然。そ のため、厳密な1フレーム単位の同期は不要。 ● 観客の更新処理をタスク化 更新結果を1フレーム後に受け取る設計に。 この設計により更新負荷のフレームレートへの影響を最 小限に抑制。 ● 即時反映が必要なケースへの対応 カットシーン切り替えなど、時間的連続性が断たれる場 面では即時反映が必要。ゲームスレッド側で更新結果を 上書きして即時反映。無駄な処理を避けるため、即時反 映対象の観客は最小限に制限。 55 #unrealfest

観客の制御(3) Tasks Systemを使用すれば簡単に実装可能。 https://dev.epicgames.com/documentation/ja-jp/unreal-engine/tasks-systems-in-unreal-engine?application_version=5.5 56 #unrealfest

• https://dev.epicgames.com/documentation/ja-jp/unreal-engine/tasks-systems-in-unreal-engine?application_version=5.5

観客の制御(4) 実際の処理では観客を区画ごとに分割し、複数タスクで並列更新を行っている。 ● 区画とは？ 通路に囲まれた複数の客席のまとまり。 スタジアムの座席ブロックをイメージすると分かりやすい。 各区画は、観客の配置・動きなどをまとめて管理する単位。 ● タスク粒度の調整 区画ごとの観客数には 1～200人程度の ばらつきがある。 タスクの負荷を均等にするため、複数区画を セットにして1タスクに割り当て。 これにより、並列処理の効率と安定性を両立。 57 #unrealfest

コンピュートの活用事例(1) StaticMeshと線分の交差判定 描画用のStaticMeshアセットだけを使って、線分との交差判定をGPU上で並列に処理する手法。コリ ジョンの設定されていないMeshでも判定が可能。交差判定の量が多いケースでもGPUの並列性を活か して効率よく処理できる。 実装ポイント ● StaticMeshComponent から頂点・インデックス情報を取得 ● 線分と三角形の交差判定をコンピュートシェーダで実装 ● ポリゴン数 × 線分数のスレッドを起動 ● 衝突点の座標と法線ベクトルを取得してバッファに格納 58 #unrealfest

コンピュートの活用事例(2) 以下のコードでStaticMeshComponentから必要な情報はすべて取得できる 59 #unrealfest

60 #unrealfest

モバイルへの対応(1) モバイル向けへの対応はハイエンド向けと同じ手法だけでは不十分で、最適化にさらなる工 夫が必要な状態。 ● 現在の対応 既存の観客モデルをベースに描画負荷を抑えるための調整を実施。 主な調整内容は、頂点数削減を目的としたLOD段階の整理。 検証にはPixel 9 Proを使用。 比較的高性能な構成ではあるが、一般的なハイエンドモバイルGPUと比べると描画性能は 控えめ。 61 #unrealfest

62 #unrealfest

モバイルへの対応(2) 描画人数が増えると30fpsを下回る場面が発生。 試合中の観客描画を想定すると、選手や球場などの要素が加わることで描画負荷が増加し、 フレームレートが低下して快適なプレイが成立しない。 ● Game、Draw、RHIT、Drawsの各値は、画面上の人数や構成に関わらず安定しており、最適化の意図 通りに動作している ● Primsの値が変化しないのは DrawIndirect による描画分が集計対象外であるためで、実際の描画プリ ミティブ数は増加している点に注意が必要。 ● GPU Timeはカメラを引いた際に増加傾向があり、各LODの頂点数に調整の余地がある可能性がある。 63 #unrealfest

モバイルへの対応(今後の方針) ● 描画手法の再構成 モバイルGPUでは、頂点処理能力とコンピュートシェーダによる演算能力のバランスがハイエンド GPUとは異なっており、ポリゴン単位のカリングによる負荷削減は、現状ではコストに見合う効果が 得られていないと考えられる。 そのためポリゴン単位のカリングは廃止し、Multi-Draw Indirectとインスタンシングを併用した構成 を検討したい。 描画モデルの種類やLODに応じて描画コマンドを分割し FRHIDrawIndexedIndirectParametersを生成。 複数の描画対象をまとめて処理する構成とする。 ● 制御処理の軽量化 描画処理以外の負荷対策として、行動制御処理の更新頻度を視野外で間引くなど、演出としての成立 を維持しつつ処理負荷を分散する工夫も併せて検討。 64 #unrealfest

Q&A ご清聴ありがとうございました。 アンケートへの回答をよろしくお願いします。 65 #unrealfest