The hair in the soup – (that’s what I wrote a few posts further above) is that there’s no limit surface based
SubD modeling approach yet, which actually provides production grade geometry. Until now I see no added
value over utilizing any SubD-package and converting a carefully shaped mesh cage to Nurbs.
What – just as a game of thought – if one used the less stony path first?
With a mesh-based solution, one should have something pretty cool running after a year or so and likely also greatly better support for 3rd party created SubD meshes. One could convert all this stuff (native and imported) to Nurbs and would end up with the geometry quality one may achieve with popular SubD plugins for Rhino. Autodesk just announced EOL for Tsplines in Rhino…
McNeel could use more personnel resources for providing a truly convincing workflow, e.g. with a more feature rich Gumball, editing in symmetry, possibly the introduction of local coordinate-systems – all stuff which is crucial for SubD editing in general.
Users could slowly get their feet wet with a new modeling paradigm, had fun and got usable output.
The big brains at McNeel – as time allows and silently in the background – would crack some real tough problems having to do with Topology and Trimming and such. When done with all that one could swap the whole system to Limit Surface based. Any user who previously tried the mesh-based solution was well prepared – workflow and strategies remain the same.
Here’s some random web-collected geometry, which got modeled using Mesh-based SubD.
