HW Lumenの使用メモリ量と、その削減に関して

anonymous-edc · March 9, 2026, 5:57am

お世話になっております。

PS5(UE5.7.3)で、HW LumenをONにするとメモリが1G程度使用されます。

RTAS(TLAS/BLAS)の削減を行いましたが、使用メモリは600MB前後までしか落ちませんでした。

主に伺いたいのは次の2点です。

1) このRTAS増分は想定内(適正レンジ)でしょうか？

2) 想定外なら、PS5＋HW Lumenで RTAS常駐を下げる推奨手段(設定/CVar/運用、除外推奨、落とし穴)を教えてほしいです

---

A. 環境

・Engine:UE 5.7.3

・Platform:PS5

・計測

・rhi.DumpMemory の Total / RayTracing AS

・stat RayTracingGeometry の ResidentMemory

・主要設定

・r.RayTracing=True

・r.Lumen.HardwareRayTracing=True

・r.RayTracing.ResidentGeometryMemoryPoolSizeInMB=200

・r.RayTracing.Culling.Radius=15000

---

B. 計測方法

草木の多いレベルの特定の場所で以下のコマンドを実行

・rhi.DumpMemory

・RayTracingGeometry

---

C. 計測結果

HW Lumen OFF(基準)

・rhi.DumpMemory Total:4569 MB

・rhi.DumpMemory RayTracing AS:0 MB

・stat RayTracingGeometry ResidentMemory:0 MB

HW Lumen ON

・rhi.DumpMemory Total:5266 MB

・rhi.DumpMemory RayTracing AS:362 MB

・stat RayTracingGeometry ResidentMemory:261 MB

---

D. 追加質問

1) 適正レンジの確認

・PS5でHW LumenをONにした際、RTAS常駐メモリ増分は一般にどの程度が適正値でしょうか?

・増加の主因(インスタンス数、BLAS数、三角形数、Nanite、フォリッジ等)と、判断の目安を教えて頂きたいです。

2) 想定外の場合の削減策

・PS5+HW LumenでRTAS常駐を下げるための推奨設定/CVar/運用を教えて頂きたいです。

・効く施策と、効きにくい施策／避けるべき(落とし穴)、も併せて知りたいです。

3) RTASが常駐して減らない挙動について

・常駐を引き起こす典型要因(そもそもの物量が多い、ポリゴン過多)があれば教えてください。

・及びそれの調査方法について教えていただきたいです。

4) RTプロキシ/フォールバックを下げても削減が鈍い件

主題ではありませんが、削減施策として重要なため確認したいです。

Naniteフォールバックを以下のような極端な設定にしても、見た目が壊れないようなメッシュになります。

・Fallback Target=Triangles

・Fallback Triangles=1%

20％と1％であまり差がないように感じます。

・この状況で、フォールバック設定がRTAS削減に効かない/効きにくい理由で考えられるものは何かありますでしょうか？

・三角形よりインスタンス数/BLAS数の固定費が支配するなど、切り分け観点があれば教えてください。

・フォールバックが実際にRTジオメトリとして使われているかを確認する推奨方法(デバッグ/統計/ツール)が知りたいです。

・こちらではr.RayTracing.DebugVisualizationMode Trianglesで確認していました。

5) RT除外推奨対象(草・空など)と副作用

・PS5のHW Lumen運用において、RTから除外すべき推奨カテゴリ(草/フォリッジ/空/その他)があれば教えて頂きたいです。

・除外の副作用(反射/GI/影)と、代替案があれば併せてお願いします。

6) UE5.7×PS5の既知問題

・UE5.7で、PS5のRTASメモリが高止まりする／想定より増えやすい等の既知問題があれば教えて頂きたいです。

---

以上、よろしくお願いいたします。

[Attachment Removed]

Yutaro_Sawada · March 13, 2026, 12:03pm

お世話になっております。

本件に関して現在各項目について確認を行わせていただいております。

お時間を頂き恐縮ですが、今しばらくお待ちいただけますと幸いです。

よろしくお願いいたします。

[Attachment Removed]

Yutaro_Sawada · March 16, 2026, 1:40pm

