Unreal texture streaming: capture the budget before changing it

When Unreal reports that texture streaming is over budget, record the streaming metrics and the scene before changing the pool size. The useful question is which resources and viewpoints create the pressure on the target machine. Hiding a warning or increasing an allocation does not, by itself, show that the game fits its memory budget.

Keep the warning attached to a scene

A screenshot of a red warning can start a report, but it rarely contains enough context to choose a fix. Record the build, machine, graphics settings, render resolution and route that reached the scene. Note whether the game has just loaded, the camera has turned towards a new area or the same view has been held for a while.

This is an evidence-gathering guide, not a claim that AneeMate or another QORPO game currently has a particular streaming defect. The studio's live page identifies development activity; an optimization result needs a controlled observation of the relevant build. Our render-resolution comparison guide covers another variable to keep stable.

Read more than the headline budget

Epic documents STAT STREAMING as the starting point for streamer performance and memory metrics. Its reference distinguishes Texture, Streaming and Wanted pools, and warns that pool terminology and currently used mips do not describe exactly the same thing. Keep the metric names in the capture rather than copying one unexplained number into a chat.

The pool is not simply a counter of the visible ground texture. Epic's configuration documentation includes other texture resources in the allocation, with platform-specific differences. That is a reason to inspect the project's actual usage. It is not evidence that a particular resource is the cause of your warning.

Capture the display after the scene settles and during the transition that triggered the concern. A steady view and an arrival can put different demands on the system. Preserve both moments so that a change which improves the still frame does not hide a worse transition.

An original route for a controlled comparison

Here is a proposed small test, not measured QORPO performance. Start outside a room, enter through a doorway, turn towards a detailed wall and stop at a marked location. Repeat with the same camera direction and settings. Save the metric capture and a normal scene image at the stop, plus a short recording of the approach.

Write down what the player would notice. Is a surface visibly soft for several seconds? Does it sharpen once and remain stable, or appear to change repeatedly? Does a frame hitch coincide with the turn? These are observations to investigate, not interchangeable names for a single cause. A memory metric alone cannot tell you how readable that wall looked.

Our mip review exercise asks whether an individual texture still communicates its material at the mip the player sees. The present exercise asks about the scene's resource demand over a repeatable route. Keep those questions connected without treating them as the same test.

Change one constraint at a time

Once the baseline is saved, choose one hypothesis. For example, investigate whether a particular group of oversized textures contributes more detail than the chosen viewpoint needs. Review their settings and visible contribution before changing several global controls. Record the affected assets, the reason for the change and how the same route will be repeated.

A different investigation may concern the configured budget for a supported device class. Epic documents r.Streaming.PoolSize in megabytes, including the special unlimited setting. That setting is not a universal recommendation. A project still needs room for its other resources and evidence from the machines it intends to support.

Do not present the disappearance of a warning as the entire result. Compare memory behaviour, visible quality and the route recording. A setting can trade one problem for another. Save the original configuration so the comparison can be reversed and another developer can reproduce the observation.

Finish with an actionable handover

A useful handover includes the exact build, route, settings, before-and-after captures and the single change. State which observation improved and which did not. If the team has not tested a lower-memory target, say so. Avoid extrapolating from a development workstation to every supported PC.

If the evidence points elsewhere, keep that result too. Our asset-loading guide discusses planning around the moment content is needed. A texture-streaming investigation should not become a blanket explanation for every delay at that moment. The next experiment should follow the captured evidence.

Frequently asked questions

Should I copy a pool size from someone else's PC?

No single number establishes the right budget for your project and target hardware. Treat another configuration as context, then measure your own scene and the other resources competing for memory.

Does switching off streaming prove the issue is fixed?

No. Epic documents that disabling the streamer fully loads texture mips. That changes the memory behaviour being tested. It can be a diagnostic comparison, but needs a separate justification before becoming a shipping configuration.

What can I report without a profiler capture?

Provide the build, machine, settings, route and a recording of the visible issue. That is useful evidence, while leaving the cause unconfirmed. Do not invent a memory saving or frame-rate gain to fill the gap.

Follow QORPO development for more bounded production exercises. The objective is a repeatable decision about a real scene, with a change another developer can inspect.

Sources: Epic's Texture Streaming Metrics and Texture Streaming Configuration, checked 8 November 2026. This article proposes a review workflow; no game benchmark or optimization saving is claimed.