Hi all,
I don’t think my Gumball is working as intended here on Rhino 7.
I create a subD primitive, cylinder, rotate in Z and Y with gumball, this is what is looks like. GOOD.
Deselect geometry and reselect:
Aaaand I can no longer scale.
I noticed this does not happen with a primitive NURBS cylinder.
Pretty sure this is the case with all SubD geometry…
Hello- is all of the selection and de-selection done in the same viewport?
-Pascal
Hi Pascal,
I ran into this yesterday too no scale handles showing up in subd. Very similar case to the user.
RM
I am not talking about no scaling handles though. Just the gumball position resetting to world when it is set to object.
What I meant by not being able to scale is that as the Gumball gets messed up, I can no longer properly scale my geometry from center in one direction.
Yup.
Also why does this happen?
It seems like when I select an edge loop which forms a planar surface, the gumball isn’t aligned…
When I create the surface out of the edge loop the gumball axis are aligned correctly:
It is really hard to work like this when the gumball positions itself randomly and not aligned…
For example this edge being view from top, I want to scale it in z direction only without truncating my geometry.
This is the result when pulling from z (blue) handle:
And this is expected:
Hello - Gumball, if set to align to object, can only do that where a plane can be found in the selection. So for your planar surface, planar curves, no problem; extrusion objects contain a plane in their definition; but polysurfaces or multiple selections do not have a single unambiguous plane that can be used, so Gumball reverts to CPlane orientation in these cases . Does that correspond to what you are seeing?
-Pascal
Hi Pascal, I understand, but I don’t think this is the case, I am talking about edges forming a planar surface. Meaning, Gumball should be able to find the plane these edges lie on an align accordingly…
Same planar shape: 3 different alignments: (done with photoshop not sure how to display this in Rhino)
SubD edge
Curves
Planar Srf.
The correct one being the planar surface. It should be like this in all cases.
PD: This clearly has to do with my original post, all in all showing certain inconsistencies in how the Gumball behaves… I expect my OP to be addressed too.
Create 2 identical cylinders. One NURBS the other SUBD. Starting Gumball:
Rotate Gumball 45 in Z, and 45 in X: Notice the difference:
Why is this important? I can still scale and transform left NURBS cylinder with gumball.
Can’t do the same with SUBD’s cylinder
This is standard in every 3d software…
Yeah, I guess the difference, as before, is that the cylinder has a plane that the Gumball can use and the SubD does not. I do not know if there is anything to be done for the SubD case - but it is not different than say a blobby surface ort an arbitrary curve - that will also reset in the same way. Currently if you set a custom Gumball position or orientation then it is persistent for the object.
-Pascal
Why do I get the feeling you are fighting my feedback/needs/wants instead of welcoming them and seeing what can be done in the future to improve this?
Bugs and bad design they both need fixing alike. This is not a bug, I get it. It doesn’t make it right.
A primitive shouldn’t behave like this… that is why there was a conscious decision to make its NURBS equivalent retain its alignment after transformations. There is literally no use for the gumball if it resets back, like I have shown.
I guess I will use this as a workaround, but sometimes it is very time consuming and difficult to re align the gumball back. I would need to move the Gumball x amount and then -x to make it stick before deselecting my geometry…
Also, it does not remember for sub-objects…
But this is a primitive…
Also, in this example I showed 2 things that were not ‘blobbly’, but planar curves and edges. Why isn’t gumball working as expected here?
Is this blobby enough for you?
I am barely starting to get into SubD, maybe I am just not getting the flow of it, but how can I easily and rapidly scale this radius in one direction (as if I had a Gumball) when I don’t have one?
Result (Left) vs Expected (Right) Notice how left ring is totally deformed (because of the default position of the gumball) and Right ring was scaled in 1D into an ellipsis.
You might be wondering how I managed to do the right one. I re positioned the gumball manually thanks to center and quads snaps. Besides this being extremely time consuming for such a trivial task, sometimes you don’t have a perfect circle to calculate a center from… and, if you want to re edit the radius, you will have to re position the gumball all over again because it does not remember its alignment for sub-objects! Brilliant! 
Now, why the Gumball can’t figure out the correct alignment of a planar circle is beyond me…
Hi @ShynnSup,
Sorry didn’t mean to intrude on your thread. I also run into what you are describing. I think it’s the one weak point in subd now or Rhino just has too many controls where this orientation of the gumball needs to be more automatic. Feels like a leftover from cplane modeling and having to toggle use move normal command all the time or re-position the gumball.
RM
I have a couple of ideas I can at least ask the developers about that might ease the pain somewhat.
-Pascal
Gumball and BoxEdit were the problem children this year.
I can’t remember Gumball being this uncontrol before.
There is not problem alone on SubD,
On SubSrf and SrfEdges Gumball with option “Allign to Object” does not work !
Thank you.
