Hello again.

In my client, I have all my data, logic and view separated.

This means in my model I already allocated arrays of voxel data.

I looked in the wiki, searched the forum and browed the API but could not see any obvious way how to feed PolyVox a pointer to my own data to use for generating the mesh.

I could use PolyVox RawVolume in my model, but I rather contain PolyVox to the view.
I could also temporarily copy the voxel data from my model into a polyvox volume in the view to build a mesh from and then either keep it or throw it away, however that would double the size of my memory and would slow things down.

I don't need any code examples or so, just pointers what approach I could take to get this working.

Also, I found a typo in the API:RawVolume, "The callback function which will be called when PolyVox tries to use data which is not currently in momory."
momory->memory

This is a good question, and basically you do have to store your data in a Volume with a PolyVox compatible interface. In your case this probably means you want to create a wrapper/adapter class around your data. PolyVox would call functions in this wrapper class and you would then translate these into calls to your own structure.

A good place to start for this is 'VolumeSubclass' in TestVolumeSubclass.cpp. This shows how you can create your own Volume subclass and implements it in terms of a PolyVox Array.

Note that technically you don't actually have to derive from BaseVolume (everything is templatised so as long as the function names etc match you are fine) but deriving from BaseVolume is much easier as it will provide default implementations for the volume samplers.


Thanks. In Git the typo only exists in LargeVolume (RawVolume doesn't actually have these callbacks!) but I've fixed it there.

Thank you for this information, I have not decided what to do yet.
But now it seems like I will just store the path to the filename where my voxal data resides on disk and let the view actually read that to create volumes.

This leads me so another question.
On disk, I have voxel data as concept of one volume which is same as one "area".

Each volume or area contains 8x8x8 regions.
Each regions contains 16x16x16 blocks
Each block can be shared (1 shared voxel) or (32x32x32 voxels).

Currently I only have one area/volume (so I don't care about finding voxels in other areas/volumes).

How do you recommend to structure the program?

I see that there are volumes, like simple or large volumes, for some reason they only take one region as argument, which means PolyVox concept of regions are not the same as mine.


I tried to create a large volume of 4096x4096x4096, however, that did not turn out very well.
Should I create several volumes?
Can I put several regions into the same volume?

Sorry for all these questions but the principles of PolyVox in the manual is empty, I think if that page existed it would have answered my questions

I don't know much about your application, so I'm assuming it's a game and that you have some kind of large world which you are representing as voxels. In general the expected usage would be that you have a single volume which encompasses the whole world.

Although you say you don't care about finding voxels in other volumes/areas, you should realise that information about neighbouring voxels is often needed for tasks such as building the surface mesh. If your voxels lie on the edge of a volume (such that their neighbours are in a different volume) then you will probably encounter issues with seams and unneccesary polygons being generated.

From your previous post it seems you are workng with the Marching cubes surface extractor and storing both a material and a density for each voxel. For the 4096^3 volume you suggest, this is 128Gb of uncompressed data. Compression should help of course but I think you'll struggle to keep it in memory at all times.

That said, assuming you can only see (and operate on) a small part of the volume at a time, you should be able to take advantage of the paging behaviour in the LargeVolume. This operates on a least recently used approach. I haven't tested terrains beyond 1024x1024x256 in my own projects (though we hope to in our next one) but I believe other people have.