If I want to do day/night cycles, I can just do color grading, or IĬan recompute the scene as the sun gradually changes. I pass in a single color and a vertex position. People tend to forget is that the more data you pass to the GPU, the Pass as little data to the video card as possible. Lighting means that I don't have to pass in the normals for the Lighting (in screen space, as a post-process), but baking in the ForĮxample, I bake the lighting into the scene. Wherever you can, you should compute data once. To answer the rest of your question, there are many things you can do to improve performance. I have tried out various techniques and I can get about 100x faster chunk generation using various caching and instancing techniques. While chunk generation might seem slow, keep in mind it is generating 3D voronoi diagrams volumetrically, calculating surface normals, lighting, AO, and shadows on the CPU with brute-force methods. You can see a poorly optimized, older version of my engine in action here (EDIT: newer version here). There are many trivial/edge cases, but in general you can expect Java to run about 1.75-2.0 times slower than (well written) C++. If you just want to write a game without bleeding-edge performance, Java is definitely acceptable (as evidenced by Minecraft). If performance is your highest priority, go with C++. However, you should think about your goal. Hands down, when you are allocating/deallocating as much data as whats in a voxel world, C(++) is the language to beat. Its less about the computational speed, and more about memory management. :) I can say with little hesitation that C++ performance is far superior (but it is also more difficult to code). I've also been writing voxel engines since 2004 (when they were not vogue). With regards to Java vs C++, I've written a voxel engine in both (C++ version shown above). How would you improve performance in a large voxel-based world? I guess there is no right answer to this, but I would be interested to see peoples' opinions on the subject. Keep the block object themselves lightweight, so it is quick to add and remove them from the trees.Use some algorithm to work out which blocks can currently be seen, as blocks closer to the user could obfuscate the blocks behind, making it pointless to render them.
Use a tree of some variety ( oct/ kd/ bsp) to split all the cubes out it seems like an oct/kd would be the better option, as you can just partition on a per cube level not a per triangle level.I assume that to make this sort of world perform well, you would need to: As it is a true 3D world, where a block can exist in any part of the world, it is basically a big 3D array, where each block in the world has a type (i.e BlockType.Empty = 0, BlockType.Dirt = 1, etc.) However, this got me thinking about the best way to manage large voxel worlds. Java, as spatial partitioning and memory management are faster in native C++.I assume Minecraft's slowness comes from: I found Minecraft's marvelous large worlds extremely slow to navigate, even with a quad core and meaty graphics card.