I can confirm I am having this issue as well in our 5.5.1. We have been thoroughly testing and even completely flushing the project of everything and rebuilding DDC, Intermediates and such does not correct this issue.
Right Clicking and saving the file does correct the Issue:
We have all symptoms of editor locking up and these logs:
LogTexture: Display: Building textures: /Game/TwlightStar/Maps/LevelDesignStylized/Foliage/SmallPlants/Textures/Plants2_diff.Plants2_diff (TFO_AutoDXT, 2048x2048 x1x1x1) (Required Memory Estimate: 288.999984 MB), EncodeSpeed: Final
LogTexture: Display: Building textures: /Game/TwlightStar/Maps/LevelDesignStylized/Foliage/SmallPlants/Textures/Plants2_Fern_gloss.Plants2_Fern_gloss (TFO_AutoDXT, 2048x2048 x1x1x1) (Required Memory Estimate: 288.999984 MB), EncodeSpeed: Final
LogTexture: Display: Building textures: /Game/TwlightStar/Maps/LevelDesignStylized/Foliage/SmallPlants/Textures/Plants2_Fern_normal.Plants2_Fern_normal (TFO_BC5, 2048x2048 x1x1x1) (Required Memory Estimate: 382.499988 MB), EncodeSpeed: Final
LogTexture: Display: Building textures: /Game/TwlightStar/Maps/LevelDesignStylized/Foliage/SmallPlants/Textures/plants2_Fern_diff.plants2_Fern_diff (TFO_AutoDXT, 2048x2048 x1x1x1) (Required Memory Estimate: 288.999984 MB), EncodeSpeed: Final
These appear after all the unlocks and point to all the meshes that do not load as well.
As well, Engine Scalability was set to High. However just for fun I set it to Epic and everything turned white and the emissive blew way out of proportion. That bright blue rock, should only have a crest glowing on it. the rest of the rocks texture in the material just doesnt exist it seems.
Awesome. Well fwiw, I did just do a few things additional, not sure if they are relevant, but while waiting about 5-10 minutes after switching to Epic and going back to High settings, those white objects all eventually just popped in with the material, except for the boats. Everything else is now normal. I never tried that before because I usually just run in High settings.
We just turned Oodle off this morning from your recommendation and I have not encountered the issue all day. Seems something is wrong with oodle controlling the textures.
Same problem here. After some time the editor starts to load or to “stuck” and then random 3d objects become black. After double click on all textures from the 3d objects they appear normal again. Using 5.5.1
After some experiments and consulting with tech artists, I figured out a few correlations.
First, when Texture Streaming is turned off, the bug doesn’t happen. But Texture Streaming is necessary to save video memory.
The appearance of the bug is related to mip maps. More precisely, it seems to be related to loading the original texture size.
If you disable mip maps, the bug does not appear, but textures without mip maps require almost twice as much memory.
There is a way to temporarily avoid the bug. This is the command “r.Streaming.FullyLoadUsedTextures 1”. If the textures have not been blackened yet, this command will help to pre-load all mip levels, including the original texture size, as I understand. At least it seems to work that way. This helps to avoid the bug completely. But after all textures are already loaded, the video memory gradually starts to fill up. I don’t know why this happens, but after the textures are loaded, if you change the value from 1 to 0 (r.Streaming.FullyLoadUsedTextures 0), the video memory will stop overflowing and return to an acceptable level. But the textures will still remain loaded.
There is a reason to believe that this bug is related to the configuration of a PC, be it hardware or operating system.
Just in case, my PC configuration is: Windows 10 Pro 22H2, RTX 3060 8GB with LHR, AMD Ryzen 7 2700X Eight-Core Processor 3.70 GHz, 32 GB RAM.
Same problem here on UE 5.5.3 on few textures.
I compared one of the black textures to the source inside perforce depot:
The only difference is this line:
Texture in Depot:
Source=(Id=5F185E5AC3C6E463DCC23C5CA751FAD4,SizeX=1024,SizeY=1024,NumSlices=1,NumMips=1,CompressionFormat=TSCF_PNG,bGuidIsHash=True,LayerColorInfo_LockProtected=((ColorMin=(R=0.000000,G=0.000000,B=0.341176,A=1.000000),ColorMax=(R=1.000000,G=1.000000,B=1.000000,A=1.000000))),Format=TSF_BGRA8,LayerFormat=(TSF_BGRA8),BlockDataOffsets=(0))
Ok glad to hear I am not the only one and Epic are on it. I will try disabling oogle as we have a massive project and I’m about to convert from 5.4 to 5.5 and the last thing we need is this when there is so much other migration and integration work to do."
Same problem here and looking daily here for a solution. I tried everything what was mentioning and nothing works.
Disabling Oodle Network and Oodle Textures will only start to recompress back some of the textures and the problem will “look” like is fixed since rebuilding the shaders is like going all over in the checking the materials/textures from that scene.
The problem will appear again later.
The only temporary solution is to resave all textures that appears as black for the engine to check them again, but problem will appear again later.
