I just tried the Windows version from this release. Unfortunately it does not seem to work and gives the following error. Is there anythin needed in addition to make it work?

Also it seems like the DLLs contained in the release zip are cudart64_90.dll, so maybe they need an update?

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

This is a 1024 res voxel model and looks correct
https://imgur.com/p0Wg37l

This is at 2048, it appears to wrap around... should be a simple fix.
https://imgur.com/sBzhsmW

Hi, Thank you for this project, it helps me very much.

I found a small issue when calculating the voxel location here:

I think it should be :

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));

since you made the info.gridsize.x == info.gridsize.y == info.gridsize.z when creating AABox we can't reproduce this issue. I found this by accident when experimenting the code and use a grid size with different value on three directions.

I used cuda_voxelizer to generate binvox files and intended to read the file using binvox_rw_py

However, the file generated lacks translate and scale in its ASCII header, I have to manually add following lines to the function write_binvox:

    output << "translate " << info.bbox.min.x << " " << info.bbox.min.y << " " << info.bbox.min.z << endl;
    output << "scale " << max(max(info.bbox.max.x - info.bbox.min.x, info.bbox.max.y - info.bbox.min.y),
                              info.bbox.max.z - info.bbox.min.z) << endl;

I guess it is right, because I checked that all vertices falls in to voxel using the following coordinate translation function:

def cartesian2voxcoord(v, vox):
    vn = (v - vox.translate) / vox.scale
    vc = np.floor(vn * vox.dims)
    vc = np.clip(vc, 0, vox.dims - np.ones(3, dtype=np.int)).astype(int)
    # original code: vc = np.round(vc).astype(int)
    return vc

Do you have any support for this feature?

Lately, theres's been a strange bug with CUDA and unified memory:

• https://devtalk.nvidia.com/default/topic/1031803/cuda-programming-and-performance/using-unified-memory-causes-system-crash/?offset=24#5308685
• https://devtalk.nvidia.com/default/topic/1043879/cuda-programming-and-performance/whole-system-freezes-when-using-cudamallocmanaged/1

I'm working on a solution to temporarily switch back to the old, more hands-on way of allocating memory for triangles and voxel table.

Thanks for your contribution !
I have a question.Can grid size of voxel be different ? For example 128192128, rather than128128128 ?

Hello all,

I found a workaround but I do not know if its intended to be an issue or not.

I you try to input a mesh file and generate a pointcloud, the resulting pointcloud would have the same dimensions but not the same center of the input mesh. This is because of the createMeshBBCube function in the utils.h file.

When you try to scale the two non-maximum dimensions to math the largest one, it creates a grid where it matches only with the largest dimension.

To do workaround, I decided to make the scaling go only on the max point of the input bounding box.

float delta = max_length - lengths[i]; // compute difference between largest length and current (X,Y or Z) length
//answer.min[i] = box.min[i] - (delta / 2.0f); // don't pad in the min direction
answer.max[i] = box.max[i] + (delta); // pad with difference behind current max

this ensures that when I use the voxelization_info.unit vector to scale back the resulting pointcloud to original dimensions, the scaling is correct.

I do not know if this should be done pre or post voxelization, I decided to do it before.

I do not know if the double-sided sacling was preferred to preserve the center of the mesh, but by using it we can only preserve dimensions and lose center, or preserve center and lose dimensions.

So if anyone is trying to use this code to check if a point in a uniform grid is inside or outside the input mesh, this modification is necessary I think.

I also noticed instability if the input mesh has small dimensions (e-3 magnitude), but that's a different issue and I wrote about it in the solid voxelization issue thread.

I just voxelized a simple cube, defined as (obj file):
v 150.100006 400.100006 550.099976
v 550.099976 400.100006 550.099976
v 150.100006 800.099976 550.099976
v 550.099976 800.099976 550.099976
v 150.100006 800.099976 150.100006
v 550.099976 800.099976 150.100006
v 150.100006 400.100006 150.100006
v 550.099976 400.100006 150.100006

f 1 2 4
f 1 4 3
f 3 4 6
f 3 6 5
f 5 6 8
f 5 8 7
f 7 8 2
f 7 2 1
f 2 8 6
f 2 6 4
f 7 1 3
f 7 3 5

The CPU mode generate fine result, but the GPU mode yield something inaccurate:




The first image is the voxelization result visualized by marching cubes algorithm and meshLab, some glitch appears along the diagonal line. The latter 3 images are 3 continuous 2-D plane of the voxelization result, the middle one shows that the glitches comes from the voxelizer.

