Resurrect region based terrain flattening

[fluffyfreak]

This was originally done by @Ae-2222 many (13/14) years ago in this branch and I've resurrected it here because issue #5154 is still a problem.

Fixes #5154

This works by querying for starports on a planet, adding them to a list, then checking that list whenever a height sample is requested... this has some performance implications but on my high end machine it runs very well. I've not yet tried it on a Raspberry Pi...

Putting this up as a draft to started discussion.

I have:

• reworked how it gets setup and initialised
• changed what was stored a little

Things I think it needs:

• optimising
• the blend method is strange to me but it works with a small enough region/city size set

Issues:
- inconsistent results across machines!
- I don't think that it currently covers all starports on a planet!
- somtimes flattens terrain away from a starport whilst not flattening the starport

Image taken at (0, -2, -2) Gliese 1

[sturnclaw]

O(N) dot-product-and-branches is not great when we're running that for every single terrain point generated on the entire planet with potentially 20+ flattening regions. That's not a condemnation of you or the original author, to be clear, but something like this IMO would be a much better fit for a GPU-based terrain generation pipeline.

However, for the purpose of getting something in, I'd personally envision the API as passing a span of valid flatten-region structs into the GetHeight() call (maybe even a GetHeightWithOverride() method wrapping GetHeight() so you don't have to ApplySimpleHeightRegions() in every terrain generator?), and making it the responsibility of GeoPatch to compute the list of applicable flattening regions to pass into the call for the patch in question.

The logic for that can be made pretty simple; each patch maintains a std::vector<SimpleHeightRegion> * until there's only one height region in the patch and then it's just a direct SimpleHeightRegion * passed down to all applicable children. In the view of optimizing for terrain generation time, it's probably better to maintain contiguous lists of height regions per patch than it is to try to store indices and pay the performance cost of doing non-contiguous pointer-chasing for each terrain sample generated.

EDIT: this also means that we're not paying the height region cost at all for patches containing no flattening regions, i.e. 99% of the planet's surface.

Regardless of how it's implemented, this does potentially run the risk of making terrain height values inconsistent based on the source that's querying terrain height (e.g. collision, rendering, etc.). I'd want to make sure we're presenting a consistent model of terrain, as future graphical features (e.g. surface-scattered objects like grass, etc.) depend on queried terrain height matching the graphical model of terrain.

I'm not sure there's an elegant solution to that problem though, outside of stuffing significantly more logic into the physics engine to generate collision representation meshes "on demand" based on nearby potential-colliders rather than doing arbitrary terrain generation queries every single collision check.

[fluffyfreak]

Great feedback! I'll have a think about resolving both of those issues