BoxEdit & Gumball improvement

Rhino Version 5 SR8 64-bit
(5.8.40315.18095, 15/03/2014)

I use Boxedit & Gumball extensively for object manipulation.
I really like Boxedit for its absolute value editing & it is my main tool for technical design.
Just a couple of things that would improve use of this great tool.

BoxEdit:
1 For Size & Scale editing, it would be useful to lock aspect to another axis, This could be a small button/CheckBox beside the axis label. This would change the selected axis relative to the new value of the edited axis. It should not clutter the form if the button is small.

2 If I edit a size value then change the pivot, the value reverts. I am often forgetting to set pivot first. :person_frowning:
other attributes Position & Rotation would change with pivot but not size or Scale.

Gumball:
3 Scale handle has a keep aspect(3d) by holding shft, it would be useful to have a 2d keep aspect, this would be relative to the current view(except perspective?). This could be achieved by holding another key eg: shft + ctrl/alt.

4 Reference point. I can drag an arrow (hold ctrl) to reposition the ref point, but it is difficult to get an absolute position. (eg: edge of object) With Osnap on it depends where I clik on the arrow.
There is a white dot that indicates the reference point, It would be awesome if this could be dragable. :slight_smile:
Using the RelocateGumball command/menu is too complicated(for me) for just repositioning, I struggle with using this command.
A simple MoveGumball would be great, where I can just click on a target point & its done. :slight_smile:

A good tool will enhance creativity & productivity, rhino does this exceptionally with many of its tools.

1 Like

This is a common request - would the 2 dimensions follow whatever the little plane dragging icon is? Otherwise, which should Rhino choose? I can imagine a Shift Click and drag in the ‘plane’ handle could be a Scale2d in that plane, though that would be a little weird too since there would be two different scale controls.

If you use this and just hit Enter after positioning the Gumball, it will stop asking questions and lat you carry on with your work. Does that work for you? You can make a macro for an alias:

_RelocateGumball _Pause _Enter

-Pascal

Hi pascal,

Yes, or in 2d display the plane of the current view. (same)

Shift Click and drag in the ‘plane’ handle exists as 3d scale, so possibly Shift+Ctrl keys

Awesome, thats perfect. :slight_smile: I might go home early today.
Thanks for the help.

Hope my suggestions for boxedit are considered.

toni

Hi Pascal,
some comments…
@gumball: All transform widgets I have used have handles in separate locations for 1,2,3D scale operations, so this is not exactly uncommon. Where the Rhino implementation differs is that Scales handle are situated at the object boundary, which leads to the questionable situation that handles for closely related operations (1,2,3D Scale) may be situated far away from each other – literarily 20 cm’s in screenspace – or even that the combined 1 and 3D scale handle is not even visible on screen!

scale handle not even visible on screen

On the other hand, the same logic inevitably causes scale handles to move very close together, this is the same box in another zoom state. At this zoom rate one has lost the abiltity to reliably Scale 1D as well as 3D by using the widget. Picking the proper handle is a matter of luck as handles don’t even give feedback (highlight) on mouseover.

Same model, other camera angle: Here picking the appropriate scale handle is a matter of luck

Usability wise this all imo is far from optimal, comparable widgets perform a lot better here. So before thinking of hooking up 2D scaling on the planes I think one should first reconsider the overall design of that widget.What does one actually win by using the Bounding Box for the Scale operator? If one wants to allow for relational scale and osnaps while scaling this also works with implementations which have a fixed screen size. In addition I see issues with the rotate handles as I in certain alignments have troubles to distinguish their spacial orientation. It regularly happens to me that I grab the wrong handle, which doesn’t happen to me elsewhere.

That said I can see that this manipulator is quite a design challenge as Rhino doesn’t distinguish between separate widgets for Translation, Rotation and Scaling, as commonly used in mesh modelling apps. To me it feels very natural to quickly change modes via hotkey so that’s what I personally prefer. If one crams all these functions into just one universal manipulator it’s likely to either leave something away or to end up with something pretty convoluted. Here’s a feature complete universal manipulator, alternatively offered inside a mesh app which gives access to everything at any magnifiation rate and which via mouseover highlight helps me distinguishing modes – but it’s of course a monster. I forgot demonstrating the cyan coloured ring, this is rotation in screen-space. (note:one obviously needs to click the image to play the gif-animation)

