In the Ogre3d forum, when I search for "minecraft", I see lots of references to PolyVox. As far as I understand the topic, the common tenor is this:

* placing lots of textured cubes into a scene kills performance, even with an octree

* having 16 different shades of lighting increases "batch" runs, and therefore kills performance too.

* better is it to not render cubes at all, but to use PolyVox or something else to extrace the faces of the cubes, triangulate them and render just them.

The other day I stumped upon "Minetest", http://celeron.55.lt/~celeron55/minetest/. This program is quite special, compared to all the other minecraft clones I saw before:

* it's open source, not just a imgur or youtube demo, see https://bitbucket.org/celeron55/minetest/overview

* It has "endless" terrain with on-the-fly procedural terrain generation.

* It displays cubes from a long range as well. Climb to a hill and look near the horizon. You can see veeeery far.

* it can display a huge landscape, even non non-3D-hardware. I have a Pentium 4 PC with 3 GHz without any NVidia/ATI/whatever hardware and using software Mesa or the Irrlicht-Software renderer I still 10 to 20 FPS, depending on which rendering engine of Irrlicht I used.


Unfortunately, my 3D programming and math skills are at best mediocre. I can't really say that I already understand what Minetest does with it's cube. But I'm quite confident that there is no "marching cube" or similar surface extraction algorithm used.

So the question is: how/why is this beast so fast?

Are you sure it's view distance is huge? How do you know? I downloaded the latest version, looking at debug text, it says render_distance 300, so I assume 300. Playing around with it, I don't think it's render distance if that far at all. When I make a stack to like 300 units above ground, the ground disappears into the fog. So I'm pretty sure viewing distance is 300.

As for no height limit in the Y. This is also possible in my game, I just need to enable 3D paging. My game is fully capable of doing 3D paging (Ogre's paging system allows this). It's just I have it turned off at the moment.

I'm pretty sure Minetest also does the "marching cube" thing as well. Why do I think this? It's render distance is not that far (can you link me to the picture where the far distance is set?). It doesn't use any shaders. If it used some crazy ray marching thing on the GPU then it must uses some sort of shaders, or maybe OpenCL, or direct compute. Obviously it does not.

I will open source my game once I'm done with it, I don't think most people will care, or that it's that good. But I'm for open source. Why don't I open source it now?

This is what Minecraft with long viewing distance looks like:

http://www.youtube.com/watch?v=iYjK5xsg-xI

I had a play with it and climbed to the highest point I could find:



If you actually count the blocks in that image I don't think it's that big - probably the visible world is only 256 blocks wide? Certainly not more than 512. As you go to the edge of the map it generates more (hence they can call the map infinite) but at that point it will stop drawing blocks on the ther side of the map.

I'm pretty sure they do use some kind of surface extraction approach, though maybe they have improved the algorithm to generate less triangles than PolyVox currently does (it needs some work here). But I think I've seen bigger maps than that made with PolyVox (beyzend - I can never find your videos on YouTube when I want them!).

@David Williams

His channel is at http://www.youtube.com/user/Beyznd

I was probably confusing the classic minecraft with the current one. I've to agree that the video you posted shows things that are wide in the distance.


@Beyznd
As for "marching cubes" or not ... I can't see any edge or other lookup table in the source.

I don't think the video beyzend posted is actually from Minecraft - it's someone else's minecraft style renderer using minecraft data. Very impressive though.


It won't actually be marching cubes (as that generates a smooth rather than cubic surface) but it will be a similar surface extraction algorithm I would imagine. In our CubicSurfaceExtractor we don't use lookup tables either, just logic to decide where the triangles should be.

marching cubes are used for smooth sirface extraction. for blocky extraction you use a different technique, but the idea is similar. Polyvox itself does not use marching cubes when you use the cubic surface extractors.

Oh please please do. My mouth waters every time I watch your'e vids. Just not something copyleft . Either way, I admire your work. Yours is one of the best MC style engines I have seen.

_________________
irc://irc.freenode.net/#polyvox

If you open source your project, I'll try to get on the train and use your source for my building simulations
I am still wandering about water physics though... So little time those days!

It will take at least another year. hehe. By then I'll have to start looking for a job if I don't get some sort of funding. If by some miracle I do get some funding in the meantime, I will most likely also release it. It was open source (MIT) then I had to take it offline for a bit. I already posted the link to the old source. It's around here somewhere. I'm also a little bit embarrassed by it. If the project were an internal one I wouldn't care as much, but to the "public" I'm kind of like man...