レベルにアセットを並べていったら、いつのまにか動きがカクつくようになった。影を弱め、テクスチャ解像度を下げてみても、あまり変わらない。そんなときは、設定を変える前に「どの処理に時間がかかっているか」を見てみましょう。
UE5の stat unit は、ゲーム全体と主な担当の処理時間を画面へ表示するコマンドです。CPUのゲーム処理、CPUの描画準備、GPUのどこから調べるか、最初の手がかりを得られます。
この記事では、数字の読み方を整理し、回転するActorのTickをオン／オフして比較します。目指すのは、特定の数字を出すことではなく、同じ条件で測り、一つ変え、その差を説明できること です。
この記事でわかること
- FPSとフレーム時間の違い
- Frame・Game・Draw・GPUの読み方と、判断できる範囲
- FPS上限や測定条件を揃える理由
- 小さな比較実験から、次に調べる場所を選ぶ手順
実践では、Blueprintの作成、Componentの追加、ノード接続を使います。図や表の計測値は、読み方を説明するための例です。実際の値はPCや設定、UEのバージョンで変わります。
「重い」をミリ秒で見る
同じ「カクつく」でも、大量の敵の行動計算、半透明の重なり、アセットの読み込みなど、原因はさまざまです。先に測れば、画質を落とす必要があるのか、ゲームの処理を調べるべきなのかを考えられます。
FPS は1秒間に表示するコマ数、フレーム時間 は1コマにかかった時間です。処理の重さを比べるときは、フレーム時間を ms（ミリ秒、1秒の1000分の1） で見ると扱いやすくなります。
目安は フレーム時間 = 1000 ÷ FPS です。
| 目標 | 1フレームの時間の目安 |
|---|---|
| 30 FPS | 約33.3 ms |
| 60 FPS | 約16.7 ms |
| 120 FPS | 約8.3 ms |
120→60FPSは約8.3→16.7ms、40→30FPSは25→33.3msです。どちらもフレーム時間の増加は約8.3msですが、FPSの減り方は大きく違います。「何FPS上がったか」だけでなく、何ms減ったか を記録すると、変更の効果を比べやすくなります。
また、平均が60FPSでも、ときどき1コマだけ100msかかれば引っかかります。一瞬だけ処理時間が跳ね上がる現象を スパイク と呼びます。ずっと重い場面と、瞬間的に止まる場面は分けて調べます。
stat unitを表示して、担当を知る
まずは手元のレベルでPlayし、ゲーム画面をクリックします。コンソールを開いて stat unit と入力し、Enterを押してください。コンソールは、短い命令を入力してゲームの状態を調べたり設定を変えたりする欄です。
既定のキーは ` ですが、日本語キーボードでは開けない場合があります。そのときは「Edit → Project Settings」で Console Keys を検索し、使っていないキーを追加します。「Engine → Input → Console」にある設定です。設定後、Playし直して試してください。
数字が出たら、まず次の4項目を見ます。同じ stat unit をもう一度入力すると表示を消せます。
| 項目 | 最初はこう読む |
|---|---|
| Frame | 1フレーム全体の時間。目標に届いているかを見る入口 |
| Game | CPUのゲームスレッドの時間。ゲームの進行やActorの更新など |
| Draw | CPUの描画スレッドの時間。描くための準備や命令の組み立てなど |
| GPU | GPU側で、画面を描くためにかかった時間 |
CPU はゲームの進行や各種の計算を担い、GPU は描画に関する大量の計算を得意とする部品です。スレッド は、処理を順に進める実行の流れです。ここでは「ゲームを進める担当」と「描画を準備する担当」がCPU側にいる、と捉えれば十分です。
DrawをGPUの時間と混同しないことが大切です。また、物体1000個がそのまま描画命令1000回になるわけでもありません。マテリアルや描画方式、同じ物体をまとめて描く仕組みなどで変わります。
Frameは、Game・Draw・GPUの合計ではない
これらの担当は、別々のフレームの仕事を並行して進めます。GPUが一つの画面を描いている間に、CPU側はその先のフレームを準備できます。このように、工程を重ねて進めることを パイプライン処理 と呼びます。
たとえばGame 5ms、Draw 4ms、GPU 15msなら、単純に足してFrame 24msとは読みません。GPUが全体の速さを制限している候補になります。このような制限箇所を ボトルネック と呼びます。
ただし、実際には待ち時間や別の処理も関わるため、Frameが最大値と厳密に一致するわけではありません。stat unitは担当を絞る入口です。数字一つから、特定のActorや関数が原因だと確定する道具ではありません。
測る条件を揃える
比較の前後でカメラの向きや解像度が変わると、見える物や描く画素数も変わります。その差を修正の効果と取り違えないよう、次の条件を揃えます。
| 揃えるもの | 今回の決め方 |
|---|---|
| 起動方法 | 「Play」のメニューからStandalone Gameで起動する |
| 画面 | 同じウィンドウサイズ・解像度・画質設定にする |
| 場面 | 同じPlayer Startから始め、同じ方向を見る |
| 計測開始 | 読み込みやシェーダーのコンパイルが落ち着いてから |
| 観察時間 | 毎回同じ時間、数秒〜10秒程度を見る |
Standalone Gameは、ゲームを独立したウィンドウで動かす起動方法です。PIE（エディタ内のPlay）でも傾向は掴めますが、エディタ の処理が計測へ混ざります。公開前の確認では、対象PCでDevelopmentビルドをパッケージ化して測ると、実際の動作環境へ近づけられます。
60FPS付近で固定されるなら、上限も確認する
垂直同期（VSync） は、モニターの画面更新に表示を合わせる仕組みです。処理に余裕があっても、その更新を待つことがあります。FPS上限も、一定以上の速さで動かさない設定です。
60FPS付近だから、すぐGPUの限界とは言えません。待ちの影響を外して比較したいときは、起動したゲームのコンソールで現在の値を調べてメモし、その後に変更します。
| 入力 | 意味 |
|---|---|
t.MaxFPS | 現在のFPS上限を表示する |
r.VSync | 現在のVSync設定を表示する |
t.MaxFPS 0 | この上限による制限を外す |
r.VSync 0 | ゲーム側のVSyncをオフにする |
t.MaxFPS 0 だけではVSyncは切れません。また、「Project Settings → Engine → General Settings → Framerate」の Smooth Frame Rate や Use Fixed Frame Rate、GPUドライバー側の上限も別です。必要なら元の設定を記録し、計測中だけ外します。終了後は元へ戻してください。
二つの状態を比べる間は、これらの設定も揃えます。上限を外す操作自体を、ゲームの最適化の成果として数えないようにします。
数字から、次に調べる場所を選ぶ
最初にFrameが目標を超えているかを見て、次にGame・Draw・GPUを比べます。Frameに近い、大きな値を出している担当が調査候補です。
| 説明用の例 | 次に確かめたいこと |
|---|---|
| Frame 22.5 / Game 21.4 / Draw 8.2 / GPU 12.1 ms | Gameが大きい。Actor更新、AIなどの内訳を調べる |
| Frame 22.5 / Game 5.0 / Draw 4.0 / GPU 21.4 ms | GPUが大きい。描画のどの処理が長いかを調べる |
| Frame 16.7 / Game 4.0 / Draw 3.0 / GPU 5.0 ms | 主な処理に余裕がある。上限や待ち、ほかの担当を確認する |
GameとDrawが近い値なら、どちらかを機械的に原因と決めないでください。担当同士の待ち合わせが影響している場合もあります。内訳を見て候補を一つ選び、その処理を変えたときに何が下がるかを確かめます。
目標を満たしている場合も、重い場面やスパイクがないかは別に確認します。一方、必要な目標を満たしているのに「今いちばん大きいから」という理由だけで、際限なく削る必要はありません。
一段詳しく調べる道具
次のコマンドは全部を常時表示せず、候補に合うものから使います。
| 調べたい場所 | 道具 | 手がかり |
|---|---|---|
| Game | stat game | Tickなど、ゲーム処理のカテゴリ別の時間 |
| Draw | stat scenerendering | 描画に関する処理時間や数 |
| 見える物を選ぶ処理 | stat initviews | 描画対象の判定にかかる時間、除外された数など |
| GPU | stat gpu、profilegpu | 影やライティングなど、描画の工程別の時間 |
| 瞬間的な引っかかり | stat unitgraph、Unreal Insights | 変化の形や、問題が起きた時間帯の記録 |
Tick は、毎フレーム呼ばれる更新処理です。stat gameでTickに関する項目が大きければ、実行するActorの数だけでなく、一回の処理量も見ます。少数のActorでも、毎回大きな配列を検索していれば時間を使います。
描画側で出てくる ドローコール は、描画の仕事を要求する呼び出しです。数だけで良し悪しを決めず、同じ場面で変更前後の時間と一緒に見ます。カリング は、見えない物などを描画対象から外す処理です。LOD・カリングの記事へ進む前の手がかりになります。
GPUの パス は、描画の一工程です。たとえば影に関する時間が大きければ、影を作るラ イトや対象、設定を調べます。profilegpu の結果は、UEの版や環境によってGPU Visualizerのウィンドウ、またはOutput Logなどへ出ます。別窓が出ない場合も、まずログを確認してください。
Unreal Insightsは、処理の記録を取り、後から時間軸に沿って読む道具です。数字が近くて原因を分けられない場合や、「敵が現れる瞬間だけ止まる」という問題は、Insightsの記事で記録へ進みます。
実践：回転ActorのTickを切り替えて比べる
回転する小物を複数置き、配置はそのままで、回転処理の有無を比べる 実験をします。回転を止めるのは、処理と重さの関係を調べるためです。必要な動作まで止まるので、この変更をそのまま完成版にはしません。
1. まず一つ、回転するActorを作る
Third PersonのBlueprintプロジェクトを使います。コンテンツブラウザからActorを親にしたBlueprintを作り、BP_Spinner と名付けます。
| 設定する場所 | 値 |
|---|---|
| 追加するComponent | Static Mesh Component。名前はSpinnerMesh |
| Static Mesh | Engineの基本形状Cube |
| SpinnerMeshのScale | X=1.0、Y=0.2、Z=0.2。回転が分かる細長い形 |
| Mobility | Movable |
| Collision Presets | NoCollision |
| Simulate Physics / Cast Shadow | どちらもオフ |
| Class Defaults → Actor Tick | Start with Tick Enabledをオン、Tick Intervalは0.0 |
Cubeが見つからなければ、アセット選択画面でEngine Contentを表示します。Tick Intervalが0なら、Tickを有効にした間は毎フレーム更新します。
Event Graphで、次の接続を作ります。Multiplyは掛け算、Make Rotatorは3方向の角度を一つの回転量へまとめるノードです。
- Event Tickの白い実行出力 → Add Actor Local Rotationの実行入力。
- Event TickのDelta Seconds → Multiplyの一方。もう一方は90.0。
- Multiplyの結果 → Make RotatorのZ（Yaw）。X（Roll）とY（Pitch）は0。
- Make RotatorのReturn Value → Add Actor Local RotationのDelta Rotation。TargetはSelf、SweepとTeleportはオフのままです。
図は接続の意味を示す模式図です。上段が実行の流れ、下段が回転量の計算を表します。TargetのSelfは、このBlueprint自身のActorを指します。
Delta Seconds は前の更新からの経過秒数です。90を掛けると、1秒に90度回るための「今回の回転量」になります。Yaw は上下方向の軸を中心にした回転です。
Compileしてレベルへ一つ置き、床より上へ移動します。Playして横にくるくる回れば、まず一個分は完成です。回らないときは、白い実行線、Movable、Tickの設定 を確認してください。
2. 数を増やして、変更前を記録する
Stopし、配置したBP_SpinnerをAlt＋ドラッグで複製します。複数選択した一組を、まとめて複製して増やせます。床の上へ間隔を空けて並べ、まずは32個程度から試します。
数は固定の再現条件ではありません。32個で差が読めなければ128個、512個などへ段階的に増やせますが、無理に60FPS未満まで落とす必要はありません。今のPCではこの程度の回転処理が主な負荷ではない、という結果でも構いません。
測定は前述の条件を揃え、Standalone Gameで起動します。同じ開始位置で動かず、stat unit と stat game を表示してください。読み込みが落ち着いてから約10秒見て、おおよその範囲と大きく跳ねる場面を記録します。
| 記録欄 | 自分の値を書く |
|---|---|
| 条件 | Actor数、解像度、画質、起動方法、上限設定 |
| Tickオン | Frame / Game / Draw / GPU、Tick関連の時間 |
| Tickオフ | 同じ項目 |
| Tickをオンへ戻す | 同じ傾向が戻ったか |
3. Tickだけをオフにして比べる
ゲームを終了し、BP_SpinnerのClass Defaultsで Start with Tick Enabled をオフにします。配置したActorの数やマテリアル、カメラは変えません。Compileして保存し、同じ条件で起動します。
小物が回らなくなったことを確認し、約10秒の範囲を同じように読みます。最後にTickをオンへ戻してもう一度測ります。オン→オフ→オンで傾向が戻るか を見ると、たまたま軽かっただけの結果と区別しやすくなります。
4. 数字の変化から、何が分かったか考える
次は説明用の比較例です。この個数のBP_Spinnerから実測した値ではありません。
| 項目 | Tickオンの例 | Tickオフの例 |
|---|---|---|
| Frame | 22.5 ms | 12.8 ms |
| Game | 21.4 ms | 4.1 ms |
| Draw | 8.2 ms | 8.0 ms |
| GPU | 12.1 ms | 12.0 ms |
この例なら、回転Actorの更新がGameの時間へ大きく関わっていた、と考えられます。ただし回転を止めると、位置や向きの変更を描画へ伝える仕事なども減ります。差をそのまま「Blueprintのノードだけにかかった時間」とは言えません。
ほかの結果も、調査の手がかりになります。
| 見えた変化 | 次に考えること |
|---|---|
| GameもFrameも下がった | 今回止めた処理が、全体の速さを制限していた候補 |
| Gameは下がったがFrameはほぼ同じ | GPUなど別の担当や、FPS上限が全体を制限していないか |
| Gameもほぼ同じ | 差が小さい、ほかの処理が大きい、Tickが切れていない可能性 |
| DrawやGPUも大きく変わった | 回転停止による描画の変化も含めて比較する |
| オンへ戻しても元の傾向へ戻らない | 読み込み、視点、設定、別のアプリなど条件を見直す |
実際の修正は、必要な動作を保って作る
原因の候補が絞れたら、ゲームに必要な動きを残して処理を減らします。遠くの飾りは更新を止めてよいか、毎フレーム必要な処理と低頻度でよい処理を分けられるかを考えます。
回転アニメーションを単に低頻度のTimerへ置き換えると、動きがぎこちなくなる場合があります。Tickを一律に避けるのではなく、TickとTimerの使い分けを参考に、用途に合わせて直します。
修正後は、同じ条件で再計測し、操作や見た目も確認します。Gameが下がってGPUが最大になったとしても、目標を満たしているなら、さらにGPUを削るかはゲームの必要性から判断できます。
おまけ：先に知っておくと良いこと
数字だけでなく、変化の形も見る
stat unitgraph は、時間の変動をグラフで見せます。ずっと高いのか、一瞬だけ跳ねるのかを見るのに向きます。通常の表示はならして見せるため、短いスパイクを詳しく追うときはInsightsで記録します。
ストリーミング は、必要になるデータを順次読み込む仕組みです。stat streaming は、特にテクスチャのメモリ使用などを見る手がかりになります。表示だけで「このロードが停止の原因」と確定するものではありません。読み込みの時間帯を記 録してから、ソフト参照と非同期ロードなどの対策を検討します。
RHITやDynResが表示される場合
RHITは、描画命令をグラフィックスAPIへ渡すRHIスレッドの時間です。大きければ、その担当や待ち時間も調べます。Game・Draw・GPUの三択へ無理に当てはめる必要はありません。
DynResは動的解像度に関する表示で、msではなく描画解像度の割合です。また、環境によってGPUの時間が取得できない場合もあります。空欄や未表示を「GPU負荷がゼロ」と読まないでください。
表示を片付け、設定を戻す
stat系は同じコマンドでもう一度切り替えられます。stat none でまとめて表示を消すこともできます。実験後は、FPS上限、VSync、Smooth Frame Rateなど、計測のために変えた設定を戻します。
次に重い場面へ出会ったら、まずFrameを見て、担当の候補を絞り、一つだけ条件を変えて比較してみてください。数字が期待どおりに下がらなくても、「この処理だけでは説明できない」と分かれば、次に調べる場所を選べます。
まとめ
- FPSは「1秒に何枚」、フレーム時間は「1枚に何ミリ秒」。比べるのは時間のほう
- Frame・Game・Draw・GPUのどれが太いかで、次に調べる場所が決まる
- 上限や測定条件をそろえないと、前後を比べられない
測る前の問いかけは、「いま何と何を比べたいのか」 です。条件を1つだけ変えて測ると、原因が1つに絞れます。
詳しく追うなら Unreal Insights、描画側を減らすなら LODとカリ ング へ進んでください。
参考：Stat Commands、Performance Profilingの基礎、General Engine Settings、Console Variables Reference。