What's quite interesting though is that as soon as user decided for one transform type all now irrelevant handles do disappear.

@ Box Edit:
I found consequent if you guys transferred your elegant Alt key driven inversion concept as known from checkboxes in Editors like SetPt or Osnaps/Filters to BoxEdit too. That principle should be applicable in all entries and allow for setting all desired axis restrictions with just one click. Makes sense?

cheers, Holger

1 Like

While at it: On my machines the mapping to Shift for 3D-Scale works very unreliably. Sometimes I can not get this function to work at all.In the attached gif I try several times in a row to scale that sphere down to half of its size uniformly. I always hold shift while hitting Enter. Simply doesn’t work.

Hey Holger,
What I do is Shift+click in the box, then let go the shift key and type the number and enter. Does that not work on your end?

Gruße aus der Westschweiz…
–Mitch

Yes, the other unfortunate side effect that I run into every day, is for lines and linear object edges, the scale handle coincides with one end of the line/edge. This makes it impossible to snap-drag the object on that end, I am forced to use Move. This happens to me many times a day…

–Mitch

Trying out E-mail response for the first time now…
Edit: Seems not to work well, formatting all off (used Thunderbird).

Hi Mitch,
@ 3D-scaling: ok I think I now understood what to do. To be precise one need to already shift-click the respective coloured rectangle which is the scale handle, then let Shift go and type the number in the numerical input box which comes up afterwards.

That works.
Man, one really needed feedback here – it would help tremendously if all scale handles highlighted, once shift got pressed while hovering over that scale box. It wouldn’t solve the other issues I talked about earlier though.

Holger

Yeah, I really like the Gumball for what it can do now, but there are lots of limitations and quirks. Mainly for me it’s trying to remember all the different sequences of keypresses needed with alt, shift and ctrl to do the operation I want.

The ones where you just need to hold the key(s) down while you are doing something are easy enough, but the ones where you have to hold the key and click, then let go are difficult for me - like with ctrl, the difference between moving the gumball or extruding is when you actually hit the key during the process. I never get it right (and there is no feedback), so the result is I rarely use the function…

Geez, I never knew you could even respond via e-mail…

–Mitch

Gumball:
I feel uncomfortable with modifier keys: Shift,Alt etc … (especially when working on different keyboards, laptops …)
OK, my fault, but …
What about a way to transform object(s) without modifier keys ?
A few hypotheses:

  • another little ball opposed to the menu ball (or after it along the white line ) might scale 3d (or 2D … see below)
  • a ‘C’ letter drawn on the same plane as the little drag plane (or …) might enable copying when preselected.
    copying, for any transformation
  • always draw all three drag planes, which (when preselected) might enable planar move/copy and scale.
  • make the different pieces that compose the widget hideable in the settings (anyone could choose what to see and use)
  • a way to repeat the last used numerical value in the editbox (say by typing ‘0’ or … ), also a way to negate it would be fine.

Thanks

Thanks for the Gumball Mouseover Highlighting in the latest WIP!
Extrude Handles which appear on Subobject selection don’t convince me. While I see that some users
aren’t comfortable with calling more options via Modifier keys, I don’t think one should hook it up that way,
More on that later.

Probably an oversight:
Gumball when set to snappy respects temporary Osnap suppression when holding Alt. Alt pressed with Gumball set to smooth doesn’t inverse its behavior.

Could you maybe also have another look at the behavior of the Alt-key with an existing selection and Gumball or non Gumball drag action? There’s no clean enough distinction between Osnap behavior inversion and changing to “drop object copies” mode. Also the Alt-Key often seems stuck in either Copy Mode or Non Copy Mode – key presses often seem not to register. Maybe one should use a time interval which converts Alt key held down with object selection to osnap state inversion.Generally I don’t think that this mapping is too dense, it just needed some tune up to work more reliably.

Yes!

Well, I do like it much better than the current V5 behavior. For me, it works, but then I’m one of those non-adepts of modifier keys that Holger is talking about… :smiling_imp: :innocent: --Mitch

Yeah, I’m not sure how to serve those best who can’t get used to pressing lots of keys to drive commands.
It at least should not lead to a Christmas Tree like widget for everyone, I already hate that settings bunnyball and the fact that one actually needs to run a command to set its drag strength: In the Gumball Rotate functionality one can nicely see how such a multiplier could get dosed by distance.

