A big content modder pointed out that was 2 years old and likely didn't apply anymore. While looking around recently for some info about cramming too much into one chunk, I came across an old post here. This led to my base slowing to a crawl FPS wise. So not wanting to build anything that wasn't claimed and wait around to get more claim chunks, I built it vertically, even after I had more claim chunks. The 1st time I played on a server way back, you could only claim one chunk at 1st. So, how do we get each chunk to only do 1 render call to correspond to ALL of the voxels it contains? That is explained in the next article about Display Lists and Vertex Buffers.I had always been told to spread stuff out. Now, when we want to render all the voxels in our world, we just call the render function for each chunk. Sitting at a level above the chunk class will be a chunk manager class that contains a list of chunks, I will go into a little more detail about the chunk manager in a future article, but for now it is important to know that a chunk contains multiple blocks and our engine will contain multiple chunks. For example being able to quickly say get me the block in the chunk at location (10, 5, 7) and being able to look into the array as m_pBlocks is very useful. It isn't vital that the voxel data be stored in a 3d array, but it is useful if we want to easily index the block data. But at this stage we can simplify the trade off as: Larger chunk sizes = less rendering overhead, but also larger chunk sizes = slower rebuild times.Ĭlass Chunk Īll this class does at the moment is create a 3 dimensional array containing the block data for each of our voxels. Later on we will do some number crunching and analysis on the chunk size and performance testing, to try and figure out a good chunk size. This is compounded if the modified voxel lies on the boundary between 2 chunks because then we will need to rebuild multiple chunk render data. Since we want the capacity to alter any individual voxel and turn it on/off as we please, we will need to rebuild the chunk render information each time a voxel contained in a chunk is modified. There is a trade off though with using chunks and this comes from the dynamic nature of a voxel engine. But having a good system to create and render chunks is vital to an efficient voxel engine. The size of a good chunk is dependent on a number of factors and really depends on what sort of things you want to do with your voxel engine, so it is really down to an individual case by case basis. This means that for a 256x256x256 block sized world, we would only have to render 4096 chunks, rather than 16,777,216 blocks, as we would have previously. A good place to start is to have each chunk represent 16x16x16 blocks. If we had some handy way to reduce the number of render calls, while at the same time having a large number of voxels rendered, this would satisfy our goal, this is where chunks come in handy!Ī chunk is a way to bundle up a number of blocks together and then only make a single call to the renderer for each chunk, this drastically reduces the rendering overhead or trying to render each block separately. The previous example would have real difficulty if we try to generate and render a voxel world of 256x256x256 voxels because we are essentially doing a render call for every single voxel that we want to draw, this is bad! A good voxel engine should try to minimize the number of draw calls made to the graphics card at all times. In reality we are going to want a voxel engine that can work infinitely in the X, Y and Z planes and just keeps going and going. It is probably fairly obvious that what we talked about in the first article works fine for a simple example, but has some major problems when we come to scale up our example to work with the sorts of voxel numbers that will be required to make a large, expansive world.
0 kommentar(er)
