After working on any level in the editor for any length of time, I start to get the ‘texture streaming pool over X KiB budget…’ message.
The longer I carry on the higher X gets until eventually, all the textures get ‘blown out’ ( fuzzy ) and I have to re-load the level in the editor.
There’s not a vast amount of stuff in the level, I’m not adding textures / actors. I’m just adjusting things / moving them around etc as I work on the level. Alternating between edit and play.
It really looks like a memory leak to me, although I have no idea how to prove that.
Hey there. Try this while not in Play: Bring up the console (tilde key) and type r.Streaming.PoolSize and set it to a high value like 4096 and see if you still get the same warning.
It’s definitely not a leak in the editor, but caused by the way you’ve authored your materials. I run into it while working on ArchViz where my usage of many 4K textures triggers the warning… while, during gamedev, I try stay within a certain limit by keeping an eye on my mips and texture sizes. But it’s not an uncommon issue since, if you set that value to 0 it would uncap the pool, it’s just there as one of the tools that help you stay within whatever texture budget you’ve set
If I look in the statistic window when running / editing, I can see the current memory column only ever goes up. Surely it should go down again when I move away from high res objects?..
Are you able to narrow it down the to the objects/materials driving up the pool? You could also try migrating your level to a blank project to see if the issue persists across.
I’ve found the objects, ie, the material. I’m not quite sure what change to make to the material yet, for some reason, it seems to be stuck on max detail, even when I’m nowhere near it.
But I guess the main thing I don’t get is why the streamer doesn’t start dropping textures that are far away. That’s it’s job, isn’t it?..
It should but each texture asset has settings that can affect or prevent this, like the MinLODSize, MipBias or TextureGroup it belongs to. There’s also a check to NeverStream a texture which will always keep it in memory, regardless of how far it is from you.
I’d recommend building your streaming data from time to time as you work, to ensure the Mip computations are kept up-to-date. Then you could more carefully check the settings of each texture used by your most expensive materials against this glossary to find any funky settings that might’ve been overlooked during import.
Thanks for your help so ar duderseb ( I have checked these things you indicate ).
It basically boils down to two things:
In this case, I have about 180 actors which are making up a large cliff face. Once I’ve been near them, they stay on 4096 res, even after walking away again. I know technically I can routing around in there and adjust the actually textures, or set the View MipBias in the material. But it’s not my material and it’s complicated. Is there a kind of ‘blanket’ way to adjust this?
So I go near the cliffs and then I go away again. So what. Why doesn’t the streamer unload the high res cliff textures and load the high res ones for the material I’m approaching, instead of whining about running out of budget?..
Any help gratefully received - especially on 1.
I discovered that using
r.Streaming.FramesForFullUpdate 100
( I have no idea what the default is ), makes the streaming work normally. IE, the amount used GOES DOWN when I move away from objects… pfff… no idea.
Was about to suggest that and a couple other r. console commands for your “blanket” solution - glad it works now, indeed it should be something in the material/texture settings FYI, you can call them on BeginPlay by wiring an Execute Console Command node in your Level Blueprint.
