Talk:Marching cubes
From Wikipedia, the free encyclopedia
Contents |
[edit] Missing triangle
The picture in the last column, second row is missing 1 triangle. 60.227.138.153 10:55, 26 January 2007 (UTC)
[edit] Ambiguities
The description given here, as well as the cited paper, give wrong results. There is huge list of follow-up papers that all present an improved version that resolves the ambiguous cases to prevent holes from appearing in the surface. This should definitely be corrected.
- It is true that the original algorithm has ambiguous cases, and that newer algorithms are available to resolve them. But they aren't "marching cubes" (at least that is my undestanding). For instance the Marching tetrahedrons, for which there is already an article, does not have the same ambiguities. However, the original algorithm is also of encyclopedic interest, and dare I say highly usefull too, as many programs use it, regardless of the ambiguous cases (for some applications it makes little to no difference). Thus, my opinion is to retain this article describing the original algorithm, and also make sure it links to alternative non-ambiguous algorithms as well. Jtsiomb 05:36, 12 August 2007 (UTC)
[edit] External Links
"good" starting point?
[edit] Cleanup ?
Since that cleanup tag is there for years now, and nobody came here to say what should be cleaned up, I believe it should be removed. If there is no objection to that, I will remove it in a week. Jtsiomb 05:38, 12 August 2007 (UTC)
[edit] 15 unique cases
The precalculated array of 256 cube configurations can be obtained by reflections and symmetrical rotations of 15 unique cases.
What do we gain with this? I don't see the advantage.. The lookup-table can't be accessed faster, the number of triangles or interpolations is not reduced.. What is the advantage of this reduction to 15 cases? --84.56.176.217 12:14, 5 October 2007 (UTC)
- Data storage perhaps? 15 cases, need less space then 256. But other than this I also see little advantage. But I'm not that experienced with this. --195.169.225.6 (talk) 22:24, 27 November 2007 (UTC)
- I have no experience either, but as I understand you have to write a different piece of code for each of the 15 cases. If there were significantly more cases, implementation would be much less feasible. Which piece of code is then executed for a configuration of voxels is then looked up in the lookup-table, so indeed execution speed is not affected. --CyHawk (talk) 11:37, 31 January 2008 (UTC)
For those of you who have never implemented marching cubes, the issue of 256 cases relative to 15 cases is irrelevant. Neither generates more code than the other, because you dont implement it as a gigantic case statement. You implement it as a lookup table that specifies exactly which cube edges you will generate the triangles from. The result is more like 15 lines of code, and detecting symmetries to 15 would actually make it more complex.
Also, the picture of the skull cannot be generated with a correct implementation of marching cubes. You shouldnt see those axis-aligned ridges and bumps on the top of the head. There is a bug in that code, and it is not an ideal representation for this wikipedia entry. A proper marching cubes implementation at the same cube resolution would make it appear fairly smooth. The problem with the skull may be that the input data has a maximum resolution lower than that of the marching cubes algorithm, too. In any case, the illustration is misleading. —Preceding unsigned comment added by 156.145.28.102 (talk) 00:10, 13 May 2008 (UTC)
