In line 655 of TextureStreamingBuild.cpp we sometimes get this ensure hit: ensure(LevelStreamingTextures.IsValidIndex(BuildInfo.TextureLevelIndex))
It can cause crashes and I have even seen it hang in development builds when it is calling MiniDumpWriteDump on Windows.
We have ran the Build → Build Texture Streaming functionality on the maps affected but the issue still keeps happening.
We’re running UE 5.3.1.
With r.Streaming.CheckBuildStatus 1 set we still always get “Texture streaming needs to be rebuilt” constantly so I am not sure what satisfies the level streaming.
There’s no legacy materials pre-UE5 either that would upset this.
Anyone have similar and/or can offer advice to what we should do?
Cheers,
Kyle.
Seems to be a race case or a shared pointer issue. Try adding this code to your project to debug this issue.
if (!LevelStreamingTextures.IsValidIndex(BuildInfo.TextureLevelIndex))
{
UE_LOG(LogTemp, Error, TEXT("Invalid TextureLevelIndex: %d, LevelStreamingTextures.Num(): %d"), BuildInfo.TextureLevelIndex, LevelStreamingTextures.Num());
// Additional handling for invalid index
}
If you find it to be a race case or shared pointer issue, you will need to look at your async loading or initialization processes. Further, last thing to check for would be for corrupted assets that are not correctly building.
We’re not doing anything fancy with async loading. We just have a persistent level with sub levels and it’s hitting it on load in.
I added some logs and it does seem like some sort of race / loading flow issue as it looks like the index is correct but for the next context instead of current.
[2024.07.24-13.51.06:722][869]LogTemp: Adding Leaks to LevelStreamingTextures at 26 with Guid 8932B4EE4A99D7971AEC1BBA37EF9051
[2024.07.24-13.51.06:724][869]LogTemp: Adding Leaks to LevelStreamingTextures at 20 with Guid 8932B4EE4A99D7971AEC1BBA37EF9051
[2024.07.24-13.51.06:725][869]LogTemp: Adding Leaks to LevelStreamingTextures at 13 with Guid 8932B4EE4A99D7971AEC1BBA37EF9051
[2024.07.24-13.51.06:726][869]LogTemp: Error: ProcessMaterial MI_Temple_SandStone_01_Beige, Invalid TextureLevelIndex: 36, LevelStreamingTextures.Num(): 15
[2024.07.24-13.51.06:727][869]LogTemp: Adding Leaks to LevelStreamingTextures at 36 with Guid 8932B4EE4A99D7971AEC1BBA37EF9051
[2024.07.24-13.51.06:751][869]LogTemp: Adding Leaks to LevelStreamingTextures at 54 with Guid 8932B4EE4A99D7971AEC1BBA37EF9051
[2024.07.24-13.51.06:751][869]LogTemp: Adding Leaks to LevelStreamingTextures at 7 with Guid 8932B4EE4A99D7971AEC1BBA37EF9051
[2024.07.24-13.51.06:755][869]LogTemp: Adding Leaks to LevelStreamingTextures at 7 with Guid 8932B4EE4A99D7971AEC1BBA37EF9051
I matched other texture indices to the next context array and they all match the lookup of textures I’d expect it wants based on the material.
This happens consistently and for the same materials and textures, which makes me think it’s more of a loading flow rather than a race issue.
As it isn’t causing any visible render issues, and changing it from an ensure to an if stops the hang in Development when Windows tries to write the mini dump, it isn’t a high priority for me to investigate too much further. Hopefully I can get some spare time though to look into it further as it would be nice to suppress it.
If WorldPartition or LevelInstances affect the texture streaming different to sub levels then that might be worth exploring. Just WorldPartition wasn’t really necessary for us when we first looked at it.
As a side note I upgraded to 5.4.3 and it is still being hit.
