Hello world again! Sorry for the long silence, it is caused with the personal problems. I have just upgraded my editor to version 5.2 and migrated the world into World Partition, but adding the water still causes a crash of the editor:
I have partially figured out this problem. There are no necessary plugins except Water and Landmass, and this is not a pure bug, but the water has now very poor optimization. The full world 12x12 km with 3 rivers, lake and some mountains crashes the editor, whereas on near the half of this - 6x12 km with the same water and only small hills (and the right half with the mountains is cropped) the peak video memory is “on the blade of a knife” - 23.4-23.5 out of 24. In that way, how much video memory is necessary to display 120x90 km with ocean, many rivers, lakes, islands, mountains and big buildings? And why adding the water bodies forces all the world to display and disables unloading the parts of the world? Is this a bug?
I had a similar (possibly same) issue.
In my case, it was the Landscape_WaterBrush. I don’t think it’s so much the water actors themselves as the dynamic landscape editing they can do (managed by the WaterBrush and associated EditLayer).
It breaks some WorldPartition functionality (load/unload).
I did sort out a bit of a work-around, though the water actors will lose the ability to edit the landscape:
Bump. I have temporarily cut half of the landscape, which currently, despite the city, does not have any gameplay activity, and the engine now does not crash but the water still does not work properly. Whereas the lake works almost properly, only the small part of the rivers has the water, and all the other space is filled with void (with only sand on the bottom). Here is the screenshot. What can be the problem?
Double bump.
Hey there @Etyuhibosecyu! Welcome back to the community! Unfortunately the landscape + water systems are quite heavy during initial operations and will often have two types of issues. One of them being at sufficient scales will use high amounts of VRAM use due to the water system having to access the entire landscape at once and cause the error you received before. This can be mitigated by working with smaller landscapes altogether, and by lowering rendering overhead as much as possible before placing in the water systems. This may be qualified as a bug, but it’s more a limitation to how the base landscape and water system interact, which I believe stems from the landscape brushes needing access to the whole landscape in memory at once.
The second issue stems from landscapes being too large (or mispositioned), often in the Z axis causing issues with how the landscape brush interacts, so often you end up with some water bodies not affecting the landscape properly while others seem mostly fine. Rivers suffer the worst in this case.
Hello @SupportiveEntity! So, is there a solution? How to place the rivers correctly, without the issues in the Z axis? Will those issues be fixed in the future versions? And is it true that the debugger with the big landscape and the water can work only on supercomputer?
Aside from the workaround mentioned, I haven’t found others to mitigate the issue. The landscape system does have some changes in the pipeline however I don’t have any knowledge outside of the roadmap information we have on hand if the landscape system/water system will be getting changes to these limitations.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
