UE5 Texture Streaming Pool Over Budget: Diagnose and Fix

Direct answer: fix “Texture Streaming Pool Over Budget” without hiding the cause

“Texture Streaming Pool Over Budget” means Unreal's texture streamer wants more texture memory than the pool currently permits for the scene and view. Start with STAT STREAMING, reproduce the warning from the same camera path, and identify whether the excess comes from oversized texture mips, missing or unusable mips, Never Stream assets, unexpected non-streaming allocations, or a pool budget that is genuinely too small for the target hardware. Use r.Streaming.PoolSize only as a measured test variable. Do not choose one universal megabyte value or raise the pool until the warning disappears.

The durable fix is a content-and-platform decision: set a texture-memory budget for each target class, make the expensive textures streamable, reduce resolution only where the visual result survives, preserve required mip chains and compression, and then validate the same representative route in the editor, PIE, standalone, and a packaged build. Virtual Texturing may help specific large or layered workloads, but it is not an automatic replacement for diagnosing conventional texture streaming.

Fast triage checklist

1. Reproduce the warning from a named map, camera route, resolution, scalability level, and target RHI.
2. Run STAT STREAMING and capture the pool, required pool, visible mips, hidden mips, forced mips, and non-streaming values.
3. Inspect the largest contributing textures before changing project-wide settings.
4. Test one change at a time: texture dimensions, mip availability, LOD bias or texture group, compression, Never Stream, material use, or pool size.
5. Re-run the same camera route and compare memory, image quality, pop-in, and frame pacing.
6. Confirm the result in a standalone or packaged build on representative low-, mid-, and high-memory devices.

What the warning actually measures

Unreal's texture streamer selects which mips should stay resident for the current views while respecting a memory pool. The pool is not simply “all visible color textures.” Epic's Texture Streaming Configuration notes that r.Streaming.PoolSize is expressed in megabytes and that the texture pool can include UI textures, NeverStream textures, cubemaps, and, on some platforms, non-texture GPU resources. That is why a warning can persist even when the textures nearest the camera look ordinary.

The warning is a budget signal, not proof of one particular bad asset. A scene can exceed its budget because several individually reasonable texture sets become resident together, because a cinematic camera makes many high-detail mips desirable, because an asset has no usable mip chain, or because non-streaming allocations consume headroom. Conversely, a larger pool can be correct when the existing pool is lower than the measured budget available on the shipping hardware. The decision must be tied to a platform profile and a reproducible workload.

Do not confuse this warning with a generic GPU out-of-memory crash. The streamer can be over its requested pool while the process still runs. It responds by dropping wanted mips, which may produce blurry textures, late detail changes, unstable residency, or repeated pool warnings. A crash, device removal, or broader render-memory exhaustion needs a wider GPU-memory investigation.

Diagnose the warning with STAT STREAMING

Open the affected map, place the camera at the failing route, wait for loading to settle, and run:

STAT STREAMING

Epic's Texture Streaming Metrics documents STAT STREAMING as the primary view of texture-streaming performance and memory counters. Capture it after a cold load and again after the representative traversal; a single idle-editor screenshot can miss the peak. Keep the engine version, screen resolution, scalability level, editor viewport mode, and RHI with the capture so another developer can repeat it.

Read the groups as a cause map rather than hunting one red number:

• Required or wanted mips exceed the streaming pool: the current view asks for more streamed detail than the budget allows. Sort large textures, inspect wanted dimensions, and compare texture-group policy.
• Forced mips are high: assets, components, cinematics, or code may force residency. Find force-resident settings and prove they are needed for the shot or gameplay.
• NonStreaming Mips are high: memory outside normal streamable residency is consuming headroom. Inspect Never Stream, UI, cubemaps, render targets, and other allocations before raising the pool.
• Visible mips rise only on a particular route: camera distance, field of view, occlusion, or a dense material cluster drives the peak. Profile that route and reduce simultaneous high-resolution demand.
• The warning appears only after repeated travel: stale references, warm caches, or lifecycle behavior may be involved. Compare a clean launch, repeated travel, and teardown with the same test sequence.

The exact counter names and layout can change across Unreal versions. Use the Epic documentation version selector that matches the project and record the full output rather than copying a threshold from a forum screenshot.

Find the assets and settings that create the peak

Start with evidence from the failing view, then inspect the assets most likely to explain it. Useful checks include texture dimensions, pixel format, compression setting, texture group, LOD bias, mip-generation setting, number of mips, Never Stream, and every material or UI path that references the texture. A 4K texture is not automatically wrong; it is wrong when its resident detail costs more than its measurable visual contribution on the target view and hardware.

For imported FBX, GLB, OBJ, USD, scan, or AI-generated assets, keep the full handoff visible: Upload or Import → Preview → Fix → Optimize → Convert → Export → Unreal validation. Check that source packages did not attach multiple near-identical 4K maps, embed unused materials, export a mask as an uncompressed color texture, or omit mip-ready dimensions. Pre-import cleanup reduces noise, but the final residency decision must still be verified in Unreal because materials, texture groups, streaming rules, and platform profiles are project-native.

