We are not (currently) using octrees for the volume data - that is just stored in a single LargeVolume/PagedVolume. A octree is instead used for managing the mesh data which we extract, and this is mostly related to LOD. Each level of the octree stores a different resolution mesh and we choose which one to use based on the distance to the camera. It's an active research area at the moment.



Yep, this is another example of why you should put everything in a single large volume rather than many small ones (though you should still generate many small meshes). The LowPassFilter averages a voxel with it's neighbours, and if those neighbours are in a different volume then it doesn't have access to them.

Hi David,

But I am using a single large volume. I am extracting the meshes in regions occupied by the chunk..

This is my exact code

The regions are separately filled for each chunk. (Note that I am filling 0 for air and 255 for ground)

PolyVox::Region region(PolyVox::Vector3DInt32(startX, startY, startZ),
PolyVox::Vector3DInt32(endX, endY, endZ));

RawVolume<uint8_t> tempVolume(region);
LowPassFilter< SimpleVolume<uint8_t>, RawVolume<uint8_t>, int16_t > pass1(mSimpleVolData, region, &tempVolume, region, 3);
pass1.executeSAT();
LowPassFilter< RawVolume<uint8_t>, SimpleVolume<uint8_t>, int16_t > pass2(&tempVolume, region, mSimpleVolData, region, 3);
pass2.executeSAT();
PolyVox::SurfaceMesh<PolyVox::PositionMaterialNormal> mesh
MarchingCubesSurfaceExtractor< SimpleVolume<BYTE> > surfaceExtractor(mSimpleVolData, region, &mesh);
surfaceExtractor.execute()

I think you will also need to filter the whole volume in one go, where as you are currently doing it one chunk at a time? If you do want to do just a chunk at a time then you will need to take extra steps so that your temporary volume is larger than a chunk, so that you can include the neighbouring voxels as well (even then I'm not sure how well it works).

If the values come from a noise function then can you not generate smoother values in the first place to avoid the need for filtering?

This is the way I do my extraction and usually contribute each post with it
In order to avoid writing the same all over, there is the post that you may get the idea:
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=14&t=624&p=4589&hilit=Crafterria#p4589
This way you don't store filtered volume, just extract your raw volume filtered.


You already know that it works and i managed to already make my chunks seamless, smooth without storing densities at all Well, this will change as now I am investigating for better algorithm based on that

Hi David,

I did try the method petersvp suggested it works really well until I start deforming the terrain. The terrain deformation is a bit wonky since the individual chunks need to be overlapped, whenever there is a terrain deformation at the edge of two meshes its causing gaps in the terrain.

I was wondering how you could use density values for smooth surfaces. I was using the example outlined in the polyvox examples but I could not get a smooth surface. Could you please help me understand this? I am using the following code.



if I change the value I multiply the density with, I do get seemingly smooth surfaces but then, I also get a lot of thickness with the mesh(which I don't need). Does cubiquity use the low pass filter internally? If so, how does it handle the overlapping mesh issue?

It's quite hard for me to explain this to be honest, I think you will need to study density functions in general. But the idea is that densities can have a range between 0 and 255 (at least in our case), and that if a density has a range < 127 then it is considered empty, otherwise it is considered solid.

The following code will give a very jagged mesh because all the densities are either 0 or 255:



To make it smooth you need to ensure that your voxel values have a gentle transition from low density to high density, and one way to do this is to use the distance directly (the distance changes gradually and smoothly). But the distance goes from zero to infinity, and you need to map that to the range 255 to 0 (our sphere should be solid near the origin and empty further out). In the code you showed, the multiplications and additions basically perform this mapping.



Yes, imagine you have a voxel with density 20. The sphere does not include this voxel (as the density is less than 127), but if you multiply all voxel densities by 10 then the new density is 200 and so the sphere does include it (as it is now more than 127).



This stuff is actually separate from what PolyVox and Cubiquity provide. Both libraries allow you to turn a density field into a mesh, but in both cases the issue of generating the density field is left to the user. The user can use noise functions, implicit surfaces, or (in the case of Cubiquity) use built in sculpting tools to set the voxel values.

So Cubiquity does use low pass filtering (I forget if it uses the PolyVox code) but not for the purpose of generating the volume data as this task is not performed by Cubiquity. I think it only uses it for LOD generation.