Hot answers tagged

106

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

You mention doing frustum culling on individual blocks — try throwing that out. Most rendering chunks should be either entirely visible or entirely invisible. Minecraft only rebuilds a display list/vertex buffer (I don't know which it uses) when a block is modified in a given chunk, and so do I. If you're modifying the display list whenever the view changes,...


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

Simplest option is to grab the lighting from the block your standing on (or if possible the lighting on the block in the air that corresponds to the block the pickaxe is in) and use that for lighting the pickaxe/player. Or in other words, calculate the lighting for the pickaxe as if it was a block in that position. To get more realistic shadows you would ...


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

While I appreciate Kevin Reid's answer, it was at a level that was higher than what my question was asking. Understandably with out knowledge of Bullet Physics, it'd be hard to answer this question. I got this working and have an answer that is specific to Bullet Physics. Along with extending the RigidBody class like I mentioned in my question. I also ...


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

There are already a lot of resources. You can start with this post on gamedev: How are voxel terrain engines made? These answers may be closer to your question: Voxel heightmap terrain editor Most of the noise functions discussed here are fine for real-time - some can generate a million values a second. I'm not aware of a C# implementation, but what you're ...


6

Ok, it's pretty simple. The good bit is, once you fix this stuff it'll perform a couple of orders of magnitude better ;) The first rule is that for functions that are frequently used and perform read operations, you can't afford to allocate memory if you want your game to actually function or perform at an interactive level. You can't afford to allocate a ...


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

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

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


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