Missing some Voxel near of origin of scene

[Olganix]

Hi.
For a project witch need to make fastly collisions for stages, I test yours solution to make voxels.

After getting the resulting point_cloud from yours functions, I add a algo to reduce the numbers of voxels by merging them into a Axis-Scaled-Voxel.
By trying to do this, I noticed there is some duplicate voxels (voxel on the same place because of float precisions : X.0002 vs Y.9999 , with Y = X -1).

The final result is I have some missing voxels, specially near of the plane Y=0, some with Z>0 and X>0. I temporaly solve the problem by using yours precision to be 20% of the voxel size.
But, that create more voxels we need, specially on walking objects.

So I search a little, I see a little mistake on the function vx__map_to_voxel() :

float vx__map_to_voxel(float position, float voxelSize, bool min)
{
float vox = (position + (position < 0.f ? -1.f : 1.f) * voxelSize * 0.5f) / voxelSize;
return (min ? floor(vox) : ceil(vox)) * voxelSize;
}
The problem is if you have a something about y~=0.5, you want the AABB.minimum.y=0, but you have 0.0 or 1.0 depending of being just bottom or up of 0.5,
0.51 + 0.5 = 1.01 => 1.0 with floor
0.49999 + 0.5 = 0.9999 => 0.0 with floor.
In case of having 1.0 with floor, you get the reason why there is some voxel on the same place.
I give a example with Y, but X and Z are also impacted.

By adding +0.5, without the "is min" condition, just decal the trouble of float precision. (I know you want to deal with the fact for negative the floor() function don't give what you want).

As we want all possibles voxels (and the validation of them is done after), I propose this solution :
float vx__map_to_voxel(float position, float voxelSize, bool min)
{
float vox = roundf(position / voxelSize);
return (min ? (vox - 1) : (vox + 1)) * voxelSize;
}
forcing to have one more on each direction could be a time consumer, but here you will be sure you have all voxels for the test with the triangle,

As there is more voxel around, I think that could also solve the trouble about hole (whena vertex of triangle is near a limit of th 3D grid of voxels) , but I don't have a good example for this. So people may be could put the precision to 0.0 (the one to solve holes).

Have a good day.

[qwiff-dogg]

I've implemented this suggestion in my fork. Combined with a precision of 0 it seems to fix the problem of having holes in the voxel shell.

My integration tests also show a significant decrease in the number of voxels before and after this fix, meaning that there were duplicate voxels before.

qwiff-dogg@fac8397

[karimnaaji]

thanks for testing and fixing that @qwiff-dogg . Are you interested in making a PR from your fork for the fixes you have? The tests would also be interesting to have.

[qwiff-dogg]

@karimnaaji My fork adds a significant chunk of code for filling the shell interior. Is that something you would want in master? I'm using it to generate volume point clouds for run-time volume calculation. From a graphics point of view it's not really an interesting feature to have, since the interior is occluded anyway.

[karimnaaji]

@karimnaaji My fork adds a significant chunk of code for filling the shell interior. Is that something you would want in master?

I think so! I'll check out your branch to test it in more detail, but I can imagine a few use cases where you'd want deep voxelization like you have.

[qwiff-dogg]

@karimnaaji I've finished working on my fork.

I can make a PR that folds all changes into 1 commit.

I've made substantial additions, some of which you may or not want to have in master.

1. Added an option to fill the voxel interior.
2. Added integration tests for voxelization
3. Added integration tests for volume calculation
4. Added Python script for visualizing point clouds

Items 3 and 4 are not part of the core voxelization functionality and could be removed.

In addition it has the fix for #9 (this issue). On the models that I've tested I've found that you can now set precision to 0, making this parameter redundant in these cases.