I have already optimized the textures and meshes, and now the heaviest and the most VRAM-consuming part of my game content is landscape. Is it possible to optimize it in some way?
Have you tried converting the landscape to nanite?
In the optimized version of my game there is no Nanite.
ah - interesting
Does nobody want to write something except flood?
You’ve only really got two options for reducing landscape triangle count: change the Landscape LOD bias to force it to a lower LOD, or resampling it to a lower resolution (The resample option isn’t available in World Partition levels, so if you’re using WP, you can only change the LOD bias)
You can scale up the landscape by x2, and then reduce the size of the components (or number of components) to match. You’ll need to re-paint/re-import the landscape to match, though – it’s not an automatic change.
But – does the landscape triangle count really matter? It’s a few thousand triangles per component. Typically, on landscapes, it’s always the material/shader cost that matters.
Before you deliberately make things looks worse, have you proved that this is a real bottleneck on your target hardware?
Really? In the Primitive Stats one shows 333 million triangles in two landscapes 8x12 and 8x8 km. Or this information is false?
Also, where the landscape info is stored? I want to make two editions of my game differ by landscape complexity. And I have written a .bat script that enables one of the editions by making the symbolic links to one of each pair of the textures and meshes folders. Is it possible to make the same with landscape?
A Landscape is made up of tons of pieces (Landscape Components) which are subject to frustum and occlusion culling. So while your overall landscape might have millions of triangles, the individual components have significantly less, depending on your component size, and thus the number of triangles being rendered is also significantly less.
The landscape renders with LOD. It also generates the triangles dynamically – they are not stored in your computers memory, but instead generated on demand.
So, the question remains: Do you have a measured performance problem in release mode builds on your target hardware?
And when you go to 8x20 km size levels, you really want to use world partition. You might also want to look into using substitute stand-ins for very-far-away landscape components.
But, if all of that isn’t enough, yes, you can create your landscape with a larger scale to get lower triangle counts for a given area covered.
Probably the Primitive Stats window does not measure VRAM in release mode builds.
I do use it.
I have just unloaded some landscape sections in the WorldPartitionEditor and seen significant drop in the numbers in Primitive Stats. So, in the release mode something other consumes the VRAM. This topic is not actual.
Take your pic out of the variety of botched epic things that you have enabled.
Nanite? Lumen? Etc.
I would suggest like always to finish your landscape editing, export everything, and turn it into meshes.
Landscape is 100% part of the problem for performance. Eliminating it will usually ned a 20% frame imcrease, even if it is a lot of work.
Moreover, since you are concerned with tris count - your meshes can be analytical. The landscape cannot. The tris distribution is 1 to a meter using the default x/y=100 scale.
On deseet areas and flat surfaces nearly all the tris are completely wasted…
Try Hourini for world generation. It seems to have tools that actually help.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.