Open ryanhlewis opened 2 months ago
Hi Ryan, Sorry for the delayed reply been busy doing other work. I haven't looked at this in well over a year now since its no longer my day job so apologies if i'm a bit rusty. From the error log I assume you are building on windows with the visual studio compiler. I primarily built this on Linux but i got a number of complaints from users who could not pip install it, all on windows. Also 1 on mac but that's a hard no as CUDA is just not a thing on MacOs ( intel or Arm).
Anyway I eventually relented and did a windows build but remember it being a real pain as i hit exactly the same brick wall as you. I did eventually solve the issue but appear to not have made the changes public (sorry about that). As such there exists only of one widows build for python 3.11 on pip. I always intended to come back and cleanup/build more versions. But as always life got in the way.
I think there are 3 separate issues at play here:
1) The glm warnings: those are are a red herring. they are harmless and can be safely ignored, as you have already noticed we don't use glm in any gpu kernels they are just for CPU backup.
2) The real issue compiling with CPU: that is Microsoft visual studio quirk. for whatever reason Microsoft are using a different c++ std to the rest of the world. the solution ended up being a few extra include files locked behind a define for windows and some changes to brackets/types. The Changes are now on a separate (now public) branch called windows build. I have tested on linux with cuda 12 and it builds and appears to run just fine.
3) The brick wall: I think the issues somewhere between conda and pip. Annoyingly I don't remember exactly how I fixed it, just remember bashing, my head against the wall for weeks. The only clue i have is some notes I made called "windows build instructions.txt" that says:
conda activate test conda install cmake numpy pybind11 tifffile pillow cudatoolkit pandas conda install -c conda-forge xtensor xtl meshio xtensor-python
pip wheel .
delvewheel repair CudaVox-1.7.0-cp311-cp311-win_amd64.whl --no-mangle cudart64_12.dll
pip install wheelhouse/CudaVox-1.7.0-cp311-cp311-win_amd64.whl
https://pypi.org/project/delvewheel/
Thus my guess is building a pip wheel, directly including the cuda dlls with devewheel then installing that specifically fixes the issue. Unfortunately I don't have a windows machine readily available to test with but I'll install windows over the weekend and do a clean test.
In the meantime you are welcome to try building it yourself. The cmakelists file you sent me looks like it should work. If you are going to do this i'd recommend first pip uninstall CudaVox or better yet use a clean coda env. Also to check the install you only really need CudaVox. cad2vox is just a pure python wrapper. As such you can quickly test in an interactive python shell with:
import CudaVox CudaVox.
CudaVox.Check_CUDA()
Alternatively for a more through test use the pytest suite (though i think you will need cad2vox for that).
Anyway let me know how you get on and FYI I do have a backup plan of converting it to a full conda build if this fails but that's a bit of work so lets see how we get on first.
Ben
Hey Ben,
Wish I could say I tried everything here- but instead I ended up just implementing what I needed in Forceflow's Trimesh2 library- essentially taking the route you did years ago of trying to modify or get around that old library.
I just added what I needed- which was texture support and GLB support to Trimesh2, as well as added color handling for voxelization. I was doing this all for Voxel Earth (https://voxelearth.org), which needed a GPU-accelerated voxelizer in contrast to our old CPU one to properly convert thousands of 3D satellite geometry objects on demand.
I wish I could say I'll come back and figure out what is wrong here- but since I moved past the problem with my own ad-hoc import/export/texture solution, it's unlikely that I need to work with cad2vox- although in all honesty, the support you have for other models here probably would have been easier (as GLB and textures are natively supported by Meshio) had I gotten it to build! Sorry about that!
Best of luck with your work.
Hey Dr. Thorpe,
I've gone through the usual hoops- installing GLM, XTensor, XTL, changing my CMakeLists.txt to point to my directories instead, and finally building correctly.
I noticed that with later versions of GLM, your cpu_voxelizer.cpp completely breaks, with errors everywhere about syntax, functions being used, and otherwise- no matter- it's not like I'm here for the cpu_voxelizer.
So, went ahead and commented out the references to cpu_voxelizer functions in the python binding and the header, and it all builds correctly- which is great!
However, can it be used correctly? Unfortunately- no. Trying to
import CudaVox
results inImportError: DLL load failed while importing CudaVox: The specified module could not be found.
which I can't get rid of for the life of me, putting the .pyd next to our Python file, putting it in System32, referencing it as os.usedll, trying building to and using four different Python versions (3.6, 3.9, 3.10, 3.11), and yet this error persists.Even with dependencies.exe, an application meant to show if our .pyd dll is missing any dependencies, and wouldn't be loaded in correctly, shows that all dependencies are found. I know this is probably a conda issue, but after trying for hours to do the pip route and WSL2 route with your Dockerfile, I've come to my wit's end. This is absurd.
Could you offer any advice or help here?
I don't believe it's the fact that I've commented out the usage of cpu_voxelizer- that was a clean cut. However- it might be whatever update causing GLM to break cpu_voxelizer snuck itself as a runtime error for our gpu_voxelizer, which is my theory~
To help you out-
CMakeLists.txt
Here's the errors when trying to compile w/o cpu_voxelizer cut out:
errorlogglm.txt
Thanks,
Ryan