(sorry, i included more questions here which are not only related to the subject)
Q1:
Are there already any example code for generating uv's for the surfaces generated by "CubicSurfaceExtractorWithNormals" ?
I am not (yet) using shaders, so i need the uvs to pass to opengl.

A: i resolved it myself, used the normals (6 cases) to set the uv's

Q2:
Also, if the hardware supports it, wouldn't it be better to generate quads (4 vertices) instead of 2 triangles (6 vertices) ?

Q3:
I am not very familar with opengl (i am even using airplaysdk.com which is based on opengl es). Do you guys call surfaceExtractor.execute() each frame or only if something has been changed?

Q4:
What do you guys do for VSD (visual surface determination) and culling out geometry? I understand that PolyVox supports "regions" but i need to relate it somehow to the camera (frustum,...). Any code/alogorith examples welcome!

Q5:
I understand that using one volume should be prefered, but is it still a good idea to use multi volumes for objects like tree, etc. which can then be rendered with smaller cubes?

Glad you solved it because we don't have an example of this. As terrains get larger it's good to compute the texture coordinates in a shader because otherwise the amount of per-vertex data is quite large (and it also makes it harder to merge faces).



According to this page (http://www.opengl.org/wiki/Primitive#Quads) quads have actually been deprecated on OpenGL. Implementations which still support them probably do it by rendering two triangles anyway.



For a real application you would run the surface extractor once for each region on startup and load the mesh on to the GPU. After that you would only call the surface extractor for a region if something has changed.



I haven't implemented anything myself but most 3D engines will perform this for you (not OpenGL though). For example you attach the mesh geomentry to a node in your engines scene graph, set a bounding box, and the engine will perform view frustum culling for you.

When using OpenGL you will have to implement this your self by performing an intersection test between a bounding box and the view frustum. I'm sure there are OpenGL tutorials which will explain this.

But to be honest I wouldn't bother with that for a while... modern GPUs can handle a lot of triangles and you'll probably run into other limitations first.

Excellent question... I haven't given much though to worlds which have different size cubes. But if you need you trees to be editable in game (like your terrain) then I would say that you should indeed use separate volumes for these. You'll be doing so experimentation/research here

Thanks for the answers!



So one purpose of the regions are to pre-cull geometry out on large volumes? I am trying to understand for what the regions are good for.

The idea of regions is that they let you specify for which part of the volume you want to generate a mesh, and therefore you can have a world built from many small meshes instead of a single large one. There are two main benefits from this:

• It is possible to cull individual meshes so that you can only have to render the parts of the volume which are currently visible.
  
• When a voxel is modified you need to regenerate the corresponding mesh, and this is faster if the meshes are smaller.

However, you can't make your meshes really small because then you will have too many of them and this can also be a bottleneck (probably you can render just a few hundred meshes each frame).

I am still trying (prototyping) to find out how PolyVox could best serve for me.
Right now i am using it as sort of mesh generator.
Let me first explain what i want to achieve:
my aim is to build a game like "DungeonMaster" or "Wizardry 7". So my idea was first to just create the level out of blocks and render them. So each block is a wall (or floor/ceiling).
Then i saw some voxel examples and the idea was born to have a level built out of many small blocks, e.g. a wall will be built out of 8x8 small blocks. This comes "Minecraft" very close.
Now i am thinking about how to build the levels regarding SimpleVolume/LargeVolume, regions and still being fast since i want to have this on mobile platform.

- What is the max size for SimpleVolume? When should one switch to LargeVolume?
- Are there any good examples for LargeVolume?
- If a level is static then caching the extracted meshes and reuse them is better than extracting it each frame?
- a region is always rectangular? I am asking this because if i would go to cull out early voxels based on camera and view distance then it would be handy to define a refrence voxel (camera position) and only extract voxels which are within a certain distance.
But maybe i am completly on wrong track here, i am not sure if i am using the right technologies together.

The limitation of SimpleVolume is that it doesn't perform any compression, and so you should switch to LargeVolume once SimpleVolume is using too much memory. For example, if your volume is 512x512x512 voxels and you are store an 8-bit material identifier for each voxel then the total storage in bytes is 512x512x512x1 = approx 128Mb. This is no problem on desktop but too much for mobile.



Only the PagingExample which comes with PolyVox. But I'd strongly recommend you just work with SimpleVolume until you have your basic system working and then scale up when you need to. The interface is basically the same so it is easy to switch, and LargeVolume is undergoing some active development at the moment (on this branch).



If your level is static then you may not need to use PolyVox at all... it probably easier just to model your level once in Bleder or some other 3D package and use it from there. But if you do use PolyVox then you shold only re-extract when the volume data changes and not every frame.



Yes, a region is always rectangular (well, a cuboid really). You can split you volume into regions, and then compute the distance from the centre of each region to your camera. Based on this distance you can decide when to extract a region and when to draw it.



I think it does depend if you need your block-based world to be dynamic or procedurally generated. A game like 3D Dot Game Heros looks like it is made of voxels but actually they just have regular geometry with a 'tile' texture stretched over it (and so it isn't dynamic). You have to weigh the extra complication of a dynamic/procedural world against the game play benefits.