Talk:Catmull–Clark subdivision surface

>> 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)

It might be clearer to say "planar" instead of "flat". Wadeb (talk) 02:33, 1 July 2017 (UTC)

isn't the image wrong? A cube shouldn't become a sphere with catmull-clark! —Preceding unsigned comment added by 85.225.115.25 (talk) 19:15, 30 December 2007 (UTC)

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)

They do NOT become spheres. There is literally no way to create a sphere using a Catmull-Clark surface (meaning x² + y² + z² = r²) -- 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)

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)

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)

>> and take the average R of all n edge midpoints for edges touching P, where each edge midpoint is the average of its two endpoint vertices

Can someone clarify this? Does this mean the endpoint vertices from the original edge or the new edge? Broodle (talk) 02:47, 28 April 2008 (UTC)

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)

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)

Remove section on software using Catmull-Clark

I propose deleting the section "Software using Catmull–Clark subdivision surfaces". It is not especially interesting for an encyclopedia, and it is highly unlikely that this list will ever become all-inclusive. For the moment it is just getting long enough to become a visual distraction to the encyclopedic content surrounding it. --Berland (talk) 09:30, 14 August 2008 (UTC)

I disagree. I do find it fully relevant.

However, does Wings3D really do Catmull Clark? I think it does Doo-Sabin only. Someone can tell for sure?

To help visual distraction, maybe it could be turned into a table.

--Mtarini (talk) 18:22, 26 January 2011 (UTC)

I also believe that 3ds max does not support Catmull-Clark subdivision surfaces but it is in the list.

--Alexk7 (talk) 21:40, 31 March 2013 (UTC)

I also doubt the value of the list. At least, the SW in the list needs to include references to their usage of Catmull-Clark surfaces. I've therefore added a "missing references" box to the section. Fredrik Orderud (talk) 16:57, 6 April 2013 (UTC)

Recursive evaluation section

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)