60fpsアクションを実現する秘訣を伝授 解析編
•
36 likes•28,254 views
講演動画：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 シノビストライカー」のグラフィック面の技術を紹介。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 60fpsアクションを実現する秘訣を伝授 解析編
Similar to 60fpsアクションを実現する秘訣を伝授 解析編 (20)
More from エピック・ゲームズ・ジャパン Epic Games Japan
More from エピック・ゲームズ・ジャパン Epic Games Japan (20)
60fpsアクションを実現する秘訣を伝授 解析編
- 1. #ue4fest#ue4fest 60fpsゲームのために 解析編 Winter Crown WORKS 梶井 祐 協力: ソレイユ株式会社 尾田 委久 協力: Winter Crown WORKS 石濃 潤一郎
- 2. #ue4fest#ue4fest • IndieGame Studio WinterCrownWORKSのプログラマー。 主に分野はグラフィックスプログラム。 仕事では各会社様からパフォーマンス関連のご相談を承って おります。 WinterCrownWORKSのアーティスト石濃、プログラマー梶 井で、アーティストとプログラマー両方の視点から改善案、 サンプル提供、エンジン改造などを行っております。 ご相談の際には contact@winter-crown-works.com までお気軽にご連絡ください。 梶井 祐
- 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-6700K 4GHz • グラフィックボード NVidia Geforce GTX 750 Ti • メモリ 64GB テストに使ったPCの構成
- 7. #ue4fest#ue4fest ProfilingTool • コンソールは各コンソール専用のものがある。 • PC側も様々なものがあり、お手軽なものから低レイヤーの値 を見るものまで。 -PIX -RenderDoc -NSight -Radeon GPU Profiler …等々
- 8. #ue4fest#ue4fest • より詳細な情報が得られる(情報の精度、範囲はProfiler次第) - どんなデータがセットアップされたのか、シェーダース テージ間では何が受け渡されているのか？ - 実際に描画されたポリゴン数は？ピクセル数は？ - 計算が重いのか？テクスチャのアクセスか？ Profilerで見ると何がいいの？
- 9. #ue4fest#ue4fest • ダウンロードしてすぐ試せる。 • 低レイヤー部分の調査が出来る。(根拠のために必要) • NVIDIA様のドキュメントやBlogで多くの情報が得られる。 低レイヤーの情報も多く載っている。 • 【今人気のプラットフォーム】の解析に近 い感覚 この度使うProfilerはNSight 2019.5
- 10. #ue4fest#ue4fest • NVIDIA 様のサイトより(翻訳)： NVIDIA Nsight Graphicsは、グラフィックアプリケーション のデバッグとプロファイリングのためのスタンドアロンアプ リケーションです。 Nsightは、DirectCompute、Direct3D（11、12、DXR）、 OpenGL、Vulkan（1.1、NV Vulkan Raytracing Extension ）、Oculus SDK、およびOpenVRで構築されたアプリケーシ ョンをサポートしています。 NSight
- 14. #ue4fest#ue4fest • Lightの置きすぎによるLighting負荷 • 広範囲に半透明を重ねすぎたOverDraw負荷 • 高解像度、テクスチャ枚数多すぎのマテリアル負荷 • PostProcessによるフィルター負荷 • 草原、森の作り方によるMaskedMaterial負荷 等々・・・・。 どんな問題がある？
- 15. #ue4fest#ue4fest • 大前提として - デバイスの性能を上回る事はない - デバイスの影響は必ず受ける デバイスの性能を使い切るために Profileingを行い正確な情報を得る。 ゲームエンジンを使用しても、なんでも お任せとはいかない・・・。
- 17. #ue4fest#ue4fest え？重いの？ • 4.16で入ったMask Material only in Early Z-pass使ったら 軽くなるんじゃなかったっけ？ 参考文献:Mask Material only in Early Z-passの効果と仕組 み • 抜きを使ったらポリゴン数少ないでしょ？軽いんじゃない の？
- 18. #ue4fest#ue4fest • Mask Material only 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 の実行 MaskMaterialOnly in Early Z pass未使用 • Prepass(Masked又は描画 しない) • BasePass(Masked) • ShadowDepth(Masked) MaskMaterialOnly in Early Z pass使用 • Prepass(Masked) • BasePass(Opaque) • ShadowDepth(Masked)
- 23. #ue4fest#ue4fest • Prepass 1.34ms • ShadowDepth 1.42ms • BasePass 2.31ms 負荷の内訳
- 27. #ue4fest#ue4fest • DrawCall Count 1 Profileをかけた範囲で発生したDrawCallが1つ。 • API Primitive Total / Avg 投入されたポリゴン数の合計 / DrawCall辺りの平均 • Shaded Pixel Total / Avg ピクセルシェーダーの動作したフラグメント数 / DrawCall辺 りの平均 ＊PrepassでOpaqueマテリアルは 0 で計上される。（PDO を使ってない場合） RangeInfo
- 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 理論値に対する達成率 ＧＰＵ ユニット
- 32. #ue4fest#ue4fest • SOL TEX 100% , ZROP 42.9% , SM 21.9% , L2 20.8% TEXユニットへのアクセスが理論値最大で出ている。(テクス チャアクセスによって速度が制限されている可能性が高い) ZROPが高いのはPrepassは深度の構築なため深度に対する書 き込み、読み込みが多いため。 SMは若干低い気がする。 次にシェーダーの実行周りを見てみる まず見るべき場所
- 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の動作
- 43. #ue4fest#ue4fest PrepassはMaskedの面積はそのまま負荷 に • 深度の裏に回った分もすべて負荷になる。 Maskedでレンダリングする際には、画面で見えてる以上に負 荷が高い という事に注意が必要。 今回の場合FS Invocationsが非常に多く、その上で TextureAccessも多い状態。 FS Invocationsはピクセルシェーダーが呼び出された数。
- 48. #ue4fest#ue4fest • Prepass が 1.34ms→0.83ms へ。 Mask部分に関して言えば0.55msと約半分に。 LODの分DrawCallは増えているものの軽量に。 計測してみる
- 49. #ue4fest#ue4fest • FS Invocationsが半分以下。 つまり単純に処理の総量が減っている。TEXが100%、Stall Long ScoreBardが高いのはMaskなので仕方ない。(Prepass全体では下がってる) MaskedMaterialそのものが軽くなった わけではないが・・・
- 50. #ue4fest#ue4fest • Mask Material only in early – Z-passを使っても注意が必要 • 重なる面積は最小に • 抜きの形状を綺麗にとるかどうかは配置数やシーン全体のポ リゴン数と相談 • 出来るだけ不必要なMaskを避ける 親マテリアルを意図せずMaskedMaterialで作っただけなんて いうケースも・・・。 Prepass まとめ
- 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のまとめ
- 67. #ue4fest#ue4fest • 草原 • 森 • オブジェクトのカメラフェード これらのシチュエーションは負荷がかかる筆頭です。 もし大量に配置が必要な場合、なんらかの方法を確立したり コストをかけないとクオリティを下げる結果になりやすい。 ＊よく誤解がありますが、InstancingやFoliageを使っても ピクセルシェーダーの負荷は特別軽くなったりはしません。 Maskedで気を付けるシチュエーション
- 71. #ue4fest#ue4fest 負荷が重いケース 頂点シェーダー • 頂点シェーダーの負荷 - ポリゴン数の超過 - 頂点アトリビュートのデータサイズ 頂点座標やUV等のデータ。UE4だと主にUV部分や SkeletalMeshかStaticMeshかで可変する。 - シェーダーステージ間のデータサイズ カスタムUVで拡張、PixelShaderで使用される最大UVイン デックス(どういう事かは後述します)
- 72. #ue4fest#ue4fest 負荷が重いケース ピクセルシェーダー • ピクセルシェーダーの負荷 - 計算量が多い(ALU,FMA,FP16) - テクスチャアクセスが多い,大きいmipへのアクセス - 冗長なTexturFormatが使われている - RenderTargetのFormatが冗長 - PixelShaderの動く面積が広い - LateZの実行(PixelDepthOffset) - マイクロポリゴン、細長いポリゴンが多い
- 74. #ue4fest#ue4fest • まず簡単なモデルデータのBasePassがどうNSightで解析で きるのか見てみます。 注目するデータ：消火栓モデル ポリゴン数 29,014 ＵＶチャンネル 2 マテリアル：BC,Normal,MRの3枚 構成
- 80. #ue4fest#ue4fest • SM Activeの割合が若干低い SM Occpancyも低く、シェーダーの実行効率が悪そう。 • Long ScoreBoardが高い L1の命令キュー待ちが多いほど高くなる。 (SM Occpancyが低くなってる原因ではないか？) • FS Invocationの値を見ると実行されているスレッド数が多い マイクロポリゴンが発生していないか？ 値をそれぞれ検討してみる。
- 81. #ue4fest#ue4fest • L1 Cache Vertexのフェッチ、次のシェーダーステージへのアウトプッ ト、Textureのフェッチ時等でアクセスされる。 • L2 Cache L1でフェッチにミスするとアクセスが発生。 メモリアクセス時に頻繁にアクセスされる。 ちょっとユニットの補足
- 84. #ue4fest#ue4fest • Opaqueにも関わらず3,4回もOverDrawされている個所があ る。 恐らく画面にOutPut出来ていないポリゴンもある。 OverDrawも発生する。
- 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のコード
- 94. #ue4fest#ue4fest • 以前のTOP SOL は TEX が56.5%,SMが56.1% TOP SOLの順位が変わっている
- 96. #ue4fest#ue4fest • Long Scoreboard 、Tex Throttle 共に下がっている。 テクスチャアクセスを減らしたことでL1の待機が減ったと思 われる。(TEXのSOLも下がっている事が確認できた) • FS Invocationが下がっている。 見た目の面積は一緒だが、マイクロポリゴンやOverDrawが 減った事により、ピクセルシェーダーの実行が減っている。 • SM Active Min/Maxも少し上がっている 多少シェーダーユニットの並列性が上がったものと思われる。 考察
- 99. #ue4fest#ue4fest • できるだけ低いmipへのアクセス 必要がなければTextureの解像度を下げる • 単色やグラデーションだけのテクスチャはパラメーターに置 き換える • TextureFilterを必要最小限に Anisotropyを低いレベルに指定する等でもう少し改善は出来 ると思われます。 TEXの軽量化
- 101. #ue4fest#ue4fest • 最近、結構誤解がある と感じたので軽くImposter Bakerに 触れておきます。 こちらはモデルを多方面からキャプチャした画像を使い、視 点方向に合わせたテクスチャを選択し、補間を行い、板ポリ でモデルを表現するような手法になります。 オマケ：Imposter Baker
- 105. #ue4fest#ue4fest まずはRendering時間の比較 Imposter Prepass+BasePass=0.047ms Model Prepass+BasePass=0.022ms
- 112. #ue4fest#ue4fest • TOP SOLのTEXの割合はImposterの方が高い そしてL2のHitRate 、SOLがImposterの方が低い。 角度補間のために同じテクスチャへのサンプリングが多く、 キャッシュミスが多いためと思われる。 • ShortScoreBoardがImposterの方がかなり高い。 恐らくUVを求めるための計算が非常に長い。 • FS InvocationsもImposterの方が高い。 つまり上記二点のボトルネックがあるにも関わらずピクセル シェーダーの実行数も多い 一見するとImposterの方が効率良さそう に見えるが・・・
- 116. #ue4fest#ue4fest • 頂点がシーンのボトルネックのケース • 表示領域が十分に小さい事,見る方向を変化させてもできるだ け一定の大きさである事。 • 用途に合わせてマテリアルも最適化した方が良い。 PixelDepthOffsetの使用を最低限にしたり、ライティングの 有無。 Imposterを使う事が有効なケース
- 119. #ue4fest#ue4fest • 主に VertexShader → PixelShader で受け渡されるデータ このサイズが大きいとシェーダーの実行効率が落ちます。 PSが起動する際、このデータを読み取り終える必要があるた めです。 こちらは、PS内で使うUVが多い場合(CustomUVでの拡張も 含む)、Vertex InterpolaterノードでPixelShaderへデータを 受け渡した場合にサイズが増えます。 シェーダーステージ間のデータ
- 122. #ue4fest#ue4fest • 尚、CustomUVを使わなくてもTextureCood に入れた最大 の大きさのindexでoutputは拡張される 使用するレジスタ数が増えました。
- 123. #ue4fest#ue4fest • TextureAccess • マイクロポリゴン • RenderTargetのフォーマット • ポリゴン数が多いケースで、VS to PSのoutputParamaterの サイズ。 • 極端に多いポリゴン数 • PixelDepthOffset (UE4においてはBasePassでもHizが効く LateZの実行という感じ) 等々・・・・。 で、BasePassが重い原因って？
- 125. #ue4fest#ue4fest • シーン内のインスタンスが多いオブジェクト その上でOcclusionに引っかかりづらい位置のもの • Instancing系の機能 • 大きいサイズのモデル（BoundingBoxの大きいもの） • 極端にポリゴン数が多いモデル。(数十万など) これらには十分注意が必要です。 カリング効率が悪いオブジェクト達が増えるとポリゴン数がボ トルネックになる事はおおいにあり得ます。 シーンのポリゴン数を気にする
- 165. #ue4fest#ue4fest • つまり、最適化の効果は・・・・ エンジニアだけが対応 → 効果小 グラフィッカーも協力 → 効果中 設計段階から考慮 → 効果大 最適化の影響と効果
- 177. #ue4fest#ue4fest • ステージの端から見ると重くなりやすい • アセットに必要以上に近づく • ありえないくらいに敵を生成 開発においてはイレギュラーとして除外するラインを決めて おく。 おおよそ主要なプレイにのっとった視点でのチェックを行う ことで、無駄の無い軽量化の調査が可能 イレギュラーをどこまで許容する？
- 179. #ue4fest#ue4fest 恐らく皆様お悩みの事と思われます • エフェクトはピクセルのレンダリング数が多くなりやすい。 - 半透明は重複で描き込みが行われる - 目立つエフェクトは表示面積も大きい - 発注されるエフェクト数も多い 作業コストを減らした作りは、相対的に重いエフェクトに なりがち。 逆に言えば、実行コストを下げるためには試行錯誤や丁寧 な仕事が必要なため時間がかかる。 (時間があっても雑に対応される事も・・・)
- 181. #ue4fest#ue4fest OverDrawを減らしたらクオリティは下 がる？ • 作成済みのものから、ただパーティクル数を減らした場合は そうなるかも知れませんが、ただし、重ねただけのものでク オリティと呼んでいいのでしょうか？ • OverDrawの原因は正しく解析できているでしょうか？ テクスチャの作りに無駄は？ • 重なった分の効果がちゃんと出ているのか？
- 183. #ue4fest#ue4fest • 余白はなるべく少なく • 明るさをはっきりとさせる。 • パーティクルのαに1.0以上を入力 概ねテクスチャと乗算することになるので、開始が1.0未満だ と想定より薄く出る。 テクスチャはキャンバスのぎりぎりまで 使う。
- 190. #ue4fest#ue4fest • 比較 Particle側 = 0.46ms 板で作成した煙 = 0.06ms と圧勝でした。 マテリアル単体の負荷は増えても、一枚の板を十分な情報量 にする事でビルボードの数を減らし、結果的に負荷を減らす 事ができました。。 ここでのトレードオフは見た目ではなく手間です。 マテリアル自体は重そうでも
- 199. #ue4fest#ue4fest • OverDrawを最小に • Lightの範囲、光量を適切に RadiusScaleをいくら広げても光量は変わらないので、意図 した広さを照らせているか、意図した数で出ているかは絶対 に確認 • Refractionを乱用しない • パーティクルの数≒クオリティではない まとめ
- 202. #ue4fest#ue4fest • AmbientOcclusion • DOF • TAA • MotionBlur • SSR • AtmosphereFog • CapsuleShadow • ExponantialHeightFog 主に使われるもの
- 206. #ue4fest#ue4fest • VelocityTextureを展開するVelocity Flattenが高負荷 • 追加コストとしてRenderVelocityがある TAAが有効か、MortionBlurが有効だとPer Bone MotionBlur が有効なオブジェクトがVelocityを書き込みに行く。 シノビストライカーではCharacterのLODが2からは RenderVelocityをSkip。 MotionBlurは負荷が高かったうえに、画面のイメージに合わ ないという事でオミット。 MotionBlur
- 210. #ue4fest#ue4fest • シノビストライカーではすべてのステージで使用。 HeightFogのみの用途であれば比較的低負荷のため、許容。 ExponentialHeightFog
- 216. #ue4fest#ue4fest • コンソール付属のProfiler それぞれのコンソールを解析するのに最も適しています。 • Stat startfile,Stat stopfile コンソール付属のものよりは大雑把に負荷調査が出来ます。 ただしスレッドの流れが追いづらい・・・。 • Stat その他 大雑把にトリアージするには大変有効。 • その他 VisualStudio 付属のProfiler等・・・ CPUの負荷調査
- 217. #ue4fest#ue4fest • 4.23から実行可能なCPU Profiler 各スレッドのTimeLineや依存関係が見やすくなりました。 Engine/Binaries/Win64/UnrealInsight.exe を起動して、該当マシンに繋いだ後、タイトルの実行ファイ ルを-cpuprofilerTraceを付けて起動するとUnreal Insightで 計測可能な状態になります。 詳しくは公式の動画をご覧ください。 Unreal Insight
- 218. #ue4fest#ue4fest • Engine/Source/Runtime/Core/Public/Misc/Build.h をいじっておくと良いと思います。 Testビルドでも色々計測できるようにする を行う,もしくは #ifndef FORCE_USE_STATS #define FORCE_USE_STATS UE_BUILD_TEST #endif 個人的にはFORCE_USE_STATSの方がSTATS関係の使える幅 が広くて使い勝手が良かった。DO_CHECKはオミットされてる ので負荷は最小限のままです。 TestBuildで計測するために
- 221. #ue4fest#ue4fest • Overlap • CharacterMovement • UpdateComponentToWorld • RayCast • Animation Characterを動かす時によく負荷になる 部分
- 224. #ue4fest#ue4fest • 必要なものだけGenerateOverlapを行う。 不用意に有効にしたまま忘れるケースも・・・。 • Update Overlaps on Animation Finalize をUncheck Animation直後にOverlapが必要なければ切っても大丈夫です。 • Overlapで収集する対象を最小限にする ＊SetActorLocateやTickによる移動などではOverlapが追 加発生するので注意。(後述致します。) 軽量化の候補
- 225. #ue4fest#ue4fest • SkeletalMeshComponentにフラグがあります。 Update Overlaps on Animation Finalize
- 245. #ue4fest#ue4fest • UCharacterMovementComponent::PhysWalking while ( (remainingTime >= MIN_TICK_TIME) && (Iterations < MaxSimulationIterations) &&・・・ こんな感じになっていて、Iterations < MaxSimulationIterations の条件から何度も Iterationしているようです。 このMaxSimulationIterationsは名前の通り、シミュレーションの反復回数の最大 で、ヒット判定を最大でこの回数分繰り返します。 下げるのには不安がありますが、Projectileなどでは半分の4が指定されていたりする。 恐らくゲームによって調整を行ってもいいはず。 C++だと
- 251. #ue4fest#ue4fest • SetActorLocation,SetActorRotation できるだけまとめて、FScopedMovementUpdateを使い遅延 させるようにする。 • 座標があまり必要のないものは座標的な依存関係をつけない。 (KeepWorldにする等) • 必要な時だけアタッチされるようにする。 攻撃に使うヒット用オブジェクトが、コリジョン切ってる間 も親子関係がついてるケースがあった・・・。 UpdateComponentToWorldのまとめ （こちらは正攻法しかないので）
- 253. #ue4fest#ue4fest • LineTraceMultiByChannel をたくさん呼び出してみたのですが、全部GameThreadに直 列になっております。 たくさん呼び出してみました。
- 256. #ue4fest#ue4fest • 判定を取る距離が長いほど負荷に 検索範囲が広がるため負荷になります。 • FCollisionQueryParamsを確認 特にbTraceComplexが有効だと、詳細コリジョンの判定もと ってしまうので、簡易なもので良いのであればこちらはfalse。 • FCollisionObjectQueryParamsを確認 必要最小限のものと判定を取れるように、用途に応じて CollisionChannelは設計する。(適当に取らない) 他にも注意点
- 261. #ue4fest#ue4fest • Boneのシミュレーションの可否 • 見えてない時のBoneの更新 • Pose同士の補間（ブレンド数で負荷が増大） • BoundingBoxをアニメーションと同期させるのか？ 等々・・・・。 他にも（Epic様の資料に大体書いてあり ますが・・・）
- 268. #ue4fest#ue4fest メモリに対する思い込み 思い込みでメモリを気にしない例 • 今どき気にする人なんて PS2世代の老人たちでし ょ？ • 何GBなんてメモリ使い切れ る訳無いじゃん。(古くは数 MBの時代にも同じセリフが あった・・・) 思い込みでメモリを気にする例 • 変数削らなきゃ文字列削ら なきゃ • テクスチャを低解像度にし なきゃ、ポリゴン減らさな きゃ
- 271. #ue4fest#ue4fest • TemporalAA ≒15MB(使ってる個所次第でもっと) • DOFFullResSetup ≒15MB • ScreenSpaceReflections ≒ 15MB • CustomDepth ≒10MB • SceneDepthZ≒10MB ・・・等々 トータルで180MB前後 瞬間的に取る量が増え る事もあるため、Poolしておくバッファとしてはもっと必要 になる。 RenderTarget シーンが1080pの場合
- 272. #ue4fest#ue4fest • テクスチャ解像度やフォーマット、読み込まれるmipに依存 • StreamingTexturePool TextureStreamに必要でフレキシブルなメモリ管理を行う。 sg.TextureQuality次第で400MB～3000MB(デフォルトがコ ンソールでsg.TextureQuality 2、PCで3なので800MB～ 1000MBが通常とられている) テクスチャメモリ
- 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 Objects Total: 147.278M 塵も積もればの場所ではありますが、何のclassが使っている かはよく確認。 地味にAnimSequenceはかなり大きかった。（80MBを占め ていた） 実際のシーンのclassオブジェクト
- 277. #ue4fest#ue4fest • LOD0の△47246 :UV 2ch: 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のための予備バッファ 等々・・・・。 他にも
- 282. #ue4fest#ue4fest 総括
- 288. #ue4fest#ue4fest • RenderHellBook • The Peak-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で多数のキャラクターを生かすためのテクニック 参考文献：