It is currently Sun Nov 17, 2019 10:11 am


All times are UTC




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: CubicSurfaceExtractor bugs on page boundaries?
PostPosted: Thu Jul 24, 2014 2:38 am 

Joined: Sun Apr 13, 2014 11:45 pm
Posts: 8
I have been having trouble with Voxel data being lost on block boundaries - is this a known thing?

I am packaging some calculated occlusion data along with my voxels (and using a custom MarchingCubesController). The marching cubes mesh generator only creates vertices on corners however, and doesnt create vertices on material or density boundaries. FORTUNATELY my occlusion data is only relevant on corners.

UNFORTUNATELY it seems that weirdness occurs on page boundaries where I have for example surface flat against the edge of the page or block or whatever its called, and a protrusion into the next page. The mesh does not incorporate any vertices from the former page, which means that my occlusion info (which I access through vertex.data) is not available at all.

I am still looking into specifically what goes wrong, but I was wondering if anyone has encountered this before or if theres anything simple I can do? I was thinking of either hiding or setting a different material on non-surface voxels, but not sure if that will help


Top
Offline Profile  
Reply with quote  
 Post subject: Re: CubicSurfaceExtractor bugs on page boundaries?
PostPosted: Fri Jul 25, 2014 4:26 am 

Joined: Sun Apr 13, 2014 11:45 pm
Posts: 8
ok, I have experimented a bit and think that I can summarise what Im after by saying 'I want mesh generation to consider my voxel data in the same way that it considers the voxel material'.

I have noticed that if I subtly alter the material to ensure that voxels with different occlusion data also have different materials, my occlusion data is suddenly apparent.

I cant see where this is happening in PolyVox though! MarchingCubesSurfaceExtractor::computeBitmaskForCell() only incorporates the threshold when determining which edges are relevant, so how does it ensure material changes on flat surfaces are rendered?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: CubicSurfaceExtractor bugs on page boundaries?
PostPosted: Fri Jul 25, 2014 7:41 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Right, I'm not sure I fully understand your question but here goes :-)

Firstly, I assume the title of this thread is a mistake, and it should refer to the marching cubes extractor instead of the cubic one? I'm also going to assume you are use the latest version of PolyVox (on the develop branch) because this stuff has changed a lot since the last stable release.

Next, I'm not exactly clear on these boundaries which you refer to. For example, if you are breaking your rendered object into a number of meshes (by calling the extractor a number of times with different regions) then you can say there are boundaries between these meshes. Does you problem go away if you extract the whole volume as a single mesh?

On the other hand, the Large/SimpleVolume stores the volume data as a set of chunks/pages/blocks and you can say there there are boundaries between these. Does your problem go away if you exclusively use RawVolume instead?

Lastly, you can talk about boundaries in the data set - i.e. where voxels with material '1' meet voxels with material '2'. But presumably materials don't affect the occlusion, so can you reproduce the problem with just a single material type in your volume? Can you reproduce it if you set the density of all voxels to either '0' or the max value? These are just ideas to simplify the problem and improve my (and your!) understanding of what is going on.

Can you also explain the structure of your voxel data - i.e. what are you storing in each voxel? Also maybe a screenshot would help?

The structure of the generated mesh (i.e. the set of vertices and their connectivity) is dependant only on the 'density' of the voxels. Density is in quotes there because the voxels may not actually store a density value, but may instead compute one on demand via the MarchingCubesController.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: CubicSurfaceExtractor bugs on page boundaries?
PostPosted: Sat Jul 26, 2014 10:10 am 

Joined: Sun Apr 13, 2014 11:45 pm
Posts: 8
First, sorry about the title and the rest of the confusing stuff in the question - you are correct I meant the marching cubes extractor, and I am using a fairly recent version of the develop branch

It seems to be a problem with paging boundaries - I modified my code to extract one large mesh and I still see miscalculated data (my additional voxel data) on 16-voxel boundaries (that is the size of my volume pages.)

In addition, by default all my voxel densities are 'max', and the whole solid volume uses the same material. As I mentioned though, if I vary the material with the occlusion data, my occlusion data suddenly becomes correctly calculated on boundaries

My voxel data looks like:
Code:
struct Voxel
{
   uint8_t material_;
   uint8_t occlusion_;
public:
   typedef uint8_t MaterialType;
   typedef uint8_t DensityType;
   typedef uint8_t OcclusionType;