お世話になっております。

本件ですが以下にそれぞれの回答をまとめさせていただきました。

調査のためには特に(4)に記載させていただいている、"D3D12.DumpRayTracingGeometries all"コマンドを確認いただく事でメモリを消費しているジオメトリを見つけられる可能性がございます。

お手数おかけしますが、下記情報をもとにご確認いただけますと幸いです。

よろしくお願いいたします。

1) このRTAS増分は想定内(適正レンジ)でしょうか？

Lumen(HWRT)を有効にした場合に1GB程度増えてしまう、といった状況は想定される数値という認識です。

Lumenを有効化した場合、Raytracingに利用しているRTAS以外にもSurface Cache等を作成するために各種必要なバッファが作成されており、

こちらはrhi.DumpMemoryで出力されるRender Target 2DやUAV Texture Memory項目などで500~600MB程度増えていることが確認できます。

そしてRTAS自体の増加の主因としましては、Raytracingに利用されている三角形の数の影響が大きくなります。

以下ページにRTASのBLAS、TLASについて紹介されていますが、StaticなインスタンスであればBLASは共通のものが利用されます。

そのため基本的な対策としましましては、レイトレーシングで利用されるメッシュのTriangle数を減らしていただく事が削減につながります。

※弊社内の利用ではプールサイズの値は256MBを設定しているケースがありましたが、こちらは全体のメモリバジェット次第かと思われます。

https://dev.epicgames.com/documentation/ja-jp/unreal-engine/ray-tracing-performance-guide-in-unreal-engine

2)想定外の場合の削減策

RTAS常駐に関してはLODメッシュのTrinangle数が多くBLASデータが大きくなってしまっている可能性があります。

Naniteの場合はFallback Mesh(またはRaytracing Proxy)、通常のメッシュの場合は表示されるLODごとにBLASが作成されるため、各LODをご確認いただければと思います。

3) RTASが常駐して減らない挙動について

常駐メモリに関しましてPoolサイズを200MBを設定いただいているとのことでしたが、

このプールサイズの値よりも大きくなっている理由としましては、一番粗いLODのメッシュのTriangle数が多い、

Naniteメッシュの場合は読み込まれているRaytracing用プロキシ(またはFallback Mesh)のTriangle数が多いといった状況かと思われます。

RTAS常駐メモリ、Resident Memoryには最低1つのLODを保持する設定(r.RayTracing.NumAlwaysResidentLODs 1)となっていますが、

UE5.5からRaytracing用プロキシメッシュが作成可能となっており、こちらを利用すると通常のFallback Mesh(LOD0)に加えて、更に粗いLOD1を作成することが可能です。

https://www.docswell.com/s/EpicGamesJapan/KWM1EQ-CEDEC2025-ue5_6update#p91

4) RTプロキシ/フォールバックを下げても削減が鈍い件

20％と1％が変わらない状態とのことで推測できるケースとしましては、既に64Trinangle数以下となっているケースが考えられます。

こちらエンジン実装内の以下箇所にてターゲットの最低値が64として設定されており、こちらのキャップにより変わらない状態となっている可能性が考えられます。

.\Engine\Source\Developer\NaniteBuilder\Private\NaniteBuilder.cpp

TargetNumTris = FMath::Max( TargetNumTris, 64u );実際にRTジオメトリとして使われているかについては、PS5上では利用できませんが、

WindowsPC上の場合”stat D3D12RayTracing”コマンドにてBLAS、TLASのサイズの内訳が表示可能となっており、

また"D3D12.DumpRayTracingGeometries all"を実行することで各ジオメトリデータをリスト化することが可能です。

まずはこちらを参考に削減できるものがないかご確認いただければと思います。

5) RT除外推奨対象(草・空など)と副作用

RTから除外する場合Lumen SceneからのGIやReflectionの効果が消えてしまうため、

こちらで許容できるか目標とするビジュアルによって除外の可否を検討頂く形になるかと思います。

6) UE5.7×PS5の既知問題

プール上限値よりも多くなってしまう状況に関しましては、最低1つのLODが読み込まれる状態から溢れてしまっている状況かと思われます。

