@eobet turning on control points should give you a far better experience than using the edit points. Much more compatible with how other mesh modelers work as well.
That doesn’t take away the fact that Gumball experience on edit points needs improvement.
An easy solution for this is to simply re-align the Gumball upon taping the Tab key that switches the smooth state of the SubD geometry.
Rhino 9 BETA already does that manually when the control polygon is visible (through the ! _PointsOn command) and the SubD is rendered smooth. The user is allowed to pick either the true control polygon or points, or the smoothed out ones. The Gumball aligns to the geometry in either case.
However, one notable difference is that selecting a control point of the actual control polygon will enable all arrow handles along the control polygon vectors, whereas selecting a “smoothed out control point” will only show 3 arrow handles plus 3 rotation handles (even though it’s useless to rotate a single control point).
The edit cage is too distracting. Also, the only other mesh modeler I currently use is Blender, and I enable the subdivision modifier in edit mode there as well, so I don’t have to ever see the cage.
Also, just noticed in another thread that I at one point managed to get the UVN gumball without the cage… no idea, how, though.
If this is possible, is there any reason we can’t have multiple simultaneous UVN gumballs?
Like, grab several subD faces, turn on multigumball, and pull on any of the multiple gumballs’ N handle, and instantly raise a bunch of bumps or spikes?
@eobet yes I found that button, but couldn’t figure out how to align the gumball to it. The gumball on my end stayed aligned to the box mesh vert.
Since Blender has 1 button modal shortcut keys, I don’t need a gumball in Blender 
(the gumball itself can also be distracting when you’re tweaking shapes).
Am I missing something, or is there a way to switch back to standard ‘Move’ instead of ‘Move UVN’ while staying in ‘Align to Object’ mode, like in Rhino 8? Right now, it seems like setting it to ‘Align to Object’ forces it into ‘Move UVN’ mode.
Addition: I noticed an odd behavior while recording a screen capture for this comment:
Object selected first, then points selected > Gumball uses standard Move.
Points selected directly > Gumball uses Move UVN."
… I can replicate this bug. ^
I sort of feel this is related to this (which still got no replies…)
The double-click on control net to get loop selection need some cleanup.
I never ever use “Align to Object”, because in that mode Gumball directions are unpredictable, unreliable, even “dangerous”.
Most of the time I have “Align to CPlane” instead.
But, for the new feature of moving grips along control net + normals, “Align to Object” is now a must.
Would it be possible to have two “Align to” modes active at the same time?
A mode for generic selections > current normal behavior.
A mode for when only grips are selected > here I would have “Align to ControlNet” most of the times (or sometime again “to CPlane”).
Currently you have to constantly swap mode… or even worse, you might not remember the mode is not CPlane/World but Object, and make edits that will later turns into errors (because “Align to Object” is unreliable).
This leads to:
I did made a color palette proposal here:
Absolute XYZ > pure RGB colors
CPlane XYZ > slightly darker colors
Object UVW > slightly lighter colors
Object grips > different colors
(and this could and should apply also to Grid axes colors…)
Currently we have always the same 3 RGB colors applied in every context.
It would really help to have the gumball silently suggesting and remembering (and warning) the user that the mode is World/CPlane/Object mode. Less errors, more clarity, at NO expense in adding new elements to the UI.
Please consider this.
Please, remember to add all control net directions for SubD grips on extraordinary vertices.
It’s enough if to have it you have to select a single grip. Better than nothing.
I agree with having two gumball mode, one for grips selection and one for the rest.
Most of the time I work with Cplane alignment but I switch it to object for “CV massaging”(@theoutside ™) or SubD modeling.
So, apparently when only grips are selected, the gumball align with the control net, otherwise “Align to Object” is used… correct?
Personally, I never use “Align to Object” and I think applying a global blind “Align to CPlane” whenever a non-grip geometry is selected, would be more obvious and intuitive.
Currently “Align to control polygon” if a mix of grips and other geometry are selected:
… this is useful only when you really need to move some other geometry together with a normal of a specific grip (or average of more)… rare if not unique.
Much more common, instead, is to move a set of geometries and some grips, towards some CPlane directions.
Currently “Align to control polygon” if a mix of unrelated grips is selected:
we get again an “old-style” gumball with only the blue arrow aligned to the average of the normals, and the green/red arrows being sort of useless/random.
I can’t see this being useful in any context. I would fear this happening and messing up my model by mistake.
Personally, I imagine “Align to control polygon” optimal this way:
Personally:
Align to CPlane = accuracy
Align to Object = errors late in the project
… different color sets to differentiate gumball directions (World XYZ, CPlane XYZ ,Object UVN, ControlPolygon) would be awesome.
Please remember the gumball for a lone-selected extraordinary vertex grip.
