Landscape performs well regardless of how many components it has. But as soon as Grass Tool node is used inside the material editor, the performance exponentially decreases based on how many components the landscape has.
Here’s a test I’m posting below to demonstrate the problem.
The Grass Type linked to the Grass Tool node is the same for both tests. Please note that both landscapes are almost at the same scale so the number of meshes distributed on both is also almost the same.
Landscape with 1 component, With Grass Tool node used inside material, performance is okay. (Overall Resolution 64x64).
Grass Tool is a feature for open world games, and in open world games a landscape usually has way more than 1-100 components so any attempts to go with the minimum number of components is a no go.
You can try to reproduce the issue simply as I showed above, if there is any more information needed I’d be happy to provide. I think this issue deserves to be fixed as soon as possible as almost everyone is affected by it.
Looking forward to hear something from Epic on this.
Thank you.
I believe you might have a simple misunderstanding of how the landscape system works, and why we give users the ability to choose the number of components and quads. I did a stream on landscapes which I believe you will benefit from, but the bottom line here (especially in your case) is that you can get the same overall resolution with a lower number of components and have better performance, than if you were to use more components.
The tradeoff for having less components are the that the LOD transitions between components might not be as smooth which can be undesirable if you are viewing the landscape from really far distances. Each landscape component is a draw call, and in your example you are comparing 18 components in total, compared to a single landscape component so it is expected there is going to be a difference in performance. You can mitigate this by doing things like optimizing the LOD distances, the cull distances of your foliage, and changing your lights mobility type.
I think you missed my point. I was talking about the Grass node behavior, not the landscape. I’m NOT experiencing any performance drop coming from the landscape. I’m putting together another test for you below.
So I just ran a test on my end using minimal content to guarantee it has to do with the correlation between landscape grass output and the number of components in the landscape. My results do not exhibit the behavior you are reporting, which leads me to believe it could be something else. The difference between our projects are the meshes you are using and perhaps slightly different densities.
As you can see my landscape sizes and overall resolutions are identical to your test cases. Perhaps I am overlooking a step or you have left out a detail or project setting? My mesh is much simpler than yours and comes from the engine content with the world grid material applied.
Let me know if you have further details or I am perhaps missing something.
I looked through the GPU Profiler and found something very weird.
On the landscape with 1 component, the ShadowDepths costs 1.42 ms and on the landscape with 100 components ShadowDepths costs 10.84 ms. That is while it’s the same grass type and same amount of meshes in both tests. So if the problem was specific to the meshes then ShadowDepths shouldn’t cost different on landscapes with different number of components. Please check these out:
It seems like each single landscape component has it’s own cost for receiving any shadows and 100 components in our case here, adds up to 10.84 ms. I can supply you the project if you need it, please let me know.
This goes back to my original post regarding this issue. More components are going to generally be more expensive due to each landscape component counting as a draw call. This also means each component will be receiving a per object shadow which can get quite expensive very quickly if you begin to use dynamic shadows.
If you would like you can share with me your project, but I have a feeling that what you are reporting is an expected cost with the amount of components being used. Either way, you can zip up your project and upload it to a shareable drive link and share with me in your response. I highly recommend you watch the stream I did as well as read the documentation to get an understanding of how and why landscapes have certain sizes that work better than others.
Hi, I have a project with a lot of vegetation but since the 4.15 even with very low vegetation I can’t get good performance, and bigger the landscape is (with more components), lower the performances are(while the quantity of vegetation does not increase) … I have re-tested with a new project, same problem. I think it’s a bug But I do not know where, I’m currently trying to make a comparison with the vegetation tools.
So again the problem only occurs when using Grass Node.
If this was an expected cost then it shouldn’t cost 6.86 ms less when using foliage painter. I can’t post these ferns in public, but I’ll use other meshes to create a demonstration project and put the link here for you shortly.
For this test I’ve created 2 blank maps, both have the same landscape settings (100 components each), and I’ve used the cone mesh from engine content. In one of the maps the cone is painted using foliage painter, in the other map is distributed using grass node. The problem is again obvious.
This may or may not be related but a couple of months back I’ve experienced severe performance drop with the grass node but only if my landscape was scaled down from the original scaling.
I’ve lately spent quite some time with debugging shadow performance, and I think what you see is more or less expected, but should still be fixed.
The thing is that, like mentioned, every component has its own draw call. This not just means that during the base pass there are 100 draw calls for the landscape, but during the shadow depth rendering there are 100 draw calls again.
If you now add grass foliage, then you will have 100 draw calls during base pass for the foliage, and also 100 draw calls for shadow depths (if you only use a single material on the grass and a single shadow cascade).
Now the real issue you see is that shadow depth rendering can just be really slow for some reason. It does not scale well with draw calls, for some reason there’s a pretty constant cost to shadow map draw calls, so 100 draw calls with a lot of vertices (foliage has many vertices) will be slow.
Manually painted foliage is a lot faster, because there you will only have a single draw call for every material that’s used on the foliage, compared to the 100 draw calls you have with the landscape grass system.
For fixing this, either shadow depth performance has to be improved (that would be that best solution, since everything would benefit from this) or the landscape grass system would need to render all the grass as a single draw call. Making it a single draw call would make adding and removing grass instances a lot more expensive I think, that’s why they probably kept it split up over all the components.
So the issue that needs to be fixed is shadow depth performance. Why are 100 shadow depth draw calls with 1000 vertices each a lot slower than a single shadow depth draw call with 100000 vertices?
