UE4で多数のキャラクターを生かすためのテクニック【CEDEC 2018】

204.8K Views

August 23, 18

スライド概要

CEDEC2018の講演資料を公開します。

profile-image

Unreal Engineを開発・提供しているエピック ゲームズ ジャパンによる公式アカウントです。 勉強会や配信などで行った講演資料を公開しています。 公式サイトはこちら https://www.unrealengine.com/ja/

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

UE4で多数のキャラクターを活かすためのテクニック Epic Games Japan / Support Engineer Ken Kuwano #UE4CEDEC

2.

はじめに • SNS上での情報の公開はOK • 本資料は講演後できるだけ早めに公開 • 本講演の内容はUE4.20で検証 • 中辛エンジニア向け #UE4CEDEC

3.

#UE4CEDEC イメージ

4.

#UE4CEDEC 現実

5.

ActionRPGのSampleを使って キャラクターをたくさん出してみよう #UE4CEDEC

6.

PC-Test 100体 #UE4CEDEC

7.

PC-Test 1000体 #UE4CEDEC

8.

PC-Test 1000体 #UE4CEDEC

9.

PC-Test 10000体 #UE4CEDEC

10.

話すこと • CPUパフォーマンスの改善方法 – 主にGameの負荷改善について CPU • 多くのキャラクターを出す際のポイント – 懸念点や負荷になりがちな点について • キャラクターと関連する機能の仕組み – 処理の流れ、設定や実装などの細かい話について #UE4CEDEC

11.

話さないこと • GPUパフォーマンスの改善方法 • キャラクターの作り方、Engine改造について • このスライドの50% #UE4CEDEC

12.

本題に入る前に 認識合わせと理解を深めるため キャラクターやCPUの動作についてのおさらい #UE4CEDEC

13.

おさらい • Characterとは • CPUの動作 • CPUのパフォーマンス計測 #UE4CEDEC

14.

Characterとは 継承 配置や生成できる #UE4CEDEC Character Pawn Actor 継承 配置や生成できて、 入力操作を受け付ける 配置や生成できて、 入力操作を受け付けて、 ジャンプなどが可能

15.

キャラクターに関連する機能 Animation Physics Navigation&AI Movement Movement Character タイトルによってキャラクターが実現する内容が異なる #UE4CEDEC

16.

CPUの動作 様々な機能を持つ複数のスレッドで動作 スレッド名 概要 Game ゲームのメイン処理 Task Graph Game の補助的役割、複数スレッド Pool Texture Streaming等、複数スレッド Rendering RHIコマンド(描画コマンド)を発行 RHI RHIコマンドをGPUに転送 CPUで動作する代表的なスレッドと概要 #UE4CEDEC

17.

CPUの動作の流れ (60fpsのモデルケース) 0.0 ms 16.6 ms Frame1 (16.6ms) 33.3 ms Frame2 (16.6ms) Frame3 Game 処理 待機 Task Graph 時間 時間内に処理が収まっているので遅延が無く理想的 #UE4CEDEC

18.

CPUの動作の流れ (60fpsのモデルケース:詳細) 0.0 ms 16.6 ms Frame1 (16.6ms) 33.3 ms Frame2 (16.6ms) Frame3 Game Third Person Template 1フレーム中の実行コスト Player Controller Character Character Movement Skeletal Mesh Animation キャラクター1体のコスト #UE4CEDEC Physics Slate HUD

19.

CPUの動作の流れ (Tick) ActorやComponentが毎フレーム実行する処理 Game Player Controller Character Character Movement Skeletal Mesh Animation キャラクター1体のコスト #UE4CEDEC Physics Slate HUD

20.

CPUの動作の流れ (Tick Group) Tick処理を行う順番を規定するグループ Actorなどが自身の処理タイミングを指定可能 Pre Physics Frame1 Pre Physics Character Game Character 処理 #UE4CEDEC Start Physics During Physics Post Physics End Physics Post Update Work

21.

CPUの動作の流れ (多数のキャラクターを出すケース) 0.0 ms 共通 Frame2 (16.6ms) キャラクター 共通 Frame3 キャラクター 16.6 ms 0.0 ms 共通 33.3 ms 共通 キャラクター キャラクター キャラクター キャラクター キャラクター 多数のキャラクターを扱う場合は キャラクター1体のコスト削減に注力する必要がある #UE4CEDEC キャラクター Frame1 キャラクター100体 Game 33.3 ms Frame1 (16.6ms) キャラクター1体 Game 16.6 ms キャラクター

22.

CPUのパフォーマンス計測 • 計測方法 – コンソールコマンド – プロファイリングツール (コンソールのみ) • 計測条件 – パッケージしたTestビルドを使用 • Epic Games LauncherからはTestビルドの作成不可 • 一部のコンソールコマンドのみ使用可能 • 出荷用ビルド(Shipping)に近い状態で計測可能 #UE4CEDEC

23.

CPUパフォーマンスはTestビルドで計測しましょう 昨年のセッションでも紹介していますのでご参考下さい #UE4CEDEC

24.

Testビルドでの制限を解除してデバッグする方法 Testビルドでのログ、コンソールコマンドを許可する方法が紹介されています http://darakemonodarake.hatenablog.jp/entry/2018/06/15/225956 #UE4CEDEC

25.

出荷用ビルドに近い状態で計測可能 Development Test CPU 製品に近い環境で計測することで 必要以上な負荷削減を減らす Third Person Templateで1000体を出した時の DevelopmentとTestのパフォーマンスを比較 #UE4CEDEC 過剰な最適化を減らすことで クオリティを維持

26.

おさらい:まとめ • Characterとは タイトルによってキャラクターが実現する内容が異なる • CPUの動作 多数のキャラクターを扱う場合はキャラクター1体のコスト削減に注力 • CPUのパフォーマンス計測 過剰な最適化を減らすことでコンテンツのクオリティを維持 実現する機能に併せてキャラクターを適切に最適化 #UE4CEDEC

27.

アジェンダ • • • • • • Animation Physics Navigation & AI Movement Networking その他 #UE4CEDEC

28.

各章の構成 タイトル 関連 おさらい 改善一覧 負荷ポイント 改善策 #UE4CEDEC

29.

[フォーマット] ユースケース、改善を行うケースの概要 負荷ポイント ● 何が行われているか、負荷ポイント 等 改善点 ● 改善方法、改善されることで得られる効果 等 備考 ● 改善を適用した際の副作用、注意点 等 #UE4CEDEC 概要図

30.

負荷ポイント/改善策 #UE4CEDEC

31.

評価 大きく負荷を減らすことができる 多数のキャラクターを出す場合は特に注意 それなりの負荷を減らすことができる 汎用的に使用することが可能 負荷を減らすことができる #UE4CEDEC

32.

誤解が無いために • 評価 – 実際のパフォーマンスへの影響はコンテンツの内容に依存 • 負荷ポイント/改善点 – 「減らすことを検討」などと記載している部分については「多 数のキャラクターを出すケース」で負荷になりがちな部分であ って、使用を禁止するものではありません #UE4CEDEC

