Path Towards Terrain Generation

[FishOfTheNorthStar]

I tried this recently with promising results:
https://github.com/Auburn/FastNoiseLite/tree/master/GLSL

Frankly, I prefer the standard, in house Terrain3D noise, so far. It just looks more natural. But it's really interesting that FNL is an option entirely within the shader. I wanted to make sure you were aware of the pure GLSL version of the FNL project. I've added a 'fastnoiselite.gdshaderinc' into the tools directory of the build (it's just an exact 1:1 copy of the code at that link), and can include it fine into current tests, and performance seems pretty good.

Using a very simple FNL noise definition for that test. Interesting stuff. I might add a 'noise supplier' option to test with so we can more easily switch between 'Terrain3D in-house noise' and 'FastNoiseLite generated noise' for side by side comparisons.

[TokisanGames]

I was the one who wrote the wrapper for FastNoiseLite and with the help of someone else got it merged into the engine. I'm aware Auburn has the GLSL library. See #48. Ultimately, I went with IQ's algorithm for the second world noise implementation for its natural looking terrain.

The world noise in its current form is just a visual gimmick for a background, without any possibility of collision. I don't want to build on it, or even encourage its use by users. It's expensive and only useful for demos. There's a cheaper way to do it. I'd rather focus our efforts in a different direction:

Here's what I want to do, and would appreciate the help in these areas:

• Implement GPU painting, and a compute GPU -> render GPU pipeline Implement GPU Painting #174
• Implement terrain generation, which might be on the CPU, but could also utilize the GPU and the GLSL noise library, Implement terrain generation #101.
• Implement a procedural mode where the compute GPU generates the map on the fly wherever the camera is, which is sent to the CPU for dynamic collision generation, and the renderer.
• Implement an RVT where the maps get baked and the shader is very simple, Make a runtime virtual texture #245
• Have fallback options for OpenGL, Mobile, and Web support where possible, but we are positioned as Vulkan/Desktop first.

[FishOfTheNorthStar]

That all sounds great. I've begun work on procedural generated textures. Here's a 'dry/desert biome strata rock' kind of test that came out nice.

generation descriptor:
8E1F5BE1D38040582DAED1E1D1804A6023FF805D9580365C23FF35E1D1802060

These can provide albedo, normal, height, roughness, metallic, AO, using small hexadecimal strings to encode the noise gen parameters into short snippets (16 hexchars per layer of noise, so each of these might have a unique identifier between 32 and 128 characters) . Results pretty promising so far. It generated this offscreen (entirely on the GPU), once per settings-change (which can happen in very smooth realtime, on my system). Generating 2048x2048 using 4 layers of noise (for this example), haven't timed it precisely yet but it's fitting within the vsync window without impacting GPU much at all, on a mid-tier system.

My plan is to implement some form of this within the Terrain3DTextureList and try out a fully generated texture set.

Conceivably, this same system could generate background world, or several blended biomes of it, even. Ultimately, that is my plan for my game, which will probably be using Terrain3D (or my weird fork of it). Procedural terrain generation is a core requirement for what I'm doing.