I’m having an issue where any map I build within a specific project will drop its textures down to what appears to be the lowest possible mipmap quality. Since it’s affecting unrelated maps, it’s clearly something to do with our configs, yet I’ve not changed anything regarding quality levels or forced effects as far as I can tell.
Importantly, my team is many builds into the project so this is something that’s just now started affecting every project. Strangely, our config files aren’t on our repo, so if one of us accidentally flipped a setting, it should have been confined to their computer.
Affecting all maps in a project suggests something with the configs, while the lack of synchronized configs sort of prevents that? It’s not a per-texture problem because it’s crushing a lot of different textures. It’s not visible in editor with a preview renderer set up for Android.
Any idea where I can look to track this down, or simply a quick list of all the places where I can triple check the quality settings to ensure they’re not forcing it?
On my latest builds, I’m getting a red error warning saying, “Texture streaming pool over 22.12 MiB budget”. I can recreate the same warning and downsampling effect by setting:
r.Streaming.PoolSize=1
If I query the value, it’s set to the standard 1000mb with no apparent influence from my config files. I manually entered pool sizes for all quality levels in my DefaultScalability.ini file, and a default value in my DefaultEngine.ini.
Is there anywhere else that the texture streaming pool might be overridden and set to zero? My map is extremely lightweight, and the 22mb estimate is almost certainly the entire texture budget right now. The build is mysteriously almost a GB larger than previous builds.
Have you ever read the page on Texture Settings? It contains information on the ini files that determine the LODs for a game and on platforms, and how to do specific changes. It sounds as though you could acquire what you need in the Compressed…, Engine Config…, and Texture Group… sections in particular. I bet there’s an issue with having only 22 MiB texture pool size because the textures you’re using on assets are not the only ones. There’s also the texture for the skysphere, atmospheric fog / other fogs, any volumetric effects, and in the textures you’ve composed or imported yourself it may be the case their settings are generating a higher memory usage than you know. For example, DXT5 compression needs twice that of DXT1 in memory, for which there’s a chart in the page I linked based on resolution. Then there’s the aspect of how the materials settings are set, in which it is essential to select certain mip settings for certain materials and textures used in those. So, it’s possible the ini files were modified somehow to suddenly reduce quality across computers for the project, or it could be the settings for textures and materials and perhaps even lights too…are not correct for the texture memory pool and thus is defaulting to low quality mips.
Circling back to this issue because it’s still limiting some builds.
The map itself has been built before without issue, and the textures in use shouldn’t be anywhere near default limits (~1000) even accounting for things like the skybox, light bakes, and fog. The value displayed in the headset build is the same as when I manually set the editor to have a limit of 1, so it’s essentially the entire size of my streaming pool rather than overflow beyond a reasonable value. What’s in the screenshot is nearly the entire level.
I tried swapping older configs from a backup made before the issue appeared, but nothing changed so I can rule them out. I deleted out the binaries, intermediate, source, and DDC project folders to allow for any generated files to be flushed and reloaded, but again nothing changed. The manual values in DefaultEngine and DefaultScalability were recognized in the editor but were ignored in the build.
We were able to find a way to bypass the issue entirely by disabling Texture Streaming under the Engine/Rendering section of the project settings. This isn’t a great solution long term though as it simply abandons the feature along with its benefits.