33.

アジェンダ • • • • • • Animation Physics Navigation & AI Movement Networking その他 #UE4CEDEC

34.

Animation #UE4CEDEC

35.

CharacterとAnimation Event Graph Mesh Character #UE4CEDEC AnimBP Anim Graph

36.

おさらい:Animation 今年のセッションでも紹介していますのでご参考下さい #UE4CEDEC

37.

おさらい:Animation (処理の流れ) Frame Pre Physics Game Task Graph #UE4CEDEC Start Physics Complete Update Evaluate AnimNode更新 ポーズ確定 後処理

38.

改善ポイント一覧 (Animation) • • • 多数のキャラクターがアニメーションを行う 移動やアニメーションに伴うBounds更新1 移動やアニメーションに伴うBounds更新2 #UE4CEDEC

39.

改善ポイント一覧 (Animation) • • • • • • • • アニメーションの実行コスト削減1 アニメーションの実行コスト削減2 アニメーションの間引きによる更新コスト削減 アニメーションの評価コスト削減 アニメーションが不要なメッシュ LODによるメッシュのリダクション ステートマシンの検索コスト削減 アニメーションのマルチスレッド処理 #UE4CEDEC

40.

多数のキャラクターがアニメーションを行う 負荷ポイント ● 毎フレームアニメーションの更新を行うがキャラクター が多いとアニメーションのコストが嵩む 改善点 ● 非描画キャラクターのアニメーションの更新をスキップ することでアニメーション更新コストを削減 備考 ● オフスクリーンのキャラクターのアニメーション更新を スキップするので画面内にいる場合は無効となる #UE4CEDEC

41.

多数のキャラクターがアニメーションを行う ● 負荷ポイント 多くのキャラクターを出すとキャラクターのアニメーション更新コストが嵩む Update Anim 多数のキャラクターを出すと... #UE4CEDEC アニメーションの更新コストが増大

42.

多数のキャラクターがアニメーションを行う ● 改善策 非描画キャラクターのアニメーション更新をスキップ Update Anim 非描画時もアニメーション更新 #UE4CEDEC Skip Update Anim 非描画時は更新スキップ

43.

多数のキャラクターがアニメーションを行う アニメーションのスキップにより以降の処理コストを削減 Frame Game Task Graph #UE4CEDEC Skeletal Mesh Tick Complete Update 全てスキップ Evaluate

44.

移動やアニメーションに伴うBounds更新1 負荷ポイント ● 移動やアニメーションを行う際にキャラクターのBounds の位置を更新するための計算コストが嵩む 改善点 ● ComponentのBoundsの位置を親Componentと同じにす ることでBoundsの計算コストを削減 備考 ● ● Scene Componentの機能のため、殆どのComponentに 適用することが可能 Boundsの統合によりカリング範囲が変わるので注意 #UE4CEDEC

45.

移動やアニメーションに伴うBounds更新1 ● 負荷ポイント 移動やアニメーション時にComponentのBounds計算が行われる – Componentの数が多いほどBounds計算のコストが増加 #UE4CEDEC

46.

移動やアニメーションに伴うBounds更新1 ● 改善策 自身のBounds計算を行わず親のBoundsを使用することで計算コストを削減 #UE4CEDEC

47.

移動やアニメーションに伴うBounds更新1 Boundsの計算を親Componentに統合することでコスト削減 自身のBoundsを計算 #UE4CEDEC 親のBoundsを使用

48.

移動やアニメーションに伴うBounds更新2 負荷ポイント ● 移動やアニメーションを行う際にキャラクターのBounds の位置を更新するための計算コストが嵩む 改善点 ● Boundsの計算にSkeletal Mesh自身が持つ固定Boundsを 使用することでBoundsの計算コストを削減 備考 ● ● Skeletal Mesh Component に適用可能 Boundsの統合によりカリング範囲が変わるので注意 #UE4CEDEC

49.

移動やアニメーションに伴うBounds更新2 ● 負荷ポイント 移動やアニメーション時にComponentのBounds計算が行われる – Skeletal MeshはPhysics AssetからFitするBoundsを生成 – PhysicsのBody数が多いほど計算コストがかかる Skeletal Mesh #UE4CEDEC Physics Asset Bounds

50.

移動やアニメーションに伴うBounds更新2 ● 改善策 Skeletal Meshが持つ固定Boundsを使用することで計算コスト削減 PhysicsAssetベース(左) と 固定Bounds使用(右) の比較 #UE4CEDEC

51.

移動やアニメーションに伴うBounds更新2 • Boundsが大きいとCullingされにくくなるのでGPU負荷に注意 – 小さすぎても不用意にCullingされるので適切な調整を Boundsによるカリング #UE4CEDEC Boundsが大きいとカリングされにくい

52.

アニメーションのマルチスレッド処理 負荷ポイント ● アニメーションの更新をGame Threadで実行するとキャ ラクターが多いケースにおいてボトルネックになる 改善点 ● TaskGraph Threadで更新を行うことでGame Threadの 負荷を集中を避ける 備考 ● ● デフォルトでは並列処理が有効になっている 並列処理が適用されないケースがあるので注意 #UE4CEDEC

53.

アニメーションのマルチスレッド処理 ● 負荷ポイント 並列処理条件を満たさない場合はアニメーション更新Gameで実行 例:Root Motion設定で”Root Motion from Everything”を使用 Game Task Graph Complete Update Evaluate 並列化有効 #UE4CEDEC Update Complete Evaluate 並列化無効 Gameに処理集中

54.

アニメーションのマルチスレッド処理 ● 改善策 並列処理条件を満たすように実装する必要がある 並列処理が可能な条件 • • • • • Project Settingsで並列更新が許可されている Animation Blueprintで並列更新が許可されている コンソールコマンドで並列更新が強制されている Tickで提供されるDelta Secondsが0.0以外 ルートモーション(“Root Motion from Everything”)を使用していない #UE4CEDEC

55.

アニメーションのマルチスレッド処理 複数Task Graphで処理できればGameが効率的に処理可能 – 並列処理が無効になるとGameがボトルネックになる Game 別処理 Task Graph 1 Update Task Graph 2 Update 別処理 並列化有効 #UE4CEDEC Update 並列化無効 Update

56.

アニメーションの実行コスト削減1 負荷ポイント ● Animation BlueprintでBlueprint Nodeを毎フレーム実行 する場合、NodeやLogicが多いと実行コストがかかる 改善点 ● Animation Blueprintで行う複雑な処理やアクセス頻度が 高い処理はC++へ移行を検討 備考 ● Native化により保守性が低下するためパフォーマンス上 の負荷になる箇所からC++に移行するのが良い #UE4CEDEC

57.

アニメーションの実行コスト削減1 ● 負荷ポイント Blueprintでの処理はC++よりもVM(Blueprint呼び出し)コストがかかる #UE4CEDEC

58.

