'I've looked all over the internet and I can't find an answer. So here it goes.
1.Why haven't devs using voxel terrains used smaller cubes? When I say smaller I mean slicing 1 of Minecraft's cubes into 8x8x8 at the smallest(thats 64 cubes making 1 Minecraft cube)or 2x2x2 at the largest(8 cubes making up 1 Minecraft cube).
2.i read that Minecraft's voxel world is CPU heavy. Is that because of Java or programming style or just that voxel world calculations must be done on the CPU? Can it be helped by the GPU?
3. What are the limitations you can think of when making the cubes smaller?
Thanks in advance!!!
Voxel question?
Who says nobody's done smaller voxels? Delta Force used a voxel-based terrain system with much smaller voxels than Minecraft, and that goes back to 1998. I'm pretty sure there are earlier examples - and newer ones.
Minecraft is probably CPU-bound because it doesn't do anything all that interesting on the GPU; it simply does more work on the CPU to make the gameplay happen. A more graphically rigorous game could easily be GPU bound instead. Some voxel work can be offloaded to the GPU for sure, but that varies a lot by game.
The hardest part of shrinking voxels is storage space. You can do some tricks to compress them very effectively, but at the cost of complexity in rendering and simulation.
You can actually get pretty good results with moderately large voxels and a strategy like Marching Cubes and implicit surfaces.
Minecraft is probably CPU-bound because it doesn't do anything all that interesting on the GPU; it simply does more work on the CPU to make the gameplay happen. A more graphically rigorous game could easily be GPU bound instead. Some voxel work can be offloaded to the GPU for sure, but that varies a lot by game.
The hardest part of shrinking voxels is storage space. You can do some tricks to compress them very effectively, but at the cost of complexity in rendering and simulation.
You can actually get pretty good results with moderately large voxels and a strategy like Marching Cubes and implicit surfaces.
Why haven't devs using voxel terrains used smaller cubes? When I say smaller I mean slicing 1 of Minecraft's cubes into 8x8x8 at the smallest(thats 64 cubes making 1 Minecraft cube)or 2x2x2 at the largest(8 cubes making up 1 Minecraft cube).8x8x8 is actually 512 rather than 64, cubes have 3 dimension, and thus runs away at N^3.
This is also why size-reductions have such a big impact. Half the size of a cube in every dimension means 8 times as much CPU power and storage. There is a trade-off between acceptable CPU load and memory usage, and size of the cube, likely Minecraft is as big as possible against those limits. You can have smaller cubes, but then the displayed world gets smaller too.
I am not sure smaller cubes is actually desired there. I never played the game, but from what I have seen, the cubes must be clearly visible to understand what it is, even on low-end screens, for people with bad eye-sight. That imposes limits on what makes sense to display.
Probably they have.1.Why haven't devs using voxel terrains used smaller cubes?
There's nothing particularly special about the size of minecraft cubes.
In all likelihood all voxels are 'unit cubes' (i.e 1x1x1) so it's mainly a question of how 'big' your spatial units are.
I think it's just a design decision.2.i read that Minecraft's voxel world is CPU heavy. Is that because of Java or programming style or just that voxel world calculations must be done on the CPU? Can it be helped by the GPU?
More work could have been lifted to the GPU.
Or more optimisation effort put in to reduce the CPU load.
But these things weren't done and nor do they need to be done - it's a successful game as-is.
Mainly it results in increased storage and computation costs.3. What are the limitations you can think of when making the cubes smaller?
It's not insurmountable - might just mean you have higher minimum requirements. Or you need to put more effort into optimisations and fancy algorithms to handle the scale.
Author
Thanks everyone, you've definitely helped me answer my question! I'm learning c++ right now, so I have the power to make my code efficient.
Most of the battle in efficiency is played above the differences between languages. The language becomes important after you stop making mistakes in the higher levels.
All I've read says that Minecraft indeed has many design mistakes. Thus why mods that more-or-less re-implement parts of the game to make it run better are so popular.
On the other hand that should be at least somewhat encouraging, you don't need perfect code for commercial success, hell you don't even need to use the most widely used tools for the task at hand. Maybe the "next Minecraft" will be coded in PyGame, who knows, and there are plenty of popular GameMaker games. You don't need to start with C++, Direct3D 14 and coding your own physics engine.
EDIT: Whoa yeah, the more I Google the more I find snippets of Minecraft code doing stupid shit in the game loop. No wonder it runs like crap. Well probably in latest releases runs better, haven't tried. You can probably do better, whatever language you end up picking (unless it's PHP).
The hardware has been available for a long time. I made this:
for a game competition in a month, 7 years ago (I should note: I didn't make the 2D sprites but I wrote the voxel engine and the code to extrude the 2D sprites into 3D voxels 'tiles'). The video was recorded running on a 9800 gtx (very old card) and the graphics ran entirely on the GPU (it was just one large pixel shader, the only geometry was two triangles that covered the window).
Each level consisted of a map which was just a 256x128x64 16-bit 3D texture which indexed into the 'tile' data. Each tile was a 16x16x16 block. All the tiles for a given level/map were stored in a single 2D texture.
It was hardly optimized, just a tech demo mostly, since it was for a small game dev competition and we only had a month. But even back then hardware was more then powerful enough. There are many things you could do like paging in and out sections to dynamically load larger levels, to a hierarchical/oct-tree compression scheme, to old-school palette manipulations.
I would have loved to make a metroidvania style game with that type of voxel engine but medical issues prevented me personally from taking it further. There are a number of game that do use 'faux' voxel engines, where they use a blocky art-style to simulate voxel graphics. So maybe its enough that it looks like voxels. Always seemed silly to me to emulate voxels with polygons, since its generally faster and more efficient to render/manipulate them directly than to emulate them; but like in the case of minecraft the gameplay was more the focus than the graphics so it didn't really matter.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
