Hello everyone !
I’m a programmer in a little video game studio, we are developping a FPS game and we just changed our UE version from 4.17 to 4.19 this week. We didn’t have a lot of trouble to do that, but with the 4.19 version, the texture streaming system doesn’t work as expected.
We make our texture with a dimension of 4096 x 4096 and with 4.17, the texture was fully loaded in memory only when the player was close of the object mapped with the texture and the mipmap level was changed when the player went farther. So the texture was not fully loaded if the player was far away. In result our streaming pool was fine and the game looked nice.
Since we are working with the 4.19 version of UE, the texture streaming doesn’t work as expected. All of our textures are fully loaded even if the player is far away from every object mapped with it. Even if we change manually the mipmap level, the memory loaded is not affected (i.e if we set manually the mipmap level at 1 of a texture where the maximum dimension is 4096 x 4096 with a memory size of ~11 MB, the current dimension stay at 4096 x 4096 and the current loaded memory is ~11MB, but the current dimension should be 2048 x 2048 and the current memory loaded should be ~6MB). The result is a texture streaming pool over error in machines with less VRAM than 6GB.
To reproduce this bug :
- Create a new FPS project
- Create a 4k texture with the properties given below
- Open the statistics window and select “Texture stats” tab
- Compile the level and run the game with the statistics window opened
- Go close of the object and refresh the statistics window
- Go far away of the object and refresh the stastistics window
Expected result : The texture current dimension and current memory should decrease when the distance between player and the cube increase.
Obtained result : The texture dimension and current memory do not change.
You will see that the texture is always fully loaded and its current dimension is always the same than its maximal dimension.
Here you can see the texture properties :
And here you can see the result in the statistics window :
- When the player is close
- When the player is far away
- When teh mipmap level is set to 1
We would like to know if we are missing something or doing something wrong. If so, is there a way to apply texture streaming correctly and change the current dimension and memory of a texture depending of the distance between player and the objects mapped with this texture ? Increasing streaming pool size seems not to be an acceptable solution.
Thank you in advance for your answer.
G.
Hello,
We’ve misunderestood the Texture Streaming workflow. What we reported is not a bug but the correct behaviour of the feature. In fact if you have enough VRAM to load all textures in the map at their maximal definition, they will be loaded at their maximal definition.
The problem we had was that the engine did not refresh the texture streaming data correctly because of an intern black magic and the result was that the used mips level were not consistent with the distance between meshes and the player point of view.
To solve this problem, we modified one of our oldest texture, rebuild the Texture Streaming data, revert the modification and build again. This should have forced the update of the Texture Streaming data.
We hope that solution will help someone else and we apologize for the wrong bug report.
G.
@xSPxFunnyGamer: I am having the exact same problem! Can you be a bit more specific about how you solved it, I don’t quite get it. ( what is your ‘oldest’ texture? )
What I don’t understand is why the streamer, apparently ‘working correctly’, then gives over streaming budget messages…
I also saw this on the doc pages:
Because any materials edited before 4.15 did not have any texture streaming data stored with the material, it won’t have any data until they are modified and resaved. This includes resaving the child instances of a material as well. To migrate the data quickly, you can use the console command BuildMaterialTextureStreamingData.
Be interested to hear… 
Hello,
I think it will be quite fun to read, but we just took one of our textures that we have integrated before we’ve updated UE…
We have enabled the option “Never stream”. We’ve compiled the texture, disabled the option “Never stream” and recompiled. After that (and we really don’t know why) the texture streamer did its job quite well again.
It might have forced a refresh of the data or another internal black magic of Unreal Engine, but we are not sure.
Concerning the error messages like “streaming pool over”, we’ve seen that it appears mainly in editor or in debug build. We have no problems in a distribution build. That’s why we think that the streamer is less efficient in editor than in a packaged game.
As you can see, we “solved” our problem with a trick that we have now added to our debugging process : Set and revert an option. We’re sorry that we cannot tell much more, but we solved some bugs with thoose kind of tricks.
And everythink were working fine with UE 4.17, so I don’t think that what you’ve seen in the documentation was the cause of our problem. But it may can be a good start for yours ?
G.
Hi G
Thanks for you answer. I’m away from the machine at the moment, but will get back if I find anything interesting to tell…
So many people are happy with the ‘streaming pool size option’, which only makes hides the error…
