Interesting concept 
So you have max of 16 chunks? Static array of chunks:
chunksLoaded[16];
Where the array above stores chunks world location and I take it this is used
for the filenames on disk? Example:
chunk3_3 - chunk at world offset 3,3?
Thanks
PS - do you do the loading in a separate thread?
@steg
I currently have an array of chunks[64] and this can be scaled. Each row needs 8 chunks.
Yes file names are calculated with ascii character based on world loaction - not stricty numbers…but are converted into the value of the char.
But yes chunk1232_8829 would work the same!
I havent moved that far away yet, but i was thinking of say every 256 chunks to put them in folders. I think MC did this AA AB AC where A =0 ;
if in the CF folder and the chunk3_78 would mean 3+(2256) , 78+(5256) world position
Thanks again @Vermeer
I’m going to try and look at implementing something like this over the weekend if I get any time!
Update:
Frustum culling
Further field of view
Some spatial portioning
Updates to camera vectors
Few bug fixes
https://www.youtube.com/watch?v=fSp-54tGgLU
Thanks
That looks to be running really well, and the further draw distance give a better sense of space. Looking cool.
What are your plans to do next? Are you planning a GUI or any game play elements?
Hi,
Thanks ;D
Dynamic loading has to be next to keep the memory stamp down and the fps up, at the moment you are seeing 16^3 chunks with a draw distance of 200. This consumes around 170mb ram and 48% CPU on average - hence need dynamic loading of chunks if wanting more.
May put water in soon. Wouldn’t mind looking at some perlin 3d noise stuff so can get caves…
I had the opposite problem with my voxel engine.
3-4% CPU & 600MB RAM with 192x192x192
3-4% CPU, what GPU was that running with?
How did you manage to get so many chunks running? I’m struggling with 16x16x16!
Regards,
Steve
Think I’m going to next do:
Wish me luck!
good luck, tho I’m sure you will get that sorted.
Initially used triangles and found little difference with VBO’s from quads. Though I believe quads are converted to triangles, so it makes sense to use triangles!
Yeah, quads are depreciated like most things in GL 3.2+
Think VBO’s should give speed increase and is way to go with modern hardware, same as using the programmable pipeline. Luckily I have some experience with this with using Direct3D!
192 blocks, not chunks. I wish I could get it running with 192^3 chunks. ;D
Anyway, I rewrote my world code, and now have 192x192x192 (blocks) in a static array using 200-300MB and taking up 10-20% CPU (it goes up when loading chunks), with infinite loading and the occasional 2-3 fps drop when loading.
It still keeps overallocating memory whenever I’m loading chunks, but at least it’s not as extreme as before. Unfortunately, I can’t find where the ‘memory leak’ is now that I’ve fixed the one with chunks. Not a memory leak, the garbage collector is a second too late and it bumps up the permgen. The memory usage is actually ~200MB.
Hello everyone.
It seems like (to me) that all of you have problems with Memory usage and Render distances.
Is it that hard to make 16³ big chunks and have ~8192 of them rendered with a render distance of nearly 0.5 Km and a RAM usage of 240 Mb?
(240 Mb because of Server/Client world chaching, the client alone only has a RAM usage of ~100 MB)
Here is a tip on how to speed up your voxel engine like heck-no-what:
Use 1 Dimensional Arrays and Integer ID’s + MetaData for your blocks.
This way here, is slow and memory comsuming:
class Block {
boolean isVisible;
}
class BlockGrass extends Block{
int GrassType;
}
class Chunk{
Block[][][] contents;
}
Do this instead:
class Chunk{
int[] blockData;
}
And use singleton classes to code the behavior of the blocks.
Like this:
class Block{
abstract void onRightClick(World world,int x,int y,int z);
abstract void onNeighborBlockChange(World world,int x,int y,int z);
}
class Button{
void onRightClick(World world,int x,int y,int z){
world.setBlockID(x,y,z,BID_BUTTON_ON);
}
void onNeighborBlockChange(World world,int x,int y,int z){
if(checkIfButtonCanStayHere(world,x,y,z)){
dropBlockAsItem(world,x,y,z);
}
}
}
If you didn’t understand something just ask as many questions as you wan’t.
Thanks Longor,
I’m changing mine now to be coded in C++ and using Shaders…
Will take on board what you have said and try the 1d array, I’ve heard that does speed things up a lot on other forums.
Not so sure about using a singleton pattern for blocks though…as there are many of these.
Here’s another tip:
Don’t switch the programming language to C++.
Why?
Writing a Voxel Engine in C++ is incredible hard because of memory-management.
Also, you won’t get any big speed improvements in C++, because Java is as fast as C++ with JIT, Runtime-Optimization etc.etc (i heard so).
The biggest problem in C++ are the memory leaks. Java has them too (i heard so), but they aren’t very big (i heard so too).
Oh, and you can use Shaders in Java too.
If you rewrite your Engine in C++, good luck!
Thanks again Longor,
I’m fine with C++ though, been coding in it for 16 years 
Not sure myself if Java is as fast, what with the JVM and all.
Ive started writing it in C++ now, just basically porting my java code to it. Got
my chunk class and block class sorted. I’m using FreeGLUT and FreeGLEW and OGL 3.2 (that is the highest my gfx card supports).
Thanks
Good luck with writing it in C++. If you could post a performance comparison when finished it would be great.
Mike
Will do, hoping to have something up by weekend…hoping!
Good luck with C++! You’re sort of lucky since you get more direct control with memory. Its important with something huge like this because if you don’t do it right, bad stuff will happen, but if you do do it right, then results will be outstanding!
I know what you mean.
Need to find a good C++ texture loader…next mission!