I barely know about cuda programming and the voxelization algorithm, just point out this issue, maybe someone can fix it.
Still very nice voxelizer 😃 !

I've made a few code improvements to your CPU version that increase efficiency by about 10 times
The test results in the same environment are as follows：
646464--->5ms
128128128--->7ms
256256256--->19ms
512512512--->121ms
102410241024--->728ms
204820482048---->5576ms

Hi,
I've been running into a lot of trouble setting up the repo and it's probably because I'm extremely new to the art of supporting C++ dependencies.
My rig right now:
Windows 10 win64, Visual Studio v141, and the CUDA 9.2 toolset

I also downloaded the prebuilt libraries of trimesh2 (your version) and added libWin64v141 to src. I also got the 'release' version not the debug version.
I also downloaded Trimesh2 repo and added the header files to src.
I also got glm and added the glm folder in include to src.

As of now when I try to build the binaries on Visual Studio, I get the following link error:
unrecognized flag 'Ot' not in 'p2'.
Based on my debugging it seems that this is because trimesh was compiled differently from my cuda_voxelizer solution build. But I am sure my build is Release, 64 and v141, the same as Trimesh.
Any help is much appreciated.

I am attempting to create a CPU version of this code. In that effort, I have figured out what part of voxelize_triangle() does, but I need a hand.

What is this "unit length" (unit.x, unit.y, unit.z)? It is the dimensions of the bounding box divided by "gridsize". That would seem to suggest unit length is the number of voxels in each direction, with gridsize being the width of a voxel in each direction. Is that true?

Does that mean this code supports voxels that aren't perfect cubes?

Maybe some of the code has to do with tiling, something I won't need to do and don't totally follow.

Further, I don't follow what the critical point and delta_p are used for. Neither are changed within the voxelize_triangle loop, but both are used. It's very odd.

In any case, here is what I have so far for my rough overview of what the code is doing:

for all triangles...

// fetch the triangle's 9 coordinates (3 vertices)
// compute the edge vectors
// use edge vectors to get tri's normal
// get tri's bounding box in global coordinates (not relative to grid)
// get "t_bbox_grid" (I don't really follow this part. If unit.x is number of voxels in x direction, I don't see what this does. I know what clamp is, though)
// without knowing the prior step, don't want to speculate on the rest

Thanks for any assistance!

Hi, thanks for sharing this code and I'm experimenting the code.
I don't quite understand the TopLeftEdge function

• Is this check necessary?
• What does it mean in geometry, does it mean the top left edge of a triange as the name implies, if yes why we should do this check?

/data/guojingfeng/trimesh2/include/Color.h(165): error: more than one instance of overloaded function "cbrt" matches the argument list:
function "cbrt(float)"
function "std::cbrt(float)"
argument types are: (float)

/data/guojingfeng/trimesh2/include/Color.h(165): error: more than one instance of overloaded function "cbrt" matches the argument list:
function "cbrt(float)"
function "std::cbrt(float)"
argument types are: (float)

1 error detected in the compilation of "/tmp/tmpxft_000027fe_00000000-6_voxelize_solid.cpp1.ii".
CMakeFiles/cuda_voxelizer.dir/build.make:160: recipe for target 'CMakeFiles/cuda_voxelizer.dir/src/voxelize_solid.cu.o' failed
make[2]: *** [CMakeFiles/cuda_voxelizer.dir/src/voxelize_solid.cu.o] Error 1
make[2]: *** Waiting for unfinished jobs....
1 error detected in the compilation of "/tmp/tmpxft_000027fb_00000000-6_voxelize.cpp1.ii".
CMakeFiles/cuda_voxelizer.dir/build.make:145: recipe for target 'CMakeFiles/cuda_voxelizer.dir/src/voxelize.cu.o' failed
make[2]: *** [CMakeFiles/cuda_voxelizer.dir/src/voxelize.cu.o] Error 1
CMakeFiles/Makefile2:82: recipe for target 'CMakeFiles/cuda_voxelizer.dir/all' failed
make[1]: *** [CMakeFiles/cuda_voxelizer.dir/all] Error 2
Makefile:90: recipe for target 'all' failed
make: *** [all] Error 2

Can you help me figure out what the problem is?

i cant get the build for linux from github actions

size_t vtable_size = static_cast<size_t>(ceil(static_cast<size_t>(voxelization_info.gridsize.x) * static_cast<size_t>(voxelization_info.gridsize.y) * static_cast<size_t>(voxelization_info.gridsize.z)) / 8.0f)

