feat: Enable scalable generation

[4Denthusiast]

This requires the engine PR MovingBlocks/Terasology#4452 . It gives an example of what that engine feature is capable of, so I would recommend testing them together.

[skaldarnar]

Could you elaborate a bit how the scale parameter is going to be used, or rather, how it should be implemented? Scaling the overall terrain looks like a super simple use case, but I'm wondering how this should apply to something like the tree facet...

[4Denthusiast]

Generally, the scaled versions of facets should be whatever is needed to make the final result visually similar, so if the tree facet is generated with a scale of 2, then for each position in the facet, the provider should try to ensure that there is a tree there iff there is a tree in any of the corresponding 8 blocks in the unscaled version, and if the scale is so large that individual trees wouldn't be visible, then something like generating trees in heavily forested areas in general (which are then converted to just 1 leaf block each) might be appropriate, until the scale gets so large that even the forest shouldn't be visible.

[skaldarnar]

💡 I think I have to read up on how the respective noise functions behave. The overall description definitely makes sense...

Given that, it might be that the computation effort for LOD chunks is the same as for the detailed chunk (determine on block level whether there's a tree or not), and then scale down to lower level of detail (is there at least one tree here, are there enough trees in this area to form a forest, ...). Maybe the tree facet is already a pretty tough thing to support, because of the randomness in the L-Systems and that it probably is harder to figure out an approximation of the blocks set later on...

[4Denthusiast]

It would be possible to generate a scaled tree facet without all that much computational expense (except that the wider trees that require a 5 block flat area to spawn on wouldn't work as well), if we change the algorithm for placing trees in the unscaled version. Rather than having a separate random sample for every surface block, if instead we start at a scale level where each block has quite a high probability of containing a tree, then if there is a tree at that scale, recursively subdivide the area using the conditional probabilities of there being a tree in each octant, given that there is a tree in at least one of them (with some correction for the correlation too). This way the computation is the same whatever the actual scale is (up to the point where pretty much every surface block probably contains a tree anyway).

This algorithm would not be perfect at always placing trees in the right place, but it would get it right most of the time, and that should be enough for LOD chunks. It would be more complicated than the current one for scale = 1, but there is also an efficiency advantage in not calculating the noise for every position. It would be even more suitable for features like volcanoes or flying islands, which are less common (which makes this algorithm more efficient) and have less conditions on suitable locations for them to appear (which makes this algorithm more correct).