必要に応じてRaytracing用プロキシの活用等をご確認いただければと思います。

[Attachment Removed]

anonymous-edc · March 17, 2026, 7:19am

お世話になっております。

長文にもかかわらず、丁寧なご返答ありがとうございました。

ご案内いただいた通り、まずは

“D3D12.DumpRayTracingGeometries all” を用いてネックの特定を進めたいと考えております。

その上で、調査にあたりいくつか追加で確認させてください。

■1）メモリ内訳について

ご回答内容から、Lumen有効時のメモリ増加について

全体で約1GB増加
うちRTAS以外（Surface Cache等）が約500〜600MB
RTASが約400MB前後

という理解でよろしいでしょうか？

また、RTAS以外のメモリ（Surface Cache等）について、

削減可能な手段（設定・運用・品質トレードオフ含む）があればご教示いただけますでしょうか。

RTAS側で削減しても一定量が残る認識のため、こちらも最適化余地があるか確認したい意図です。

■2）Nanite Proxy / Fallbackが効きにくい要因について

Fallback Triangle数を極端に下げても効果が限定的な点について、

64Triangle制限の可能性をご教示いただきありがとうございました。

この場合、Triangle数としては十分に削減されている一方で、

メモリ増加の主因が別要因（例：インスタンス数やBLAS数）に移っている可能性もあると考えております。

このように、Triangle数以外（インスタンス数等）が支配的となるケースについて、

発生しやすい条件や判断の目安があればご教示いただけますでしょうか。

以上、恐れ入りますがご確認のほどよろしくお願いいたします。

[Attachment Removed]

Yutaro_Sawada · March 18, 2026, 8:43am

ご確認頂きありがとうございます。

Lumen関連メモリの内訳としましては、ご記載頂いているような形で約1GBほどになっている状況かと思われます。

AS関連の設定以外にも、いくつかメモリ削減に有効な設定がありますので下記で紹介させていただきます。

(1)RTAS以外のメモリ（Surface Cache等）の削減について

RTAS以外でLumen関連のメモリ削減を行いたい場合に効果的なものとしましては、Distance Fieldsに関する設定やSurface Cacheのアトラスサイズがあります。

・Distance Fieldsに関する設定

Distance Fieldsは、マージを行い全体を簡略化して表現しているGlobalDistanceFieldsと、個別のDistance Fieldsがテクスチャアトラスとしてメモリに展開されます。

GlobalDistanceFieldsは、r.AOGlobalDFResolution(デフォルト128)で解像度の設定が可能で、こちらは単純にGlobalDistanceFieldsの解像度に影響が起きます。

個別のDistance Fieldsの使用状況に関しては、r.LumenScene.DumpStats 2で表示可能となっており、

アトラスサイズに関してはr.DistanceFields.BrickAtlasMaxSizeZで調整が可能です。(デフォルト32でMax 256MB消費、16にするとMax 128MB消費)

こちらを削減することでメモリに乗らないDistance Fieldsが発生する可能性がありますが、適宜追い出して読み込まれる想定ですので描画上許容できるか確認しつつ調整が可能です。

DumpStatsで不必要に解像度が高いものが確認された場合はStatic Meshの設定からDistance Fieldsの解像度を調整して削減することも可能です。

またランタイムでの設定は行えませんが、HWRTの場合以下コマンドにてDistance Fields自体を読み込まない設定も可能です。

こちらはDistance Fieldsを利用する機能が使えなくなるため、使用状況により検討頂く形になるかと思います。

r.DistanceFields.SupportEvenIfHardwareRayTracingSupported=0

・Surface Cacheのアトラスサイズ

Surface Cacheのアトラスサイズに関しては、r.LumenScene.SurfaceCache.AtlasSizeコマンドで設定可能となっており、

利用されているAllocateCardAtlases()関数を確認いただくと、この解像度をベースに各種テクスチャが作成されている箇所が確認できます。