Pay special attention to these root causes:

• Oversized source resolution: the texture contains detail the asset never presents on screen. Compare the maximum projected size on the actual camera route before reducing it.
• Missing or disabled mip generation: the streamer cannot select cheaper lower-detail levels. Fix the import or mip-generation policy and inspect quality at distance.
• Inappropriate texture group or LOD policy: a broad group may keep more detail than this asset class needs. Prefer an owned group policy over scattered per-asset exceptions.
• Wrong compression or semantic type: normals, masks, HDR data, UI, and color textures have different requirements. Select compression from the data's meaning, not only file extension.
• Never Stream or forced residency: reserve these for assets that genuinely require stable full-detail residency. Remove them only after verifying there is no UI, cinematic, or gameplay requirement.
• Duplicate or unused references: material instances, hidden meshes, variants, or stale content can keep avoidable textures relevant. Remove references through normal source-control review, then cook and test again.

Fix the root cause in the right order

Use the smallest reversible change that addresses the measured cause. This order keeps visual quality and platform constraints visible.

1. Freeze the baseline. Save the failing STAT STREAMING capture, route, build identity, pool setting, and screenshots at comparison viewpoints.
2. Repair mip availability. Ensure streamable world textures have valid mip chains and that mip generation was not disabled unintentionally. Reimport only from a controlled source asset.
3. Right-size the heaviest textures. Reduce dimensions or apply LOD bias where the target camera cannot resolve the removed detail. Check hero objects and close-ups separately from background assets.
4. Correct group and compression policy. Put related assets under a deliberate texture group and data-appropriate compression. Re-check package size, memory, and visible artifacts.
5. Remove unjustified forced residency. Audit Never Stream and force-resident behavior, then test cinematics, UI, rapid turns, and teleport cases for unacceptable pop-in.
6. Reduce simultaneous demand. Split overly dense material sets, remove duplicate maps, simplify distant variants, or change level composition when too many high-cost textures become wanted at once.
7. Evaluate the pool last. If the optimized content still fits the hardware's measured GPU-memory budget with safe headroom, set a platform-specific pool deliberately and document why.

During diagnosis you can change the runtime value as an experiment:

r.Streaming.PoolSize 1500

That number is an example command, not a recommended production value. A console change is temporary and helps answer “would more pool headroom remove this specific pressure?” Persistent configuration belongs in the project's reviewed configuration and device-profile strategy. The correct value differs by platform, GPU memory, resolution, other render features, and the scene's peak. Test low-memory devices first; an editor workstation can hide an unsafe shipping choice.

Decide when Virtual Texturing is relevant

Conventional texture streaming and Virtual Texturing solve overlapping but different residency problems. Epic's Texture Streaming Overview explains the conventional streamer workflow; Runtime Virtual Texturing and Streaming Virtual Texturing introduce their own tile production, feedback, material, cache, and platform considerations. Do not enable virtualized texturing merely because one conventional pool warning appeared.

Virtual Texturing is worth a separate evaluation when the workload contains very large surfaces, layered landscape data, or texture sets whose tiled access pattern is a better fit than full mip residency. The evaluation must include material compatibility, tile upload behavior, cache pressure, visual latency, cook size, target-platform support, and shader or sampling cost. Keep a fallback and compare both paths under the same camera route and content revision.

If the problem is duplicated 4K textures, missing mips, an incorrect compression format, or unjustified Never Stream, converting the workload can move the cost without fixing the content mistake. Fix those authoring issues first. Use the dedicated Runtime Virtual Texturing guide for the separate RVT decision rather than mixing two migrations into one troubleshooting pass.

Validate image quality, performance, and packaging

A passing result needs more than a cleared warning. Run a repeatable matrix and keep before-and-after evidence:

• Editor viewport: capture STAT STREAMING, reference-camera screenshots, and pool plus non-streaming values. Pass when the warning is explained and intended detail remains stable.
• PIE: capture startup, traversal, texture pop-in, and frame pacing. Pass when the gameplay route stays within budget without unacceptable late mips.
• Standalone: use a cold launch and repeat the route at representative resolution. Pass when the result does not depend on editor-only warm state.
• Packaged build: run a Development or Test build on each hardware class. Pass when pool policy, cooked mips, compression, and quality match the shipping configuration.
• Stress route: exercise fast travel, teleport, camera cuts, a dense scene, or repeated map travel. Pass when the peak recovers predictably without accumulating unexplained residency.

Compare GPU memory alongside frame time and visual output. A lower pool can reduce residency but cause distracting blur or churn; a larger pool can suppress the warning while stealing headroom from Nanite, Lumen, render targets, or other GPU resources. Set an explicit headroom requirement and fail the test when another render feature becomes unstable.

