Memory Contraints

Yeah, that's a crazy huge amount of memory -- especially when you consider every PS3 game out there gets by on 256MB.

You don't need to store positions - you can infer them from the array indices.
You don't need to store texture coordinates - you can infer them from positions.
An array of bools is space-inefficient (8x overhead), you can use a bitset instead, which works like:unsigned char exists[(CHUNK_BLOCKS+7)/8];
bool BlockExists( int index )
{
int byte = index/8;
int bit = index%8;
unsigned char mask = 1<<bit;
return exists[byte] & mask;
}

I'm curious about what you're doing with that 2MB per chunk. If Minecraft is your "competition" I would wager that they are no where near 2MB for a similar sized chunk, and that, whatever their draw-distances are, memory use is probably not a significant factor in their decision.

Lots of stuff can be inferred, as Hodgman said. Also, generally speaking the world is typically pretty "sparse" where here I mean either empty space, or large, contiguous runs/macro-blocks of identical block types -- any time you see this property, you are guaranteed favorable compression rates, something around 10:1 is probably a decent guess (possibly even conservative), as far as encoding block types goes (though it will swing wildly from 1:1 in areas with lots of "detail" to 1000:1 in a 10x10x10 uniform macro-block) -- but overall compression also depends on what other data you encode into a block, since I'm guessing that you aren't really spending 2MB on a 3D array of block objects.

Another thing to think about is that, most of the time, you only need a subset of the block data to represent the structures built from blocks -- you never need the internal blocks of a large cube, for instance -- not until you do something to dig into it, anyhow. If you have a way of detecting when these previously unexposed blocks become exposed, and a method of loading them, then you can simply consider them to be empty-space (or rather, undefined-space. Null or void space, if you will until.). Take it a step further where the world is procedurally-generated, you don't even need to know what a particular part of the world looks like until you're looking at it, and you don't need to store it until you modify it! This is similar to fractals -- they have infinite detail, and through how we map their algorithms to our screens, it only requires exactly as much computation is necessary to present themselves as the exact level of detail needed. I'm sure there's a clever analogy to be drawn to Schroedinger's Cat, or the fact that you can't observe a particle and know its true position at the same time, but I'm too tired for that and you'll have to make due with their mere mention

Keep your ingame and graphics stuff separate. The format of minecraft lets you get away with 2-3 bytes per block and has 16x16x128 blocks per chunk, so thats 64kb-92kb.

For the graphics stuff:

-Do not create data for invisible faces. Ignoring the fact that a few blocks have special geometry or is transparent, the majority is a unit cube and makes it trivial to decide if you need to draw a face (is there a neighbor or not). Just keep in mind you have to handle chunk borders, especially updating when loading new chunks. You can also ignore 2 sides for each chunk not "in line" with the chunk youre in (and 1 for the rest except the center).

-Don't use full blown floats for data that hardly requires more than a few bits. Unit cube texture coords only have 4 options and are either 0 or 1. I'm using a table in the shader, but you could directly use the bits. Position doesn't even need a full byte. Lighting can be stuffed into 4-8bits (all based on minecraft format). Have an offset per chunk and do your blocks relative to that. You'll need to handle special geometry differently of course, but that's the minority anyway.

I can tell you that 1339 chunks need about 65MB "graphics data", so on average 50kb per chunk. Add 92kb for the block data (type, data, light/blocklight combined in one byte) and you should run into loading time issues before you run out of memory (not happy with 1.5s for 1339 chunks, but might get it down to 1s).


I guess many people are fooled by Minecraft being all blocky and low res and looking pretty old school (or "lame") and really underestimate the thought that needs to go into handling that many blocks with finite ressources.

I thought bools were 1 bit ?

I think this is whats killing me:
float buffer[16*16*16][4][5];
float bufferLiquid[16*16*16][4][5];
float bufferTranslucent[16*16*16][4][5];
This is taking 983KB (983,040 bytes) per chunk.

There has got to be a better way to do this.

[quote name='coderWalker' timestamp='1301190519' post='4790855']
I think this is whats killing me:
float buffer[16*16*16][4][5];
float bufferLiquid[16*16*16][4][5];
float bufferTranslucent[16*16*16][4][5];
This is taking 983KB (983,040 bytes) per chunk.

There has got to be a better way to do this.

You can make one mesh that contains all the possible faces that a chunk could have, and then use that single mesh to render any possible chunk (instead of making a unique mesh for each chunk).

If we say a 'chunk' is a 16x16x16 grid of cubes, then we can draw it with a 17x17x17 grid of vertices. Once we put that 17x17x17 grid of vertices into a VBO, then it becomes a shared resource that every chunk can use. Every chunk has it's vertices in the same (relative) positions, the only difference is the absolute position of the chunk in the world, which you can express with the modelview matrix.

Now we need a way for each chunk to 'select' the vertices/faces that it actually requires from that grid -- to do this you can use an index buffer.

To do a 2D example, imagine a 2x2 grid of squares, where we number the vertices depending on the order they appear in the vertex buffer:1---2---3
| | |
4---5---6
| | |
7---8---9If a chunk wants to draw grass across the top 2 squares, it's 'grass' index buffer could contain the indices (for a tri-list): 1 2 4, 2 5 4, 2 3 5, 3 6 5
If a chunk wants to draw 'rock' in the bottom right square, it's 'rock' index buffer could contain the indices (for a tri-list): 5 6 8, 6 9 8

This can NOT be done immediate mode right?
What extention do I need to use?