Memory
The Memory tab reports lighting assets and memory estimates. It is a read-only inspection panel: changing the report scope does not change compression, resolution, or bake quality.
Display
Current Level
Default selection.
Inspects the editor world's current level. This is the active editing level, not automatically every loaded streaming level. Check the scope when a multi-level map appears to have missing assets.
It can inspect current in-memory lighting state, while the disk figure still comes from saved files.
All Levels
Scans project map assets under /Game, including maps not currently open, and inspects their saved build-data packages. It does not switch the editor to each map.
This can take longer and load build-data packages for inspection. A map with no saved build-data package can be counted in scope without contributing lighting data. It is not a complete installed-engine or plugin-content scan.
Refresh
Rebuilds the report for the selected scope. The panel also refreshes when opened and when the map changes. Refresh after a bake, capture update, or save when comparing results.
The Details search filters what you see; it does not rebake assets or change their settings. Clear the search if an expected group is hidden.
Memory Summary
Scope
Number of levels included by the selected mode. It does not count actors or textures. In All Levels, this includes discovered maps even if some have no saved lighting data to report.
Build Data On Disk
Size of saved BuildData packages in scope. Duplicate package paths are counted once. Unsaved changes are not represented by the saved file size.
A disk package can be compressed differently from its runtime data, so this number should not be used as a GPU-memory total.
Lightmap GPU Memory
Reports resident and fully loaded texture memory. “Resident” describes the currently resident mip set; “fully loaded” estimates the allowed full mip set.
For virtual lightmaps these are estimated tile footprints, not exact private allocations. Physical tiles live in shared pools, so charging one pool allocation to every texture would be misleading.
Probe Payload
Allocated probe-data size and probe count for the reported fields. A larger box or smaller Voxel Size can increase this substantially.
It is the lighting payload, not the complete actor's memory or the size of the whole map package.
Total Lighting Memory
Combines the lighting estimates and reports baked-shadow CPU and disk figures separately. Allocated shadow virtual-texture pools and page tables across loaded scenes are counted once. Shared frame buffers are excluded.
Loaded-scene shared allocations do not become neatly attributable to one map simply because Current Level is selected.
This panel is not a GPU profiler. Geometry, general textures, gameplay objects, many renderer buffers, and other systems are outside this report. Use the estimates to compare lighting choices, not to claim a total packaged-game memory budget.
Lighting Assets
Lightmaps
Lists unique textures, not one entry for every mesh using them. Each row includes the owning/report level, dimensions, and resident versus fully loaded memory or virtual-texture estimates.
Open the texture from its row to inspect it. A large atlas dimension does not mean every mesh received that many texels; multiple bindings can share it.
Baked Static Shadows
Lists Spectral baked-shadow assets. Rows show loaded CPU bytes and compressed page data, which are different measurements. Open the asset for inspection rather than reading the disk figure as GPU residency.
Volume Probes
Lists field names, level names, probe counts, and payload sizes. In an All Levels saved-data scan, fields can have generated report names rather than the currently selected actor's label.
Use this group to compare the cost of volume bounds and spacing.
Prefabs
Reports shared captured surface lighting and probe payloads, with captured textures available for inspection. The capture's combined figure uses a fully loaded texture estimate and excludes mesh geometry.
This is not the total Blueprint asset size. Several instances reusing a capture do not mean the stored shared payload should be interpreted as a new independent bake for each one.
See Reading memory estimates for comparison pitfalls and Optimization for changes that reduce lighting cost.