Hot answers tagged

107

With regards to Java vs C++, I've written a voxel engine in both (C++ version shown above). I've also been writing voxel engines since 2004 (when they were not vogue). :) I can say with little hesitation that C++ performance is far superior (but it is also more difficult to code). Its less about the computational speed, and more about memory management. ...


23

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, ...


21

When I had this problem while working on my Cubes, I found the paper "A Fast Voxel Traversal Algorithm for Ray Tracing" by John Amanatides and Andrew Woo, 1987 which describes an algorithm which can be applied to this task; it is accurate and needs only one loop iteration per voxel intersected. I have written an implementation of the relevant parts of the ...


15

From your diagram, it looks like the geometry you're constructing contains T-junctions - places where a vertex of one triangle is supposed to lie exactly on another triangle's edge (resulting in one edge meeting another in a "T" shape). Due to the limitations of finite-precision arithmetic, the vertex usually cannot be guaranteed to meet the edge perfectly ...


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 ...


11

Castle Story looks like this due to technical constraints: Were there to be a heightmap per each voxel in the entire volume, rather than only a heightmap per each surface voxel, storage cost would be vastly greater, on the order of O(n^3) which can be prohibitive, as opposed to a more favourable O(n^2), where n is the side length of a cubic voxel space ...


10

Due to the sheer volume of data in your average voxel world, it will be challenging to draw much geometry with your approach, before hardware limits are reached, without some kind of spatial subdivision approach. You also need to be highly efficient in packing data at the bit/byte level. Method: RLE Enter Run-Length Encoding (RLE) compression as a popular ...


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 ...


9

There are a couple different ways to store the data for a game with blocks like Minecraft. The way I believe Minecraft does it is breaks the world up in the 16x16x256 Chunks. The chunks around the player are loaded into memory when the player starts the game, then a background thread loads more as you walk around. Here is a video that shows it: http://www....


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

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

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 ...


7

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 ...


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 ...


6

1) The non-scary way to do 90-degree rotations is to swap a set of axes, and negate one of them: Rotated along x-axis: swap Y/Z to Z/-Y (a,b,c) -> (a,c,-b)


6

I think Minecraft is almost a genre, at this point. There are many success where people are taking the core concept adding something new. But you have to find the core mechanic that differentiates you from the original.


6

Right now you essentially have a 2D plane, or at least a thick sheet of cubes. That's your map. You want to take that map and wrap it around a sphere. An easy way to do that is to convert your wrapping coordinates into spherical coordinates. Wrapping the same way you would with your current world. To avoid all the nasty warping effects you get from this ...


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

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

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

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 ...


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 ...


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