Then, I found that the Gumball will not position itself between all edge loops after selecting one edge loop and then using the “Select edge ring” tool. Instead, it remains focused on the edge loop that was selected initially. This is strange, because the Gumball always behaves in a predictable way while using the NURBS tools, but seems like it has a totally different behaviour with the SubD selection.
Even though I could still press the white circle of the Gumball to access its quick options and reset it to an automatic location, Rhino 7 will follow its own weird logic and will not set the middle point at an equal distance in-between the 4 edge loops (all of them are symmetrical in this example). Instead, it will prioritize two of the edge loops and will place itself on the left side.
Even though the Gumball was set between the edge loops on the left side (see the image above), it lead to another confusion after I held the “Shift” key and dragged the tiny “grid” of the Gumball to Scale 2D the selection. Look like the “Scale 2D” function in this case will behave in a very unpredictable way, setting the base point where the mouse pointer was located upon pressing the left mouse button to scale the edge loops. This makes it impossible to scale properly from the center of the Gumball using that method.
I hope that these issues could be fixed in the next service releases. I find the SubD interesting and quite useful for certain shapes, but the unpredictable relocation of the base point makes the modeling work somewhat confusing and forcing me to press the Undo icon way too often.
It’s a promising modeling technique for organic tools, though I can see it still lacks some tools that make the current implementation a bit slow compared to similar Catmull-Clark subdivision techniques in other programs such like 3ds Max.
Also, some icons for SubD could be improved to make them easier to understand.
Yes, I’m aware that it works in this particular case, though it would be nice if the extra mouse clicks needed to manually align the Gumball to the most logical location could be avoided in the future Rhino 7 releases. It’s not just about speeding up the workflow, but also to prevent inaccuracies caused by the improper base point used for Scale 2D.
I think the limited toolset, some of the buggy/untested implementations, and the room they create for mistakes are the main reasons we mostly stay away from SubD modeling in Rhino. Yet we really appreciate having SubD support in Rhino to be able to bring in models from other software, and even so some small changes/edits.
Also for those who have not used much SubD in their work outside of Rhino, the current V7 tools are a massive improvement, as compared to trying to do all concept iteration/exploration in Nurbs.
It’s a journey… sometimes I get really frustrated by it, then I have to remind myself that compared to any other MCAD/technical 3D package, having what we have now is pretty awesome.
This is the key, I think. Blender is free and has had a decade of development on their SubD tools.
I didn’t bother to learn IMA when Catia got SubD, I didn’t bother to learn Speedform when Alias got Subd and I am not going to learn Realize Shape in NX. They (and Rhino) can all import from Blender anyway.
It’s not just about speeding up the workflow, but also to prevent inaccuracies caused by the improper base point used for Scale 2D.