LandscapeStreamingProxy Won't Rebuild / Disappears when Lit
UPDATE: Info on crash at end
We have a large island world that is split into a set of streaming sub-levels all constructed using the landscape tools.
This weekend, one of the LandscapeStreamingProxy actors has started behaving strangely. When lit and rendered normally, there is no visible representation of the terrain. I can still interact with it and walk across it but visually it is absent.
There are a few peculiarities:
I've found several similar issues reported in the past, and this one offers a solution:
The solution is to re-make the landscape by selecting the Landscape Manager, switching to the component resize tool and, without changing any settings, clicking re-apply (which I believe, essentially rebuilds the landscape). I have tried this and it is crashing unreal. If I try and rebuild with the persistent level open, it uses a monumental amount of memory (hundreds of GBs), takes forever, and crashes. If I try and rebuild within ANY sub-map (including the broken one) it goes much faster but still crashes as it is trying to write something to disk.
I am looking for any additional help I can get! At this point, any alternative solution to the original problem would be appreciated but also insight into why rebuilding the landscape might be taking so long in the persistent level / crashing in the end would also be welcome.
Presently this was all attempted with UE 4.20.3 on MacOS 10.14.4. I will also be attempting the rebuild on Windows soon with the debug library loaded to try and figure out more about why its crashing.
Re-ran the rebuilding of the landscape on the broken sub-level on a computer that has debug libraries installed (also a windows computer) and got a more useful stack trace when the crash occurred. Here's the gist of what I'm seeing:
The specific assertion is:
So my assessment is that it wants to 'lock' some data (presumably a mipmap level in the Landscape data) and it fails to lock (the lock status remains 'Unlocked' when it shouldn't). I'm not really sure what the sense is of 'lock' here, could be just some sort of write protection or finalization of the data, or maybe it has to do with SVN (which we are using) but either way, something is failing to lock and it is immediately crashing as a result.
ACTUALLY, after looking at the source code for this assertion, it happens right at the top of the Lock() function and is checking that the status of the data is 'unlocked' before it tries to lock it. Apparently, it is not 'unlocked' for some reason (maybe already locked, maybe some kind of error state).
Here's a screen grab of the Unreal Crash Reporter showing the stack trace in detail:
Follow this question
Once you sign in you will be able to subscribe for any updates here