アニメーションの実行コスト削減1 ● 改善策 Blueprintでの処理はC++よりもVM(Blueprint呼び出し)コストがかかる 複雑なロジックやアクセス頻度が高い処理は出来るだけC++を利用 AnimBPをNative化することも可能だが、 Native化のコードも含むためパッケージサイズに影響 #UE4CEDEC

59.

アニメーションの実行コスト削減2 負荷ポイント ● Animation BlueprintでAnim Nodeの実行に時間がかか るとTask Graph Threadのコストに影響 改善点 ● Fast Path機能を利用することで高速なパスで実行可能 備考 ● ● Fast Pathが常時適用されるようにする Fast Pathの適用をチェックする警告設定がある #UE4CEDEC

60.

アニメーションの実行コストを削減2 ● 負荷ポイント Anim Graphでロジックによる演算を行うとFast Pathが適用されずに Task Graph Threadの処理コストに影響 ロジックがあるため Fast Path無効化 #UE4CEDEC Fast Path 無効

61.

アニメーションの実行コストを削減2 ● 改善策 Blueprintでロジックを処理しないことで高速パスでの実行が可能 Fast Path 有効 NG #UE4CEDEC OK

62.

アニメーションの実行コストを削減2 Clamp Nodeは利用ケースが多いがFast Pathを阻害してしまう – 4.20からAnim Node内でClampを処理することが可能 • 4.20まで Clamp Nodeを使用することで処理 Fast Pathを維持できない • 4.20から ClampをAnim Nodeで処理可能 Fast Pathを維持できる #UE4CEDEC

63.

アニメーションの実行コストを削減2 Anim Graphでロジックを実行したい場合はEventGraphで実行する – さらにC++に移行することでVMアクセスのコスト削減 #UE4CEDEC

64.

アニメーションの間引きによる実行コスト削減 負荷ポイント ● アニメーションを毎フレーム更新することでアニメーシ ョンの更新コストが嵩む 改善点 ● アニメーションの更新頻度を調整することでアニメーシ ョンの更新コストを抑制 備考 ● アニメーションの更新頻度はEditorに調整項目が公開され ていないのでC++で実装が必要 #UE4CEDEC

65.

アニメーションの間引きによる実行コスト削減 ● 負荷ポイント キャラクターの位置に関係なくアニメーションの実行コストは一律 – 遠方のキャラクターは描画の重要性が低いが実行コストは同じ カメラから遠い場合 重要性は低い カメラに近い場合 正確に描画 #UE4CEDEC

66.

アニメーションの間引きによる実行コスト削減 ● 改善策 UROを使用してアニメーションの更新頻度を調整することでコスト削減 – 遠く離れている場合など、アニメーションの精度が低い場合など有用 Editorに調整用パラメータは公開されていないためC++で調整が必要 – 最適な設定はプロジェクトに応じて調整 #UE4CEDEC

67.

アニメーションの評価コスト削減 負荷ポイント ● Anim Nodeが多く接続されていることは非同期処理の実 行コストが嵩む 改善点 ● Anim Nodeの利用を不用意に増やしすぎないことにより TaskGraph Threadの処理コストを抑制 備考 ● 処理が多いほどコストが掛かるのは当然だが、多数のキ ャラクターを扱う場合はTask Graphのコストも注意 #UE4CEDEC

68.

アニメーションの評価コスト削減 ● 負荷ポイント/改善策 Anim Nodeを多く利用することは実行コストが増える多用しすぎに注意 – 非同期で処理する場合もキャラクターが多いとコストが嵩む Update Game Task Graph Node1 Node2 Node3 Node4 Anim Nodeの更新コスト #UE4CEDEC

69.

アニメーションの評価コスト削減 “Layer Blend per Bone”Nodeの有無による処理コストの違い #UE4CEDEC

70.

アニメーションが不要なメッシュ 負荷ポイント ● アニメーションを必要としないキャラクターであっても アニメーションを実行することでコストが嵩む 改善点 ● 明示的にスケルトンを更新しないことでアニメーション 実行のフローをスキップすることでコスト削減 備考 ● Skeletal Meshが持つ各種設定を用途に応じて使い分ける #UE4CEDEC

71.

アニメーションが不要なメッシュ ● 負荷ポイント/改善策 • アニメーションが不要なケースではアニメーションを停止させておく – 見た目に変化が無い場合は明示的に停止して無駄なコストを抑止 アニメーションの更新停止 #UE4CEDEC

72.

アニメーションが不要なメッシュ Skeletal Meshの各種設定 • アニメーションの更新を停止 – Skeletal Meshの更新負荷を削減 • アニメーションの再生を停止 – 動的に変更が可能でTrueで更新を停止 • Static MeshのRenderingと同様の描画パスを使用 – 動的に変更が可能でアニメーションの更新を停止 #UE4CEDEC

73.

LODによるメッシュのリダクション 負荷ポイント ● ● キャラクターがカメラから近くにいても遠くにいてもア ニメーションを行う処理コストが一定 遠景にいる場合は処理を間引きたい 改善点 ● Skeletal MeshのLODを設定してBoneを削除することで コスト削減 備考 ● 特になし #UE4CEDEC

74.

LODによるメッシュのリダクション Skeletal MeshのLODを設定してBoneを削除することが可能 #UE4CEDEC

75.

ステートマシンの検索コスト削減 負荷ポイント ● 毎フレームステートマシンで評価を行うが遷移候補が多 いと検索コストが増加 改善点 ● 多くの検索を行わないようにステートマシンの遷移先を 細分化することで検索コスト削減 備考 ● 検索候補を減らすことも重要だがステートを減らすこと を意識してシンプルな実装を目指す #UE4CEDEC

76.

ステートマシンの検索コスト削減 ● 負荷ポイント State MachineのTransitionが多いと検索コストが増加 回避C 攻撃A 回避B 攻撃B 回避A 攻撃C Idle #UE4CEDEC

77.

ステートマシンの検索コスト削減 ● 改善策 Stateを細分化することで検索コストを下げる 回避B 回避C 攻撃A 回避A 攻撃B 攻撃C 回避 攻撃 Idle #UE4CEDEC

78.

アジェンダ • • • • • • Animation Physics Navigation & AI Movement Networking その他 #UE4CEDEC

79.

Physics #UE4CEDEC

80.

CharacterとPhysics 剛体 Rigid Body Mesh Physics Asset 衝突判定 Character Collision Capsule Collision #UE4CEDEC

81.

おさらい:Physics (Collision) オブジェクトの物理挙動のふるまい • • • Collision Query Physics #UE4CEDEC :QueryとPhysics :Raycast, Overlap, Sweepなどの空間クエリ :Rigid Body, Constraintなどの物理シミュレーション

82.

おさらい:Physics (Query Collision) • Raycast, Overlap, Sweepなどの空間クエリ – 衝突判定、当たり判定のようなイメージ Raycast #UE4CEDEC Overlap 判定は正確 実行コスト高め Sweep

83.

