|
|
|
|
|
|
by berkut
2244 days ago
|
|
|
Subdivision surfaces end up as curved surfaces when rendered, i.e. an approximation of the limit surface, but the modellers most definitely do model them as polygons in the DCC apps. Some of the studios still don't even bother with crease weights and still "double-stop" ends with extra vertices/faces to create hard edges. My original point was that it is possible to render subdivision surfaces without dicing down to micropolygon (i.e. you approximate the limit surface with Gregory Patches or something), but only if you don't have displacement: as soon as you need displacement, you pretty much need to dice down to micropolygons, and in this scenario, the geometry representation can be extremely expensive in memory with large scenes. |
|
|
Yes, right, I know. I phrased that poorly, so I guess I should give BubRoss a break. The point I’m trying to make is that starting with the idea of polygon modeling, and starting with the idea of subdiv modeling, are two different things. If we’re talking about subdiv modeling, they it should be called subdiv modeling. Modeling “polygons” doesn’t just automatically produce decent looking smooth models and good connectivity and UVs, you have to use subdiv tools while you work.
That you can render subdivs without subdividing is related to what I was trying to say, that these surfaces are higher order, have an analytic definition, etc... they’re not just polygons. I guess it’s a good thing that subdivs are so easy to work with that they’re equated with polygons.