It is currently Tue Nov 12, 2019 11:05 am


All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: [0.2.1] Crash in peekVoxel0px1py0pz
PostPosted: Sun Mar 20, 2016 10:15 pm 

Joined: Tue Apr 08, 2014 5:10 pm
Posts: 124
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?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: [0.2.1] Crash in peekVoxel0px1py0pz
PostPosted: Tue Mar 22, 2016 11:17 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
petersvp wrote:
These days my head is puzzled in a crash in
return *(mCurrentVoxel + this->mVolume->getWidth());

Stack trace is:

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


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:

Code:
template <typename VoxelType>
VoxelType RawVolume<VoxelType>::Sampler::peekVoxel0px1py0pz(void) const
{
   if( BORDER_HIGHY(this->mYPosInVolume) )
   {
      return *(mCurrentVoxel + this->mVolume->getWidth());
   }
   return this->mVolume->getVoxelAt(this->mXPosInVolume,this->mYPosInVolume+1,this->mZPosInVolume);
}


to

Code:
template <typename VoxelType>
VoxelType RawVolume<VoxelType>::Sampler::peekVoxel0px1py0pz(void) const
{
   return this->mVolume->getVoxelAt(this->mXPosInVolume,this->mYPosInVolume+1,this->mZPosInVolume);
}


I'm really only guessing though.

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


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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: [0.2.1] Crash in peekVoxel0px1py0pz
PostPosted: Wed Mar 23, 2016 10:31 am 

Joined: Tue Apr 08, 2014 5:10 pm
Posts: 124
Thanks. The
Code:
this->mVolume->getVoxelAt
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: [0.2.1] Crash in peekVoxel0px1py0pz
PostPosted: Sat Mar 26, 2016 12:37 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
petersvp wrote:
Thanks. The
Code:
this->mVolume->getVoxelAt
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: [0.2.1] Crash in peekVoxel0px1py0pz
PostPosted: Fri Apr 01, 2016 12:16 pm 

Joined: Tue Apr 08, 2014 5:10 pm
Posts: 124
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 :)


Top
Offline Profile  
Reply with quote  
 Post subject: Re: [0.2.1] Crash in peekVoxel0px1py0pz
PostPosted: Sun Apr 03, 2016 8:37 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Great, I'm glad you got it sorted!


Top
Offline Profile  
Reply with quote  
 Post subject: Re: [0.2.1] Crash in peekVoxel0px1py0pz
PostPosted: Sun Apr 03, 2016 3:00 pm 

Joined: Tue Apr 08, 2014 5:10 pm
Posts: 124
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: [0.2.1] Crash in peekVoxel0px1py0pz
PostPosted: Sat Apr 09, 2016 10:42 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
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.


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net