おさらい:Physics (Physics Collision) • Rigid Body, Constraintなどの物理シミュレーション – 重力に従った挙動のイメージ #UE4CEDEC

84.

おさらい:Physics (Physics Body) • UE4でのPhysicsの動作 – 物理エンジン(PhysX)で物理シミュレーションを行う – Physicsを扱う空間(Physics Scene)にPhysics Bodyが投入される UE4 Objectの生成や変化 シミュレーション結果 #UE4CEDEC PhysX Physics Body

85.

おさらい:Physics (Physics Body) • Physics Sceneに投入されたオブジェクトを確認する方法 – コンソールコマンド (“PXVIS SYNC COLLISION” など) – 専用ツール (PhysX Visual Debugger) PXVIS SYNC COLLISION コマンド #UE4CEDEC PhysX Visual Debugger

86.

おさらい:Physics (Query処理の流れ) Frame Pre Physics Game Raycast Trace Result PhysX 空間クエリはGame Threadで結果を待つ #UE4CEDEC

87.

おさらい:Physics (Physics処理の流れ) Frame Pre Physics Start Physics Game PhysX Wait End Physics Post Physics fetch Result simulate Objectの移動や投入が可能 #UE4CEDEC During Physics Simulation 非同期で物理シミュレーション実行 Wait

88.

改善ポイント一覧 (Physics) • • • • • • • PhysicsBodyのシミュレーションが多い Collision設定とパフォーマンス アニメーションに伴うPhysicsBodyのスケール同期 アニメーションに伴うPhysicsBodyの位置同期 オブジェクトのオーバーラップ検出 移動やアニメーションに伴うBounds更新3 非同期シーンを利用したRaycast #UE4CEDEC

89.

Physics Bodyのシミュレーションが多い 負荷ポイント ● 多くのPhysics Bodyを持つキャラクターが移動するケー スにおいて物理シミュレーションのコストが増加 改善点 ● Physics Bodyの数を出来るだけ増やさないことで、位置 同期の更新やシミュレーションの実行コストを削減 備考 ● Physics Bodyの数を厳密に管理して調整 #UE4CEDEC

90.

Physics Bodyのシミュレーションが多い ● 負荷ポイント 動いているPhysics Body数が多い時にPhysicsのfetchコスト増加 Frame 動いていない Game simulate fetch Result 動いている Game simulate fetch Result Physics Bodyのチェックコスト増 #UE4CEDEC

91.

Physics Bodyのシミュレーションが多い 動いていない Game PhysX #UE4CEDEC Frame fetch Result simulate Simulation

92.

Physics Bodyのシミュレーションが多い Frame 動いている Game PhysX #UE4CEDEC ActiveなBodyを全て走査して 継続しない場合は戻す Move fetch Result simulate Active Simulation Inactive

93.

Physics Bodyのシミュレーションが多い ● 改善策 Physics Bodyの数を出来る限り減らすことでPhysXへの更新を減らす #UE4CEDEC

94.

Physics Bodyのシミュレーションが多い ActiveなPhysics Body数の違いでのパフォーマンスを比較 #UE4CEDEC

95.

Physics Bodyのシミュレーションが多い Physics Body:19 (neckあり) Physics Body:18 (neckなし) Third Person Templateで1000体を出すと... #UE4CEDEC 約0.9ms 削減

96.

Physics Bodyのシミュレーションが多い • 静的なオブジェクトは物理シミュレーションに影響するか? – レベル上に多数のオブジェクトを配置した際の定常コスト Static Mesh Collision Destructible Mesh 殆ど影響なし 殆ど影響なし 影響する #UE4CEDEC

97.

Physics Bodyのシミュレーションが多い • Static Mesh、Collision – 配置しただけでは定常コストに影響しない – Movableでも動いていない場合は影響しない – 回転や移動時はシミュレーションが発生 • Destructible Mesh – 配置しただけで定常コストに追加 – 破壊発生のタイミングでのみ使用するなどで 定常時のシミュレーションコストを削減 #UE4CEDEC

98.

Collision設定とパフォーマンス 負荷ポイント ● 移動やRaycastを行う際にQuery and Physicsは空間クエ リ及び物理シミュレーションを行うため、Query Onlyや Physics Onlyと比較してコストになる 改善点 ● 用途に応じてQuery Only/Physics Onlyを適切に設定す ることで無駄な処理コストを削減 備考 ● No Collisionは物理処理のコストが一番安く、Query and Physicsは最もコストが高い #UE4CEDEC

99.

Collision設定とパフォーマンス ● 負荷ポイント Collision設定においてQueryとPhysicsの両方を適用するとコストが嵩む Query #UE4CEDEC Physics

100.

Collision設定とパフォーマンス ● 改善策 Collision設定の”Query Only”と “Physics Only”を使い分ける Capsule Collision Enabled (Query and Physics) ⇒ 衝突判定と物理シミュレーションが可能 Skeletal Mesh Query Only (No Physics Collision) ⇒ 衝突判定のみ検出が可能 #UE4CEDEC

101.

Collision設定とパフォーマンス 例:「キャラクターの部位判定が不要」なケースの場合... – – Skeletal Mesh は “No Collision” に設定 シーンに投入されなくなるので物理シミュレーションのコストが安くなる Skeletal Meshを “No Collision”に変更 #UE4CEDEC

102.

アニメーションに伴うPhysicsBodyの位置同期 負荷ポイント ● アニメーション再生時にPhysics Bodyを更新する際にボ ーンとPhysics Bodyの位置を同期する 改善点 ● Physics Bodyの同期処理をスキップすることで負荷削減 備考 ● 見た目とPhysics Bodyの位置が同期しなくなるので、ア ニメーションによる位置同期が不要な場合に有効 #UE4CEDEC

103.

アニメーションに伴うPhysicsBodyの位置同期 ● 負荷ポイント アニメーション再生時にボーンに付随するPhysics Bodyの位置を更新 – 所有するPhysics Bodyの数が多い程同期コストが嵩む #UE4CEDEC

104.

アニメーションに伴うPhysicsBodyの位置同期 ● 負荷ポイント Physics Bodyの位置同期をスキップすることで同期コストを削減 – 移動しないキャラクターなどPhysics Bodyの同期が不要な時に有効 ・Skip Simulating Bones (デフォルト) 物理シミュレーションを行うボーンのみ同期スキップ ・Skip All Bones 全てのボーンを対象に同期スキップ #UE4CEDEC

105.

アニメーションに伴うPhysicsBodyのスケール同期 負荷ポイント ● アニメーション再生時にPhysics Bodyのスケールを更新 することでボーンとPhysics Bodyのスケールを同期 改善点 ● Physics Bodyのスケール同期処理をスキップすることで 同期コスト分の負荷削減 備考 ● ボーンとPhysics Bodyのスケールが同期しなくなるため 、ボーンのスケールが動的に変わらない場合に有効 #UE4CEDEC

106.

