Rwi
(Rwi)
1
現在、UE4の「Sprite」及び「Paper Flipbook」機能を主に用いて、2D弾幕シューティングゲームの作成に取り掛かっているUE4初心者です。敵弾の数がそれほど多くない場合は60fpsを維持し快適に動作するのですが、現状だと弾数が増すにつれ、次第に処理落ちしてしまい困っています。
自力での解決は難しそうなため、改善案をご教授いただければと思い質問させていただきました。なお、参考までに自分なりに模索した過程等を以下に記載します。
初めに原因を掴むため、画像のようにTick処理等を無効化した敵弾を、レベルブループリント内の処理で画面内に1000個スポーンさせてみました。すると、新規エディタウィンドウ（PIE）上のプレイで30fps前後で動作する形となりました。
敵弾ブループリントのTickやBeginPlayイベントを予め無効化していることや、カメラを移動させ画面内に弾を映さないようにすると60fpsで動作すること、コンソールコマンド「stat unit」の計測でGPUの数値が高いこと。以上から、スプライト画像の表示処理に不要な負荷が発じているのが処理落ちの原因ではないか・・・と推測しました。
次に、GPUビジュアライザー機能を使い、GPUのネックとなっている処理を確認すると以下の項目の負荷が目立ちました。（いずれも継続時間が5～10ミリ秒程度）
- PrePass DDM_AllOpaque(Forced by DBuffer) → Dynamic
- Translucency
- FilterTranslucentVolume 64x64x64x Cascades:2
- CullLights 20x12x32 NumLights 0 NumCaptures 0
- HZB SetupMips Mips:1 …9 512x256
- BeginOcclusiontests
- BassPass → Dynamic
そこで、完全に手探りではありますが「プロジェクト設定」→「エンジン」→「Rendering」から、"DBuffer Decals"の項目を無効化させてみたところ、BassPass以外の目立っていたGPU負荷を大きく削減することができました。PIE上でのプレイでも36fps程度と、動作がわずかに向上しました。
ここまでは自力で何とかできた（と思う）のですが、その他の良い設定の仕方が分からず、ここで手詰まりになってしまいました。 環境設定や、それ以外の方法など、3D表示の品質はある程度犠牲になっても構わないので、処理速度優先でスプライト表示の負荷を軽くできればと思います。
なおUE4のプロジェクト設定は、Renderingセクションの" Bloom " や " AmbientOcclusion " をオフにした以外は、概ねデフォルト設定のままとなっています。
画像がすべて無くなっていて正しい情報がわかりません。
あと、弾のMaterialがどのようになっているか気になります。
Rwi
(Rwi)
3
申し訳ありません、すべての画像の再添付を行いました。
弾のDefault Materialには、Sprite, PaperFlipbook 共に、デフォルトで適用されている「MaskedUnlitSpriteMaterial」をそのまま指定しています。その他、必要な情報がお有りでしたら何なりとお申し付けください。
T_Sumisaki
(T_Sumisaki)
4
Rwi
(Rwi)
5
ご回答ありがとうございます。
問題の解決に繋がるかは判りませんが、コンソールコマンド「stat scenerendering」を、表示する弾数を分けて複数実行してみました。「Mesh draw calls」の数値は、画面内に表示されているアクタの数とほぼ同数のようです。
1枚目:弾数1000
2枚目:弾数500
3枚目:弾数0
4枚目:弾数10000（画面内の表示数は1470発程度）
5枚目:弾数20000（画面内の表示数は1470発程度）
参考スレッドのご紹介も重ねてお礼申し上げます。読解度に自信がありませんが、スレッドの内容をまとめると
・UE4のスプライト機能は他のゲームエンジンに比べ数倍重い
・「PaperGroupedSpriteコンポーネント」を利用すると軽くできる（試験的な機能？）（しかし毎フレーム動かすと重い？）
ということでしょうか？なお、試しに「PaperGroupedSprite」を親クラスにしたアクターを同様に表示させてみましたが、負荷は上記の結果と変わりありませんでした。(PaperGroupedSpriteコンポーネントの使い方は分かりませんでした・・・)
PaperGroupedSprite 関連の情報や事例はとても少ないようで、他に解決策がない場合、自身の能力ではこの先自力での解決や、今後発生しうる問題の対処は厳しそうです。
弾幕のような表示数の多いアクターには、PaperFlipbookのアニメーション機能などは諦めて、StaticMeshとBoxCollisionコンポーネントを合わせたアクター等で代用するのが賢明でしょうか。
alwei
(alwei)
6
Paper Grouped SpriteはInstanced Static Meshと同様の扱い方をするための専用クラスです。Instanced Static Meshについて、以下の記事などを参考にしてください。
つまりどういうことかと言いますと、同じマテリアルを利用しているのであれば、1回のドローコールで何度でも描画できるので、1枚だろうが1000枚だろうが全く同じCPU Drawコストで済ませることができます。※ポリゴン描画コストは別でこちらはGPU次第
ただし欠点としては、個々のスプライトインスタンスが持つ情報はスプライト画像、頂点カラー、トランスフォームの3つしかありません。1つのアクターで全てスプライトを管理する必要があるので、細かい機能を作るのには向いていません。弾幕のような大量に表示されるものを作るのであれば今回の用途には向いているかと思います。
うまく制御できれば、どれだけの弾幕を表示させても負荷はほとんどかからないはずです。
Rwi
(Rwi)
7
(質問を解決済みにするため、こちらに回答としてコメントします)
頂いた情報を元に、Paper Grouped Sprite コンポーネントとConstruction Script 処理を組み合わせた結果、画面いっぱいの表示状態でも60fpsで動作させることができました！
これでスプライト画像の表示負荷を軽くすることができました。
しかし、どうしたら弾幕としてこれらの弾を一つ一つ動かすことができるか・・・という問題に今度は直面しています。
Paper Grouped Sprite の扱いがうまくいかない場合は、解像度の調整や弾数制限を厳しくするなど、ゲームデザインの変更等も今後は視野に入れていこうと思います。
お二方とも、この度は丁寧なご回答をどうもありがとうございました。
