Download as PDF, PPTX
Uploaded byエピック・ゲームズ・ジャパン Epic Games Japan
60fpsアクションを実現する秘訣を伝授 解析編
講演動画：https://youtu.be/YXGmiWzHxeo 基礎編：https://www.slideshare.net/EpicGamesJapan/ue4-festeast2019-60fpsbasic 2019年10月6日に行われた「UNREAL FEST EAST 2019」における「60fpsアクションを実現する秘訣を伝授」の登壇資料です。 ●公式サイト https://unrealengine.jp/unrealfest/ === 発売中のタイトル「NARUTO TO BORUTO シノビストライカー」に開発中のプロジェクトの事例も加えて、60fpsアクションゲームを実現するためのポイントや、パフォーマンス・チューニングについて解説します。おまけとして「NARUTO TO BORUTO シノビストライカー」のグラフィック面の技術を紹介。
More Related Content
![[CEDEC2017] UE4プロファイリングツール総おさらい（グラフィクス編）](https://cdn.slidesharecdn.com/ss_thumbnails/ue4profilingbasiccedec2017-170831013144-thumbnail.jpg?width=640&height=640&fit=bounds)
![[CEDEC2018] UE4アニメーションシステム総おさらい](https://cdn.slidesharecdn.com/ss_thumbnails/animationsystem-180823080249-thumbnail.jpg?width=640&height=640&fit=bounds)
![[CEDEC2018] UE4で多数のキャラクターを生かすためのテクニック](https://cdn.slidesharecdn.com/ss_thumbnails/cedec2018charcterperdormanceoptimze-180823081028-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to 60fpsアクションを実現する秘訣を伝授 解析編
![[GTMF2019]Unreal Engine 4の2019年上半期 アップデート情報まとめ](https://cdn.slidesharecdn.com/ss_thumbnails/tokyogtmf2019sawada-190718080113-thumbnail.jpg?width=640&height=640&fit=bounds)
60fpsアクションを実現する秘訣を伝授 解析編
- 1. #ue4fest#ue4fest 60fpsゲームのために 解析編 Winter Crown WORKS梶井 祐 協力: ソレイユ株式会社 尾田 委久 協力: Winter Crown WORKS 石濃 潤一郎
- 2. #ue4fest#ue4fest • IndieGame StudioWinterCrownWORKSのプログラマー。 主に分野はグラフィックスプログラム。 仕事では各会社様からパフォーマンス関連のご相談を承って おります。 WinterCrownWORKSのアーティスト石濃、プログラマー梶 井で、アーティストとプログラマー両方の視点から改善案、 サンプル提供、エンジン改造などを行っております。 ご相談の際には contact@winter-crown-works.com までお気軽にご連絡ください。 梶井 祐
- 3.
- 4. #ue4fest#ue4fest 目次 1.GraphicsをProfile ...p7 2. 軽量化、高速化に入る前に...p14 3.Maskedなマテリアル ...p17 4.BasePass ...p69 5.アセットについて ...p127 6.Translucency ...p179 7.PostProcessに関して ...p201 8.CPU軽量化、最適化 ...p214 9.オマケメモリに関して ...p267 10.総括 ...p283 11.参考文献 ...p289
- 5. #ue4fest#ue4fest • CPU i7-6700K4GHz • グラフィックボード NVidia Geforce GTX 750 Ti • メモリ 64GB テストに使ったPCの構成
- 6.
- 7.
- 8. #ue4fest#ue4fest • より詳細な情報が得られる(情報の精度、範囲はProfiler次第) - どんなデータがセットアップされたのか、シェーダース テージ間では何が受け渡されているのか？ -実際に描画されたポリゴン数は？ピクセル数は？ - 計算が重いのか？テクスチャのアクセスか？ Profilerで見ると何がいいの？
- 9. #ue4fest#ue4fest • ダウンロードしてすぐ試せる。 • 低レイヤー部分の調査が出来る。(根拠のために必要) •NVIDIA様のドキュメントやBlogで多くの情報が得られる。 低レイヤーの情報も多く載っている。 • 【今人気のプラットフォーム】の解析に近 い感覚 この度使うProfilerはNSight 2019.5
- 10. #ue4fest#ue4fest • NVIDIA 様のサイトより(翻訳)： NVIDIANsight Graphicsは、グラフィックアプリケーション のデバッグとプロファイリングのためのスタンドアロンアプ リケーションです。 Nsightは、DirectCompute、Direct3D（11、12、DXR）、 OpenGL、Vulkan（1.1、NV Vulkan Raytracing Extension ）、Oculus SDK、およびOpenVRで構築されたアプリケーシ ョンをサポートしています。 NSight
- 11.
- 12.
- 13.
- 14. #ue4fest#ue4fest • Lightの置きすぎによるLighting負荷 • 広範囲に半透明を重ねすぎたOverDraw負荷 •高解像度、テクスチャ枚数多すぎのマテリアル負荷 • PostProcessによるフィルター負荷 • 草原、森の作り方によるMaskedMaterial負荷 等々・・・・。 どんな問題がある？
- 15. #ue4fest#ue4fest • 大前提として - デバイスの性能を上回る事はない -デバイスの影響は必ず受ける デバイスの性能を使い切るために Profileingを行い正確な情報を得る。 ゲームエンジンを使用しても、なんでも お任せとはいかない・・・。
- 16.
- 17. #ue4fest#ue4fest え？重いの？ • 4.16で入ったMask Materialonly in Early Z-pass使ったら 軽くなるんじゃなかったっけ？ 参考文献:Mask Material only in Early Z-passの効果と仕組 み • 抜きを使ったらポリゴン数少ないでしょ？軽いんじゃない の？
- 18. #ue4fest#ue4fest • Mask Materialonly in Early Z-pass MaskedMaterialのBasePassの負荷は下がります。 が、 MaskedMaterialのすべてが解決する訳ではない。 • 板ポリの積極運用でポリゴンを減らす 抜きを使ってポリゴン数を減らして行っても、頂点数がボト ルネックのケースでない限りは効果は微妙 整理しましょう。
- 19. #ue4fest#ue4fest • Prepassの負荷 • ShadowDepthの負荷 •BasePassの負荷 Mask Material only in Early Z-pass で対処されるのはBasePassについて。 他の描画パスでは注意が必要。 ポイント
- 20. #ue4fest#ue4fest Masked Material の実行 MaskMaterialOnlyin Early Z pass未使用 • Prepass(Masked又は描画 しない) • BasePass(Masked) • ShadowDepth(Masked) MaskMaterialOnly in Early Z pass使用 • Prepass(Masked) • BasePass(Opaque) • ShadowDepth(Masked)
- 21.
- 22.
- 23. #ue4fest#ue4fest • Prepass 1.34ms •ShadowDepth 1.42ms • BasePass 2.31ms 負荷の内訳
- 24.
- 25.
- 26.
- 27. #ue4fest#ue4fest • DrawCall Count1 Profileをかけた範囲で発生したDrawCallが1つ。 • API Primitive Total / Avg 投入されたポリゴン数の合計 / DrawCall辺りの平均 • Shaded Pixel Total / Avg ピクセルシェーダーの動作したフラグメント数 / DrawCall辺 りの平均 ＊PrepassでOpaqueマテリアルは 0 で計上される。（PDO を使ってない場合） RangeInfo
- 28.
- 29. #ue4fest#ue4fest • PD(Primitive Distribute)= インデックスバッファのロード • VAF(頂点属性のフェッチ) = 頂点バッファの読み込み • SM(ストリーミングマルチプロセッサ) = シェーダーの実行 • FMA fp32(FADD,FMUL,FMAD) = 32bit浮動小数演算 • ALU = 整数および論理演算 • FP16 = 半精度の計算 • SFU = 三角関数等(rsqrt,cos/sin ) • TEX = SRV,UAVのフェッチ ＧＰＵ ユニット
- 30. #ue4fest#ue4fest • VPC =ViewPort変換、錐台カリング • L2 = L2キャッシュ • CROP = ColorRenderTargetへの書き込み、ブレンド • ZROP = 深度ステンシルテストを行う • VRAM = GPU Video Memory • SOL = Speed Of Light 理論値に対する達成率 ＧＰＵ ユニット
- 31.
- 32. #ue4fest#ue4fest • SOL TEX 100%, ZROP 42.9% , SM 21.9% , L2 20.8% TEXユニットへのアクセスが理論値最大で出ている。(テクス チャアクセスによって速度が制限されている可能性が高い) ZROPが高いのはPrepassは深度の構築なため深度に対する書 き込み、読み込みが多いため。 SMは若干低い気がする。 次にシェーダーの実行周りを見てみる まず見るべき場所
- 33.
- 34. #ue4fest#ue4fest • SM Activeが100%に近いのにStall Long ScoreBoard が非 常に高い。 FS Invocations（ピクセルシェーダーの実行数）が非常に多 い。 どう見る？
- 35. #ue4fest#ue4fest • Prepass はMaskedのままでレンダリング - 抜きの計算のためにPixelShaderが走る 抜きのためのテクスチャアクセスも行われる。 - EarlyＺが効かない 深度の裏に回ってもレンダリングされる。その上でピクセ ルシェーダーもテクスチャアクセスも行われるので尚負荷に MaskedMaterial おさらい
- 36. #ue4fest#ue4fest • 流れ - 頂点シェーダー(画面に入っていた場合) Early Zを通り抜けピクセルシェーダーへ - ピクセルシェーダー OpacityMaskに繋がってるノードを計算。 αテストを通っていれば 深度テストへ(Late Z Test) - 深度テストを抜けた場合、DepthBufferへ出力 α抜きの動作
- 37. #ue4fest#ue4fest • 流れ - 頂点シェーダー(画面に入っていた場合) 深度テスト（EarlyZ） - 深度テストを抜けた場合DepthBufferへ出力 ピクセルシェーダーは走らず、テクスチャアクセスも頂点で のフェッチまでしか発生しない。 OpaqueMaterielの動作
- 38.
- 39.
- 40.
- 41.
- 42.
- 43. #ue4fest#ue4fest PrepassはMaskedの面積はそのまま負荷 に • 深度の裏に回った分もすべて負荷になる。 Maskedでレンダリングする際には、画面で見えてる以上に負 荷が高い という事に注意が必要。 今回の場合FSInvocationsが非常に多く、その上で TextureAccessも多い状態。 FS Invocationsはピクセルシェーダーが呼び出された数。
- 44.
- 45.
- 46.
- 47.
- 48. #ue4fest#ue4fest • Prepass が1.34ms→0.83ms へ。 Mask部分に関して言えば0.55msと約半分に。 LODの分DrawCallは増えているものの軽量に。 計測してみる
- 49. #ue4fest#ue4fest • FS Invocationsが半分以下。 つまり単純に処理の総量が減っている。TEXが100%、StallLong ScoreBardが高いのはMaskなので仕方ない。(Prepass全体では下がってる) MaskedMaterialそのものが軽くなった わけではないが・・・
- 50. #ue4fest#ue4fest • Mask Materialonly in early – Z-passを使っても注意が必要 • 重なる面積は最小に • 抜きの形状を綺麗にとるかどうかは配置数やシーン全体のポ リゴン数と相談 • 出来るだけ不必要なMaskを避ける 親マテリアルを意図せずMaskedMaterialで作っただけなんて いうケースも・・・。 Prepass まとめ
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62. #ue4fest#ue4fest • 運用方法 - 影モデルとして配置するものはLODを1段下げる ポリゴン数を抑える効果、maskの場合は書き込みの総面積 の抑制効果による軽量化が出来ます。 -シルエットを合わせた別モデルを用意する。 こちらもMaskedの場合は総面積を減らせますし、シルエッ トを合わせる事でOpaqueMaterialで配置も出来るかも知れま せん。 影モデルを用意してどうするの？
- 63. #ue4fest#ue4fest • MaskedMaterialはDynamicShadowにも影響 重なる面積で負荷が非常にあがる • こちらもPrepass同様、無駄な書き込み面積を減らす事が重 要 •解像度は要調整 BaseScalability.iniで各スケーラビリティごとに、 r.Shadow.MaxCSMResolution で解像度が設定されている。 タイトル側でiniファイルを作りスケーラビリティをタイトル の方針に合わせる。 ShadowDepthのまとめ
- 64. #ue4fest#ue4fest • Prepass とShadowDepthで負荷に影響が出てくる。 重なる総面積に注意。 よく目にするBush(茂み)モデルはパッと見の見た目以上に重 なっているので、負荷が高い。 頂点をただ削られて総面積が変わらないデータを見る事があ りますが、広く重なる面積を減らす方が効果が高い事が多い。 FS Invocations 、Shaded Pixelの数が非常に大きい値になっ てないか確認を。 MaskedMaterialのまとめ
- 65.
- 66.
- 67. #ue4fest#ue4fest • 草原 • 森 •オブジェクトのカメラフェード これらのシチュエーションは負荷がかかる筆頭です。 もし大量に配置が必要な場合、なんらかの方法を確立したり コストをかけないとクオリティを下げる結果になりやすい。 ＊よく誤解がありますが、InstancingやFoliageを使っても ピクセルシェーダーの負荷は特別軽くなったりはしません。 Maskedで気を付けるシチュエーション
- 68.
- 69.
- 70.
- 71. #ue4fest#ue4fest 負荷が重いケース 頂点シェーダー • 頂点シェーダーの負荷 -ポリゴン数の超過 - 頂点アトリビュートのデータサイズ 頂点座標やUV等のデータ。UE4だと主にUV部分や SkeletalMeshかStaticMeshかで可変する。 - シェーダーステージ間のデータサイズ カスタムUVで拡張、PixelShaderで使用される最大UVイン デックス(どういう事かは後述します)
- 72. #ue4fest#ue4fest 負荷が重いケース ピクセルシェーダー • ピクセルシェーダーの負荷 -計算量が多い(ALU,FMA,FP16) - テクスチャアクセスが多い,大きいmipへのアクセス - 冗長なTexturFormatが使われている - RenderTargetのFormatが冗長 - PixelShaderの動く面積が広い - LateZの実行(PixelDepthOffset) - マイクロポリゴン、細長いポリゴンが多い
- 73.
- 74. #ue4fest#ue4fest • まず簡単なモデルデータのBasePassがどうNSightで解析で きるのか見てみます。 注目するデータ：消火栓モデル ポリゴン数 29,014 ＵＶチャンネル2 マテリアル：BC,Normal,MRの3枚 構成
- 75.
- 76.
- 77.
- 78.
- 79.
- 80. #ue4fest#ue4fest • SM Activeの割合が若干低い SMOccpancyも低く、シェーダーの実行効率が悪そう。 • Long ScoreBoardが高い L1の命令キュー待ちが多いほど高くなる。 (SM Occpancyが低くなってる原因ではないか？) • FS Invocationの値を見ると実行されているスレッド数が多い マイクロポリゴンが発生していないか？ 値をそれぞれ検討してみる。
- 81. #ue4fest#ue4fest • L1 Cache Vertexのフェッチ、次のシェーダーステージへのアウトプッ ト、Textureのフェッチ時等でアクセスされる。 •L2 Cache L1でフェッチにミスするとアクセスが発生。 メモリアクセス時に頻繁にアクセスされる。 ちょっとユニットの補足
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90. #ue4fest#ue4fest CustomShaderノードの中身です。これ自体はunreal内で宣言されているコードとほぼ同一のもの になります。 MaterialFloat2 NormalXY =vRG.rg; NormalXY = NormalXY * MaterialFloat2(2.0f,2.0f) - MaterialFloat2(1.0f,1.0f); MaterialFloat NormalZ = sqrt( saturate( 1.0f - dot( NormalXY, NormalXY ) ) ); return MaterialFloat4( NormalXY.xy, NormalZ, 1.0f ); オマケ：UnPackNormalのコード
- 91.
- 92.
- 93.
- 94. #ue4fest#ue4fest • 以前のTOP SOLは TEX が56.5%,SMが56.1% TOP SOLの順位が変わっている
- 95.
- 96. #ue4fest#ue4fest • Long Scoreboard、Tex Throttle 共に下がっている。 テクスチャアクセスを減らしたことでL1の待機が減ったと思 われる。(TEXのSOLも下がっている事が確認できた) • FS Invocationが下がっている。 見た目の面積は一緒だが、マイクロポリゴンやOverDrawが 減った事により、ピクセルシェーダーの実行が減っている。 • SM Active Min/Maxも少し上がっている 多少シェーダーユニットの並列性が上がったものと思われる。 考察
- 97.
- 98.
- 99. #ue4fest#ue4fest • できるだけ低いmipへのアクセス 必要がなければTextureの解像度を下げる • 単色やグラデーションだけのテクスチャはパラメーターに置 き換える •TextureFilterを必要最小限に Anisotropyを低いレベルに指定する等でもう少し改善は出来 ると思われます。 TEXの軽量化
- 100.
- 101. #ue4fest#ue4fest • 最近、結構誤解がある と感じたので軽くImposterBakerに 触れておきます。 こちらはモデルを多方面からキャプチャした画像を使い、視 点方向に合わせたテクスチャを選択し、補間を行い、板ポリ でモデルを表現するような手法になります。 オマケ：Imposter Baker
- 102.
- 103.
- 104.
- 105.
- 106.
- 107.
- 108.
- 109.
- 110.
- 111.
- 112. #ue4fest#ue4fest • TOP SOLのTEXの割合はImposterの方が高い そしてL2のHitRate、SOLがImposterの方が低い。 角度補間のために同じテクスチャへのサンプリングが多く、 キャッシュミスが多いためと思われる。 • ShortScoreBoardがImposterの方がかなり高い。 恐らくUVを求めるための計算が非常に長い。 • FS InvocationsもImposterの方が高い。 つまり上記二点のボトルネックがあるにも関わらずピクセル シェーダーの実行数も多い 一見するとImposterの方が効率良さそう に見えるが・・・
- 113.
- 114.
- 115.
- 116. #ue4fest#ue4fest • 頂点がシーンのボトルネックのケース • 表示領域が十分に小さい事,見る方向を変化させてもできるだ け一定の大きさである事。 •用途に合わせてマテリアルも最適化した方が良い。 PixelDepthOffsetの使用を最低限にしたり、ライティングの 有無。 Imposterを使う事が有効なケース
- 117.
- 118.
- 119. #ue4fest#ue4fest • 主に VertexShader→ PixelShader で受け渡されるデータ このサイズが大きいとシェーダーの実行効率が落ちます。 PSが起動する際、このデータを読み取り終える必要があるた めです。 こちらは、PS内で使うUVが多い場合(CustomUVでの拡張も 含む)、Vertex InterpolaterノードでPixelShaderへデータを 受け渡した場合にサイズが増えます。 シェーダーステージ間のデータ
- 120.
- 121.
- 122.
- 123. #ue4fest#ue4fest • TextureAccess • マイクロポリゴン •RenderTargetのフォーマット • ポリゴン数が多いケースで、VS to PSのoutputParamaterの サイズ。 • 極端に多いポリゴン数 • PixelDepthOffset (UE4においてはBasePassでもHizが効く LateZの実行という感じ) 等々・・・・。 で、BasePassが重い原因って？
- 124.
- 125. #ue4fest#ue4fest • シーン内のインスタンスが多いオブジェクト その上でOcclusionに引っかかりづらい位置のもの • Instancing系の機能 •大きいサイズのモデル（BoundingBoxの大きいもの） • 極端にポリゴン数が多いモデル。(数十万など) これらには十分注意が必要です。 カリング効率が悪いオブジェクト達が増えるとポリゴン数がボ トルネックになる事はおおいにあり得ます。 シーンのポリゴン数を気にする
- 126.
- 127.
- 128.
- 129.
- 130.
- 131.
- 132.
- 133.
- 134.
- 135.
- 136.
- 137.
- 138.
- 139.
- 140.
- 141.
- 142.
- 143.
- 144.
- 145.
- 146.
- 147.
- 148.
- 149.
- 150.
- 151.
- 152.
- 153.
- 154.
- 155.
- 156.
- 157.
- 158.
- 159.
- 160.
- 161.
- 162.
- 163.
- 164.
- 165. #ue4fest#ue4fest • つまり、最適化の効果は・・・・ エンジニアだけが対応 →効果小 グラフィッカーも協力 → 効果中 設計段階から考慮 → 効果大 最適化の影響と効果
- 166.
- 167.
- 168.
- 169.
- 170.
- 171.
- 172.
- 173.
- 174.
- 175.
- 176.
- 177. #ue4fest#ue4fest • ステージの端から見ると重くなりやすい • アセットに必要以上に近づく •ありえないくらいに敵を生成 開発においてはイレギュラーとして除外するラインを決めて おく。 おおよそ主要なプレイにのっとった視点でのチェックを行う ことで、無駄の無い軽量化の調査が可能 イレギュラーをどこまで許容する？
- 178.
- 179. #ue4fest#ue4fest 恐らく皆様お悩みの事と思われます • エフェクトはピクセルのレンダリング数が多くなりやすい。 - 半透明は重複で描き込みが行われる -目立つエフェクトは表示面積も大きい - 発注されるエフェクト数も多い 作業コストを減らした作りは、相対的に重いエフェクトに なりがち。 逆に言えば、実行コストを下げるためには試行錯誤や丁寧 な仕事が必要なため時間がかかる。 (時間があっても雑に対応される事も・・・)
- 180.
- 181.
- 182.
- 183. #ue4fest#ue4fest • 余白はなるべく少なく • 明るさをはっきりとさせる。 •パーティクルのαに1.0以上を入力 概ねテクスチャと乗算することになるので、開始が1.0未満だ と想定より薄く出る。 テクスチャはキャンバスのぎりぎりまで 使う。
- 184.
- 185.
- 186.
- 187.
- 188.
- 189.
- 190. #ue4fest#ue4fest • 比較 Particle側 =0.46ms 板で作成した煙 = 0.06ms と圧勝でした。 マテリアル単体の負荷は増えても、一枚の板を十分な情報量 にする事でビルボードの数を減らし、結果的に負荷を減らす 事ができました。。 ここでのトレードオフは見た目ではなく手間です。 マテリアル自体は重そうでも
- 191.
- 192.
- 193.
- 194.
- 195.
- 196.
- 197.
- 198.
- 199. #ue4fest#ue4fest • OverDrawを最小に • Lightの範囲、光量を適切に RadiusScaleをいくら広げても光量は変わらないので、意図 した広さを照らせているか、意図した数で出ているかは絶対 に確認 •Refractionを乱用しない • パーティクルの数≒クオリティではない まとめ
- 200.
- 201.
- 202. #ue4fest#ue4fest • AmbientOcclusion • DOF •TAA • MotionBlur • SSR • AtmosphereFog • CapsuleShadow • ExponantialHeightFog 主に使われるもの
- 203.
- 204.
- 205.
- 206. #ue4fest#ue4fest • VelocityTextureを展開するVelocity Flattenが高負荷 •追加コストとしてRenderVelocityがある TAAが有効か、MortionBlurが有効だとPer Bone MotionBlur が有効なオブジェクトがVelocityを書き込みに行く。 シノビストライカーではCharacterのLODが2からは RenderVelocityをSkip。 MotionBlurは負荷が高かったうえに、画面のイメージに合わ ないという事でオミット。 MotionBlur
- 207.
- 208.
- 209.
- 210.
- 211.
- 212.
- 213.
- 214.
- 215.
- 216. #ue4fest#ue4fest • コンソール付属のProfiler それぞれのコンソールを解析するのに最も適しています。 • Statstartfile,Stat stopfile コンソール付属のものよりは大雑把に負荷調査が出来ます。 ただしスレッドの流れが追いづらい・・・。 • Stat その他 大雑把にトリアージするには大変有効。 • その他 VisualStudio 付属のProfiler等・・・ CPUの負荷調査
- 217. #ue4fest#ue4fest • 4.23から実行可能なCPU Profiler 各スレッドのTimeLineや依存関係が見やすくなりました。 Engine/Binaries/Win64/UnrealInsight.exe を起動して、該当マシンに繋いだ後、タイトルの実行ファイ ルを-cpuprofilerTraceを付けて起動するとUnrealInsightで 計測可能な状態になります。 詳しくは公式の動画をご覧ください。 Unreal Insight
- 218. #ue4fest#ue4fest • Engine/Source/Runtime/Core/Public/Misc/Build.h をいじっておくと良いと思います。 Testビルドでも色々計測できるようにする を行う,もしくは #ifndef FORCE_USE_STATS #defineFORCE_USE_STATS UE_BUILD_TEST #endif 個人的にはFORCE_USE_STATSの方がSTATS関係の使える幅 が広くて使い勝手が良かった。DO_CHECKはオミットされてる ので負荷は最小限のままです。 TestBuildで計測するために
- 219.
- 220.
- 221. #ue4fest#ue4fest • Overlap • CharacterMovement •UpdateComponentToWorld • RayCast • Animation Characterを動かす時によく負荷になる 部分
- 222.
- 223.
- 224. #ue4fest#ue4fest • 必要なものだけGenerateOverlapを行う。 不用意に有効にしたまま忘れるケースも・・・。 • UpdateOverlaps on Animation Finalize をUncheck Animation直後にOverlapが必要なければ切っても大丈夫です。 • Overlapで収集する対象を最小限にする ＊SetActorLocateやTickによる移動などではOverlapが追 加発生するので注意。(後述致します。) 軽量化の候補
- 225. #ue4fest#ue4fest • SkeletalMeshComponentにフラグがあります。 Update Overlapson Animation Finalize
- 226.
- 227.
- 228.
- 229.
- 230.
- 231.
- 232.
- 233.
- 234.
- 235.
- 236.
- 237.
- 238.
- 239.
- 240.
- 241.
- 242.
- 243.
- 244.
- 245. #ue4fest#ue4fest • UCharacterMovementComponent::PhysWalking while ((remainingTime >= MIN_TICK_TIME) && (Iterations < MaxSimulationIterations) &&・・・ こんな感じになっていて、Iterations < MaxSimulationIterations の条件から何度も Iterationしているようです。 このMaxSimulationIterationsは名前の通り、シミュレーションの反復回数の最大 で、ヒット判定を最大でこの回数分繰り返します。 下げるのには不安がありますが、Projectileなどでは半分の4が指定されていたりする。 恐らくゲームによって調整を行ってもいいはず。 C++だと
- 246.
- 247.
- 248.
- 249.
- 250.
- 251. #ue4fest#ue4fest • SetActorLocation,SetActorRotation できるだけまとめて、FScopedMovementUpdateを使い遅延 させるようにする。 • 座標があまり必要のないものは座標的な依存関係をつけない。 (KeepWorldにする等) •必要な時だけアタッチされるようにする。 攻撃に使うヒット用オブジェクトが、コリジョン切ってる間 も親子関係がついてるケースがあった・・・。 UpdateComponentToWorldのまとめ （こちらは正攻法しかないので）
- 252.
- 253.
- 254.
- 255.
- 256. #ue4fest#ue4fest • 判定を取る距離が長いほど負荷に 検索範囲が広がるため負荷になります。 • FCollisionQueryParamsを確認 特にbTraceComplexが有効だと、詳細コリジョンの判定もと ってしまうので、簡易なもので良いのであればこちらはfalse。 •FCollisionObjectQueryParamsを確認 必要最小限のものと判定を取れるように、用途に応じて CollisionChannelは設計する。(適当に取らない) 他にも注意点
- 257.
- 258.
- 259.
- 260.
- 261. #ue4fest#ue4fest • Boneのシミュレーションの可否 • 見えてない時のBoneの更新 •Pose同士の補間（ブレンド数で負荷が増大） • BoundingBoxをアニメーションと同期させるのか？ 等々・・・・。 他にも（Epic様の資料に大体書いてあり ますが・・・）
- 262.
- 263.
- 264.
- 265.
- 266.
- 267.
- 268. #ue4fest#ue4fest メモリに対する思い込み 思い込みでメモリを気にしない例 • 今どき気にする人なんて PS2世代の老人たちでし ょ？ • 何GBなんてメモリ使い切れ る訳無いじゃん。(古くは数 MBの時代にも同じセリフが あった・・・) 思い込みでメモリを気にする例 •変数削らなきゃ文字列削ら なきゃ • テクスチャを低解像度にし なきゃ、ポリゴン減らさな きゃ
- 269.
- 270.
- 271. #ue4fest#ue4fest • TemporalAA ≒15MB(使ってる個所次第でもっと) •DOFFullResSetup ≒15MB • ScreenSpaceReflections ≒ 15MB • CustomDepth ≒10MB • SceneDepthZ≒10MB ・・・等々 トータルで180MB前後 瞬間的に取る量が増え る事もあるため、Poolしておくバッファとしてはもっと必要 になる。 RenderTarget シーンが1080pの場合
- 272.
- 273. #ue4fest#ue4fest • BC5 :4096x4096 mip 13 ≒ 21MB • BC7 : 4096x4096 mip 13 ≒ 21MB • DXT5:4096x4096 mip 13 ≒ 21MB • DXT1:4096x4096 mip 13 ≒ 10MB • G8 : 4096x4096 mip 13 ≒ 21MB • RGBA8:4096x4096 mip13 ≒ 86MB ＊ただしこれはmipが全部読み込まれた場合のもの,実際には Streamerが読み込むmipを制御 テクスチャのメモリ 使用例
- 274. #ue4fest#ue4fest • Total size:InMem ≒ 546.71 MB - B8G8R8A8 size: InMem ≒ 72.91 MB - DXT1 size: InMem ≒ 96.60 MB - DXT5 size: InMem ≒ 187.54 MB - FloatRGBA size: InMem ≒ 37.34 MB - BC5 size: InMem ≒ 69.82 MB - BC7 size: InMem ≒ 77.42 MB 実際のシーンのテクスチャメモリ例
- 275. #ue4fest#ue4fest • 194376 ObjectsTotal: 147.278M 塵も積もればの場所ではありますが、何のclassが使っている かはよく確認。 地味にAnimSequenceはかなり大きかった。（80MBを占め ていた） 実際のシーンのclassオブジェクト
- 276.
- 277. #ue4fest#ue4fest • LOD0の△47246 :UV2ch: LOD3 2.1MB • LOD0の△21256 :UV 3ch: LOD2 1.1MB • LOD0の△15360 :UV 2ch: LOD3 1.2MB Meshのメモリ使用例：
- 278. #ue4fest#ue4fest • Static Mesh≒ 128MB • SkeletalMesh ≒ 20MB 実際のシーン
- 279. #ue4fest#ue4fest • NaviMesh • Collision •Animation • Physics • Sound Pool • Streamingのための予備バッファ 等々・・・・。 他にも
- 280.
- 281.
- 282.
- 283.
- 284.
- 285.
- 286.
- 287.
- 288. #ue4fest#ue4fest • RenderHellBook • ThePeak-Performance-Percentage Analysis Method for Optimizing Any GPU Workload • What is Limiting Your Rendering Performance? Using ‘Nsight Graphics: GPU Trace’ and the Peak-Performance- Percentage Method • life-triangle-nvidias-logical-pipeline • GPU-DRIVEN RENDERING • Mask Material only in Early Z-passの効果と仕組み • NSightCompute • NSight UserGuide • UnrealInsights • ＵＥ4アニメーションシステム総おさらい • UE4で多数のキャラクターを生かすためのテクニック 参考文献：