Emptying the level doesn't free memory nor restores textures best lod


My game is sort of a baby editor, where players can spawn/destroy actors at will.

When i spawn too much actors, there is a point where all the textures go super low detail.

This is normal, it just tells me that i am using too much memory.

But when i destroy all the actors but one, i have two problems:

A) the remaining actor never gets its nice texture back, and no matter what i spawn after that, all the textures are super low detail

B) in the windows task manager, the memory taken by the game never decreases, here is a typical scenario:

  • i launch the game → 300 mo

  • i load my save with lots of actors → 1300 mo

  • i destroy all the actors → 1300 mo (the memory is not freed)

  • i reload my huge save → 2300 mo (the memory increases again)

In the hereabove screenshot, the central picture is before the heavy load (on the left), and the picture on the right is after the destruction of all other actors.

The only way i can get the textures back is to close and reopen the game.

To destroy the actors, i was using the aactor::destroy() function, and after some research, i used the function Rama gives in this thread, but it didn’t solve the problem.

So is it normal that the lowest LOD of all textures is used in an empty level after the level has been populated and emptied ?

Or am i destroying the actors incorrectly ?

Thanks !


Hey uced,

It sounds like you could have a texture streaming issue. as your assets are loading and destroying correctly. You can try increasing your streaming texture pool size, as well as debugging your texture streaming.

Be sure the assets you are loading and destroying have texture streaming enabled for their respective texture assets, i.e. MipMaps and the Never Stream option is checked on.

For more information about how to debug your textures, take a look at our documentation which will provide some helpful commands and tools to find where the issue lies.

Texture Streaming

Let me know if this was helpful, or if you are still having issues.


Hey Andrew,

Thanks for your answer, but i am still a bit confused.

I unchecked the texture streaming and it solved the problem, except the sky was all blurry. The sky is not so important in my game so at least i have a workaround.

Trying to be less violent, i checked again the texture streaming and made a few tests by loading my large save with various sizes for the texture pool. I tried 1024, 2048 and 4096 mo, and i watched the “stat texturegroup” in the console.

Using 1024 and 2048 bring expected results: when the memory becomes greater than the texture pool value, the textures go wrong.

But, strangely enough, using 4096 bring the same result as “no streaming”: the texture are always ok, no matter the memory used.

But i still believe there is something strange going on, as when i load several times the same save, the memory is never released and endelessly adds up.

In the three following screenshots (all taken with texture pool = 4096mo), you’ll find:

  • first: the memory usage right after launching the game (PIE)
  • second: after the first load (so you can see the size of one loading)
  • third: the size after a few loads of the save (you can see the memory accumulates to crazy values)

I am positive the assets are destroyed when i reload (doubled check the code, and when i move an object, there is not several copies of it at the same place, so i am sure they are destroyed before reloading).

I am by no mean a texture expert, so you might find this normal, at least you have the info, just in case there might be a real problem somewhere with memory freeing.

In the meantime, i am tempted to just uncheck the texture streaming, any idea of all the bad this might bring ?



Hey Cedric,

Thank you for the detailed response.

Are you rebuilding your scene between each iteration? Since you are loading and destroying actors, and modifying the max memory pool, you will want to rebuild your scene.

The reason your project seemed to work okay with 4096 and Never Stream is the pool size was not longer the limiting factor. Once you reload your map, try rebuilding the scene to see if the memory is still huge.

Let me know if you are still having trouble.

Thank you,

Hi Andrew,

I’m not sure what you mean by rebuild. Do you mean rebuild in the editor ?

All i am describing is occuring during runtime, in PIE or in a packaged game.

When i speak about loading, i mean during runtime, using an FArchive to store/read data in/from a file, and spawn/destroy object in c++ code.

My map never changes and remains empty in editor. I don’t even use the editor preview frame, as you can see on the screenshot below, it is kept to a minimum size and my map contains a player start, a sky sphere, a postprocess volume, and that’s pretty much it.

The level is populated/emptied only during runtime, either by players, or when reloading a save. To do that, i use the UWorld::SpawnActor function to create a default actor (from a class i wrote, containing skeletal/static mesh components), then i dress it with properties i loaded using the FArchive. All the static/skeletal meshes, or even blueprints are loaded dynamically using functions such as StaticLoadObject, etc.

That is why i am not sure about my memory management :smiley:

Maybe it will be more clear with a video, you can see the sort of things players can do here, where i setup a little scene from scratch:

Or do you mean there is a way to rebuild a scene during runtime other than waiting for the next frame ?



Hey uced,

Thank you for clarifying this is all happening at runtime. I was under the impression you were destroying actors while PIE and then ending your PIE session and allowing the meshes to reload. This is why I asked you to ‘Rebuild’ and by that I mean using the ‘Build All’ option within the viewport to rebuild you scenes geometry and lighting.

In regards to the texture streaming, I am actually assigned another issue where a user is reporting a similar problem with his project.

AnswerHub Post - Streaming Texture Bug

If you follow the forum link provided in that post, you can see we are aware of the issue and have begun entered a bug report. If you have any questions in regards to this issue, would you mind posting in the link provided so we can keep these together and organized. It helps us track the issue more efficiently and assist users in an effective manner.

Update For reference the bug entered is UE-21800. It has been verified and fixed as number of fixes were entered into recent versions that address the issues mentioned here.