PDA

View Full Version : CCsubd or not?



Pensart
12-19-2013, 01:51 PM
Just wondering, what kind of subd's are you guy's and girls using?
Is anyone using the ccsubd, and any tips why to use them or why not?
Problems with weights? or other problems? I havent really used them.

Greetz,
G.

Ryan Roye
12-19-2013, 02:00 PM
I use the default subpatch for performance. CC subpatch simply slows down things too much in both layout and modeler... unless there's something I'm doing wrong or some additional step is required to make it manageable that I'm not aware of.

SquishyAni
12-19-2013, 02:09 PM
Slows for me on my end also.

Pensart
12-19-2013, 02:36 PM
I was secretly hoping that they would be better in the latest release. So, back to the regular subd's then ;)

eV1Te
12-19-2013, 02:36 PM
I think that CC is slower only because it creates more polygons per "level". Someone can correct me but normal subd scales with level^2 but CC scales by (2^level)^2.

So when using CC you can lower the level without loss in detail (in modeler you can set the default level for SubD and CC separately)

Sensei
12-19-2013, 02:37 PM
Slows for me on my end also.

Default sub-division level is 3 for sub-patches and 3 for cc, if I recall correctly.
Which means sub-patch generates 3*3 = 9 real polygons,
and cc is generating 2^3 * 2^3 = 8 * 8 = 64 real polygons.
That's 711% more.
Obviously the more math cpu is doing, the slower it's calculated.

Other apps have just cc, and you have no way to compare their efficiency.

hrgiger
12-19-2013, 03:41 PM
Here's a diagram I made up to show the difference in levels between Traditional LW subpatches and CC subdivision. You can see that at lower levels, cc's are similar to subpatches that are one level above them. However, that difference increases with each level.

118797

Having said that, CC subdivision in LightWave has some issues to be aware of- For instance if you use edge sharpness (which is part of the large benefit to using CC's in the first place over subpatches), if you mirror your geometry over, your mesh will break. Its been broken since it was implemented in LW9 with no signs of being fixed. I'm hoping they just go with OpenSubdiv in the future.

Of course another benefit of CC subdivision is that it will allow ngons to be subdivided. However, I find this to be of least concern, generally I try and stick with quads and occasional tris whenever possible. If you're thinking of using CC subdivision so that you can use it with Booleans, stencils, etc.. I wouldn't recommend that. That's just sloppy practice.

SquishyAni
12-19-2013, 04:46 PM
Learn something new everyday. That clears up a ton. Good to know. Thank you!

Sensei
12-19-2013, 04:51 PM
I'm hoping they just go with OpenSubdiv in the future.

It wouldn't change anything in department of "keeping additional per polygon/per edge data"... And the all existing tools would break it the same way, as they are breaking CC.

BigHache
12-19-2013, 05:03 PM
I have not been satisfied with the poles on traditionally subpatched spheres. They seem to pinch now matter what (all quads too). CC subdiv seems fine however.

Except for spheres, I like to stay with traditional subpatch to make sure I'm quad compliant. It just feels too easy to get sloppy with ngons by going CC.

hrgiger
12-19-2013, 06:10 PM
It wouldn't change anything in department of "keeping additional per polygon/per edge data"... And the all existing tools would break it the same way, as they are breaking CC.

Well that doesn't make any sense to me because I can copy and paste some CC subdivided geometry that has edge data/sharpening on it and it doesn't break. Comes out fine. You're telling me they can't build a mirror tool that doesn't break the per edge data?

Sensei
12-19-2013, 06:14 PM
For non-programmers most of things don't make sense..

I mean- if opensubd is using per-polygon per-edge (edges don't exists btw) data, the all existing tools will be breaking it, the same way as currently existing tools are breaking cc edge weighting data.
To support not breaking cc edge weighting data, there are needed to be rewritten/adopted the all hundred tools existing in application, and hundred 3rd party tools.


You're telling me they can't build a mirror tool that doesn't break the per edge data?

Sure it could be done. I adopted mine EasySplit to not break CC edge weighting after release of LW v9.0 when they were introduced.
But for whole application it means hundred rewriting/adopting.
Enormous amount of work, for so little.

tburbage
12-19-2013, 06:25 PM
I have not been satisfied with the poles on traditionally subpatched spheres. They seem to pinch now matter what (all quads too). CC subdiv seems fine however.

Except for spheres, I like to stay with traditional subpatch to make sure I'm quad compliant. It just feels too easy to get sloppy with ngons by going CC.

If you want a spherical shape for subD'ing, you're better off starting from a cube and subdividing using Divide: Subdivision method=Metaform once or twice, then go into your choice of SubD mode. SubD algorithms can't deal with poles...

Pensart
12-19-2013, 08:45 PM
Thanks for all the explanations :) Makes sence now

BigHache
12-19-2013, 09:55 PM
If you want a spherical shape for subD'ing, you're better off starting from a cube and subdividing using Divide: Subdivision method=Metaform once or twice, then go into your choice of SubD mode. SubD algorithms can't deal with poles...

Cheers. I'll give that a go.

prometheus
12-20-2013, 12:34 AM
Cheers. I'll give that a go.

exactly as tburbage mentioned, even though you said you have a sphere with all quads, there are to many polys sharing the same end/pole point, and besides if you created a simple sphere... the top of such a sphere isnīt consisting of quads, those are triīs.
You could use the fix pole command, selecting the top tri polys of the sphere and run the detail/polygons/more/fix pole...command, then select the newly created top polys and run the command again, this creates more polys on the top of the spere to even
out the pinching, alternativly, you select just the top point of the sphere and run the fix pole command twice.
fix pole add additional geometry on the poles ...so that might not be what you want.

Otherwise, metaforming a cube twice and the subdiv will be fine for many cases, not sure they are truly surface spherical with that approach, since you can see some slight quadric surface bulging at times.
Using tesselation upon sphere creation instead of the globe type, will also provide a sphere without pinching, but then you got all triīs.


Michael

Amurrell
12-20-2013, 08:06 AM
In normal subdivisions the number you set is the integer squared so subdivision of 3 is 3^2 or 9 per polygon, Catmull/Clark you are setting the power where the integer is always 4 so the same setting will be 4^3 or 64 per polygon. You can see this by taking a plane and adding both subdivision types and freezing them, if you were curious.

so where X is the value entered in the subdivision setting

Simple subdivision = X^2

Catmull/Clark = 4^X