incoherent face orientation in marching cubes

[Josh Warner]

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.

>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 
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20140106/bb5e9dbf/attachment.html>