Evening

I've got a quick question since this has been baffling me.

I've created a simple volume of 65x65x257 using int32 (4 bytes) per voxel.
Using that logic, the SimpleVolume.calculateSizeInBytes() function should be returning: 4,343,300
Give or take a small (in relative terms) margin to accommodate additional data.

Simple cration code is below:


I put a breakpoint at (int h = 0) to show me the value of K.

However, k = 10,748,000
The memory actually stored is more than double the specified number of bytes.
I can confirm the number is accurate from Task manager.

Is there something I'm doing wrong here? Is there a better storage medium than SimpleVolume?

Essentially my main interest in polyvox lies in the mesh optimization, so if there's an unconventional solution to maintain that element in particular I'm all ears.

Cheers!

Hi, and welcone to PolyVox

Internally the SimpleVolume stores it's data as a set of blocks, and by default these blocks are 32x32x32. This means your volume dimensions will be rounded up to the nearest multiple of 32, which in your case makes the volume 96*288*96 voxels. With four bytes per vertex this explains the size you are seeing.

Probably this extra overhead doesn't matter, and it becomes less significant as the volumes get larger. But if you want to avoid it then you can use RawVolume instead as this simply stores a single large chunk of data which should be the expected size.

Ah, that makes sense. many thanks for the reply!
I'll admit I'm pedantic to a flaw when it comes to the memory management and predictability aspects of development. RawVolume looks to be precisely what I'm looking for. Still relatively fast at mesh generation too, which is nice!

On a side note since I'm here, I'm really looking for a fixed size of 64x64x256 (0,0,0 to 63,63,255), but two if the edges end up not being created for the mesh unless I add that additional +1

Is there a way to tell it to always assume that an out of bounds vertex will be 0?
I tried volData.setBorderValue(0); but I suspect I'm misinterpreting the point of that function

Thanks for the welcome, too

Yes, for small volumes like yours it is fine. For larger volumes the block-based nature of the SimpleVolume is more cache-friendly.



There's some useful information in the CubicSurfaceExtractor documentation, but do ask if it's still not clear.




That should work (in conjuntion with setting the region size correctly as in the previous link), though in the lasest (develop) branch of PolyVox there is a new approach described here: https://bitbucket.org/volumesoffun/poly ... at=develop

Makes sense. Since I explicitly want the regions to remain separate I'll stick with the +1 method, at least for now.

If the new method uses getVoxel() to determine borders I assume that would be included to some degree in the mesh extractor?

Cheers for replying again

Yes, one of the reasons for making these wrap modes be passed as a parameter (rather than using a different function as in the getVoxelAt() case) is that they can then be passed to the various algorithms. The CubicSurfaceExtractor does take such a parameter but I'm not sure if it's hooked up internally at the moment.