I am making a game that utilizes a Voxel engine, that allows players to place and destroy blocks similar to Falling Sand Game however in 3d.
My Game:
I am now at the point that I really need to be concerned with speed. I have been trying to code with it in mind the entire
time, however the game is now just too laggy.
The main problem causing it to be laggy is how I am rendering the chunks.
As you can see in the picture the game draws using Voxels with textures.
How the game loads and renders a chunk:
Loads the 16x16x16 array of blockID's from HDD in binary (~4kb)
Using 3 For loops (x,y,z) it checks every block to see where it does not have a block touching.
If blocks were positioned like this: [ ][ ][ ] only the 3 top, 3 bottom, and 2 side faces would be drawn.
When it finds that it needs to draw a face the face is added to 1 of 6 of that chunks draw Queues.
(I have 6 queues for each Chunk: top, bottom, left, etc) This is so that I can draw different sides with different lighting.
Once it is done processing the chunk it will not have to reprocess it again until it changes.
The Baked mesh data is then sent the GPU using the code pasted below, when drawing each frame.
Does anyone know of a way I can speed this up?
Basically I'm just loading the blocks, baking the mesh, then drawing.
Is this the best way to do this?
Would really like to hear opinions.
Thanks,
CoderWalker
Chunks code for drawing 1 side of its containing blocks:
//Send a Baked Chunks mesh to GPU
glColor4f(lightTop,lightTop,lightTop,1.0);
glEnable( GL_TEXTURE_2D );
glBindTexture( GL_TEXTURE_2D,texAtlus.texture );
glPushMatrix();
glTranslatef(x,y,z);
//Enable
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glVertexPointer(3, GL_INT, 0, &vertexTop[0]);
glTexCoordPointer(2, GL_FLOAT, 0, &textureTop[0]);
//Draw
glDrawArrays(GL_QUADS, 0, vertexTop.size()/3);
//Disable
glDisableClientState(GL_TEXTURE_COORD_ARRAY);
glDisableClientState(GL_VERTEX_ARRAY);
glPopMatrix();
Code to read a chunk from HDD to memory:
chunk* file::readChunk(signed int x,signed int y,signed int z)
{
std::stringstream name;
std::string temp;
chunk* newChunk;
ifstream fileStreamRead;
////Open File to load from
name.str(std::string());
name << "save/" << world0->name << "x" << x << "x" << y << "x" << z << ".txt";
temp = name.str();
fileStreamRead.open(temp.c_str(), ios::in|ios::binary);
if (fileStreamRead.is_open())
{
newChunk = new chunk(x,y,z);
////Make the 2 pointers
char *pStoreMemory;
char *pLoc;
////Allocate memory
pStoreMemory = new char [16*16*16];
pLoc = pStoreMemory;
////Copy memory to file
fileStreamRead.read(pStoreMemory,16*16*16);
////read needed data from memory
//if ((unsigned char)*pLoc != 48)
{
//newChunk->empty = false;
for (int i = 0; i < 16; i++)
{
for (int j = 0; j < 16; j++)
{
for (int k = 0; k < 16; k++)
{
newChunk->position[j][k] = (unsigned char)*pLoc;
// /!\ Add to watch Queue if block has potential to move
switch (*pLoc)
{
case steam:
case smoke:
case water1:
case water2:
case water3:
case water4:
case water5:
case lava1:
case lava2:
case lava3:
case lava4:
case lava5:
case oil1:
case oil2:
case oil3:
case oil4:
case oil5:
newChunk->liquidBufferAdd(i,j,k);
break;
}
pLoc++;
}
}
}
}
fileStreamRead.close();
delete[] pStoreMemory;
return newChunk;
}
else
{
//cout << "/!\\ Cannot open " << temp.c_str() << "\n";
newChunk = new chunk(x,y,z);
generateChunk(x,y,z,newChunk);
return newChunk;
}
}
Using 3 For loops (x,y,z) it checks every block to see where it does not have a block touching.[/quote]
You should definitely multi-thread that (OpenMP is quite painless) or use a GPU language like OpenCL. That process sounds like it takes a lot of time.
#pragma omp parallel
{
#pragma omp for
for(int i = 1; i < size; ++i)
x = (y[i-1] + y[i+1])/2;
}
That loop would be scheduled up between all processors.
Edit: Also.. You could avoid some of those side checks entirely if you automatically eliminate one or three of them based on the direction you're looking (since they're all axis aligned). The logic to split that up might get annoying though. You could roll with a touching block function pointer that you re-assign based on the direction you're looking at in the beginning of each frame. Your code could stay pretty much the same in that case.
Edit: You should definitely build just one of those cubes with the three sides you can see and instance all of them instead of turning them into a mesh. Less buffer down-time.
Step 1) Profile. Profile. Profile.
Step 2) act on results of profile.
Also; I assume you AREN'T rebuilding the stuff to draw every frame? Chances are most things are going to be the same between frames anyway so you might as well cache the results and only update when something significant happens such as a block changing or camera movement beyond a certain threshold. Fastest work = work not done after all.
That's what I mean by the term baking.
Basically I am creating the mesh and texture data ONLY when 1)the chunk is loaded 2) the chunk is changed.
So when the frame draws I'm just calling a draw routine in all the chunks that sends thier mesh and texture data to the GPU.
So basically the only way to speed this up would be multithread it?
I have actually tried that before, only problem is that when it creates the mesh or "bakes" it has to check adjacent chunks.
Meaning that 2 or more threads would be reading or writing the same section causing errors aka Seg Faults.
The only way to fix this is mutex's. But if only 1 thread can run at once, then defeates the purpose.
Out of the box solutions?
Below is the code that Creates the mesh for a Chunk:
How can I make this smaller, faster and better?
--Alot is repetitive just for diffrent directions.
Before you can hope to speed it up, or get advice on speeding it up, you're going to need to use a profiler and actually tell us what's slow
Is it the GPU or CPU that's the bottleneck? Is there too much GPU work going on every frame? Is the game slow, even when no block updating is being done? Or is it just frames that need to update the baked meshes slow?
Get some profilers (for both GPU and CPU), and identify the actual bottlenecks. Only then can you hope to figure out how to eliminate those pieces or make them faster
Meaning that 2 or more threads would be reading or writing the same section causing errors aka Seg Faults.
That's not a SegFault. Yes, making that for loop parallel would be a bad idea, because of all the vector pushing. But nothing should keep you from at least processing the chunks in parallel, as they all seem to have their own vectors anyway.
You fail to mention WHAT is slow. Are your fps too low? Does loading take to long? Processing of chunks? Without knowing which part of an application is causing the slow downs it is really pointless to optimize anything and just hope to accidentally change the right thing. For low fps you should ask yourself: how much geometry do I try to render? How many state changes and draw calls am I using (hint about a huge b**tload more than necessary which may or may not be filtered by the driver). If nothing of that is the obviously problem you can try using VBOs instead of vertex arrays.
As for the code... well, it's code. Without context.
-What is block and position?
-What's the point of the calculations before that part?
-Why is the function called render and is it executed every single frame?
-Why is there so much pointlessly redundant code and setup in every single if-block? None of them has any reason to contain more than 4 lines.
-All the copy/pasted Add-functions seem to achieve the opposite of what functions are good for (reduce redundancy and copy/pasting) by not passing the vector as parameter.
-Code that really would benefit from these seperate functions is an endless copy/paste orgy (why isn't AddTop able to figure out which vertices to add on its own instead of painfully passing them one by one?)
Texture atlases are used to minimize the amount of texture binding, yet you happily call bindTexture 6 times per chunk, which in MC terms is almost 4000 times per frame when there is no reason to call it more than once per frame.
Edit: You should definitely build just one of those cubes with the three sides you can see and instance all of them instead of turning them into a mesh. Less buffer down-time.[/quote
It's funny everybody always points out how you can never see more than 3 sides of a cube, but fails to mention a concept to exploit it that wouldn't require either constant or at least significantly more updating of vertex buffers.
So let's first decide that we definitely do NOT want to update every frame, just because a shifted perspective means we might now see tops or bottoms previously unseen. That means we always have to draw at least 4 sides. Further more, for chunks directly in the line with the one the player is in, you can't skip the sides, because depending on the position either one could be visible, meaning you can only skip a single side (the one facing away). For the chunk the player is in, no side can be skipped at all.
So let's compare ignoring that and trying to use it assuming 25x25 chunks (seems to be what MC uses for far view distance):
Ignoring backfaces:
-When crossing a chunk border you load and update 25 chunks (loaded over the memory previously used by the 25 chunks that became invisible). You're done.
Exploiting backfaces (no top/bottom):
-When crossing a chunk border you load 25 chunks (again with the memory of the now useless chunks)
-You update the 25 chunks previously in line with the player chunk (which can now hide one more face per block)
-You update the 25 now in line with the player chunk (which can only hide the one facing away)
-You update the 25 you just loaded (which can also hide 2 faces)
Essentially you trade in rendering a few faces less (which is fast) for 3 times more updating (which usually hurts a lot). Unless polycount really turns out the issue, I'd stay far away from that.
That's not a SegFault. Yes, making that for loop parallel would be a bad idea, because of all the vector pushing. But nothing should keep you from at least processing the chunks in parallel, as they all seem to have their own vectors anyway.
You fail to mention WHAT is slow. Are your fps too low? Does loading take to long? Processing of chunks? Without knowing which part of an application is causing the slow downs it is really pointless to optimize anything and just hope to accidentally change the right thing. For low fps you should ask yourself: how much geometry do I try to render? How many state changes and draw calls am I using (hint about a huge b**tload more than necessary which may or may not be filtered by the driver). If nothing of that is the obviously problem you can try using VBOs instead of vertex arrays.
[color="#006400"]When the player stays in the same Chunk the FPS are fine >60. It only uses ~10% of my Geforce 8800GT to render the frames, so not bad at all.
The problem is when the player moves to another chunk.
The game slows because it's having to render all of those new chunks 11^3 chunks with (16x16x16 blocks each) for now. Goal would be 25.
As for the code... well, it's code. Without context.
-What is block and position?
[color="#006400"]Position is a 3d array (16x16x16) containing all the block ID's.
Block is a 1d array containing the texcoords, fluid amount, draw type, etc
-What's the point of the calculations before that part?
-Why is the function called render and is it executed every single frame?
[color="#006400"]Render is just a name I came up with, what It does is makes the draw data from the blockID array.
It is only called Once (when the chunk laods), then later when the chunk is modified.
Meaning Chunk load time takes a bit, however helps a ton when drawing.
-Why is there so much pointlessly redundant code and setup in every single if-block? None of them has any reason to contain more than 4 lines.
[color="#006400"]I origonally had just a addVertex() function meaning I would have to specify the verts.
I have the diffrent buffers so I can just glColor() before drawing each side for *lighting.
However this is a very poor method as each block can not have it's own light values.
Should I just have one array per Chunk?
You can send Verts, and texCoords using ClientSide, can you send lighting information?
Or is there a way to have the blocks that emit light (lava, fire) ?
-All the copy/pasted Add-functions seem to achieve the opposite of what functions are good for (reduce redundancy and copy/pasting) by not passing the vector as parameter.
[color="#006400"]If thier decalred as inline, will it take the same amount of time as now even if I pass the queue as a parameter?
However if I switch to one queue per chunk, then this is not even needed.
-Code that really would benefit from these seperate functions is an endless copy/paste orgy (why isn't AddTop able to figure out which vertices to add on its own instead of painfully passing them one by one?)
[color="#006400"]Again use to be an old function just addVertex()
[color="#006400"]However if I switch to one queue per chunk, then this is not even needed.
Arn't orgys a good thing? j/k
Texture atlases are used to minimize the amount of texture binding, yet you happily call bindTexture 6 times per chunk, which in MC terms is almost 4000 times per frame when there is no reason to call it more than once per frame.
[color="#006400"]Thanks a ton for noticing that!
Edit: You should definitely build just one of those cubes with the three sides you can see and instance all of them instead of turning them into a mesh. Less buffer down-time.[/quote
It's funny everybody always points out how you can never see more than 3 sides of a cube, but fails to mention a concept to exploit it that wouldn't require either constant or at least significantly more updating of vertex buffers.
[color="#006400"]Considering the verticies are only modified once this really isn't needed. I mean it barely uses the GPU now.
If I wanted I could even save alot of time and also send the normals to the GPU, however with my clipping routine it may not be worth-it.
So let's first decide that we definitely do NOT want to update every frame, just because a shifted perspective means we might now see tops or bottoms previously unseen. That means we always have to draw at least 4 sides. Further more, for chunks directly in the line with the one the player is in, you can't skip the sides, because depending on the position either one could be visible, meaning you can only skip a single side (the one facing away). For the chunk the player is in, no side can be skipped at all.
[color="#006400"]Chunks do not need to be redone at all unless modified.
So no calculation at all is needed. Just passing the drawData to the GPU.
So let's compare ignoring that and trying to use it assuming 25x25 chunks (seems to be what MC uses for far view distance):
Ignoring backfaces:
-When crossing a chunk border you load and update 25 chunks (loaded over the memory previously used by the 25 chunks that became invisible). You're done.
[color="#006400"]were good here.
Exploiting backfaces (no top/bottom):
-When crossing a chunk border you load 25 chunks (again with the memory of the now useless chunks)
-You update the 25 chunks previously in line with the player chunk (which can now hide one more face per block)
-You update the 25 now in line with the player chunk (which can only hide the one facing away)
-You update the 25 you just loaded (which can also hide 2 faces)
Essentially you trade in rendering a few faces less (which is fast) for 3 times more updating (which usually hurts a lot). Unless polycount really turns out the issue, I'd stay far away from that.
[color="#006400"]Yea, poly count is definetly the least of my worries.
I just realized this really is kinda hard to explain and a picture wouldn't really do it either.
I have the game online, all you have to do is make an account really quick
The game is on this page: http://webstrand.comoj.com/betatesting.php invide code: bl0ck 0 not o!
Also the reason for some checking position, and some checking using world0 is that:
When calling world0 it checks to make sure the coordinates are in the correct chunk, and position is direct access to the correct data with no validation.
Basically World sets the target to find which chunk pointer and which position in that chunk to use.
void world::setTarget(float x, float y, float z, signed int xChunkOffset, signed int yChunkOffset, signed int zChunkOffset)
{
//Sets the target of other functions
//tmpOffset (Chunk in Map)
//tmpPoint (Block in Chunk)
[color="#006400"]
The game slows because it's having to render all of those new chunks 11^3 chunks with (16x16x16 blocks each) for now. Goal would be 25.
So your visible world is 11 chunks in each direction? Why would you "render" them all (are we talking actual rendering or just the function misnamed "render") when only 11^2 chunks have been loaded? The only affected chunks are the loaded ones and their neighbors (which can usually also be only 11^2 chunks).
