Hello, I have a really big, detailed static mesh that can be walked on by the player. But it’s running slow. Now I’m wondering, are there ways to make it more performant, e.g. by having LODs within this one big mesh? To my understanding, UE4 must be using such a LOD technique for landscape meshes, right?
Alternatively I think I could slice the mesh into several pieces and use ‘normal’ LODs, but if there are better/simpler solutions, I’d be very interested to hear them.
Thank you.
Landscapes use something a lot like tesselation. So setting up a tesselation material might work.
On the other hand, trees utilize billboards when they are far away. Usually consisting of 4 or more LOD based on their size.
Games also load different models when the player travels through a tunnel or other kind of view obstructor. Smoke and mirrors in other words.
It’s a little tough without knowing more about your mesh needs though.
Thanks for your answer!
Tesselation would subdivide the mesh more, not simplify it, wouldn’t it? Also I think tesselation is GPU based, so the (CPU) collision might not be accurate anymore.
Let’s say a small detailed planet or a really big tree, that the player can navigate on. The important bit is that it is not a flat plane with a height map, so I can’t use a landscape mesh.
You would be better off implementing a quadtree algorithm in cpp.
a decent read on what it is:
https://www.gamasutra.com/view/feature/131841/continuous_lod_terrain_meshing_.php
And to answer your question about what unreal uses, the answer is s h i t - At the moment anyway (I’m sure the team knows this and is actively re-working the landscape yet again).
They implement a badtardized version of the article information thats closer to what would have been decent in 2000 rather than a version that could support anything (think Google earth like). To top it off, they locked in tessellation on it, which you have to build a custom shader/engine to disable.
Anyway, shortcomings of the engine aside, if you just implement a quadtree system (and by the way, the new .26 water stuff uses it, so maybe you can just pull their code and use it) you’ll likely be a million times better off.
Obviously the size of the heightmaps are still a concern. You need to figure out what size performs best.
the file size is still directly linked to 1px per meter anyway. Mostly because finding more detailed data is impossible.
Actually, I suppose if you wanted to quadruple the size of the heightmaps you could do 4 vertex to 4 pixel for finer detail.
the obvious drawback here is the project’s file size, not necessarily its performance (since with quadtree you only load what you need).
With a 10km^2 area you’d be dealing with a total pixel size of 40,000^2 - obviously cut into tiles of a power of 2 value.
Still, at png16 thats a lot of data.
The other downside is that the landscape sculpt tools won’t work on this at all.
Unless you make your own system that is.
In a past life, I led a team that built an octree mesh LOD system that ended up tesselating all of Earth from “satellite height” down to “walking on the surface.”
Building the strips that match up different LOD levels at the edges of the cuts was a big challenge, especially because we modeled in double precision but rendered in single precision with local camera offset (really, the only way you can do it.) The main challenge here is to avoid “sparkles” where the pieces fit together.
If your mesh is less than a kilometer in size, you can just model it all in single precision, it’ll be fine. Cut it into may pieces, and export them as an “array” of meshes. It may be that this is all you need to do, because collision detection will then only collide against some of the closer chunks, rather than the full chunk. However, if that’s not enough, you can then also manually model multiple LODs, making sure they have vertices that match up at the edges (so this makes it harder to get really strong reduction, because the edges need to be tesselated to the highest level.) This will work without changing the Unreal Engine at all.
Once thing we ended up building to solve that was “strips” that bound two LODs together, and filled in the gaps and hooks them up. We tried to call these “hookers” but as it was for a military contract, that ended up getting dropped from the documentation 
If you want to write your own C++, maybe that’s a way to go? It was a fair amount of work to get it all to work out, but that’s partially because we had 20+ LOD levels, we had to make materials match up, we had to stream the different levels from spinny disks, and the graphics card of the time was something like a Geforce 4 …