A bug in solid voxelization

[UGzhang]

I try to input 32/50/64/100 as voxel grid length in cpu mode.
32/64/100 work very well, but 50 has a bug.
I have uploaded my source obj file and output .obj file (modify .txt to .obj).

sphere.txt
sphere.obj_50_voxels.txt

[Forceflow]

If I read this correctly, you're trying a non-cubical voxel grid? There is still no official support for this - ymmv.

Have you tried with the developer branch?

Thanks for report, though.

[UGzhang]

I will try to developer branch, thx.
And I notice in the paper Fast Parallel Surface and Solid Voxelization on GPU's, they use octree in solid voxelization(like right pic)
Do you have use octree in this project?

[UGzhang]

Another bug happened in solid voxelization.
I use grid size = 8 in cpu mode.
My input is a cube, and output is 8x8x7. I think the correct output is 8x8x8.
Do you have any idea to solve this problem?

[xingshh]

I find this bug too。 I think the boundary pnt should be reserved., then reset the bounary bit?
when x = xmax;
{
if (morton_order) {
size_t location = mortonEncode_LUT(x, y, z);
setBitXor((voxel_table, location);
boundaryBits.push_back(location);
}else {
size_t location = static_cast<size_t>(x) + (static_cast<size_t>(y) * static_cast<size_t>(info.gridsize.x))+ (static_cast<size_t>(z) * static_cast<size_t>(info.gridsize.x) * static_cast<size_t>(info.gridsize.y);
setBitXor(voxel_table, location);
boundaryBits.push_back(location);
}
}
}

[conceptclear]

您好，您的邮件我已收到并会尽快回复，祝好

[Forceflow]

Can you try again with the latest release version?

[hitrpr]

Tested now .5 release, have the same single-voxel layer.
127 width for main object and 127 grid with 2 layers for additional

I did -s 128
Magica voxel
So i can suppose, that are voxels 1—128 plus zero voxel.

[Forceflow]

And this only happens in solid voxelisation?

[hitrpr]

And this only happens in solid voxelisation?

No, with hull-voxelization too


m1.obj_128.zip
command was cuda_voxelizer.exe -f ./proc/m1.obj -s 128 -o vox

[adnan-saood]

I have somehow similar behavior in my project. I am trying to voxelize a simple 3D blob read as a surface_mesh object in CGAL.

I made the appropriate conversions (so I don't use Trimesh, because I have to use CGAL).

All meshes are read and solid voxelized correctly but this one.

I m trying to save it as a pointcloud file (the ultimate goal is for me to check if a point is inside the poly or not)

Did anyone face similar behavior anywhere? Me using CGAL is working perfectly as intended for other files (cube, iso-sphere, prism,...)

File:
polyhedral.zip

[conceptclear]

您好，您的邮件我已收到并会尽快回复，祝好

[adnan-saood]

I can do a basic workaround to produce what I want but in a very unintuitive way, If I use an STL input file with mm units (scaled x1000 compared to the zip file I attached earlier), the result is good. I do not know what caused this, maybe some numerical errors.

[Forceflow]

Yeah, I'm writing this down as some numerical errors. I'm currently in the process of rewriting the project to remove the dependency on GLM, maybe this resolves these numerical quirks, since it is not really meant for usage with CUDA.

Thank you all for the detailed reports and test models. As soon as I got the rewrite nailed won, I'll have a new look at this. If you're compiling yourself, maybe disable fastmath?

[adnan-saood]

@Forceflow I will definitely try that. If this is a collaboration-based library don't hesitate to create the task and maybe we would do the changes in our forks and PR. Thanks again for the clarifications.

[Forceflow]

You can test with the dev branch if you want.