Hot answers tagged

24

Storing the blocks as the positions and the values is actually very inefficient. Even without any overhead caused by the struct or object you use, you need to store 4 distinct values per block. It would only make sense to use it over the "storing blocks in fixed arrays" method (the one you described earlier) is when only a quarter of the blocks are solid, ...


14

This is achieved by interpolating ramps between cubes of different height. When you have a scenery like this (seen from the side) # #### ## ############ you would add polygons to make it look like this: /#\ /####\ /##\ ############ An algorithm to calculate these ramps is the marching cubes algorithm. When you want it to be even more beautiful, ...


12

A* would work just fine. Path finding is what you want, finding the shortest path is just as fast (or faster) than finding any path at all. In this situation A* is likely the most suitable given you have a start and end point. this means you have the added heuristic to speed up the search. With A* typically the first path you find is the shortest, so it's ...


10

Terrain generation falls under the form part of development. It's an artistic endeavor, so I'm not so sure there's a correct answer. However, I can try to tell you about the knobs you can turn to get different results, and it'll be up to you to turn them to get the result you want. Compress/expand: You can stretch or shrink the noise along a specific axis ...


10

You don't need a new way of storing them, just just need a new way of accessing them. Storing the data in lists in the chunks is fine. You just need a way to index into them at the world level. The world should contain a list of chunks currently loaded, and the chunks contain lists of voxels. Each chunk should be the same size (contain the same volume of ...


10

The transvoxel paper is a fairly in-depth work, discussing a variety of topics on how to create an entire voxel terrain system, including an overview of marching cubes, how to fix the ambiguity problem, vertex sharing, triplanar texturing, and texture splatting. The area you are interested in is covered in chapter 4, Level of Detail. It introduces 512 new ...


9

If you're prepared to do some pre-processing and eat the storage cost, then partitioning voxels into connected groups at build time gives an obvious answer to 'is there a path at all'. There is a path between two voxels if they're in the same group. The problem with that obviously is that you have to store group information somewhere, and that depends on ...


8

The first thing I didn't understood was if transvoxel is a modified marching cubes or a second layer that modifies the work of the marching cubes. My reading of the paper is that Transvoxel's novel addition is a kind of "adapter" to bridge regions of voxels at different resolutions. Let's say you have an area of very dense voxel samples near your ...


8

It is not simply Marching Cubes With marching cubes, a block would expand into the surrounding ones. In fact, with the default configurations for the Marching Cubes algorithm the result is a Rhombicuboctahedron, depicted below. That is the result of considering all the eight vertices of a cubic block set as input for the marching cubes algorithm. It is ...


7

Octrees exist to solve exactly the problem you describe, allowing dense storage of sparse data without large search times. The fact that your voxels are the same size just means that your octree has a fixed depth. eg. for a 16x16x16 chunk, you need at most 5 levels of tree: chunk root (16x16x16) first tier octant (8x8x8) second tier octant (4x4x4) third ...


7

Nice idea by the author. From experience... High vertex counts aren't that much of a problem (100Ks, millions even). Dealing with complex UV mapping is far more so. Sometimes it is worth staying closer to the actual description of the surface (i.e. the backing 3D array), than optimising yourself into a place where it's not as easy to change the mesh when you ...


6

Yes. VertexPositionTexture is a 20 byte structure. With over 2 million of them, they take up around 43MB of memory. Which gets copied around a bit on the CPU, and then transferred to the GPU. Each frame! There are almost certainly going to be other optimisations you can pursue. I see, in the comments, merging adjacent faces is suggested. I think Minecraft ...


6

I had the same problem with a recent game I'm working on. I guess you are using one big texture with all the block textures in it (like Minecraft does it)? If so these white pixels appear because of rounding errors in the shader that lead to "empty" texture spots. This occurs even if you do not use texture interpolation (which is the case with your game ...


6

