Flatten terrain under surface starports

[sam52796]

Fixes #5154.

If you look closely, you'll see that the terrain under a surface starport usually isn't completely flat. This is mostly not noticeable because the placing code fishes around for a relatively flat area to put them on. But the bottom of the building could still float in the air or clip into the ground. In extreme cases, like the linked issue above, particularly on small asteroid type worlds, the terrain would be too bumpy for the relocation code to find a suitable area, so it would give up after a while, and end up with steep terrain blocking some of the landing pads.

This PR modifies the terrain heights after the starports are placed to ensure that a circular area underneath each one is perfectly flat. On large worlds it then blends the flattened area with the surroundings, so that you don't really notice that it's been flattened. On bumpy asteroid worlds it keeps a sharp edge to make it look like a man-made flattened area for the starport to sit on.

Before:

.

After:

[bszlrd]

@fluffyfreak might find this interesting

[fluffyfreak]

Yes this does the same as I was doing in #6086 and looks like it will have similar performance considerations

[sam52796]

Not sure what performance considerations there would be here. A post processing step is applied once when fetching terrain heights, e.g. when a geo-patch is created. A mesh is then built from those heights and re-used - it isn't calculated again every frame for rendering. The only repeated per-frame calls would be for things like testing terrain height for collisions, and those are already running the full fractal calculation, so a few extra dot products each time doesn't seem excessive.

An area for improvement is that the fully flat terrain looks a little unnatural, so instead of fully flattening it I could leave it with the underlying bumpiness, but ensure that it doesn't exceed the height of the landing pads.

This would work well when the landing pads are up on stilts like in the screenshot. However, now that we can reliably flatten the terrain an alternative approach is to have the landing pads flat on the ground, more like airplane tarmac.

So if anyone wanted to create an alternative "flat starport" model, I could apply full flattening for those and then leave a bit of bumpiness for the ones on stilts. I actually think that would look better, since it seems conceptually odd to have landing pads raised off the ground, or on top of a huge octagonal structure. They're just flat areas for ships to land. But presumably the models had to be designed that way to handle uneven terrain until now.

[bszlrd]

On the thought of pads closer, or on the ground: how about driving it form the station.jsons? Say a radius to the effect, a falloff, and the max height allowed inside that radius? That way the stilted stations would have their justification for being stilted, but there could be flat ones too. (I could imagine stations that only have "painted on the ground" landing pads even, for low-tech worlds. A bunch of landing lights hammered into the ground, and maybe a projected texture of compacted dirt or concrete if anybody ever wants to implement such feature)

[sam52796]

Now that I think about it, we can derive those things from the model. If you create a model with a tarmac 5mm off the ground, then the code can measure the height from the model origin to the landing pad height (5mm) and then allow a maximum of 5mm bumpiness in the terrain. The current high-platform starports would work on the same principle but allowing 100m or so of bumpiness (the height of their landing pads).

I've added a second commit with this change now - the terrain bumpiness gets scaled down to the height of the lowest sitting landing pad on the model. If anyone adds a new "tarmac only" station type with pads at a tiny height off the ground, the code should flatten the ground accordingly. And I'd encourage people to try this because I think it would look more realistic.

This should also address any lingering performance concerns because most existing starports are the "on stilts" model and the existing terrain doesn't breach them, so in fact the code ends up deciding not to flatten those areas at all. For example on both Mars and New Hope there is now no flattening so performance will be unaffected on those planets.

[fluffyfreak]

The comments in #6086 cover the performance concerns that @sturnclaw raised, though they are lowered due to me making it generate many points at once instead of one. Where the concern remains is precisely in the collisions which generate a single point still.

The actual bug is worth looking into #5154 as that shows ALL landing pad types being covered by highly erratic terrain.

I'm fine with your PR superceding my own, they are very similar in implementation, but mine has been semi-abandoned due to work/life constraints.

[fluffyfreak]

Also there can be hundreds of starports on a planet, there are some mods which do this already for Earth. So the cost of iterating through them all per-patch can become excessive.

A basic approach I've tried on a branch is to group these flatten regions by the planet quad face. Thus reducing the number iterated through by at least 6.
However the next logical step for that is to pass down, and reduce the number of, flatten regions on a per-patch basis. That way each patch only contains the regions which might affect it instead of the full list of regions for the entire planet.