   Voxel() : material_(0), occlusion_(0) {}
   Voxel(uint8_t material, uint8_t occlusion) : material_(material), occlusion_(occlusion) { }

   operator uint8_t() const { return material_; } // to make the cubic extractor happy

   DensityType getDensity() const { return material_ == 0 ? 0 : std::numeric_limits<DensityType>::max(); }
   MaterialType getMaterial() const { return material_; }
   OcclusionType getOcclusion() const { return occlusion_; }
};

And this is my controller:
Code:
class MarchingCubesController
{
public:
   typedef gl::vox::Voxel::MaterialType MaterialType;
   typedef gl::vox::Voxel::DensityType DensityType;
   typedef gl::vox::Voxel::OcclusionType OcclusionType;

   DensityType convertToDensity(gl::vox::Voxel voxel) { return voxel.getDensity(); }
   MaterialType convertToMaterial(gl::vox::Voxel voxel) { return voxel.getMaterial(); }

   gl::vox::Voxel blendMaterials(gl::vox::Voxel a, gl::vox::Voxel b, float weight)
   {
      auto material = a.getDensity() != b.getDensity()
         ? (a.getDensity() > b.getDensity() ? a.getMaterial() : b.getMaterial())
         : std::max(a.getMaterial(), b.getMaterial());

      auto occlusion = std::max(a.getOcclusion(), b.getOcclusion());

      return { material, occlusion };
   }

   DensityType getThreshold() { return 127; }
};


Im not sure how helpful a screenshot will be but Ive attached one that shows occlusion data at the y=15 -> y=16 threshold

Thankyou again for your help


Attachments:
File comment: showing occlusion info problem
occlusion.png
occlusion.png [ 116.61 KiB | Viewed 5441 times ]
Top
Offline Profile  
Reply with quote  
 Post subject: Re: CubicSurfaceExtractor bugs on page boundaries?
PostPosted: Sun Jul 27, 2014 7:43 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
seshbot wrote:
It seems to be a problem with paging boundaries - I modified my code to extract one large mesh and I still see miscalculated data (my additional voxel data) on 16-voxel boundaries (that is the size of my volume pages.)


Very interesting - this is not the answer I was expecting. Can you confirm then that it works correctly with the RawVolume (as this stores the data as one single array)?

If RawVolume works properly and Large/SimpleVolume doesn't, then it implies the problem is actually in the volume code. That somehow the voxels are not being stored properly?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: CubicSurfaceExtractor bugs on page boundaries?
PostPosted: Sun Jul 27, 2014 10:50 am 

Joined: Sun Apr 13, 2014 11:45 pm
Posts: 8
ok - Ive not used RawVolume before so Ill experiment with it a bit and come back and edit this question

I was wondering though, how does the mesh extractor allow for material boundaries? I dont think its just the 'weighting' thing, but somehow when vertices are being created they incorporate material boundaries. Within the code I can only see it looking at 'density' - if you search for 'material' in the MarchingCubes extractor it only shows where 'blendMaterial' is being called - is this the only place or is something else happening I dont see?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: CubicSurfaceExtractor bugs on page boundaries?
PostPosted: Mon Jul 28, 2014 8:30 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
seshbot wrote:
I was wondering though, how does the mesh extractor allow for material boundaries? I dont think its just the 'weighting' thing, but somehow when vertices are being created they incorporate material boundaries. Within the code I can only see it looking at 'density' - if you search for 'material' in the MarchingCubes extractor it only shows where 'blendMaterial' is being called - is this the only place or is something else happening I dont see?


I don't think there is any special handling of material boundaries as such, and the shape of the mesh (that is, the positions of the vertices and indices it contains) is entirely determined by the densities. Whenever a vertex is created at a given position, the code also then checks the volume data to determine the material at that position and assigns that material to the vertex. This is done by the blendMaterial function, because a vertex is always created between voxels and so two voxels will actually contribute to the material.

Note that the code sometimes refers to 'material' and sometimes to 'data' - these are the same thing (as I recall) as we're just trying to make it more generic but not everything is renamed to data' yet.

Imagine that you have a volume which is high denisty at the bottom and low density at the top. This will result in a horizontal surface being extracted. Imagine that you also have material '1' on the left side and material '2' on the right side. The generated vetices mesh will then sample the volume at their positions and pick up the corresponding mateial. This means you have halve the vertices with material '1' and half with material '2', and when you assign textures/colours based on these you will see the boundary.


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 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