アニメーションに伴うPhysicsBodyのスケール同期 ● 負荷ポイント アニメーション実行時にPhysics BodyのScaleスケールを更新 – ボーンのスケールとPhysicsを連動させるため x0.5 HeadのScaling #UE4CEDEC x1.0 x1.5 Bone Scaleに応じてPhysics Bodyも同期

107.

アニメーションに伴うPhysicsBodyのスケール同期 ● 改善策 アニメーション実行時のPhysics BodyのScale同期をスキップ – ランタイムでボーンスケールが変更しないケースなどで有効 x0.5 Scale同期スキップ #UE4CEDEC x1.0 x1.5 Bone ScaleとPhysics Bodyの同期をSkip

108.

アニメーションに伴うPhysicsBodyのスケール同期 Physics EditorからPhysics Body毎に指定することが可能 #UE4CEDEC

109.

移動やアニメーションに伴うBounds更新3 負荷ポイント ● 移動やアニメーションを行う際にキャラクターのBounds の位置を更新するための計算コストが嵩む 改善点 ● Boundsの計算に不要なPhysics Bodyを除外することによ ってBoundsの計算コストを削減 備考 ● 特になし #UE4CEDEC

110.

移動やアニメーションに伴うBounds更新3 ● 負荷ポイント 移動やアニメーション時にComponentのBounds計算が行われる – Skeletal MeshはPhysics AssetからFitするBoundsを生成 Skeletal Mesh #UE4CEDEC Physics Asset Bounds

111.

移動やアニメーションに伴うBounds更新3 ● 改善策 Boundsの計算にPhysics Bodyを指定して含まないことが可能 OFFでBounds計算から除外 両手・両足・頭 だけでも成立 #UE4CEDEC

112.

移動やアニメーションに伴うBounds更新3 Skeletal MeshのBounds計算は次の順で優先されます Physics Bodyが多いほど Boundsの計算コストが嵩む 優先 親Boundsと同期 #UE4CEDEC 固定Bounds Physics Assetから計算

113.

オブジェクトのオーバーラップ検出 負荷ポイント ● Overlapイベントを有効にした場合、Componentの移動 の度にOverlapテストを実行するのでコストが嵩む 改善点 ● Overlapが不要な場合はオフにすることで、移動時の頻繁 なOverlapの実行コストを削減 備考 ● オフにすると当然ながらOverlapイベントを検出しないた め、使用する場合はOverlapのON/OFFを制御するなど #UE4CEDEC

114.

オブジェクトのオーバーラップ検出 ● 負荷ポイント/改善策 Overlap Overlap Eventが有効時、移動の度にOverlap検出処理を実行 – Overlap検出を抑制することで移動時のコスト削減 Overlap Capsule Collisionの Generate Overlap Eventsが有効な場合 #UE4CEDEC Overlap 移動の度にOverlapテスト実行

115.

非同期シーンを利用したRaycast 負荷ポイント ● 足音を鳴らすためにRaycastを頻繁に利用するようなケー スにおいて、Raycastの多用がGameの負荷になる 改善点 ● 非同期Raycastを使用することでGameの負荷を削減 備考 ● 非同期Raycastは次フレーム移行で処理することから、同 期して処理する必要があるケースには向いておらず、全 ての処理を非同期で行えば良いとは限らない #UE4CEDEC

116.

非同期シーンを利用したRaycast ● 負荷ポイント/改善策 足音を鳴らすためのRaycastを頻繁に利用するとGameの負荷が嵩む – 非同期Raycastを使用することでGameの負荷集中を避ける ・非同期トレース用のAPIを使用 Raycast ・非同期シーンの使用を許可しておく #UE4CEDEC

117.

非同期シーンを利用したRaycast • 非同期シーン? – Physicsを扱う空間として3種類のPhysics Sceneが存在 #UE4CEDEC

118.

非同期シーンを利用したRaycast Physics SceneとPhysics Body • Sync Scene デフォルトで使用するシーン Static MeshやSkeletal Meshが投入 • Async Scene 非同期トレースで使用するシーン Static Mesh以外は任意で指定 • Static MeshとSkeletal Meshの シンプルなシーン #UE4CEDEC Cloth Scene Cloth simulation用のシーン

119.

非同期シーンを利用したRaycast Frame 同期Raycast ・Game Threadでトレースを実行 ・Game Threadで結果を待つ ・トレース完了後に足音を再生 Game PhysX Result Frame2 Wait Game Exec PhysX #UE4CEDEC Exec SE 再生 Frame1 非同期Raycast ・Game Threadで開始を通知 ・トレースは非同期で実行 ・足音は次のフレーム以降で再生 Trace Frame2 Trace Result SE 再生 Gameの負荷集中を避ける

120.

アジェンダ • • • • • • Animation Physics Navigation & AI Movement Networking その他 #UE4CEDEC

121.

Navigation & AI #UE4CEDEC

122.

CharacterとNavigation&AI Navigation Character Behavior Tree EQS #UE4CEDEC

123.

おさらい:Navigation&AI (Navigation) Navigation Meshを使ってキャラクター移動の経路探索 Navigation System 制御 Navmesh Volume 範囲 Recast Navmesh データ 構築 Navigation Mesh 経路探索 Character NavigationとCharacter #UE4CEDEC Navmesh Generator 生成

124.

おさらい:Navigation&AI (Behavior Tree) エージェントの行動パターンを定義 BlackBoard EQS データ Decorator 条件 Service 思考 構築 Behavior Tree 行動パターン Character Behavior TreeとCharacter #UE4CEDEC 情報収集 Task 処理

125.

おさらい:Navigation&AI (EQS) 行動選択においてレベルから最適な情報の収集 Context 対象 Generator 検索 構築 EQS 情報収集 Behavior Tree 行動パターン Character EQSとCharacter #UE4CEDEC Test 評価

126.

おさらい:Navigation & AI (処理の流れ) AIを使用したキャラクターが移動・行動する時の処理の一例 Frame Game Task Graph Pool Behavior Tree Update PathFinding BT更新 Navmesh Rebuild Navmesh生成 #UE4CEDEC Nav Octree Update 経路探索 Data更新

127.

改善ポイント一覧 (Navigation & AI) • • • • • • 移動に伴うNavOctreeの更新 EQSのQuery検索 BehaviorTreeの実行コスト削減 BehaviorTreeの動作制御 AI Perceptionの制御 AIControllerの制御 #UE4CEDEC

128.

移動に伴うNavOctreeの更新 負荷ポイント ● 移動時に所有する全てのComponentの情報をNavOctree に通知して更新するためNavOctreeの更新コストが嵩む 改善点 ● 動的なNavigation Meshの変化が無い場合は、 NavOctreeの更新を抑止することで移動時のコストを抑 制 備考 ● Navmeshを動的に再構築しない場合には更新不要 #UE4CEDEC

129.

移動に伴うNavOctreeの更新 ● 負荷ポイント キャラクターが移動時にNav Octreeの情報を更新する – 移動に伴い座標更新されたComponent数だけ更新を行う 更新 Nav Octree 移動に伴うComponent更新 #UE4CEDEC NavOctreeのComponent情報を更新