void FLumenSceneData::AllocateCardAtlases(FRDGBuilder& GraphBuilder, FLumenSceneFrameTemporaries& FrameTemporaries, const FSceneViewFamily* ViewFamily)※PS5よりもメモリの制約が厳しい一部のプラットフォームの場合デフォルト4096の半分の2048が設定されており、おおよそ200MBほど削減可能の見込みです。

この値を下げることによるデメリットですが、以下資料で紹介されているようなLumen Sceneにおいて利用しているSurface Cache(Lumen Card)が減るため、物量が多い場合に物理ページが足りずにキャプチャが不十分な場所が発生してしまうケースがございます。

https://www.docswell.com/s/EpicGamesJapan/5EV87K-UE5_Lumen101#p38

Surface Cacheの情報は、r.LumenScene.DumpStats 1コマンドで取得可能となっており、

使用状況としては、以下のようなAllocated XXX physical pagesやPhysical texels行のusageが参考になるかと思います。

Allocated 256 physical pages out of 256
Physical texels: 3.874M, usage: 96.848%

※各ページは128x128となっており、AtlasSizeが4096の時は1024ページ、2048設定の場合は256ページの物理ページがあります。

128x128未満のSurface Cacheの場合は1ページの中にグループ分けされて保存され,

128x128以上のSurface Cacheは複数ページを利用する可能性もあるためページ数=Surface Cacheではありません。

このグループ分けされたページの使用状況は、Surface cache Bin Allocator 項目で確認可能です。

r.LumenScene.SurfaceCache.CardMaxResolutionでカードのサイズを制限することで大きいSurface Cacheを作らないように制限したり、以下ページに記載しているようなr.LumenScene.SurfaceCache.CardMaxTexelDensity(要求されるSurface Cacheの解像度に影響)やr.LumenScene.SurfaceCache.CardTexelDensityScale(距離に応じて影響させるScale)などを設定して要求されるページを減らすことが可能です。

これらは最終的にGIやReflection効果における解像度が減ることになるため、効果を確認しつつ調整することになるかと思います。

https://www.docswell.com/s/EpicGamesJapan/5Q8Q67-2023-12-21-185240#p75

(2)Triangle数以外（インスタンス数等）が支配的となるケースについて

こちらは”D3D12.DumpRayTracingGeometries all”コマンドを用いてレベルへのメッシュ配置状況を確認いただくことが原因特定へのヒントになるかと思います。

※デフォルトで大きいものから順に表示され、メッシュ名が表示されますので数が多いといった場合もこちらから確認可能かと思われます。

お手数おかけしますが、上記情報を元に削減方針を検討頂けますと幸いです。

よろしくお願いいたします。

[Attachment Removed]

anonymous-edc · March 19, 2026, 5:47am

ご返答ありがとうございます。

すみません、一点補足させてください。

＞PS5（UE5.7.3）で、HW LumenをONにするとメモリが1GB程度使用される件

現在、当プロジェクトではSW Lumenを使用しております。

そのため、「Lumenオフ → HW Lumen ON」ではなく、

「SW Lumen → HW Lumen」に切り替えた場合のメモリ挙動についてお伺いしたいです。

その場合だと、回答いただいている内容から変わりはあるでしょうか？

具体的にはRTAS以外のメモリはどうなるかという点が気になっています。

説明が不足しており失礼いたしました。

上記条件の場合について、ご教示いただけますでしょうか。

[Attachment Removed]

Yutaro_Sawada · March 19, 2026, 9:09am

現在SWRTからHWRTへの変更を検討頂いているとのこと承知しました。

前回紹介させていただいた内容は、基本的にどちらのLumenモードでも有効な対策となっています。

RTASがHWRTの場合に必要な追加のメモリコストとなりますが、Surface Cacheはどちらのモードでも内部で利用しており、Distance Fieldsに関しましては通常SWRTで利用するものですが、デフォルトではHWRTの場合でも保持しているため、SWRTに切り替えができなくなる代わりにr.DistanceFields.SupportEvenIfHardwareRayTracingSupported=0にて削減可能となります。

お手数おかけしますが、よろしくお願いいたします。

[Attachment Removed]

anonymous-edc · March 24, 2026, 8:28am

ありがとうございます。

