Oh God. Please remove this regression or let me turn it off

Hi McNeel team,

This is the most stupid thing I’ve seen implemented in Rhino a long time:

As a customer, I never want to see this. I only want to see my last numerically input value. Not only you are flushing from memory my last numeric input, but you are also now showing me the numeric value of something that was never meant to be a numeric input.

This is just dumb. It needs to go away ASAP.


PS: I do not want to argue with the very rational, eloquent, control-freak that convinced you all that this is a good idea. Yeah sure, this is very rational, but also Asperguian and the most shitty UX. I can’t even believe I have to come here to make this point. I really worry about Rhino sometimes.

1 Like

Dial it back Gustavo.
Your assumptions and commentary are not helpful in this case.
This is a bug.

I don’t recall the specifics but I’m sure one of the other techs will.


so what is correct? only manual input should be remembered?

Hi John, I’ve been seeing it discussed here before. I think it’s a feature, I just looked it up and @pascal Pasca called it a feature here:

When I dial it back you guys take 3-5 years to fix/add things. Every once in a while I have the right to have a tantrum. I choose those carefully. This time I decided this is tantrum-worthy. So please let me have it…


1 Like

Inappropriate behavior is always inappropriate.
I’m on a knife edge as to kill this thread or not.

I’ll leave it up for now in case there is a useful response.


Yeah, I am getting that the general vibe is not in favor of this -

RH-65698 Gumball - extended format on stored distance values

I’ve asked Mikko to undo…



I experience the same problem when I move objects with the Gumball, either manually dragging with Grid snap on, or by typing the exact value I need. I like both of them. However, the problem is that when I drag manually and Rhino’s tooltip says that the distance is, for example, exactly 5 mm (after all, I use Grid snap, so it’s always a whole number), any subsequent repeat done by using Gumball’s ability to remember the last used value results into some totally random and confusing number like 4,999999532 or 5,000004257. :slight_smile: If I enter an exact numerical input by typing 5, the next time I use the last remembered value Rhino also tends to use its own logic and displays random number with plenty of 9’s after the decimal comma that are not exactly a whole number. :upside_down_face:

It would be totally fine if that random number was a result of dragging (or rotating) without Grid snap on, but the main issue is that it happens with active Grid snap which is supposed to always force use whole numbers for the manual dragging.

I propose for this feature to work in the following way:

  1. When Grid snap is turned ON while dragging an object manually, or an exact numerical value is entered in the box (such like 5 mm), the last remembered value must be a whole number, too (5 mm again). This means that Rhino should never show random numbers behind the decimal comma if the user only entered whole numbers for the distance of moving or angle of rotation.

  2. When Grid snap is turned OFF while dragging an object manually, the last remembered value must be the exact distance used for it, including the numbers after the decimal comma.

I disagree for 2 reasons:

  1. snappy dragging does not equal grid snapping. You happen to choose grid-snapping on your modeling so you see that gumball will snap to grid, that’s not a universal case. It will snap to whatever it finds nearby, or even really far away objects but ‘close by’ from a camera POV, which is truly awful IMO.

  2. There’s no way to tell visually if your gumball is set to snappy or smooth. You only discover in which mode you are after you start using it. This is also another truly awful design oversight.

So please let’s not make more bad UX decisions that are just dependencies of other existing bad UX decisions.

I just want an option so I can never see in my numeric fields the recorded numeric value of a prior manual dragging. Regardless of this tool staying or going away, or what others think, I just want an option so I never see it again.



1 Like

Yep, that would be a fairly accurate analysis based on the posts here…

I haven’t seen a lot of people jumping up and down saying “Yay! This is a great feature!” in regards to this. :thinking:


I have never mentioned the “snappy Gumball” option. :slight_smile: I mentioned “Grid snap” only. :wink:

I do agree that the manual dragging value should be an option that could be turned on or off by the user, because some people like it, while others don’t. So, making it an optional thing would suit the use case for everyone.

I’m with Gus on this one.
I think tantrums are great, they show an emotional state, but I also think that headlines like these doesn’t add value to the context as they are click-bait based. (But that said, I would have ignored the thread if it didn’t lure me in!)

So +1 to both Gustavo and John :wink:


am i misunderstanding this maybe? you guys are not complaining about the manually moved values? i quite like them

it is.

ever since it was introduced a couple of weeks ago i came to appreciate it. one could argue if gumball move should generally avoid decimals of that magnitude but the gumball is also and maybe even most of all a manual helper, please dont make that a control freak tool indeed unlike gustavo actually states.

1 Like

Hmmm … wouldn’t a couple less significant figures and deletion of trailing non significant zeros help ? :slight_smile:

Apparently it cannot be done - all or nothing… But wiping out previously typed values seems like the most convincingly bad thing, to me.



why not having 2 values, one for clicking the gumball, one for dragging it, manuell value recall could happen by for instance with dragging and hitting space while dragging

It can be a handy feature, if you happen to snappy drag a whole number. Simple example: if you snappy drag a box that is 20 high, vertically to its corner, you can click /enter to repeat this 10 unit move.

as for the UI:
In case it’s not a whole number, instead of showing the 4.999992342342342 it could show (5.000) indicating it’s a rounded number being displayed (and behind the scene let it use whatever it wants)

edit: rounding is actually consistent with Modeling Aids cursor tooltips

1 Like

so what are possible workflows behind this ? what is the need for the transformation-numbers being stored ?
i made a suggestion here:

and i thing this would be a very nice general tool / approach to cover most needs.
would love to see your comments on the topic linked above.

Merry Christams everyone! :christmas_tree::sparkles:

+1 to dial down the candid tone but also +1 to the request to reverse this.

I have yet to come across a scenario on which I use the automatically stored value.

Honestly it is not even rational.

Having it overwrite the manually inputed value is just crazy.

Basically, when you select one of the gumball’s grips and drag most likely you are looking to eyeball a value, or maybe snap it. In any case the value will not be meaningful at all. Statistically speaking, most often than not it won’t.

When you instead click, and type, you are looking to make a precise movement, it already has more value than the previous gesture.

Most often than not this value represents something in your model. An offset value, a height, a width, a grid dimension, etc.

But I have given up on the Gumball a while ago. I am sorry Rhino team. I do love the snapping feature, that works great, but aside from that every live modeling session in a Teams or Zoom meeting Rhino’s Gumball is the laughingstock. It just so crazy it can’t even make an oriented bounding box and calculate axis based on that. It feels so random… and don’t get me started with SubD and sub objects :persevere:.


You can check post #69 in the link below. Yesterday I wrote something about a possible solution, but it all depends on the Rhino developers if they would like to implement it: