Unreal Engine5を非ゲーム開発ノートPCで動かすための調整方法

検証バージョン: UE5.6.0, Windows


1. 概要

一般的な非ゲーム開発向けノートPCを使用してUE5の編集作業をエディタ上で実用的に行うための パフォーマンス調整方法を紹介します。特に以下のユースケースにおいて役立ちます。

[ユースケース]

  • とりあえずUE5が自分のPCでどれくらい動くか試したい
  • 社内での軽量なノートパソコンによるプロトタイプ作成における調整
  • 教育機関等におけるUE5の導入検討

Unreal Engine5のハードウェア要件については以下の公式ドキュメントで定義されていますのでこちらをご覧ください。


2. 使用環境

今回の検証で利用するPCは以下のスペックとなっています。

品名:LIFEBOOK A 5513/R (ノートパソコン)

項目 内容
CPU 13th Gen Intel(R) Core™ i5-1335U
CPU 動作周波数 Pコア:最大4.60GHz, Eコア:最大3.40GHz
CPU コア数/スレッド数 10コア(Pコア:2、Eコア:8)/ 12スレッド
CPU キャッシュメモリ 12MB
RAM・メインメモリ 16GB(DDR4-3200)
GPU Intel UHD Graphics (CPU内蔵)
ストレージ 256GB (DRAM-less SSD/PCIe NVMe)
OS Windows 11 Home 64bit
UEバージョン Unreal Engine 5.6.0

このPCは非ゲーム開発におけるMicrosoft Officeによる作業などを行うケースにおいては十分なスペックで、生協などで購入が可能なスタンダードスペックのノートPCとほとんど同程度のスペックです。ただし、ゲーム開発、特にUnreal Engine 5における開発としては最低動作スペック以上ではありますが、最新のレンダリング機能の利用に制限があるなど、やや不十分なスペックです。


3. 初期動作チェック

初期状態でのUE5動作状況

Unreal Engine 5 をインストール後、Third Person Template プロジェクトをデフォルト設定で起動・操作した結果、以下のような状況でした。

  • エディタ起動時間:約10秒 (初回起動:15秒)
  • ビューポート描画:非常に低速でマウス操作が即時反映しない
  • CPU使用率:約70%が使用中
  • メモリ使用量:16GB中12GB (約67%)が定常時消費
  • フレームレート:デフォルト表示設定で 10fps 前後

シンプルなThird Person のプロジェクトであっても、既にCPU, GPU, メモリがほぼ上限近くで動いているので、このスペックのPCだと若干心もとないところはあります。

起動直後のエディタ表示です。この時点でコンソールコマンド “stat unit” を実行して現在の負荷状況を確認します。

この時点では重いですが、最終的に色々調整することである程度簡単に負荷を減らして動作させることが可能です。

スペック不足によるレンダリング機能の停止

そもそもPCのスペック不足(グラフィクスカードが古い、グラフィクスドライバが古い、古いWindowsバージョン等)の場合、エンジンは自動的にNaniteやLumenなどの新しいレンダリング機能を利用できないように切り替えます。このチェックに引っ掛かった場合は、エディタの右下に以下のようなポップアップ表示でユーザーに通知します。

具体的にはエンジンの起動時に動作チェックを行い、SM6 (シェーダーモデル6) に対応していないスペックだと判断したらSM5に下げて起動します。このチェックは具体的に CheckFeatureSupport にて行われます。

		if (SUCCEEDED(Device->CheckFeatureSupport(D3D12_FEATURE_SHADER_MODEL, &FeatureShaderModel, sizeof(FeatureShaderModel))))
		{
			return FeatureShaderModel.HighestShaderModel;
		}

SM6に対応しているグラフィクスボードかどうかは、事前にPCで調べることが可能です。PCでコマンドから「dxdiag」と入力して「DirectX診断ツール」を開きます。

その中で [ディスプレイ]->[Direct Xの機能]->[DirectX 12 Ultimate]が “使用可能” になっていれば SM6 に対応しているため、新しいレンダリング機能をシステム的に利用することが可能となります。

これが利用できないグラフィクスカードを利用している場合は、以下のように「使用不可」となっています。

事前にこれらの設定を確認しておくと、UE5の新しいレンダリング機能を利用できるかどうかを事前に知ることができます。


4. 軽量化設定の内容

編集作業の実用性を確保しつつ、最小限のリソースでUE5を動作させるための設定については以下の通りです。

効果的な調整・設定

以下に調整が容易でパフォーマンス改善に大きく効果がある方法を示します。

スケーラビリティ設定

ビューポートのスケーラビリティ設定を調整すると一括でパフォーマンスを容易に調整できます。Unreal Engineの場合はレンダリングの品質がデフォルトで高いので、ここを調整することでレンダリング品質とトレードオフでGPU および CPUのパフォーマンスを改善してパフォーマンスを大幅に引き上げることができます。

以下は設定毎でのfps値の変化をリストにしたものです。

項目 Chine Epic High Mid Low
FPS 8.1 8.7 11.6 18.1 34.6

これらの設定の詳細な内訳は以下の通りとなっています。設定に応じて各値が殆ど比例して変化があることが分かります。見た目のクオリティを落としすぎると製品のクオリティにも直結するため、出来る限りパフォーマンスを維持しながら描画設定の内容は落としすぎないように注意して調整が必要になります。

項目 Chine Epic High Mid Low
Frame 122.85 114.23 85.79 54.98 28.88
Game 57.34 38.65 49.10 34.87 28.75
Draw 119.41 112.45 84.46 54.13 16.67
RHIT 88.93 75.64 35.84 25.41 10.37
GPUTime 122.57 110.09 85.67 54.99 28.23

スクリーン比率

ビューポートの画面解像度を指定する値で上書きします。これにより描画品質は低下しますが、レンダリングにかかるGPUのパフォーマンスを大きく改善できます。この値は、スケーラビリティ設定の品質に応じて自動で調整されます。

リアルタイムビューポート更新

ビューポート操作時以外のレンダリング更新を停止することで、定常時のGPUのパフォーマンスを大きく改善します。主にレンダリングにかかる全般のコストが削減されて、エディタUIのレンダリングにかかるコストだけの状態となります。

タブのドッキング

エディタのUI (slate) は多く表示されているほど負荷になります。そのため定常時には極力画面に表示されているUIが少ないほどパフォーマンスが良くなります。ここではコンテンツブラウザやアウトライナーなど、表示物が多いものをドッキングで利用することをおすすめします。利用していないUIをドッキングによって表示を消せるようにすることで、CPUのパフォーマンスを改善することができます。


効果が限定的な調整・設定

調整が比較的容易でパフォーマンス改善には少し影響する方法を示します。

ツールチップ表示

コンソールコマンド “Slate.EnableTooltips false" と設定することで、エディタのプロパティを選択時に表示するツールチップを表示しないようにします。これによりツールチップ表示がなくなりますが、表示のためのCPUのパフォーマンスをわずかに改善することができます。

コンソールコマンドは「出力ログ」ウィンドウか「コンソール」ウィンドウから入力して実行することによって反映されます。以下の図はコンソールコマンドを入力する例です。

リアルタイムサムネイル表示

以下の設定をオフにすることで、アセットのリアルタイムサムネイル更新を抑制します。これに伴い、サムネイルの更新コストを削減します。サムネイルが表示されていない状況では効果がありませんが、CPUのパフォーマンスをごくわずかに改善することができます。

ボリューメトリッククラウド設定

コンソールコマンド “r.VolumetricCloud 0” を入力すると、雲のレンダリングが停止しますがGPUパフォーマンスを大きく引き上げることができます。

GPUパーティクル設定

コンソールコマンド “FX.AllowGPUParticles 0” を入力すると、GPUパーティクルが利用できなくなりますがGPUのパフォーマンスを引き上げることができます。


SM6以降でも有用な設定

以下はSM6以降で有効な新しいレンダリングに関連する機能および、その他のレンダリング関連のパフォーマンス改善に寄与する設定の一部を示します。描画品質と引き換えにGPUのパフォーマンスを改善します。

設定項目 日本語設定名 調整値 コンソール変数
Dynamic Global Illumination Method 動的グローバルイルミネーションメソッド Lumen→None r.DynamicGlobalIlluminationMethod=0
Enable virtual texture support バーチャルテクスチャのサポートを有効化 True→False r.VirtualTextures=0
Reflection Method 反射メソッド Lumen→None r.ReflectionMethod=0
Shadow Map Method シャドウマップメソッド Virtual Shadow Maps → Shadow Maps r.Shadow.Virtual.Enable=0
Nanite Nanite True→False r.Nanite.ProjectEnabled=0
Anti-Aliasing Method アンチエイリアス手法 Temporal Super-Resolution (TSR, Default) → None r.AntiAliasingMethod=0
Bloom ブルーム True→False r.DefaultFeature.Bloom=False
MotionBlur モーションブラー True→False r.DefaultFeature.MotionBlur=False
AmbientOcclusion アンビエントオクルージョン True→False r.DefaultFeature.AmbientOcclusion=False

これらの設定は、エディタの設定ファイル DefaultEditor.ini の [ConsoleVariables] セクションに登録することで、エディタでの動作時にのみ適用することもできます。

[ConsoleVariables]
r.VolumetricCloud=0

以下のようにProjectフォルダの下にあるConfigフォルダ内にある .iniファイルを開いて項目を追加して保存します。このファイルを共有することで、チームでも同じ設定を共有することが可能です。


5. 調整前後のパフォーマンス評価

エディタの起動時間についてはそれほど変化がありませんが、操作性やメモリ使用率は大幅に改善しました。しかしこれらの調整には描画品質を下げたり、画面解像度を下げるなど、見た目の品質が下がってしまう事は、パフォーマンスの低下を回避することとのトレードオフとなります。

メモリ使用量は65%前後まで抑えられ、エディタの操作性に関する安定感は大きく向上しました。フレームレートにおいても、Unlit表示時は65〜75FPS、Lit表示でも60FPSを維持できており、ハイスペックではない状況においても、実用的なパフォーマンスは得られることが分かりました。

項目 調整前 調整後
起動時間 約10秒 約9秒
メモリ使用量 約90% 約65%
ビューポート操作 カクつき / 不安定 滑らかに操作可能
フレームレート 約10〜15fps Lit: 60fps / Unlit: 65〜75fps


6. Third Personテンプレート以外のプロジェクトでの検証

Third Personテンプレート以外のプロジェクトにおける評価については以下の通りです。

Lyra Shooter Sample

特に設定を追加したり変更することは不要でプロジェクトを起動することはできましたが、当然ながらデフォルト設定ではまともに編集したり操作することができませんでした。

このようなケースでもスケーラビリティの設定を EpicからLow に変更するだけでもひとまず60fpsにまでは持っていくことができます。

Lyraのサンプルはアセットの数はそれほど多くなく、レンダリングに関するクオリティもそれほど高いものではありませんが、スペックが十分ではないPCで開こうとすると時間がかかったり、FPSが低下した状態になることがあります。

ValleyoftheAncient

アプリケーション起動時に以下の「DirectX 12 is not supported on your system. Try running without the -dx12 or -d3d12 command line argument.」ポップアップが出力されてアプリケーションの起動に失敗しました。

これは新しいレンダリング機能を利用することを前提としており SM6 でのみアプリを動作することが前提になっているためです。以下の設定をDefaultEngine.ini に適用することによってアプリケーションを起動することはできました。

[/Script/WindowsTargetPlatform.WindowsTargetSettings]
;-D3D12TargetedShaderFormats=PCD3D_SM5
+D3D12TargetedShaderFormats=PCD3D_SM5

しかしマップを開くなど、アセットロードの際にはパフォーマンス不足により1時間経過してもマップを開くことができなかったので、「このプロジェクトを利用するにあたって想定されたPCスペックと、現在使用しているPCスペックにおいて、相当大きな差異がある」と判断し、これ以上の検証は断念しました。

サンプルプロジェクト別スペック情報

Epicの公式が出している高品質なサンプルプロジェクトにおいては、それぞれで想定されるスペックというものが存在します。開発用PCに関する考察、およびサンプルプロジェクト等での推奨スペック一覧情報はこちらのスライドでご確認頂けます。

プロジェクトを初めて開くときに重い理由

プロジェクトを初めて開くとき、2回目以降に開くときに比べてかなり長い時間がかかるかと思います。これは初回プロジェクトを開いた際にアセットのキャッシュデータ(2回目以降に素早くアセットをロードするためのデータを作成)を作成することや、それに伴うシェーダーコンパイル処理など、様々な処理が行われることによります。パフォーマンスが不足しているPCでは特にこれらのアセットをロードする処理に時間がかかることがあります。このアセットロードはCPUの処理(周波数、コア数、スレッド数)、ストレージ(HDDよりSSD推奨)が影響しています。


