Gumball bug: wrong explicit scale dimension


(Gustavo Fontana) #1

Hi all, the gumball scale widget has a weird bug. I’m placing it in the right anchor location and I’m trying to get a desired distance, but I’m getting double that distance instead. take a look:


(Willem Derks) #2

Hi G

On a related note check the latest change for the gumball scale handle:


(Gustavo Fontana) #3

oh God. that’s for that link Willem, I see that @clement also got tricked by this. I vaguely remember discussing this with @pascal when I asked for this feature and it was first implemented. BUt now using it more I realize that it’s so terribly broken and I don’t think this makes any sense because:

  • you have a selection that has a known XYZ bounding box, with known X1,Y1,Z1 lower limits and X2,Y2,Z2 upper limits.
  • you have a gumball with knows XYZ location.
  • you know where the gumball is in reference to the selection’s XYZ values. So you should be able to determine that when you input Xmm you want to scale in the X axis to reach a distance of Xmm, not 2X mm!

I think the problem here is because it’s starting with the already confusing assumption that if the gumball is at the midpoint, when you entered a desired scale target you really mean 2X that number, but you like to so math in your head for no reason. The only reason I see it’s because it’s consistent with the scale tool behavior, if pivot is on center. But equally consistent if pivot is on one extreme side.

I think this shoudl be fixed. It’s terribly confusing right now.

thx,

G


(Willem Derks) #4

I see how this is confusing , especially when the gumball is off-center.

@mikko About the feature to use a units suffix of the input: would it not be better to make the user explicitly state input of factors and assume units by default

So input 2 would shift the scale handle 2 units outwards of the center. ( Negative values would shift inward)

And input *2 would multiply the distance between handle and center by 2, allowing for scaling by a factor.

It’s at least less cumbersome than having to enter explicit characters for units. As the * is at hand in the numpad for most keyboards, and you do not have to know the document units.

Still @gustojunk you are asking for another type of behaviour when inputting units: you do not want a shift like with the translation arrows of the gumball. Rather you want the value entered to become the new distance from the center. Right?

So we would need 3 types of input:

Shift amount
Scale factor
Length

Assuming the current distance from center is 5.4 we could make 3 types of notations when entering the value of 2

A) 5.4 +2 = 7.4
B) 5.4 *2 = 10.8
C) 5.4 =2 = 2

As explicitly typing units is the most cumbersome I’d suggest they are assumed default (example C). This is what @gustojunk would like…right?

For scaling we would add the prefix * with an option to add a - for negative scaling. (*-1 would mirror )

For shifting we would start with an + or -

For convenience I’d even opt for the input field to reflect the current length.

So the inputfield would either be pre filled with the current value and the user can edit it for C) or add a suffix calulation A) & B).

Yet this would require extra clicks for C) to backpace/delete the current value.
So how about the inputfield would be preceded with a field showing the current length. The input field after that would be accepting the 3 types of input based on prefic charaters
`* *- *+

  • -`

I like the idea of showing the current value as it’s og value to verify and know the current situation.

For discoverability of different types of input which is a serious issue. I’d opt to maybe prefill the inputfield with preselected text like so

*=scale +/-=shift
Or a tooltip when hovering. …

-Willem


(Gustavo Fontana) #5

I don’t thinks that doing math or expecting people no know that the various options even exist make sense.

The handle is a scale1D tool. And the default, pre-existing, and expected behavior is that numeric inputs are scaling factors. 90% of users will only use that. Adding units makes sense because it’s a way to tell Rhino that it’s NOT a factor. Just keep in mind what the Scale1D tool asks you:

Step 1.

Step 2

So in the gumball these are:

Also in some places people work with different units. So my file units might be in mm, but I might want to do my next transformation in inches.

I’m ok with the handle (that shows only towards one side of the gumball from its origin to the objects edge on that direction) so only affect the explicit distance of half of the object and make it the same to the other side. That’s how the scale1D tool work.

What makes no sense is doing this when the gumball in on one end of the object. Because that is not how the scale1D tool works.

…but what’s confusing here is that relocating the gumball to a corner of the object leave the scale handles pointing to nowhere and still show that the are targeted to half length based on their prior centered position, instead of the new full object length:


(Willem Derks) #6

Hi Gustavo ( correct right?)

I’m out, this is to convoluted to get a solution to satisfy all IMO

I agree with your observations, yet I think this needs a good thinking over as leaving out different types of input wastes great potential.

I’ll leave it up to the developers to come up with a new implementation.

If need be I’ll shoot again after that.

-Willem