Should we ceil it after '/ 8.0f' ?

here is an error
cpu mode works

Would be nice to have this as an option for export

I think I noticed something I think is slightly off in the implementation of equation 2 (second part where one calculates d) inside voxelize.cu in lines 131 - 133. For each edge projection into the ZX plane there is written:
float d_xz_ei = (-1.0f * glm::dot(n_zx_ei, glm::vec2(v0.z, v0.x))) + glm::max(0.0f, info.unit.x*n_zx_ei[0]) + glm::max(0.0f,info.unit.z*n_zx_ei[1]);
but shouldnt the supplied axis to each max function actually be the same order as the previous two plane projections? For example XY where the first call to max has the first axis X like info.unit.x * n_xy_ei[0] and the second call to max has the second axis Y like info.unit.y * n_xy_ei[1].
For the ZX axis this would look like:
float d_xz_ei = (-1.0f * glm::dot(n_zx_ei, glm::vec2(v0.z, v0.x))) + glm::max(0.0f, info.unit.z*n_zx_ei[0]) + glm::max(0.0f,info.unit.x*n_zx_ei[1]);
I think for the end product it does not matter currently as info.unit.x/y/z are the same at the moment (gridSize in main.cpp) but technically it is still wrong, or am i missing something here?

An error occurs when I run cmake --build. --parallel 8
Can you help me figure out what the problem is？

Color.h(165):
static inline float cielab_nonlinearity(float x)
{
using namespace ::std;

if (x > 216.0f / 24389.0f)
return cbrt(x);
else
return 4.0f / 29.0f + (841.0f / 108.0f) * x;
}

Since this seems to be a harder issue, I am creating a seperate one for this. The conversation from #21 can be moved here if that is possible.

Hi,

Could you please help me ?

My OS is Windows 10 & i'm using VS 15.

thnx.

Hi,
Is VTK (Legacy file format) supported for input?

GLM is mostly headers and it doens't have a library to be linked so there is no need to include it in TARGET_LINK_LIBRARIES and because Cmake can not find it, it is better that its include directory be set by the user the same as trimesh2.

Currently it looks like one has to build for Linux manually. Unfortuantely I am not experienced in that and also there is not much documentation here about how to do that. I suspect it requires some pre setup of dependencies and is not just a simple command?

Thus it would be helpful having a Linux release available for download.

Can't build on Ubuntu 16.04 even if I set up the GLM_INCLUDE_DIR correctly.
cuda_voxelizer/./src/thrust_operations.cuh:14:23: fatal error: glm/glm.hpp: No such file or directory

The ability of creating solid voxels with this tool would be cool.

Hi,@Forceflow
I have found the reason which caused the problem that you mentioned in util.h.
In cpu_voxelizer.cpp Line 133 to Line 135
and voxelize.cu Line 131 to Line 133
The positions of z and x in these lines of code are wrong.
The modified code could be

float d_xz_e0 = (-1.0f * glm::dot(n_zx_e0, glm::vec2(v0.z, v0.x))) + glm::max(0.0f, info.unit.z * n_zx_e0[0]) + glm::max(0.0f, info.unit.x * n_zx_e0[1]);
float d_xz_e1 = (-1.0f * glm::dot(n_zx_e1, glm::vec2(v1.z, v1.x))) + glm::max(0.0f, info.unit.z * n_zx_e1[0]) + glm::max(0.0f, info.unit.x * n_zx_e1[1]);
float d_xz_e2 = (-1.0f * glm::dot(n_zx_e2, glm::vec2(v2.z, v2.x))) + glm::max(0.0f, info.unit.z * n_zx_e2[0]) + glm::max(0.0f, info.unit.x * n_zx_e2[1]);

After modifying these codes, the problems mentioned in #7 should not happen again :)

CMakeList.txt only specifies

INCLUDE_DIRECTORIES(${Trimesh2_INCLUDE_DIR})

but it should be

INCLUDE_DIRECTORIES(${Trimesh2_INCLUDE_DIR} ${GLM_INCLUDE_DIR})

if I am not mistaken.

Edit: Reading the readme helps

Hi,

Greate code, I'm trying to compile the code in linux but I'm having a wrong voxel grid (doesn't look ok) than the one in windows? any idea about the difference ?

Thanks

Hello,

I was wondering if your software can generate solid voxels. I noticed that with
the example, I get only the surface voxels.

Regards.

The testing OBJ file: http://s000.tinyupload.com/index.php?file_id=68607642443901015496