I mean that this can be only some sort of adaptation for the current RW generator (a kind of optimisation - if current generator uses heightmaps it can generate LOD faster), the LOD itself and volumetric generators (and caves) will require some sort of density function to generate LOD.
That does not work without degrading performance: Having a heightmap representation of the terrain available is not only helpful for LOD chunks, the game uses this information for other things as well (e.g. to decide which parts of the terrain will be affected by snow, or to handle ambient sounds properly etc).
If we want to keep it, but also have to generate additional data with higher resolution at the same time, this definitely has performance implications.
This is one of things sparse voxel octrees are created for - different LOD for chunks on different distance (and faster LOD generation for distant chunks). Voxels are stored hierarchically inside a tree, with 8 leafs per node, so for chunk with 32 blocks there will be 6 hierarchical levels, but these levels don't need a full grid of voxels.
This does not cover the actual problem: Octrees still have overhead we don't have to deal with at the moment. Irrespective of how much optimization will be put into their implementation, they will be slower than the current LOD implementation (unless we want to fundamentally change the way how the world and terrain is generated).
And when talking about memory, the terrain data isn't necessarily the main issue (only when it comes to serialization/deserialization or network traffic, but that's a different story), the main issue are the different meshes that need to be generated for this - and there is no way to save much memory on them. Currently the game only generates LOD chunks (both the data and their meshes) once and then never touches them again (unless the world at that location was modified). The game only has to distinguish between LOD chunks and regular chunks (although regular chunks are based on LOD chunks), so this handling is rather cheap (in terms of performance). If we want to implement dynamic LOD handling (i.e. only generate the different LOD levels when they're needed), this will be more complex and will definitely degrade performance compared to our current approach.
Blockscape appeared in 2012, and this method worked fine these days, it will not cost too much performance, and probably will be even faster that the current one
IIRC the old Blockscape version back then had some issues regarding performance (and there was probably a good reason why the dev switched to a different style the last years), however, I'm not sure if you can really compare Blockscape with RW. The game has a different style, and while the mountain looks great in Blockscape, the same mountain wouldn't look that great in RW.
You also have to keep in mind that terrain generation is only a small fraction of the things the game has to generate - so we can't spend too much of our frame budget on it. In Blockscape, for example, or in block based games like Minecraft, terrain and blocks are typically the same mesh. This approach doesn't work for RW, so plants and constructions still need to be generated separately (especially generating the latter can be quite time consuming).
At the end of the day, implementing a better algorithm for LOD chunks would only slightly improve the final visual result in most cases (on natural terrain, our LOD chunks typically fit quite well to regular chunks), but at the same time, this would result in a slower world generation (and probably a higher memory overhead).
As mentioned before, while there is certainly room for improvements, we can't spend any time on reworking the LOD chunk handling at this stage.
Wenn das nur temporär ist und die Spieler sich daran gewöhnt haben, kommt ein Riesenaufschrei, wenn das dann plötzlich wieder reduziert wird. 
Vielleicht ist es wirklich sinnvoller, hier noch zu warten, bis es ein entsprechendes Tool gibt.
Ähnlich wird das dann später bei Blaupausen laufen, die die selbe Mechanik verwenden werden.
Weiteres Feedback in dem Bereich ist aber auf jeden Fall sehr hilfreich 
Does that mean you no longer run into timeouts after joining the test server once? 
