お世話になっております。
現在メモリの最適化を行っているのですが、レベルによってPhysicsで消費されるメモリ使用量が大きく異なり、その原因と特定しようとしています。
重いレベルの場合だとUnrealInsights上でPhysicsのメモリが887MB、そこまで重くないレベルの場合だと73MB程度に収まっています。
確保しているCountの数が桁違いなので置かれているStaticMeshやActorの数が問題なのではないかと推測しているのですが、具体的に消費している項目が何に使用されているものなのかわからず、
特定に時間がかかっている状況です。
こちら、ChaosAccelarationやChaosGeometry等が何が原因で大きくなるのがご教授頂いてもよろしいでしょうか？
お手数おかけしますが、よろしくお願いいたします。
<br/>
[Image Removed]
(下記のリンク先は、本スレッドを英語に翻訳した英文スレッドですが、Epic Games のサポートチームが内部的に使用するものですので、ユーザーの方に利用していただく必要はございません。サポートは、この日本語スレッドに日本語で表示されるようになります。)
[How to identify the cause of significant difference in Physics memory usage among [Content removed]
[mention removed] 様
(以下は EPS メンバーの Corvi Ernesto によるコメントを翻訳したものです。)
Development ビルドで chaosgeometrymemory をコンソール上で試してみてください。Simplified メッシュ/ Trimesh ジオメトリのメモリ使用量の内訳が表示されるはずです。
本件問題は、Nanite で使おうとしたメッシュに原因があることが多いです。チェックボックスにチェックを入れるのを忘れて、Complex Collision (複雑なコリジョン) を使ってしまうことから生じる場合が典型となります。
[mention removed] 様
(以下は EPS メンバーの Corvi Ernesto によるコメントを翻訳したものです。上記回答を詳しく説明したものです。)
もし Nanite を有効にして使用するつもりのハイポリ モデルをインポートしたけれども、うっかり Nanite を有効にし忘れていた場合、コリジョン用の Trimesh はそのハイポリのメッシュから生成されます (そのメッシュのコリジョン設定が Use Complex and Simple または Use Complex as Simple になっている場合)。メッシュで Nanite を有効にすると、コリジョン用の Trimesh はフォールバック メッシュから生成されることになり、通常はポリゴン数が非常に少なくなります。
chaosgeometrymemory コマンドを使えば、コリジョン メモリ使用量の少ない順に、読み込まれているメッシュのリストが表示され、Simplified メッシュ/ Trimesh ジオメトリが使われているかどうかも示されます。このコマンドは Unreal エディタ上でも実行できます。
[mention removed]
お世話になっております。
頂いたアドバイスを元にUse Complex as Simpleになっているメッシュやフォールバックメッシュそのものの頂点数を調整したところ、大きくメモリ消費量を減らすことが出来ました。
ただその状態でも依然としてPhysicsが消費しているメモリは大きい状態にはなっております。
今回のStaticMesh側の調整とは別に、レベルに配置してあるStaticMeshActorをMergeActorのBatchを使用してInstancedStaticMeshにしてもメモリ消費量が減ることを確認しています。
頂点数の調整を行った後にInstancedStaticMeshにするというのはまだ行えていないのですが、そもそも今回のようにChaosAccelarationやChaosGeometryが大きくメモリを確保してしまっている状態の最適化として適切なものになるのでしょうか。
お手数ですが、ご確認よろしくお願いいたします。
[Image Removed]
[mention removed] 様
(以下は EPS メンバーの Corvi Ernesto によるコメントを翻訳したものです。)
原因が分かってよかったです。補足させていただきたいのですが、メッシュを No Collision という反応に切り替えても、自動的にコリジョン情報が削除されるわけではありません。これは、実行時にこのコリジョン反応を一時的に変更することができるようにするための措置です。
クック時にメッシュからコリジョン情報を完全に削除するには、スタティック メッシュ エディタで Never needs cooked collision data (クック済みのコリジョン データはまったく必要ない) にチェックを入れてください。このようにしてプロジェクトをクックすると、そのコリジョン データはクックされず、ゲームに一切含まれなくなります。
[mention removed] 様
(以下は、サポート担当の Stacey Geoff によるコメントを翻訳したものです。)
お世話になっております。
本件問題に対応しようとしてこのスレッドを開いたところ、Ernesto さんにすでに答えて頂いておりました。(Ernesto さん、ありがとうございました。)
本件問題をクローズできてよかったです。
補足アドバイスを申し上げれば、Unreal Engine には Unreal Insights というプロファイラーがあります。これには、メモリ割り当てプロファイラーも含まれておりますので、不明なメモリ割り当てを追跡調査するのに役立ちます。
https://dev.epicgames.com/documentation/ja\-jp/unreal\-engine/unreal\-insights\-in\-unreal\-engine
https://dev.epicgames.com/documentation/ja\-jp/unreal\-engine/memory\-insights\-in\-unreal\-engine
(以下は、サポート担当の Stacey Geoff によるコメントを翻訳したものです。)
>以前にも提案したことがあるのですが、chaosgeometrymemory というコンソール コマンドは、もっと宣伝して目立つようにしたほうがいいと思っております。
Ernesto さん、それはよい提案ですね。ところで、ワークフローの中で CVD (Chaos Visual Debugger) を使っていますか？
[mention removed] 様
(以下は EPS メンバーの Corvi Ernesto によるコメントを翻訳したものです。)
ゲームの必要性に応じて、アプローチはさまざまです。
コリジョンの正確性を必要としないメッシュには、Simplified (簡略化された) ジオメトリを生成し、Use Simple as Complex に設定します。これにより、多くのメモリを節約できます。Simplified (簡略化された) ジオメトリは通常、負荷が軽いからです。
コリジョンの正確性をまさに必要とする (Complex as Simple) けれども、フォールバック メッシュのトライアングル数がコリジョンに必要な数より多いメッシュの場合は、コリジョンに必要な精度を持つ Simplified (簡略化された) メッシュを作成し、Custom Collision Mesh オプションを使って、そのメッシュを、コリジョン用の Trimesh として使われるメッシュとして設定することを検討してみてください。
その手順についての説明は、次のリンクにあります。
お役に立てますと幸いです。
お世話になっております。
こちらの主な原因ですが、StaticMeshのコリジョンはSimpleに設定されているものの、PCGによって作成された大量のInstancedStaticMeshによって引き起こされていることがわかりました。
Actor1つにつき数百～数千のInstanceが作成されており、このPCGActorのコリジョンプリセットをNoCollisionにするだけで数百MB単位でメモリ削減に繋がったことをご報告します。
未だ最適化作業中ではありますが、今後のため検証した項目を挙げておきます。
■PCGによって作成された数千のInstanceを抱えるActorのコリジョンプリセットをNoCollisionにする
→ 今回のケースでは最も工数をかけず効果が大きいものとなりました
■ComplexCollisionを使用しているMeshのコリジョンメッシュのリダクション、Simple化
→ 消費量が大きいStaticMeshに対して1つ1つ実行する必要があり、手間はかかりますが効果は大きかったです
■StaticMeshActorをInstancedStaticMeshにまとめる
→ Physicsのメモリ消費という観点ではあまり効果がありませんでした。UObjectのメモリは減っているのを確認しています。
→ 今回作成しているゲームのマップがそこまで広くなかったことも関係しているかと思います。
→ PackedLevelActorやFastGeoPluginに今後期待したいです。
以上になります。
対応頂いた [mention removed] 様、英語版スレッドでお答え頂いた [mention removed] 様。ご協力ありがとうございました。
このスレッドは一旦解決済みにしてもらって構いません。
よろしくお願いいたします。
[mention removed] 様
詳細な情報を共有していただきまして、大変ありがとうございます。非常に助かります。
これにて、一旦本スレッドをクローズとさせていただきますが、また、何かご質問等ありましたら、本スレッドに書き込むだけで自動的に再オープンされます。
ご利用いただきまして、ありがとうございました。
(以下は EPS メンバーの Corvi Ernesto によるコメントを翻訳したものです。)
>本件問題に対応しようとしてこのスレッドを開いたところ、Ernesto さんにすでに答えて頂いておりました。(Ernesto さん、ありがとうございました。)
どういたしまして。
私たちの場合、最近、ほとんどあらゆるプロジェクトでこの種の問題に遭遇しております。Nanite の到来により、そのためのチェックボックスをチェックし忘れてしまうのはかなりよくあることで、それによる副作用のひとつとしてコリジョン メモリの急上昇が最もよく見られます。
以前にも提案したことがあるのですが、chaosgeometrymemory というコンソール コマンドは、もっと宣伝して目立つようにしたほうがいいと思っております。
また、私たちの場合、次のような、Content Browser のためのカスタムのフィルタをいくつか作成しております。
((CollisionComplexity = UseComplexAsSimple | CollisionComplexity = UseSimpleAndComplex) & triangles > 20000) | PhysicsSize > 131072
このようなフィルターを使うことによって、本件問題を引き起こしうる問題含みのメッシュを特定するのに実に役立っています。
(以下は EPS メンバーの Corvi Ernesto によるコメントを翻訳したものです。)
こんにちは、Geoff さん。
> ところで、ワークフローの中で CVD (Chaos Visual Debugger) を使っていますか？
個人的には、はっきりしない物理的な作用を調べるときに 1～2 回使った程度です。あまり使わないのは、Chaos 物理が全体的にうまく動作していることの何よりの証だと思っております。
今回ここで論じられた問題は、どちらかというとアセットのセットアップに関する問題なので、原因を特定するためにこれまで議論されてきた方法の他にも、私たちのチームでは、Data Validator を使ってこうした問題を早いうちに検出するようにしています。
(以下は、サポート担当の Stacey Geoff によるコメントを翻訳したものです。)
Ernesto さん、ありがとうございます！
これで、本スレッドをクローズしたいと思います。