Support more region sizes

[TokisanGames]

Edit:
Changing region_size broke existing data. And no other size even worked, so I disabled them all except 1024 in ebf9df0.

Now let's get all the other sizes working again and look at much larger spaces like up to 2048 regions (45 square) and up to 2k or 4k region sizes. See #77 (comment)

---

Changing region size should not change the data at all. It should only change the size of the regions, represented as white boxes in the images below.

Instead it gives all sorts of artifacts:

• The data on the region map loses order, some sections appear split and move around
• Some data gets scaled laterally, some is flattened vertically
• Terrain normals are not recalculated afterwards
• The total size changes, rather than only the regions changing with the same data.

It may be as simple as running some update functions after changing region size.

4k x 2k @ 1024 region size

Change to 2048 region size. The total size is 2x as large. Instead only the white boxes should be bigger. That "mountainous" section in the top left between the split peaks is actually flat. But the normals make it look like there are heights there.

Changing to 512 region size and everything got smaller with less resolution. The data should remain the same, and the only difference we should see is the white boxes getting smaller.

[TokisanGames]

Actually, none of the region sizes work without producing a ton of error spam in the console. PR should fix all region sizes started from scratch and changing sizes and adjusting data.

ebf9df0 limited region sizes to 1024 only for now.

[outobugi]

The size should only be set once. We have discussed about making a creation menu which would force the user to save data as .res and select a region size etc. It makes no sense (to me, at least) to have a different regions size and constant map size. Sure, it would reduce the pixely look on smaller sizes, but on larger sizes the pixeliness increases. (e.g 4k region and 1k texture)
One pixel is one unit and I think we should keep it that way.

[TokisanGames]

Per this discussion with @wojtekpil, we can experiment with much larger spaces:
https://discord.com/channels/691957978680786944/1065519581013229578/1127936984053186600

Opengl 3.0 requires 256 layers. Each layer has it's own independent max size. So even in opengl 3 we could do up to 256 16k^2 layers. At 2k, 4, 8, 16k, dimensions are: 32k, 64k, 128k, 256k.

Opengl 4.0 and the vast majority of modern cards support 2048 layers. And 96.3% support 16k textures, 25% 32k textures and in the next few years more cards will support that (even GTX 1030 from 2017 supports it!).

So we should support up to 2048 layers (45 x 45), and region sizes at least to 2k or 4k, maybe up to 16k and let the user decide.
At 2k - 16k, dimensions are: 90k, 180k, 360k, 720k per side.

2048 layers at 32k each, which a GTX 1030 technically supports, would be a max terrain size of..... 1.47M by 1.47M! That's only 8.8TB of VRAM for one RGBA texture.

[amelkor]

Would be great to have smaller region sizes as well, that would perfectly match our terrain tiles which are size of 256 (in Unity, currently looking for the ways to port the terrains to Godot)

[TokisanGames]

You can import any size terrain, <64-16,384 (though only ~90 regions can currently be saved to disk #159).

If you want to have it look smaller, you can achieve that now in the shader. Look at the tips page in the wiki to cut off drawing outside of the regions. You can change that conditional to cut off vertices outside of exact coordinates. Will still use memory and vram for 1k, but you'll save pixel draws.