Hello!
Some of our developers are experiencing an issue inconsistently when interacting with Landscapes. We’ve investigated some to find some key facts, but are unable to identify a root cause. We are primarily hoping for guidance where to look next at this stage.
When some of our developers attempt to edit a Landscape, they are blocked by this loading spinner: “Waiting for textures resources to be ready for landscape named: Landscape.”
However, this spinner never resolves. After some debugging, we have identified that the resource in question is one of the Weightmaps or the Heightmaps of the landscape, though it differs between users as to which one or ones have the issue. Specifically, the textures themselves load, but not all of their mips do, seeming to always be waiting on the 2-3 highest detailed mip levels. The textures reflect this by having their NumResidentLODs and NumRequestedLODs at 7, but their maximum expected LOD count is 10.
Furthermore, these mips fail to fetch from the DDC in FTexture2DStreamIn_DDC::DoCreateAsyncDDCRequests, and are queued for rebuild at line 138:
else if (Response.Status == EStatus::Error) { FTextureCompilingManager::Get().ForceDeferredTextureRebuildAnyThread({Texture}); }The rebuild request appears to succeed later in FTextureCompilingManager::ProcessDeferredRequests, and FTexturePlatformData::Cache is called, and appears to succeed throughout. Nonetheless, the load request fails in the same way again when it is re-attempted the next frame. This continues forever, and you can see in DDC statistics that we slowly accrue misses every tick.
We have found one workaround of sorts, which is if we Export the affected height or weightmap from the Landscape Editor, it fixes the issue for some users. Note you do NOT need to re-import here, just the export is sufficient. However, since the affected textures appear to differ for each user, this doesn’t really help, and also doesn’t address the root cause.
We have attempted to rebuild the landscape, to export and re-import the height/weightmaps, and to run PrimeDDC, as it seems to be some issue with cached data. This has inconsistently resolved issues for individuals, but nothing which resolved it for everyone.
Our best guess is either that these mips are failing to generate locally in some environment-dependent way, or that there is some keying error with the DDC which provides a false-negative to return the mips. However, since we are a distributed team, we actually use a few DDC configurations, and this issue appears across multiple, so it is unlikely to be directly related to cached data.
While a suggestion towards a fix would be ideal, at this point we’re also interested in any temporary workarounds or ways to suppress this behavior so that our developers can get back to work while we investigate more deeply.
Thanks!