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.

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

Tracking further development of this in https://github.com/fluffyfreak/pioneer/tree/regions-branch

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

When something queries the height via GetHeight that is done on the BaseSphere -> GeoSphere which holds the terrain, so it can all be unified through that 👍 should be consistent.

Hard part right now is making sure that it's consistent with the GeoPatchJobs system. Finding the appropriate region(s) to pass through to those jobs because at high levels of the quadtree there could be many regions involved.