130.

移動に伴うNavOctreeの更新 • NavOctreeとは? – – Navigation Meshを高速に生成するためのデータ(Bounds/Collision/Voxel等) 移動が発生する度にActorやComponentの情報を更新 Nav OctreeのBounds表示 #UE4CEDEC Octree Details表示機能 (4.20から)

131.

移動に伴うNavOctreeの更新 ● 改善策 NavOctreeが持つComponent情報の更新を無効にする – 以下のどちらかをNavSystemから実行 – – UNavigationSystemV1::SetUpdateNavOctreeOnComponentChange() UNavigationSystemV1::ConfigureAsStatic() 無効化した場合RuntimeでのNav Mesh更新が反映されないので注意 #UE4CEDEC

132.

移動に伴うNavOctreeの更新 • NavOctreeの更新コスト – コンソールコマンド“stat component“で確認が可能 – ComponentやActorの数を減らすことで削減 #UE4CEDEC

133.

EQSのQuery検索 負荷ポイント ● EQSでActorOfClassを使用した検索はWorld上の全ての Actorを対象とするので検索コストがかかる 改善点 ● 検索対象が限定されるケースにおいては、予め対象を絞 った検索を行うことで検索コストを下げる 備考 ● 特になし #UE4CEDEC

134.

EQSのQuery検索 ● 負荷ポイント Query検索を行う際にActor Of Classを使用すると検索コストが掛かる – Worldから全てのActorを収集しテストを行う Actor Of ClassによるClass収集 #UE4CEDEC 全Actorが対象なのでStatic Mesh Actorなども含む

135.

EQSのQuery検索 ● 改善策 検索対象が限られている場合は収集方法を限定する – Generatorを作成して収集対象を絞る – 例えばPawnのみを対象とする場合はUWorld::GetPawnIterator()か ら取得したIteratorのリストから検索 #UE4CEDEC

136.

BehaviorTreeの実行コスト削減 負荷ポイント ● Behavior Treeはカスタムしやすい反面、常に実行される 箇所であるため呼び出しコストが嵩みやすい 改善点 ● TaskやDecoratorなどの頻繁に実行されるロジックは C++側で作成したものを使用することでVMコストを削減 備考 ● 保守性が低下するので調整して方針が固まった後などの タイミングで適用 #UE4CEDEC

137.

BehaviorTreeの動作制御 負荷ポイント ● Behavior Treeは常時稼働しているため、キャラクターが 多いケースで常駐コストとして存在 改善点 ● プレイヤーからの遠方のキャラクターや更新が必要無い ケースなどON/OFFを制御して常駐コストにならないよう にする 備考 ● 特になし #UE4CEDEC

138.

BehaviorTreeの動作制御 ● 負荷ポイント 多数のエージェントのBehavior Treeが常駐コストとして存在 – Wait Taskで待機している状態でもBehavior Tree は稼働 BehaviorTreeを起動すると #UE4CEDEC Behavior Tree Component が生成 AIControllerからアクセス可能

139.

BehaviorTreeの動作制御 ● 改善策 Behavior Treeを稼働状態に応じて適切にコントロールする – 稼働状態を監視してON/OFFを切り替えることで常駐コストを抑制 AIControllerのBrain Component経由で稼働のON/OFFを制御 #UE4CEDEC

140.

AI Perceptionの切り替え 負荷ポイント ● 知覚機能など常時稼働しているケースが多くキャラクタ ーが多数出ているとコストが嵩みやすい 改善点 ● プレイヤーから一定距離離れた時、ActorPoolingで稼働 していない時など適切にON/OFFをコントロールする 備考 ● 特になし #UE4CEDEC

141.

AI Perceptionの制御 ● 負荷ポイント/改善策 知覚機能は稼働状態が長くキャラクターが多いと実行コストが嵩む – エージェントの稼働状態を監視してON/OFFをコントロールする 登録:UAIPerceptionSystem::UpdateListener 解除:UAIPerceptionSystem::UnregisterSource #UE4CEDEC

142.

AIControllerの制御 負荷ポイント ● ControllerのRotation同期機能によりAIControllerは毎フ レームエージェントとRotationを同期するがComponent の移動コストとして処理コストに計上される 改善点 ● AIControllerの同期が不要であればOFFにすることで回転 処理(Componentの移動)コストを抑制する 備考 ● 特になし #UE4CEDEC

143.

AIControllerの制御 ● 負荷ポイント/改善策 AIControllerはPawnとRotation同期を行っているため移動コストとなる – 同時自体が不要であれば下記の同期設定をOFFにすることが可能 – Rotation同期するメリットがない (他に取得する方法があるため) この同期処理自体はAIControllerのTickで処理されるため、AIController のTick処理自体が不要であればTickから止めるのも可 – AIControllerのTick呼び出しコスト自体を削減 #UE4CEDEC

144.

アジェンダ • • • • • • Animation Physics Navigation & AI Movement Networking その他 #UE4CEDEC

145.

Movement #UE4CEDEC

146.

CharacterとMovement • Movement = Character Movement Component – – 移動の機能を提供するComponent Walk以外にSwimやFlyといった移動モードやNetworkの機能を備えている Character #UE4CEDEC Character Movement Component

147.

おさらい:Movement Movement Componentから派生した様々な移動用Componentがある UActorComponent UMovementComponent ・移動抽象クラス UInterpToMovementComponent UProjectileMovementComponent URotationgMovementComponent UNavMovementComponent UPawnMovementComponent UCharacterMovementComponent UArchVisCharMovementComponent UFloatingPawnMovement USpectatorPawnMovement UWheeledVehicleMovementComponent USimpleWheeledVehicleMovementComponent UWheeledVechicleMovementComponent4W #UE4CEDEC ・・ ・・・区間移動 ・・・平行移動 ・・・回転移動 ・・・経路探索 ・・・Pawn移動 ・・・Chracter移動 ・・・建築ビジュアライズ用Character移動 ・・・無重力移動 ・・・観戦者移動 ・・・車両シミュレーション移動 ・・・N輪駆動車移動 ・・・4輪駆動車移動

148.

おさらい:Movement (処理の流れ) Frame Pre Physics Game Tick 移動判定 #UE4CEDEC Component更新 NavData更新 床判定 物理作用

149.

改善ポイント一覧 (Movement) • • • • • • 静止中の床判定 移動中の床/衝突判定 移動に伴うComponentの相対的移動1 移動に伴うComponentの相対的移動2 移動に伴う物理作用の適用 オフスクリーン時の移動更新の抑制 #UE4CEDEC

150.

静止中の床判定 負荷ポイント ● 移動していない状態で行う床判定処理においてSweepを 使用するため定常コストとして追加される 改善点 ● ● 床判定テストをスキップすることで負荷削減 停止しているケースが多いほど効果が大きい 備考 ● 動的な床判定への対応ができなくなる #UE4CEDEC

151.