Validate at the project's actual screen percentages and scalability tiers. A fixed desktop capture does not prove console, laptop, cloud-streaming, or mobile behavior. If a platform exposes a different counter set or shares memory with the CPU, document that boundary and use its native profiling guidance rather than translating a discrete-GPU budget mechanically.

Common failed fixes and what to do instead

“Set the pool to a huge value and ship it”

This hides the warning without proving that the hardware has safe headroom. Use a larger value only as a controlled experiment, then create per-platform budgets from measured packaged builds.

“Run DisableAllScreenMessages”

Suppressing on-screen messages does not reduce residency or repair content. Preserve warnings during diagnosis and resolve or explicitly accept the measured budget condition.

“Convert every texture to Virtual Texturing”

Virtualized tiles add a different workflow and runtime cost. Select them for a suitable workload after a side-by-side profile, not as a global reaction to one pool warning.

“Downscale every texture”

Blanket downscaling can damage hero assets, UI, cinematics, or close-range readability. Rank assets by memory contribution and projected size, then make reversible group or per-asset decisions.

“It passes in PIE, so it is fixed”

PIE can reuse editor state and does not prove cooked data or shipping profiles. Repeat the cold standalone and packaged route on target-class hardware.

Team handoff checklist

• Unreal Engine version, project revision, target RHI, device profile, screen resolution, and scalability tier.
• Failing map and deterministic camera or gameplay route.
• Before-and-after STAT STREAMING captures, including pool and NonStreaming Mips context.
• Changed textures, source files, dimensions, mip settings, compression, groups, and residency flags.
• Temporary console values kept separate from persistent configuration changes.
• Visual comparison points and known exceptions for hero, UI, cinematic, or accessibility assets.
• PIE, standalone, and packaged-build results on every claimed hardware class.
• Rollback revision and the condition that reopens the budget decision.

SEELE AI handoff and product boundary

For a new concept, SEELE AI can generate a native Unreal 5 game, provide a browser preview, support optimization and packaging, and provide the project or packaged output for download. The Unreal game creator covers that creation path, while the Unreal 3D asset optimizer supports exported-asset review before Unreal import.

That new-project workflow is separate from troubleshooting an existing project. Existing-project texture work stays with the Unreal team: open and edit the current .uproject, change DefaultEngine.ini or device profiles, toggle Virtual Texturing, modify texture assets, run STAT STREAMING, cook the build, and prove the platform budget. Unreal Engine is a trademark of Epic Games; this independent guide does not imply Epic endorsement.

Official sources and related Unreal guides

• Texture Streaming Configuration in Unreal Engine — console variables and pool configuration.
• Texture Streaming Metrics in Unreal Engine — STAT STREAMING and memory/performance metrics.
• Texture Streaming Overview for Unreal Engine — first-party overview of conventional texture streaming.
• Unreal Engine rendering guides library — related rendering, VFX, and performance workflows.
• Unreal Runtime Virtual Texturing guide — evaluate RVT as a separate workload decision.

Frequently asked questions

What does “Texture Streaming Pool Over Budget” mean in UE5?

It means the texture streamer wants more memory for the current views than its configured pool permits. It does not identify one bad texture by itself. Capture STAT STREAMING and inspect streamed, forced, and non-streaming demand before deciding whether the root cause is content, residency policy, or a genuinely undersized platform budget.

Which command shows texture streaming memory in Unreal Engine?

Use STAT STREAMING in the Unreal console and reproduce the warning through a fixed camera or gameplay route. Save the complete capture with engine version, RHI, resolution, scalability tier, map, and build identity. Counter layout can vary by engine version, so use the matching Epic documentation version.

Is increasing r.Streaming.PoolSize a valid fix?

It can be valid when packaged-build measurements show that optimized content needs a larger pool and the target hardware retains safe GPU-memory headroom. It is not a universal fix. Use it temporarily to test the hypothesis, then document a platform-specific persistent budget instead of copying one megabyte value across devices.

Why are NonStreaming Mips high?

High NonStreaming Mips can point to memory that the normal streamer cannot freely reduce, including Never Stream textures, forced residency, UI textures, cubemaps, or other allocations included in the pool on some platforms. Trace the contributing assets and resource types before increasing the pool or reducing unrelated streamed textures.

Should I enable Virtual Texturing to remove the pool warning?

Not automatically. Virtual Texturing is a separate tiled residency workflow with material, cache, feedback, cook, shader, and platform tradeoffs. First fix missing mips, oversized source maps, incorrect compression or texture groups, and unjustified forced residency. Compare Virtual Texturing only for workloads that genuinely benefit from tiled access.

How do I verify a texture streaming fix before shipping?

Repeat the same representative route in the editor, PIE, standalone, and a packaged build on each claimed hardware class. Compare STAT STREAMING, total GPU memory, frame pacing, texture clarity, pop-in, cold-load behavior, and recovery after camera cuts or travel. Keep a rollback revision and a documented headroom requirement.