Although the warning ‘TEXTURE STREAMING POOL OVER’ (followed by a value in mebibytes) uses intimidating red text and is written all in shouty capital letters, it’s not something to panic over. This is a very common warning that is simply telling you that the textures in your scene are using more memory than you have allocated for them, and as a result the engine has started decreasing the quality of your textures to compensate.
There are two productive ways to fix the ‘Texture Streaming Pool Over # MiB’ warning message. The first is to increase the size of your texture pool either via the console or your project’s configuration files. The second is to optimize your levels/materials to keep the size of your textures down.
Side note: Yes, there are also unproductive ways to clear this error. If you absolutely must, in a pinch you can enter the command DisableAllScreenMessages into your console and all warning messages will be suppressed. Just remember this isn’t actually solving anything though, and those warnings will be back the next time you open the editor. Don’t sweep your dust under the carpet. Fix it properly!
To understand why you’ve received this warning message you’ll need to have a basic grasp of Unreal’s texture streaming system – what it does, and why it’s so important. Let’s do a quick overview.
What is texture streaming?
No matter what kind of environment you’re making, your level is going to have textures – and if you’re making something anywhere close to substantial you’re going to have a lot of them. Even if you’re not using 4k texture maps for every single asset, the amount of data these textures contain will add up really fast. It’s a lot of information to keep in memory at any one time.
This is where Unreal’s texture streaming system comes in. It uses a combination of clever techniques to dynamically load textures in and out as required to improve the performance of your game. It also uses a level-of-detail optimization method called mipmapping to increase or decrease the resolution of your textures on the fly. This ensures that the least amount of texture data is loaded at any given time without sacrificing visual fidelity.
Using this technique will make your textures take up 33% more space on disk, but it will mean less data is loaded at any one time. They also make your textures look a lot better when viewed at a distance, like in this example.
Streaming data (including mipmap information) is precomputed as part of the Build all levels procedure. It can be generated on its own by selecting Build Texture Streaming from the Build menu.
The texture streaming system has been designed to make your textures look as good as possible, at any distance, and with the least possible overhead. Moreover, it is highly customizable to fit your project’s performance specifications with a wealth of configurable options.
You can wholesale disable texture streaming via your Project Settings – but I don’t know why you’d want to!
What is the Texture Streaming Pool?
The TEXTURE STREAMING POOL is a virtual storage container for all of the textures that are currently being drawn by the streaming system. This value will not be the same as the physical RAM you have installed on your machine (which is lucky, because you need some of that for your operating system and other vital services), and is composed of several different pools of memory that operate together to make sure textures can be streamed in and out safely.
You can enter the command ‘stat streaming’ into your console in either the editor or at run-time to see a comprehensive breakdown of your texture streaming system’s memory allocation.
You can see each pool’s maximum capacity in the far right column of the Memory Counters section. By default the size of the texture streaming pool is set to 1000 MB.
Option A: Increase your texture streaming pool memory allocation
This is the quick and easy solution. Simply increase the size of your texture streaming pool to encompass your texture data and you’re all set. Of course, this is only advisable if your hardware (and your target spec) has the memory to spare.
Check the bottom of this article for a quick and easy method of finding out how large your texture pool needs to be to meet your texture requirements.
You can change the size of your streaming pool in the editor with the following console command, where # is the value you want to set in megabytes.
You can check that your change was accepted by using the stat streaming command.
Remember, like many config commands entered via the console, altering the size of the pool this way is only temporary. It will reset to the default value of 1000 whenever you reopen the editor. If you want this change to persist, you’ll need to navigate to your project’s DefaultEngine.ini config file and add r.Streaming.PoolSize=# to the [/Script/Engine.RendererSettings] section. If it doesn’t exist, create it.
You’ll know it worked on editor restart because there will be a line in the output log marking the change, and you’ll see it reflected in your stat streaming profiler.
That’s it. Problem solved. Assuming you have the memory to spare. If not, there is always…
Option B: Reduce your texture overhead
If you don’t want to raise the size of the pool to meet the demands of your textures, then you’ll need to reduce the amount of data your textures require. It’s one way or the other.
Texture & material optimization is a huge topic that we’re not going to deep dive here (maybe one day), but here are a few quick tips to help you on your way to reducing your texture overhead.
- Reduce the resolution of your textures via the Maximum Texture Size value in your texture settings.
It’s very common for artists to author textures at up to four times the anticipated use-case resolution as a contingency. This means there are often 4k textures floating around that would look just as good at a quarter of that size.
Have a close look at your texture maps in the context of your level, and play around with reducing their resolution by half (and then half again if you can). You might be surprised at how little quality is lost for such a significant performance gain.
- Check your compression settings!
You’ll need to decide on a case-by-case basis as your texture compression settings will depend highly on how each specific texture is used. Going into detail on what each of these compression settings does is beyond the scope of this post – but you can start by checking out the official documentation here.
- Reduce or reuse your texture channels. Remember, most textures you’ll be working with have 3 channels (4 with alpha), and you may not be using all of them to full effect. Utilize texture packing where possible to combine multiple masks into one.
- If you’re using static lighting, then your lightmaps may take up a huge amount of your available texture memory. Even medium-sized levels can have hundreds of lightmapped objects packed into several atlases. Where possible, keep your lightmap resolution at an appropriate minimum to reduce this impact.
How big does my texture streaming pool need to be?
Here is a quick tip for figuring out the minimum size in MB that your texture streaming pool needs to be to encompass your level’s texture data.
If you input r.Streaming.PoolSize 1 into your console, you’ll set the texture streaming pool to 1 MB and all your textures will immediately be mipped out of existence – but this is okay. It’s just temporary.
You’ll notice now that as you move around the map the texture streaming pool over budget warning message will be updating to tell you just how over-budget you are. Zip around your map and pick out the highest number – that value (+1) is your minimum pool size.
Thanks for checking out my article. I hope it’s helped you understand why the texture streaming system is such a vital part of the engine – and why that warning message can get so persistent.
If you’re interested in further information on texture streaming, I absolutely recommend checking out Epic’s extensive documentation on both how it works, and how you can best bend it to your will.
If you’re keen to learn more optimization tricks for textures, materials, and more; VFX extraordinaire Luos_83 has been collating those he has discovered in a document which you can read here. Super useful!