Hello, I’m encountering a new problem that I can’t seem to understand. When creating large landscapes, the performance takes a hit. I get a smooth 120fps with a 4k landscape, but with 8k landscapes, the performance drops to under 50fps. What feels strange to me is that the bottleneck appears to be on the CPU side rather than the GPU.
The frames seem to be waiting on thousands of ‘tick: grass’ operations, even though I have no material, grass, or any other elements on it. Aggressive LOD, usage of HLOD, and even Nanite do not change the result. Any idea what or why this is happening?
What system specs are you currently running? Larger landscapes can cause performance problems depending on your system. Also, the thing with the grass - is this a specific level you’re having the problem on or if you open a completely new project and do it there is it the same?
Hello, this issue is happening even on a brand new level with just an 8K landscape and an 8K Heightmap—nothing else. I doubt my system is at fault here (RTX 3080, Ryzen 7 5800X3D, 64GB RAM). What could be causing my CPU to struggle with calculations on a simple, unlit, fixed landscape mesh, especially when there’s nothing else on it, not even a material.
Does someone know what this “TickGrass” operation is and why it’s repeated so many time?
I have the same problem, looks like engine is updating grass on all LandscapeStreamingProxies and I had a lot of them ~1000.
I was able to mitigate it somewhat by creating new ladscape with bigger “World Partition Grid Size”
this generated landscape with far fewer LandscapeStreamingProxies however it still is very slow on my PC, would be nice to disable it as the problem exists only in editor view.
I was not only appearing in the editor for me but also in runtime, but I found at least why it was still a problem with no landscape loaded, HLOD keep doing it, each frame, so large landscape even if only existing in HLOD absolutely kill performance, you can keep them all fully loaded with the same performance (If CPU limited).
I’ve dug a bit and I still can’t understand. With world partition active and landscape not spatially loaded, with one or even none of the landscape proxy loaded and rendering on screen, UE keep doing the landscapeProxy::tick for every (16) landscape proxy in the level, and it’s unreasonably long (5ms). Is they a way to (even manually) block those unwanted action from the CPU? I feel like I’m missing something basic. Or I’m looking at the wrong element and the bottleneck is something totally different?
(Ps: making less but larger proxy change nothing as each tick takes more time)
Okay, I will continue to post my research on the question, it could serve someone.
I’ve found a way to get the performance back but It make no sense to me why. If I remove visibility of the the landscape in the editor, then when simulating (and not toggle visibility during the simulation) I have normal 100-120fps performance.
editor:
simulation:
If I toggle the visibility in the editor I get the same performance as if all the landscape proxy were loaded and I was not using world partition (50fps). But the only visible part of the landscape still only the one loaded by world partition.
editor:
simulation:
So same visible result, but double the frame rate for hiding the landscape in the editor-
Seems like the problem is ALandscapeProxy::ShouldTickGrass.
/* Per-frame call to update dynamic grass placement and render grassmaps */
FORCEINLINE bool ShouldTickGrass() const
{
// At runtime if we don't have grass we will never have any so avoid ticking it
// In editor we might have a material that didn't have grass and now does so we can't rely on bHasLandscapeGrass.
if (!GIsEditor && !bHasLandscapeGrass)
{
return false;
}
...
According to the function implementation, even if there aren’t any landscape components with grass configured, the grass will be ticked/updated as long as the program is run in the editor.
Haven’t found a way to bypass this yet. Wasn’t able to find any CVARs to access this outside of a c++ project but I believe this still happens in development builds. Haven’t tried in shipping ones yet
