[Bug] Voxellization produces totally inaccurate result

TRIMESH VERSION: 2.14.17

STL FILE

https://drive.google.com/file/d/0B18jNduc8kjldzFuTVRaTFBsLTA/view?usp=sharing

CODE TO REPRODUCE

m = trimesh.load_mesh("the_above_mesh.stl")
vox = trimesh.voxel.Voxel(m,.25,size_max=1e10)
showin = vox.mesh + m
showin.show()

PRODUCES RESULT:

NOTES

The provided mesh is shown to have no problems that Netfabb can detect. Despite this, the underside of the funnel surface looks a little… fishy to me? I’m not sure what problem, if any, this corkscrew pattern of triangles could cause. But that’s where I’m starting my search on this one.

[mikedh]

Ah yeah, the voxel module isn’t very well thought out or particularly well implemented. My general though is that I’d like to switch to using something like openVDB and just do a thin wrapper. Unfortunately that is a royal PITA to install (although if you want to package it for conda-forge that would be sweet 😃.

As a quick thing to try, slicing meshes using mesh.section and then rasterizing using trimesh.path.polygons.rasterize_polygon might do a better job then the ray thing there now.

The data structure is also not great. Maybe it would be better as an octree (pyoctree looked interesting) or as one of the scipy.sparse encodings.

[jonnymaserati]

I see that FCL implements octree and appears to initiate an octree object when creating a collision object. Is it possible to use this for creating voxels?

I’m interested since I’d like to get the node coordinates of the empty voxels in a scene but I’m after the sparsely sized voxels (i.e. large voxels where there’s no occupancy). Is there a way of doing this already with trimesh?