7. スペックとエンジン処理の関連性

マシンスペックがエンジンのどのような処理に影響するかについて以下に示します。これらの内容を元に自身のプロジェクトに則した開発用マシンのスペックを検討することができます。

CPU

動作周波数

シングルスレッド性能が求められる処理において、数値が高いほど高速に処理することができます。

  • エディタの応答性(Blueprintコンパイル、Viewportにおけるレベル編集作業)
  • C++コードのビルド
  • AI、Physics、Gameplay処理などランタイムの計算

コア数・スレッド数

CPU処理を並行して同時に処理することが可能なため、数値が大きいほど同時並列処理数が向上して高速に処理を完了できます。

  • シェーダーコンパイル
  • C++コードのビルド
  • クック処理

キャッシュメモリ

共有メモリのサイズを示し、並列処理における処理の高速化に影響するため、数値が大きいほど処理性能が高いです。

  • スレッド間の効率的なデータ共有

ストレージ(HDD / SATA SSD / NVMe SSD)

ファイルアクセス時の読み書き速度全般に影響します。HDDは非常に遅いため、可能な限りはNVMe SSDの導入をおすすめします。

  • プロジェクトの起動、アセットの読み込み
  • クック処理時の一時ファイル書き込み
  • PIE(Play In Editor)の起動時間

メモリ(RAM)

高速アクセスが可能なメモリ容量のサイズを示し、この値が大きいほど同時に多くのアプリケーションを動かしたりすることができます。メモリが不足するとパフォーマンスの低下や、クラッシュなどが発生します。

  • 大規模マップやワールドパーティショニングの使用
  • シェーダーコンパイルの一時データ
  • クック・ビルド処理
  • PIE中のデバッグ・ログ保持
  • Zen ServerによるDDC管理

GPU(グラフィックスカード)

動作周波数

GPUコアがどれだけ高速に処理できるかを示す値で、同じ世代・同じコア数でもクロックが高ければ処理スピードも向上します。

  • ビューポート表示

コア数・スレッド数

GPUには数千のCUDAコアやシェーダーユニットがあり、これらがピクセルや頂点の描画処理を並列に実行します。

  • ビューポート表示

VRAM(ビデオメモリ)

GPU専用の高速なメモリで、グラフィックスの描画や処理に使うデータを一時的に保存する領域で、値が大きいほどテクスチャやマテリアルを多く利用でき、VSMやLumenのキャッシュとしても利用できます。

  • Lumen、Nanite、VSM使用時の描画
  • 高解像度テクスチャ・マテリアルの表示
  • シーケンサーでのリアルタイムレンダリング

8. プロセス別ボトルネックケース

以下はUnreal Engineでの処理プロセスに関連しているスペックを一覧にした表です。

プロセス 関連するスペック
ソースコードビルド CPU(全般)、ストレージ、メモリ
初回の全体シェーダーコンパイル CPU(コア数)、ストレージ、メモリ
クック処理 CPU(スレッド数)、メモリ、ストレージ
巨大なレベルの編集 メモリ、GPU(VRAM)、ストレージ
PIEでのプレイ/デバッグ CPU(周波数)、メモリ、GPU

例えば「ソースコードビルド」が遅い場合、「CPU(全般)、ストレージ、メモリ」のいずれか、もしくは全てのスペックが低いため処理のボトルネックになっていて遅くなっている事が想定されます。

このケースで言えば、たとえ良いCPUとストレージを利用していたとしても、メモリ(RAM)が低いと、ビルドに必要なメモリ不足が発生して時間がかかることがあります。もし特定の処理で時間が掛かっているような場合は、動作PCのスペックとどの処理で時間がかかっているかを比べてみて、どのスペックを増強する必要があるかを検討してみると良いかもしれません。


9. まとめ

高いスペックのPCを利用するとより快適な開発が出来るのは間違いありませんが、そうでなくても設定を調整することによってUE5を利用することは可能です。これからUE5で開発するためにPCを新調しようとしている方も、まずは今手元にあるPCでUE5をインストールしてみて利用してみてください。

1 Like