Today I got voxel generation back in for the heightmap terrain. Originally, my intent was to use 64 bit doubles on the CPU to generate the voxels, and 32 bit floats on the GPU for the far terrain. The far terrain wasn't that precise, so I thought that the loss of precision would just cause minor inconsistencies that weren't noticeable at all. Unfortunately, due to the way gradient noise works, the two implementations produce vastly different results. The 64 bit CPU version didn't line up with the far terrain at all in some places, and it only got worse the more octaves you added. We simply can't use a 64 bit GPU implementation, so it seems that we are going to have to switch to CPU only, which will be nullifying a lot of the work I put into GPU gen. (I'm used to throwing away work now) The implications of switching to full CPU generation are as follows: Pros: Easier for modders to change generation. Can use much more complicated and realistic generation techniques (can't use branching well on GPU) Easier to manage code wise, since we don't need to make sure the two implementations are the same. Cons: Far terrain generation may be noticeably slower. May not be able to generate normal maps anymore (requires 16x as many noise samples) Or we may only generate them close to you. However, there are other ways to make it look good even without generating normal maps. It won't be as slow or poor quality as the 0.1.6 terrain generation, since that one didn't even use multithreading. I am confident that we can get good results with this, it's just a shame. This is entirely my fault for not doing enough preliminary testing and making assumptions about precision implications, and I am sorry. Over the next few days I'll work on outlining a new generation system that uses the CPU, that will allow lots of flexibility in generation, and I will do my utmost to make sure the generation stays fast and remains of high quality.