Talk:Catmull–Clark subdivision surface

message: >> The new mesh will consist only of quadrilaterals, which won't in general be flat. 
Could someone clarify this?
Does this sentence mean:
"The new mesh will consist only of quadrilaterals. Each quadrilateral won't in general be flat."
or
"The new mesh will consist only of quadrilaterals. The mesh won't in general be flat."
: It means that the quadrilateral won't in general be flat. --Fredrik Orderud 20:40, 4 September 2007 (UTC)
replies: text: It might be clearer to say "planar" instead of "flat". Wadeb (talk) 02:33, 1 July 2017 (UTC)

text: No, Cubes do indeed become spheres when subdivided using Catmull-Clark. Perhaps you're thinking of regular subdivision or are expecting some form of chamfered cube. 71.171.252.81 (talk) 06:25, 6 February 2008 (UTC)
replies: text:  They do NOT become spheres. There is literally no way to create a sphere using a Catmull-Clark surface (meaning x2 + y2 + z2 = r2) -- see NURBS Control Points for a brief mention of this problem. A Catmull-Clark surface generates a series of connected cubic, uniform, polynomial B-Splines, and thus cannot represent non-trivial conic sections. They can approximate spheres (i.e. they "look like" spheres as far as your eye can tell), but no matter how dense your control cage is, you will never generate a sphere. There are more complex subdivision schemes that can create true spheres, but they lose a lot of the elegance of a Catmull-Clark surface, and so are more rarely used. Ahelps (talk) 19:09, 23 December 2008 (UTC)
replies: text:  I just implemented this algorithm using this article as a guide. I got a perfect sphere from a cube, i.e: indistinguishable, pixel-wise, from one plotted trigonometrically. I don't know what you are talking about. Of course it isn't a true sphere, but what method of subdivision yields one anyway? I would be curious to understand what you are referring to.
The weights (n-3)/n, 2/n and 1/n are definitely not the ones used in the images. K-3D uses (n-2)/n, 1/n, 1/n. Similarly every other illustration on CC SubD uses this set of weights.
Here are two movies showing the different Subdivision stages:
(n-3)/n, 2/n and 1/n: http://dl.dropbox.com/u/281539/jReality-CC.mov
(n-2)/n, 1/n and 1/n: http://dl.dropbox.com/u/281539/jReality-CC-2.mov
Clearly the method with (n-3)/n causes the weight to vanish for valence 3. Hence the old vertex has no impact whatsoever in the new location. While there are other approaches
to handle extraordinary vertices, they usually result in less "round" edges because they give a larger weight to the old location of the vertex during the move stage.  — Preceding unsigned comment added by Moritz Angermann (talk • contribs) 16:17, 8 March 2011 (UTC)

text: The confusion seems to lie in the definition of the edge average R. R in the article is defined as the average of the edge midpoints (i.e. the midpoints of the edges incident to P on the original mesh), not the average of the previously computed smoothed edge points. Since these are a linear combination of the original edge endpoints which include the point P, and do not factor in the new face points, one reasons that they lend weight to P. Formulations which have (1/n)F + (1/n)R + ((n-2)/n)P will define R as the average of the adjacent vertices of incident edges from the original mesh, so that the R term does not lend weight to P. I suspect that the two formulations are equivalent. 104.175.160.5 (talk) 16:42, 17 September 2015 (UTC)

text: This formulation is indeed misleading, most likely even wrong. I learned about this scheme in a lecture at university, and our materials say that R is the average of the 'edge points' of the edges incident to the original point P, i.e. the edge points that you computed in the step before. 84.226.52.126 (talk) 20:56, 22 August 2009 (UTC)
replies: text:  I just implemented this algorithm using this article as a guide. R isn't the average of the "edge points that you computed in the step before". The edge points that you computed in the step before have the facepoints factored in. R uses just the edge points. Although I could be wrong in that your way could be OK too. I'm just assuming I'm doing it the only way right because I get a perfect sphere from a cube. Anyway, the formulation isn't wrong. 62.57.227.138 (talk) 05:16, 1 October 2009 (UTC)

message: I find this section rather difficult to understand. A few graphical masks would be of much more help than "face point"/"edge point"/... (btw: are you sure it's correct or do I still not understand it? :) Is an edge point really the average of all neighbouring face points? (I thought the points were only dependent on the original pts?)  —Preceding unsigned comment added by 91.19.90.230 (talk) 13:49, 21 October 2008 (UTC)
thread_title:  Recursive evaluation section