If you build your meshes more carefully, ensuring you are reusing vertices wherever possible, you should be fine: That is, you must not duplicate vertices per face as then the GPU rasteriser will see them as two discrete objects and sometimes fail to rasterise the in-between space (thus defaulting to the GL's clear colour) due to floating point limitations; ...


6

There are many more things to the game that will be taken care of by a game engine than just the management of meshes. Control input, sounds, lighting, GUI, meshes other than the terrain, camera, etc. So the benefit of using an engine comes from all the other features it provides. If you're going to be writing a voxel engine anyway, might as well have ...


6

There are two obstacles you need to deal with in order to achieve similar quality like the one in the image, the first is artistic and the second is technical (memory, processing). First I assume that you already solved your artistic problem, you can make the models, the art and the shaders etc. (Partially because I can't answer art problems) The major ...


6

Remember, the whole point of using a chunk mesh is to try to render just the outside skin, and hide all the internal detail inside the chunk where we can't see it. If we generate a whole cube (all 12 triangles) at every occupied position, then we might as well spawn it as a separate mesh and at least hope GPU instancing saves us some work - otherwise we're ...


6

If you don't want a 2d array of chunks indexed by world position because the player might get very far away from the world origin or you might have negative indexes, then it might be worth to look at other data structures. A hash table with the coordinates as keys A 2-d tree which you auto-balance so that the root is always at the player (can also be useful ...


6

Quoting the meshing page you link: It isn’t too difficult to modify the code deal with either multiple block types or different normal directions. What you would do is modify the array called “mask” in the code to store an integer value which encodes the type of each block. You’d need at least 1 bit for orientation, and then you could use the rest to store ...


5

There's a good source for that here Currently the free ones (with source) are: Infi-Chunk Stacker CubeField MetaBalls ChunkRenderer Voxel Terrain Marching Squares 2D Free Terrain 3 Terrain Generator Cubic World


5

Another way would be to procedurally generate your textures. This approach comes with its advantages and disadvantages. Most important tradeoff is that you can't draw your textures in an editor but have to code them using noise functions. The huge gain in your situation is that you can texture your terrain completely orientation independent. This is done by ...


5

Most perlin noise algorithms will allow you to retrieve the noise value at any given location, with something like noise(x,y,z). This makes it fairly trivial to generate noise on a chunk by chunk basis. All you need to do is pass the global position, instead of the chunk position. for(int i = 0; i < CHUNKMAX_X; i++) for(int j = 0; j < CHUNKMAX_Y; ...


5

You aren't resetting the modelview matrix, so each cube's translation is added to all further cubes. Use glPushMatrix and glPopMatrix around each translate-and-call.


5

Marching cubes is an algorithm for polygonizing an implicit surface - i.e. one defined by an equation of the form f(x, y, z) = 0. You can evaluate any function f(x, y, z) you like, and the algorithm tries to make a polygonal model of the surface formed by the points where the function is zero. I haven't looked at the source code, but from the screenshot, ...


5

I would cheat, and represent each planet as a flat plane in terms of "cubelets" and graphically wrap the plane around the sphere for distance POV. This will work as long as you don't have tiny planets (IE: from the surface, the planet is big enough to appear flat). The other option is to simply construct the entire planet out of cubes, including the ...


5

Do you need to have every single chunk (presuming you're using chunks) in memory at once? Some will be occluded - particularly underground - or behind mountains etc. Lots will probably be just air/empty and so could be marked with a flag. Also you could use a LOD octree or similar structure to try keep the detail currently visible inversely related to the ...


5

Short Answer The Octree is favoured in games and rendering, because It supports visual level of detail, sensibly. It provides extremely tight compression of sparsely-populated spaces. (c.f. SVOs) At its lowest level it matches the uniformly-sized / -placed cells required for a voxel world. Other 3D accelerative structures may not do this, as explained ...


Only top voted, non community-wiki answers of a minimum length are eligible