The central problem I see with this extrude implementation is that it is actually issued by Gumball itself and that its direction constraint is inevitably set by the handle dragged. This determines an inflexible behavior right from the beginning. It will not take long and there will be (rightful) wishes for extrusion in 2 dimensions and difficulties to cram them into the widget adequately - that’s currently also the issue with Scale. One possible alternative approach to deal with the problem was to first issue a sub-object duplication in place (not directly tied to a specific gumball handle) and to then use all existing Tools the Widget offers to actually shape the duplicate.

In this gif you see me first simply scaling the face, then a in place duplicate is created which can get treated with existing tools.

I failed to resist spending more time on thinking about Gumball than I should. Looking at the V5 Gumball I see the following isssues:

  • It does not offer all basic transform types, some are well hidden. Scale3D can only get accessed via Hotkey, Scale2D is unavailable, 2DMove doesn’t allow for numerical entry.
  • The Widget doesn’t give feedback. This part just got greatly improved through mouseover highlighting
  • The placement of rotate handles makes the widget larger than necessary.
  • The underlying logic used is inconsistent - while Scale handles react dynamically to the object size all remaining handles have a predefined location/size. This got addressed in the latest build.
  • The settings ball gets accessed with LMB. This is a needless trap in an area full of often accessed handles which use LMB. It’s the only handle offered which differs semantically, it opens a context menu and therefore should get accessed with RMB. Quite in general one should make all context menu functionality accessible by pressing single hotkeys too, that way one could for instance quickly cycle through different orientations of the widget.

Here’s a mockup for a possible Gumball redesign, it’s nothing really new and certainly isn’t visually refined yet. It rather picks up established conventions found in various other programs and combines them into a hopefully half way slim universal manipulator. While it looks considerably different, everything should work as usual and on click onto a handle a numerical input field appeared.

Appearance with a rotate handle clicked, irrelevant stuff gets culled. One might offer another circle for rotation in screen space but stricty speaking one then needed the same for Move and Scale too…

An alternative angle.


As stated before I would suggest to limit Gumballs handle types to just basic transforms. Should one e.g. at some point decide to offer Subdivision Surfaces, limiting Gumballs Extra-Features to Extrude appeared as a random choice. One needed another handle for Bevel, yet another for Bridge. I think one should deal with this topic differently.

2 Likes

“latest WIP!”

Where can I find the WIP…


One thing I need to do often with gumball is to move the reference point to an edge of the object, easy enough to do but if I have numerous objects to transform I have to move the reference for each object & it gets time consuming.
Modifier keys in my opinion add powerful functionality to a tool like gumball without cluttering the widget on screen. Modifier keys typically are very ergonomic to use as the effect is obvious from visual feedback.

I use 2d display mode extensively for precise alignment of objects, maybe Gumball can behave differently in 2d mode to apply functionality only to the 2 axis displayed.

toni

I agree that the scale handles should NOT be sized to objects in the future, it’s inconsistent to the other controls, very hard to use in most cases, and completely unusable in others.

ill second that one. the scale handles are often off the screen and hard to grab.

I like the layout. It looks as though it would obscure the underlying object to a far lesser extent than the existing Gumball. It looks as though it would also work cleanly in ortho views.

For Scale1D, add the same ‘square’ as for Scale2D, but next to the main X,Y, Z axes? That would infer a logical link. I guess Scale3D could be a small floating cube, positioned at the missing corner of the ‘box’ formed by the 3 Scale2D squares, but I think it would add too much visual clutter

Hello!
Just having a quick look at 6.0.16135.23041, 14.05.2016…

Regarding BoxEdit:

  1. I noticed that after entering a value, only clicking “Apply” accepts it. It would be comfortable if the ENTER key could also be used for applying, and ESC to leave the text input fields.

  2. Something I wished for some time ago already:
    it should also be possible to enter values relative to the Gumball, not only World and CPlane - see mockup screenshot.

Being able to set values relative to the Gumball/object would come in handy e.g. when you have a rotated object and want to set it’s size.

I know that the Gumball axes can be clicked to enter numeric values, but that’s complementary, not a replacement.

What do you say?
Thanks!
Eugen

1 Like

My 2 cents are that I would like the relocate gumball command to be “sticky”. Unless I’m missing something, the gumball resets once I’ve performed a command after relocating it.
Also, what program are you guys using to make these short videos I’ve seen posted lately? Very handy!

Dennis