Hi!
After some research I concluded that PolyVox might be just the thing I'm looking for. I want to create a world similar to Minecraft in Ogre3D. I already looked into the Thermite3D source code. Now I have two questions:

1. Do you think it's a good idea to use PolyVox for a Minecraft-like world where you can "edit" the world? And what would be the expected FPS in Ogre when having a 256^3 voxel world for example? (maybe you can post your experiences and system specs for comparison)

2. From what I have seen in the Thermite code I'll have to use the code from the SurfacePatchRenderable::buildRenderOperationFrom function to get the PolyVox volume to render. Is this the best/fastest approach or are there any better ideas?

Thanks for your attention!

Hi, and welcome to the Thermite3D community. I've been following the recent thread on the Ogre forums so I'm glad you decided to come by and give PolyVox a go

Yes, I think that will work well. If you haven't already tried it, you should have a play with the Thermite3D Tech Demo. It's the demo from the YouTube video on the front page and is a couple of years old now, but that castle is in a 256^3 volume (though it only occupies the lower half). As you can see, it destroys hundreds of voxels at a time.

This demo was actually using the Marching Cubes surface extractor, where as I imagine you'll be more interested in the new 'cubic' surface extractor. This has not been optimised at all but still runs faster than the Marching Cubes version because it is a simpler algorithm.

That code is in need of a clean up and is more complex than it needs to be. It handles things like duplicating trianges to blend between material - this problem simply doesn't exist when working with the cubic surface extractor. Your best bet is to make use of the Ogre 'ManualObject' class, and then maybe HardwareBuffers at a later date.

Also, have a look at this tutorial and the Basic Example which comes with PolyVox.

Let me know if you have any more questions!

Hi, I'm currently making a "block cube Minecraft 4 teh win" game too. (No I'm not trying to copy Minecrat exactly.) So far I have implemented an initial prototype using PolyVox, specifically it's Volume and CubicSurfaceExtractor classes. I also did a quick hack just now hooking into Ogre's Paging and WorkQueue systems, doing this allows me to have paged world using Perlin noise (via LibNoise). So yeah, initial prototype has the Minecraft Alpha look.

Basically to get something work, you need to first define your volume. Then, use CubicSurfaceExtractor to exact a Surface. What I do after that is pass the Surface to another object which creates a Manual Object for me. Look up the OpenGL examples plus the source on SurfaceExtractor, the API is very light and easy to understand .

As for performance I'm happy with it. I have some hackish shaders thing which does SSAO, Bloom, and Spherical harmonics lighting and I get 90 to 100 fps (this is with infinite terrain streaming). If I turn everything off I get 160 to 200 FPS. Also this is for what I deem to be typical "Minecraft World", that is, without a lot of high frequency details in terms of world generation via Perlin Noise. (What I'm saying is you get good looking generate world. But frame rates goes to hell if you try to create a "crazy" world with very randomized block placements. Ex: On/Off air and dirt blocks. To be fair, I think this is beyond the intended scope of PolyVox.)

I may need to modify the PolyVox code for surface extraction though, in order to take into account better streaming.

Thanks for your reply!
Today I wanted to implement PolyVox into my game but failed due to the C++0x requirement. As you probably know I have to use some parts of Boost because of Ogre (which uses Boost). But (at least) with GCC Boost doesn't seem to work with C++0x enabled. To make a long story short, how can I build PolyVox without C++0x? I have not seen any build option whatsoever to disable it. Seeing that C++0x isn't really the standard yet I simply can't understand why I'm forced to use it here.

Hi,

If you have a look in 'trunk\library\PolyVoxCore\include\PolyVoxImpl\TypeDef.h' you will see there is some logic to disable the use of C++0x and use the Boost features instead. It does this based on the compiler available, and assumes C++0x support unless the compiler is VS2008 or earlier. You should be able to modify this to use the non-C++0x version for your compiler as well. This is the code I'm referring to:



However, this is largly untested as I use VS2010 for most of my development. So let me know if you hit any problems.

Thanks for the info! I saw that code part earlier but I failed to properly include the Boost-includes. Now I managed to compile PolyVox without C++0x, I just have to test some code to see if it works.
BTW, could you please update some of the documentation? I know programmers generally don't seem to like writing docs, but the Principles of PolyVox page for example is completely empty but is referred to in the tutorial. The second part of Tutorial1 - "Creating a volume" still has the sentence "Mention required headers", too.
I'll be back if I get anything done.

edit: And could you please get rid of these "#pragma region" things? By just using the Volume class once I get about 120 warnings just because of that (I'm using GCC).

edit2: I hope I'm not annoying you, just wanted to point out some errors I encounter while getting used to PolyVox. Some of the links in the tutorial to the Doxygen doc don't seem to work, like SurfaceExtractor. Also the createSphereInVolume function in the tutorial has only two parameters whereas the code makes use of three (like in the OpenGL example).

I mostly agree with you regarding the documentation, but I doubt if it will change much in the near future. It's simply a lot of work to write, and as you've noticed it gets out of date as the code evolves. I don't have enough time to do all the programming I would like, let alone keeping the documentation up to date...

I wasn't aware that these caused a problem with GCC - what is the warning mesage it gives? It was my understanding that if a compiler doesn't understand a particular #pragma then it should simply be ignored.

BTW I'm currently on Ubuntu 10.04 and I use G++ 4.4 and my command line options to enable C++0x is: "-std=c++0x". I haven't had any sort of problem with compiling.

As I understand it, AndiNo's problem with the C++0x usage was that it was interfering with the version Boost installed. This is unfortunately a problem with Boost but since there's quite a lot of overlap it's not very surprising.

In the past we did indeed have a compile-time option to use or disable C++0x features (or use Boost) but about 6 months ago we decided to make c++0x the default since all newer compilers are supporting the few features we wanted (see this thread for discussion). Since then we're had one or two people request to be able to turn off the C++0x features and so David reintroduced the 'hack' he explained above. It's unlikely that we'll switch back to using a compile-time option but we'll keep the 'hack' intact for those people who want to manually disable C++0x.

The #pragma region bits are used by VS to do things (I'm not sure what exactly since I only compile it in Linux). When I compile PolyVox in Linux with full warnings (I usually run at a lower warning level) I simply pass '-Wno-unknown-pragmas' to GCC to disable the warnings.

Finally, about the documentation: it's still a work in progress but if there's anything that you need help with feel free to ask in this forum. We'll try to move relevant information into the manual over time. And about the links from the manual to Doxygen, the incorrect link that you're seeing is caused by a bug in the piece of software that bridges between Sphinx and Doxygen (called doxylink) but that bug will be fixed in the next release of the bridge.

_________________
Matt Williams
Linux/CMake guy

I can fully understand that. However it is just my experience that a project is less likely being picked up by "outsiders" as they can't see through how the program works without a proper documentation. On the other hand I'm glad that there is at least an introductional tutorial. That's more than nothing

The warnings look like this:

and so on...

That's right. Ogre 1.7.1 currently uses Boost 1.42 but I get a compile error when trying to compile my project which uses Ogre with the C++0x features enabled (which seems to be a known Boost error). So I would either have to recompile Ogre with a newer Boost (which I try to avoid and I could only hope that the error was already fixed) or compile PolyVox without C++0x (which obviously was a lot easier).
I just think you might want to make the non-C++0x version the default (or at least support it) until C++0x is really standard.