静止中の床判定 ● 負荷ポイント 静止状態で床判定処理を毎フレーム行うため定常コストに投入される Collision Analyzer #UE4CEDEC

152.

静止中の床判定 ● 改善策 床判定の処理をスキップすることで静止時の定常コスト削減 Always Check Floor = OFFで床判定スキップ – デフォルトはON – 副作用あり #UE4CEDEC

153.

静止中の床判定 床判定処理をスキップした場合、床の変化に対応できないケースがある 動いている床に 乗ることが可能 床に乗れず 貫通する 床判定をスキップしない 床判定をスキップする AlwaysCheckFloor = true AlwaysCheckFloor = false #UE4CEDEC

154.

移動中の床/衝突判定 負荷ポイント ● 移動する際にSweepを用いて衝突判定、及び床判定を行 うため移動時の処理コストとして計上される 改善点 ● ● Navmeshを基準とした移動により床判定をスキップ Navmesh Walking時は更に移動判定をスキップ 備考 ● Navmeshを使用することが前提なのでNPCのキャラクタ ーなどに限定される #UE4CEDEC

155.

移動中の床/衝突判定 ● 負荷ポイント 移動状態で衝突と床判定処理を行うことによるGameの負荷が嵩む Collision Analyzer #UE4CEDEC

156.

移動中の床/衝突判定 ● 改善策 NavWalking及びSweepスキップにより移動時のコスト削減 デフォルト設定 #UE4CEDEC 床判定スキップ 床/衝突判定スキップ

157.

移動中の床/衝突判定 • Characterの床判定や移動コスト – コンソールコマンド“stat character“で確認可能 – 負荷になっている時は、床判定スキップやNavmeshWalkingを検討 #UE4CEDEC

158.

移動中の床/衝突判定 • Navmesh Walkingモードの注意点1 – – Navigaiton Dataが無いとWalkingモードに戻る Walkingモードに戻るとSweep判定が実行されます #UE4CEDEC

159.

移動中の床/衝突判定 • Navmesh Walkingモードの注意点2 – Navmesh上を歩行するので完全には接地していない Navmesh WalkingモードとWalkingモードの比較 (左がNavmesh Walkingモード) #UE4CEDEC

160.

移動中の床/衝突判定 • Navmesh Walkingでの接地への対応 – – Skeletal MeshのLocationを調整 Navmeshの投射機能を使用 (Raycastでジオメトリを探して接地する) Meshの高さ調整で見た目を合わせる #UE4CEDEC Raycastで設置面をチェック

161.

移動に伴うComponentの相対的移動1 負荷ポイント ● ● 移動やアニメーションの際に所有しているComponentの 座標も併せて更新することでコストになる 多くのComponentを所有する場合はコストが嵩む 改善点 ● Scene Component (位置情報を持つComponent) の使 用を厳密に管理して無駄にComponentを増やしすぎない 備考 ● 複数のComponent(Skeletal Mesh等)を統合することで Componentを減らすことも可能 #UE4CEDEC

162.

移動に伴うComponentの相対的移動1 ● 負荷ポイント/改善策 移動やアニメーション時にComponentの座標を更新する – – 所有するComponentを相対座標からワールド座標に変換して再配置 Component数が多いほど再配置コストが嵩むため数を厳密に管理 Mesh (1000,0,0) Mesh (0,0,0) Weapon_L (0,0,0) Weapon_R (0,0,0) Weapon_L (1100,0,0) Relative → World変換 #UE4CEDEC Weapon_R (900,0,0)

163.

移動に伴うComponentの相対的移動1 Frame Game Move Animation Capsule 配下の移動 キャラクターの移動に伴うComponentの移動 #UE4CEDEC Mesh 配下の移動

164.

移動に伴うComponentの相対的移動2 負荷ポイント ● ● 移動やアニメーションの際に所有しているComponentの 座標も併せて更新することでコストになる 多くのComponentを所有する場合はコストが嵩む 改善点 ● ComponentがActiveで無い場合はComponentを切り離 すことでComponentの移動コストを削減 備考 ● Audio ComponentとParticle System Component のみ で使用可能な設定 #UE4CEDEC

165.

移動に伴うComponentの相対的移動2 ● 負荷ポイント/改善策 キャラクターの移動に伴うComponentの同期コストを減らしたい – – Attachしていない場合はComponentの座標変換が不要 AudioやParticleはアクティブでない場合は自動的にDetachする #UE4CEDEC

166.

移動に伴うComponentの相対的移動2 • Componentの変換や座標更新コスト – “stat component “で確認することが出来ます – 負荷になっている場合はComponent数やDetachを適用 #UE4CEDEC

167.

移動に伴う物理作用の適用 負荷ポイント ● 移動した際に物理作用(下向きの力、反発力)を発生させて 周辺にインタラクションを反映 改善点 ● 移動に伴う物理作用が不要な場合はオフにすることでイ ンタラクションのコスト削減 備考 ● 移動に伴う物理作用の適用は設定に従うが、単純な衝突 判定についてはCapsule Collsionで行う #UE4CEDEC

168.

移動に伴う物理作用の適用 ● 負荷ポイント/改善策 • 移動時に下向きの力と反発力を適用 – OFFに設定すると物理作用は適用されないがコストダウン – 基本的にはCapsuleの接触判定でオブジェクト同士はブロック #UE4CEDEC

169.

オフスクリーン時の移動更新の抑制 負荷ポイント ● 床判定や移動判定処理が毎フレーム実行されることで、 移動しないキャラクターなどの重要度が低いキャラクタ ーも同一コストが発生 改善点 ● 描画されていないキャラクターはCharacter Movement のTick処理をスキップすることでコスト削減 備考 ● ● Tick処理をスキップするので移動自体を行わなくなる 「描画されていない時に移動が不要なキャラクター」な どの限られたケースで有効 #UE4CEDEC

170.

オフスクリーン時の移動更新の抑制 ● 負荷ポイント/改善策 重要度が低くても同一の移動処理コストが発生 – オフスクリーン時の移動処理スキップ にぎやかし #UE4CEDEC ゲーム中のカメラ視点 建物の中にいる

171.

オフスクリーン時の移動更新の抑制 Frame Pre Physics Game Start Physics Tick 全てスキップ 移動判定 #UE4CEDEC Component更 新 NavData更新 床判定 物理作用

172.

アジェンダ • • • • • • Animation Physics Navigation & AI Movement Networking その他 #UE4CEDEC

173.

Networking #UE4CEDEC

174.

CharacterとNetworking Move Server Move Character Move Client Client 主にネットワークを利用した同期 #UE4CEDEC

175.

おさらい:Networking (処理の流れ) Client1 Wait Server Client2 Client3 入力 移動OK? ServerMove 移動 Client Ack Good Move Move 移動 移動 Client Adjust Position 同期 同期 ネットワークについてはCPUコストよりもNWトラフィックを減らす #UE4CEDEC

176.

