Some semi-random thoughts on terrain generation

[xoft]

That's indeed quite an interesting approach, but I can't see any use for it in our case at this moment. We'll see if something pops up.

[NiLSPACE]

It seems someone on reddit also tried to offload parts of the generation to the GPU: https://www.reddit.com/r/proceduralgener...n_the_gpu/

[xoft]

Their code is not too optimized for our use-case. We get a very high speedup from the fact that we query a lot of noise values in a uniformly-spaced grid, which means a lot of the calculations can be cached. That's actually the magic behind why our noise implementation is (much) faster than the Simplex noise. I'm not sure if such optimization is possible on the GPU, where memory-access (caching) is an expensive operation, unlike calculating from scratch.

[xoft]

Finally, I managed to get all the side-tracking distractions done, and I can start work on the new generators.

For the new generator, I need new types of connectors (vertical with rotation support). So I needed to be able to generate them in the Gallery plugin running on the Gallery server. But for that, I needed to add visualization for them so that they display properly in WebAdmin. But for that, I needed to change MCSchematicToPng. And that takes ages to compile for the RasPi, so it would be a much better idea to run it on a different computer and have the rendering requests delivered to it via network. But for that, the network protocol needed to change (so that it contained the actual area data - the remote computer has no file-level access). And then I needed to implement that protocol in GalExport and Gallery plugins. And while I was changing them, I realized that it would be much better to store the area previews in a single DB file, rather than in a thousand tiny files (better last-modification-time tracking).

Now I finally have all that behind me and can get working. First, I'll add support for the new connector types into the PieceStructures generator, to make sure the idea works, and to make it possible to use proper vertical connections between areas. And then finally the all-new ConnectAllStructures generator that works similarly to PieceStructures, but has additional limitations on the placed pieces (all their connectors must be connected to a counterpart in another placed piece), which will finally make the underwater temple and the woodland mansion possible in Cuberite.

If I'm right, we'll even have a better woodland mansion than Vanilla - ours could, theoretically, generate an atrium inside it

[NiLSPACE]

Whoah, that's amazing. Do you need help for adding the connectors to the pieces?

[xoft]

Not yet, first I want to write most of the generator to find out if it's really a viable solution. It might need some optimizing before it is usable.

[xoft]

Now I just wonder who's gonna review that mess. And it's not even the new generator yet, it's just the new connector support into the old generator...
https://github.com/cuberite/cuberite/pull/3569

[xoft]

The new ConnectAll generator is not going as smooth as I thought it would. The algorithm is not so easy to pin down into exact terms, and the more I think about it, the more I believe the overall performance would be totally unusable.

[xoft]

My initial fears were far too optimistic. In the end the generator is trying to solve an NP-complete problem and is hopelessly slow. I've let it run for some 20 minutes and it hasn't generated a single structure in that time!

I'll have to come up with something smarter for the mansions / underwater temples

[NiLSPACE]

Aww, that sucks

Perhaps this idea can be used, but when expanding you don't let the structure go out of a specific boundingbox.
Nevermind, that wouldn't work easily because we have specific connectors where the prefabs should work with.