Wait, each block holds a vbo, as in you have a vbo for each cube? You should pretty much have as few vbos as you can. In your case, that could pretty much be one. As in, you input your data once - or when it changes - and only render using a single glDrawArrays (or similar) call per frame. Or divide into slightly smaller blocks of multiple cubes (which you might be doing, your description wasn't too clear about that) and call it for every N³ block of cubes, still not for every cube. You might also want to draw with index lists, though that might not be a good idea if you want to have per-face normal information. Which is not absolutely necessary, but makes lighting a bit easier.
Also, if you only have a few vbos, they don't take RAM pretty much at all, only VRAM. And assuming you use vec3 for every position, normal and texture coordinate and also use a baked float for ambient occlusion or whatever, you'll be doing 40 bytes per vertex and 960 bytes per cube. With 200MB of VRAM, that gives you over 200k cubes (a lot more in usual situations if you cull the underground faces) to play with, which ought to be more than enough.
I tried to use one static vbo for the cubes and just translate the cube for each draw. It lagged the game like hell. I'm looking to get around (32*32*32)*5 cubes in the Ram. This is all the cubes in the current chunk and all the cubes in the adjacent chunks. When you move to the next chunk all the data is saved and whatever chunks havent been loaded or generated are generated.
The problem is the VBO takes in vertexes for each face. Thats 72 float variables stored for EACH cube. Not to mention Texture coordinates. When I ran this last time on a 128*128*128 chunk it managed to run fast but it took up around 2Gigs of Ram.
You're doing Vertex Arrays (VA) instead of Vertex Buffer Objects (VBO) if your index count makes your RAM usage go up. (Or you're developing on a laptop with shared memory, which would be very, very sad.)
I'm also interested in how you got it to take over 2 GBs of whatever memory it takes. If you go the very unoptimized route and store everything (underground, air, all the cubes there are) in your VBO, you'd still have only 32x32x32x5x72x4 bytes = 47 185 920 bytes - under 50 MBs. If you optimize it a bit and only store and show the ground layer, you'll probably be looking at a few megabytes of data.
EDIT: Ah, you got the >2GB with 128³, which would still result in around 600MB by my calculations. I wonder what's going wrong here..
Ah yes I'm using a laptop with 256mb of dedicated VRAM. The laptop itself is pretty good. it runs on a 2.4Ghz dual core AMD with a Radeon HD graphics card. My laptop isn't a High end gaming laptop but it should be able to run anything that I make by myself.
On startup only the active blocks have VBOs when you add a block to the world it initializes its VBO.
I think one of the main reasons of the 2g memory usage was that I was doing 128*128*(some random number between 5 and 20) blocks that all had a VBO that held 72 float variables.
It's very in-efficient and I'm trying to find out how to have VBOs with only 8 floats for the vertexes.
It's very in-efficient and I'm trying to find out how to have VBOs with only 8 floats for the vertexes.
Well, if you want to take that idea to the extreme...you can get away with 1 float per voxel if you use a geometry shader, but I can't speak to the speed or plausibility of that. You could also apply the same idea by sending your 8 floats through, and then using the geometry shader to generate whatever else you need. And finally, you can try sending 8 floats plus an integer index buffer.
The chunk size is 128*128*128 and each one has its own VBO. Only the blocks that are generated at startup get a vbo and the rest aren't rendered until they are added.