改善ポイント一覧 (Networking) • • • • • 移動に伴うトラフィック調整 不要なReplicationの通知を抑制 Dedicated Serverでの物理シミュレーション Replicationの効率的な通知 Replicationデータの効率的な設定 #UE4CEDEC

177.

移動に伴うトラフィック調整 負荷ポイント ● 多数のキャラクターが存在する場合、データの同期によ りReplicationでCPUコストを逼迫する 改善点 ● ネットワーク設定を環境に併せて設定し、ネットワーク トラフィックを調整 備考 ● 特になし #UE4CEDEC

178.

移動に伴うトラフィック調整 • 多くのキャラクターが居る場合は特にSever-Client間での同期コストが増 えるため、Network設定を想定環境に併せて調整 Network送受信に関するパラメータの設定 (Engine.ini) #UE4CEDEC

179.

移動に伴うトラフィック調整 • 多くのキャラクターが居る場合は移動の同期コストが増えるので、移動に 関するNetwork設定を調整 Actor関連の調整値 (Actor) 移動関連の調整値 (CharacterMovement) #UE4CEDEC

180.

移動に伴うトラフィック調整 以下のスライドに各種項目などの説明がありますのでご参考下さい https://www.slideshare.net/EpicGamesJapan/ue4-multiplayer-online-deep-dive-1-byking-ue4dd #UE4CEDEC

181.

不要なReplicationの通知を抑止 負荷ポイント ● 多数のキャラクターが存在する場合、データの同期によ りReplicationでCPUコストを逼迫する 改善点 ● 休止状態を適切にコントロールすることでReplicationを 抑制することによりトラフィック及びコスト抑制 備考 ● 特になし #UE4CEDEC

182.

不要なReplicationの通知を抑止 • 休止状態を適宜制御して不必要なデータのやりとりを抑制 – キャラクターの稼働状態に併せてゲーム側から動的に制御 – 必要な情報はAActor::FulshNetUpdate()で強制的に送信 • net.UseAdaptiveNetUpdateFrequency – 更新頻度が低いほど頻繁に更新レートを落とし、頻繁に更新するにつ れて更新レートを上げる機能 #UE4CEDEC

183.

Dedicated Serverでの物理シミュレーション 負荷ポイント ● 多くのキャラクターが存在してPhysics Bodyを持つ場合 物理シミュレーションのコストが嵩む 改善点 ● Dedicated Serverでは物理シミュレーションが不要のた め無効化することでサーバー上のCPUコスト削減 備考 ● Dedicated Serverでのみ適用されるオプション #UE4CEDEC

184.

Replicationデータの効率的な通知 負荷ポイント ● Actorが状態を複製する際に同じ状態が多くのClientに送 信されることがある 改善点 ● 同一情報をキャッシュ、再利用して効率的にReplication やRPCなどのシリアライズデータを送信できる 備考 ● 4.20からの機能 #UE4CEDEC

185.

Replicationデータの効率的な通知 • キャッシュ/再利用が可能なシステムを利用し効率化 (4.20から) – “net.ShareSerializedData=1” で有効 – ReplicationとRPCのシリアライズしたデータを共有して再利用 Actor Actor Actor State Actor State Actor State Client Client Client #UE4CEDEC Actor State Client Client Client

186.

Replicationデータの効率的な設定 負荷ポイント ● 多数のキャラクターが存在する場合、データの同期によ りReplicationでCPUコストを逼迫する 改善点 ● Replication Graphを使用することでReplicationの収集や 優先付けを適切に行うことが可能 備考 ● ● 4.20からのPlugin機能 (Experimental) プロジェクトで独自の実装が必要 #UE4CEDEC

187.

#UE4CEDEC

188.

Replicationデータの効率的な設定 • Shooter GameにReplication Graphのサンプルがあります #UE4CEDEC

189.

アジェンダ • • • • • • Animation Physics Navigation & AI Movement Networking その他 #UE4CEDEC

190.

その他 #UE4CEDEC

191.

その他一覧 • • • • • Affinity設定 Tickコントロール コンソールコマンド Significance Manager Particle Pooling #UE4CEDEC

192.

Affinityの設定 (Console Only) • スレッドが動作するコアを指定 – [Platform]Affinity.hから設定 #UE4CEDEC

193.

Tickを適切にコントロールする 出来るだけ非アクティブなActorはTickを止めるのが望ましい – 次のケースではどう処理されるでしょう? 未接続のTick Node #UE4CEDEC 非ActiveなTick Node

194.

Tickのコントロール BlueprintのTickは実行されないが基底のTickが実行 TickTask Manager AMyCharacter AActor Blueprint AActor Blueprint そのTick処理が必要ない場合は根底から停止 TickTask Manager #UE4CEDEC AMyCharacter

195.

コンソールコマンド (パフォーマンス関連) dumpticks – Level上に存在するActorやComponentのTick設定を出力 – 不要に動いているTick設定やTickGroupを見直す際に有効 #UE4CEDEC

196.

コンソールコマンド (パフォーマンス関連) stat dumphitches – 指定時間を超えるヒッチを出力 – ヒッチを見ることで過負荷のあたりをつける際に有効 #UE4CEDEC

197.

コンソールコマンド (デバッグ関連) ShowDebug XXX – 標準で搭載されている各機能を視覚化 #UE4CEDEC

198.

コンソールコマンド (デバッグ関連) ShowDebug Input – キー入力情報の視覚化 – Input Componentのスタック情報 #UE4CEDEC

199.

コンソールコマンド (デバッグ関連) ShowDebug Animation – アニメーション情報の視覚化 #UE4CEDEC

200.

コンソールコマンド (デバッグ関連) p.VisualizeMovement – 加速度や移動モードを表示 #UE4CEDEC

201.

Significance Manager オブジェクト同士に優先度を設けて機能のON/OFFを制御 • 優先度の決め方 – • Highest 優先度の適用対象 – • 距離、スクリーンサイズなど AIPawn、Particleなど 実装 – 各プロジェクトで独自の実装 Lowest Player Other Players #UE4CEDEC

202.

Significance Manager 主に3ステップを実行して重要度を管理 • 対象Objectの登録 – • 例) AActor::BeginPlay() 重要度の計算 – • Register Calculate 例) SignificanceManager::Update()等 重要度に応じた効果適用 – 例) SignificanceManager::UpdateSignificance()等 Affect #UE4CEDEC

203.

Particle Pooling • Spawn Emitter関数へのPoolingオプションを追加 (4.20から) – 最初にSpawnしたParticle System Componentを再利用 – SpawnしたObjectはActivate/Deactivateで再利用 #UE4CEDEC

204.

まとめ #UE4CEDEC

205.

まとめ • コンテンツにあわせて機能や設定のON/OFF • 必要な機能も動的に切り替えて無駄のない処理 • 出来る限りシンプルに設計 #UE4CEDEC

206.

まとめ 初期から機能を把握して設計 プロファイリングを行いボトルネックを探して最適化 開発の早期からお気軽にご相談下さい #UE4CEDEC

207.

告知 #UE4CEDEC