|Fuzzycraft - not minecraft!|
It's an interesting problem; sure it's just a bunch of cubes - but who wants to stop at a few thousand of them? You want a massive world where you can potentially see tens of thousands of theses blocks at a time. And due to its nature you're left without many of the techniques often used to optimize terrain rendering.
Sounds like a good opportunity to get a little more comfortable with OpengGL. Enter fuzzycraft-webgl; poorly textured terrain in all it's blocky glory! This ended up being horribly slow. More on that in a bit.
Trying out minecraft; the terrain seems to load very slowly. With my fairly high-end GPU I'm pretty sure OpenGL isn't the bottleneck here. Generating what blocks go where isn't slow either. (Test it by toggling the graphics options between fancy and fast; you can still see the chunks appearing one by one, oh so slowly) The only thing left is the process of building the geometry to send to the GPU.
I wanted to see if I could do better. Coffeescript was something I was wanting to try out and I always like to see how far WebGL can go. Turns out, getting good FPS was next to impossible with larger worlds. Generating the blocks of geometry to send to the GPU wasn't too bad; although to be fair, I had 8 cores chewing through it via web-workers.
Really, using OpenGL just works best in C. I was confident that it was possible to get it fast; both generating and rendering it. So I re-wrote it all in C++. There's really not a whole lot to say other than yes, it is very possible. There are still a few optimization I could do to make it run even faster. I may do them someday; but for now I've satisfied my curiosity.
So why does minecraft take so long to get those chunks of vertices to the GPU? I don't really know. Part of me wants to decompile minecraft's bytecode and find out. But I work with way to much Java as it is at my day job; and honestly, it's not a language I adore.