Wow thanks for the help, that's very kind of you!

Here's what it looks like:
I'm using this texture (just for testing):


Look from far away:


Close-up look:


Most of the time the texture is either just yellow or completely distorted, however it works for one specific direction and it's opposite side. In this case the picture is drawn some hundred times but much too small.

Just in case the fault is on my side here's my code for creating the ManualObject:


Again thanks for the help so far!

It looks like you are copying the vertex positions from the SurfaceVertex to the ManualObject, but you are not copying the vertex normals. You need to call PVWorld->normal(...).

The shader code uses the surface normals to decide which face it is currently drawing to.

You were absolutely right
Now all faces of the cubes are drawn correctly. However the problem remains that each cube side has my texture repeated thousands of times. Do I have to change the shader to rectify this or do I have to call PVWorld->textureCoord(...), too? From what I understood the texture coordinates are not taken into account when using shaders, but I could be wrong. I scaled my ManualObject with the factor 100, could that cause that problem?

This is something I have thought about as well but there are a few catches. Firstly, there is more to a vertex than it's position - there is also the material ID and the normal. Actually I'm half-thinking to remove the normal it can also be generated in the pixel shader and will allow for more vertex sharing, but that's really a seperate discussion. The point is that you can have several vertices with the same position but other different properties.

Secondly, it's not good in all scenarios. If someone wants to use PolyVox for the simplest possible task of generating one mesh which corresponds to the whole volume then they have a rather huge vertex buffer.

Although the above sounds negative, I do actually think the idea is interesting. Maybe you can also take it further. Do you actually need the vertex buffer at all? If you know you have a region of 32x32x32 and an index in the index buffer of (for example) 4096, then you can actually deduce that this would correspond to a position of (0,0,4) (I hope I got that maths right). Maybe in a geometry shader or something.

However, for now I won't be taking that route. But I will try and spend some time over the next few week improving the performance of the CubicSurfaceExtractor. I am sure I can make the meshes many times smaller, but I don't know so much about the execution time. I might me bounded by memory access - i.e. the time to simply read each voxel from memory. I'll let you know how I get on.

The shader is using the pixel's world-space position as a texture coordinate. So yes, the scaling will make a difference. You can divide the texture coordinates by an amount to make the textures larger. For example:



I didn't try compiling that but that's the idea.

Bingo.


BUT:


The ManualObject is at Position 0,0,0. But the texture on the cubes is shifted by a constant offset, how do find out how much this is so I can change it in the shader? Or better, how can I avoid that entirely?
Again thanks for the continuing support!

Try adding 0.5:



It's because the origin of the voxel is in it's center, rather than it's lower left corner.

Victory is ours!


It's clear that you're a good amount of time ahead of me in shader experience. I would have not achieved this in this short time without your help. I'll remember your name for the credits if my game gets finished Thanks again!

I'll try to figure out how to use the shader with a texture atlas. If you however have a shader at hand that does something similar I wouldn't say no My searches so far have not brought up a shader like this.

Great work!


Thanks. It's partly just experience, and partly that I have the advantage that I wrote PolyVox so I know exactly how everything works



Have a read of this:

Improve Batching Using Texture Atlases

Note that you don't have to use texture atlases and they have some significant problems with linear texture filtering (I assume this is why MineCraft uses point filtering).

An alternative is to simply split up the SurfaceMesh into several different meshes - one for each material. You get more batches (so slower) but you might find it easier. The surfaceMesh class has a function called 'extractSubset' which you might look into. It not that well written and I can't be sure it works with the 'Cubic' surface extractor, but it's a starting point.

I already thought of that. However the way I imagined things wouldn't work with that I think. If I want to display a 256^3 voxel world consisting of 512 32^3 volumes, that would make 512 batches. In the worst case every volume has some 20 different materials in it, that would result in a batch count of 512*20 = 10240. At least if the whole world is in the field of view. But even if I can only see a part of the world this would still mean a batch count of about ~2500. I'm not sure if I should try that...