I recently begun one of these “real world scale” projects, with an extent of about 2500km by 2100km and an elevation limit of 3750m. Output size is maxed out at 16k width. The 80km limit on layout shape falloff, and the 8km limit on shape breakup, are far too abrupt to use shapes to control the overall base elevation. Similarly, the 512km limit on radial gradient is not large enough to encompass some accurately sized “high plains” layout shapes.
Specific example: A high plateau region with 1200m elevation, needs to run smoothly all the way down to 0m elevation over a distance of about 750km. (It’s not the same shape, but think Kansas or Colorado east of the Rockies, nearly a tilted plane.) When defining the plateau with a layout shape, the entire elevation change takes place in no more than 80km. Actually, the plateau needs asymmetric falloff around the perimeter, so I really need to blend several layout shapes, one of them masking a linear gradient, but the range on linear gradients is not enough to cover the necessary 750km.
Frankly, I expected to run out of memory before functionality, but 64GB and 24 threads has been quite ample to work on a project of this size, provided you don’t tweak the larger layout shapes endlessly. However, I cannot build the overall elevation contours I need because the (relatively) short scale limits prevent subtle blending of layout shapes at differing elevations. Advanced Perlin is to provide appropriate random variation on top of these base elevations, which are designed (or surveyed) and not produced by a random process.
I will be restarting my project at a smaller scale, but would encourage substantially larger limits on these features to support “real world scale”. The layout shape falloff limit is the most critical, as I can use that to mask almost anything else.
Much larger radii/falloffs on generators
This is a good idea, the problem has always been how to expose these extended ranges to the user. The slider should still enforce soft limits for usability sake, while the parameter should allow the “extended” range if you explicitly enter it. This is not possible with the current UI framework, but is something I’d like to see in the future.