Developer log of Jens Blomquist

Hi,
I'm Jens Blomquist, responsible for every aspect of this game. This is my log about the adventures in the code of Blockscape.

Limit reached part three

Hi,

Actually there are a whole bunch of limits that have been reached. Here is a list:

A. Main memory

On max view distance it could use up more than 3GB of main memory. (32 bit processes are limited to 2GB but I modify the exe so that it can use up to 4GB. The problem is that 1GB is used by the OS and the framework.)

B. Graphics memory

On max view distance it could use more than 1GB of graphics memory.

C. Rendering speed

On max view distance it may have to render more than 10M vertices.

D. Block types are hard coded

The block types that we have today are pretty much hard coded into the engine. Global illumination, surface extraction from voxel grid and mesh optimization are all done on a per block basis and how the block relates to surrounding blocks.

Okay. That is not good. Why didn’t you think about all these things from the start I hear you say. Well, I did. The problem is that the solution is so annoyingly complicated that it took me almost a full year to think it through and implement. This is why I released Blockscape with the engine that we have today and then continued working in parallel with version 2 of the engine.

The good news is that this version 2 of the engine is almost ready. When I say almost I mean in a few days. Next snapshot will run on the new engine.

So how did I solve all the problems?

First I need to tell you why we have the problems and it actually boils down to one single thing: The world is made of blocks. Yes, that is right. If we skipped the blocky part and went for curved surfaces using some well known method like the marching cubes algorithm we would never have had all the memory and performance problems above. The mesh generated by the Marching cubes algorithm is very easy to work with and to optimize. But at the same time we would also have to throw away all the blocks and how we work with world. Crafting, blueprints, mining and building would be something else or not working at all. And beeing limited to only curved surfaces is not an option for me.

The solution:

1. The solution to A is voxel data compression.
2. The solution to B and C is progressive meshes.
3. The solution to D is Constructive Solid Geometry (CSG)

The voxel data compression was quite straight forward. I did some compression in the old engine and I just made more tuned version. There is still room for improvement here if needed.

Progressive meshes were a real pain because of the blocky properties of the world. And to make it work in realtime was even more pain. I spent huge amounts of time on the algorithms here and I’m quite happy with the result. Much fine tuning is still needed and I guess some of you will complain on how detail pops up when you approach new terrain. This is unfortunately a side effect of using progressive meshes and I don’t have the luxury of time (as this runs in realtime) to do very smooth transitions.

The CSG part is not working at 100 percent yet but it is good enough for now.

A positive side effect of solution 2 and 3 is that I now have access to the real surface much earlier in the pipeline and because of that I can do much better/accurate lighting in much shorter time. A bit hard to explain but you will definitely see the result. Surfaces will appear brighter and better lit. The snow for example will look more like snow and not like the “dirty” snow we have today.

The result:

We can now add any block type with any complexity we want. More bricks, slopes, bars, tiles. The engine will, using CSG, automagically combine the different blocks into a perfect mesh. The progressive mesh engine will then optimize the meshes and do LODing in realtime.

In other words: The new engine will do more stuff faster using less memory. 

On my machine on max view distance it currently uses about 1.5GB of main memory, about 300MB of graphics memory and runs at a steady 150 FPS.

best regards
Jens