Add in place region modification methods to Terrain3DRegion

[LucaTuerk]

This PR is a draft for providing convenient methods of modifying the height, color and control map values directly in the Terrain3DRegion.

The Usecase

I am currently experimenting with importing heightmaps and splat maps exported from WorldMachine into Terrain3D and using procedural noise textures inside Godot to provide slight variations to uv angle and scale.

Using the methods for control map variation exposed in Terrain3DData is slow when importing values for a large area.
I did not look too far into this part but having to make the global_position to region local pixel position for each pixel modification is probably part of this.

I feel like there should be a way to modify the regions data similar to the Terrain3DData methods but operation on the local (pixel) coordinate system which can then f.e. be used in a do_for_regions callback to vary a specific value across the terrain.

The Alternatives

The Terrain3DUtils currently provide encode functions exposed to gdscript, but these do differ from the Terrain3DData API by expecting integer values for "float" values such as angle or scale, and would require knowing the control map format and bit masks for making modifications.

If these methods don't fit into Terrain3DRegion architecturally convenient methods could also be added in Terrain3DUtils that take an Image as parameter to achieve the same effect.

Open to suggestions!

[TokisanGames]

Thanks for the effort and thoughts on this.

to provide slight variations to uv angle and scale.

UV scale will likely be dropped in a future version. Detiling is intended for slight variation as well as uv angle.

I feel like there should be a way to modify the regions data similar to the Terrain3DData methods but operation on the local (pixel) coordinate system

This may be the way to go, but I don't like all of the duplicate code. I have to maintain this. I'd be more open to it if Data called these functions, and if they were all inlined at the bottom of the header file.

The Terrain3DUtils currently provide encode functions exposed to gdscript, but these do differ from the Terrain3DData API

The Util API can be improved, as can the documentation with more examples.

by expecting integer values for "float" values such as angle or scale

Easily converted with util.as_uint()

var control: int = util.as_uint(control_map.get_pixel(x, y).r)
if not is_hole(control):
    var overlay_id: int = get_overlay(control)

, and would require knowing the control map format and bit masks for making modifications.

The API does not require knowledge of the control map format, as demonstrated above and at the top of the Util API page, which shows a full example of modification. However, the control map format is fully documented and usable by all if they wish.

architecturally convenient methods could also be added in Terrain3DUtils that take an Image as parameter to achieve the same effect.

Rather than discuss implementations, I'd rather design an API based on examples of how user code is currently and how it would improve if the API was better.

As for do_for_regions() I don't like this function and would like to get rid of it in the future. It doesn't do anything more or faster that you can't do with a loop and it's unnecessarily complicated.