No, I consider not having mesh based subdivision levels exposed to the users and only having a toogle between super low res + edgy and perfectly smooth (á la Tsplines) a major disadavantage. Perhaps one should not do what seems most straighforward from a mathematical point of view. But I wonder if I can get across what I mean…
-
Being able to see the cage at all resolution states is very helpful. When shaping a freeform volume from scratch it is common practice to start off with an extremely lose cage. Good modellers in this minimum complexity state already define all mayor features of the shape, they have developed a good sense of the way a shape develops in in smooth state - but one will want to have a peek here and then. The higher SubD states had to appear absolutly instantly, having to wait for a transformation (miliseconds to many seconds and minutes) as in Tsplines sucks.
At some point the low res mesh should be collapsed, so that one has some more geometry to work with. In traditional SubD one can simply freeze the mesh approximation at the currently displayed density. Wysiwyg, no mode change required here. -
interoparability with mesh software.
With mesh based approximations one can simply send a the present state of a mesh over to Zbrush to use a single tool here, from there bring it to Modo to unwrap and finally send it back home to Rhino as a mesh with the same basic topology, with some vertices in other places and proper UV’s, while the mesh inside Rhino has retained its SubD history. This ability was very vital generally, but particularly useful in early states of the Rhino implementation, with just a very slim feature set.
2a) again UV’s: There’s hardly anything more elegant as the way UV’s work in in mesh base subdivision surfaces. Slice the mesh at basemesh level and reproject to any higher level. There sure are options rebake existing UVs to true SubD and back to meshes at export time but that’s a needless source of errors. Tsplines in the last version I have isn’t able to properly retain existing texture data in imported meshes.
-
locked data: Most SubD apps don’t expose the concept of “true Subdivision Surfaces” to the user and will not able to read your accurate data. Maya indeed as an exception has this dual system internally, but I’m not sure it can read true Subdivion Surfaces from other sources.
-
Performance: I simply doubt that interactive preview in all modelling operations (not just subdivision) will be as fast mesh based subdivision surfaces.Tsplines after ten years of development isn’t but mesh based previews are. If things still get too slow one can simply step down one level. It’s proven, it just works.
-
Convention: Touch and feel of Tsplines, Clayoo and the like simply will not feel attractive for someone with a background in mesh based SubD and used to the snappiness of editing here.
-
What does one actually win by giving users accurate Subdivision Surfaces? This is an honest question. Also in Tsplines there’s brilliant options given to create perfectly curvature contionous – but still all lumpy blobs. I my opinion one rather needed to develop deeper strategies for for the smartest sythesis of Nurbs and Mesh in interactive modelling. Only representing inaccurate hand-sculpted geometry accurately througout the modelling process does nothing good in its own rights, imo quite the opposite.