Hi, David.

These days my head is puzzled in a crash in
return *(mCurrentVoxel + this->mVolume->getWidth());

Stack trace is:

Marching cubes:
execute() -> generateVerticesPerSlice -> computeCentralDifferenceGradient -> peekVoxel0px1py0pz

Probably, I am doing something odd with my multi threading code, but even if I add the calls to execute() under a mutex, I still experience crash and I cannot understand why. I cannot see something corrupting my voxel data, and I first generate a RawVolume and then feed it to the extractor, and even if other tread decides to use the same chunk, I also read it via mutex.

Maybe I am missing something, but I believe that execute() should at least be re-entrant?

I'm afraid I don't have much insight here... but I do vaguely recall there was a bug with one of the peek..() functions long ago. Maybe try making the peek...() function always call getVoxel(), by removing the optimizaion? E.g. change:



to



I'm really only guessing though.



On the same extractor object? If you call execute() simultaneously on the same MarchingCubesSurfaceExtractor then I expect it will cause problems as it stores some state. If you call it simultaneously on two separate MarchingCubesSurfaceExtractor instances then I would expect it to be ok. Unfortunately, as with all threading stuff in PolyVox this is largely untested.

Thanks. The solution fixed the crash for me.
But not the performance overhead the project have overall.

I switched to a variation of the Paul Bourke's Marching Cubes code which make 4x speed increase for me but still didn't tested the output of it.

PolyVox was originally based on Paul Bourke's Marching Cubes code but has changed a lot since. As mentioned in another thread, PolyVox goes to significant effort to eliminate the duplicate vertices for a proper index/vertex buffer, and there is some performance and memory overhead for this. But it seems that you don't need this for your project anyway.

Also I think PolyVox 0.2.1 made use of the Array class, which had some performance issues. This is changed in the latest version.

By the way, after I finally succeeded to integrate the original Marching Cubes with no-vertex-merging, my server started acting slow as hell, even with LZ4 compression.

After some benchmarking and debugging compressions, I understood that i'm an idiot and
compressed world Data from 4 MB jumped out to 20. Sending the data to client was the bottleneck - the data was huge.

I'm back to the PolyVox implementation, because Vertex merging is actually very good form of data compression by itself and I prefer to sacrifice some CPU ticks on the server to merge vertices prior LZ4 compression and move the decompression and filtering task to client-side.

Also, PolyVox is giving to me mesh filtering so chunks match seamlessly. With the Bourke implementation I had to post-process the mesh to cut edges manually so chunks match seamlessly

Great, I'm glad you got it sorted!

In fact I did not. Even compressed everything, I got 8 MB Join Game requirement. Not acceptable.

Interesting is that my 20 MB Voxel Raw data got smashed to 2 MB.
Looks like my assertion that sending the meshes over the network is cheapets way was indeed wrong.

I don't really have a clear idea about whether is is better to send voxels vs meshes, but sending the voxels is more conventional and what other engines seem to do (or they just send a seed and generate client-side). PolyVox 0.3 does make some effort to compress meshes e.g. by storing a normal as a single 16-bit int rather than three floats, but I don't if that helps enough. With cubic-style terrain the voxel data is much smaller because it compresses so well, but perhaps not the Marching Cubes case.

For what it's worth, the research I'm doing into Cubiquity version 2 takes a completely different approach. In this case there is no surface extraction as such (it's based on sparse voxel octrees), so sending the voxel data will be the only option.