Gumball improvements!

Hi all again!
@Joshua_Kennedy @Gijs @Rhino_Bulgaria @martinsiegrist @gustojunk
Excuse me for tagging you all.


Wish 1

Gumball handles visibility.


In this picture two arc handles (green and red) and one arrow (blue) are mostly useless.
The same way we have “Plane visibility angle” option for plane handles, is it possible to have the equivalent option for arc and arrow angles?
This would be useful to simplify the view while working, making it lighter and cleaner.


Wish 2

More obvious UI difference from mode to mode.
New Gumball “Align to Object” mode is really good while working with SubD!
Before this I always had Gumball set to “Align to Cplane” mode, and rarely changed it.
Problem:
Now, after editing control points, I forget the mode is “Align to Object”, and for geometries like this:


I might move it with the gumball thinking it’s moving on the CPlane or World/absolute, but instead it’s “Align to Object”, and in this case will slightly go off, a tiny angle away from ortho = messed up the position and I’ll discover this late when this potentially had already ruined many other geometries.
Solution 1:
Add tiny texts:

World - CPlane - Object

Solution 2: (best option imo)
Colors palettes!



(actually “Object - UV” and “Object - control points” can share the same palette)
(Also note, I’m not asking for this specific palettes, but to give the idea… I’d like pure RGB for world directions though…)

In my opinion, this should need a tiny mini global rework (just colors, no months of work).
Even for the CPlane appearance itself, currently you can’t distinguish if it’s a world-orthogonal plane, or a generic CPlane!! (this is actually serious matter!)
This color change would and should apply to any UI elements that relate with direction, like the gumball.

This is the general idea. Without adding UI elements that clutter the view, simply by changing the colors of handles of the Gumball the user can intuitively avoid mistakes while working.

Importance of coordinate systems: World > CPlane > Object
Additional perk:
If a direction of a gumball (or CPlane axis) is actually perfectly aligned with a direction of a “superior” coordinate system, use the color of that superior direction!
With this, while working the user can constantly monitor and verify the direction of the geometries is correct and nothing is going out of place! No extra UI elements or interaction!


@Joshua_Kennedy in my last picture “Object - control points” the plane handle colors are not matching the arrow directions, the plane is not aligned with any arrow pairs.
It would be cool to have specific plane handle for every arrow-pair in a gumball, but this might be overkill.
If that plane is meant to be World-aligned, again the color solution would be really useful here, more obvious UI and UX.
Also , it would be useful if we could press SHIFT to constrain the movement to one of the 2 directions of the plane handle, like a mini ortho mode.


Sorry for the long post. I think this is worth it.

In Rhino 7, the Gumball handles that are not usable in orthographic views are hidden.

P.S. I love the alternative colours in the last image (OBJECT - Control points).

Might be better by the white dot. Don’t think necessary on every axis.

But yes I agree 100% that the orientation state of the gumball should always be visible where the modelling is happening.

The current white ball options handle does not give any visual feedback about the active mode. That can be changed with a mode-specific icons shown in the images below.
The 2nd purpose of these is to be able to cycle between all Gumball modes in a quick and intuitive way. No need to reach the Gumball settings.

This proposal is old:


I just made this extra image to further develop the proposal. Note that I set a different icon to each Gumball to make it clear how this should work. Obviously, the “View” mode should change the look of the Gumball to be parallel to the view.


Note that the extra “Drag strength” handles could be used with both, LMB and RMB. In this case, the LMB and RMB will do the following:

Move handle with LMB: move with 5% drag strength (can be set to any other value);
Move handle with RMB: move by 1 unit (can be set to any other value);

Rotate handle with LMB: rotate with 5% drag strength (can be set to any other value);
Rotate handle with RMB: rotate by 1 degree (can be set to any other value);

Scale handle with LMB: scale with 5% drag strength (can be set to any other value);
Scale handle with LMB: scale by 1% (can be set to any other value).

I see you’ve been lobbying for your needs for a long time, and rightly so. I don’t know how realistic it is to expect your proposals to be implemented. I had similar thoughts regarding VisualARQ objects, where the standard Gumball doesn’t work all that well. I don’t know if this is still true, but I believe 3rd party developers can’t do much with the Gumball. It would be great if they could. Various types of specialized software and workflows could benefit from their own custom Gumballs.

@mikko @Joshua_Kennedy

I’m not a developer, so I don’t know the details - how do things stand in 2026? Could you consider allowing plugin developers to “easily” create their own Gumballs and the scenarios in which these custom solutions would be triggered (depending on the selected objects, etc.)?

Having a direct access to both, normal speed and “Drag strength” speed is something that will benefit many users across many industries. Other programs like Alias rely on fine adjustment via “Drag strength” (they use a different name, but the principle is the same), but the process is cumbersome in both, Rhino and Alias. The reason is that both programs lack a proper dual-speed Gumball. The user is forced to constantly switch between two speeds or reach a slider to adjust the speed every few seconds. The “Drag strength” handles solve that problem.

Note that one of my proposals is to have a dual-speed capability even by using the current regular Gumball handles with the right mouse button (RMB), keeping the same clean look of Gumball.


The extra “Drag strength” handles expand that capability by offering adjustable “step adjustments” described in my first post above, after the 2nd image. Currently, the used can get non-adjustable “step adjustments” by activating “Grid snap”, such like:

  • Moving every 1 unit (there is a bug with “Smooth dragging” mode, only “snappy dragging” works properly for now);
  • Rotating every 5 degrees (Ortho must be turned off for this to work).

My proposal solves both of these issues. because the user is not forced to turn on or off “Grid snap” and “Ortho” if he or she uses the RMB function of the “Drag strength” handles. They are supposed to override both “Grid snap” and “Ortho”, offering a customizable “step adjustment” (the user can customize the distance for moving the object, the angle of rotation for each step, and the percentage of scale with each step).

Its true that the gumball is challenging to use as a 3rd party developer and even as an internal developer for that matter. However, one of the new features of v9 is a series of on screen viewport widgets that can be customized that are very easy to work with for a developer. You can see many of us starting to create things and use them in things like the ArrayCrv command grips, the new Patch revamp, the new Grasshopper in viewport sliders and grips, and even the in viewport MarkUp command buttons and icons. It’ll be interesting to see how these flush out over the next couple of versions of Rhino and how many commands and new commands they invade. I think it’ll be a lot!

Yeah I’ve seen that… I’m happy this is happening. It was due. It was time.

@Rhino_Bulgaria your picture suggests having almost twice UI/handle elements in the viewport.
While I’m curious and I’d like to test such idea, I think they are a bit too much UI elements.
I think having less is better, if it’s possible to not lose functionalities.
And it is possible! Use different colors (as in my first post) or, for example, by exploiting right and middle clicks, which currently are not used at all (on gumball widgets UI elements)…
There is plenty of room for improvements.

Note that my proposal has 3 different “layers”:

  1. Adding a RMB functionality to the existing Gumball, so no visual changes are needed to achieve it;

  2. Super Gumball with extra “Drag handles” handles that unlock fine adjustment (with the LMB) and the ability to move, rotate and scale in steps (with the RMB). The user must be able to customize which handles will be visible, so those who are afraid that the Gumball may become a “Christmas three” must have no worries at all;

  3. Adding a new functionality to the white Options circle (cycle all Gumball modes with the LMB, quick reverting to the default CPlane mode with the RMB) and replacing it with a dynamic icon that changes its looks depending on the active mode.

Also, note that certain objects and sub-objects need only a small amount of the Gumball handles. For example, Gumball shows only the Move handles when a single control point is selected, which makes it very clean looking, because the Rotate and Scale handles are hidden then.