Yeah its using 2^3 32x32x32 volumes in those screenshots. I'll try the single volume with a sphere out in a sec. The reason I want to use multiple volumes is because I'm going to be using this for a MMO type thing with more terrain data than can fit in server or client memory at once, so I wanted to page them to and from disk on the server. Maybe the paging should be done inside polyvox, instead. Hmm

edit: seems fine with a sphere overfilling the volume

but with the continuous noise it does this

I think it should. Improving the volume compression is probably my highest priority task for PolyVox and I will do some work on it in the next couple of months. I'm not currently planning paging though - just much better compression (I would estimate a factor of 100 over the raw uncompressed data). But I think you'll need to worry about rendering performance before memory issues.


What's causing the problem, is it the fact that there are multiple volumes, or the fact you are using the perlin noise? If you create a single volume of Perlin noise then is it correctly 'sealed'?

Edit: Assuming it's the multiple volumes, are you creating a seperate SurfaceExtractor for each? If not maybe try that in case it's not being reset between volumes or something?

Yeah, I'm using a separate extractor for each volume. The problem occurs even with just one volume, I think. I'll test it in a second to make sure.

edit: you seem to be on to something with that, it doesn't get holes with just 1 mesh but when i up it to 8 cells it does. Hmm.

http://dl.dropbox.com/u/6281166/bug.jpg
http://dl.dropbox.com/u/6281166/nobug.jpg

Ok, some random thoughts which might shed some light...

Does it only happen on one face (I can't see the back in the screenshot)? If so which one? I'm guessing it's along positive or negative Z?

Can you simplyfy it to two volumes and still get the problem? Does matter how they are placed (next to each other, above/below, etc)?

Does it happen on both of them? Or is it just the first or second?

Can it be a rendering problem? Assuming all the volumes have the same data, can you print out the number of vertices/indices to see if it's the same between volumes?

That's more questions than answers I'm afraid but it's some things to look for...

Yeah it's only on the one face, not sure what axis it is atm. The holes in each mesh seem to be totally independent of what I set the volume data to. Even when its 100% full it still gets those same holes in the same volume's mesh. The holes and which volumes get them don't change at all when I rerun the program. This seems a lot like some kind of memory corruption. It repeats across most volumes but some don't have any problem.

http://dl.dropbox.com/u/6281166/bug2.jpg

Ok, it seems it would be worth me trying to reproduce this. I'd rather leave out rendering, so maybe you can create a C# snippet which creates a volume, fills it (solid is fine as that seems simplest), extracts a mesh, prints the numbers of verts/indices, and then does that again? Then I can convert that code to C++ to see if I can get the same thing to occur.

I'll look at it tomorrow if I can, otherwise the next day.

I just compared and all the vertex and index counts match. I even tried feeding the renderer the first mesh 8 times and it changes. The errors are changing each time now so it definitely seems like memory corruption of the vertices/indices from something, hmm.

Now I'm testing it again and the vertices are equal, but they still render differently... this doesn't make any sense at all
I have a hunch that its the nuclex batch renderer screwing everything up, again. Going to try doing the vertex/index buffer rendering myself.

edit:
I was right, its the goddamn nuclex batch renderer screwing it up. Going to give the nuclex coders my regards about it later Sorry to have wasted your time with 2 stupid nuclex bugs in one day, haha.

No problem, glad you got it working.

Yeah, now I just need to fix the seam normals. I guess I will do what the other guy did and copy in border info from neighboring cells so it lines up properly.
http://dl.dropbox.com/u/6281166/lighting.jpg
http://dl.dropbox.com/u/6281166/weareborg.jpg
http://dl.dropbox.com/u/6281166/exploded2.jpg

I'm still investigating possible ways to get rid of the seams for non-cubic cells. Apparently the C4 engine calculates each cell mesh at 3 different voxel resolutions and stitches cells together, selecting the detail level based on camera distance. I'm not sure how they avoid having to regenerate the whole mesh every time a single cell is changed, though. Anyone have any theories on how it might work?. I think they might be using a vertex shader to do it in real time but I don't know how to even begin doing something like that. I think actually generating new vertices in the shader requires directx 10 so it might only be possible to do on the cpu.
http://www.terathon.com/wiki/index.php? ... ng_Terrain

edit: Aha, found the paper on what C4 uses http://www.terathon.com/lengyel/Lengyel ... in-Low.pdf
What do you think the chances of something like this being implemented in Polyvox are, David? I know you said you weren't going to focus on supporting very large worlds, but I think it would make the library much more useful.