Hi Yegor,
The crash occurs because in the editor, landscape edit layers are active and they will merge when requested. In UE5.5, the merge process requires a bunch of temporary render targets that are sized to the size of the landscape that is currently loaded (“global merge”). If you have a resolution of 16k x 16k, that’s likely because the loaded landscape proxies cover an area of 16k x 16k. Please check the loaded proxies while executing the commandlet and verify what resolution is needed. It is generally advised to aim for a maximum area of 4k x 4k (you can check the computed resolution in ALandscape::CreateLayersRenderingResource when the merge algorithm runs).
In UE5.6, a new merge algorithm has been officially introduced : batched merge (you can also activate it in UE5.5 with the CVar landscape.EditLayersLocalMerge.Enable 2, but it only became the default in UE5.6 so it’s possible you will encounter some bugs unless you switch to UE5.6 or, even better, UE5.7, where the old code path has been removed entirely). Batched merge tries to circumvent these OOM issues by splitting the renderable area of the merge into smaller batches, and merging the landscape batch by batch. This way, you can load a much larger region of landscape and not go OOM while using edit layers.
That being said, there are some factors that can influence the landscape proxies that need to be loaded. On a standard landscape, only the loaded region’s size will matter, which means that using iterative cell mode, only the landscape proxies intersected by the cell should be loaded. However, if you are using BP brushes (such as the Water Brush) on one of the edit layers, we then force-load all proxies of the landscape, meaning that even if your cell intersects only a couple of proxies, all proxies will still end up being loaded (but in the editor only). That is because we don’t have control over what BP brushes are doing so we don’t know what region of landscape they require in order to be applied in a deterministic way. The water brush, for example, requires to be applied on the entire landscape because of the way it is computed internally. As a result, whenever a BP brush is used, we force-load all proxies, meaning that if the overall landscape is very large, then no matter the region size you’re trying to load, it will end up updating the entire landscape and is likely to go OOM. Are you guys using BP brushes?
Please note that this remains true even with batched merge. We’re slowly moving away from BP brushes for this reason (although they will remain usable, but with the same loading constraints) and the water brush will be converted to a dedicated water edit layer to circumvent that problem.
If you want to disable the edit layer merge altogether, there’s also a hidden boolean you can set on the main ALandscape actor : bEnableEditorLayersTick. It will bypass the merge entirely. It comes with no strings attached, though : it’s not exposed to BP or even C++ because of it. It’s not well-tested, so it’s possible it will create bugs later down the line. But if nothing in your commandlet requires the edit layers algorithm to run (this could happen if ForceLayersFullUpdate was called, for example), then it might be a way to avoid going OOM by bypassing the landscape edit layer system altogether (please note that if the landscape proxies are not up-to-date, then you might end up with PCG instances being spawned at the wrong location, for example).
Can you have a look at these and let us know if you have more questions? If so, please provide the full log.
Cheers,
Jonathan
[Attachment Removed]