Some semi-random thoughts on terrain generation

[NiLSPACE]

Wow.. Just wow.. I created a plugin that is basicly a world generator and it generated this:



I immediately had to think about the trip xoft took to New Zealand.

[xoft]

This looks like the very regular Noise2D heightmap?

---

You might want to read up on Perlin noise and others; I can recommend the entire LibNoise webpage: http://libnoise.sourceforge.net/index.html

[NiLSPACE]

I even managed to create a biome generator:


I used a perlin noise generator. Or at least it says it is because I don't really know the difference.
I found the code here: http://pastebin.com/EZRaakNf and then line 1 to 72.

[xoft]

Yes, that's a naive algorithm for Perlin noise; MCServer uses more advanced stuff, for performance reasons.

[NiLSPACE]

We really need a better way of making plugins that generate terrain. Lua is too slow to create a complete new generator. With this generator I'm baraly doing 18 ch/s which is quite allot if you also think this generates: the heightmap, the biomes, the composition and the finisher.

I've heard quite allot about LuaJit being faster. I have no idea in what aspect it is faster or why it's faster but if I remember correctly a while ago some people here on the forum were also discussing LuaJit.

EDIT:
I see why you enjoy working on the world generator. It's awesome to see the new terrain generate before you without really knowing how the result would look like.

[worktycho]

LuaJIT is faster for code that is run multiple times like a world generator because it compiles the scrits to native code. It claims to be drop in compatible with lua 5.1 so its probably worth giving it a try.

If your writting world generators in lua then we need to rethink how the bindings should work for better performance. I would think we should create an object similar to cluatask as a generator. A plugin would then construct one of these with call backs for the various generating functions. This would avoid the overhead of the hooks system.

If the bottleneck is still the bindings after that then we need to look at a limited form of c++ plugins.

[xoft]

I think plugins are altogether not the place to build brand new generators. Some things just need to be done properly, and for a real generator you need to go C++. The current interface is meant for plugins that want to disable parts of the generator, for example the Gallery plugin; it is not supposed to be used for implementing a real generator, and even if we did in fact use LuaJIT, it would still be much slower than native C++.

[worktycho]

Then we need some form of limited c++ plugins so that people like STRWarrior can develop generators seperatly from MCServer. We do not want to require that generators all have to be part of the main server. C++ plugins would involve all the maintance overhead of another set of bindings and a loader when luaJIT is not much slower.

[xoft]

Actually, we DO want to require tight coupling. It makes sense to require it when the code needs top performance.

[FakeTruth]

You could at least use light userdata instead of full userdata to cut down on quite some Lua overhead already:
http://bitsquid.blogspot.nl/2011/06/ligh...dings.html