Split regions into separate files

[TokisanGames]

Description

After discussing with my Out of the Ashes team, I'm now convinced multiple storage .res files is the way to go, one per region, with foliage transforms stored inside. Eventually we'll support region sizes other than 1024k, and more than 256 regions (16k^2), up to 2048 (45-90k), the opengl limit for texture arrays on many cards.

Separate files will allow us to get under the 1gb limit for res files (#GodotEngine currently crashes above this), finally allowing us to save 16k terrains.

But the biggest benefit is for team development. With only a 2k terrain in OOTA, we already have challenges handing off the baton to edit the terrain between me and my level and environment artists so we don't conflict on git.

I thought about making the foliage instances its own resource file so one could paint foliage independent of sculpting/texturing. But the reality is an environment artist needs to sculpt, texture, and foliate simultaneously.

It would be insanely impractical if we had a 16k terrain and several more people working on it, where one dev has the entire terrain checked out. Plus it does suck to upload the entire terrain data, when you've only been working in one small area.

There will be an automatic upgrade process for your data as there has been on every change since 0.8.

Related #77
This would fix #159

---

Here's how I think it should look:

• Inspector: change visible storage variable to a directory with a select folder dialog.
• File name format: change from userspecified.res to userspecified_00_00.res where these numbers represent vector2i region offset. With the 1024x1024 regions, region offset is basically global position / 1024. But get it from storage.get_region_offset(). There's an OpenGL max of 2048 texture layers, which tops out at 45 x 45, so 2 digits is enough.
• Data structure: current foliage terrain_3d_storage.h

	PackedInt32Array _region_map; // 16x16 Region grid with index into region_offsets (1 based array)
* 	TypedArray<Vector2i> _region_offsets; // Array of active region coordinates

*	TypedArray<Image> _height_maps;
*	TypedArray<Image> _control_maps;
*	TypedArray<Image> _color_maps;

	// Foliage Instancer contains MultiMeshes saved to disk
	// Dictionary[region:int] -> Dictionary[mesh_id:int] -> MultiMesh
*	Dictionary _instances;

Asterisked items are currently stored in the storage file. Region map is not. region_map and region_offsets work together to define where regions are. Region IDs have no bearing on location. They are only indices into region_offsets, which has the location.

By storing the region location in the filename, upon loading its location can be inserted into region_offsets, and that index is its region number. So we no longer need to store _region_offsets in the files, as it is apparent by looking at the files and their names on disk.

We only need to store the maps and instances dictionary. Storage is currently a Resource so it can be loaded or saved directly to disk using engine functions. Instancer is an object so it cannot be saved to disk or displayed in the inspector. Instead it's an object that Terrain3D loads, then it manages data inside of Storage::_instances.

Like how Storage currently works, make a small subclass that extends Resource and only has the image maps and instancer data. However you only need one Image for each type, instead of a TypedArray. When loaded into Storage the maps can be inserted into the existing TypedArrays for minimal code change. Then Storage can be converted to an Object, like Instancer.

Like the maps, the instances dictionary will also need to be separated by region and merged on load and save. But don't worry about foliage until my PR is merged. Don't worry about upgrading users for now. First just envision starting a new user from scratch.

[icebamboo97]

I just wanted to say I love you.❤️It's what I rely on for my 16km x 16km maps.

[TokisanGames]

This has been fixed in #374 and #476.