Hello,
I'm using PolyVox since quite a lot of time and it works like a charm, however I hit a problem since last week.

I'm using PolyVox 0.2.1 and the CubicSurfaceExtractor, everything worked fine until I started to introduce seams in my terrain, and since then I started experiencing random crashes that were pointing to SurfaceMesh::removeUnusedVertices in release mode.

After quite a lot of struggle I was able to export one portion of the terrain that is giving me the problem and edit the BasicExample to reproduce it.
In debug mode, it hits the assert in CubicSurfaceExtractor::addVertex

This is the main.cpp of the BasicExample with my modifications (sorry for the mess, I tried to replicate my internal code as close as possible but it was quite hard to decouple it from my application):
http://pastebin.com/cMj4J8BC

To reproduce the issue you will need this file where I saved the raw data from the volume in my application:
https://www.dropbox.com/s/q5ijkgxjbfabbo8/test.data

I hope you can help me with the issue since I don't know much about the internals of the library, maybe I'm doing something wrong?

Thanks in advance, and if you need any additional information just ask.

EDIT: I forgot to mention I changed type of the material in PositionMaterial from float to uint32_t since I had some precision problems under certain circumstances, and changed the line 263 of CubicSurfaceExtractor.inl to

to accout for that, but I tried changing it back and it gives the same problem.

Unfortunately I haven't managed to reproduce this error. I got the PolyVox 0.2.1 zip file from this site and did a fresh build in a new location, and applied the new main.cpp. I also added the test.data to my project (you might want to add 'assert(testFile.good());' after you open the data as I placed it in the wrong position to start with and it then reads the data from an empty stream but doesn't complain). I also tried it with and without the one-line change to the CubicSurfaceExtractor.

I tested on Windows so let me know if you are actually on Linux.

Assuming you are on Windows, perhaps you can place a fresh copy of PolyVox 0.2.1 somewhere on your system and repeat the changes yourself? If you still get the error you could zip up the whole folder (delete the debug/release folders) and send it to me so I have a better chance of reproducing the problem.

I'd also be curious what happens if you change line 35 of CubicSurfaceExtractor.inl so that MaxVerticesPerPosition is '8' instead of '6'. Does this help the problem?

Hi David, I'm on windows too (vs2010)

I tried the change you suggested and it solves the crash, I also tried it in my app and everything seems to work fine now.

Strange you can't reproduce the issue, I tried downloading a fresh copy of polyvox and even without making any of my changes it still crashes for me. I have zipped up the folder as you asked, you can find it here (sorry for the size, I probably forgot to delete something):
https://www.dropbox.com/s/dpc3upheshg958i/PolyVox.zip

Let me know if you need anything else, and thanks a lot for helping me solving this

Ok, I can reproduce the error so I'll investigate and get back to you.

Ok, I've decided that increasing MaxVerticesPerPosition is actually the correct solution to the problem. This constant is used by the code which eliminates duplicate vertices, and it used to be the case that a vertex could be shared by no more than six voxels. However, recent changes regarding the 'IsQuadNeeded' callback and support for transparency mean that the limit needs to be raised to eight.

I've committed this change to Git: https://bitbucket.org/volumesoffun/poly ... 6d9ceeae95

After more testing, I hit the problem again however this time it was a lot more rare, I tried changing the constant to 10 and I have never encountered the problem again. I have waited several days to be sure.

Due to the rarity of the issue, it's hard for me this time to provide a test case, however I still wanted to report it.

If you need the test case, I'll try to provide it.

Very strange! To provide some context, PolyVox tries to eliminate duplicate vertices by keeping track of all vertices at a given location and reusing them if possible. However, sometimes you do need multiple vertices at a single location beause the vertices might have different materials (in which case they can't be shared). So for each position an array of vertices is stored and the constant 'MaxVerticesPerPosition' controls the size of this array.

If you have eight semi-transparent voxels (with different materials) forming a cube then you would need eight vertices at the center of it. But this should almost never happen, and I can't imagine how you can need more than eight.

So I think this is a bug and will try to investigate. I can probably catch it by lowering the assert limit to just three or something because even this should be quite uncommon. The bug is logged here (but you can continue to reply to this thread if it's easier): https://bitbucket.org/volumesoffun/poly ... g-exceeded

Maybe a little context will help.
I started having problems after I implemented lighting, so maybe it's that. Every face of a cube takes the lighting from the empty cube in front of it during extraction, so it can happen that a cube has a different "material" (since the lighting is stored in it) for each of its faces.
I use this system only for solid cubes, since transparent ones take the lighting value from the cube itself.

Other than that, it could also be some weird behavior on my part due to a bug elsewhere, I will let you know if I find something.

Ah, that's very interesting. If we allow the vertices to have a different material based on which face of the voxelthey came from then I think the theoretical maximum number of vertices is a lot more. Probably 24 (a vertex can come from three faces of the voxel and could be at the centre of eight voxels).

It might be time for a more dynamic approach - i.e. keeping a linked list of vertices rather than a fixed size array.