They are. You just make your own system.
If you want performance that’s really the only way.
In terms of LODs, there is no need for them to be generated at runtime, or by the engine. A 75%, 50% 25% vert reduction per LOD works fine 90% of the time. In some cases you just add a 90% as the first reduction, move on from there.
Collision doesn’t matter for LODs, and usually you can get by with complex collision off the first mesh. Depending on how many verts each tile has anyway. In some cases you can just simplify it by using the lowest complexity LOD.
Anything except the engine allows you to generate an analytical mesh, where more density is used only where needed.
If you cut your meshes exactly as the landscape system cuts components, then you get the same culling, the same drawcalls, and great performance.
If on top of it you create a system to aggregate tiles at runtime based on view fustrum / distance (octree based), then you can even further reduce the drawcall count. Though in 99.9% of cases, just using manually (or script) placed static meshes already offers top performance, so there isn’t a drastic need for this. Its more of a nitpick, whoch with some basice c++ is fairly easy to achieve (but it is runtime based, so it can take a toll comparatively. Depends on device used. Pc great, console? Not so much).
Generally, the base process is you never do design stuff in engine. Once you start thinking that way, everything is easy, and everything you make can be exported out to other engines.
Texturing and materials are even better, since you don’t have to use the expensive landscape blend bs.
You can actually bake down your diffuse off a fully painted/blended mesh, and suffer no performance loss at all from having 20 different layers. (Sure paitning it in houdini or blender is a bit of a challange, but they use processes very similar to the layers in engine. On that note, adding a billion verts in zbrush and using polypaint to bake down to the original is also a viable solution).
The procedrual foliage tool is one of the few engine tools I still occasionally use.
(Its far better to import hism instances via a script, and to sculpt/generate positions outside the engine).
There must be around 100 blocks of different spawners, and at least 2 global ones which are in charge of grass, pebbles, random bushes, etc.
I have at least 13 grass meshes. From a clump to 10mx10m flat out zones.
I do run some of the grass off an hism where the objects are positioned from hudini via a script. (Also the 10mx10m blocks, which only go in very specific areas).
Those are for the piques and areas where the grass mesh would often fly in the air or similar.
(Note that sometimes, for particularly challanging landscape spots, its better to export the composed grass a static mesh. It won’t cull when you look at it if its combined, but it offers less drawcalls and thus slightly reduces the performance load for those areas).
Overall, to me, the important part is that if I get sick of this sorry excuse of an engine, I can use just about anything else.
When you only use engine tools only, well good luck migrating.
The engine alternative is you create your landscape. Get it all painted, and bake doen the tiles. You then create a new level with only the baked tiles as levels.
While not being able to cull component size bits of the floor, like the landscape system does, you still get 60% to 90% increase of MS processing speed just by the fact you aren’t using the landscape system.
And a next to nothing drawcall count when using 8km tiles…
Don’t forget that you do have to generate the LODs for the tiles you geberated the impostor for manually. I mean, ue4 allows you do set a couple LODs, but the result it generates was never really that good.
Even a blender pass with a limited dissolve and a 5° angle provides better results in trerms of final tris count to look…
UI/UX features to create faster:
Functionality Features for more beautiful end results