・SurfaceCacheについて調査したところ、SWRTとHWRTの間で大きな差は見られないことが分かりました。

・また、D3D12.DumpRayTracingGeometries allを実行した結果、約0.1MBのデータが約3,000件存在していることを確認しました。

以上を踏まえ、こちらの認識に誤りがある可能性もあるため、確認させてください。

RTAS：約391MB

RT Geometry：約323MB

UAV / RenderTarget：約198MB

これらを合計すると約912MBとなりますが、この値が増分の主な要因と考えて問題ないでしょうか。

また、RT Geometryに関する理解が十分でなかった点についても認識しております。

もし上記の理解が正しい場合、インスタンス数がボトルネックとなっている可能性が高く、物量を削減する、あるいは品質とのトレードオフにより対象物を絞ることが最も効果的な対応になると考えていますが、この認識で問題ないでしょうか。

お手数ですが、ご確認のほどよろしくお願いいたします。

[Attachment Removed]

Yutaro_Sawada · March 27, 2026, 3:47am

お世話になっております。

本件確認にお時間を頂いておりました。申し訳ございません。

こちらからの返信にて一部誤解を招いてしまう記載をしてしまっていたため、補足と現状の認識をまとめさせていただきます。

まず最初の返信にて、1GBほどの増分は想定の範囲の旨記載させていただいておりましたが、

この記述に関してはデフォルト設定を前提に、Lumen無しとHWRTのLumenを比較にて1GB程度の増加は発生してしまうという意図となっておりました。

ご質問頂いていた内容から、Lumen無しの状態からHWRTのLumenを有効にすることで1GB程度増加していて、

RTAS(TLAS/BLAS)の削減によって増加分が600MB前後まで落ちることを確認されていた、という認識でしたが、

その後のご指摘で、今回のご相談はSWRTからHWRTへの変更時の挙動とのことでしたので、切り替え時のメモリ差分としてはRTAS分が増加するという認識です。

※SurfaceCacheが消費するメモリについてはSWRTとHWRTの間で大きな差はないため

DumpRayTracingGeometriesについて

D3D12.DumpRayTracingGeometriesで確認できるジオメトリデータ(RT Geometry)はBLASデータとなるため、

本スレッドで扱っているrhi.DumpMemoryで確認可能なRayTracing AS(RTAS)にRT Geometryは含まれる認識です。

D3D12.DumpRayTracingGeometries出力の注意点としまして、

Editor上の場合、レベルで実際に利用していない不必要なデータもロードされている可能性があるので、

パッケージ化またはQuick Launch Current Level等、単体で起動後に確認いただく事で実際に必要なものを確認可能となっています。

rhi.DumpMemoryのRayTracing ASに含まれる内容とサイズについて

rhi.DumpMemoryで確認可能なRayTracing AS(RTAS)には、BLASに加えてTLASが含まれており、

TLASに関してはインスタンスの数とGPUから取得したサイズからプール形式で16MB単位で取得を行います。

また、TLASは用途に応じたLayer(Base、Decals、FarField)が3つ存在するため、

デフォルトで48MB(16MB*3)ほど消費しTLASはインスタンス数に応じて増えます。

こちらがRTASとRT Geometryのサイズの差分になっている状態かと思います。

まとめると、「SW Lumen → HW Lumen」に切り替えた場合のメモリ挙動については

最新のご投稿で記載されていたデータのシーンではRTAS：約391MBが増分している状況かと思われます。

今回約0.1MBのデータが3000個存在しているとのことでしたので、個々のBLAS自体は小さいものの、ユニークなメッシュの個数によりメモリが増加している状況かと思われます。

表現上削減できるものに関しては、Static Meshアセット毎の詳細設定からSupport in RaytracingフラグをDisableとすることで削減できますので、こちらの対応を検討頂けますと幸いです。

※Foliage(HISM)やInstanced Static Meshなどのインスタンスに関してはメッシュごとにBLASが共有されます。

長くなってしまいましたが、ご不明な点がありましたらご指摘いただければと思います。

お手数おかけしますが、よろしくお願いいたします。

[Attachment Removed]