Is there any situation where the generated mesh from PolyVox would contain materials not found in the volume?

I'm populating a volume, and all my voxels only ever have material IDs 0, 1 or 2. Yet somehow some of the vertices generated by polyvox are coming out as material ID 3. It seems to be occuring in areas where there is a transition between 2 materials.

Here's a screenshot. Grass 1, Rock is 2, sand is 3. 0 is "error" material for things that shouldn't be drawn. I'm only populating my volume with grass and rock (1s and 2s), I have checked this and I know for 100% sure this is the case. Yet as you can see, Polyvox is producing ID 3. In the background you see some random patches of sand also, they should be rock. I've double checked everything, the 3s make it into the system as soon as I execute the surfaceextractor.



Any thoughts?

how are you getting your indices from the SurfaceMesh? could there be any float casting issues?

Actually I think this is indeed a bug in PolyVox. In the old days PolyVox only supported material volumes (no density), and zero was considered to be empty space while any other material id was solid. Therefore, when generating a surface between two voxels it was guarenteed that one of the voxels would be zero.

I needed to assign the material which was not zero to the vertices, and rather than using if-else statements I could just OR the value of the two voxels (knowing that one of them was zero). However, I don't think this logic makes sense anymore since we have the densities but it has been left in. A logical OR of '1' and '2' would give your value of '3'.

I'll move this to the bugs forum and get it fixed. Of course it could still be something else (like rounding errors... it's a bit ugly that PolyVox uses floats for the materials) but I'll start wth the logical OR.

I've always wondered, why are the material indices floats to begin with?

I'm not exactly sure which GPUs support integer types but I don't think it's all of them. I'm sure that DirectX10+ hardware will support them for indexing texture arrays, etc, but I don't know about older hardware. Whereas I do know that floats work everywhere.

However, PolyVox could (and probably should) still output integer materials and leave it up to the user to cast them to floats if necessary for their particular target hardware. The reason it doesn't do this at the moment is that it is currently possible to do a direct memcpy() of the index/vertex buffers which is theorectically faster than iterating over each vertex and copying/casting them one at a time.

In practice, many people are not doing a memcpy() anyway as they are using things like Ogre::ManualObject. Also, for some applications you want to split the mesh or duplicate triangles so in this case you are iteratng over the data anyway. I think in the future the data type will get changed to int rather than float.

I iterate over my vertices (several times since I smooth the mesh and other stuff), so I don't use memcpy. I have a seperate VBO (using OpenGL) for positions and normals so I kinda have to.

Thanks for looking into it. I did notice some OR operations going on when I looked over the source code briefly but didn't really understand what was going on.

I know you're a busy man, and I don't mean to be rude, but I'm on a deadline - what kind of timeframe are we looking at?

I think you can fix this quite easily yourself. If you look in SurfaceExtractor.inl you need to replace the three lines similar to this:



with lines similar to this:



In Git master it's lines 445, 468, and 491, but the lines number might be different in the last snapshot. Looking at Git master should let you recognise the code though.

Note that the three instances are slightly different (v100 vs v010 vs v001) so don't just do a copy and paste. Let me know how that works out and I'll commit it if it's ok.

Cheers, I'll have a go at that later and let you know how it turns out.

Success! Your fix seems to have fixed the problem.

What technique do you use for the texturing? Looks very nice : D