From a cursory look at your example, it seems you're effectively writing a normal of [0, 0, 0] to each face (a 'facet' in STL). This is likely part of
It's not just you. The algorithm is a naive implementation of marching cubes. It does not provide surface normals or specific face orientations, because these were not described in the original paper. All it gives you is faces with associated vertices. These correctly describe each face in 3D space, but due to the way the algorithm takes advantage of symmetry roughly half of the orientations will differ from the counterclockwise convention. For some purposes, e.g. finding total surface area, this is sufficient. For visualization, some packages can handle this without issue (if you have Mayavi and run the example in the docs, the ellipsoids are lit correctly). However, it seems STL files really do require normals. the problem. A true normal vector would have length 1, and should be derived from the data. It's possibly why some of the faces appear to be rendering transparent. Once you do a little linear algebra to get surface normals from face vertices, then you'll run into what I described above. I would like to support this feature, though, and have a few ideas on how to tweak the current implementation to fix the orientation issue. On Monday, January 6, 2014 5:34:22 AM UTC-6, Janto Dreijer wrote:
I am trying to create an STL file from the results of running marching cubes. Attached is the modified version of the marching cubes usage example from the documentation. It seems that skimage does not yield coherent face orientations. See attached image (the gaps are faces in the other direction).
Using meshlab's "re-orient all faces coherently" command seems to help a bit...
Is it just me or is this a bug in skimage?
Regards Janto