Some semi-random thoughts on terrain generation

[xoft]

I've just realized that I'd completely forgotten about ores in the new generator. So I quickly ported (and improved, of course) the ore generation into the new architecture.
A build is available, as usual.

[xoft]

Why we need a lighting rewrite

This was taken using a profiler, the numbers represent percent of time spent in the functions. More than half of the time used for terrain generation is spent in lighting.

[xoft]

Ugh, the new lighting thread needs over 7.5 MiB just for its internal buffers. That's gonna hurt - it definitely won't fit into the CPU cache.
And there I was, thinking that I could fit it into the thread stack

[NiLSPACE]

What does an lighting thread do? I thought that the client now decided where the light was.

[xoft]

The server calculates lighting and sends it to the client as the initial chunk lighting. From that moment on, the client calculates the lighting for itself. But the server still must be calculating lighting, both for new clients and for mobs, plants etc.

Actually this exact thought brought me to the current implementation - lighting is to be calculated only when explicitly asked for - either due to a chunk being sent to a client, or a mob spawn operation. So the server doesn't keep re-calculating lighting all the time, but only on request

[xoft]

Alright, I think I've managed to get the lighting working, too. So now we have a version that might actually work

I have built Rev 497 and put it to the nightbuild website. I ask anyone interested to give it a try and tell me if there are any significant issues with the generator or the lighting.

Notes:
- Lighting is stored only in the Anvil (.mca) scheme. If you're using Compact (.pak) scheme, lighting may not be saved to the files or may be read wrong upon loading. Needs fixing.
- Documentation is coming later. Most of the world.ini settings and the rationale behind them can be found in this thread.

[xoft]

Since there are no bug reports and the code seems to run smoothly, I'm thinking about actually merging the composable_generator branch into the trunk. That means that there won't be any more special branched builds required, the code would be in the reguular nightbuilds.
Also, I'm pretty sure the code is more stable than anything in the repository so far, so I'd like to propose releasing it as a Beta candidate, if not already a new release on the official page.
Of course, FakeTruth has the ultimate decisive say in this.

[xoft]

Branches merged. Now I need to write up some documentation

[NiLSPACE]

so the new generator is now completely finished??

[xoft]

I wouldn't say completely. It's not like we couldn't improve on it. A lot, in fact.
But now the generator can do as much as the old one could (with some extras). So there's no need to keep it separate anymore. Especially now that it's faster and more stable than the old one.

The cool thing is that now any modification to the generator is quite localized to one place. If you want to generate sand in desert instead of grass, it means touching a single object, cCompoGenClassic, that has one single purpose - filling terrain based on biomes. So the code is quite clear and easy to maintain and extend.

For the users, it means more freedom in what they want their world to look like. If they don't like trees, they can switch trees off, while keeping all the other features. If they want square biomes, so be it, they can get square biomes. If someone likes the desert, they can set the biomes to constant desert and that's what they get. Of course this will need some more time for the generators to mature, right now there are only generators usable for the classic terrain and for some debugging. I expect more to crop up soon, though.